LLDN (4) - フレームワーク対決

LL rails

Sledge, Ruby on rails, Kahuaの、3つのweb application frameworkが激闘を繰り広げた。

Sledge - (Simple|Smart) Libraries for Edge

2001年9月から旧オン・ザ・エッヂ（現ライブドア）社内にて、様々な受注案件で繰り返し書かれる似たようなコードをまとめる形でbottom upに開発された。2003年2月13日に公開。GPL/Artisticデュアルライセンス。

特徴としては次のような感じ。 比較的古くに開発されたので、特にアーキテクチャとして真新しい特徴があるわけではない。平凡なことを高い信頼性でできること、その実績が売り物だろう。

  • MVC。

    • Controllerの雛形が自動生成される。これを継承して必要なロジックを盛り込む。
    • Modelについて特に規定することは無いので、その辺はよしなに、自前で開発せよ
    • ViewにはHTML::TemplateやTempalte-Toolkitを使用 - 知名度が高いモジュールなので現場で使いやすい。

  • FileやRDBMSにセッション情報を永続化して管理

  • 認証処理
  • 文字コード処理 - この辺がしっかりしてるのは流石は日本発。
  • 処理の各段階に対するフックによって機能拡張が可能。横断的関心の実装に威力を発揮
  • CPANモジュールを積極的に利用することによる高い信頼性（目玉の数さえ十分なら……）
  • 商用サイトでの実績多数
  • ドキュメントが少ない。というか、「誰か書いて」とのこと。

Sledgeを使うには

  • 必要なCPANモジュール（かなり沢山あるらしい）をひたすらインストール
  • コマンドラインから sledge setup を呼んで、アプリケーションの雛形を生成
  • session用のDBを設定
  • その他、設定ファイルを編集
  • 雛形の中のControllerにあたるクラスを継承して、自前のControllerを作成
  • Controllerを使用するには、controllerオブジェクトに処理を委譲するスクリプト（1行）を書いて、CGIやmod_perlで動かす。

発表の中の、「JavaでできてPerlでできないことはないだろう」ということで作った、というのは印象的。

Ruby on Rails

発表者が高橋氏であるから、当然、高橋メソッドによる発表だった。今日のRubyistたちはひたすら高橋メソッドだった。

Agile Web Development With Rails も出るし。Rubyだし。正に本命。

特徴としては

  • MVC
  • DRY (Don't Repeat Yourself) - 重複は悪。同じ事は二度書かない。
  • 雛形の自動生成により効率的な開発
  • 外部で細かく設定するよりは、適切な規約に従って開発することで無設定にする。
  • 書くべきコード自体が非常に自己記述的。ドメイン特化言語の風味、ということなのだそうだ。

  • O/Rマッピング（Active Recordパターン）からMVCから、単体・機能テストに至るまでトータルにサポートする。これによる一体感がある

    • DAOやDTOよりはActive Recordを選ぶことで、シンプルに。
    • 反面、密結合である
    • トータルサポートで密結合だから、無設定化が可能？

  • Ajaxに熱心。

密結合は悪というのが世間の常識であるけれども、Railsは敢えて逆行している。曰く、「密結合化の欠点は柔軟性の低下であるが、LLの柔軟さがあればそれはカバーできるのではないか」「近年になって特に疎結合化が叫ばれるのは、JavaがLLに比べて柔軟性に欠けることが原因ではないか」「言語の硬柔とアーキテクチャの疎密とのバランスが肝心ではないか」とのこと。

確かに、Javaのチープなリフレクションとは世界が違うRubyのダイナミックさがをもってすれば、かなりのことができるだろう。メタプログラミングはできるし、なんと言ってもRubyである以上、最終兵器として特異クラスがある。どんなオブジェクトでも自在に変身させられる。

そして、欠点がカバーできるならば、密結合やActive Recordの利点としてシンプルさがある。DTOとかDelegateとか色々挟まっていないのは見通しを良くする。

kahua

  • 継続ベース
  • S式によるコンテント記述

Schemeの継続(Continuation)によってアプリケーションの状態を渡していくので、ユーザーは明示的に状態を管理する必要がない。

通常Web Applicationでは1つのユースケースを実行するために画面遷移を経ることになる。そのため、単純に各画面に対応する処理を書けばロジックが分散してしまうし、ロジックを一カ所に集中しておくには、statelessなHTTPからなんとか状態を引っ張り出してきて、復元してからロジックの残りを実行する必要がある。いずれにしても、言語レベルで言えば、1つのユースケースが複数のオブジェクトや複数のメソッドに分断されることは避けがたい。

kahuaでは、これを継続によって解決する。複数の画面が必要ならそれはそれでいい。そんなことは考えずに単にロジックを書けばいいだけだ。そのロジックに対応する関数を評価する過程で、勝手に画面出力に移り、ユーザーの操作を受け、状態を復元し、何事もなかったかのように元の関数の評価の続きに移る。

しかも、実行過程に生じるそれぞれの継続についてURLが対応しているから、前の画面のURLに戻れば、前の画面の状態からforkして別個に処理を続行可能なのだ。

あぁ。うまく言えない。継続を使いこなしている人なら当たり前の事なのかも知れないけれど。デモを実行したときの会場のどよめきは大きかった。

コンテンツまで全てがS式というのも便利だ。でも、その代償としてデザイナとの連携はやりづらそうだ。デザイン段階ではXMLを経由してXSLTを組み合わせたりして、逆変換の機構も用意すればカバーできるだろうか。あるいは、先にも書いたけれど、いっそCurlとの組み合わせというのはありかもしれない。

続

LLDN(5) に続く