とちぎRuby会議02がありました！普段は技術や「普及するには？」ということについて語られることが多いIT系イベントですが、仕事としてのマインドについて多くのメッセージを聞くことができました。今回はその中でLTの発表をしてきましたので、スライドとスクリプト(時間の関係でかなり削りましたが)を公開します。裏切り者感たっぷりのスライドですが、最後までおつきあいください。
今回ご紹介したいものが、このSphinxです。
Wikiみたいなプレーンテキストの簡易マークアップから整形してくれるツールです。相互リンクも張ったり、索引を作ったりもしてくれる。LaTeXを経由しないPDF出力は現在活発に開発されている部分。これができるとかなり強力です。コードハイライトも、nginxというリバースプロキシーサーバの設定ファイルみたいな、超マニアックなフォーマットのハイライトにも対応していたりします。
僕の最近の活動はSphinx関連が多いです。
まずはドキュメントの翻訳。夏休みをつぶしてやりました。今も普通に使う部分はほぼ完了。拡張機能周辺だけが残っている状態です。浴衣の女性とかが街を歩いているわけですよ。花火大会、お祭り。Sphinxには、そのような一夏の思い出を捨てでもなお、価値があります。
あとは検索の多言語対応。これはパッチを投げています。開発者の人は忙しそうなので、取り込まれるかはわかりませんが。
テキストで擬似コードを書くと、シーケンス図をSphinxに画像にして入れてくれるプラグインも作りました。
それではインストールの仕方の説明をしていきます。まず準備としてしておかなければならないことがあります。この会場はMacを使っている人が多いと思うので、Macの説明だけしますね。
(メモ：)ここは１文字ずつ増えていくように20枚以上スライドがあって、タイピングしているような演出をしました。
残念ながら、SphinxはPythonで書かれたプログラムだったのです。すみません。
Sphinxは開発されてから１年ちょっとですが、数多くのプロジェクトで使用されています。Python本体もそうですし、Pythonじゃない人でも聞いたことがあるようなWebのフレームワークのDjangoやTurbo Gears、Zope3なんかも使用しています。Python以外でも、SeleniumやSelfも使っているし、僕の周りにはScalaの文章を書いてみようかな、という人やErlangの本格的なドキュメントを書いている人もいます。
ドキュメントの翻訳をしてからは、Sphinxを使うユーザも増えたようで、Twitterなどの上でコメントを書いてくれる人もふえています。
中には、「モテる」と言っている人もいるし、「ニヤニヤしちゃう人もいる」という報告もあったし、「Javaに欲しい」という人もいる。今回来られている懸田さんも「巨大なドキュメントに便利そう」とメッセージを書いてくれていますね。
本題にうつる前に、今回、時を超えた創造の原則
WikiとSphinxは処理の流れというか、アーキテクチャーについてはかなり似ている部分が多いです。Wikiはウェブアプリケーションで、Sphinxはローカルアプリケーションという違いはありますが(昔はSphinx-webというWikiっぽいのもあった模様)。テキストで書いていき、相互リンクが張られ、ドキュメントのエコシステムが完成していきます。その中でも一番大きな違いは、文章の構造です。
Wikiに関しては皆さんご存じだと思います。Sphinxの文章は完全に木構造を保っています。子供は完全に親に包含されます。文章を辿るナビゲーションも、このツリー構造になっている目次を辿るというのが主な使い方になります。ロジカルライティングされた文章構造に近いので、全体像は掴みやすいです。一方、Wikipediaを延々とWebサーフィンするような、世界がどんどんひろがっていくような探検する楽しみはありません。
ようやく本題にはいります。
Oracleという会社は皆さんご存じだと思います。こちらのドキュメントに関する考えを紹介します。なお、内容には紹介者のやまぐち氏の個人的な熱い思いも含まれているみたいです。
ばしっと言い切っていますよね。
ここからはOracleの話しではないですが、昔から言われていることですが、最初はハードが商売でソフトはおまけでした。ちょっと前はコンポーネントやミドルウェアなど、ソフトの部品を売るのが主流でした。ソフトウェアのコンポーネント自身にお金を払っていました。
そして現在はオープンソースが当たり前になってきて、ソフトウェアの部品そのものを売るのではなく、それをカスタマイズしてシステムを提供して、サポートしていくという流れが確実に着ています。クラウドのムーブメントもあって、ハードウェアそのものもサービスの範疇になってきています。
例えば、LShiftという会社がありますが、ここの会社はコアになるRabbitMQというメッセージキューの部分をオープンソースにしてしまっていて、それを各ユーザのシステムと接続する部分の開発などを商売としているようです。このように、オープンソースが商売になっているということ自体、コードのビジネス価値が我々の仕事の100%であるというわけではない、ということを示しています。
最近ドキュメントやサポートについて考えていることはこのようなことです。ソフトウェアそのものと、同じ物差しで価値を判断することができるんじゃないか、ということです。
アジャイルはドキュメントを書かないと言われるという問題があります。
よくある反論はこれですが、どうひいき目に見てもいいわけっぽく聞こえます。
一方で、「アジャイルはテストをしない」とは言われません。むしろテスト厨というぐらい。このドキュメントとテストの待遇の差は、テストには「テスティングフレームワーク」という象徴があるからだと考えています。
Sphinxはプレーンテキストで作成されていて、ソースコードと一緒に成長していくドキュメントに最適です。
Sphinxはドキュメント界のSUnitになれるのでは、と思います。SUnitが出るまでもテストをするツールはあったし、みんな自作していたはずです。テストというプラクティスがなかったわけではありません。でも、SUnitというツールの形にまとまったため、業界全体の知識体系が発達し、平均値があがったと言えます。Sphinxにもそのような力があると思います。開発を加速するドキュメンテーションのプラクティスがここから花開いていくはずです。
今後僕が取り組んでいきたいと思っているのは、文芸的ユニットテスト。TDD、BDDという流れは、ドキュメントとしてテストを見ようという大きな流れの一部。それであればドキュメントの中に、本当にドキュメントとしてテストを書いてしまえるような拡張機能をSphinx上に作っていきたいな、と考えています。
なぜ、このRuby会議という場でわざわざPython製のツールを紹介したのかという真意は、是非ともSphinxのクローンが増えて欲しいから、というのがあります。Rubyでも似たようなツールが出てきてクローンが増えてくれば、こそ、Sphinxの価値はもっと認められていくはずです。Wikiだってテスティングフレームワークだってそう。色んなクローンができて、バリエーションが広がったからこそものすごい普及していった、というのがあります。
なので、誰か作ってくださいw
Sphinxの開発の経緯が書かれたブログ(今翻訳は完了していて、公開OKかどうか問い合わせ中)を読むと、Wergzeugというウェブのフレームワークの開発で、手書きのドキュメントと、自動作成のドキュメントを融合させるために、PythonにおけるRDtoolであるdocutilsをベースに開発されたとあります。RubyにはすでにRD/RDToolという文化が根付いていると思うので、ここを起点にしてRuby版Sphinxは作れるんじゃないかな、と思います。
ちなみに、当日LTではヒトコトも説明できなかったけど、このブログを書いたArmin Ronacher氏(Twitter上は@mitsuhiko)は、20歳前後のオーストリア人。Wergzeugをはじめとして、かなりのすご腕プログラマーです。天に二物を与えられたヤツという評判です。Wergzeugのドキュメンテーションを通じてPython本体への影響も与えているし、これからのPython界を引っ張っていく人財です。DHHよりもイケメンだと思います！
で、そろそろPythonのインストールは終わった頃だと思いますが・・・
sphinx-quickstartコマンドでRailsのscaffoldみたいなドキュメントプロジェクトができます。後は中にドキュメントを追加していって、ビルドするみたいな流れです。詳しくは以下のブログエントリーを参照してください。僕のこのブログは今のところ日本語で書かれたSphinx情報は一番集まっていると思います。
みなさんはユニットテストを書いたことがあると思います。初めてユニットテストを書いた時の感動に似たものを感じることができます。まずは使ってみてください。
