Cellsは"Ruby on Railsウェブアプリケーションプラットフォームにコンポーネント指向開発の恩恵をもたらし"、依存性がなく再利用可能な、言い換えると、自己完結型でアプリケーション上で他のセルと組み合わせて再利用できるようなコンポーネントをつくることができるようにする。
Cells上に構築されたApotomoはCellsを強化し、完全にステートフルなコンポーネント、つまり、よく知られたGUIウィジェットを同レベルの抽象を持ち込んだ。すなわち、"ApotomoはRailsをいつどのように更新されるかを知っているイベントドリブンなウィジェットで拡張した"のだ。その結果、Apotomoを利用する開発者は、JavaScriptを記述したり、基本的なAJAX呼び出しについて気にかけることなくYUIのような既存のUIライブラリを利用することができる。Apotomoウィジェットはイベントとつなぎ合わせることができるので、ウィジェットをお互いに依存させることなく、また再利用しやすくすることができる。
InfoQは一年以上前にすでにCellsを取り上げたが、その後、Cells 1.0はリリースされ、Apotomoの開発は続けられてきた。
InfoQはCellsのメイン開発者であるNick Sutterer氏と話をした。最後にインタビューをしてからの1年でCellsにはどんな変化がありましたか？
山ほどですよ！ CellsがRailsが1.2.3からバージョン2.3になる間に成長するにつれて、私はRubyを学びました！ 私が言語をより理解したことと盗むべき様々なフォークのおかげで、より簡潔で構造の整ったCellsのコードができました。
可読性の高いコード以外に、Railsビューに見られるフラグメントキャッシュに似たシンプルなキャッシュを導入しました。それにより、Cellインスタンスのオブジェクト指向の特徴を失うことなく、アタッチされたバージョニングメソッドがCellsビューを失効させるまでビューをキャッシュできるようになります。Micha? ?omnicki氏には大変助けられました。複数のパッチと彼のプロジェクトにおけるテストケースをもたらしてくれたのです。
ユーザの視点では、Cellsはずっと高速になりました。私は最近くだらないメモ化パターンによってビューの検索スピードを99％向上させました。 その裏では、もっと多くのことが進行中です。日中とある不快でうるさいオフィスでとあるプロジェクトに従事したあと、私はCellsを基礎としてRailsにステートフルコンポーネントをもたらすApotomoの作業を続けました。その夜の時間に行うコーディングは私のうんざりするようなプロジェクトからの魂の救済のようなものでした。
あなたは、前回Railsコミュニティに注目に値するほどの興味がある、と言いました。今日の状況はどうでしょうか？
ここで統計について話してほしい、というわけじゃないですよね？ それはともかく、私がCellsを始めたとき、片手で数えられるほど少数のプログラマが私とRailsのコンポーネントの欠如の問題について話しました。今では、ウィジェットマニアの«シーン»があります。
Cellsのgithubウォッチャーを見てみるとそれがよくわかります。最近、Cellsの変更について即座に情報を得たいプログラマが150人程度になりました。それは素晴らしいことですし、このプロジェクトに興味を持ってくれているという事実をうれしく思います。私たちはだいたい6つのフォークをCellsのメインラインに戻すマージを成功させました。
突如としてネット上にCellsやPresenterを用いたpartialのような代替手法について議論するブログポストが出てくるようになりました。
«興味»についての別の指標が#cellsというIRCチャンネルです。私が参加するときはいつでも4人から8人の人が世界中からそこに待ち伏せしています。新しい人も参加し続けていて、サポートや手助けを求めています。私はこのチャンネルをプロジェクトにとっての最も重要なサポートメディアだと思っていて、そこで人々と会うのが楽しみなのです。
Cellsが生まれてから10社ほどの企業が私にコンタクトをとってきて、実際のプロジェクトにおけるCellsの利用について聞いてきましたし、実際に使っている人たちもいます。そうだ、IBMでさえ寄付してくれましたが、まだ猛烈に寄付を待っています。MITライセンスのおかげです。
このプロジェクトにとってのハイライトは仲間であるMike Pence氏と一緒に行ったフロリダ州オーランドで行われたRubyConf 2008での講演でした。サラソタに出かけて素晴らしい時間を過ごし、講演の準備をし、ビールを飲んで、そしてショータイムです！ 現実の人々が聴衆として座り、私たちの講演を聴いてくれました。講演のあとで真剣な議論をし、プールパーティでもKirk氏とコンポーネントについて話をするのを止められなかったのです。
USに行った後間もなく、私たちはRails 2.3に対応するCellsをリリースしました。Apotomoブログでの公式の発表はDHH自身によってTwitter上でつぶやかれて、一日500人まで読者が増えました。興味深い経験でしたし、David氏の影響力を見せつけられました。おぉ！
David氏は一度私たちにコンタクトしてきましたが、私たちはCellsをRailsにどのように統合するかについて解決策を思いつきませんでした。私たちは全員プラグインとしてそれを行うことがより好ましいと考えています。プラグインはいい方法です。
私はRails 3のコードを時々見続けています。私はYehuda氏のリファクタリングが大好きですし、新しい内部APIがCellsのようなものに新しい道を開いてくれることを本当に望んでいます。誰もがコンポーネントを必要としているのです。そして今はちょうど、Rails 3 APIが確実になるのを待つべきか、新しいコードに飛び込むかというときです。今は、私はチュートリアルや記事を書いたり、Apotomoを改善したりすることに集中し、コアな誰かがRails 3でのCellsの置き換えを思いつくかどうかを確かめようとしています。
本当にステートフルなコンポーネントを必要としているのでしょうか？
いいえ。もしあなたが「ともかく直線的な制御フロー」、つまり、完全なページをリクエストのたびにレンダリングするとか、MVCスタックのコントローラやビュー、もしかするとモデルレイヤーにまでAJAXのロジックを散在させたようなもの、をより好むのであれば、コンポーネントは必要ないでしょう。同様に、もしリクエストのたびに完全なプロセス環境を確立させるのを好むのであれば、ステートフルであることは不要でしょう。
Mike氏の言葉をを引用させてください。「もっといいおもちゃを持つべき時だ。できる子どもはもうそれを持ってるんだ。それにRailsのレベルをもっと高く引き上げたっていいんじゃないか？」 SmalltalkプログラマはSeasideを好み、GUI開発者はウェブを嫌います。両方の世界から最高のものを取り込んで、Railsの上に持ってきてもいいんじゃないでしょうか？
私が言いたいのは、Apotomoがアプリケーションの中でどれくらい欲しくなるかはプログラマにかかっている、ということです。そして、ステートフルウィジェットの真の力を経験したら、大きなコントローラに戻ることは決してないでしょう。
それはコンポーネントの再利用性だというだけでなく、より優れたカプセル化であり、アプリケーションの小さな部分に対する強固なテストシナリオであり、イベントドリブンアプローチであり、より少ないコードであり、よりよい開発のワークフローによってステートフルで生きたウィジェットが素晴らしいと納得させられる、そんなものなのです。
Cellsについてさらに知りたければ、RubyForgeのCellsウェブサイトを訪れてみよう。