Rubyカンファレンス2006

いやあ、面白かったの一言。

多士済々という言葉がピッタリだと思う。プレゼンの内容も人もどちらも面白かったです。

ざっと見た所では、まちゅダイアリーさんのまとめがよくまとまってて、2日目の方にリンク集もある(来てたのなら、ぜひお話ししたかったです)。

私も少しづつ感想を書いていきます。

gem戦記スタート

ということで、無事Rubyカンファレンスの発表も終わったので「Amrita2強化月間」は終了して、このブログは「gem戦記」として再スタートすることにした。本当は、永遠に「Amrita2強化月間」を継続するつもりだったのだけど、二日目に会場に行く途中のゆりかもめの中で突然この名前が閃いて、そのままプレゼンの最後で披露してしまった。ブログのタイトルが天から降ってくるということは、「Amrita2に限定せず、もっとテクニカルなことを書け」という思し召しだと思った。

私のように右脳と左脳が変に密着している人間は、本当は二つのブログを適切に書き分けることは至難の技なのだが、こちらは、RubyとRailsを中心に純粋にテクニカルな話題を書いていくつもり。

「アンカテ」ともどもよろしくお願いします。後で、サイドバーにもう一方の最新タイトル一覧を入れて、どちらか興味のある方だけ購読しておけばいいようにします。

なお、gem とは、Rubyのソフトウエアをインストールする為のパッケージ管理システムの名前。Ruby on Railsというのは、実は多くのライブラリが一体となった複雑な構成のソフトなのだけど、これがあるおかげで、

$ gem install rails

と打つだけで一発でインストールできる。

普通は「ジェム」と読むらしいのだが、このブログのタイトルとしてはもちろん「ゲム戦記」と読んでください。

Amrita2は演繹的ソフトウエア？

私のプレゼンの資料はココ。XUL Apps > Tiny Applications > 高橋メソッドなプレゼンツール in XUL リターンズ で書いたので、firefoxオンリーです。

プレゼンとしてはボロボロだったけど、言いたいことは伝わったみたい。

というのは、発表の後の雑談の中で、たださんと後藤健太郎さんに非常に適切なコメントをいただいて「ああ伝わってたんだ」と安心した。それは自分なりにまとめて見ると、「Amritaはひとつの小さなピュアなアイディアからロジカルに演繹して作られていったソフトウエアで、そこに面白さと難しさがある」ということだ。

「ピュアなアイディア」というのは、資料に書いた「テンプレートとはそもそも何か」という疑問である。「HTMLで書かれたテンプレートは構造化ドキュメントであって文字列ではない、テンプレートエンジンはそれを文字列として処理するのではなく、構造を持ったドキュメントとして扱い、そこに構造を持ったデータを混ぜるという演算として、出力を生成すべきである」ということだ。

これは、今回の発表にあたって言語化したものだが、漠然とこのような思想は最初からあったと思う。私はどうも、そういう「思想」を一切の妥協無く、純粋に追及していくような傾向があるらしい。ひとつの「思想」を展開することで、たくさんの機能を演繹的に実装しようとしてしまうのだ。

そういう「思想」の過剰なソフトウエアは、たくさん機能があっても一本筋が通っているので、見た目の複雑さよりは理解しやすい所もある。機能やオプションではなく「思想」を理解してしまえばなんとなく使えるからだ。だから、一見して「これはいい」と使いはじめる人は多いようだ。

しかし、世の中にはさまざまな「雑事」があって、「雑事」は「思想」と相性が悪い。Amrita用のテンプレートを作成することは、(これは自分でもよくわかるのだが)非常に頭を使う作業であって、ちゃんと考えればできそうな気がするが、なかなか思うような出力が得られない。理論的にはAmritaはどのような出力にも容易に対応できるはずなのだが、実際の作業の中では、なかなか時間内に完成しない。だから、やってみて途中でAmritaを使うことを断念してしまい、その断念の理由はなんとなくうまく説明できない。そういうパターンに陥るようである。

Amrita2では、"partial ERb template" や "amrita:type=use_argsオプション"等(詳細は上記資料参照)、「雑事」をこなす為の拡張(妥協)を入れたので、いくらかは使いやすくなっていると思うが、これらを多用するのではそもそもAmritaを使う意味がないので、「思想過剰」という根本的な弱点は残ると思う。

そういうふうに考えると、tDiaryはAmritaと対極的な位置にある「帰納的ソフトウエア」と言えるのではないだろうか。私にとっては、tDiaryのソースは理解しやすいとは言えなかったけど、何かしたいことがある時に、やりたいことがすぐできるソフトウエアであることは間違いない。それは、一ユーザとしてインストールして、設定してプラグインを入れることというレベルでもそうだし、fcgiで動かしたり、静的なドキュメントを生成したりという、かなり実装のコアにかかわるような変更を加える時もそうである。tDiaryには「思想」はないがポリシーがある。「雑事をこなすことに最適化する」というポリシーがはっきりしていて、コードを外から見ても中から見ても使いやすいソフトウエアである。

たださんのプレゼンを聞いて、直にお話することもできて、それは偶然ではなく、明確なポリシーがあってそうなっていることを確信した。

また Rails は、「演繹的ソフトウエア」と「帰納的ソフトウエア」の両方の良さを持っていて、DHHのプレゼンは、「CRUDオリエンテッドという制約によってプログラマを自由にする」という、その「思想」の部分を明確したものであるかもしれない。

それと余談だけど、私の発表の後で、DHHから物凄い勢いでツッコミが入って、控室でしどろもどろにそれに答えているうちに、id:secondlifeさんの発表が終わってしまった。これが、今回のカンファレンスで一番残念だった。(今日になってやっと発表資料を見たけど、やっぱりこれは聞きたかった)。

DHHは、ふだん静かだけど、やはりソフトの話になると熱い人でした。

DHHのツッコミ

なお、DHHのツッコミは、以下の二点。とりあえず、自分用に、ツッコミの内容をメモっておいて、対応は後で考えます。

ビューロジックを別ファイルに分離できないか？

Amrita2はコンテンツの動的な部分をハッシュやPlain Ruby Objectのデータとして作成するのだが、私のプレゼンの中ではその処理をコントローラの中で行なうように書いている。これは説明の為の便宜で、実際には、Helperメソッドの中で行なうようなオプションもある。

DHHは、まず「コントローラの中にビューに関わるロジックがあると、"one controller, many in, many out" というRailsの考え方に合わない」と言っていた。これは、まあ当然の指摘だと思う(artonさんにも「ちょっとあれはね」と言われた)。

そして、Helperメソッドが使えることを説明したが、それよりは、別ファイルにビューを置くような方法の方がいいのではないかと言っていた。

(app/views/action/index.a2html)
<span id='name' />

(コントローラ)
@person = Person.find(....)

(app/views/action/index.a2logic)
{
   :name = @person.name + "さん"
}

つまり、index.a2htmlとペアになるindex.a2logicというファイルを新設して、ここに動的なデータを設定するロジックを書く。そのロジックは、(XmlBuilderがRubyコードをビューに書くのと同じような意味で)Rubyのコードになる。

こういうふうにできれば、Railsの思想と(今後の方向性に？)うまくはまるよ、というようなお話。

GIGAZINEで紹介されていた「Shopify」で使われている、Liquidというテンプレートシステムを参考が参考になるかも、というアドバイスもいただいた。これについては、これから調査予定。

Smartyの「モディファイア」のようなことができないか？

もうひとつは、XOOPSで使われている Smarty というテンプレートエンジンが持っている「モディファイア」という機能に相当するものは無いのか？という質問。

これについては、私がその機能を知らなかったので、ポイントをつかめなかった。Helperメソッド等で代用できるように思ったのだが、よくわからずじまい。

「Helperメソッドに書くなら、(上記のアクションごとの)ビューロジック内でメソッド定義できるようにした方がいい」というようなことも言っていた(ような気がする)。

もし、Smartyの「モディファイア」を便利に使ってる人がいたら、情報下さい。

Write Less Software!!

素晴しい仕事にふさわしい勲章ですね。

ちょっとうらやましいけど、私が同じサインをもらっても、角谷さんの感じている嬉しさは得られないと思う。仕事の報酬とはそういうもので、本当の価値はやったことの中にある。

角谷さん、スタッフの皆さん、おめでとう、ありがとう、そして、お疲れさまでした。

しかも、この言葉は、彼のボスの Less is More とうまくペアになる所がまたいいですね。

今回の発表で、技術的な意味での一番の収穫はくまくまーの人の発表。これは、with_scope という「知る人ぞ知る」みたいなAPIを題材にして、DRY原則によってどんどんコードを減らしていく話。私の今書いてる例にもピッタリあてはまるテクニックだった。

この業界は長いんで、「コードの行数が減ります」という話は聞きあきてるんだけど、これまでたくさん聞いた「コードの行数を減らす」話は、必ず減らした分の何倍もの対価を後で要求される。エネルギー保存の法則みたいなもので、コーディングが簡単になれば設計が難しくなるし、開発が早くなれば保守が困難になる。全部まとめて良くなる話もあるけど、そういうのは必ず「普通のプログラマ」にはついていけない話。

しかしこれは本物だ。本当に対価無しで "Write Less Software!!" を実践する話だった。

対価が発生するのは、実世界とモデルとコードの距離を縮めないでコード量を減らそうとするからで、実世界に接近したモデルを書いて、それをそのまま動かせば、対価無しで、わかりやすく短かいコードが書ける。RubyとRailsは普通のプログラマの手の届く所でそれを可能にする。いつもこの例のようにはいかないかもしれないが、どこを目指すべきかを、このプレゼンは明確に見せてくれた。

角谷さんは、(少なくともMacBookの寿命が尽きるまでは)毎朝仕事道具を手にするたびに、この呪文を読んでこの発表を想起できるわけで、それ一つとってもこれは凄い財産かもしれないですね。