Rails のデメリット
この2週間は Ruby on Rails の初仕事に没頭する日々だった。ある EC サイトを作っているのだが、とにかくはじめてのことだらけでなかなか先に進まない。Rails は理解してしまえば、あっという間に仕事をこなせることが多いが、その理解するまでが大変。いままで Rails は Ruby 界隈のハッカーたちに熱狂的な支持を受けてきたが、ハッカーではなく私のような普通の開発者に受け入れられるようになるまでにはいくつかの障害があるだろう。
1. はとにかく高い。Rails は scaffold で雛形を作るまでは簡単だが、その先、何をどうしたらいいか飲み込むのに時間がかかる。それは Rails の Convention over Configuration （設定より規約）という一つの柱がマイナスに働いている面だろう。たとえば、コントローラで URL を作る url_for というメソッドがあるが、これはデフォルトを最大に生かす Rails らしいメソッドである。しかし、これがなんともわかりずらい。URL のルートマッピングを複雑にしたとき、正しく期待したとおりに URL を生成できるか自信がもてない。
コントローラやビューでどんなメソッドが使えるのか、使えないのか、結局 Rails のソースコードを読まないとわからない。特にビューはどんなコンテキストで実行されているのかもわからない。最近になってようやくわかってきたのだが、コントローラはテンプレートをレンダリングする直前に、自分のインスタンス変数をコピーしてテンプレート(*.rhtml)に渡すらしい。うーん。Ruby はあまりにも柔軟すぎ、あまりにも多くのマジックを実行可能なため、本当にわけがわからない。
Rails の作者の DHH 氏をはじめ、Ruby 界隈は実に頭のよい人たちが多い。物事を成し遂げるには、頭を使うか体を使うかのどっちかである。Rails の場合、体を使うのをケチって頭を使おうということなのだが、私のような普通の人間には、頭を使いすぎてオーバーヒートしてしまう。
ホスティングは深刻な問題である。Rails を安定運用させている実績がまだあまりないのである。WEBRick というピュア Ruby なウェブサーバは、簡単な社内サービス程度にはいいかもしれないが、おそらく B2C の EC サイトには使えない。となると、やれ apache + FastCGI だ Lighttpd だ Mongrel だという話になる。ここの部分がきちんとしないと商用としてはお客さんが不安で使えないだろう。
PHP が懐かしい。ある意味でやはり PHP 4 は最強かもしれない。PHP 4.4 系であれば安定しているだろうし。とりあえずやりたい仕事をさくさくこなすには PHP はいい。本格的なオブジェクト指向とするにはやや厳しいけれども、PHP 4 でもクラスを使ってある程度モジュール化を図ることはできる。命名規則とかディレクトリのファイル配置の規則とかきちっと決めれば、ある程度大きい規模の開発でも対応できるんじゃないか。(実際、楽天はあれだけ大きいシステムを PHP で作ってきたんだし）
・・・と Rails を批判的に見てきたが、これは本当にきちんと理解すると本当に早く書けるのは事実。ただ、正真正銘のハッカーを除いて、本当にきちんと理解することができる人がどれほどいるかは疑問。それが Rails の一番厳しいところかな。
