[winny] 結論

IBM時代のころをいろいろ思い出すと、自分の原点を見つめなおすことができる。私は待遇に不満があるわけではなかった。むしろ高く評価していただいたと思う。IBMに育ててもらったし、嫌いなわけではない。やめた今でもお付き合いをさせていただいている。というか、一番大きな取引先である。 それなのに・・・・なぜやめたか。 それは、Reflexを作りたかったからだ。 Reflexは、「P2Pで安全に商取引ができるインフラの提供」を目的としたミドルウェアであるが、なぜP2Pにこだわるかをここでちょっと説明したい。

一極集中から新しいパラダイムが生まれて分散へ流れ、それから、また集中に動く。 これをITにおける輪廻という。 （by IBM 中島DE）

YahooやGoogleといった巨大なポータルサイトもあるが、インターネットは、原理的にはIPによる個々のコンピュータによるネットワークである。すなわち、基本的に分散型であり、インターネットの特長を最大限に生かすには、P2Pのような分散型が最適であると考えられる。 今、WEB2.0という新しいパラダイムが生まれて、CGMという個人の情報が重要だと認識された。 CGMを最も効率よく流通させるのは、インターネットの特長を生かしたP2Pであることは、疑いようがない。 また、今後膨大なCGMが発信するようになると、1極集中型が破綻すると私は予想している。ムーアの法則がサチッてきている以上、横に広がる以外ないのだ。 なので、私は新たな流通基盤が必要となる時代は必ず来ると信じている。これがReflexを開発している動機である。 今は、WEB2,0は「あちら側」という言葉に代表されるように、巨大プレーヤーによる演出に目を奪われがちであるが、なんのことはない、Googleだって個々の情報で商売しているだけではないか。たしかに、すばらしい検索能力をもっているので、Googleがまるで情報を生み出しているような錯覚を覚えることはある。しかし「情報発電所」は勘違いであり、「発電」しているのは個々の情報発信者である。 P2Pは「あちら側」でもなく「こちら側」でもない。単に個々が連携しあって成り立つネットワークである。繰り返しになるが、これがインターネットの本質であると私は思う。P2Pの検索システムは、インターネットが存在する限り、破綻することのない無限の可能性をもったシステムである。Skypeは無限のユーザ数に耐えうるそうだが、要するに、そんなようなものだ。 インターネットに問い合わせるだけで、得たい情報を得ることができるようになった。しかし、現在は、Googleにしか問い合わせることができないのが問題だ。私たちの情報を無断で利用し、他に検索手段がないことにつけこんで、いろいろ商売を行っている。私はこのような「あちら側」を撲滅したい。Google八分という言葉をご存知だろうか。インターネットはもっと公平であるべきだし、自由であるべきだ。P2Pであれば誰からもコントロールされず、また、「あちら側」の撲滅が可能だと思う。 Reflexで「あちら側」の撲滅が可能とは到底思えないが、まずは、ここに述べたような分散型の理想のネットワークを実現させたいとは思っている。私はそのためにIBMをやめたのだった。 特定プレーヤーによる１極集中ではない、バーチャルで分散型のネットワークの実現。それがバーチャルテクノロジーという会社の目的だ。バーチャルには「本来の、本質的な」という意味がある。「バーチャル＝仮」ではなく、「本来」のものを得るための技術という意味で、バーチャルテクノロジーという名前にした。 私は著作権破壊とか、ほう助とか、決して望んでいない。しかし、Reflexを開発し、公開することで、結果的にそうなってしまうかもしれない。一時は開発を断念しようかとも思ったが、今はそれで有罪になってしまうのであれば、やむをえないかなと思っている。 技術の進化は誰にもとめられない。

[news] Donald F. Fergusonがマイクロソフトに？

あの、Don FergusonがIBMを退社してマイクロソフトに入ったという噂（※）がある。WebSphereを作り、今でもSOAのキーパーソンである彼がなぜIBMをやめなければならなかったか。詳しくはよく分からないが、本当にこの業界はこの手の話が多い。（※事実かどうかはまだ分かりません）

私がIBMにいたころは、戦略を考える際には、常に彼のことを念頭に置いていた。彼が今何を考えてどうしたいのか。皆で議論しても埒が明かないときは、彼の言葉を信じてそれに従った。まるで神のような絶対的な存在であった。私がIBMの事例を誰よりもはやく作れたのは、彼のおかげかもしれないと思っている。自慢話ここから==>

ちなみに、WebSphereを日本で最初に導入した実績を作ったのは私である。1997年であったがFirst Referenceにすることができた。それから、同年クロネコヤマト様の荷物追跡システムを設計し、2002年、Webサービスを使って連携するシステムを作った。1999年には東京海上様の代理店検索システム、2001年にはKDDI様のPayCounterシステムではSOAP認証を作った。2000年には岡村製作所様でIBM初のEJBによるWebEDIシステムを作った。また、RTS様で業界初のUDDIシステムmabotを設計した。

東京海上様の代理店検索システムは、全国の代理店情報を地図上にプロットして紹介する、いわゆるマッシュアップのはしりのようなシステムだ。MapFan様の地図を利用させていただいたのだが、最初の企業ユーザだとおっしゃっていたので、私が一番最初であることは間違いない。そのアイデアを転用して、2004年、XMLコンソーシアムでiPlatを設計した。これが出来上がるころに、googleマップがUSでオープンになって話題になったが、私たちはそれに刺激されながら作業していたのを覚えている。このときはまだAJAXもWeb2.0も騒がれていなかった。

<== ここまでが自慢話 このように、業界初のものを多く手がけることができたのは、恩師であるIBMの中島DE、それから、Fergusonの慧眼のおかげであった。本当に感謝しているが、こんなに簡単にやめられるなんて、寂しいかぎりである。（よく考えたら人のことは言えなかったりする） IBMは最近、あまり評判よくないようだから、特に、日本IBMについてこの先心配である。

追記:

　Google AJAX Search APIを担当するテクニカルディレクターは、かつてMicrosoftの一流エンジニア　だったMark Lucovsky氏だ。

こちらはこちらで大変なのね。

もういちど、Fergusonの本を紹介しておこう。

[Winny] 開発者がなぜ萎縮するか

まず、白田氏のこちらを読んでもらいたい。Winny事件判決の問題点　開発者が負う「責任」とは

極めて簡単に言えば、「Winnyが違法コピーに広く使われているってこと、知ってたでしょ。それにもかかわらず、Winnyの改良をしたでしょ。だから幇助」ということになる。この判決骨子の論理では、「画期的なソフトウェアを開発したプログラマが、実験的にリリースしたら、利用者に思いもよらない使い方をされてしまった」というだけでは幇助にならない。また仮に「思いもよらない使い方で反社会的な効果が生じてしまった」と認識した後に、とくにその反社会的な効果の拡大につながる積極的行為をしなければ幇助にならない。だから、「ヤバい」と思ったら配布公表を停止すればよいことになる。それ以上の責任、たとえばソフトウェアの回収とか削除までしなければならない等は、どこにも述べられていない。

　だから、この事件が一般的に「プログラマや技術者に無理解な不当な判決であり、今後新しい技術を開発するにあたって萎縮効果をもたらす」というのはやや誇張された主張で、金子氏や弁護団のみなさんがこの点を声高に言い過ぎると、かえって金子氏の立場の正当な要素を損ないかねないと危ぐする。もちろん、このくらい簡単に誇張して言わないとマスコミの人たちや一般の人たちに分かってもらえない、という気持ちも良くわかるんだけど。あくまでも「幇助概念」に関する法律論が主戦場である本件判決を、無理して別の価値に関する議論の文脈におくと、たぶん、なにかがゆがみはじめる。

私たち開発者にとって関心があるのは、開発したソフトを公開したときに、有罪になることがあるかどうかの１点だけだ。

この記事を読む限り、自由に開発して公開しても有罪にはなりえないが、著作権侵害に利用されていることを知りながら、著作権侵害を助長するソフトを開発し続けると有罪となる。

判決が出た後である現在では、Winnyを開発することは当然有罪になり、また、「それと同等の機能」をもったソフトを開発して公開することも有罪になると思われる。そうでなければ、名前を変えてWinnyを開発し続けられることになる。

一番の問題は、「それと同等の機能」を開発して公開すると有罪に問われる危険があるということ。「それ」とは、P2Pにおける匿名性をもったファイル交換技術だ。なぜなら、「それ」を実装したソフトは、Winnyでなくても、全く同じことが可能になるからである。

Reflexは、ここにも書いたが、 WinnyはITの核兵器なのか「それ」を実装している。そして、Winnyが著作権侵害に利用されていることを知りつつ開発したことになるので、使われ方によっては、金子氏と同罪になる危険性がある。なので、私は開発をストップせざるを得ないかなと考えている。

このように、判決が出たあとでは、明らかに対応が異なるのであって、これは萎縮ということになるだろう。白田氏の意見は、実際の現場をよくご存知ないのかなと思うしだいである。繰り返しになるが、私のように萎縮してしまう開発者は大勢いると思われる。

司法は、開発者が萎縮してしまわないような、判決をすべきであると思う。今のままでは、何をしたら大丈夫なのか、まるでわからない。少なくとも、Reflexを公開して有罪にならない補償はない。やはり、遠山の金さんに聞くしかないのかなあ。

[winny] 司法ではなく立法の仕事？

いやあ、すばらしい記事だ。有罪の根拠を納得できた。
Winny裁判、罰金刑は重いか？軽いか？--自己矛盾を抱えた判決

いや、そんな倫理性の話でなくても、あちこちで「著作権を崩壊させる」と発言して国家権力に挑戦し、結果的に著作権侵害ファイルを蔓延させている以上、これを無罪とするというのは国家権力の側の判断としてはあり得ないように思われる。

司法としてはやむなしということか。ということは、あとは立法の仕事ということ？新しい時代の著作権法を作る動きを期待したいところだが・・・・。

この判決には、大いなる自己矛盾もある。氷室裁判長は、情状酌量の理由として「著作権侵害を目的にしたのではなく、新しいビジネスモデルを生み出すためだった」と述べた。しかし金子被告の意図が著作権侵害ではなかったのだとしたら、その行為がなぜ「著作権侵害の幇助」に問われなければならなかったのか？　意図はしていないが、結果的に侵害に利用されれば、それは「幇助」となってしまうのか？　このあたりの問題は堂々めぐりの迷宮に入ってしまいそうになる気もするが、こうした自己矛盾がひそかに内在しているあたりにも、今回の判決の何とも言えない微妙さが浮き彫りになっているようであり、そしてこの事件の判断の難しさを体現しているようにも思えるのである。

よし、この本買おう。

[winny] 普通に考えると・・

amachanに同感。
プログラムを作って公開した結果、有罪になるなんて、やっぱりおかしいと思う。

[prototype.js] 連想配列からXMLに変換するJavaScript

Prototype.jsを使うと連想配列からXMLに変換するコードを、こんなにシンプルに書ける。

DEMO

prototype.jsを使わないバージョン＝＞extractive.jsの中に含まれる

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>JSON2XML</title>
<script type="text/javascript" src="scripts/prototype.js"></script>
<script type="text/javascript">

var extension = {
　toXMLString: function() {
　　　return this.map(function(pair) {
　　　　　return "<"+pair.key+">"+ (
　　　　　　　typeof　pair.value == 'string' ? pair.value　: $X(pair.value).toXMLString()
　　　　　) +"</"+pair.key+">";
　　}).join('');
　}
}

function $X(object) {
　var hash = $H(object);
　Object.extend(hash, extension);
　return hash;
}

function test() {
　　
　　var aa = $H();
　　
　　aa.b = "ta </a>} : ke";

　　var h0 = { root : { a : aa,
　　　　　　　　b : "2",
　　　　　　　　c : { d :"3", e:"4" },　　
　　　　　　　　f : ["5","6"]　　
　　　　　　　　}
　　}

　　var h = $X(h0);
　　
　　alert(h.toXMLString());
//　　alert(h0.c.d);　　
}

</script>
</head>
<body onload="test();"></body>
</html>

[prototype.js] Event.observe()

いつも忘れるのでメモ

Event.observe(element, name, observer, useCapture)で登録したイベント処理を受けるときは、Event.element(e)を使う。

Event.observe(but1, 'click', showMessage, false);

function showMessage(e) {
alert('clicked: '+ Event.element(e).id) ); // but1
}

どうしたらほう助とならないのか・・遠山の金さんに聞くしかない

Winnyは、違法コピーを防止するような改善がなされなかったので、ほう助と認定された。氷室裁判長は、「無限定なほうじょの成立拡大も妥当ではない」といっている。ここでのポイントは、１．その技術の社会的での利用状況、２．提供する側の主観的な態度。

１、については利用者側がどう使うかは、開発の段階では未知である。結果的に違法コピーの道具にされることもありうる。そうなったときに防ぐ手段をとれるかどうか。少なくとも、Winnyに関してはなかった。

２、については、金子氏自身、「著作権のあり方への挑戦」といわれていたこともあったらしいので、ほう助と認定されたのかもしれないが、一方で「積極的な企図があったとは認められない」のがよく分からない。

では、どうしたらほう助とならないのか、つまるところ、開発者の態度をみて、裁判長が有罪か無罪かを判断するということなのか。ああ、遠山の金さんみたいな話だ。

[winny] 有罪の本当の理由

判決では有罪となったわけだが、一方で、現在でもWinnyネットワークは厳然として存在している。ということは、Winnyを規制してすべての人が使用しない限り、法による情報のコントロールはできない状態になっている。有罪とされた本当の理由は、このへんじゃないかなと思う。その証拠に、量刑の理由は、Winnyを検索キャッシュに置き換えただけなのだが、全く当てはまることがわかる。検索エンジンとWinnyは、著作権侵害幇助というより、コントロールできるかどうかだけの違いだと私は思う。

情報規制は、お上によって正しく情報の峻別がなされることが前提で成り立つ話である。しかし、「コントロール≒権力」でもあるので、権力を利用して、私利私欲に走る輩が出てくることも心配だ。同じように心配している方もいる＝＞なにかNHKで..インターネットの匿名性について議論やってますが

言論の自由は、憲法というより、実質的にはインターネットの匿名性で保障されてると考えているのは私だけだろうか。

[winny] WinnyはITの核兵器なのか

Winny判決で驚いたのは、有罪となったということより、その刑の理由だ。「金子氏の著作権侵害幇助の企図は認められないが、著作権侵害のために利用されることを知りながら何も対策を講じなかったから有罪」だという。要するに、大変有害なソフトであるが改善されないから有罪だという。いくら作者だからといっても、それは無理というもの。P2Pネットワーク上のファイルを消すのは、技術的に不可能に近い。判決が逆ならまだよかった。ソフトが悪用されて侵害されたのは他者によるものであり、それを防ぐには技術的な理由があって対策を講じられなかった。なので、そのことについては罪には問えないが、著作権侵害幇助の企図があったので有罪。ソフトはあくまで人が利用するものであり、どのように使ったかを問題とする、いわゆる「包丁」の例えを適用するとわかりやすい。このままだと、銃刀法違反のような法律がITにも適用されるんじゃないかと不安を感じてしまう。

特定のソフトであればまだいい、実は、弊社で開発しようとしているReflexにも適用されてしまうんじゃないかと心配している。Reflexは、Overviewの「何が嬉しいか」を見てもわかるように、P2PをベースにしたCGMの管理ミドルウェアを目指したものだ。CGM（コンテンツ）があらゆるノードでキャッシュされているが、IDで特定できて、誰がいつ作成したかを確認できる。特定のノードにいなくても、どっかにキャッシュされていれば、自動的に検索されてダウンロードできる。暗号化とPKIを使うことで、オープンな環境で安心して商取引ができることを目指したものだ。しかし、適当な署名を作って公開することも、やろうと思えばできる。当然、証明書が偽造されていることが分かるので、信用できないことはすぐに分かるのだが、それがたとえ信用できないものであっても、リスクを承知で入手することはできる。すなわち、匿名のファイル交換が実質的にできてしまうのだ。このソフトを公開したらどうなるのだろう。私は著作権幇助を企図していないけれども、利用者はどう使うか分からない。判決を知った今であれば、もちろん、匿名のファイル交換ができない仕組みにするとは思うが、もし知らないで公開してしまったら、金子氏のように有罪となってしまうのだろうか。私は、こんなリスクをしょってまでReflexを開発するつもりはない。設計の大幅な見直しか、あきらめざるを得ないだろう。私のように感じている者は日本中に大勢いるはずだ。司法は、著作権を主張する者の利益もそうだが、日本のIT業界全体の利益も考えて判断すべきだと思う。今回の判決は、イノベーションに取り組んでいるIT技術者のモチベーションに大きく影響を与えることだろう。

原爆を発明したアインシュタインは有罪か、使った者が有罪か、それとも両方なのか。
アインシュタインを有罪とする法律が当時はなかったから無罪だという人がいたが、どうなんだろう。

Winnyは原爆のような存在で、昨日、それを発明した人に罪が言い渡された。
著作権侵害幇助の企図は認められないが、大変有害なものであり、改善されないので有罪だそうだ。

[winny] Winny 量刑の理由

私のBlogにはちゃんとCopyrightが付いているにもかかわらず、勝手に検索キャッシュにコピーして、私の意図とは異なる利用のされかたをされ、利益を得ている輩がいる。その輩には以下を言い渡す。まあ、罰金刑が相当だろう。

量刑の理由

　被告は、検索キャッシュを開発、公開することで、これを利用する者の多くが著作権者の承諾を得ないで著作物ファイルのやりとりをし、著作権者の有する利益を侵害するであろうことを明確に認識、認容していたにもかかわらず、検索キャッシュの公開、提供を継続していた。

　このような被告の行為は、自己の行為によって社会に生じる弊害を十分知りつつも、その弊害を顧みることなく、あえて自己の欲するまま行為に及んだもので、独善的かつ無責任な態度といえ、非難は免れない。

　また、正犯者らが著作権法違反の本件各実行行為に及ぶ際、検索キャッシュが、重要かつ不可欠な役割を果たした▽インターネットにデータが流出すれば回収なども著しく困難▽インターネットの利用者が相当多数いること、などからすれば、被告の検索キャッシュの公開、提供という行為が、本件の各著作権者が有する公衆送信権に与えた影響の程度も相当大きく、正犯者らの行為によって生じた結果に対する被告の寄与の程度も決して少ないものではない。

[Google Calendar][JSON] Google CalendarでBlogのエントリー

Google Calendarのコメント情報をJSONで読み、Blogのように時系列で表示するJavaScriptを作ってみた。ここを参照＝＞（デモと説明）

カレンダーに自由に書き込んでもらって結構なのでぜひ使ってみてほしい。こういう使い方はカレンダーの想定外かもしれないけど、ちょっとした情報共有にはこれで十分事足りると思う。

技術的なポイントは、

• 　エントリーをソートする（ feed.entry.sort() で、sort中に更新順となるような条件を指定した）
• 　ISO8601からDateへの変換（d.replace(/^(\d{4})-(\d{2})-(\d{2})T([0-9:]*)([.0-9]*)(.)(.*)$/,'$2/$3/$1 $4')）・・9時間足してねえ
• エントリーのlinkを元にコメントのリストをJSONPを使って作成する（document.write()だとIEで動かないのでdocument.createElement（）を使ってscriptタグを作成した）
• 　4行目のIFRAMEは埋め込みカレンダーを横に出すため
• 　30秒おきにリロード（この動きがかっこ悪い）

[Google Calendar] JSONのテスト

時間があるときにやってみようということで、ここを参考にやってみた。Google Calendar TIPS
すごく簡単に作れる感じだ。弊社ではカレンダーをアルバイトの勤務管理に使っているので、毎月の支払いをすぐに計算できる。また、WikiなどのようなアプリもJavaScriptだけでできそうだ。カレンダーに書いたコメントを時系列に表示するだけでグループウェアの代わりに使える。Author別、日時別の表示切替も簡単にできると思う。

FeedはATOMを独自に拡張したもののようだ。gd:ではじまる独自のタグがあるのだが、JSONでは:は$に変換される。
これは、Reflexと同じルールだ。なんという偶然。っていうか他にないからなあ・・。

コメントなどは、Calendarのエントリーにリンクされる別のエントリーになっているため、これらを取得するにはまたJSONリクエストを飛ばさなければならない。

ATOMのタグを独自に拡張して、エントリーにエントリーがリンクするようなこの仕様は、ATOMPPを考えたときにどうなるのか、ちょっと心配でもある。

XML開発者の日

先日のSeasarカンファレンスが秀才たちの集いとすれば、昨日のXML開発者は天才たちの集いという表現がぴったりだろう。前回より右脳をいっぱい使った気がする。朝１０：００～１８：００までほとんど休憩なくセッションがあってそれから親睦会。家に帰ったのは夜の１１：３０だった。村田さん、Yoheiさん他、多数の著名人と会話できて非常に充実した一日だった。それでは、セッションの内容について、面白かった順にポイントをご紹介しよう。

１）RESTの話（Yoheiさん） REST Best Practicesyohei-y:weblog: 第九回XML開発者の日 終了

* CoolURIでいこうとのこと。納得。URIはクライアントに不透明だそうだ。
* UIとしてのWeb
* ハイパーメディアシステムとしてのWebWiki
* フレームワーク重要
* データ重要
* WebアプリとWebAPIでURIを分けない
* SOAへの対抗イデオロギーとしてのROA(<= 今後注目) 以下はRESTに関する私の理解。 リソースにはパーマリンクがつく形で一意に識別できる。リソースは集合であってもよい。集合といってもCountableである必要はない。検索結果はそのサブセット。パーマリンクはリソースを特定できるが表現はいつも同じとは限らない。ここまでは理解できる。 以下は疑問点。

１．クエリパラメータが複数あるときにPOSTで渡すという話は、201 createdが返るのだが検索なのに一時的にリソースが作られる？その場合には、検索条件はリソースになり、パーマリンクもつくのだろうか。また検索対象との関係はどうなるのだろうか。ちょっとよくわからなかったが、きっと揮発性のものなんだろう。

２．リソースを複数の検索条件で絞り込んで検索するときの結果にはパーマリンクはつかないのだろうか。検索対象のリソースのURI＋検索条件でパーマリンクとしてよいのだろうか。もしいいということであれば、POSTで検索という話はあまり旨くない。

３．パーマリンクはリソースを特定できて表現は変わってもよいと理解しているが、本質的に情報の意味が変わっても、同じリソースといっていいのだろうか。例えば、http://天気/東京/今日というリソースが、「晴れ」とか「Sunny」を返すのはいいが、10:00を返してもいいのだろうか。

２）ODL vs OOXML（村田さん） いやあ、面白かった。 MSの言い分は、ワードというソフトを作ったけど、クローズなままだともったいないから、フォーマットをオープンにしてOOXMLとして標準化したい。ODL側は、ワードフォーマットをMSが勝手にコントロールしてけしからんから、皆で決めたフォーマットを標準にしたい。 いい考えがある。一太郎のフォーマットを世界標準にすればいいのだ！！！ まあ、冗談はさておき、私はどちらも流行らないに１票を投じたい。個人的にはPDFがいいと思っている。XMLにもしやすいしね。

３）Microfomats(概要　上之郷さん、Syndy Chronicle　山口さん)　 こっそりタグ付けする人にやさしい発想は支持したいと思う。でも、自己主張が苦手で自信のない人には向いてないかもとは思う。こんなタグをつけてごめんなさい、といつも罪悪感を感じながら開発しなきゃならないのだろうか。 今後は注目したい。

４）Google Calendar & GData（Masa and Takさん）カレンダーアプリへのGData実装

JSON対応になったそうだ。すげー。メモメモ 　（追記: 2006/12/11 DEMOを作ったのでこちらも参照くださいGoogle CalendarでBlogのエントリー ）

５）ブログエディタへのMicroformatsの実装（後藤康成さん、室田直匡さん）feedpath blogot

* ｶﾞ━(ﾟДﾟ;)━ﾝ　この人すげー。
* WSSEはATOMPPでデファクトと思っていいのだろうか。誰かははやく決めてほしい
* いろいろ部品を選択して作れる blog editor。AJAXがはやるわけだ。

６） Plagger: the duct tape of the Web（宮川さん）

* この人かっこいい。話がおもしろくてプレゼンがうまい。サンフランシスコからプレゼンとはよく考えたものだ。すげー。
* 製品はよさそう。

７）RESTfulアプリケーションの方向性（川村さん）

* RoRに興味がある人にはたまらない内容だっただろう。私はまだやってない。
* RESTのWebアプリ設計のヒントになった。特にケース１。

ウィザード画面をリソースに対する操作のイメージで作る

POST　/order/34 201 created
GET /order/34
PUT /order/34
303　SeeOther /order/34で次画面

PUT /item/99

最後はcompleteというステータスになるだけ。うーん。なかなかいい。

The Reflex

So why don't you use it
Try not to bruise it
Buy time don't lose it

なんでこんないいもの使わないんだ
打ち砕いて壊さないでくれよ
時間を買ってもなくさないでよ

楽をするために苦労を厭わない人たち - Seasarカンファレンス(秋) -

ものすごい熱気と情熱が感じられたイベントだった。Javaのイベントでこんなに人が集まるのか。
そして皆若い。

受講者は２０代の若者がほとんどで、講師の平均は３０代だろう。理事クラスが私と同年代といったところか。私は２０代の受講者に混じって席取り競争に参戦したというわけだ。ひー。

ところで、Seasarのイベントでは、Javaの健在ぶりが感じられて非常によかったのだが、喜んでばかりもいられないかなとも思った。それは、EoDというところにこだわりすぎている点。EoDの究極は作らないことだが、作らないということは、再利用かあるいは自動生成ということになるのだろう。SeasarのDIとAOPの特長を生かすとしたら、自動生成より再利用の方が合っているのではないかと私は思うのだが、Seasarの連中は自動生成の道を選択するらしい。

私はちょっと違和感、危機感を感じてしまった。

Rubyのようなスクリプト言語がWeb2.0の主役となったのは疑いの余地はない。自動生成の道は、RoRに影響されたのかもしれない。SeasarがRubyを意識しすぎなのは今に始まった話ではない。しかしWeb2.0の主役になれなかったからといって、今更、LAMPの生産性に追いつこうと思っても、とうてい無理に思える。

Seasarを理解して開発することは結構大変だ。楽のために苦労するところは結構ある。「楽をするために苦労を厭わない人たち」という表現は、彼らのためにあるのだろう。なぜなら、すげー楽になった！と、毎日、毎日、寝る間を惜しんでフレームワーク作りに明け暮れているからだ。ここで一度冷静になって考えてみてほしい。Javaフレームワークよりスクリプト言語の方がはるかに楽ではないか。

Super Agileとか、Easy Enterpriseは、たしかにいい言葉だ。ワンフレーズで分かりやすいのは結構な話だが、Webアプリケーションをサクサク作るっていわれても、本当にそのようにできるのか。私はJavaで作るWebアプリという発想そのものが疑問符「？」である。LAMPの台頭で、それがもう否めない時期にきているのではないか。

また、プレゼンテーション層に限っては、リッチ化という大きな流れがある。これはもう生産性の話だけではない。JSPだけでは表現力に限界があるし、画面駆動といったって、プレゼンテーション層がサーバにあるのは、Ma○○や、Tee○○にしても同じことだ。AJAXやFLEXのようなUIを実現することをサーバで担おうと真剣に考えているのは、今の時代、Javaぐらいだろうと私は思う。「Webアプリ＝Java」の時代はもう終わってしまっていると私は思う。それを真摯に受け止められるかどうかがJava陣営の試練であり課題でもある。

次回は、私が考えるプレゼンテーション層の設計について述べたい。

AXIS2のデータバインディング能力

Seasarのメーリングリストを見ていたら次のような記事を見つけた。

Axis2自体に問題があるようなので、
DTOの入れ子の確認は、まだ先になりそうです。

2年前に参加したXMLコンソーシアムのTravelXML接続検証プロジェクトでは、AxisではDTOの入れ子に問題があったので、わざわざCastorを使って、Axis＋Castorという組み合わせでやった。あのときはWSDL2Javaを使っても、複雑なDTOの入れ子を作成できなかったのだ。そんな苦い経験があってReflexを作ることになったのだが、それがAxis2となった現在でも改善されていないとは・・。インターオペラビリティを考えるならば、データバインディングにはもっと力を入れるべきだし、それができないなら、やはりSOAP通信というオペレーションだけに特化した方がいい。しかし子要素を配列で渡すかなあ・・普通はListでしょ。こんな話を聞くと、規約をもっと重視すべきだと思う。

【Reflex】 きれいなXMLは好きですか？

　現在、Reflex Resource MapperというXML/JSON⇔JavaBeanのバインディングツールをsourceforge.jpにUpしている。これは、StAXのようなPull型で高速なパーサxppをもつXStreamをベースにしている。XStreamについてはこちらが分かりやすいので参照いただきたい。（超簡単Java Object-XML Mapper "XStream"）

　JavaとXMLのバインディングツールは別段、めずらしいものではない。すでにXMLBeansやCastorなど有名なものが出揃っており、JAXPのような標準的なAPIもある。これらと何が違うのか。

　Resource Mapperで私が最も強調したいのは、「きれいなXMLを扱える」ということだ。

　本来、XMLは可読性をもつデータ定義言語として考えられたものだった。だが、自動バインディングツールを介すと、お世辞にも綺麗とはいえないXMLが出来てくる。バインディングツールでは、やみくもに自動化できればいいというものではない。変換後においても可読性を維持しつつ、開発者がモデリングしたときの構造が崩れないように、うまくバインディングする必要がある。
　私もCastorを愛用していた一人だったが、出力されたXMLに冗長な部分が多くなり鼻につくようになったので、自分でバインディングツールを作ろうと決心した。そのバインディングツールでは、XMLのスキーマ定義から連想されるJavaBeanを作成するだけで、スキーマ定義に合ったXMLを扱えるようしたかった。基にしたXStreamには十分といえるシリアライザー/デシリアライザーの機能はない。Castorなどは、目的の形のXMLを得るために、XSDからJavaBeanを自動生成できるが、XStreamでは手で作成したJavaBeanの構造からXMLを作ることしかできない。とても不便であったXStreamを、Reflexは規約に則ってJavaBeanを作成することで、自由に目的のXMLが得られるようにした。いわゆるCoC（Convention Over Configuration）という考え方で、XMLスキーマからJavaBeanを連想しながら作成することができるようにした。
　（Reflexにおいても、Reflex表現という簡易的なスキーマ言語を作成することで自動的にJavaBeanを生成できる。さらに、Reflex表現の作成は、Reflex Entity Editorを用いることで、グラフを見ながら直感的に作成していける。詳細はこちらを参照いただきたい＝＞Reflex Entity Editor）
　サンプルを見ていただくと分かるが、このModelBeanはいくつかのBeanをList構造に定義して階層を表現しており、図に示すXML構造とJavaBeanとで同じ構造をしている。XSDは特に必要なく、JavaBeanの構造だけで、あらゆるXMLを表現できる。例えば、既存のXMLスキーマはもちろん、RSSやATOMなどのフィード、さらにSOAP通信であっても可能である。
　
　ところで、先日、AXISとの通信テストを実際にやってみた。うまく通信させることができたのだが、HTTPヘッダにSOAPAction : ""を追加する必要があった。SOAPAction なる残骸を考慮しないと通信できないとは・・イタイ話である。

　また、小さく軽い（ライトウェイトである）ことも特長の一つである。jarファイルはxpp(100k)とXstream(241k)とReflex(27k)の３つでサイズはなんと350kbytes。たったこれだけで、Xerces、Castor、あるいはAXISのバインディング機能を実現できてしまうのだ。CastorやXMLBeanを使ってきて、今まで何やってたんだろうと思う。それから、XMLのJavaコーディングでありながら、Xercesにクラスパスを通さないのは実に気分がいいものである。

COMETの有効性

COMETが熱いらしい。とにかく煽られるので、自分を抑えるのに苦労している今日この頃だ。これには、あまり深入りしてはならないと、自分の感性は訴えているのだが、本当はやりたいらしい。さて、その仕組みはもうご存知の方も多いと思うが、一度サーバにリクエストを投げて予約しておき、サーバはそれを一旦保留、サーバ側で何かイベントがあった際に「返答」するというものである。奉仕人(server)のくせに自分の都合で客(client)に要求することが、実質的にできてしまう技術である。今までは、クライアントからポーリングをして、客(client)が奉仕人(server)の様子をときどきチェックする必要があった。別にこれでも十分だと思うが、COMETのよい点は、クライアントからの頻繁なアクセスがなくても、サーバからあたかもコールしているかのように動作することだ。ポーリングよりトラフィックを減らせることになるかも、というのがメリットだと個人的には思っている。でも実際にはサーバのリクスト数が数万は軽く突破したなどの報告もあるので、本当に有効かどうかはよくわからない。コネクション数の増大はJETTY６のContinuationsを使えばなんとかなりそうだが、実際はよく分かっていない。それとは別に、ネットワークの間にPROXYなどがあった場合に、コネクションタイムアウトしたらどうなるのだろうとか、課題も多そうだ。タイムアウトを避けるためにポーリングしたりして・・・・。意味ないYO!　そういえば、JETTY6をReflexに載せる予定だった。COMET対応は避けられないかなあ。

WebサービスプラットフォームのDon Fergusonが来日？

あの、Don Fergusonが来日するらしい。来週、iSUC@札幌で講演するらしいが、これほどの大物にしては地味すぎるなあ。いったいどういうこと？まあ、話が聞ける人は幸運な人ということで。
彼の話は、たぶんWEB2.0で惹き付けておいて、SCAで締めるという感じになるんじゃないかな。SCAはとっつきにくいかもしれないので、参加者は、以下の本を読んでおくといいと思う。それから、IBMがなぜこれほどまでにSCAにこだわるのか、要するに彼がこだわっているからなのだが、そのはっきりとした理由をもし聞ける人は聞いてほしい。

Bloggerについて

このブログのように、Bloggerは自分のサイトに置くことができるので、ドメイン名を変更することなく使えて便利なのだが、カテゴリー分けができなかったり、トラックバック機能がなかったりと、当然あるものと思っていた機能がないのでちょっととまどった。しかし、それらはTagClickとか、HaloScanとか外部サービスのマッシュアップでできるのね。かなりびっくり。ReflexでBLOGを作る前にBloggerをさわっておいてよかったかも。

とりあえず、ホームページをBLOG化

本当はReflexでBLOG化したかったんだけど、いつになるか分からないので、Bloggerの助けを借りることにした。