LiQ Container 1.0-alpha2 リリース

リリースしました。
ダウンロードはこちらからどうぞ。

あいかわらずドキュメントが全然だったり、例外処理が手抜きだったりと
課題は山積ですが、今日だけは自画自賛させてください。

ほとんど全部のコードを書き直した結果、課題だった拡張性は大幅に
向上し、プログラムの構造もさらにシンプルに、きれいになりました。
いくつかのちょっと面白い新機能も盛りこまれています。
数寄者の方は是非ソースを読んでいただいて、批評して下さいませ。

例によって、ご意見、ご要望、批判、誹謗、中傷など歓迎します。

全体的なアーキテクチャはこれで大体Fixさせようと考えています。
なので、宣伝と、後でドキュメントを整備するときの叩き台とすること
を狙って、このblogでLiQ Containerの詳しい解説を
始めようかと思っています。

今後の予定は、beta1までの間に、ちょっとしたサンプルアプリを
作ってみて、足りてない機能がないかどうか検証します。
beta版は、public APIはFixして、ドキュメントの整備とバグフィックスを
行います。

段々自分の作ってるものに思い入れが出てきたので、是非
「使える」ものに仕上げていきたいとおもっております。

また、極論を。。。

関数と構造体だけあれば十分、それは随分な極論な気がしますが。。
でもよくよく考えてみると、純粋な業務ロジックは結局
関数と構造体だけで済む場合も多いのかもしれませんね。

ここ数年みんなが悩んでるのは、関数と構造体だけで済む部分と
そうでない部分(DBからデータをとってくるとか、UIまわりとか)
をきれいに切り分けるのが意外に難しいからだという気が
しています。

死ぬ程いろんなフレームワークが出てきても、なんかいまいち
解決されてる気がしないのは私だけでしょうか?

冷やかし

今日、人材紹介会社を冷やかしにいってきました。
今の会社に転職したときに御世話になったとこです。

いまやってることを放っぽり出して転職するわけに
いかないから、本当に冷やかしだったにもかかわらず、
転職市場の話がいろいろ聞けてためになりました。

やっぱり最近IT業界の人気は落ちてるみたいですね。
悪いイメージが定着してしまって、若い人が全然はいってこないらしい。
嘆かわしいことです。SIでも、パッケージ開発でも、なにかサービスを展開するにしても、
ソフトウェア開発はクリエイティブで楽しいことのはずなんですけどねぇ。

他の会社はわからないですが、すくなくとも私のみるかぎり、
うちのおやごさんの状況は実際にひどいもんです。開発プロセスの未熟、
マネジメントの不在、スキルの空洞化など、問題をあげればきりがない。
こんな状況で品質も顧客満足もあったもんじゃないです。
いくら体力に自信があるといってもこのままでは、あと数年もすると本当に
まずいことになるような気がしてなりません。

自信をもって若い人にSI業界にきてくださいとは、
とても言えない状況なのが情けないです。
少なくとも自分のチームだけは多少なりともましな状態にしたいと思って
がんばっています。

話のついでにうちの会社が人材紹介会社にまともな求人票を
出していないことが判明。やっぱり。
どうりでいくらまっても人が増えないわけだ。

しっかりしてくれよ、もう。
どんくさいにも程があるぞ>経営陣

Maven2でJUnit4サポート

されたようです。ちょっと前の話みたいですが、なぜかJIRAの通知メールがGmailで
迷惑メールにされてて気づきませんでした。
いま、surefireのtrunkをおとしてきて動かしてみたら、確かに動き
ました。いままでは、JUnit4の、JUnit3のRunner用のアダプタ使っても、
パッチあてないと動かないような状態だったんですね。

これで@Testとかをちゃんと認識してテスト実行できるようになりました。


--
svn co http://svn.apache.org/repos/asf/maven/surefire/trunk/ surefire
--

とかで、最新のソースコード落としてきて、

--
mvn install
--

で使えるようになります。

環境に依存する設定について

最近ブラックホール系のプロジェクトに飲み込まれているため、
あまり饒舌にはなれないですが、hiro345さんのエントリに
少々コメントをば。

さすがに鋭いご指摘だと思います。
JavaでDIの設定を書こう、という場合、環境依存の情報をどうやって扱うか、
というのは解決しなければいけない問題です。
違うマシンにデプロイするたびにソースコードからビルドしなおす
ようなことは当然許されるはずはないですから。

いまのところ、環境に依存した情報はModuleのsetter経由で
渡すことを考えています。
例えば、コネクションプールなどの機能をもつデータソースを
コンポーネントとして提供するモジュールであれば、
以下のようなイメージになります。

--
DataSourceModule module = new DataSourceModule();
module.setDriverUrl(...);
module.setUser(...);
module.setPassword(...);
module.setMaxConnections(..);

DataSource ds = module.getInstance(DataSource.class)
--

setterに渡す値はそれこそXMLなりプロパティファイル
なりから適当にとってくればいいと思います。
外部ファイルから設定をとってくるには既存のライブラリが
いろいろ使えると思ってるので、いまのところLiQ Container自身が
その仕組を提供することは考えていません。
ただ、関連プロダクトとしてそういうものを作る可能性はあります。
Moduleは限りなく
ふつうのJavaオブジェクトなので、XMLバインディングツールを
使ってモジュールをインスタンス化することすらできるはずです。


環境に依存する情報は、DIの設定からは切り離して、別途設定し、
DIの設定はプログラマのみがいじるようにすべきだと
思っています。

繰り返しになりますが、私がJavaで設定を書くべき、といっているのは、
DIに関してだけです。とくに運用の人にJavaコードで設定書かせるなんて
ひどいことはさすがに考えてないです。。

ところで、問題はこのモジュールが提供するDataSourceをよそのモジュールの
コンポーネントにどうやってInjectするか、なのですが、よくある
「継承」とかとはちょっと違うアプローチを
思い付いたので、alpha2で公開すべくがんばって作業してます。

alpha2は1月中のリリースが目標です。さすがにAPIはそろそろ安定
させたいものです。何をいってもやっぱり動くもの出してかないと
だめですしね、

力尽きたので、今日はこれまで。おやすみなさい。

ブックレビュー: Java 並行処理プログラミング

前から洋書の方を買おう買おうと思っていたら翻訳版がでたので、
去年の年末ぐらいに買いました。

内容はとても素晴らしいです。
翻訳もこなれた日本語になっていて、読みやすい。

いままでスレッドとか並行処理に関してここまでわかりやすく、かつ
幅広く解説した本はなかったのではないでしょうか。


この本を読んで、スレッドに関する私の理解は実はそうとう中途半端
だったことが判明し、反省しきりです。
いままで仕事でスレッドが絡むプログラミングをしたこともあるのですが、
あれは本当に大丈夫だったのだろうかと不安に駆られました。

今まで私の中で謎の存在だった
java.util.concurrentパッケージがかなり便利なこともわかりました。
これを使わない手はないですね。

普段あんまりスレッドとか触らない人でも、Javaプログラマを
名乗るのであれば、一般教養として読んでおきたい一冊ですね。

ツールと記法の問題について

koichikさんやひがさんが
指摘されているように、確かにDSLとしてのJavaの表現力は非常に弱いです。
それは、Java で DSL ぽいことをやるフレームワークを実際に書いた当人である
私は、すごく実感しています。

LiQ Containerを作りながら、何度「mix-inしてぇー」と叫びたくなったことか。
私も、「全て」の設定情報や定義情報をJavaで表現すべきだとは思っていません。
そこでJavaで勝負しようとするのは辛すぎます。
プログラミング言語をDSL的に使うという点では、Rubyとかの方がずっと能力が
高いと思います。

ただ、私がそれでもDIコンテナの設定にJavaコードを使うのが良いと
思うのには以下の2つ理由があります。

1. DIコンテナが扱う設定情報の多くがJavaクラスに関するものである
2. Javaクラスという情報を扱うのに、Eclipse JDTというツールが使える

ある情報を表現する記法の是非を問うときの観点として、記法自体の能力と同じくらい、
その記法を記述するのに使えるツールの善し悪しは重要だと思います。
もし、Javaコードを書くツールがメモ帳とjavacしかなかったら、
Javaで設定書こうなんて言い出してなかったと思います。

たとえば、私は結構 Excel VBA マクロをよく使うのですが、
別にVisual Basicの文法が好きで使っているわけではありません。
いまさら言うまでもないことですが、Visual Basicの文法は完全に腐っています。
にもかかわらずExcel VBAが「それでも使える」と思う理由は、
エディタの存在です。軽快なエディタが、Excelインストールすると
デフォルトで付いてきてAlt-F11を押すだけで起動すること、
イミディエイトペイン経由で現在のExcelオブジェクトの状態を
簡単に見られること、デバッガが軽いことなどが Excel VBA を救っています。

私は、あるツールの善し悪しを決める要素として、そのツールの機能の成熟度
も、もちろん大事なのですが、ツールのセットアップにかかる手間も結構大事
だと思っています。Eclipseプラグインだったら、デフォルトで入っているJDT
のようなツールが十分使えるなら、それが一番いいし、入っていないなら、
ダウンロードしてインストールしなければいけないプラグインよりも、
ちゃんとupdate siteが用意されているプラグインの方が良いと思います。

それは、単純にセットアップがめんどくさいという理由だけで
そう思うわけではなくて、デフォルトで入っているツールは、それだけ
多くの人に使われて、叩かれて、磨かれていると思うからです。
実際、JDTの成熟度は凄いと思います。


DIコンテナの設定がJavaで十分簡潔かつ宣言的に書けるのであれば、
Javaで設定を書いてJDTで編集するほうが、
XMLで設定情報を書いて、裏でJDTを利用する特別なプラグインで編集するよりも
良い、というのが私の立場です。koichikさんとはちょうど真逆の立場ですね。

そんなわけで、「Javaで十分簡潔かつ宣言的に書ける」という仮定を成り立たせる
ことができるかどうかがLiQ Containerの生命線になってくるわけです。
あらゆる設定情報を書ける必要は全然なくて、DIコンテナの設定さえできれば
問題ないのです。

いまのところ、良くある設定のパターンに関しては、
かなりいい線いってんじゃないかと自分では思っていますがどうでしょうか?
拡張性に関して、クリアしなければいけない課題をいくつか抱えてはいますが、
それはalpha2である程度改善したいと考えています。

尚、私がこのような立場をとっているのは、
多分私があんまりEclipseプラグインとかを書けないということも関係があると
思います。もし、自分にものすごい勢いでハイクオリティなプラグインを作る能力が
あったら、もしかしたら全然違うこと言ってたかもしれないですね。

そうはいったものの

昨日のエントリを書いたあと、やっぱりあまりにも
記述量が増えすぎるんじゃないかということと、コードの可読性が
かなり落ちてしまう、ということで思い直して、
今では、現在の記法も残そうと考えています。

--
component(GlassBean.class).property("content")
--

型の安全性 vs 記述量と可読性というトレードオフの問題ですね。

Injectorのインタフェースは昨日の案の通り変更するつもりです。
特殊なInjectionをしたいときは昨日のコード例みたいな感じで書く
ことになります。匿名内部クラスの生成コード書くのはうっとおしい
ですが、IDEのコードテンプレートの機能とかをうまく使うと多少
マシになるのではないかと考えています。

ついでにInjectionのタイミングも、インスタンス生成直後に問答無用で
Injectしてしまうのではなくして、相互依存するコンポーネントを
setter injectionでinjectできるようにしたいと考えています。
そうすることによって、後々いろいろといいことがありそうなんです。

かなりの大手術になりますが。

仕様変更素案

自分の書いたコードをオープンソースとして世間に公表したのは
この LiQ Contaienr がほぼ初めてですが、ポジティブなものであれ、ネガティブな
ものであれ、なんらかの反応がいただけるのは大変ありがたいことだと思います。
一つ一つのご意見が本当に参考になるし、自分のなかでまた新しい考えが
生まれてきます。

そして書きたいことがとても一つのエントリでは書ききれないほど
あふれてきます。

さて、いろいろなご意見にインスパイアされた結果、setter injection
の定義方法を次のようなイメージに変更しようという考えに至りました。

 
--- 
public void BeverageModule extends AbstractModule { 
    public void moduleDef() { 
        component(Water.class); 
        component(GrassBean.class) 
            .injector(
                new Injector<GrassBean>() {
                    public void inject(GrassBean bean) {
                        bean.setContent(using(Beverage.class));
                    }
                }
            );
    }
}
---

これで、プロパティを文字列で参照しなくてもよくなるし、
単なるsetter injection以外のいろいろなinjectionが一つの仕掛けで
実現できるようになります。
めちゃめちゃタイピング量増えてるじゃんか!
というおしかりはごもっともです。素直にあやまります。

ですが、私はもともと constructor injection派で、setter injectionは
本当にたまにしか使いません。
LiQ Containerも基本は constructor injectionが楽になるように作ってあります。

なので、setter 派の人には本当に申し訳ないのですが、
私的にはこれでもあんまり不満はないのです。
(とはいえ、本当はここでクロージャが欲しいところです。Dolphinで
クロージャが導入されることを期待してます)

むしろ、たまにしか使わない機能のための、めんどくさい introspection の
コードを一掃できてすっきりしますし、
何も削るものがないところまで無駄を省いて、緊張感を作り出す
というわび茶の精神にも合致します。

私が LiQ Container でやりたいのは、「DIコンテナの設定をJavaで書く」、
ということも確かにあるんですけど、「実はDIコンテナはもっと小さくても十分機能するのでは」
という仮説を検証することも同じくらい重要なのです。
最初の動機はJavaで設定書きたいっていうことだったんですけど、
LiQっていう名前を付けた瞬間から、実装をコンパクトにして、
必要最小限の機能だけをサポートする方向に大きく舵が切られましたね。
Javaで設定書いたほうがXMLとかで書くより実装を小さくできるという風に、
目的と手段がごっちゃになってしまった感じです。

最近、ライブラリとかフレームワークにとって重要なのは
十分にシンプルで、「理解できる」っていう安心感があることなんじゃないかと
思っています。「理解しがたい」フレームワークに依存することはプロジェクトにとってリスク
になると思います。

最初からそう考えてLiQを作りはじめたんではなくて、
LiQって名前つけて、シンプルなコンテナにしようと努力しはじめてからそう
考えるようになりました。

やっぱ名前重要です。

話は変わりますが、「設定が楽」だけではなく、「コンテナの使い方が簡単」
も実はアピールしたいポイントだったりします。
上の例の BeverageModule から、GlassBean.classのインスタンスを取り出すのは
以下のようにします。

---
BeverageModule module = new BeverageModule();
GrassBean bean = module.getInstance(GrassBean.class);
---

自分では、この「設定をnew してすぐ使える」ってところが
意外に気に入ってるんですけどね。

Moduleになんかインターフェース実装させて、それ自体を他のModuleに
コンポーネントとして登録したりとか、簡単にできます。

お答えします

なぜか2chのSeasarスレにLiQ Containerの微妙な
フィードバックのようなものが。。。

>>341
LiQってAOPサポートしてないのか？

サポートしてません。今後も多分サポートしないでしょう。
以前AOP的な機能を実装してみたことがあるのですが、
仕様も実装も複雑になりすぎるので、泣きながら削除した、という経緯があります。
どうも私にはAOPというのはむずかしすぎるようです。
AOPをサポートするコンテナをお求めの方はS2かSpringをどうぞ。

>>348
この作者クラス名は文字列で書けねーのにプロパティ名は平気なのか？

平気なわけありません。凄く嫌です。でもこればっかりは
他にどうしようもないのではないでしょうか。
いろいろ考えたんですが、他に良いアイデアがでず。。

もう一ひねり欲しいな。
すいません。精進します。


ここで他のコンポーネントのプロパティを明示的に設定する方法が分かんね。
自分でコンポーネント取ってきてPropertyDependencyに食わせるのか？
moduleDef()の中でそんなことするわけねーか。

鋭い。。。
いまのところ、他のコンポーネントのプロパティを明示的にInjectする
方法は提供していません。これを実現するには自分でそういう
Dependencyを作る必要があります。
いくらシンプルが売りっていっても、このくらいはコアの機能として提供
しても罰はあたらないんじゃないかと思いますので、
alpha2には組み込む方向で考えたいと思います。

ちなみに、おっしゃる通りmoduleDef()のなかで自分でコンポーネントとってくるのは
反則です...

>>350
LiQClickとかLiQDaoとか予定あるんかな？

LiQ Containerの回りにそういう周辺フレームワークを作りたい気持ちは
大いにあります。
ちなみにまえLiQからS2Daoを使おうと試みたら、S2Frameworkが依存関係
としてくっついてきてしまうという事態が発生しました。
S2DaoをS2Frameworkに統合する計画があるようですが、分けて使いたい
人も少数ながらいる、ということも少し気にして欲しいですなぁ。

間違ってもKatsuraとかHamaなんて名前にはしないでくれよ

LiQの語源は離宮ではなく、利休なので、そのようなことには
ならないと思われます。