[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の助けを借りることにした。