khara@fmsc's weblog

先日、チームのメンバーと昼ご飯を食べていて少し話しに出てきた内容を、このブログに関心を寄せて頂いた読者の方々に伝えたいと思い、なんとか記事にしてみたい。上手く伝わるかどうか心配ですが...

我々は、JAVAの基盤系技術に強く、J2EEの初期アーキテクチャから、様々な会社のフレームワークを見てきたし、最近で言えばオープンソース系ってところもです。この業界、もっと絞って言うなれば、Java開発のフレームワーク技術については、次々と目新しいものが登場してくる。少し前で言えば、DI（Dependency Injection）+AOP（Aspect Oriented Programming）だとか、JSF(Java Server Faces)だの、CoC（Convention Over Configuration：設定より規約）だとか。JPA（Java Persistent API）だとか、アノテーションでメタ情報とか。ちょっと分野が違いますが、Ruby on Railsとかね。

次々と登場してくる新しい話題と技術。我々専門家としては相応に消化して取り入れていく訳ですが、この急速な変化と言うか、昨日はこっちで明日はあっちみたいな思想の流れ、そして多次元に広がる流れに、真に付いて行けている開発技術者がどれだけいるのか、振り回されているだけではないのか、と言う疑念が生じてきます。現場でも、その技術を理解しているしていないとかの問題ではなく、思想としてポリシーとしてそれで良いのかって、首を傾げたくなるシーンも多く見受けられます。つまり、上手く消化できていなかったり、必要でないのに捨て切れていなかったり、見合っていないのに取り入れたり、その技術概念に取り付かれて広い視野で物事が見れなくなっていたり、ってのを感じることがあります。これは今の状況に限ったことではなく、永遠の論議であり教え事でもありますが。

別の表現を試みて見ましょう。いわゆる「state of the art」(最新の技術)を全てかき集めて、今のマーケット的に話題で流行の技術をベースに開発しようとしています。ひょっとしたら１つや２つぐらいは試してみたい新しい要素もおそらく取り入れていることでしょう。あるいは、ベンダーのマーケッターが、これからはこれですよって、耳元で囁いているかも知れません。さて、あなたは、いや、あなたのチームには、これらの目まぐるしく変わる最新の技術要素を吸収して身につけているエンジニアがどれだけいるでしょうか。そして、どのように取り組めば良いのでしょうか。昔、とあるお客さん曰く、「自分が１０人とか２０人いればそのような方式でやるだろうけど、そうじゃないので、こういう方式にしてある」と信念を持って話してたお客さんもいらっしゃりました。おそらく、最新の技術や話題の技術に重点ポイントがあるのではなく、業務を知っていたり、自社の要員とか力量であったりとか。あるいはまた、物事を難しくしないでシンプルにするってことでもあります。その分、他のことに気が回りだします。そして、それが一番生産性が高く発揮できたり品質が良かったりするわけですね。技術的には、最新のセクシーな感じではなく、オーソドックスなスタイルとでも言いましょうか。もちろん、レガシー技術を例えているわけではなく、どれもJavaベースの話ですよ。

日々、目新しく登場する技術や人を魅了する話題など、急速な変化と情報の流れの中、すべてを飲み込んで取り入れて消化するリソースもないと思うのです。古い技術のままの居場所にずっと留まっているのは死を意味する一方で、少しでも最新の技術を採用したいとか最新技術のオープンソースを組み合わせてという思想も理解出来る一方で、そんな両極端なものではなく、どちらかというと、技術的に「ゆったりとした流れを創る」というような設計思想というか、そういう方針で取り組まれてもよろしいんじゃないでしょうか。

生産性を上げるとか品質を上げるイコール、最新の技術を使うということではありませんし、ベースとなる設計思想やフレームワークの頻繁な乗り換えには疑問です。確かに新しい流行には楽しい要素があり技術者としてエキサイティングな面はあるのですが、ソフトウェアの生産性や品質を上げるためには、目まぐるしい急速な変化の中で、自社あるいはプロジェクトに見合ったゆったりとした流れを意図的に創ることも重要でしょう。これを標準化と言う言葉で表現することも出来ることでしょう。じっと動かないのではないですよ、ゆったりとした流れを創るのです。特に技術要素の乱立・乱用気味の昨今の流れの中、このような考え方も重要なのではないでしょうか。

Webサービスを調べる機会があったので、少し記事にしてアップしておきます。

当然、Amazonを調べて参考にするわけで、次に楽天あたりを参考にするわけですが。

AmazonがWebサービスとして、SOAPとRESTを採用しているのはご存知の通りですが、その利用の85%はRESTって話みたいです。その他、大勢がRESTだけなんですね。もう少しSOAPとRESTの両方提供するところがあっても良いと思っていましたが、そういう流れなのでしょう。

それはさておき、楽天APIでJSONがサポートされるようになっていました。これも流れでしょうか。

http://webservice.rakuten.co.jp/api/itemsearch/

リクエストパラメータからXMLがなくなり、レスポンスもXMLじゃなくなってしまうのでしょうか。
javascriptやAJAXの世界では既にそうなんでしょうが、サーバーサイドも含めて、データ構造の表現がJSONに置き代わっていく可能性もありますね。

最近、XMLがどんどん使われなくなっていくような気がするのは私だけでしょうか。
Webサービスに限らず、Javaの世界でも複雑なXML設定を記述しなければいけないのを避ける流れにありますしね。さて、XMLは、いずこに？

以上、ちょっと気に止まったので、記事にしてみました。

jaba言語に関する記事です。いわゆる「java」言語ではなく、「jaba」プログラミングに関する記事です。

さて、読者の皆さんは、このブログ記事には、どのようにして、たどり着きましたか？

Googleとかの検索エンジンから来られたのであれば、見事にSEO対策に嵌っています。

タイプミスとか、漢字の誤変換を狙って、検索エンジンの上位表示を狙うって手法です。

そうです。このブログでちょっと実験してるわけです。悪意はございませんのでお許し下さい。

さて、何位に上位ランキングされるでしょうか？その持続期間は？

javaをjabaで間違えることはそう多くないでしょうが、では、無線ＬＡＮ内臓パソコンとかね。
間違いに気付きましたか？これに関しては、下の記事でも読んで見て下さい。

「湯に黒」をただの誤変換と侮るなかれ

以上、失礼しました。

なんらかのテンプレートから、ソースとか設定ファイルを自動生成したい場合が良くありますよね。本格的にやるならコード生成プログラムを書いたりするのでしょうが、単純なものならantのcopyタスクでフィルター(filterset/filter)を使えば、コピーする際に文字列置き換えしてくれるので、簡単な自動生成が実現出来ます。

<copy overwrite="yes" todir="${to.dir}" >
  <fileset dir="${template.dir}">
    <include name="**/*.*"/>
  </fileset>
  <filterset>
    <filtersfile file="build.properties"/>
  </filterset>
</copy>

# build.propertiesの例
class.name=Hello
package.name=jp.fmsc.labs.sample

# テンプレートの例
package @package.name@;

class @class.name@Action {
  ;

}

ここでは発想だけお伝えすることとして、続きはANTのマニュアルにて。。。ゴメン。

http://www.jajakarta.org/ant/ant-1.6.1/docs/ja/manual/CoreTasks/copy.html

久しぶりに少しまとまった時間を頂いてプログラマーしてました。と言っても、過ごした時間の大部分は、仕様の詰めのやり取りであったり、打合せであったり、ドキュメント書きであったりなわけで、実コーディングしている時間ってのはそんなに多くないわけですが。そういう意味では、生産性をあげるためには、全方位の工夫とフレームワークが必要なわけで。まあ、それはさておき。。。

今日はLOOK&FEELなプログラムのお話。え、GUIの操作のこと？そうじゃないよ。

プログラムでも、見たまま、感じたままに使えるってのが上質なインタフェースなわけで。特にフレームワークとか共通ライブラリのAPIを提供するプログラムってのはそういうもののはず。難解な構造を理解しないと使えないとか、ドキュメント読んで良く理解しないと使えないとか、動かしてみないと何が返って来るか分からないとか。

まあ、それは極端な例としても、パッケージの名前とか纏まった括り方とか、クラス名とか、メソッド名とか、引数の名前と型とか。特に名前でLOOK＆FEELな表現は出来る要素はともて多い。もちろん、共通APIの名前に限らず、どんなプログラムコードでも、ボディ部分であっても、誰かが見るわけで、LOOK＆FEELなコード表現が出来ているか、人に優しいプログラムかって感じのことも意識すると、すっごく良くなります。

ある優秀なプログラマーいわく、「処理ロジック書くのに悩むことはないけど、メソッド名とかのネーミングに悩むし時間が掛かる。」とさ。変な名前付けると気持ち悪くて自分で嫌なんでしょうね。

普通にプログラムが書けるようになって、もっと上を目指すなら、処理効率とか実行コンテキストを意識するのはもちろんのこと、LOOK&FEELなプログラムを意識して見てはいかがでしょうか。そうすると、すっごく、イケてるコードになります。どうせやるなら、綺麗なコードを書きたいものですよね。

皆さん、JDK5.0で導入されたGenericsって使ってますか？
特にJavaのコレクション(ListとかMapなど)を使う時、Genericsって使ってますか？
まぁ、ケースxケースなんでしょうけどね。
私的には、Genericsって、あまり好きくない。なぜかって、コードが汚くなるからですよ。

ちょっとコードを例示すると、昔はこうだった。

人によっては、たかがキャスト、されどキャストなのかも知れませんが。明示的な型宣言というかコンパイル時の型チェックというかJavaが静的型付けなのでそうすべきと言う理屈はそうなのですが、個人的にはどうも感覚的に好きになれないんです。それに、最近、動的型付け言語が台頭して来てるし。

そもそも、この< >の山括弧が視覚的に受け入れにくいのかなー。プログラムって、()とか{}の括弧とかで見慣れているので。それにそこの型宣言の行だけが長くなってバランス悪いし。

それに、別にコレクションの中の型なんか、明示的にGenericsで宣言しなくても、それを使うコンテキストとメソッド名とかパラム名とかで大概の場合は想像つくじゃん。

でも、まぁ、ケースバイケースなのかな。慣れの問題かなー。んー。

そうか、やっぱ、美的な感覚で好きになれないということなのか。
その感性を大事と思うか理論性を優先させるべきかは人によるけど。

まぁ、どうでもいいか。

最近、皆さんはJava EE(Enterprise Edition)の新バージョン、例えば、Java EE 5とか、Java EE 6に、どれだけの興味を持って注目しているだろうか。もはやコミュニティ主導で進化する中、Java EE仕様は完全に、追いかけられる側から、追いかける側に回った感がある。ラボの他のメンバーも自身のブログ(kimada)に記載しているが、今さらJava EEの中で仕様化することに、どれだけの意味があるのだろうか。逆に混乱を招かなければ良いのだが...。

かと言って、Java EEのコミュニティ主導のスペックにも、その威力と影響力が薄れてきている感がある。Javaが、定住化する中で、それぞれが成功体験と成功パターンを蓄積してきているわけで、その尺度との比較で、冷静に、かつ、賢く物事を測ることが出来るようになってきたということだろうか。あるいは、皆と同じようにやっていても競争に勝てないので独自の工夫を凝らし始めたからだろうか。一部では、「ブルーオーシャン戦略」って用語までも飛び出して来ているようなので...。(この件に関しては、いつの日か弊社のBlendの思想について語る機会を頂くことにしよう。)

それよりも、私の中では、Java SE(Standard Edition)の進化への興味が増している。これは多分にRubyの影響が大きいのではあるが...。Java SE 5としては、GenericsやAnnotationなど、大幅な仕様拡張が行われたのは記憶に新しいだろう。個人的には、Annotationに大いに興味があるし、上手に使いこなしたい(乱用ではなく上手に...ね)と思っている。これまた他のメンバーのブログ(hisama2)で記載されているが、クロージャなど、まさに今後のJavaは言語的な進化がテーマなのであろう。そうでないと、今のJava EEも乗り越えられない壁にぶち当たっているようにも思える。

追記：
この記事ではチームメンバーのブログ間の相互の関連付けを行ってみた。以前のブログ記事でも記載したが、相互作用により生まれてくる何かに期待したい。インターネットWeb 2.0の世界ではそれが普通なのだから。

先日「JavaからRubyへ」って書籍が出版されましたが、実はその前編とも言える「Beyond Java」っていう名著があります。残念ながら、こちらは日本語翻訳版(注1)は出版されていないのですが、英語原本で良ければ購入できます。「JavaからRubyへ」はどちらかと言うと、マネージャー向けに書かれているようですが、「Beyond Java」はJavaを一通りマスターしたプログラマーに是非読んでもらいたい内容です。文章にセンスがあって、例え話もとても面白いです。私の超お勧め本です。

内容はJavaの先に見えるプログラミング言語の洞察などが中心となっていますが、第一章に「茹で蛙(Boiling Frogs)」の例え話が出て来ます。この茹で蛙の例え話は、別にJavaに限ったことわざではなく、熱湯に蛙を入れると逃げ出すのに、ぬるま湯につけられて徐々に温度を上げられると熱いと思ったときにはもう手遅れで致命的だよ注意しな、って話ですが、これが実にJava技術者の現状をうまく比喩表現出来ている気がします。特に我々のような一歩先を歩まねばならない会社にとっては死活問題でもあります。もちろん、まだ沸騰するほどお湯の温度は上がっていないですし、今後、どうなっていくかは分かりませんが、周りの温度のチェックだけは怠らないようにしないと行けないステージに入ってきた感はありますね。先日の「JavaとRubyを」のブログ記事も参考にして見て下さい。

(注1) あまりに素晴らしい内容なので、出版社の方に、日本語の翻訳版を出版して頂けないかとお願いをして見ました。現在、真剣に検討頂いているようで、ひょっとしたら翻訳版が出版されることになるかも知れません。

日本全国に展開している私のアンテナショップ(意味不明？ まぁ、つかみだからいいか。)がキャッチした情報をもとに分析してみると、今年はJBossが来る予感。。。

RedHatがJBossを買収したまでは覚えていたが、突如、私の目の前に急浮上してきたのだろうか。いや、きっと必然的なものなのだろう。

当然ながら「商用オープンソース」としてのRedHatの成功シナリオをもとにした戦略を取ってくるわけで。すなわち「商用サポート付き」。これほど魅力的な言葉は無いのでは。さらに、サブスクリプション型のライセンス体系で、初期導入コストが無いに等しい。そして、コミュニティとして、今や2EE仕様をリードする存在感。理由を挙げると、沢山ある。

でも、なぜ、今年なのか? それは、「日本国内でのサポート強化」にある。私の前職時代の知人もRedHat JBossへ移籍した。何か手応えを感じているようである。人が動けば何かが動くのがこの世界であり、兆候は現れるもの。参考のために、以下にプレス記事へのリンクを貼り付けておこう。

http://www.jp.redhat.com/news_releases/2007/05232007.html

企業向けに使うのに少し抵抗があったSI会社が、日本での商用サポート付きと言うことであれば、動くのではないか。責任分解点理論が重視される日本社会では、これはかなり大きな理由付けというものだ。

なお、誤解の無いように説明しておくが、弊社はJBossだけを特に推奨しているわけではなく、どのベンダーからも中立的なポジションに立っている。それは弊社がコンサル会社であるからと言うのも１つの理由であるが、我々の中での答えは明確で、「どのアプリケーションサーバが良いかは、諸々のコンテキストにより決定されるべきもの」であるから。すなわち、システムの特性、プロジェクトの事情、担当者の思いなどにより決定されるべきものだからである。

いずれにせよ、今年はJBossの動きに注目ということだけは、読者の皆さんに発信しておきたい。

「JavaからRubyへ」って書籍がありますが、私からはそれにちなんで「JavaとRubyを」ってことで一席。

そもそも、なぜ今、Ruby/RoR(Ruby on Rails)かってことですが、はやりJavaの行き詰まり感が背景にあると見ています。それが仕様の混乱と乱立の結果なのか、あるいは、スペック(仕様)主導の功罪なのか、いろいろな解釈があると思うんですけど。何を言ってるかと言うと、例えば、気持ち的には、もう以下のような感じ。

1. J2EE仕様
特にEJBか。JMSのAPIもイマイチ。デプロイメントとか。他にも指摘しだすと切が無いか。

2. コミュニティ仕様
Struts仕様、Spring仕様、Hibernate仕様みたいな。これもオーバースペック。
初期Strutsはまだしも、他は技術的に懲り過ぎってか、ちょっとやり過ぎだろう。

3. ベンダー仕様
ベンダーの独自仕様のこと。これはある意味仕方が無いので責めはしないが。

ってこと。私的には、もういい加減にしろって怒鳴りたくなる。それに何事にも技術的に懲り過ぎなのは良くないよね。これじゃあ、生産性の向上どころか、益々悪くなるってことで、鮮烈に登場したのがRailsなんでしょう。まあ、Railsに限らず、もやはJavaから学ぶものはなく、Javaは他の分野から学んでいかなくては進歩しないってことを、Javaの技術者自身が気付いて行動する必要があるように思うのです。だから今、「JavaとRubyを」ってことがお勧めなんです。

そこで、Ruby/RoRですが、単純にRailsのデモ見て凄い生産性ってことではなくて、本質的な視点というか、もっと突っ込んだ洞察で捉えて欲しいですね。なぜ、RailsがRubyを選んだかって、やはりJavaでは出来ないRubyの動的型付けと強力なメタプログラミング機構にあるのでしょう。Railsみたいなことは、Rubyのような言語仕様じゃないと実現出来ないし、逆にRails並みにRubyを上手く使いこなさないと、Rubyを使う意味が無いというか逆効果と言えるかも知れませんね。それと、Ruby/RoRには先進性というか、Beyond Javaの潜在性みたいな空気が感じられて、Java界の優秀民族の一部が住居の移動を始めちゃったりもしていますね。ただ、もちろん、すべてがバラ色な訳では無く、Ruby/RoRも、今後、信頼性や性能、高度で自由過ぎるRuby言語仕様、RoRの実践での適用性とか...などの課題が山積みではあります。

JavaとRubyに関してはいろいろな見解はあると思うのですが、確かなのは、今、Java系技術者(会社)が最も注目し、また、必ず押さえておくべき必要のあるテーマ、それがRuby/RoRだと言えるし、１コンサルタントとしてそれを推奨する。Ruby/RoRを本質的に押さえることにより、Javaの良い点・悪い点が見え、現状改善に繋がるはずである。つまり、JavaとRubyの相乗効果を狙うべきだと思っている。

と言うことで、「JavaからRubyへ」とか「JavaかRubyか」ではなく、「JavaとRubyを」って落ちでした。

追伸：
弊社のラボでは、Enterprise向けRuby/RoRの活用へ向けての研究活動に取り組んでいます。題して「Enterprise Ruby」。これに関しては、またの機会に書きますね。