« 2006年07月 | メイン | 2006年11月 »
2006年08月24日
Gmailで致命的に足りない機能
Gmailが招待制から登録制になったという事で（一般紙にも掲載されていましたね）この機会に前から気になっていた事を...Gmailってスレッド表示出来なくないですか？
カンバセーション（会話）という括りで纏められるけれど、本来のスレッドの枝がバッサリとフラットになってしまって、会話がまったく追えないのでとても不便しています。特にメーリングリストの場合、スレッド内で個々のメールへの返答とかが誰から誰のどのメールへの返答だかまったく分からなくなる場合があってとても困ります。
誤解の無いように一応書いておきますが、Gmailは上記の一点を除けば素晴らしいメールサービスです。特にスパム判定率が高いので個人的なメールアカウントとメーリングリスト用のメールアカウントをすべてGmailに転送しているほどです。ただ、スレッド表示が出来るようになってくれさえすれば…
追記：
よく考えたら、Webメールサービスはもう５年ほど使っていないので最近の他のWebメールサービスではどうなっているのか知らないです。もしかして、所謂カンバセーションという括りすら無いのかもしれない（笑）
本来のスレッド表示（秀丸メール）
投稿者 BlogWrite担当 : 11:44 | コメント (0) | トラックバック
GData API for Google Base
という事で、期待していた通り、Google Base APIが公開されたようです。
New GData API: Google Base
http://code.google.com/apis/base/
ただ、やっぱりGoogle Base自体がまだ内容的に欧米セントリックという所があるので、（というかGoogle Base自体日本語化されていない？）ちょっと残念ですが、このAPI公開は多方面で非常に意味があるなぁと思います。検索エンジン業界にとってもその他の分野でもこの意味は長い目で大きな影響がある気がします。
関連記事：
Google Base
不動産物件情報とXML（Google Base）
投稿者 BlogWrite担当 : 04:11 | コメント (0) | トラックバック
2006年08月17日
Google不動産検索
Googleのサイトを色々弄っていたら、Googleの試験用のサイト内で、潜在的な新サービスを見つけちゃったよ、という話。
What's in Google's Sandbox?
日本語版画像
その中で、「Google不動産検索」とあったらしい。他にも「Google イベント」「Google Guess」「Google オンライン評価」「Google RS2」「Google Writely」「Mobile Marketplace」「SSD」「Weaver」「WiFi」「トーク」「ローカル ビジネス センター」等々１４のサービス。
Google Baseでも簡単な物件リストを追加することが出来たがあくまでも超シンプルなリストの上にあまりインパクトが無かったです。不動産検索に特化したサービスが出てくるとしたら大歓迎ですね。
あまり一般には知られていないのだけど、日本では、不動産物件情報を公開するのに、一件につき幾ら、という感じでサイトにお金を払っています。
つまり、日本ではコンテンツを持っている不動産会社が、お金を払ってコンテンツを提供しているのです。そう、普通お金を対価として受け取ってコンテンツを提供したり、無料で提供して無料でサービスを受け取る、のとはまったくの正反対。
例えば、Yahoo！Japanに物件情報を掲載する事で、お金がYahoo！Japanに流れるわけです。そしてYahoo！Japanは物件情報をネタにして集めた閲覧者を対象にした広告を出して、別途広告料を広告主からもらう分けです。
さすがYahoo！Japan
Googleだったら普通に完全に無料で物件掲載するでしょうけど。
ブログでいうと、一記事掲載するのに７００円払って、且つ広告が勝手に挿入されるというありえない状況。いつまで放置するのでしょうかねぇ...この状態。
投稿者 BlogWrite担当 : 16:59 | コメント (0) | トラックバック
RESTにおけるベストプラクティス： エラーハンドリング
RESTfullなAPIにおいてのエラーハンドリングについては重要なのですが、今まで（特に日本では知っている限り）あまり言及されたことがなさそうなのと、オライリー系のサイトでたまたま今日良い記事 RESTful Error Handling を見つけたので、ココで紹介したいと思います。 （2003年12月の記事ですが何故か見落としていました）
この記事では、REPSfullなWebアプリケーションにおいて、エラーが発生した時の動作は（調査した所）一般的にいって４っつの方法が利用されているとしています。
１．HTTPステータスコードのみ
例えば、
http://www.example.com/xml/book?id=1234&dev_token=ABCD1234のようなアドレスでGETした時、もし"id="によって指定されたデータが見つからなかった場合、HTTPステータスコードの404 Not Found を返す、といった具合。
２．空のレコードセットを返す
例えば、Atomフィードを返すようなケースで、エントリが一つもないフィード空フィードを返す。この場合、そもそも不正なIDなのか、単にまだ存在しないのかなどは分からない。
３．HTTPヘッダーを拡張する
HTTP/1.1 200 OK
...省略...
X-DAS-Status: 403
Content-Type: text/plain
Content-Length: 10
Date: Sun, 30 Nov 2003 21:02:13 GMT
上記のように、HTTPヘッダー内にアプリケーション固有のエラーコードを埋め込む。（注：確か偉い人がX-＊＊のような拡張は安易に行なうべきではない、といった事を言っていました）
４．XML文書を返却する
<?xml version="1.0" ?>
<xoomleError>
<method>doGoogleSearch</method>
<errorString>Invalid Google API key supplied</errorString>
<arguments>
<hl>en</hl>
<ie>ISO-8859-1</ie>
<key></key>
<q>oreilly php</q>
</arguments>
</xoomleError>
のようなXML文書を返却して、エラーの詳細を通知する。
RESTにおけるベストプラクティスではRESTベースのWebサービスではどの方法がベストプラクティスと言えるのでしょうか、と筆者は問いかけ、未だベストプラクティスといえるものは無いようだと述べています。
しかし、もっとも重要なのは、「人間が読めるエラーの説明文」、「アプリケーション固有のエラー」、「機械処理できるエラーコード」であり、この三つのカテゴリを含む、少なくとも下記の条件を満たすのが大事なんじゃないかと述べています。
- HTTPステータスコードはHTTP通信に限ったエラーのために用い、アプリケーション固有のエラーには用いない。
- エラー発生時には、必ず詳細を含んだXML文書を返却する。
- XML文書にエラーコードと共に人間が読めるエラーメッセージを含めよ。具体的には下記の例：
<?xml version="1.0" encoding="UTF-8" ?>
<error>
<error_code>1001</error_code>
<error_msg>不正な Google API キーです。</error_msg>
</error>
これを実践することによって、Webサービスは利用側の苦労は軽減し、問題が起きた時の対処も楽になる。エラーコードを元に適切な挙動をする事も出来る。
記事は大体上記の感じです。最後のまとめ部分は、１００％同意する所です。以前、関連する事を、REST原理主義という微妙な記事で書いてしまいましたが、元々はAtom Publishing Protocolのワーキンググループ内での議論がきっかけでした。
個人的にAtom Publishing Protocolでエラーハンドリングのことが何も決まっていないのは問題だと思い、エラーフォーマットを提案していたのですが、大体において反応は、あると便利（４．XML文書を返却する）というのが多数、あるべきというのは少し、無いべき（１．HTTPステータスコードのみ ）というのが少数だが激しく、という感じで結局、仕様には含めない、という事になっています。（このワーキンググループでは、異論があるのは本仕様外とする、という傾向が常々指摘されているw）
つまり、
「人間が読めるエラーの説明文」： なし（追記：正確にはリスポンスのボディに何かが返される場合がある。何かは極端な話×印の画像かもしれない。文字列だとしても、JSONかもしれないし、XMLかもしれないし、ただのテキストかもしれないし、Base64エンコードされているかもしれない。さらには文字コードの判定と変換といったWebブラウザ並の処理の手間がかかる。もしこれが特定のXMLフォーマットが返ると決まっていれば、これらの問題と手間はすべて解消される）
「アプリケーション固有のエラー」:： なし（追記：正確にはHTTPステータスコードで間に合わせる）
「機械処理できるエラーコード」： HTTPステータスコードで間に合わせる
という残念ながらベストプラクティスとはかけ離れたものとなってしまっています。最終的な希望は、Atomのコア仕様に含まれなくても、拡張仕様として後付けできるという事で、今後の試行錯誤で何らかのフォーマットが出来て、それにまとまっていくことが考えられます、というか強く希望しています。
なお、ホンモノのRESTベストプラクティスを読みたい方は、こちらのスライドをどぞ。
投稿者 BlogWrite担当 : 15:31 | コメント (0) | トラックバック
Blogger + GDataとoptimistic concurrencyなど
Bloggerのブログがアップデートを控えてベータ版が公開されています。主な変更は、
- GMailでメールにラベルをつけるのと同じように、記事にラベルをつけられる。（カテゴリの感覚）
- 記事を誰が読めるか指定出来る（Voxと同じ方向性）
- マウスのドラッグ＆ドロップでレイアウトを変更
など。ここで新機能の紹介と、日本語のニュース記事は、ここや、ここ。 今後徐々にベータ版に移行できるようにしているそうです（現在移行できるブログに制限がある）。
感覚的には、日本ではあまりBloggerは利用されていない感じがして身近にインパクトはありません。ただし、GoogleのGDataAPIに関する動きの一環として、今回のベータ版からGDataAPIを利用した投稿が出来るようになったのが興味あります。
GDataAPIと言えば、新しいAtom Publishing Protocolベースの規格で、今の所、Googleカレンダーそして今回のBloggerで使えるようになりました。（Google Baseで使えるようになるのが待ち遠しい..）
Bloggerでの利用方法と詳細は、Using the Blogger Data API。
個人的な感想としては、Atom Publishing ProtocolベースのGDataAPIといっても、一癖ある感じです。特に、AtomicとIBM系のAtomサーバー実装などで行なったテストなどと比べると幾つか面倒な点がありました。
一つは、GDataAPIの独自のクセのある認証方法、もう一つはoptimistic concurrency (OCC)。 Googleを皮切りに、IBM系のシステムでもこのOCCを検討しているらしい...。と同時に、一部で議論になりつつもあるのがOCC。
意図しない上書きなどによる、データの誤った喪失を防ぐにはOCCは安易な方法だけれども、万が一、かち合った（conflict）場合の処理方法（DiffとMerge）、を考えると現実的ではないし、第一ぜんぜん楽しくない。例えば、バージョン管理システムのSVNでConflictがあると、「エーイ面倒くせーい、一旦全部削除してしまえ」という事がたまにあるのだけど（ほんの稀にですw）、それと似た感じ...
最悪なのは、記事を編集して投稿したら、Conflictが起きたので、今のは破棄するか、最新の記事を取得し直して一から書き直してください、見たいな事が起きてしまう事ですよね...。
他の方法としてはClient-ServerデータベースアプリケーションでよくあるLock。これだと、某ユーザーがアクセス中なので変更出来ません状態に陥ってしまいます。なので、多くの場合、後勝ちの方法で、最後に更新されたデータで上書きされる、というのが現実的に採用されています。多分現在のブログは、この後勝ち。どれもそれぞれ欠点というか問題があります。
カレンダーアプリケーションのようなケースでは良いですが、その他のケースでは個人的には、安易に特定の仕組みを導入するよりかは、実装と運用方法でカバーするのがベストのような気がしますが、もうちょっとこの件追っかけて行きたいと思います...。