pyconjp で発表してきた #pyconjp

Python Conference Japan 2012 で機会を頂けたので発表してきました。 45分枠で70名くらいの方にご参加頂きました。

資料は Google Docs で作成してあり、プレゼンテーションは YouTube にアップされています。 プレゼンの終わりの方でノートパソコンが不調になってしまって５分くらい止まってしまい、せっかく聞きにきて頂いた方には申し訳ない感じです。 また機会があれば、もうちょっとちゃんと準備しておきたいと思います。。。

目次

• 資料など
• 補足
• 終わりに

資料など

目次

• 概要、自己紹介
• ソフトウェアの開発プロセス
• 発表で扱う範囲・扱わない範囲
• 環境の構築 - virtualenv + pip
• 実装サイクルについて考える
• 様々なツール - meta build, DSL
• Sphinx を例に比較 - make, scons, waf
• waf を使う - pyflakes, pep8, nosetests
• zc.buildout を使う - Google App Engine, Solr, MongoDB
• まとめ

動画

補足

時間の都合もあって説明には含めませんでしたが、ビルドツールとその周辺ツールの相性、という問題もあります。 たとえば、scons を virtualenv 環境下で動かすことは難しいはずです。 何らかのオプションを有効化する、あるいはインストールプロセスを工夫することで解決できるかもしれませんが、 そこを頑張る必要があると本論からは逸脱してしまうので、言及しませんでした。 「簡単に使い始められるますよ！」という部分を共有しておきたかったため、scons ではなく waf を題材として使っています。 個人的にも scons よりは waf の方が良いと思います。コマンドを実行する書き方が直感的 (= 個人の主観) なためです。 平たく言えば、「すでに scons を使っているならば仕方ないけど、これから使い始めるなら waf の方がオススメ」ということです。 ただし、ドキュメントの量が少ないので自力で読み解く必要があります。

実行速度についても言及を避けています。 たいていのビルドシステムはファイルの依存関係を解決してくれますが、この処理に時間がかかります。 依存関係を解釈するルールはツールによって異なりますが、もちろんベースとなるソースコードの量に依存します。 ちょっとサンプルで作ってみた、という程度で比較しても意味がないのと、大量のソースコードを含むビルドシステムの置き換えを試してみる時間を確保できなかったので、資料に盛り込むことはできませんでした。 いくつか使ってみた所感をベースにすると、scons はそんなに早くありません。 また、多くのプロジェクトは速度よりも記述の簡便さで選択することが多いようです。 特に、開発者が増えてくると、この傾向は強いのではないでしょうか。 システムのすべての部分をビルドするのは Jenkins などの CI サーバに任せて、個々の開発者は分割されたモジュールの開発・ビルドに注力するためです。

終わりに

自分の準備不足で最後がちょん切れてしまいましたが、伝えたいことは盛り込めたかな、と思います。 ビルドシステムの構築は特定の人に偏ることが多く、まとまったノウハウを共有しにくい分野だと考えています。 また、CI システムを構築する上では幅広い知識が要求されることもあり、なかなかうまく進められないプロジェクトも多いのではないでしょうか。 Python 製のビルドシステムを導入することで、記述の一貫性を保ちつつもスクリプティングでコーナーケースを回避できると思いますので、プログラムの文法は覚えて動作するソフトウェアを書けるようになってきたら、チーム開発に必要な基盤を整えられると良いですね。

今回は、発表の機会を頂けて、どうもありがとうございました :D