JumpShip(source)はオープンソースのFlexおよびActionScript用リッチインターネットアプリケーション（RIA）(source)フレームワークで一番の新参だ。そのversion 3.1が2008年5月21日にリリースされた。RIA開発フレームワークを追っていくというInfoQの取り組みの一環で、JumpShipフレームワークの製作者でウェブデザイン会社JSJ Studiosを持つJamie Scanlon氏に話を聞いた。彼は開発者がよく出くわすユーザビリティの問題のためにJumpShipを開発することを考えついたといい、以下のような思い出を語った。
JumpShipの前身となったフレームワークは私一人だけで始められました。そう思いたったのは、ある大規模プロジェクトを終えて最終製品を評価する時間が得られた時でした。このプロジェクトはMVC（サービス指向アーキテクチャのRIAを素早く作るのに役立ちます）を使って構築されたのですが、それは有効であったもののコードが私にとっては複雑になりすぎました。数百行のコードがあるようなコントローラやビューがいくつもありました。デバッグの時には、問題となるコードを見つけるのに修正と同じくらいの時間がかかったりしました。同じようなサイズの別プロジェクトも始まろうとしていたので、何かもっと良い方法が必要でした。
私がRuby on Railsを知ったのはその時でした。私がフレームワークに求めるもの、特に簡潔であるということを含め全てが揃っていました。制約のある方法をベースにしていましたが、高尚なGoFデザインパターンの優雅さより実際の物事を進めることにフォーカスしていました。このようなフレームワークが ActionScriptにもほしかったので、自分で作るのに着手したのです。
Scanlon氏はこう説明する。
JumpShip が目指すのはMVCのベストプラクティスを考慮しながらも物事を進めることにフォーカスした方法を実現することです。実用性のためならJumpShipが人柱的なものになっても構いません。明確なベストプラクティスがない場合に物事を進めるベストな方法についての意見を取り入れるのはフレームワークにとって悪いことではありません。またJumpShipはRuby on Railsの「設定より規約」フィロソフィに忠実であろうとしています。規約に従うことはベストプラクティスについて気にしたりコーディングするのにかける時間を減らせるということなのです。
ARPやCairngormやPureMVCといった他のAS3フレームワークとJumpShipとの違いについてScanlon氏はこう述べる。
JumpShip に関して一番ユニークなのは、内蔵した標準データモデルによって自動的に検索、ソート、データ走査、データ列挙ができるようになっていることです。この JumpShipのデータモデルは、プロトタイプを作ったコミュニティでの成果を基にしていて、フレームワークのどこでも使うことが可能な非常に強力なデータ構造を備えています。
JumpShipと他のMVCフレームワークで異なる別の点は、他のクラスへの参照を作るのにシングルトンパターンを使った簡易な方法に頼らないように意識していることです。
彼はこう思い起こす。
最近文章にしたある経験があります。ビデオプレイヤをCairngormで作ったのですが、一度に複数のプレイヤが必要な別のアプリケーションにそれを複数載せようとした時にある問題に直面しました。Singleton ModelLocatorクラスとCairngorm EventDispatcherクラスを使っていたせいで、一つのプレイヤの再生ボタクリックすると全てのプレイヤが再生スタートのイベントを受け取ってしまったのです。
私はシングルトンパターンがほとんどのフレームワークで考えなしに使われすぎてきたと確信しています。シングルトンは各クラスへの参照を格納する必要をなくしてくれます。これは大変便利ではあるのですが、ウィジット化されコンポーネント化された環境で製作しようとしている時には問題となって帰ってくるのです。
JumpShipと他のフレームワークで異なる機能にRails Gatewayがある。これはRailsが備えるRESTfulなウェブサービスの利点を活用するライブラリで、Railsで作られたバックエンドに基本的なCreate-Read-Update-Delete（CRUD）操作を行わせることができる。JumpShipとRuby on Railsの連携についてScanlon氏はこう説明する。
Ruby on Railsはどれだけフレームワークを簡素にしてどれだけフレームワークによって開発が簡単にするかという点で私のモデルとなりました。私のRuby on Railsの経験から、フレームワークが定義する標準のデータモデルがあることは大変有益なことだと常に思っていました。Railsには ActiveRecordクラスがあり、これがデータベースのテーブルを抽象化して基本的なCRUDを行ったり検索やソートやデータ走査を行います。もしデータベースのテーブルを抽象化したデータについて考えるなら、こういった類の基本的な操作ができることを想定するでしょう。私は自分のアプリケーション内のデータは単にテーブルから取ってきた値であるという決まりを作りたいと考え、また自分のデータモデルはどのようにデータを検索、ソート、走査、変更できるか知っているようにしたいと考えました。
また、私はどこでも有効に使える唯一のデータモデルがあったらいいと考えました。といっても、各アプリケーションに対応するバリューオブジェクトを定義する気はありませんでしたし、たとえ定義しても二度と使われることがないことを知っていました。唯一のデータモデルという考えは、現在のプロジェクトだけでなくどんなプロジェクトでも使えるということで、これはActionScriptの世界ではまだ新しい考え方です。このデータモデルはサーバから送られてきたものを何でもパースして格納するためのものではありません。データがXMLやJSONで送られるのであれ直接オブジェクトが送られのであれ、受信したデータそのままにデータモデルを構築してしまうという罠にかかることはよくあることです。受信するデータはバックエンドのビジネスロジックで扱いやすい構造であることが多いですが、フロントエンドの開発者がそれと同じ構造を保たないといけない義務はありません。開発者はデータを自分たちに便利なようにデータを作ることができますし、そうすべきであって、逆のことをすべきではありません。
Scanlon氏は次のようなことも思い出しながらRails Gatwayについて説明をした。
JumpShip を開発中にRailsで作ったバックエンドに取り組んでいた時、RailsとActionScriptがお互いに対話できるようにする方法が分かるリソースはほとんどありませんでした。少しばかりの間フラストレーションを抱えた後、私は自分で実装してみようと決めました。しかし結局それは大変なものでもなく、そしてその方法を公開しようと思いました。Railsの開発者たちにRailsアプリケーションとFlashフロントエンドとをどのように連携させるか知ってもらい、Flash/Flexの開発者たちにFlash RemotingやAMFばかりでなくもっと大きなウェブサービスの世界に目を向けてもらいたいと思ったのです。
その後分かったのは、この道をたどったのは私だけではないということでした。数ヵ月後、AdobeがFlexとRailsを一緒に使う方法の記事を公開しました。それでも私はJumpShipのRailsゲートウェイを改良を止めなかったのは、Flexに縛られずRailsとActionScriptを連携させる方法を作るのはやる価値があると思っていたためと、JumpShipのデータモデルを使った方法の利点を生かせるからでした。
そして決められたデータモデルがあることのもう別の利点にも気付きました。それはRESTfulなサービスとXMLを通じて通信を行えること、そして全てのデータをJumpShipの標準データモデルに変換できることです。例えば”users”と名付けたデータモデルを作り、それをJumpShip Rails Gatewayに渡してサーバへクエリを投げます。このゲートウェイはusersテーブルへクエリを行い、その結果のXMLをJumpShipのデータモデルに変換します。これはとてもクールなことです！JumpShipのデータモデルをゲートウェイに渡して格納させることも可能です。ゲートウェイはデータモデルをXMLに変換して、Railsにデータベースへそれを格納するように伝えることができるのです。
Rails へのゲートウェイは一定のActionScript開発者たちにとって便利なものですが、Rails開発者たちからも多くのポジティブなフィードバックがあったことは驚きでした。Flashをフロントエンドとして使っているような人たちにとっても役立つものだったのです。
InfoQがScsnlon氏にJumpShipフレームワークで改善したいと思っていることのトップ3を挙げてくれるよう頼むと、彼はこう答えた。
優先する事項として、ドキュメントをアップしたいですね。これはちょうど今取り組んでいることです。良いドキュメントは人々にこのフレームワークのパワーを理解してもらうのに非常に重要なものですから。ただ、これにはとても時間がかかりますし、私自身こういうことをする習慣がないんです。
また、このフレームワークに関係するコミュニティも良くしたいですね。コミュニティが広がり、より多くの人が考えや経験を提供してくれることで、このフレームワークが成長しより良いものになることを望んでいます。
そして、JumpShipをFlexフレームワーク内でも使えるようにしたいです。JumpShipはFlashのフレームワークとして始まり、Flash を使う開発者たちにとって便利なものであり続けてほしいと思っていますが、増加しているFlexの開発者たちにもアピールできるものにしたいと思っています。このフレームワークは両方の環境にとって有効なものですが、普通のFlex開発者だとJumpShipのコンセプトの一部を異質なものに感じるかもしれません。私の目標はFlex開発者にとっての敷居を下げて、CairngormのようなFlexに特化したフレームワークと同じくらい簡単に JumpShipを使ってもらえるようにすることです。
Scanlon 氏は、JumpShipはシングルトンパターンに依存しておらずコンフリクトを起こすこともほとんどないため、ウィジットやコンポーネントのように移植性と再利用性のあるコードを作るのにも適していると指摘する。まとめていえば、デザインパターンの理論やMVCのベストな実装方法をあまり気にすることなく物事を素早く行えるようにするフレームワークを探している開発者たちへ贈るフレームワーク、というのがScanlon氏のJumpShip像だ。
原文はこちらです：http://www.infoq.com/news/2008/06/jumpship-31-released