Grails 1.0 リリース: ORM DSL、フィルタ、RESTおよびその他投稿者

Grails 1.0がリリースされたことが、プロジェクトのメーリングリスト(source)、Graeme Rocher氏のブログ(sourse)、およびGrails.org(source)で発表されている。InfoQでは、Graeme Rocher氏に話を聞いた。Graeme Rocher氏は、Grailsプロジェクトのリードであり、G2One(サイト・英語)の創設者の一人かつCTOでもある。Grails 1.0のリリースについて、一連の機能、成熟度、使いやすさ、およびGrailsの今後の計画を含めて詳しく紹介する。

Grails 1.0のリリースノートのページ(source)には、新機能が細かく挙げられており、以下のようなものが含まれている。

• ORM DSL(source)。レガシーテーブルを扱う際に、Hibernateマッピングへの依存を減らすことができる。
• フィルタの扱いやすさ(source)。特定のアクション、1つのコントローラ全体、または複数のコントローラにURIに基づいて適用できる。
• REST(source)サービスの作成に対するサポート。 
• コンテントネゴシエーションのサポート(source)。HTML、XML、JSON、およびその他の同様の表現間で切り替えを簡単に行うためによく使用される。
• XMLまたはJSON経由でのデータ発行をサポートするための自動XML/JSONアンマーシャル。WebサービスおよびREST的な手法を使用する場合に重要となる。
• スコープ化されたサービス(source)。サービスにおける状態を保管するためのさまざまなプログラミングモデルを可能にする。

Grailsは、アノテーションなど、Groovy 1.5の機能をいくつか利用している。

1.0では、GORMとは異なり、必要であればJPAスタイルのアノテーションを使用できます (現在は、Hibernateとのマッピングをサポートするのみ)。

また、のような、Springのアノテーションサポートもすべて活用できます。

リリース1.0は、ソフトウェアプロジェクトが何回も行うリリースの内の1つではあるが、心理的に大きな意味を持ち、プロジェクトチームによる信任投票のようなものである。

Marc Palmer氏は次のように述べている(source)。

多くの人々は、リリース1.0が重要であることを心理的に理解しています。これは、今後の将来像の基準および基盤を決定するものです。Grails 1.0は、コア機能の点で非常に充実しています。また、さまざまな種類の強力な機能性を追加する無償プラグインも増え続けています。

Graeme Rocher氏は、Grailsの成熟度、つまり「実際に使用できるのか」という質問に次のように答えた。

自信を持って言いますが、成熟度は高く、実際の使用に耐えられるものになっています! ただし厳密に言えば、バグの一切ないソフトウェアリリースというものはこれまで実現したことがありません。ソフトウェアベンダーが、このソフトウェアにはバグがありませんと言えば、それは嘘を言っていることになります。私に言えることは、私達は時間をかけて完成させたということです。Grailsの作成には3年近くがかかっています。Grailsを試してもらえば、必ず、満足してもらえることと思います。

Graeme氏は、Grailsの成功例(source)としてこのサイトにリストされている例を説明した後、次のように補足した。

Grailsが浸透している分野は、主に、単純に掲載したり、そのままお話したりすることの難しいエンタープライズの分野です。

例えば、Grailsは、フランスの主要放送会社、USの大規模ホスティングプロバイダ、およびロンドンのトップHR企業で使用されています。さらに、SAPでは、SAP NetWeaver 7.1上で複合アプリケーションをすばやく構築することを可能にする、Composition on Grails(source)プロジェクトが進められています。

Grailsは、Groovy言語 (最近、エンタープライズへの対応(source)に取り組んでいる)、SpringおよびHibernateといった成熟度の高いものの積み重ねの上にある。Graeme氏は、「SpringやHibernateを危険性が高いと思いますか」とも言っている。

Graeme氏は、Grailsがエンタープライズから多くの理解を得ている理由について次のように述べた。

大企業では、SpringやHibernateで作成されたインフラストラクチャが既に存在していることが多く、そのような場合にGrailsの導入はより簡単になります。

これには、多くの理由があります。その1つは、既存のSpring bean定義をとても簡単に再利用できるようになっていることです。単純に必要なXMLを投入するだけで済みます (おそらく、これはGrailsでXMLを目にする唯一の瞬間です)。

また、既存のHibernateドメインモデルも、Grailsの利点を一切損なうことなく簡単に再利用できます。

続いて、開発チームがいかに簡単にGrailsを使えるようになるかについて次のように説明している。

Groovyは、構文レベルで可能な限りJavaとうまく統合できるようにするという考えに基づいて作成されているので、当然、Java開発者のチームはより簡単にGroovyを習得できます。

Grails自体は、Java EEを大幅に簡略化したものと言えます。率直に言えば、Java向けに存在しているフレームワークの多くは、必要以上に難し過ぎます。このため、他のプラットフォームのソフトウェアエンジニアは、急に複雑な世界に飛び込むことになるので、Javaプラットフォームへの移行をなかなか決められません。.

こうした意味で、Grailsは、PHP(source)など他の世界の開発者に、Javaプラットフォームへの扉をまさに開いたと言えるでしょう。

しかし、すべてJavaで積み重ねていくという簡単さには、代償が伴うこともある。

大きな危険としては、基盤となっているフレームワークの抽象化において私達の側であまりに多くのことを行っているため、リークを発生させる可能性があります。

例えば、HibernateのLazyフェッチとEagerフェッチの違いを理解していない開発者は、何らかの問題に陥る可能性があります。このような危険は、実際には他のJavaプロジェクトも同じですが、このフレームワークがとても簡単なだけに、新しく始めた人は時としてこのような落とし穴にはまることがあります。

動的言語は、最初の開発としては簡単だが、効率の悪いツールのために後で保守コストが大きくなると考える人たちもいる。Graeme氏は、このような懸念に対して次のように述べている。 :

Groovyはそうならないと私は強く信じています。私がこのように信じるのには、いくつかの理由があります。まず、Groovyは動的な型指定ではなく、任意の型指定です。つまり、型を指定するかしないかは選択することが可能で、かつほとんどの場合において型は推測されます。例えば、IntelliJのJetGroovyプラグインなどを使用することによって、Groovyでも、Javaとほぼ同レベルの完全なリファクタリングおよびコード分析サポートが得られます。

さらに、Groovyは、共用コンパイラを備えた、真の混合ソース言語であるため、JavaからGroovyに、またはその反対に簡単に移動することができます。他の動的言語では、Javaのコード分析およびレファクタリング機能の多くが失われてしまうと思いますが、Groovyではそのようなことはないので、保守はJavaの場合と変わりません。

やがて、EclipseおよびNetbeansのサポートがIntelliJのレベルに達し、より多くの開発者がこの種の開発に触れるようになることを期待しています。

Grailsの将来について、Graeme氏は、1.0の後のリリースプランを語った。まずは、Groovy 1.6およびパフォーマンスについて次のように述べている。

1.0は、下位互換性の基準となるものです。今後は、どのような機能を追加する場合でも、既存のアプリケーションなどを慎重に考慮していくことになります。

1.0.xリリースはいずれいくつか登場すると思いますが、私達は、現在、1.1に向けて多くのことに注目しています。まず、GroovyおよびGrailsのロードマップは相互に共通している部分が多くありますが、中でも、Grails 1.1に含まれる予定のGroovy 1.6での重要な点は、呼び出しサイトのキャッシング技法を使用することによるパフォーマンスの大幅な改善です。

この目的は、Groovyを、JVM上での最速の動的言語と同レベルにすることです。Grailsは、強固な基盤の上に構築されて既に十分なレベルに達しているので、さらなる恩恵を受けるだけです。これがGrails自体にとって重要となるのは、Java EEテクノロジおよびプロジェクトとの統合をさらに進めることです。

Marc Palmer氏は、Grails 1.0およびそれ以降で使用されるようになる、実際のアプリケーションで行う新しい種類の結合テスト(source)について、次のように述べている。

私達は、Grails常時結合ビルドの一部としてSVNで提供される「サンプル」アプリケーションで、有効なWebテストを自動的に実行するためのフレームワークも作りました。サーバ環境に関して最初は問題がありますが、プロセス全体はローカルで機能します。必要なことは、SVNに、有効なテストアプリケーションと、さらに重要なWebテストスクリプトを入れることだけです。

これは、Grails用「TCK (テクノロジ互換性キット)」のようなものを効果的に形成し、1.0を基準とした機能性に対して安定性を確実にします。大量の単体テストも、常時結合ビルドプラットフォーム (実は、かなり優れているBamboo) の一部としてGrailsが継続的に行います。包括的な単体テストおよびWebテストを行う大規模なアプリケーションからの貢献を期待しています。

Grailsは、全階層にわたる統合を実現すること、およびJava用Webフレームワークのトップとなることを目指して、Javaの世界から継続的に新しいテクノロジを統合していくであろう。

1.x リリースでは、JSF、GWT、Wicket、およびStrutsなど、他のよく使用されるWebフレームワークとのプラグインを通じての統合と合わせて、JPA、JSPタグライブラリ、およびPortletサポートを追加する予定です。さらに、GrailsをMavenライフサイクルに結合するMaven 2プラグインを通じて、GrailsにMaven 2サポートを標準で含むようにする計画もあります。Grailsは、単なるWebフレームワークではなく、ビルドシステムからORM層まで、ソフトウェアライフサイクルのすべての部分に対応することを目指すソフトウェアの集まりであることを忘れないでください。

Graeme氏は、すべてのプラグインシステムが抱える問題として、プラグインは他のプラグインと連携しないということを認めているが、よく使用されるプラグインのいくつかについて次のように述べている。

いくつかのプラグインは、かなりの成長を遂げ、拡大を続けるすばらしいコミュニティを持っています。例えば、JSecurity、Searchable (Compass統合)、XFire、およびRichUI (Yahoo UI統合) は、非常に普及していると言え、さらに高速に進化を続けています。

ゆっくりとしたペースで進化するものもありますが、「死んだ」プラグインはほとんどありません。これは良い状況と言えます。

最後に、2007年10月にはG2One(サイト・英語)が設立されている。これは、GroovyおよびGrailsについてのトレーニングサポートおよびコンサルティングを行う企業である。

10月に創立して以来、著しく順調であり、規模は倍になりました。Groovyを得意とし、例えば、問題解決数はどんどん増加しています(source)。 

現在は、フルタイムやパートタイムの人々で各プロジェクトを進めています。また、Groovyの採用を検討するためのサポートを求めていた人々に大きな影響を与えてきました。

コミュニティからの反応は、Jaiku(source)や、いくつかのブログ(source)などからわかりつつある。多くはリリースの事実を伝えているだけであるが、Grailsを試してみての反応をいくつか以下に紹介する。

• Michael Kimsal氏(source)は、このリリースを待っていたことを次のように記述している。

  私は、このリリースを長年待ち望んでいました。Grailsは、昨年の春に私が .5リリースあたりから始めて以来、確実に大きく進化しています。Graeme氏たちは、多数の大きなバグに意欲的に取り組み、この数ヶ月で何百かの問題を修正し、1.0のリリースを実現しました。

• 一方、Ray Kreuger氏は、Java開発者にGrailsを詳しく調べてみることを提案している(source)。

  もし、Javaを知っているのにGrailsまたはGroovyを知らないというのであれば、Grailsを見てみることを強くお勧めします。Grailsは、Convention over Configuration (設定より規約) という考えに基づく、高速Webアプリケーション開発フレームワークです。これは、Ruby-on-Railsに非常に似ていますが、言語にGroovyを使用します。このアプローチの大きな利点は、GroovyがJavaに基づいているという点です。つまり、Javaのように使えるのです。このため、チームは少ない学習で導入することができます。この他にも、ビルドを、どのような古いアプリケーションサーバにも配置できるWARファイルにできるという利点があります。このために、特別な技法は必要ありません。これは、エンタープライズ的な環境に配置するときには重要なことです。

• Bill Gloff氏は、氏の言葉を信じるのではなく(source)、自分で試してみるようにと書いている。

  最近、Groovyとそれに対応のWebフレームワークであるGrailsで製作活動を行うことに非常に興奮しています。そして、なぜ使用していて楽しいのか、またなぜ開発者として大幅に生産性が上がるのかがわかってきました。Grailsは、Ruby on Railsから多くのヒントを得ていますが、既存のJavaの知識とJEE環境を活用することができます。

• GroovyZoneでは、次のようにGrailsが支持されている(source)。

  私にとって、Grailsは、究極のJava用高速プロトタイピングプラットフォームです。私は、既存のHibernate構成のクラスを投入することで多数のアプリケーションを構築したり、スカッフォールディングビューを生成したりしています。これは、本当に簡単に始めることができ、私が、作成しているアプリケーションの方に集中できるようにしてくれます。

• 最後に、最近の以下のようなRailsとGrailsを比較する議論は、この2つがどの程度まで匹敵するものとなっているのかを理解するのに役立つ。

  • Darryl West氏は、RailsからGrailsに切り替える10の理由(source)を挙げている。
  • さらに、Graeme Rocher氏は、GrailsがJava開発者にRailsを忘れさせる理由(source)を挙げている。 
  • 主にRailsに関する実績で知られるRelevanceは、Graeme氏の挙げる理由(source)を「切り替える理由」、「ごく限定的なもの」、および「くだらないこと」に分類している。  
  • Jens Krämer氏は、Graeme氏は単にGrailsへの関心を高めよう(source)としているだけだと述べている。

InfoQでは、今後も状況の変化に合わせてGroovy(source)およびGrails(source)を取り上げていく予定である。

原文はこちらです：http://www.infoq.com/news/2008/02/grails-1.0-released