News

David Pollak氏 lift と Scala を語る

作者 Gavin Terrill, 翻訳者 畠山貴 - (株)永和システムマネジメント 投稿日 2008年3月28日午後12時10分

コミュニティ: Java,; Architecture
トピック: 言語,; Webフレームワーク
タグ: Scala

3月10日、David Pollak氏(source)は lift 0.6 のリリース(source)をアナウンスした。

lift は表現力ゆたかで洗練されたウェブアプリケーションフレームワークで、JVM上で動くスクリプト言語 Scala で書かれています。lift はセキュリティの重要性・メンテナンス性・スケーラビリティ・パフォーマンスを重視しています。また、lift により開発者は高い生産性を得ることができます。

lift 0.6 は以下のエキサイティングな新機能・機能改善をもたらします。

- Scala 2.7.0 のサポート(lift アプリケーションの開発に Eclipse が使えるようになります)
   - liftコアクラス内でのローカリゼーションのサポート(Mariusによる)
   - リダイレクトのサポートの強化
   - Cookie のサポート(Servlet の Cookie 機能を使いやすいようにラップしたもの)
   - Prepared Statement の改良
   - JSON サポートのための大幅な改良とクライアントサイドの HTML 生成
   - テストとドキュメントの改善（Eric による)

David へ質問する機会を得た我々 InfoQ 取材班は、彼が lift の開発を始めたきっかけと、これまでの Scala(サイト・英語)での開発経験についてたずねた。

lift の開発に至った経緯を教えてください。

わたしはこれまで Rails による開発を 18 カ月、Java による開発を 10 年経験してきました。Rails はウェブ開発に新しい風を吹き込みました。よく使うタスクはコマンド一発で実行することができます。実にすばらしい。しかし、私は気が付いてしまいました。Ruby の動的型付けは多くのエラーを引きおこすことに。そして、安心してデプロイするためには 95% ものテストカバレッジを達成しなければいけないことに。95% のテストカバレッジを得ることの代償として、私の書いたコードは(テストコードも含めて) Java で書いたものと同等のサイズにまでふくれあがってしまいました。その上、Rails では動的なコードの変更が可能なため、開発・テスト・デプロイ中にトラブルが続出するようになりました。高いテストカバレッジを確保しているにも関わらずです。これらの問題にくわえて、MRI(Matz Ruby Implementation: まつもとゆきひろ氏による Rubyの実装)は速度が遅く、言語仕様も安定していません。それなのに開発コミュニティはそのことに見向きもしません。私は他の言語も見てみようと思うようになりました。そんな時に Scala と出会いました。Scala を使ってみて、これこそが私が求めていた言語だと思いました。私が Ruby で気に入っている機能と Java で気に入っている機能のすべてを Scala は備えていました。それはまさに「君のピーナツバターが僕のチョコレートについちゃった」瞬間でした。 (訳注: Reese 社のピーナツバター入りのチョコレート菓子の CM のフレーズ。ピーナツバターを持ってる少年と、チョコレートを持ってる少年が道でぶつかり、ピーナツバターつきのチョコレートが出来るというストーリ。http://jp.youtube.com/watch?v=9IfbqYwMYAA)

Scala をウェブフレームワーク開発に適した環境たらしめているのは何なのでしょうか？

言語のシンタックス・パフォーマンス・安定した言語仕様・必要なところでだけ指定すればよい優れた型システム・クロージャ・パターンマッチング・組み込み XML リテラル、そしてアクター。たくさんありすぎて、きりがありません。.

Rails、Seaside、Java のフレームワークである Struts や SpringMVC と lift との違いは何でしょうか？

Rails のように簡潔で使いやすく。
Seaside や Wicket のようにセキュアでステートフル。.
型安全なのに Struts のように冗長過ぎることもなく。
他のどのフレームワークよりも手厚い Comet のサポート。
これにより大人数でのコラボレーションを可能とする即時応答アプリケーションを作成できるようになります。
これらの特徴により、驚くほど強力なアプリケーションを（Rails のように）驚くほど速く作ることができるのです。また、lift ではアプリケーションの持つ状態をリレーショナルデータベースへぐいぐい押し込むことに心悩まされることはありません。状態はフリーズドライにされることなく「生きたまま」に保たれます。これは、フロントエンドのデータをデータベーステーブルへ格納するようなアプリケーションにおいて大きな違いを生み出します。

lift を製品環境で使った経験について聞かせていただけますか？パフォーマンスなどはどうでしたか？

わたしは十分な数の lift アプリのベンチマークを計測しました。lift レンダーパイプラインは簡潔で扱いやすうえに、lift は標準的な WEB コンテナで動作します。これは、lift は上手く書かれた J2EE アプリケーションと同等のパフォーマンスを得ることができることを意味します。データベースへのアクセスがないページのレンダリング時間はだいたいが 1ミリ秒以下です。DB へアクセスするページのレンダリング時間は、当然ですが DB アクセスの種類によります。Amazon EC2のインスタンス(1.7GHz のインテルプロセッサと 2GB の RAM)上で動かした場合で、アクセスするページのうちの 50% が同じインスタンス上の MySQL へアクセスしていたとすると、lift は 1秒あたり 500ページものアクセスをさばくことができます。

既存の Java アプリケーションとの連携や JRuby のような言語環境との混在についてはどう思われますか?

lift は既存の Java コードとの連携を見事にこなします。実際に lift の RabbitMQ と XMPP サポートは、Java のライブラリの上に構築されています。Scala は Java のコードを 100% シームレスに呼び出すことができます。Java のインターフェースを Scala で実装することも、Java のクラスを Scala でサブクラス化することもシームレスに行うこともできます。Scala と Java の連携はすでに実用になっているようです。lift と Spring を連携させているプロジェクトが少なくともひとつは存在しています。私が初めて書いた Scala アプリは Servlet コンテナだったのですが、Java との連携部分があまりに簡単に動いてしまったため、コードを書いた自分自身が驚いた経験があります。

原文はこちらです：http://www.infoq.com/news/2008/03/liftweb