[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陣営の試練であり課題でもある。

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