2010年09月4日に早稲田大学西早稲田キャンパスで「XP祭り2010～アジャイル学園祭」が開催されました。数あるイベントの中でも主催者、発表者、参加者の垣根が限りなく低いこのイベントの模様を、4名のレポーターの方に振り返っていただきました。
なお、本レポートEM ZERO Vol.6に掲載したものの完全版です。
Jxckさんのレポート
「Pythonでアジャイル開発サイクル2010ver.」（清水川貴之さん）
清水川さんの「Pythonでアジャイル開発サイクル2010ver.」というセッションに参加させていただきました。その場で、実行委員長の渋川さんが、「セッションに来られなかった人のために、レポーターをやる人」を募集していたので、手を挙げさせていただきました。スライドについての補足と個人的な感想等を添えながらまとめたいと思います。
なお、セッションのスライドはWebで参照できます（http://www.freia.jp/taka/docs/xpfest2010/）。
このスライドは、id:amachangさんが作成したs6というHTMLプレゼンテーションツールを使って作られています。使い方は、とりあえず「←→↑↓」ボタンを押してみれば分かると思います（少し重いです）。
セッションの概要
主に、アジャイル開発に必要になる以下のような自動化ツール類についてのお話です。
- ソースコード管理の自動化
- テストの自動化
- 環境構築の自動化
- 継続的インテグレーションの実施
- ドキュメント生成の自動化
「これ全部Pythonで揃うよ！」といった内容で、“Engineering Practiceなコンテキスト”の話でした。
清水川さんの自己紹介
清水川さんはお仕事でもPythonを使っており、昔は組み込み系の開発でXPを実践されていたそうです。参加コミュニティは主にZope/Plone、Sphinx、pyspa、XP関連。最近は、Deliverance/xdvといった、「Webフレームワークのテンプレを書き換えずにデザイン適用」する技術に注目しているそうです。
そして何より、最近『エキスパートPythonプログラミング』（http://d.hatena.ne.jp/asin/4048686291）という翻訳本を出されています。清水川さん（と実行委員長の渋川さん、他2名）による翻訳本です。Pythonに限らずソフトウェア開発者全般にとって勉強になる内容なので、ぜひ読むことをお勧めします。 7～11章はPythonと言うよりは XP（正確に言えばPythonで、いかにXPのプラクティスを実践するか）について幅広く書かれています。本セッションもこの辺のお話でした。
ソース管理の自働化
何を自動化するにしても、まずはコード管理から！
ソースの管理は、VCS（Version Control System）を使用して行います。これでソースそのものの管理、ソースの変更履歴の管理、そしてソースの共有を行うことで、以降の自動化の基盤を形成します。
VCSにはCVS、SVNといった中央集権型（中央にセントラルリポジトリを持つ）と、hg、bzr、git等の分散型（リポジトリのクローンが複数箇所にある）の大きく2種類があります。
清水川さんは、導入にサーバ等が必要ない“分散型”がお勧めとのことで、Pythonで作られたVCSであるhg（mercurial）を紹介しました。導入と基本の使い方は以下のとおりで、インストールはpythonのパッケージ管理システムであるeasy_installを使うとお手軽です。
easy_install mercurial
hg init
hg clone
さらに、mercurialに内蔵されたサーバ機能を使えば、ソースのちょっとした履歴の確認や、共有のための公開が簡単にできます。
hg serve -p 8000
環境構築の自働化
- プログラムはVCSから入手するだけでは動かない場合が多い
- 関連するプログラム（依存ライブラリ等）を入手、配置
- パスの設定、スクリプトの設置
- 環境設定ファイルを配置、必要に応じて変更
そこで、こういった環境構築を自動化するのがbuildoutです。buildoutは、buildout.cfgというini形式のファイルに環境構築に必要な情報を記述しておくことで、構築を自動化します（スライドは、ZopeとPloneを自動インストール＋プラグインも入れるbuildout.cfgの例）。
設定を記述したら
$ hg clone http://xxxxx/ .
$ ls
bootstrap.py buildout.cfg
$ python bootstrap.py
$ bin/buildout
で環境構築完了です。これで完璧とはいかない場合もありますが、だいたいの部分はうまくいきます。
デモとして、zc.buildoutでGAEの環境を作成する例が実演されました。cfgファイルは、テンプレートが多く公開されているので、少しいじれば使えるものも多いそうです。実行すると、必要なライブラリ等が展開されます。appengineの場合はファイル数制限があるので、よく使うライブラリはあらかじめzipに固めるようなことも、cfgの設定で簡単にできます。
仕組みとしては、“レシピ”というものを呼ぶだけなので、誰かが書いたレシピや、レシピを自分で書けば、いろいろな環境を構築できます。
テスト自動化
Pyhtonには、標準でユニットテストライブラリがあり、すぐにでもテストが始められます。それでは機能が足りない場合は、Noseやpy.test、渋川さん作のPySpec（RSpecのpython版）等があります。テスト周りは、RubyやJavaのほうがまだ少し強い面もありますが、pythonでも十分ユニットテストは可能です。
また、他の言語にはあまりないPyhtonの機能として、DocTestがあります。これは関数にヒアドキュメントを書くと、テストとして実行できる機能です。機能の説明が、そのままテストになるというスグレモノです。次のようなものです。
def add(x, y):
""" 二つの値を足します。
>>> add(1, 2)
3
""""
return x + y
※これは以前、清水川さんが書いたブログの転載です。
スライドには、DocTestを使ったTDDのデモFlashがあります。
注意点としては、docTestだけで何でもかんでもテストを書こうとしないこと。しかし、関数の使い方の説明とテストがくっついていると、ドキュメントが集約され、あちこち見に行かなくてよくなるという点で非常にメリットがあるとのことです。
継続的インテグレーション
ここでは、いわゆる CI（Continuous Integration：継続的インテグレーション）のお話です。CI用のソフトには色々あります。
ここでは、Python製自動テストサーバーBuildbotが紹介されました。Pythonが動作する環境であれば動かすことができます。
基本的な使い方の流れは、
- テスト書く
- テスト通す
- コミットする
- フックする
- buildbot走る
- エラーだと通知やパトランプ
です。複数人が共同でソースを書いていく場合は、誰かのコミットが他に影響したことを知るために、こういったCI手法が有効です。buildMasterが統合の集中管理をしており、buildSlaveの管理や、結果通知等をしているようです。また、buildbotは色々なvcsに対応しています。
こうした柔軟性から、Buildbotは次のような多くのOSSプロジェクトで採用されているようです。
Buildbot、Python、Webkit、Mozilla、Google Chromium XEmacs、MongoDB、Wireshark ILM、Boost、Zope、Twisted、SpamAssassin、OpenID、KDE、GHC、Subversion、OpenOffice、Jython…
BuildbotやPython本体はもちろん、WebkitやChromium、XEmacs等そうそうたる顔ぶれで、その実力が伺えます。
ドキュメント作成の自動化
ドキュメント作成はさぼってしまいがちです。
- 向かうにつれて時間がない
- 文章を書くのが苦手だ
- 見ない文章は書きたくない
という状態を
- ドキュメントを書くのは楽しい！
- プロジェクト開始時にプロセスを整備
- 必要な文章を必要な時に書く
- ソフトウェアコード同様に成長させていく
という方向に持っていくのが大切です。そのために、「ドキュメントを書くのをもっと簡単に！」するためのツールとして、Sphinxというツールが紹介されました。
SphinxはPyhtonで作られたドキュメント生成のツールです。reSt（reStructuredText）というwikiのような記法で記述します。ソースのビルド時に、ドキュメント間のリンク生成や、強力なコードのシンタックスハイライトを使って見やすいドキュメントを簡単に作ることができます。
また、作成したドキュメントは、HTMLやPDFだけでなく、ePubにしてiPad等で見ることもできます。Pyhtonのdocutilsやpygment等の既存記述をうまく組み合わせて作られており、拡張もPythonで書くことができます。最近はOSSでドキュメント生成に使われたり、日本では翻訳プロジェクトでも使われているようです。
ドキュメントの生成は、“make”を使うので、“make html”を先ほどのCIで回しておくと、作成しながらすぐフィードバックを得ることができるとのことです。
また、ソースはテキストなのでバージョン管理もしやすく、セミラティス構造であるwikiに対して、Sphinxはツリー構造であるため、構造をシンプルに保つことができます。
以上のことから、Sphinxは最終成果物として非常に利用しやすいそうです。
なお、「渋日記：Sphinx紹介セッション@BPStudy #30」に渋川さんの紹介資料があります。
課題管理システム
複数人でプロジェクトを進める上で、バグや課題等を管理するシステム（プロジェクト管理）が重要になります。PythonだとTracが有名です（他にはRedmineなど）。
Trac＝wiki＋課題管理＋コード管理
Tracを使った作業フローは次のようになります。
- 誰かがチケットを書く
- 担当者がAcceptしてコードを修正する
- 修正をコミットする
- コミットログが自動で同期される
- チケットをcloseする
- ノウハウ等をwikiに記録し共有する
このとき、チケットやコミットの動きはTrac上のTimelineという画面で流れを追うことができますし、チケット登録時の#idを使って、コミットと実装を紐づけたり、wikiとリンクを貼ったりできます。
プロジェクトで出てくる様々な課題に関する情報が一元管理できて、さらに必要な情報が繋がっている（散らばっていない）ということで、プロジェクトを円滑に進めることができます。
全てを1つに繋ぐ
ここまでに出てきた
- ソースコード管理の自動化
- テストの自動化
- 環境構築の自動化
- 継続的インテグレーションの実施
- ドキュメント生成の自動化
これらを全て、自動化し連携させる、そして「これら全部をPythonでできるよ！」というお話でした。
質問タイム
会場からの質問と、清水川さんによる回答です。
Q1：テスト周りがRuby等に比べると遅れているという理由は何ですか？
A1：ユニットテストの文化はあります。しかし他の言語は「自然言語の文脈からテストを行う」といった領域にも挑戦しています（rubyだとcucumber）。Pythonにはそういうのがありません。
Q2：ソースを分散VCSで管理した場合、どうやってCIするのですか？中央集権型のほうがよくないですか？
A2：分散型であっても、ずっとバラバラなままではなく、最終的には1つにまとめます。Mercurialでも中央サーバに当たるものを1つのcloneに位置づけて、そこでCIを回します。その点、「どれを中央サーバにするか？」などの運用ルールはその都度決める必要があります。
Q3：Sphinxで他の文書をimport／exportする仕組みはありますか？別のドキュメントやtracのwikiとか再利用したいです。
A3：今は、頑張ってパースをかけるしかないです。しかし、HTML等は構造化文書なのでパースをかけやすく、Word等もHTMLで出せるので、できなくはありません。手動でやらなくても、そういうサービスをしているサイトもあります。DocBookというものもあります。あと、TracはwikiにreStを使うことができるので、reStで書いておくと後で使い回せます。
おまけ
今回のプレゼンは、Sphinxを変換してid:amachang謹製のS6というHMTLプレゼンツールで書かれていました。
感想
今回は、Pythonを用いたプロジェクト自動化の各ツールを横断的に紹介＋デモという内容でした。ツール自体がPython製なだけで、多くのツールはPythonを用いた開発でない場合でも十分に通用するものです。
開発に集中するために、プロジェクトの最初の段階でこういった環境をきちんと構築してしまうと、そのあと多くの場面で恩恵を受けることができると思います。
もし一度に全部を導入するのに敷居の高さを感じるのであれば、個人的にはソース管理のMercurialやドキュメント作成のSphinxから始めてみるのがよいのではないかと思います（テストはもう書いていますよね？）。
今回は概要でしたが、もっと詳しく知りたくなったら、清水川さん他4名による以下の翻訳本『エキスパートPythonプログラミング』を読むことをお勧めします。前述しましたが、Pythonの話だけでなくXPの話が多く出てくるので、Pythonユーザ以外にもお勧めできると思います。
以上でレポートを終わります。清水川さんありがとうございました！
