0015 号 巻頭言

初稿：2006-07-13

本当は面白い Ruby on Rails

Rubyist Magazine 第 15 号をお届けする。

今号は、ASR や rjb、あるいは『邪道編』で知られる arton さんを迎えての「Rubyist Hotlinks 【第 15 回】 arton さん」、 BBS に新着順表示機能と分割表示機能を加える「Ruby ビギナーのための CGI 入門 【第 4 回】 同じようなことを繰り返して実行する」、 賞味期限へのチャレンジにいそしむ青木さんが Ruby 版 Tropy の添削にもチャレンジする「あなたの Ruby コードを添削します 【第 4 回】 Tropy」、 似ているようでいろいろ違う URI と Pathname ライブラリを紹介する「標準添付ライブラリ紹介 【第 8 回】 uri, pathname」、 Yu_kata さんが Rails アプリのはまりどころを実体験を元に説明する「RubyOnRails を使ってみる 【第 8 回】 Rails はまり道」、 どの辺が Rubyist のためなのかはさておき Forth を紹介する「Rubyist のための他言語探訪 【第 8 回】 Forth」、 RubyKaigi おつかれさまのささださんが YARV の命令列とそのシリアライズについて説明する「YARV Maniacs 【第 8 回】 命令列のシリアライズ」、 さらに「0015 号 読者プレゼント」、「Ruby 関連 News」と「Ruby 関連イベント」など、 いつものように盛りだくさんの内容である。 —-

先日、日本 Ruby カンファレンス 2006 が無事開催された。 諸方面の方々にはご迷惑をおかけしたが、 参加された方々からはおおむね好意的な感想をいただくことができた。 ご協力いただいた方々には心よりの感謝を捧げたい。 本当にありがとうございました。

これを受けて、日経 BP では、 IT Pro のサイトに RubyKaigi2006 の記事を 2 つ (David のインタビューもあわせれば 3 つ) と、 それとは別に Ruby の記事を書いていただいている。 いくつかには私の言葉も引用していただき、 たいへん恐縮ではある。

ところで、どちらの記事も Ruby をビジネスに利用することについて、 非常にポジティブに書かれている。 私自身はもう少しネガティブな懸念も持ってはいるが、 だからといってポジティブな面が相殺されるほどではないだろう。 何より、捺印ナビリティを高める上では、「日経」という名前も合わせて非常に効果的な記事であることは間違いない。

ただ、このような扱われ方をすると、Ruby が、 とりわけ Ruby on Rails によって、 ビジネス側に引っ張られてしまうのではないか、 と心配される方もいるかもしれない。 もちろん、そのような懸念もないわけではない。 しかし、Rails に限って言えば、それは杞憂に過ぎないだろう。

このカンファレンスでは、基調講演として、 まつもとさんと一緒に、DHH こと David Heinemeier Hansson 氏に来日していただき、 講演していただいた。 彼は行く先々でサインを求められていたようだが、 そこで書いていた言葉は「Write Less Code」だった。 現在では世界でもっとも有名になった Ruby のアプリケーションである 「Ruby on Rails」のコードを書いているその人のメッセージが「Write Less Code」なのは、ある意味で皮肉なことなのかもしれない。

Write Less Code とは何か。あまり深い含意はなく、字句通りの意味にも見える。 Rails 最初のリリース、 0.5.0 の公開時のメールには以下の文章があった。

Everything needed to build real-world applications in less lines of code than other frameworks spend setting up their XML configuraion files. Like Basecamp, which was launched after 4 KLOCs and two months of developement by a single programmer.

単に LOC、ソースコードの行数が less だ、と言っているだけである。 そのままである。

もっとも、このように考えることもできる。 Rails の特徴として知られている「DRY」や「Convention over Configuration」は、 「Write Less Code」から演繹することができる。 同じことを書くとそれだけ長いコードになるし、 規約を決め、それに従うことにしてしまえば、 個別に設定を書くよりも記述量は減るだろう。 つまり、 DRY や Convention over Configuration 自体は Rails にとって目的なのではなく、 「Write Less Code」を実現するための手段なのかもしれない。

Rails にはこのように、妙にロジカルというか、 原理原則から単刀直入に演繹したロジックでどこまで行けるか、 という面があるように感じられる。

おそらく Rails は、 おそらく一般に思われているよりも野心的、 実験的なプロジェクトなのではないか。 たとえば、 DB のテーブルのカラムにアクセスするための情報をコードや設定で記述せず、 代わりに DB 自体から都度テーブルのメタ情報を取得して利用する、 という発想は、少し考えただけでもパフォーマンスの点からありえないと思うだろう。 しかし、Rails はそういう意見に対し、 「じゃあキャッシュすればいい」「けれども開発時は読み込みなおすのが面倒なので、 運用モードのみキャッシュして、開発時は本当に都度読むようにすればよい」という解決策の方に進むのである。

David が基調講演で話した、 CRUD と HTTP の関係についても同様である。 HTTP には DB の CRUD に対応する 4 つのメソッド (POST/GET/PUT/DELETE) がある。 だから、DB のように、HTTP の 4 つのメソッドと Ruby のメソッドを規約で対応づければコードは減るし、 考えることは減るし、URL もシンプルで済むしめでたしめでたし、 などという主張は、通常のブラウザでは GET と POST しか送ることができない、 という現実を見ていない空理空論のようにも見える。 しかし David はそのような意見に対し、じゃあ JavaScript を使うとか、 それでも駄目ならクエリパラメタでメソッドの情報を送れればいい、 という回避策を持ち出す。

Rails がほんとうに面白いのは、このようなある種の愚直さと、 その愚直さを支えるための、これまたある手の愚直さが感じられる実現手段である。 そこにこそ David 自身が持つ特徴が埋め込まれているような気がしてならない。

このような考え方は、 Ruby on Rails がビジネスで役に立つかどうか、 ということとはまったく別のことである。 いや、むしろ、役に立たないような形に進化しやすくなることが容易に起こりうるのではないかと心配しないでもない。 けれど、 Rails の現在の形はまさにこの発想に従ったものであり、 そのために今の Rails があることもまた事実である。 それで成功するかはまったくべつである。 正直なところ、どこかで行き詰まりそうな気もしないではない。 しかし、たとえ Rails が失敗したところで、 その挑戦自体が不可能であることが示されることは当分ないだろうし、 また不可能であることを明示する、 すなわち不可能性を証明することも興味深い試みになる。 野心的、実験的なプロジェクトとしては それで問題ないだろう。

Ruby on Rails がビジネスとしての成功を目指しているのは間違いない。 そのマーケティングセンスをほめ称える人は少なくない。 しかし、Rails が目指しているのはそれだけではない。

まつもとさんがよく使われる言葉のうち、 私がもっとも好きな言葉は「多様性は善」である。 ついでに歴史的薀蓄も書いておくと、まつもとさんが Ruby 界隈ではじめて多様性について語ったのは 1996 年 10 月 31 日に書いたメール (ruby-list:967) の中での「プラットフォームの多様性があることは良いことです (と思う)。」という言葉であり、「多様性は善」というフレーズが出てくるのは、 1999 年 9 月の (ruby-list:16610)、 なひさんによる「Ruby Workshop」のレポートが初出のようである。 この思想から行くと、 Ruby がビジネスの現場に投入され、切磋琢磨されることも、 また Ruby がプログラミングおたくのための実験場として怪しげな DSL やメタプログラミングを駆使したアプリケーション記述言語として極めていくことも、 Ruby の持つ多様性を極める上でどちらも欠かせない。

もちろんビジネスのツールとしてのみ Rails に触れるのでも構わないが、 本誌を読まれる程度に Ruby やそれ以外のことにも興味のある方には、 Ruby on Rails が持つ面白さにも触れてみてほしいと思う。