今まで何度かとりあげたことがありますが、私結構坂村健教授って尊敬しているんですよね.....で、毎日新聞の日曜日の第２面にエッセーをよく書いていて、それが面白く納得のいくものなので、ちょいと楽しみにしていたりするのです。

で、10/26 に「ノーベル賞の意義」というまあ、時事ネタなのですが、

そりゃ今回日本人（というか、厳格には日本出身者の）のノーベル賞の受賞者が４人も出たのだが、みんな昔の研究成果に対する受賞で、イマの研究でそれに値するものがホントにあるんだろうか？？？

 というちょい斜に構えたご意見が、何か幅を利かしている風潮を見うけますけども、さすがに坂村教授ですから、もう少し当事者的な見地で

 なぜ日本の理系は不遇なのか？

という社会の大問題を論じてます。要するにそれはですね、

問題は世界がどんどん米国型になってきていることだ。現代資本主義の中では、個人の生産性はその個人の独立した能力の絶対値ではない。ごく簡単にいえば、その人がコントロールする資本--配下の組織や設備や資金力がその人の生産性だ。（中略）その評価基準で言う以上、管理側にならない限り給料は個人の能力の範囲を超えない。そして一般に理系の業務は管理職のキャリアに直結しない。問題は個人の生産性は若いうちにピークを迎えるということだ。

と、正しく社会的な問題（というか、極めて広い意味での「権力構造」、大げさで苦笑ですが...）として、

理系のライフサイクルが、日本の資本主義の意思決定構造とうまくマッチしていない

ことを指摘するわけです。勿論、それに対する補償は、以前の日本とイマのアメリカで対照的でしたが、

以前の日本：

徹底した年功序列賃金と、相対的な給与格差の小ささによってカバー。管理職でなくても年を取ればそれなりの給与がもらえた。

イマのアメリカ：

職別の給与体系と徹底的な能力給。それと容易な転職によるキャリアアップ。スポーツ選手のように個人が最も能力を発揮する時期に高い賃金が取れる。

と、それなりに「理系が住める社会」なのですが、イマの日本では

そもそも理系が住みやすい社会、ですか？

と問わざるを得ない...でしょ？？ まあ今回記事のご紹介まで。

「私の選考のコンピューターサイエンスにはノーベル賞はないのであるが...」（苦笑）まあ、いいさ、そのうちチューリング賞を取る人が出るのでは？と期待しておきましょう（ＯＳ設計者もＯＫですから、坂村健だって可能性がないわけでは....）。授与者のＡＣＭは「アメリカ計算機学会」ですが、今まで非米国籍（たぶん）な人も数多く「コンピュータ科学のノーベル賞」であるチューリング賞を受賞しています....ダイクストラ（オランダ）、ホーア他（英）、ヴィルト（スイス）、ナウア（デンマーク）、ダール・ニガード（ノルウェイ・北欧はＯＯＰＬ）、レディ（インド）、ラビン他（イスラエルは暗号強し！）とかなり国際色豊かですし。アジア系はヤオだけのようですが、まあこれならそのうち日本人の受賞もありなのでは...とも期待はできますね。

地味なもの、というのはどうしても注目とか集めにくいものなのですが...

Java の世界で限って言うと、極めて地味な機能である、

• リフレクション
• シリアライゼーション
• RMI

というあたりが、かなり初期から装備されていた（それこそ JDK1.1/1.2 のレベルですから、1998年にはこの３つが揃ってます...）ことが、実は現在の Java の覇権につながっている...というのは否定できないことですよね。リフレクションがなければ JavaBeans も Struts もないですし、シリアライゼーション・RMI がなければ、EJB も JMX もありえません。こういう「地味な事実」こそが、「Java の栄光」の最たるものなのではないのでしょうか....あれ、Java 使っててご存じないようなこと、ないでしょうね！

なので、そういう「地味さ」という面で言うと、実は 1.4 で装備された nio(New I/O) が実に地味な機能で、java.io/java.net と機能がカブるために、今一つちゃんと利用されていない状態が続いてきたわけですが、例の comet について、

select(2) が使えるのは、Java では nio だけだ！

ということがあって、少し陽の目を見た感じがありますが、実は ftplet でご紹介した Apache ftpServer プロジェクトが基盤とする、Apache Mina プロジェクトが、

この nio に１枚カブせて、汎用的なサーバ用途にいろいろと便利なライブラリを作る

というノリのプロジェクトのようです。

Mina の下には非同期に HTTP を使っちゃおう（そりゃsocket を非同期に使えますから...）、という AsyncWeb プロジェクトもありますが...こっちは面白いけども、まだあまりきっちり成果が上がってるものではないようです。HttpFuture オブジェクトって名前がカッコイイですけどね...（苦笑。でも「HTTPの未来」と訳したら間違いってわかってる？）

まあ、

サーバ用途で効率的かつ柔軟な入出力ライブラリで、イベントモデルだって出来てしまう...

というあたりは、実際にはこの「nio ならでは」な機能のわけです.....

何かこういう「地味だけど何気に高機能」というのは、私個人としては「萌え」です.....

 

さて、まあ今更なんですけどね、私らしくもなく

Web2.0 の終り

なんていう大問題（あるいは無問題）でもネタにしましょうか！

厳密にプログラマ視点でいうと、このところの Hadoop への注目って、

まだ Web2.0 じゃん！

ということの証拠だと思いますよ、充分にね。というのは、

これからのプログラマに求められる知識とは？

という視点で考えたときに、

1. 1. マルチスレッドモデルを「攻め」で使えるような、平行処理をイメージする力。
2. 2. 巨大なデータを（必ずしも）決定論ではなく（蓋然的に）適切に処理する力。当然、統計学知識（特にベイズ統計）は必須だし、「大数の法則」についての深い洞察力が必要。

...そう考えてみれば、実際には、

プログラマの資質としては、Web2.0 は始まったばかり

という気がするのですね。ほら、ここらへんの知識能力って、今まで勿論研究はされてながらも、表立って一般的なプログラマ能力としては取り上げられてこなかったものでしょ！

個人的にはですね、私はプログラマですから、

新しいトレンドは、マーケ屋さんとか、株屋さんとか、そういう言葉遊びの好きな業界の方が作るのではなくて、実質的なプログラミングや処理の技法のなかから、徐々に立ち上がってくるものだ

ということを信じているわけです。コトバがどうであれ、技術は進み、普及していくのです....だって、大概の技術は、普及するのに１０年かかっている、というのが事実なのですから。ＯＯＰだってそうですし、卑近なあたりではスタイルシートだってそうでしょ。

プログラマの究極の目標、と言われて何となく感じることですが、

本質的に難しいことを、易しく記述すること

のような気がします.....

たとえば、有名なデザインパターンに限ってもですが、

A. Composite パターンを使って、複雑な中計構造を持った階層について、合計を行う。これは集計を、複雑な階層構造の構築　＋　Compositeパターンの特性を生かした集計に分解することだ。

B. Interpreter パターンを使うとは、複雑な処理の組み合わせを、実際の動作をするプリミティヴと、プリミティヴを組み合わせる「文法」に分解することだ。

C. 例の MapReduce だって、大規模データに合わせて並行処理するために、フィルター処理(map)とアグリゲータ処理(reduce)に分解することだ。

要するに、この３つの例では、

N × M はとても複雑で難しいから、うまいアルゴリズムで複雑性を N + M に分解する

という共通する（かっこよく言えば）「メタ・パターン（パターンのパターン）」を持っているわけですね....こういうの、

複雑さを分解して単純にする

ものですから、プログラマ冥利（大げさですが）みたいなものを感じますね。MapReduce ブーム（苦笑）にはそういう心理的要因もあるのかな。

それでも Apache Hadoop はいっぺん使ってみたい....

小さいものはカワイイから、...let と付ける習慣があったりしますよね。

Applet  -- Application の小さいもの
Servlet -- Service の小さいもの
Proglet -- Program の小さいもの

まあその他にも、doclet とか portlet とかいろいろあります...Java 周辺でこういう付け方が流行だった時がありますからね。その中で、

Apache の pure Java メールサーバである、James で、受け取ったメールに対して固有の業務処理（たとえば空メールを受け取ったら、ＤＢにアカウントを追加しちゃうとかね）を好きなように書ける機能として、mailet というのがあります。以前私は James について詳しい説明を書いたことがありますが、実際ホント何でもできちゃいます！そのとき、比喩として

「お抱えの郵便係」をそっと郵政局に送り込んで、そいつにスペシャルなサービスをさせる

なんてイメージでこの mailet 機能を説明したことがあります。cron ジョブで POP して処理するよりも、ずっとモデルがすっきりしているでしょ....だって、メールを受け取ったらそのまま業務処理が動いちゃうんだもの。ホント、James って名前はダテじゃないですね。どうです、あなたの業務で？

で今回、ftp で処理しなければならないファイルを送りつけてくることになりました....あれ？

ftplet ってあるのかしら？？？

実はあります。やはり Apache の Mina プロジェクトにある Apache ftpServer では、mailet と同じような

ftplet

というものがちゃんとあったりします。まあ、Apache ftpServer 自体、もともと James と似たような設計だったこともあって、そういうアイデアがやっぱりあったわけですね...コレ要するに、

イベントドリブンな ftp へのフック

みたいなもので、自分用の ftplet を実装してインストールし、設定ファイルに書いたら、

内緒でいろいろなこと

が ftpServer の中で出来ちゃうもののようです。Mailet みたいに、

メールの状態によってきめ細かく処理を分岐させていろいろする

というノリではなくて、

ftp コマンドに対応して、たとえば PUT コマンドが発行され処理の完了直後に、アップロードされた中身をチェックしてウィルス感染してないかチェックする（まあそれを実装すれば....）

なんてことができる、というタイプのものですね。ですから、James のややこしいパイプラインではなくてかなりシンプルです。ちょっと遊んでみよ。

けどこの ftpServer は昔は Avalon ベースの Phoenix で出来てたけども、最近は Spring ベースみたいです....Cocoon も Avalon 止めちゃったし、Avalon を引きずってるのは James くらいなのかなぁ....

とまあ、実はノイマン式のコンピュータを使ってる限りは、当たり前の話なんですが....ちょっとシリーズ風に、YAML + Janino とその応用編みたいな話を書いて、

プログラム断片をデータとして管理する

手法をとったわけですが、そういうネタの総まとめに、こんな話題です。

Java7 で、クロージャが導入されるのですが、よくよく考えると、Janino で作るコード断片って、見ようによればクロージャ（風）かもしれません....ちょっと一枚かぶせてやれば、それっぽくもなるでしょうね。Java という言語は、

唯クラス主義

というか、もともと

すべてのオブジェクトは、クラスとインスタンスだ

という隠れた哲学（コレ少し参考になるかな？→「Javaの冗長な記法って小クラス主義の表れではないかな」）を持ってたわけです。ジェネリクスが C++ のものと比較して制限されているのも、

ジェネリクスをクラスに対するフレーバー付け

くらいの感じで、「唯クラス主義」を損なわないように実装されたのもその影響じゃないかと思います....で、このクロージャは何か、というと

クラスでもインスタンスでもないヘンなプログラム実体

ということになって、Java の「唯クラス主義」を傷つけるんじゃないか...とも思います。まあ、Command パターンとか使い捨ての内部無名クラスとか使えば、

クロージャが欲しい大概のコンテキスト

は実現できる....というのもありますからね（それでもカリー化はちょっと厳しいか）。まあどうなるかは知りませんけど、やはりこれって、Java プログラマの成熟もありますが、

プログラムとデータをガッチリ区別する、管理のパラダイム

がホントに効率的かどうか？という反省もあるのかもしれません....まあ、私が Janino での手法を提案したのも、

そんなコロコロ変わる会社ごとの特別な仕様を、マジメにハードコーディングしてたら、たとえ専用の継承クラスを作って切り分けるとしても、時間の無駄じゃん

という「メンテナンス視点ありき」の発想でしたわけで....あまり理屈優先じゃないです、すみません。

考えてみれば、データとプログラムを分ける／区別しない、というのもそれこそ1960年代の Lisp からの話題で、別に珍しい話でも何でもないわけです。YAML について調べていると、こんなものも見つけましたよ....

SXML -- S式XML(S-expressed XML)

要するにこれ、Lisp でプログラム／データを表現する（悪名高いカッコの）ｓ式で、XML を表現しちゃおうというやり方です。SXML は YAML とは違い、完全に XML と等価です。形式的な書き換えで相互変換できてしまいます。まあ、Lisp と同じ S式構造ですから、当然 Lisp 系言語コミュニティ（特に Gauche）で、言語のとの親和性がイイというのを理由として採用されるケースがあるようですね。

じゃあ、SXML が「プログラムと同じ形式のデータ」ならば、「XML形式のプログラム」ってあるのか....というと、以前にも紹介した Apache Commons Jelly が典型でしょうか。これはスタンドアロンの汎用的なタグプログラム言語ですが、勿論 JSTL とか Struts タグライブラリの方が、JSP 埋め込みでは常識ですしね。あと、XSLT だって立派なチューリング完全な言語です...「データの顔をした言語」なんてありふれてます。

もっと面白いのはですね、プログラム言語でもあるデータ...というものです。それもクラシックにＣ言語ソースなんだけども、画像データだったりする....というヘンな存在です。それはですね、X-Window のカーソルやアイコンに使われる、Xbm という楽しい画像形式です....ホントに形式的には

タダのＣ言語ソース

なのですが、実際にはデータとして使われる、固定しており広く知られた画像形式だったりするわけです.....表にまとめましょうか？

	Ｃ言語	Lisp	XML
プログラム	フツーのソース	フツーのソース	Jelly, JSTL, XSLT
データ	Xbm	SXML	フツーのXML

としてみると、XML ってちゃんと「言語」なんですね！

同僚からの質問で、ＰＧＰについて訊かれました。なので、

うん、家にあるオライリーの「ＰＧＰ」を持ってくるね！

と貸し出しをしたわけですが.... オライリーの「ＰＧＰ」 （シムソン・ガーフィンケル著）ってなにげに名著なんですね（ちなみに、バイブルで有名な石田晴久氏らが選ぶ「コンピュータの名著・古典」にもちゃんとランクインしてます）。実際この本、オライリーとしては珍しいこと（ごめん）ですが、

読み物としてメチャクチャ面白い（オライリーの名著はたくさんあり過ぎですけどね）

という性格を持っているのです。この本は読み物として面白くなる条件はガッチリ揃ってます。

1. 1. 公開鍵暗号は 数学原理に基づいており、パズルみたいな面白さが味わえる。特に一番最初の「マークルのパズル」のアイデアなんてサイコーでしょ。コロンブスの卵とはこのことですね！
2. 2. 当初PGPは海賊ソフトみたいなものでしたから、開発者ジマーマンは ソフトウェア特許権をめぐってRSA社と対立します。トラブルの行方は？
3. 3. さらに、暗号技術を「武器」として捉えるアメリカの安全保障（担当は「ハイテクスパイ組織」と陰口を叩かれるNSAですね...）との間の問題がある。スパイ小説、かな？

...と、これで面白くならなければ、ライターとしては落第？じゃないでしょうか。

しかしですね....この本の問題は、

定価が高すぎる....（新品は定価5050円）

ということだったりします。とはいえ、今は後半の

実際のソフトウェアとしてのＰＧＰの使い方

の部分はハッキリ古くなってますから、

その分が値引きされた（苦笑）

感じで、中古を購入するといいのでは？などとも思います。amazon だと 2000 円からありますから、お買い得ですよ！

中立的な技術であっても、今までの成り行きから特定の文化と相性がいい／悪いというのはあるものです。たとえば、

Java - Struts - XML
Ruby - Rails - YAML

って、そういう対立かもしれません。意外に Java 屋さん、YAML 知らないものみたいですね（勉強するなら「プログラマーのためのＹＡＭＬ入門」がオススメ）。今回はそう、Java で YAML を使うべきコンテキストの話です。実は私、結構前から

いつか Java の仕事で、XML のかわりに YAML を使ってみたいな！

なんて思ってたんです。まあ、XML と YAML とでは、データ記述という似たことをするものですけども、性格がかなり違います。

1. 1. YAML はシンプルで読みやすい。
2. 2. YAML の方はデータ表現に必要なものに制限されているが、XML の表現力は多彩で用途に縛られない。YAML ではインライン要素は表現できないしね。
3. 3. XML は公的にガッチリ規定された規格でありつつ、拡張可能...というマジックを使える（勿論ネームスペースによって）が、YAML はプライベートなデータ記述と交換用途であり、公的規格にするのには向いていない。
4. 4. XML はスキーマによる文法チェックができるが、YAML にはスキーマの概念はない。

まあ、こう考えてみると、私なんかは

ライバルというよりも、別物

というイメージの方が強いんですけどね....というわけで、Java 屋さんが何でもかんでも XML を使いたがるのは、やや勉強不足かな、という気もするわけです。

どうみても、XML よりも YAML 向きで、反論のしようがないケース

というのをうまく Java プログラミングの中で示せれたらいいな、という風にずっと思っていたんですね。で、今回、

Janino を使って、Java コード断片をファイルで管理する。そのとき、ハッシュテーブル風に、キーからコードが対応するように引ける

という問題が出たわけです。まあ、これ勿論 XML でも書けるし、管理できるのですが、

1. 1. プログラム中の <, >, &, " をエスケープするのはイヤだ（まあ、CDATAセクションを使うとエスケープせず書けますがね）。
2. 2. 改行や空白の扱いが asis ではないのがイヤだ（同上）。ただし YAML もタブは使えませんがね。
3. 3. 単にハッシュのキーと値しか要らないから、XML だと過重。余計なタグが入っていると逆にエディタ上で見た目がややこしい。

というわけで、これ実に YAML 向きでは？と感じたわけですね。ま、比較してみると一目瞭然でしょ。

YAML

# YAML format JaninoValidator code fragments
# See http://jp.rubyist.net/magazine/?0009-YAML
validateA: |-
  if( application.getTransferId() > 8 ){
    if( action.isLevelDescented(employee, application) ) {
       action.setError(null, "errors.appChangeBelong.conflictLevel", messages);
    }
validateB: |-
    if( action.isSalaryDescended(form) && action.isSalaryEqual(form) ) {
       action.setError(null, "errors.appChangeBelong.conflictSalary ", messages);
    }

XML

<?xml version="1.0" encoding="UTF-8"?>
<rules>
<!-- XML format JaninoValidator code fragments -->
<rule>
  <name>validateA</name>
  <!-- CDATAセクションは使わない -->
  <body>  if( application.getTransferId() &lt; 8 ){
    if( action.isLevelDescented(employee, application) ) {
       action.setError(null, &quot;errors.appChangeBelong.conflictLevel&quot;, messages);
    }
  </body>
</rule>
<rule>
  <name>validateB</name>
  <!-- CDATAセクションを使う -->
  <body><![CDATA[   if( action.isSalaryDescended(form) && action.isSalaryEqual(form) ) {
       action.setError(null, "errors.appChangeBelong.conflictSalary ", messages);
    }]]>
  </body>
</rule>
</rules>

まあ、コードをメンテする私以外の人は、たとえ YAML をあまり知らなかったとしても、どっちを歓迎するか...は自明な気がしますね。どうでしょう？

さて前回のエントリで触れた Janino ですが、提案してみたら結構気に入られたようです。うれしい！

で、これやはり、

変わる可能性の高く、適用もローカルで、ローカルな設定に値が依存するローカルルールを、変更しやすいかたちで記述する

というかなり一般的な要求があって、それを

ハードコーディングではなくて、設定ファイルに書くだけで適用できるようにする

と解くという一般的な手法なのです。ストラテジパターンのさらに可変度の高いバージョンみたいなものかな。勿論、値を変えるだけで何とかできるようなものならば、そこまでするメリットはないのですが、

ロジック自体をストラテジパターンよりも柔軟に差し替えたい

というややこしい要求なのですよね...

これの解は、別にもあります。簡単だけども、スパゲッティ化しかねない解法だと、

そもそも、スクリプト言語で全体（あるいはその「可変部分」）を書く

というアプローチもあります。Java 6 なら Janino を使って Java で書くよりも、Rhino で JavaScript で書く方が現実的かもしれませんね。まあこれは生産性と頑強性、テストしやすさ、変更コストとの兼ね合いでしょう。ちなみに私が Janino をお気に入りなのは、ライブラリサイズが意外に小さいのがかなりポイントなのです。実際、ls -lSr してみると、Janino は log4j より大きいですが、 struts, poi, hibernete3, spring なんかよりはずっと小さいです（463K）。気にするほどじゃないですよね。

で....さらに「重量級」なアプローチ、というものもあります。Drools とか、いわゆる「ビジネスルールエンジン」というタイプのアプローチですね。ビジネスロジックを分離するのって、J2EE の基本ですが、これをさらにルールを管理するデータベースと、推論エンジンで管理しよう、というアプローチです。ですからこれも、

when
  マッチングパターン
then
  実行されるコード断片

という格好で、ルールが記述されることになり、Drools だと Java のコード断片をハンドルするのに、Janino が使われてるわけです.....

まあ、このビジネスルールマネージメントのやり方は、大昔の第五世代コンピュータ・プロジェクトあたりで、その成果となることが期待されていた「推論ベースのエキスパートシステム」の子孫のようです。結構懐かしくてちょっと関心持ってしまいました....けど日本語のページで詳しいのって、

ビジネスルールの館（イルミナード）

くらいしかないみたいですね。勉強しよっと。

ちなみに Drools ってもともと Codehaus で開発されてたけど、3.0 になって JBoss に採用されたこともあって、オープンソース開発のホスティングを JBoss に移籍したようですね。面白い....ちなみに JSR 94 という Java 規格もあり、これも準拠してますから、世の中ようやく追いついたのかも....