jFD開発したりしなかったり日誌

_ ぼやき

UMLを作った設計作業がもうすぐ終わるのだが、一言いいたい。

オブジェクト指向じゃないソースからUMLは作れません。

アクティビティ図とフローチャートは似てるけど別物。

ベタベタWebアプリ（1画面1クラスみたいなの）のクラス図って

意味あるのかなあ。

_ jFD2

クライアントから送られてきた二つのエクセルファイルが同じっぽいけど

確信が持てないので、ファイルを比較するスクリプトを書いてみた。

20行。

お手軽。

実行してみたらやっぱり同じファイルだった。

_ Groovyを使ってやりたいこと

dotさんのblogでGroovyの利用方法について書かれていたので

ちょっと僕も書き込んだのだけれど、スペースが十分じゃなく

説明しきれそうになかったんでこちらに。

_ 以前某社で画面のモデルとビューを全てXMLで定義できる

Swingフレームワークというのを書いた。

これを設計していたときに気がついたのだが、プレーンテキストの

設定ファイルのみで画面が作れるということは、

ランタイム部分をクライアントに持たせれば設定ファイルは

Webサーバーにでも置いて、クライアントには設定ファイルの

URLでも渡してやればよく、つまりWebアプリ的に使える

クライアントアプリが書けるのではないだろうか。

実際にはストップがかかり（事例が無いので実行時のXML使用を禁止された。怒）

実現不可能になったが、

その後も構想だけは進めていた。

当時の実装では振る舞いだけはJavaコードだったので、全面的にWebサーバーに

置くのは難しかった。

振る舞いもXMLで記述する、というのも考えたのだが、

過去にもXMLで記述するプログラミング言語は見たことがあるが、

はっきり言っちゃうがあれは読みづらいし書きたい代物でもない。

XSLTなんかがそうだけど、記述が冗長で、無理矢理感が強い。

そこで振る舞いをGroovyにしてしまえばそれらが問題にならなくなり、

リッチクライアントを全てテキストファイルで記述できるんじゃないかと

考えている。

_ 僕の感覚だが、そのフレームワークを使って画面の振る舞い以外を作成するのに

必要な労力は、通常のJavaコードで書くのと比べて3分の1くらいだった。

Swingの知識が不要だったし、良い意味で自由度が抑えられていて、

「こういう画面が作りたい」という要求に対する回答が一つしかあり得ず、

実装者が無駄に悩むことも無い。

これで振る舞いの記述にGroovyを使えばGroovy自体の記述性の高さも加わって、

さらに効率の高いフレームワークになるのではないだろうか。

_ ただし、Groovyには問題点が幾つか。

_ ※のろい。

これはそんなには問題にならないと思う。

スクリプトから生成されたクラスをキャッシュする等の工夫が

確実に必要になるが、それはフレームワークの機能にすればよいし、

どうしても速度が必要な場合はJavaクラスで記述するって手もある。

あと現状で全く最適化されてないので後で高速化されるということに期待。

_ ※セキュリティ

今jFD2が同じ問題を抱えているのだが、GroovyはJavaで出来ることが

全て出来るので、改変したスクリプトで不正な操作が出来てしまう。

スクリプトファイルに署名するなどの仕組みが必要な気がする。

_ ※適用出来る部分を見誤ると、ものすごいスパゲッティが出来上がる。

Groovyを使って300行以上のコードを書くべきじゃない思う(個人的には100行)。

文法的にJavaと比べてGroovyが優れているのは、Javaが大規模ソフトウェアに

対応するために組み込んだ面倒な手続をいい加減に省いて小規模コードを

書くのを簡単にしてくれていることだ。

ある程度以上のソースになると、IDEの手助けは期待できないし、

Javaだとコンパイラが弾いてくれるバグが実行するまでわからなくなるんで

かえって開発効率が落ちる。

Groovyはあくまでグルー（糊）であって、基盤はJavaで記述するべきだろう。

そのためにもフレームワークがきちんと作りこまれていないと、

素のJavaで書くよりも悲惨なことになる。

_ ちなみに、このフレームワークはすごく書きたいんですが、

今はjFD2だけで手一杯（さらにこの後書かないといけないのが二つ控えている)なので

現実的に難しいです。

どこかの会社で僕を雇って書かせてみませんか？

（ないだろうなあ、そんな会社・・・）