コーディングの掟/arton, 宇野るいも

artonさんに昼の宇野るいもさんに助けてもらった話を書いたら、artonさんのブログからリンクされてしまいまいした。「ファンです」と書いたエントリなのでちと恥ずかしい。

そのエントリにはartonさんとるいもさんのコンビで書かれた数々の本が並べてありました。artonさんの本はRailsの本やC#の本(眺めただけだけ)は買ったことがあるのですが、もちろんるいもさんと組む以上はJavaの本なのです。

とはいえ、最近は自分がインフラとして保守で関わっているアプリケーションのメモリアロケーション時のスタックトレースから遡って

String str = "";
Iterator hmit = hm.keySet().iterator();
Object obj;
while(hmit.hasNext()) {
    obj = hmit.next();
    if(hmit.hasNext()){
        str += "'" + obj.toString() + "',";
    }else{
        str += "'" + obj.toString() + "'";
    }
}

のようなアポなコードを見つけて鉄槌を下す(自分では直さない。なぜなら私は(少なくとも、公式には)Javaが書けない人だから)というようなのが仕事だったりするので、Javaを全く知らないというのも許されません。

でも、Cでプログラミングとメモリ操作について学び、VB2でGUIプログラミングに触れ、Delphiで本格的なオブジェクト指向と(VCLで)クラスライブラリの設計について学んだ末に、1.4の時代からRubyistになった私にとって、JavaはシステムプログラミングをするにはCに及ばず、GUIを作るにはVBに及ばず、言語とクラスライブラリの美しさでDelphiに及ばず、生産性でRubyと勝負にもならないという「学ぶ気ゼロ」言語だったりするわけです。何せ、上のコードはRubyで書けば

str = hm.keys.map{|a| "'#{a}'" }.join(",")

で終わってしまうわけで、なんでわざわざやりづらい方法を学ぶのかと。

と言いつつ、素のJavaはともかくServlet(というかJavaEE？)とJDBCはやはりメリットの多いシステムだと思います。Strutsも加えてもいいかもしれません。こいつらはちゃんと勉強しないとなあと思ってます。

というわけで、この機にお二人の本を・・・といいつつ一番楽しく読めそうな「コーディングの掟」を読みました。とにかく、

例外とマルチスレッドは(いろんな意味で)難しい

ということはよくわかりました(笑)

参考になったのは、Servletを使うからにはマルチスレッドにならざるを得ないよという辺りです。マルチスレッドを意識するときには、スレッドセーフであるとか、同期だとか、ロックだとかをうんうん考えるより、そもそもオブジェクトのスコープをちゃんと意識するということが大事だというのは、目から鱗です。Servletにおいて、「ThreadLocal＝スコープがリクエスト単位」というのはちゃんとわかってませんでした。

Javaアプリケーションサーバの世界においてスコープを考えると

• アプリケーション全体
• サーバ
• セッション
• リクエスト

のような、Webアプリケーションとして自然なスコープがあるはずで、それとJavaのコードがどう対応するのかきちっと理解できていないなあというのが感想です。アプリケーション全体はDBで永続化されるべきで、セッションはセッションオブジェクトだから明確ですが、残りをどこに記述しておくのが正しいのか、どこに書かれる可能性があるのかは整理されていないと困りますよね。