Grailsを選択する理由
日本Grails/Groovyユーザーグループ 山田正樹
[email protected]
[email protected]
Webアプリケーション構築にGrailsを使うとなぜ得するのか?
三つの視点から
プログラマ/エンジニア
顧客/ユーザ
ベンダ/SIer
作る側の視点から
1. Groovy すごっ
めちゃくちゃ生産性高い
バグの入り込む余地が減る
少ない行数でリッチな機能
いろいろなことに挑戦しやすい
可読性も高い
多分今の半分の人数で作れる
コード行数はおおざっぱに言って1/5くらい
メンテナンス, 拡張もしやすい
高品質
インタラクティブに動かせるし
テスト環境も揃ってる
メタレベルを簡単にいじれる
特にJavaとの親和性高い
プログラムを対象にプログラミングできる 同じ作業を繰り返すことなくコード化できる
List retrieve(problem, n = 5) {
assert problem
if (!cases) return null
def result = cases.collect {
[score:similarityOf(it, problem), 'case':it]
}
assert cbrSpec
switch (cbrSpec.retrieving) {
case Number:
n = cbrSpec.retrieving
break
case Closure:
return cbrSpec.retrieving.call(result)
}
result = result.sort { it.score } [-1..-n]
}
!"#$%&'()
&*+,-
./0#12
345678'()
作る側の視点から
2. 既存資産を活用できる
Javaの知識, ノウハウ, コード
Javaのすべてのフレームワーク/ライブラリ
もちろん!
GroovyオブジェクトとJavaオブジェクトは完全互換だから
特にGrailsではSpring, Hibernate
Webアプリケーション構築の必携道具
その他にもAnt, セキュリティ, Log4j, JUnit, ... ∞
Groovyは高生産性の代わりに確かに遅い.
けど, CPU-sensitiveなところだけJavaでさくっと書けばいい
配備/運用はJ2EEの環境をそのまま使える
これがRuby/Railsとの最大の違い!
だからPHPから来た人はRonRでもいいかも知れない
作る側の視点から
3. 仕様と実装を分離できる
「仕様」は日本語ではなく, DSLを使ってプログラムとして宣言的に書く!
そのソフトウェアが何をすべきかが明確になる
日本語からプログラミング言語への翻訳が不要になる
共通のDSLは標準で組み込まれているが, 必要に応じて自前で簡単に定義できる
DSLを定義すると言うことは, 自分たちが格闘している問題の本質を明らかにすることだ!
つまり仕様が動く!
DSLで書いた仕様をどう動かすかは, メタプログラミングでプラグイン化する!
一度プラグイン化した, 「仕様インタプリタ」は何度でも再利用できる
「メタプログラミング」とはプログラマが繰り返しやることをプログラム化すること!!!
interfaceとclassのことぢゃないよ!
GrailsはDSLとプラグインの塊なのだ
概念クラスの例
class Product implements Comparable, Serializable {
String name, description
static constraints = {
name(blank:false, unique:true)
description(blank:false, validator: {
it?.indexOf("<script") < 0 &&
it?.indexOf("<link") < 0
})
}
static mapping = {
cache usage:"transactional"
}
static belongsTo = [category:Category]
static searchable = true
}
!"#$%&'
()*+,-./012 34566789:;<=>?
@AB !%&'
CDEFGH5IF12
J:K(LMNOPQ RSTUK
VUWXYZ[\]^_<RS
ワークフローの例
def OrderProductTestProcess = {
OrderFormWait(isStart:true, dueDate:0,
nodeInfo:'Product Order') {
variable(productId:READ_ONLY, catalogId:READ_ONLY,
price:READ_ONLY, quantity:WRITE_READ,
commentary:WRITE_READ)
action {
Log(logMessage:'Starting ordering product...')
return Order()
}
on('Order').to(['CheckingOrder'])
}
// ...
}
!"#$%&'
()*%&'
+,%&'
-./01%&'
23%&'
使う側の視点から
1. どんなものを作っているのか,
早くから確認しながら進められる
ちょっとしたプロトタイプは
DSLを書いたり, プラグインをインストールしたり, scaffoldすれば
すぐにその場で見せられるよ
使う側の視点から
2. 自分たちの課題をDSLの形で,
論理的に明確に提示することができる
DSLを顧客やユーザが直接書くことだって, あり得る
書けないとしても, 開発側が書いて説明すれば分かりやすいし, 動かして見せればもっと分かりやすい
後でロジックを弄らなくても, DSLの変更だけで, ソフトウェア変更も可能だ
もちろんそれだけでは駄目な場合もある. けどこれでうまく行く場合も多い
開発側との間で, 要求や仕様をちゃんと詰めることができる!
もしかしたら, 自分たちのビジネス改善につなげることだってできるかも知れないぜ
提供する側の視点から
1. 開発ノウハウをプラグインとして
資産化できる
ユーザから問題領域に関する知識が降ってくる → 要求
それをDSLで仕様として書き下ろす → 頭 = 個々のアプリケーション
アスペクト/ノウハウを具体化する → 胴体 = プラグイン
両方がバランスをとって成長しなければならない
雪だるま式開発
提供する側の視点から
2. 工数削減, 工期短縮, 品質向上
J2EEで苦労しているプロジェクトの半分の人数で大丈夫
実際には余った人数は, ちゃんとできていなかったテストに回すとか
最初の機能は例えば2週間後に提供可能
全体でも工期オーバーの案件数は絶対的に減らせる
プラグイン資産が充実してくれば, 同様のドメインに対しては圧倒的に有利
ただし技術を身につけるまではちょっと大変かも. それから, Grailsに合ったインクリメンタルなプロセスをちゃんと回すことも大事
バグは減る. よりよい提案を顧客/ユーザにできるようになる
ドメインを見つけるひと
ユーザ, クライアント
言語を設計するひと
ドメインを実現するひと
ドメインを組み合わせてアプリケーションを作るひと
ドメインを言語で記述するひと
ドメイン把握能力 営業力
技術力 総合力
聴き取り能力 構想力 抽象化
能力
専門的 技術力
提供する側の視点から
3. いろいろな役割の人のチーム
三方良し
本当にそんなうまい話があるのか?
一つは, 技術の素性の良さ
二つ, 少人数でいいから優秀な人が必要
最初から優秀な人はいない. 人を育てる. それも大事な仕事
三つ, 開発側とユーザ側がちゃんとコミュニケーションを取ること
商品化のための余計なめっきも (今のところは) ない
ま, それはどんな仕事の場合でも大事なことなんですけどね 作る
使う
提供する
