2013-04-24

Struts1ユーザにGrailsをオススメする6の理由 - The search is over -

Struts1のEOLがアナウンスされました。最後のリリースから長く時間が経過しており、実質開発は終了している状態でしたが、このタイミングでのアナウンスとなりました。

アナウンスの中では、次の乗り換え先として、Struts2・Spring Web MVC・Grails・Stripesといったフレームワークがお薦めされていますが、私はダンチな生産性を提供するGrailsをお勧めします。

私のフレームワーク遍歴は、Struts1、Wicket、Seasar2、Springと色々渡り歩いてきましたが、ここ1年はがっつり業務でGrailsを使用しています。 1年がっつり使ってみた経験から、Struts1ユーザにGrailsをお勧めする理由をいくつか考えてみました。

Grailsは既存Java フレームワークの延長線上にある

Grailsを支える基盤は、Spring・Hibernateといった、Javaの世界でよく知られ、また広く使われているフレームワークです。ビューはSpring MVCをベースとしており、モデルはHibernateをベースとしています。このため、既存のJavaシステムで、これらフレームワークの知識を有している場合は、そのノウハウを思う存分活用できます。

Struts1ユーザからみてGrailsをお勧めする理由の1つは、Grailsのコントローラがリクエスト駆動ベースであることです。 WicketやJSFなどのように、コンポーネントベースではありません。このため、Struts1でActionクラスを実装してしてきたユーザにとって、GrailsのControllerは非常に馴染みやすいはずです。

さらに、Java EE互換である点も重要です。 Grailsでは、単にgrails warとコマンドを実行するだけでwarファイルを生成できます。このwarファイルは、Tomcatなど今までStrutsアプリケーションをデプロイしてきたアプリケーションサーバにデプロイ可能です。既存のアプリケーションサーバが使用できるため、今までの運用ノウハウも引き続き活用できます。

GroovyはJava開発者のための言語である

Ruby、Pythonといった言語に比べて、Javaコードの冗長さは、よく批判の対象になります。 Groovyの目標は、常に、このJavaの定型的な冗長さを排除し、Java開発者に異次元の生産性を提供することです。

GroovyはJava言語の延長にある、Java開発者のための言語です。 Java開発者のための言語である証拠に、一部の例外を除き、Javaのコードは、Groovyのコードとして実行可能です。これは、Groovyのシンタックスは、Javaのシンタックスと互換があるということです。そのため、Java プログラマであれば、今すぐにでもGroovyのコードが書き始められます！世界中の多くのJavaエンジニアは、潜在的なGroovyエンジニアといっても過言ではないでしょう。若干言い過ぎたかも知れませんが、Javaエンジニアにとって非常に学びやすい言語であることは間違いありません。

もちろん、Javaコードとの親和性だけでなく、GroovyにはJava開発者に異次元の生産性を提供する多くの機能が含まれています。型宣言の省略、クロージャ、便利なコレクション操作、メタプログラミング、演算子のオーバーロードなど、Rubyや他言語で羨ましかった機能、またはそれ以上の機能がGroovyで使用できます。

Grailsは、このGroovyでコードを書きます。 Struts1ユーザにとっては、このGroovyが逆に障壁になるかと思います。いくらJavaとの親和性が高いとはいえ、言語が変わるというのは大きな話です。しかし、新たなフォースを手に入れるには常に痛みが付き物です。 Java開発者にとって、比較的少ない痛みで、異次元の生産性が手に入るのはGroovy以外にありません。

既存のJava資産をそのまま活用できる

GroovyとJavaの親和性の高さも、既存のJava開発者にとって大きな魅力の1つです。 Groovyからは、既存のJavaのライブラリ・フレームワークといった、Javaのコードを簡単に呼び出すことができます。これは、Javaのコード内でJavaのコードを呼ぶように、Groovyのコード内でJavaコードを呼び出せます。

また、GrailsでもJavaライブラリや、Javaのコードと連携する仕組みが予め用意されています。 jar形式のJavaライブラリは、単にlibディレクトリにファイルを置くだけで、簡単にアプリケーションの依存関係として追加できます。 Javaコードには、デフォルトでsrc/javaというディレクトリがGrailsによって用意されており、このディレクトリでJavaコードをすぐに書き始めることができます。

もし、Strutsアプリケーションで使用してた、ライブラリや、ビジネスロジックなどの資産がある場合は、 Grails上でもその資産を活用できます。

フレームワークの連携で悩むことはありません

Struts1を単独で使用していたユーザもいるかも知れませんが、SpringやHibernateといった、他のフレームワークと組み合わせて使用していたユーザも多くいると思います。これらフレームワークを組み合わせて使用する場合は、自分で連携の設定をしなければなりません。この連携の設定を調べるために、インターネットを彷徨い、気がつくと1日2日経過していた、という話は珍しくありません。一度連携できたら、使い回すだけでしょ？と思いがちですが、フレームワークのバージョンに伴い設定方法が変更になり、また1日2日インターネットにダイブする羽目になります。

たかが数日と思うかもしれませんが、迅速な開発が求められる昨今においては、これは非常に足かせになります。ぐぐってる暇なんてありません。

Grailsはフルスタックフレームワークです。create-appとコマンドを打てば、数秒で全てのフレームワーク連携が完了した雛形が手に入ります。 Struts1のように、フレームワークの連携で悩むことは、Grailsではありません。

進化し続けるフレームワーク

Struts1ユーザにとって、乗り換えたフレームワークが、数年で使い物にならなくなる自体はあまり嬉しくないでしょう。そのため、現在Grailsの開発が活発に行われているか、今後もメンテンナスが続くかは関心の1つかと思います。

現在Grailsは、VMwareとEMCとの合併会社Pivotalの配下にある、SpringSourceで開発が行われています。開発自体はオープンに行われており、ベンダー依存を気にする必要は今のところ無いかと思います。ソースコードもGithubで公開されています。

開発は活発に行われており、世の中の動向に合わせて新しい機能が今なお追加されています。ただ、新しい機能がどんどん追加されているため、正直枯れているとは言えない状況です。

Sturts1ユーザにとっては、安定性が心配になるかと思いますが、商用レベルでの使用に十分耐えるレベルではあるので、安心してください。

学習環境

Grailsのドキュメントは非常にしっかりと書かれており、日本語版も鋭意翻訳中です。

まとめ

GrailsはJava開発者のための、フレームワークです。 Java開発者が魅力を感じないとしたら、ほんと訴求先がないと言っていいかもしれません(言語、フレームワークは素晴らしいのは間違いないのですが、Java開発者以外には訴求力が弱い)。

ということでSturts1ユーザの皆さん、一緒にGrailsやりましょう！

2012-05-20

GrailsでHibernateのSQLログを出す

grails hibernate

DataSource.groovyでloggingSqlをtrue、formatもしたい場合はformatSqlをtrueに。

dataSource {
    ...
    loggingSql = true
    formatSql = true
}

おなじDataSource.groovyで

hibernate {
    show_sql = true
    format_sql = true
    ...
}

としても同じ。

こんな感じで出る。

grails> Hibernate:
    select
        this_.id as id0_0_,
        this_.version as version0_0_,
        this_.bar as bar0_0_,
        this_.foo as foo0_0_,
        this_.hoge as hoge0_0_
    from
        hoge this_ limit ?
grails> Hibernate:
    select
        count(*) as y0_
    from
        hoge this_

ただこれだとcreate tableするあたりが出てくれない。その場合はorg.hibernateのログレベルdebugにすると以下の様な感じで出る。

2012-05-20 11:34:27,830 [pool-84-thread-1] DEBUG hbm2ddl.SchemaExport  -
    create table hoge (
        id bigint generated by default as identity,
        version bigint not null,
        bar varchar(255) not null,
        foo varchar(100) not null,
        hoge varchar(255) not null,
        primary key (id)
    )

2011-01-31

Hibernateでテーブル構築時に初期データを投入する

hibernate

最近はもっぱらORMはJPA(Hibernate)を使用しているyamkazuです。こんにちは。

今更かもしれませんがhibernate.hbm2ddl.autoの威力はすごいですね。もはやCREATE TABLEを自分で書いたら負けの気分にさせられます。もう完全にEntityの実装駆動で開発が出来るのでかなりフットワーク軽く開発できます。どうしてもDDLが必要になったときはhibernate3-maven-pluginでEntity情報を元にDDLを生成なんかもできます。
参考: http://unmaintainable.wordpress.com/2008/04/12/hibernate3-schema-creation/

合わせてSpring Rooとか使用しているとDatabaseのDriverとかも簡単に切り替えられるので、チョチョイとテスト用のH2のDDLと、本番用のPostgreSQLのDDLとかも簡単に生成できて便利です。

hibernate.hbm2ddl.autoはすごく便利なんですが、個人的に不便だと思ってたのが初期データの構築。適当なユーザー情報とか、マスタデータとかです。なんか無いかなーと検索してたら以下の記事を発見。
http://stackoverflow.com/questions/673802/how-to-import-initial-data-to-database-with-hibernate
どうもクラスパスのルートにimport.sqlとファイルを置いておけば実行されるような事が書いてある！やってみたところ簡単にできました。素晴らしい。

ついでにHibernateの3.6からは

hibernate.hbm2ddl.import_files
http://docs.jboss.org/hibernate/core/3.6/reference/ja-JP/html/session-configuration.html

というプロパティがサポートされているのでコレが使えます。これを使うと任意のファイル名や、複数のSQLファイルが指定できるようになります。ドキュメントにも書いてありますが、どちらの方法を使うにしてもhibernate.hbm2ddl.autoに create か create-drop を指定しているときのみ有効です。

てかjbossのドキュメントにhibernate.hbm2ddl.import_fileとか書いてありますが正しくはhibernate.hbm2ddl.import_filesなのでお間違いないように！小一時間ぐらいはまりました。
コメント欄にあるとおりバグ報告していただいたのでそのうち直っているはず！
http://opensource.atlassian.com/projects/hibernate/browse/HHH-5887