8.08.2005
7.31.2005
例外設計の要諦をつかむ
JavaWorld9月号の記事で「例外設計の要諦をつかむ」という記事がある。
迷わず買いです。
特に面白いというか、役に立つのが「EJBにおける例外処理」である。
実際、ここ1ヶ月EJBのXAExceptionに悩まされおりEJBの例外発生時のコンテナの振る舞いについて勉強が足りないなーと感じていた矢先の記事だったので飛びついてしまった。
具体的には、EJBにおけるアプリケーション例外、システム例外発生時にクライアントはどのように対処すべきか、そしてコンテナはどのようにトランザクションを処理するかが書かれている。
多少、日本語がわかりづらいが非常に役に立った。
ただ、ユーザー定義例外の設計原則においてRuntimeExceptionを継承してExceptionを作るべきではないという部分には、若干疑問が残る。
例えば記事の中では、FileNotFoundExceptionにはIOExceptionがあるように上位クラスではスーパークラスでキャストしてカテゴリーごとに対処すべきだと言っている。
しかし、現実的じゃないような気がする。
例えばSQLExceptionって、ロックタイムアウトや重複時の例外以外ってRDBのエラーだったりするわけである。つまり回復なんぞおお無理なわけだから、通常の例外にされると他のクラス設計によからぬ影響を残す気がする。
だもんで、Model部分でキャッチしてログを出した後にRuntimeExceptionでthrowしてしまうほうが良いのではないだろうか?という事である。
ただ、この辺が不勉強なところで、EJBコンテナにおいてはどうもRuntimeExceptionしたときの振る舞いが判然としない。
-------
ちなみに、DB2でXA利用時にLocktimeOutのSQLExceptionが出ると、キャッチして握りつぶしてもXAResourceがXA_RBDEADLOCKによってendできないのは仕様なのだろうか?DBにはちゃんと反映されているんだけどなー。
そもそもLocktimeOutが発生した時点で、だめってことなのかな?
迷わず買いです。
- 例外の基本
- ユーザー定義例外の設計原則
- EJBにおける例外処理
特に面白いというか、役に立つのが「EJBにおける例外処理」である。
実際、ここ1ヶ月EJBのXAExceptionに悩まされおりEJBの例外発生時のコンテナの振る舞いについて勉強が足りないなーと感じていた矢先の記事だったので飛びついてしまった。
具体的には、EJBにおけるアプリケーション例外、システム例外発生時にクライアントはどのように対処すべきか、そしてコンテナはどのようにトランザクションを処理するかが書かれている。
多少、日本語がわかりづらいが非常に役に立った。
ただ、ユーザー定義例外の設計原則においてRuntimeExceptionを継承してExceptionを作るべきではないという部分には、若干疑問が残る。
例えば記事の中では、FileNotFoundExceptionにはIOExceptionがあるように上位クラスではスーパークラスでキャストしてカテゴリーごとに対処すべきだと言っている。
しかし、現実的じゃないような気がする。
例えばSQLExceptionって、ロックタイムアウトや重複時の例外以外ってRDBのエラーだったりするわけである。つまり回復なんぞおお無理なわけだから、通常の例外にされると他のクラス設計によからぬ影響を残す気がする。
だもんで、Model部分でキャッチしてログを出した後にRuntimeExceptionでthrowしてしまうほうが良いのではないだろうか?という事である。
ただ、この辺が不勉強なところで、EJBコンテナにおいてはどうもRuntimeExceptionしたときの振る舞いが判然としない。
-------
ちなみに、DB2でXA利用時にLocktimeOutのSQLExceptionが出ると、キャッチして握りつぶしてもXAResourceがXA_RBDEADLOCKによってendできないのは仕様なのだろうか?DBにはちゃんと反映されているんだけどなー。
そもそもLocktimeOutが発生した時点で、だめってことなのかな?
7.30.2005
FC4ぶっ壊れた・・・
FedoraCore4がぶっ壊れた。
正確にいうと、GDMでroot以外でログインできなくなってしまった。
原因は不明だが、ある日リモートからXDMCPでログインしてみたら、ログインしたあとすぐにログアウトされてしまう。
おかしいと思って、本体でログインしたら
って、言われちゃう。
ちょっと調べてみると同じ現象に遭遇している人はいるものの、掲示板で放置プレイ。
しかも原因がいろいろあるっぽい。
http://cvs.gnome.org/viewcvs/gdm2/po/ja.po?rev=1.30
のサイトから英語のメッセージを調べ、それで探してもいまいち原因がわからない。
そろそろ1週間になるのであきらめて、WBEL4に乗り換え決定!
正確にいうと、GDMでroot以外でログインできなくなってしまった。
原因は不明だが、ある日リモートからXDMCPでログインしてみたら、ログインしたあとすぐにログアウトされてしまう。
おかしいと思って、本体でログインしたら
あなたのセッションは10秒以上続きませんでした。もしあなた自身の手でログアウトしたのでなければ、インストールの問題があるか、ディスクスペースが足 りないか、ということを意味します。フェイルセーフなセッションからログインしてみて、この問題を解決できるかどうか確認してください
って、言われちゃう。
ちょっと調べてみると同じ現象に遭遇している人はいるものの、掲示板で放置プレイ。
しかも原因がいろいろあるっぽい。
http://cvs.gnome.org/viewcvs/gdm2/po/ja.po?rev=1.30
のサイトから英語のメッセージを調べ、それで探してもいまいち原因がわからない。
そろそろ1週間になるのであきらめて、WBEL4に乗り換え決定!
7.29.2005
技術革新の足を引っ張るな
この著作権の権利団体というのが、いまいち既得権益団体にしか見えない。
日本のオンラインコンテンツの流通を妨げてるのは、やつらでは・・・・
速やかに「iPod課金」を――音楽関係7団体が強く要望
http://www.itmedia.co.jp/lifestyle/articles/0507/28/news106.html
日本のオンラインコンテンツの流通を妨げてるのは、やつらでは・・・・
速やかに「iPod課金」を――音楽関係7団体が強く要望
http://www.itmedia.co.jp/lifestyle/articles/0507/28/news106.html
7.02.2005
おっ、Geronimo来るか?
アパッチ族の大酋長の名を冠するオープンソースJ2EE実装「Geronimo」、開発開始から2年、満を持していよいよ登場するかもしれない。
果たして昨今の軽量コンテナブームを押しのけて存在感をアピールできるか!?
実際問題、中立的であるApacheからJ2EE互換コンテナがリリースされるのは非常に喜ばしい。
兼ねてより、私はJ2EEを習得するに当たり、その仕様の複雑性よりももっと大きな問題があると思っている。
その問題とは、J2EEを始めようとしたときに何から手をつけてよいのかまったくわからいということである(少なくとも私は・・・)。
例 えば代表的な製品でIBMのWebSphere、BEAのWebLogic、SunのSunOne(もう名前変わりすぎて覚えてないヨ)、JBossな どがあるが、どれを触ってみてもどこからがベンダ固有で、どこからがJ2EEの仕様なのかがわからないのである。それゆえ、苦労して覚えても役に立たない のではないかという不安に襲われるのである。かくして初心者は、その不安とJ2EE特有の複雑性・・・もとい芸術性により、かのEJBを語るとき遠い目を してしまうのである。
つまりGeronimoの意義とは、かつてサーブレット開発者がTomcatを学ぶことによって各ベンダのサーバに適応していったように、J2EEコンテナにおける標準スキルパスを用意することにあると思う。
是非、Tomcatと同様にGeronimoがJ2EEコンテナのデファクトスタンダードになってくれることを望みたい。
Apache Geronimo公式サイト
http://geronimo.apache.org/
developerWorks - Apache Geronimo resources
http://www-128.ibm.com/developerworks
/opensource/top-projects/geronimo.html
アパッチの「Geronimo」プロジェクト、Java互換性試験に合格
http://japan.cnet.com/news/media/story/0,2000047715,20084928,00.htm
果たして昨今の軽量コンテナブームを押しのけて存在感をアピールできるか!?
実際問題、中立的であるApacheからJ2EE互換コンテナがリリースされるのは非常に喜ばしい。
兼ねてより、私はJ2EEを習得するに当たり、その仕様の複雑性よりももっと大きな問題があると思っている。
その問題とは、J2EEを始めようとしたときに何から手をつけてよいのかまったくわからいということである(少なくとも私は・・・)。
例 えば代表的な製品でIBMのWebSphere、BEAのWebLogic、SunのSunOne(もう名前変わりすぎて覚えてないヨ)、JBossな どがあるが、どれを触ってみてもどこからがベンダ固有で、どこからがJ2EEの仕様なのかがわからないのである。それゆえ、苦労して覚えても役に立たない のではないかという不安に襲われるのである。かくして初心者は、その不安とJ2EE特有の複雑性・・・もとい芸術性により、かのEJBを語るとき遠い目を してしまうのである。
つまりGeronimoの意義とは、かつてサーブレット開発者がTomcatを学ぶことによって各ベンダのサーバに適応していったように、J2EEコンテナにおける標準スキルパスを用意することにあると思う。
是非、Tomcatと同様にGeronimoがJ2EEコンテナのデファクトスタンダードになってくれることを望みたい。
Apache Geronimo公式サイト
http://geronimo.apache.org/
developerWorks - Apache Geronimo resources
http://www-128.ibm.com/developerworks
/opensource/top-projects/geronimo.html
アパッチの「Geronimo」プロジェクト、Java互換性試験に合格
http://japan.cnet.com/news/media/story/0,2000047715,20084928,00.htm
さーて、じぇねりっくす時代が始まるざーんす!
Eclipse3.1正式リリース!!!
http://eclipse.org/
Eclipse3.1のJDTがフルサポートするJDK1.5(J2SE5.0)は、Genericsプログラミング、Annotation、enum型 サポート、Autoboxing、拡張for文など数多くの言語仕様拡張とThread制御周りを初めとするAPIの大幅な強化により別言語といっても良 いと思う。
これらの非常にエキサイティングな拡張は、新たなコーディングスタイルやプログラミングパターン、設計ノウハウをもたらすに違いない。
これからのことを考えると、ワクワクするなぁ~~!
ああっ、生まれてきて良かった。
http://eclipse.org/
Eclipse3.1のJDTがフルサポートするJDK1.5(J2SE5.0)は、Genericsプログラミング、Annotation、enum型 サポート、Autoboxing、拡張for文など数多くの言語仕様拡張とThread制御周りを初めとするAPIの大幅な強化により別言語といっても良 いと思う。
これらの非常にエキサイティングな拡張は、新たなコーディングス
これからのことを考えると、ワクワクするなぁ~~!
ああっ、生まれてきて良かった。
6.30.2005
LAMPの使いどころ。またはJavaを如何に愛しているか・・・
プロフィールでも書いている通り、私自身は向学やリプレースのためにPerlやPHPのコードを追った以外は、実際のLAMPを殆どを知らない。
しかしながら、CNETの記事(文末参照)における
正直、鼻血が出るような値段である。ちなみにブルジョワ向けJ2EEセットであるOracle&Weblogicでは3LDKマンションの頭金ぐらいにはなるであろうと思われる。
一方でLAMPの代表的組み合わせのApache、PHP、MySqlトリオは無料である。それなりの技術は必要だろうが経験豊かな人間が居れば設定なんぞ鼻くそであろう。
ここで、LAMP擁護者は得意気に勝利を宣言するのであるが、ちょっと待って欲しい。以下の点に留意してもう一度コストを計算してみよう。
するとどうだろう、LAMPのコスト的優位は特に無いのではないだろうか?
その上で、LAMPとJ2EE(もちろんEJBを除く)について考えてみよう。私の私見ではLAMPの特徴とは
であり、J2EEの特徴とは
であると思う。
上記から、私が導き出した使いどころは
環境構築の容易さについては説明も必要ないと思うが、Tomcatだけであればhttpd.confと格闘する必要もないし、mod_???の設定やphp、Perl、CGIの設定も必要ない。持ち帰りや分散開発が多いSI業界において実働環境を殆ど意識せずにWindowsPC上(別にLinuxでもOsXでも良いが・・・)で開発できてしまうのは大きなアドバンテージである。
そして、TomcatはどのOSに対しても、まったく同じバイナリが提供されているため通常はどのOSでも同じ振る舞いを示す。(Java実行環境はOSごとに違うが・・・)
さらに、ServletやJSPの仕様は過去数回のリリースにおいてコンテキストなどの取り扱いが一貫しており、仕様が安定している。例えばJ2EE1.2で動作したサーブレットは基本的にJ2EE1.4でも動作する。
最 後に、逆手に取るようではあるが、動的型付け言語ではないことで手軽さが失われる半面、保障された型変換を行うことが出来る。少なくとも数値用の フィールドに誤ってシングルクォートが入っていたときに文字列として扱い見逃す危険性はまずない。(実行時例外は出るかもしれないが、SQLインジェク ションはされない)
とJavaの利点ばかりあげたが、それでもコンシューマ向けや、手軽なサイト構築、複雑なトランザクション処理が必要ないWEBアプリケーションであればわざわざJavaにこだわる必要もないと思う。
なぜなら、ただのアンケートサイトであればPHPなどLAMPで作りこんだほうが、遥かに早く完成するのを見せ付けられたからである。
参考:
注目集める「LAMP」--Javaや.NETに次ぐ第3の潮流になるか
http://japan.cnet.com/news/ent/story/0,2000047623,20084497-2,00.htm
しかしながら、CNETの記事(文末参照)における
「Java は古い型の言語で、それほど優れたものだとは考えていない。IBMの『WebSphere』やBEA Systemsの『WebLogic』を稼働させるのに、いったいいくら投資しなければならないか、考えてみてほしい。Javaは、開発資金を際限なく引 き出す存在なのだ」という部分に関しては、(Javaが古い型の言語であるという点を除いて)まったくその通りであると言える。例えば、インターネット経由で利用するWEBシステムを構築するときにIBMの代表的なミドルウェアを利用するとしよう。
- IBM DB2 (583,485円)
- IBM WebSphereAP Express V6.0 (262,500円)
正直、鼻血が出るような値段である。ちなみにブルジョワ向けJ2EEセットであるOracle&Weblogicでは3LDKマンションの頭金ぐらいにはなるであろうと思われる。
一方でLAMPの代表的組み合わせのApache、PHP、MySqlトリオは無料である。それなりの技術は必要だろうが経験豊かな人間が居れば設定なんぞ鼻くそであろう。
ここで、LAMP擁護者は得意気に勝利を宣言するのであるが、ちょっと待って欲しい。以下の点に留意してもう一度コストを計算してみよう。
- MySqlはJ2EEで利用してはいけないという決まりはない
- J2EE without EJBという選択を行った場合、APには無償でありオープンである我らがTomcatがある
するとどうだろう、LAMPのコスト的優位は特に無いのではないだろうか?
その上で、LAMPとJ2EE(もちろんEJBを除く)について考えてみよう。私の私見ではLAMPの特徴とは
- 動的型付け言語であり、スクリプトで記述でき手軽で高速である。
- 静的型付け言語であり、コンパイルが必須であるがポータビリティが高い。
上記から、私が導き出した使いどころは
- LAMPは迅速な構築や、デザイナーと協業するコンシューマ市場向けWEBサイトの構築に向いている。
- Javaは環境非依存性やMVCの高度な分離(WEB層、ロジック層、エンティティ層)を必要とするエンタープライズアプリケーションの構築に向いている。
- 環境構築の容易さ(EJB抜き)
- OSにほぼ完全に依存しない振る舞い
- 過去数バージョンにおける安定した仕様
- 動的型付け言語ではない
環境構築の容易さについては説明も必要ないと思うが、Tomcatだけであればhttpd.confと格闘する必要もないし、mod_???の設定やphp、Perl、CGIの設定も必要ない。持ち帰りや分散開発が多いSI業界において実働環境を殆ど意識せずにWindowsPC上(別にLinuxでもOsXでも良いが・・・)で開発できてしまうのは大きなアドバンテージである。
そして、TomcatはどのOSに対しても、まったく同じバイナリが提供されているため通常はどのOSでも同じ振る舞いを示す。(Java実行環境はOSごとに違うが・・・)
さらに、ServletやJSPの仕様は過去数回のリリースにおいてコンテキストなどの取り扱いが一貫しており、仕様が安定している。例えばJ2EE1.2で動作したサーブレットは基本的にJ2EE1.4でも動作する。
最 後に、逆手に取るようではあるが、動的型付け言語ではないことで手軽さが失われる半面、保障された型変換を行うことが出来る。少なくとも数値用の フィールドに誤ってシングルクォートが入っていたときに文字列として扱い見逃す危険性はまずない。(実行時例外は出るかもしれないが、SQLインジェク ションはされない)
とJavaの利点ばかりあげたが、それでもコンシューマ向けや、手軽なサイト構築、複雑なトランザクション処理が必要ないWEBアプリケーションであればわざわざJavaにこだわる必要もないと思う。
なぜなら、ただのアンケートサイトであればPHPなどLAMPで作りこんだほうが、遥かに早く完成するのを見せ付けられたからである。
参考:
注目集める「LAMP」--Javaや.NETに次ぐ第3の潮流になるか
http://japan.cnet.com/news/ent/story/0,2000047623,20084497-2,00.htm


