Rubyに人気があるため、Ruby on RailsやMerb、CampingといったWebフレームワークが誕生した。Wavesという新しいWebフレームワークが最近リリースされたが、 Ruby開発者が興味を持って試してみようと思うような特徴が、Wavesにはある。
WavesはRuby on RailsのようにMVCフレームワークであり、Request Lambda(source)と呼ばれるものを使うが、各マッピングはルールとブロックで構成されている。ルールが要求と一致すると、そのブロックが実行される。 Wavesに独特な特徴の１つである。
Wavesのこの他の優れた特徴には以下が挙げられる。
- 真のコード再ローディング
- ホットパッチング
- クラスタのサポート
- スレッド・セーフティ
InfoQは、Wavesの開発者Dan YoderとWavesについて話す機会を得た。
Robert Bazinet（RB）：Wavesとは何ですか。
Dan Yoder（DY）：Wavesは次世代のWebアプリケーションフレームワークであり、MITライセンスです。Railsが止めたところから始めてお り、主にそれが理由で「次世代」となっています。スレッドセーフであることやフットプリントが小さいことなど、基本的な事柄もあります。JITR （Just In Time Resources）のような特徴により、DRYは次レベルに押し上げられるわけですが、JITRによってアプリケーション全域でMVCコードの再利用が 容易になるか、アプリケーション全体の再利用さえ可能になります（その理由は、アプリケーションが何よりもモジュールの中にカプセル化されているからで す）。Wavesはよりオープンでかつ拡張可能でもあります。 例えば、容易に自分だけのViewクラスを書いて、ビューの選択もしくはレンダリングの方法を変更したり、モデル向けに別のデータベースプラットフォーム を使用したりすることができます（デフォルトはRuby Sequelです）。「RubyにおけるWebアプリケーション用MVC」という意味で、基本的な考えはRailsと同じですが、数年におよぶRails の使用経験を基に、さらに優れて、強力なフレームワークを開発しようと作り上げたものです。
RB：開発した理由はなんでしょうか。
DY：一言で答えるなら、Campingです。
もう少し詳しく説明すると、私自身のアプリケーションで、Railsの厳然たる限界に達してしまったことが主な理由です。Wavesは実のところ、プラグ インの豊富なセットとしてスタートしました。けれども、本当にリリースしたいと思う段階までは達しませんでした。なぜなら、実のところ、Railsの上に 乗っかっただけの新規フレームワークを作っているとわかっていたからです。普通のプラグインというより、どちらかというと Streamlinedのようでした。また、Railsコードを回避するか、モンキーパッチを当てて、フレームワークの予想行動を本質的に変更していたこ とに気付きました。ですから、Railsの世界で必ずしも他者と調子よく動かなかったのです。ちょうどよい例が、Just In Time Resourcesの初期実装でした。ObjectとModuleではActiveDependencyがconst_missing に優先してコードの再ロードを処理します。この行動を変えたかったので、Railsがしていたことを無効にする必要がありました。私にはObjectや Moduleに触る必要のないソリューションがあったため、Railsのソリューションが好きではありませんでしたが、Railsのやり方という理由で、 身動きが取れなかったのです。
そんなある日、私はCampingを眺めていました。理由は思い出せないのですが、コードの簡潔性に驚いたことは覚えています。その時、ひらめいたので す。Railsに対処する必要なしに、私が望むだけの特徴を持った新しいフレームワークを作れば、事はより単純ではないかと。その時までにどうにか、こう にかRailsのアドオンとして作ってきたものをリリースしようと計画しており、そちらの方がずっと困難の少ない道でしたから、難しい決断ではありまし た。加えて、書き直しの必要なコードがたくさんありました。骨が折れました。けれども、出来上がったコードは、ずっとリーンで、拡張も作業もより簡単に なったと思います。そうしたら、DuckTyped.comのBenがRackを教えてくれて、私がコードに埋もれている間にRackがリリースされ、そしてそれが基本的にぴったり合ったのです。それと同時に、DataMapperとSequelの成熟が進んでいたため、課題のうちのMVC Webアプリケーション部分にのみ徹底的に焦点を当てた、フル機能のフレームワークの導入が可能になったのです。
RB：Wavesは誕生からどの位経っていますか。
DY： Wavesに取り掛かり始めたのは、つい2007年8月のことです。最初のベータリリースは2月初旬でした。ですから非常に新しいフレームワークで、旅は 始まったばかりです。私は保守的なので、私にとってベータ版は「本番使用のための準備が整っていない」を意味します。
RB：Waves を利用してアプリケーションを書くことについて、開発者が試してみて、さらに多くを体験できる最良の方法は何でしょうか。
DY：おそらく最も良い出発点はスクリーンキャストで、チュートリアルを説明していますが、このスクリーンキャストで興味を持ったら、チュートリアルを体 験できます。また、かなり完全に近いRDocsもあります。サポートフォーラムもあり、どんな質問にも、数時間か、遅くとも１日以内に返答するよう努めて います。チュートリアルを体験し、RDocsに入っているものを基に試してみて、フォーラムをチェックして、そして、にっちもさっちもいかなくなったら、 質問すればいいのです。
RB：WavesはRailsのように、MVCフレームワークですね。WavesはRailsとどのような相違があるのでしょうか。
DY：無数の点で異なります。これまでに言ったように、Wavesは「次世代」であり、Railsの進化版です。スレッドセーフであり、フットプリントも 小さいのです。JITRやモジュール内でカプセル化しているアプリケーションなど、アプリケーションの中、また複数のアプリケーションにまたがっての両方 で、再利用にさらに重点をおいています。ルート相当物はRequest Lambdasであり、より強力であり、道理にかなっている場合はMVC行の外に色をつけることができます。また、すべてのコントローラーをまたいで１ヵ 所に、アプリケーションを安全に保持することができます。望みのORMフレームワークにモデルを連結させることができますが、もし1つも使わないなら、メ モリ利用やメモリパフォーマンスにORMを使うことに対し、代償を払うことはありません。例えば、ファイルストレージを使い、そして本当にORMを必要と しない、WavesベースのCMS（コンテンツマネジメントシステム）があります。Wavesには、Railsよりさらにコントローラーから切り離されて いる、一流のビューがあります。例えばレイアウトは、コントローラーではなく、ビュー自体の中で指定できます。同様に、レイアウトを入れ子にするか、 ビューの中からコントローラーメソッドを呼び出せます。もう1つの実に重要な相違は、 Wavesでは本当の意味のコード再ロードができることです。すなわち、コードが再ロードされる前に、自動的にアンロードされ、そのため以前のロードから 残っているアーチファクトが存在しないのです。これがなぜ重要かというと、デバッグが多少容易にはなるだけでなく、LiveConsoleを使って比較的安全にホットパッチを本番コードに当てることもできるからです。両者の違いを示す良い例でしょう。Rubyの中でMVCパラダイムが本当に進化しているのです。
RB：どのようなタイプのサイトがWavesを実行しているのでしょうか。
DY ：様々な種類のサイトを動かしているCMSがあり、そうしたサイトにはもちろん、Ruby Wavesのサイト、RubyWaves.com も含まれます。また、Wavesを使ったテーマ構築アプリケーションもあります。こうしたものは元々Rails上で動作していたものですが、現在では Wavesになっています。必要メモリは従来の約３分の１から４分の１になり、コードベースもRailsと比較して小さくなっています。また、再起動不要 で、何週間も動作します。ですから、私は勢いづいています。他のデータポイントも手に入れたいと思っていますが、入手先は自分以外を望んでいます。うまく いけば、間もなく手に入るでしょう。
RB：Wavesはオープンソースですか。もしそうなら、開発者はどのように関与できますか。
DY：WavesはMITライセンスであり、これ以上のオープンはないでしょう。プラットフォームを前進させる手伝いをしてくれる中核的な貢献者の参加を 心から望んでいます。関与への第一歩は、サポートフォーラムで私に連絡し、どういった種類のことに取り組みたいか知らせてください。今のところ、空きが いっぱいあります。やるべきことは山ほどあり、Wavesだけでなく、少しでも意味のあるフレームワークを成功させるには、それに取り組む開発者のコミュ ニティが欠かせないと思います。Waves はRack、Sequel、Markabyの存在から非常に利益を得てきました。RackやSequel、Markabyでは実質的に、本当に素晴らしい オープンソースの取り組みに、多大な作業が任されたのです。おかげでWavesは、MVCグルーの提供に貢献すること、この点の改善だけに集中できるので す。けれども、Wavesをさらに改良する機会はたくさんあります。
RB：Wavesはスレッドセーフだそうですが、これを説明していただけますか。
DY：Wavesは「要求毎のスレッド」モデルをサポートし、異なるスレッドがお互いぶつからないように、要求はミューテックス内で処理されます。 Wavesはクラスタリングをサポートし、Rackを使うので、これがサポートしている唯一のモデルではありませんが、特にRuby1.9がネイティブで OSスレッドをサポートするでしょうから、開発者に選択肢を与えることは重要だと思います。現在のところ、Rubyコミュニティ内でスレッドにとりわけ魅 力があるわけではありませんが、ネイティブのスレッディングがサポートされるようになった途端に、返り咲きするのではないかと思っています。なにしろ、事 がはかどりますから。利点は、動作させるアプリケーションインスタンスをより減らしてスケール可能なことで、パラレルアーキテクチャを活用できる、優れた スレッド実装を有するマシン上では、特にその傾向が強くなります。そしてWavesでは、それがかなり簡単にできます。
RB：Ruby 1.9には「ネイティブ」スレッドがあるのを知って、Wavesが1.9とどのように連動すると思いますか。
DY： Wavesは今のところ、1.9上ではサポートしていないと明言しておくべきでしょう。しかしながら、1.9でのサポートがWaves前進の主な目標であ り、それは1.9にはWavesで活用できる多数の魅力的な特徴があるからだけでなく、スレッドセーフであることが1.9上でのWavesのパフォーマン スを飛躍的に向上させるからです。例えばMerbの皆さんはパフォーマンスについて心配していらっしゃいますが、私がMerbの方たちほどパフォーマンス を心配する必要のない理由のひとつがここにあります。そして、次のリリースでは、WavesをThin上で動作させ、パフォーマンスを向上できるはずで す。けれども、1.9に移行した途端に、もっとずっと面白くなると思っています。
RB：JRubyのサポートはどうなっていますか。Wavesでは、JRubyで完全サポートはしていないSequelを使っていますよね。
DY：その件はおそらくロードマップでは、1.9サポートの後になる予定ですが、提案を聞く用意はあります。Sequel は新規アプリケーションのデフォルトになっているだけで、WavesがSequel に依存しているわけではないことを指摘しておきましょう。しかし、そうは言っても、今のところはパフォーマンスより特徴に重点を置いているため、 JRubyは最優先課題ではないのです。私はSequelの機能の混合が本当に気に入っていたので、それが良い例でしょう。うまくいけば、Waves用の 重要ライブラリは、ロードマップの十分早期の段階で、1.9とJRubyへマイグレーションするでしょう。ここでも、Rubyコミュニティからフィード バックがあれば変更の可能性もあり、とりわけ貢献することに興味のある方がいらっしゃれば、その可能性は高くなります（暗に貢献のお願いです！）。
RB：Wavesの予定について、詳細を教えていただけますか。
DY：第一に、すでに素晴らしい提案をもらっています。その中には、Tenjin、Haml、SassのテンプレートライブラリやThin Webサーバに対するサポート追加が入っており、近々実現することになっています。そして、クラスタリングサポートのバグ・フィックスです。現在は欠けて いるデータベース支援のセッションをサポートに加えることも計画しており、request lambdaも若干改良する予定です。
Wavesのスキーマ反映能力の強化には多大な努力が必要です。今のところ、ここがSequelとDataMapperの弱点であり、WavesにはORMに依存しないスキーマの概念を持たせたいのです。JIT主義をViewsに拡張する上で、スキーマ反映が非常に重要と考えているからです。
テストに最良のデフォルトアプローチを見極めたいと思っています。これまでいろいろなアプローチを使ってきて、RSpecをとても気に入っているのです が、デフォルトのWavesアプリケーションに組み込むのにはためらいがあります。その理由は、検査に関しては現在、Rubyコミュニティに非常に多種多 様な意見とアプローチがあるからです。Sequelはとても簡単に決定できましたが、その理由は、ミグレーションをサポートしていること、Rubyの表現 式をクエリとして容認することで、これは本当に素晴らしい特徴だと思います。しかし、RSpecをデフォルトにすることに関しては、Sequelほど自信 を持てません。ですから、この分野で助けていただけると、非常に嬉しいです。
パフォーマンスへの取り組みも開始したいと思っており、最初は、問題の可能性がある箇所のベンチマークとプロファイリングのみ行います。本当に、これから やるべき興味深いことが山積しています。Wavesはすでにかなりいい線まできていると思いますが、Wavesが魅力的になるかどうかは、Wavesが不 可能を可能にできるかにもかかっているのです。見えているのは氷山の一角に過ぎないのです。ロードマップ項目のリストをhttp://rubywaves.com/roadmapに管理していますので、まだ改良の初期段階ですが、さらに詳細をお知りになりたい方はご覧ください。
RB：時間を割いてWavesについてお話しいただき、ありがとうございました。
WavesのWebサイトには、複数パーツからなるブログを作成するチュートリアル(source)がある。Wavesのセットアップとチュートリアルをやってみたが、宣 伝にあるようにすべてが機能し、すてきなアプリケーションが出来上がった。チュートリアルに続いてスクリーンキャスト(source)も利用可能である。Wavesに関す るこの他の情報についてはWaves Webサイト(サイト・英語)をご覧あれ。
原文はこちらです：http://www.infoq.com/news/2008/02/waves-ruby-framework