Blog/2010-05-16

何度も何度も †

韓国潜水艦沈没
http://tanakanews.com/100507korea.htm
ホントかなあ。なんか米原潜の事を極秘にする理由が薄い気がするんだけど。

Unicode絵文字のgoogle提案、あれ本気みたいね。
http://japan.cnet.com/column/pers/media/story/0,2000058034,20394318,00.htm
http://japan.cnet.com/column/pers/media/story/0,2000058034,20398174,00.htm
ソース分離っていうのを読み間違えて日本の各キャリアごとに絵文字が割り振られるのかと思ったけど、そうではないみたい。それならまあいいか。こうやって議論の棚にあがってこなれた文字セットとなって、携帯各社もUnicode絵文字に対応してくれれば今後はキャリア間の絵文字変換とかも考えなくていいわけだし、これはいいかもしれない。

Java周りのテクノロジーが多すぎると思う。
Hibernate,Torque,iBATIS,Spring,guice,struts,struts2,SpringMVC,Velocity,MyFaces?....
いったいいくつ覚えていくつ忘れていくんだろう。TorqueとかStruts Tilesとか二度と使わないと思う。そんで最近の流行はSeamですか・・。ajaxまわりだってprototype.jsにjQueryから始まって、Google GWTやらAdobe spryやら。確かに新しいのが出るたびに 今までに無いウリがあって、そこだけ注目すれば確かに便利そうだけど、実際に触るとやっぱりいろいろ手こずる事がでてくる。

やりたいのは最新のアーキテクチャに触れる事じゃない、お客さんの笑顔が見たいんだ。そのためにはこんなテクノロジーを覚えるために時間を割くんじゃなくて、シンプルで拡張しやすいシステムを作ることに頭と時間を使いたい。お客さんの要望があったらすぐ機能追加できるようにしたい。10年20年使える決定的なフレームワークはでないものか。日本だとstrutsを使い続けるところが多いんだろうなあ。

自分で作ってメンテなんて面倒だけど、延々と勉強させられるよりはマシかなあ。springのDI、sturts2のアクションベースコントローラーとDynamicMethodInvocation?と後なにがいるだろう。DB周りはJDBCの知識があれば新しいことを覚える必要が無いようにしたい。ボトルネックになるのはDBだしSQL直書きでチューニングできないようなのは避けたいし。ViewはとりあえずjspにJSTLとカスタムタグを入れつつスクリプトレットを許可するかな。スクリプトレット排除の為にActionで表示する文字列を作成するとかMVCの概念から外れてるし、Viewには表示用ロジックを入れる余地は必要だと思う。一つのjspでしか使わないのを全部カスタムタグにするのは手間が増えるだけだし。

POJOはいい。継承しまくりでsuperクラスいっぱいたどらないとなにをしてるかわからないよりは全然いい。でも今のPOJOブームはどうなんだ。クラスのメタデータ参照してリフレクトで呼び出すとか、「いつどこでどうやって呼ばれるか」が見えないから結局継承の時より可読性が落ちてる。

いつも思うのは頭のいい人っていうのはいつの時代も一握りで、構造化の時代は構造化の枠内ですごく読みやすいソースを書く人が居たし、今の時代でもすごいなと思うソースを書く人は一握りしか居ない。OOだ委譲だPOJOだとかで古いアーキテクチャをけなす人はいるけど、確かに今の技術がなければ大規模システムの実現はすごく面倒になるけど、結局のところ目的を達成するための道具でしか無くて、道具の良し悪しでどうこう悩むより、成果物の精度を上げるために時間を費やしたい。


タグ：雑談