CMWK

We’re now ready for the next stage of our redesign

via googleblog.blogspot.com

2011年も残すところあと1ヶ月になりましたね。各方面で Advent Calendar もスタートするようです。楽しみですね。

最近は多忙でなかなかブログの更新や Google APIs Client Library for Perl の更新とかできてないのです。

12月は毎日何かを書いてブログを習慣としたいところです。がんばろうっと。（がんばれるか？）

ブログはもっと気軽に書いていきたいですね。

追伸 最近ブログ書くときに Markdown (解説: 英語 / 日本語 ) 使ってます。

Google Developer Day 2011 Tokyo の Ignite で Google APIs Discovery Service についてお話しました。お聞きいただいた皆さんどうもありがとうございました。GDD の話は動画が公開される（？）頃などにまた別のエントリを立てる予定です。

先に UDDI について触れておこうと思います。

UDDI はオワコンか？

私はトークの中で「UDDI はオワコンなので」と言いました。まだまだ現役で稼動しているところももちろんあると思います。アーキテクチャとしては面白いアイデアだったと思います。ぼくは ProgrammableWeb に列挙されている API を UDDI でまとめたいと思ったりしたほどです。でも今ここで UDDI を採用する決断ができるかというとそこは難しいところです。

英語版の Wikipedia の UDDI のページが詳しいので参照しますと、
2000年8月に UDDI が登場しました。その後、UDDI 周辺のさまざまな技術が出てきまして、ベンダーによる UDDI リポジトリが公開されました。しかし、2006年1月にIBM, Microsoft, SAP の3社は公開していた UDDI リポジトリを閉鎖しました。あまり普及しなかったことが縮小されていった原因のひとつだと言われています。そして、2007年後半には UDDI の仕様を作っていたチームが解散となりました。
Microsoft社は製品としてのサポートは引き続き行っていて、現在は BizTalk サーバに UDDI コンポーネントを持っていますし、Java のプロダクトである Apache Foundation の jUDDI も継続して開発が行われています。

昨今はわざわざ UDDI リポジトリに登録しなくてもWebサービスを提供する各社が REST API やそのドキュメントを提供するので、UDDI の必要性は薄れています。また仕様を検討するチームがいないので仕様が進化しません。UDDI R.I.P.（意訳「UDDIよ、安らかに」）というエントリの中で「UDDI is dead」と言われているほどです。
もちろん社内などプライベートな空間での需要はあるでしょう。そういったときに jUDDI や BizTalk サーバを活用して、UDDI リポジトリを立ち上げることはできます。しかし UDDI が当初描いていた世界中のサービスを統合する計画は暗礁に乗り上げていると言わざるを得ません。UDDI リポジトリ利用者が少ない中でグローバルな UDDI の展開はより厳しいです。

ということで、「UDDI はオワコン」と発言しました。

WSDL はオワコンか？

UDDI に関係する技術として WSDL があります。WSDL は Amazon Product Advertising API で現在も使われています。一方、Google では Google SOAP Search API で WSDL の提供をやめましたが、AdSense の WSDL は現在も提供されています。
W3C の Web Services Description Working Group は2007年6月にクローズしましたが、まだ広く使われていることから WSDL はオワコンとは言えない感じですね。ぼくは Ignite で「WSDL はオワコン」と言ったと思いますが、それはちょっといいすぎました。ごめんなさいー。

おまけ

YAPC::Asia Tokyo 2011 に行きました。スピーカーとして、ボランティアスタッフとして、その両面から語ろうと思います。

As A Speaker

Evolution of API With Blogging というタイトルでブログ周辺技術の歴史を振り返りつつ、これからの API のあり方についてお話させていただきました。

gihyo.jp の YAPC:Asia Tokyo 2011 2日目レポートできれいにまとめていただきました。ありがとうございます。

・・・はい。警告をありがとうございました。個人的には今回は滑りました。。
反省がいくつかあります。今回の発表のコンセプトとして Ignite を一気に7本やるイメージでした。Ignite は15秒ごとにスライドを切り替えて合計20スライド、5分で話すというもの。でも7本分はちょっと詰め込みすぎたのでお題目を減らしつつ、1スライドあたりの話す時間を30秒に設定しました。自宅でリハーサルをしたときは大体こんな感じで進めれば大丈夫だな、というスピード感だったので安心していたのです。本番当日、いざ自分のトークの直前になったら重く緊張が圧し掛かってきたので音楽聴いて体ほぐして、さて望んだらストップウォッチみてるのに喋りが速い！その結果スライドが終わる前に話を端折ってしまっているし、ああ全くダメだこりゃ。話す側からすると40分のトークって結構あっという間に終わるんです。で、聞いている側は30分過ぎると中だるみすることがあります。なので30分付近に全然違うネタを織り交ぜたりして緩急をつけてみましたが。。。
振り返るとリハーサルのやり方が緩かったとおもいました。午前3時に椅子に座りながらモゴモゴと話しながら練習するのは心拍数も安定してるし日常生活をしているとき以上にゆっくり話してしまう。でも舞台に立ったときは心拍数が多いから体感時間が午前3時とは違うんですな。
それからrjbsの闇のEメール伝説 (Email Hates the Living!)を見ていて、みんなが共感できるものをシェアするのは盛り上がるよなあ。YAPCでは実際に起きた体験談は受けますからね。
そんなこんなで反省点としては次の通りです。

• リハーサルは人間的な活動をする時間に舞台と同じ体勢で
• 緊張をほぐすのにイヤホンして大音量の音楽を聴いてストレッチする
• 事前に大量の水分（そうしないと最初っからのどが渇くからね）
• 40分のトークでは30分あたりからの変化をつけるのがポイント
• みんなに共通するネタ（いつも sigh となるようなネタとか）を出すと受ける

この反省を YAPC::Asia Tokyo 2012 やその他の発表の場で生かしたいと思います。まだどこかで話したときには成長しているところをお見せしたいと思います。

トーク終了後に Mobile Link Discovery をいかにスマートフォンに対応させるか的な質問をいただいたりして聞いてくださった方からの直接反応があったのはうれしかったです。

同僚がプレゼンツールを作りかけてくれてサポートしてくれました。ありがとです。（本番では Ubuntu の OpenOffice だったんですが。）

As A Staff

今年もボランティアスタッフという肩書きでも参加しました。最初に東工大でやった2009年の以来、2回目です。2010年のときは前夜祭の前のお手伝いと最終の片付けをちょこっとお手伝いさせてもらったり、ここ3回分は裏方の様子も見たりしてきました。今年はボランティアスタッフが42名ということでしたが人数が多いと負担が小さくなるので以前に比べたら楽になりました。イベントの規模が大きくなるにつれてスタッフのモチベーションも高くなっています。メンバーは新人と経験者がうまく混ざっているし、もちろん941さんや牧さんやみらのさんの指示などもあって、チームのスキルが高くなっています。2008年のときは各会場を行ったり来たりすることもありましたが、もうそんな必要はなくなって各自が担当のタスクをこなすだけという感じです。すばらしいですね。
今回の僕がやった仕事を紹介します。

• 10/13(木) ノベルティの詰め合わせ、ノベルティや機材を会場へ移動
• 10/14(金) 講堂での会場設営、スピーカーの案内、ビデオ録画
• 10/15(土) 講堂でのスピーカーの案内、ビデオ録画、会場撤収

100枚くらいTシャツが入った段ボールを手で持って運ぶですよ。力仕事。スクリーンとかプロジェクターとか機材も安全に運ぶです。講堂と蔵前会館の間を何往復しただろうか。いい運動ですよ。（歳のせいか膝にきたけどさ。。）これは例年の作業。想定内。（膝は想定外。）
ノベルティの詰め合わせも1時間くらいで終わったし（前は2時間くらいかかってたかなあ）、撤収も超速でできたし、とてもスムースでした。びっくりよ。会場の清掃もとても丁寧にしましたね。
ビデオ撮影も録画が途切れたりしないよう常にチェックしているし、音声が途切れないようにセッションが終わるたびにビデオ用のBluetooshマイクの電池換えたり、ワイヤレスマイクの電池の充電が切れないようにしたり、タイムキーパーがスピーカーに時間を伝えたりね。結構細かいこともしてます。

しかし想定外なトラブルが結構ありました。

10/14(金)は朝に会場に備え付けられたプロジェクターでスタッフのMacbookつかってテストしてOKだったから安心してたけど、オープニング直前に別のMacbookつかったらNGになっちゃって。原因不明。急遽、会場備え付けのプロジェクターを諦めて、レンタルしてたプロジェクターに切り替え。早くからチェックインした人はプロジェクターの設置を見てたと思いますが、僕らは朝8時から設営に入ってます。（5:30起きだよ。）だけどトラブっちゃったからぎりぎりまでかかっちゃった。

10/15(土)はPAシステムが突然のダウン。マイクから音が出ないわ、電源は死ぬわ。スピーカーの方には地声でトークしてもらうという前代未聞な展開になってしまいました。。（伊藤直也さんが電源ケーブルのチェックとか手伝ってくれたり。ありがとうございました。）スタッフが大学のサークルの人とかに掛け合ってマイク調達してその場を凌ぎ、気がついたら別のPAシステムが復活。なんとか元に戻せました。ほんと焦りました。

そんな突然のトラブルも何とか回避できるくらいスタッフの処理能力は高いです。スタッフの功績って見えなかったかもしれないけど、いろいろ支えているんですよ。しかもボランティアなんでJPAからもYAPCからも給料出ませんし、その上会社休んできたりさ。いろいろがんばりました。

あと、これはいわゆるおっさんの冗談混じりな愚痴だけどさ（笑）、牧さんは楽させてもらったと言うけど、僕は重たい段ボール持ったりしてて、「あ！重田さん、それは僕らが持ちますよ！」的なさ、そういう優しさがあってもよくね？もっとおっさんを労わってあげて！

って言ってる時点でもうボランティアスタッフは卒業かなと思いました。これからボランティアスタッフやる人たち、がんばれ！応援してるぞ！

Precious

今回の宝物は Blog Hacks に miyagawa さんと naoya_ito さんにサインをいただいたこと。自分のスライドでも使わせていただきました。伊藤直也さんが「え！これ何年前だっけ？？7年前？まさか今頃サインを書くなんて」って驚いていました。そりゃそうです。もう絶版になっていますから。でも僕はこの本からの影響はとても大きいんです。ブログの会社で働いているくらいですからね！

あとは毎年オライリーさんのブースにあるガチャガチャです。あれはやっておかないと。また来年もあったらやりますよ。

Next

YAPC::Asia Tokyo 2011 が終わり、もう僕は次へのステップを踏み出しました。まずはスライドの中でお話させていただきました google-api-perl-client を充実させること。次に同様にスライドで触れたブログの Import/Export フォーマットの検討もしてみたいなと。なので camlistore とか触ってみるかとかフォーマットの標準化とかできるといいよね。あとは SPDY に興味があるのでその辺とか。

ということで今回もまたたくさんの影響を受けた YAPC::Asia Tokyo 2011 でした。みんなありがとう！！

Hello Perl mongers,

I'm happy to say this. I just pushed Google API Perl Client to github right now.

https://github.com/comewalk/google-api-perl-client/

If you try this module, you can run like below.

 $ git clone git://github.com/comewalk/google-api-perl-client.git
 $ cd google-api-perl-client
 $ perl -I lib eg/urlshortener/cli_public_access.pl

Also, I put psgi app.

 $ plackup eg/urlshortener/sample.psgi

If you embed this module in your application, you may need both Client ID and Client secret for private access. You can get Client ID and Client secret at Google APIs Console. Please replace "<YOUR CLIENT ID>" and "<YOUR CLIENT SECRET>" to your ones.

Samples list is following page at Google Project Hosting. I'll add more API samples later.

http://code.google.com/p/google-api-perl-client/wiki/Samples

Also, this module is using Google Project Hosting. The URL is below.

http://code.google.com/p/google-api-perl-client/

I'll update this blog for announcements of Google API Perl Client. If you're interested in this module, please add this blog to your feed reader.

If you have any questions or suggestions, please feel free let me know at Google Groups google-api-perl-client.

Enjoy!

via google-api-perl-client.blogspot.com

I posted above. I mentioned before about Google API Perl Client. I pushed the module to github. If you're interested in this module, please feel free watch it on github.

Also I posted an announcement at Google APIs Discovery Service forum.

Enjoy!

I went to Jesus Jones show at Akasaka Blitz in Tokyo, Japan. I was very excited. Jesus Jones rocks!

I thought that Japanese audiences seemed to love Liquidizer - Jesus Jones 1st album - strongly. They were singing, jumping and dancing at the floor. Yeah! me, too!

Set list - Akasaka Blitz - Tokyo, Japan. 22.08.2011:

1. Who? Where? Why?
2. Move Mountains
3. International Bright Young Thing
4. Caricature
5. Real Real Real
6. Nothing To Hold Me
7. Get A Good Thing
8. Never Enough
9. All The Answers
10. Culture Vulture
11. Right Here Right Now
12. Zeroes & Ones
13. Bring It On Down
14. Info Freako
15. Idiot Stare

[Encore]

1. Message
2. Blissed

via plus.google.com

Tokyo Katie uploaded video on YouTube. Thanks for sharing!

Jesus Jones Akasaka Blitz Tokyo Japan 22nd August 2011

s/I will see you/I will show you/

https://twitter.com/#!/yapcasia/status/106577828463656960

（Blackbird Pie がダウンしていたから代替手段です）

ということで、YAPC::Asia 2011 のトークが決まりました！

チケットは絶賛発売中ですので、トーク一覧をご覧いただきながら、ぜひともチケットをご購入いただければと思います。

今年の YAPC::Asia では、ゲストスピーカーとして Ricardo Signes、Marc Lehmann、木村 秀夫 (敬称略、順不同）が登場します。さらにスペシャルゲストに、宮川達彦、Jesse Vincent（敬称略、順不同）と豪華なメンバーがそろいました。さらにスイーツエリアをご用意しており、より身近なコミュニケーションができると思います。

今年は多くの企業様よりスポンサーをいただいておりまして、YAPC::Asia 2011 のサイトの右サイドバーにロゴが掲載されております。こんなに多くの企業様から注目されているイベントなのです。今年は遠方からの参加者支援策もしていただいたり、東京だけではなく日本全国からも注目されていますし、Perl のイベントとしては YAPC::Asia は世界最大規模になり、諸外国からもエンジニアが参加します。とても注目されています。

それから今年初の試みとして個人スポンサーがあります。こちらも本当に多くの皆様にサポートしていただいて本当にうれしいです。

当日はボランティアスタッフを含めたチームで YAPC::Asia 2011 のサポートをしていきますので、円滑な開催ができると思います。

YAPC はプログラミング言語の Perl が中心のように見えます。もちろん Perl の話題が多いですが、Perl を採用している多くの企業のノウハウが YAPC::Asia を通じて垣間みることができますし、直接質問なども出来ます。前夜祭を含む3日間を通して、エンジニアが何かを習得し、そして交流を深める、有意義なイベントになると思います。上司を説得するためのテンプレもありますので、YAPC::Asia 2011 にぜひお越しください！

最後に宣伝ですが、Evolution Of API With Blogging と題してブログツールを取り巻く API 周辺技術の進化についてお話させていただきます。ご興味がありましたらぜひお越しください。（発表日程は変更になる可能性があります。）

Tomoyasu Hotei is a guitarist. As you may know, he made a theme of Kill Bill named BATTLE WITHOUT HORNOR OR HUMANITY. Or you can see also wikipedia. And he launched official YouTube channel at 10 Aug 2011. His videos look like a movie. Check it out!

By the way, I can play the guitar. When I was around 15, I started to play the guitar. Of course, Hotei is my biggest influence!

I'm happy to hear that he launched his channel. Also I'm glad to share his channel to everyone :D

When I was reading github API documentation, I found that github is using PATCH method for updating data. (e.g. Gists API)

And Today Google posted an entry about using PATCH method for partial update at Google Code Blog. They mentioned Google Buzz sample at the entry.

PATCH method is very useful for compressing data. Although Google told us, we can get more faster for sending data. If we have an oppotunity for using PATCH method, I think that we should use it positively.

In REST(Representational State Transfer) world, to update resources uses PUT method. But we can start to consider PATCH method for updating resources. 

I would like to quote following paragraph from RFC 5789 (PATCH Method for HTTP).

Clients need to choose when to use PATCH rather than PUT. For example, if the patch document size is larger than the size of the new resource data that would be used in a PUT, then it might make sense to use PUT instead of PATCH. A comparison to POST is even more difficult, because POST is used in widely varying ways and can encompass PUT and PATCH-like operations if the server chooses. If the operation does not modify the resource identified by the Request- URI in a predictable way, POST should be considered instead of PATCH or PUT.

via www.ietf.org