January 09, 2005

Hibernateの本がオライリーから出たというので、ジュンクに行った。

Hibernateの本（Hibernate 開発者ノートシリーズ）は会社の金で買っておいて、思わず心引かれて自腹で購入したのは、軽快なJava

過去のエントリに書いてあることですが、えふしん的に、いろいろ疑問点として思ったこと。

・EJBの概念は、EJBの本を読んでも理解できんかった。何でこんなのがもてはやされるんだろうか。（まーいきなり、スタブがどうのこうのから説明する本のあり方もどうかとは思いましたが。書いてるほうが、人に物を教えることを理解してない本だったと思う。）
・SOAPって、WDSLとかが間にあってややこしいなぁ。うまく通信できないときのトラブルシュートがややこしくない？
・XMLスキーマとかXSLとかのXML技術って複雑極まりないけど、役に立つの？そこまでやるなら、使い慣れたスクリプト言語で生成するのでいいんじゃないの？
・Strutsとかって理解するためのコストがかかって大変。フレームワーク製品の最大のポイントは「普及してること」こそが重要ですわ。
・セマンティックなコードであるSQLを構築するために、文字列処理としてSQLを構築するプログラムを毎度毎度書くのってバカバカしい。クォーテーション忘れでエラーが出たりしたら、ためいきが出る。
・厳密なUMLって書いてどれほどのメリットがあるの？文章＋フローチャートじゃダメなの？良いとこ取りで都合の良さそうな使い方はするけど、ツールには怒られてばっかり。
・メモリ１GBも積んでないと動かないアプリケーションサーバ製品
・デザインパターンって、自分のものになってないと話がややこしくなるね。自分が使うのって何種類もないなぁ。（まぁ先人の知恵ですからね。）

逆にシンプルで良いなぁと気に入っているのは、

・XML-RPC（SOAPの前身だそうですが、このぐらいが丁度良い）
・RSS
・O-Rマッピング（でも簡単なのじゃないと意味ない）
・Apache Commons

なんか矛盾してるし、こいつバカだよとか言われても、面倒と思ってるものは面倒なので開き直りますが、例えば大規模な開発には必須だよと言うのであれば、ややこしいと思ってるものが大規模な開発で使われたらもっとややこしいんじゃないの？とか思うわけです。

でも好意的に言って、僕が関わる仕事の範囲で単純に不要なだけでしょう。例えばSOAPやXML Schemeの厳密性は必要とするシーンがあればこそ必要であって、自前サーバアプリと自前のFlashで通信するだけなら、DTDやXML-RPCすら不要で、Excelの表で書いておけば済むレベルだったりするからです。

しかし、つまるところ開発する内容やシーンや規模によって、良いともてはやされているがちっとも良くなかったりするわけです。

でも今あるトレンドのテクノロジで、自分にとって何が無駄で何が最適か、その場で判断するのはなかなか難しい。実際、採用して使いはじめてから後悔することもあるでしょう。この本は、その辺のJavaのテクノロジの「真実」を描いています。結構、面白い本だと思います。

特にフレームワーク等、継続的なメンテやカスタマイズを前提にしたアーキテクチャを設計する人におすすめ。何がプロダクトにとって必要であるか、また余計なものを捨ててシンプルにすべきかの参考になることでしょう。著者は「アンチパターン」の本を書いた人だそうです。納得ですね。