Groovy/Grails/GAE

Groovy再考

Groovy には昔結構入れ込んだ。しかし、仕事で使うことはなかった。なぜかと言うと、動的言語を用いるとプロジェクトのアプリケーションの品質を保てないことが明白だったからだ。高品質なアプリケーションを開発するためには Groovy のほうが Java よりもはるかに開発者に高い能力を要求する。

しかし、自分で会社を始めた今、自分の権限でメンバーを選ぶことができる。現状は自分を含めて２名のエンジニアしかいないわけだが、動的言語でも品質の高いアプリケーションを書くことができると確信している。

そうなると、java よりは Groovy のほうが適切なのではと考えるようになった。

Grails再考

また、Grails については、 Grailsそのものの品質がまだ見えていなかったことや、Grails のコミュニティが他の動的言語のコミュニティのように見かけだけの生産性のみを追及するのではないかという懸念があったため、手を出さないでいた。

しかし、SpringSource が Groovy を獲得したため、見かけだけの生産性を追及するような懸念はほぼ払拭できている。

さらに、 VMWare が SpringSource を買収したことにより、クラウド、アプリケーションサーバ、Web系フレームワーク、DIコンテナ、言語、これらのすべてがワンストップで提供される可能性が出てきた。

そうなると、この流れに乗っておきたい気がする今日この頃である。

GAE再考

クラウドについては GAE についても検討しているのだが、正直まよっている。確かにメリットは多いのだが、許容できるレベルにないデメリットが数多く存在するのが問題だ。

大量のデータのインポートやエクスポートができないとか、join が使えないとか、リクエストの処理時間に制約があるとか、これらは我々の開発方針としては許容できない。しかし、これは時間が解決してくれる可能性もある。

BigTable については、現状においては DB のテーブル設計が神という考え方をする人たちには向いていると思うのだが、オブジェクト指向設計を行う人たちには RDB よりも敷居が高いと考えている。理由は、オブジェクトとのインピーダンスミスマッチが RDB よりも BigTable のほうが大きいからだ。そして、その影響は、洗練されたオブジェクト指向設計であればあるほど大きくなる。トランザクションその他の機能についても、BigTable には不利な点が多い。しかし、メリットも当然多いはずなので、メリットとデメリットを十分に見極める必要がある。

最初からデータ中心の設計を行い、ドメインモデルではなくトランザクションスクリプトを用いる可能性も視野に入れつつ GAE の使い方を検討してみるのもいいかもしれない。

なんてこと考えてました。