あなたがRoRを使わない10の理由に違和感を感じる幾多の理由

php ethna ror

別に個人的にGREEでEthnaを使ってたから、とか藤本さんと個人的に知り合いだからだとかそういう理由じゃなくても、ここでEthnaが引合いに出されるのはやっぱり違和感がある。だからあえて書く。勘違い君を増やしたくないので、ネタにマジレス。

EthnaってあのクソなStrutsの劣化コピーwwwwww -- Ethnaは確かに洗練されたフレームワークではない。それは誰しもそう思うだろう。実際に一緒に仕事をしていた同僚はみなRoRを引合いに出しては「なんでEthnaには○○がないの?」と言っていたように思う。でも、フレームワークって洗練されているか否かという観点で語るもんじゃない。現実世界の問題 (つまり案件一つ一つ) を、どうやって大勢でよってたかって解決するか、という解法に対するアプローチに過ぎないからだ。そして、いかなるアプローチでも現場の大多数が違和感を感じるならそれを選択するべきではないし、多数が受け入れられるものであれば、洗練されていようとなかろうと、それが正しい選択になり得る。

Strutsがいくらクソでも、しかし多くのWebアプリケーションプログラマはそこから出発しているという現実がある。同様のことはPHPにもいえる。PHPはクソだ。あえて言う。たとえPHPのコミッタとしてもだ。でもPHPは廃れない。それはなぜか。それはRubyとは違う歴史を辿っているからだし、そこにRubyにはないWebアプリケーションに特化した言語であるという経験値があり、そこに多くの開発者が安心感を見出しているからだ。

フレームワークというのは、いわば開発者の間の共通言語である。アプリケーションとしてのコード量が増えれば増えるほど、開発者間のコミュニケーションコストが増大する。コスト対効果という側面で語れば、ドキュメンテーションでその溝を埋めようとすれば埋めようとするほど損をすることになる。それは、コードというものが字面以上にアプリケーションのセマンティクスの表現として示唆に富むものだし、それはプログラマにとってコーディングという作業にもっとも労力が費やされているという点で自明である。ゆえに、いかにそのコストを低減するかという観点が重要になり、フレームワークの出番となるわけだ。

例えば、そこがまさにアジャイルな開発手法の出発点であるように思う。TDDが、アプリケーションの品質を確保するための必要条件であるとしても、そこで勘違いしてはならないのは、逆説的にもテストそれ自体が品質の向上に寄与しているわけではないということだ。ねらいとしては、むしろ、テストを書くという作業を通じて、開発者間でコードによる非自然言語的なコミュニケーションを促進することにある。

話を戻して、そういった意味でJSFのようなフレームワークがあってもStrutsが未だに現場で使われている理由なのだ。言語でいえば、C#がいくら生産性に優れていても、Javaを使い続けなければいけない理由なのである。

EthnaはStrutsのような第1世代Webアプリケーションフレームワークをなぞったものだ。しかしそれは単純にそういう選択が生産性という観点で最適だったということであって、決して一般的にソフトウェアとして最適な道を選択したわけではない。

職場でEthnaを使っていることがRoRを使わない理由にならない、これはその通りだが、Ethnaに慣れているからRoRよりもEthnaを選択するというのは理に適った選択だと思う。ActiveRecord のほうが「かっこいい」と思うのは勝手だけど、少なくとも Hibernate だって JDO だって HQL や JDOQL のように SQL の再発明をしているさまを見ると、「かっこよさ」って何なんだろうと小一時間は考えることができる。そんなもんなのだ。

次の話題に移ろう。「RoRは最も簡単にセットアップできて最もたくさんのインストール数を持っているWeb Framework環境だ」だって？簡単にセットアップできるという意味では例えば Django も RoR も変わらない。少なくともRoRでなければならない理由などない。たくさんのインストール事例がある、これはその通りかもしれないが、それはあまりにも開発と運用のギャップを度外視しているように思う。

Rubyが大規模Webアプリケーション環境でどれだけデプロイされてきたか、という点に絞って言うと、明らかにPHPの方が実績という面で勝っている。YouTubeがいかに巨大になろうと、PHPで動いているという事実は変わらないだろう (詳細については以下を参照)。GREEでもそうだった。PHPがその性質から開発コストの増大に繋がっていることは間違いなかったけれども、PHPを使い続けているのは、それがあまりに現実的だからだ。勝手が分かっているからだ。

もう、あとは Scaffold だのなんだのと論じはじめると、各論に達するし、それで「10の理由」の10項目を埋めているだけのように思うので、ここからは語らない。Ethna だってアプリケーションテンプレートを整備すれば CRUDの「足場」が実現できるし、「○○がある、ない」という議論は、そこはフレームワークの良し悪しではなく、単純にリソースの投入具合の違いによるものだという点に落ち着くからだ。

大事なのは、それが現場の空気に合っているか合っていないか、だと思う。あなた一人で仕事をしているわけではないのだから。

追記: YouTube は Python で書かれていると Guido がいったらしいけど、あくまで *almost* entirelyで、フロントエンドはまだ PHP を使っているはず (結構 Python に切替えてるように見えるけど)。Digg のここの記事のコメントにもあるように

by HeyItsJeremy on 12/13/06
The article is a bit misleading, the YouTube frontend which accounts for about 90% of the use of the site (more people watch videos than upload them) is written in PHP. The backend is written in Python. The backend handles uploads and command line access into FFMPEG for screen caps and video conversions.

You can even see here: http://youtube.com/my_videos.php clearly, that's PHP.

の通り。

昔はファイルアップロードフォームに hidden 要素で "MAX_FILE_SIZE" とかがあって微笑ましかっです (いまはさすがになくなったみたい)。