Oct 30, 2006

PaginatedFeedのバックストーリー

Ogawa::Buzz: PaginatedFeed公開の背景と意義を説明するのがこのエントリーの目的です。

Movable Typeを含むブログツールを使っているほとんどの人にとって、RSSやAtomとは、再構築時または閲覧時に勝手にレンダリングされる特定のXML形式で書かれた「ファイル」だ、そのファイルをアグリゲートしてブログリーダやブログ検索などのサービスが提供されるのだ、という認識かもしれません。

物理的な実体としてのフィードは確かにそういう認識であってもよいのですが、フィードはブログの「インタフェース」でもあります。それぞれブログには(各Webページのlink要素によって)フィードURLが関連付けられており、フィードURLは、GETリクエストを受け取るとフィード(=機械的に操作可能なブログのメタ情報)をレスポンスとして返す「Web API」になっています。ブログリーダやブログ検索などはそのAPIを介して収集したフィードをサービスの対象にしているわけです。

そう考えると、ただ最新のN件のエントリーを取り出せるだけでは、Web APIとしてはあまりにもしょぼくね?と思えてくるはずです(思えない?そうですか、それでもいいですが私はしょぼいと思います。もっとリッチなAPIを提供してアプリもそうしたAPIに対応するようになった世界の方に夢を感じます。)。

例えば、Google Blogger (beta)のフィードURLは、GData APIのエンドポイントURLになっていて、GETリクエストによって(Paginationを用いて)全エントリーの内容とメタ情報、エントリーのEditURIを取得できるようになっています。もちろんそれだけでなく、フィードURLやエントリーのEditURIに対して更新操作も可能です。

GData APIなみの機能を実現することは当面無理だとしても、全エントリーとメタ情報を取得できるようにすることは難しくありません。そういうわけで、それを実現したのがPaginatedFeedなのです。

Paginationのナビゲーション用にOpenSearch 1.1 Response elementsを含むようにしたことに関しては若干の議論の余地があるかと思います。もしナビゲーション用のlink要素がなければ、「PaginatedFeedに特定の引数とともにGETリクエストすれば所定のエントリー群の情報が得られることを知っているクライアント」でなければ任意のエントリーの情報を取得することはできません。これに対して、OpenSearchのResponse elementsを含めておけば、OpenSearch用のクライアントが共通のインタフェースでフィードを取り扱える、という利点があります。ついでに言うと、これはGData APIのフィードでも採用している方式でもあります。もちろん、alternativeな方法を採ることもできますが、そうする意味もないでしょう。

さて、もう語ることはあまり残っていません。

PaginatedFeedを活用するには、特定の引数とともにGETリクエストすれば所定のエントリー群の情報が得られることを知っているクライアントかOpenSearchクライアントを用意する必要があります。そうでなければ通常のフィードと変わりありません。

ブログ検索用のクローラーがOpenSearchに対応していれば、いずれは全文検索してくれるようになる(かも)、と信じて枕を高くして寝ましょう。

そうそう、これはまったくコンテキストが異なりますが、Movable Typeのmt-search.cgiをOpenSearchに対応させるという話なら、Niall Kennedyがずいぶん前に書いているので、そちらに興味がある方は以下を参考にされるとよいでしょう。

OpenSearch standard using Movable Type

Oct 29, 2006

PaginatedFeed公開

Movable Typeで、Pagination機能付きのRSSやAtomを生成するツールを作ったので公開しておきます。

PaginatedFeed - ogawa - Pagination機能付きのRSSやAtomを生成するMovable Typeアプリケーション。 - Google Code

Movable TypeでAtomフィードやRSSフィードを静的に生成するとき、最新の指定個数のエントリーしか対象にならないのが面白くないとは思いませんか。私には、こうした安直な「部分フィード」はいわば生成コストや取得コストの軽減に特化された形式であって、対象コンテンツセットの「表現」としての性質は必ずしも芳しくないのではないか、と思えてなりません。例えば、部分フィードを元に対象コンテンツ全体を把握することも対象コンテンツの更新内容全体を把握することもできませんし、部分フィードを対象とした検索エンジンはブログ空間を対象とした検索エンジンとはなり得ません。

思い切って全エントリーを含むフィードを生成するというソリューションもあり得ますが、フィードが巨大になるため、再構築を行うWebサーバの負荷、(HTTP Compressionを使ったにせよ)トラフィック、その巨大フィードを利用するクライアントプログラム・サービスの負荷が問題となります。

一方で、OpenSearchのレスポンスフィード(要素)やGoogle Blogger betaのAtomフィードは、openSearchというXML名前空間を使ったフィードのPaginationを実現しています。

これと同じことがMovable Typeでも実現できればよいのではないか、じゃあ作っちゃえ、と思って作ったのがPaginatedFeedです。PaginatedFeedでは、表示したいエントリーのオフセットと件数を指定してフィードを生成できます。また、フィードにOpenSearchレスポンスに必要な要素を追加するのに便利ないくつかのテンプレートタグを実現しています。

興味のある方は上記リンクよりどうぞ。

Oct 26, 2006

日本シリーズ、昨日の時点で1勝3敗。

第三戦を観た時点で1勝4敗で日本シリーズが終わりそうなことは、中日ファンなら誰しも認識していたはずです。中日ドラゴンズという球団は空気を読み過ぎなのです。よく考えてください。あなたの応援している中日ドラゴンズはこんな球団だったはずじゃありませんか?

  • オープン戦は絶好調、開幕戦後は期待したほどでもない。
  • 相手エースが絶不調で一か月勝ち星が付いていないとき、勝ち星を付けてあげる。
  • 相手ホームランバッターがスランプで一か月ホームランを打っていないとき、スランプ脱出の手助けをしてあげる。
  • 連勝中のチームには連勝が止まらないように負けてあげる。
  • 連敗中のチームには浮上のチャンスとなる貴重な勝ちを与える。
  • 相手ルーキー投手がびくびくしながら初先発したときには、二桁三振や二桁残塁を記録して自信をつけさせてあげる。
  • 味方ルーキー投手がびくびくしながら初先発したときには、二桁三振や二桁残塁を記録して見殺しにして、タフな中継ぎ投手の道を歩ませる。
  • タフな中継ぎ投手が余りすぎてトレードに出した場合、必ず過分な「恩返し」をされる(2安打完封とか15奪三振とか)。
  • 最多勝投手のタイトルはなるべく獲らない。獲るときは、できれば複数投手で獲れるようにしたい。ときどき空気読まない投手もいて困る。
  • ホームラン王のタイトルはできれば獲らない。獲るときは、なるべく複数選手で獲れるようにしたい。空気読まない奴は長続きしない。
  • 中継ぎ陣が崩壊している事実を十分承知していながら、「投手王国」と呼ばれると悪い気はしない。
  • 無死満塁と二死満塁では得点できない。
  • 無死満塁で4番打者ならゲッツーフラグ(または4番打者が空振り三振、5番打者がゲッツー)。二死満塁で4番打者なら空振り三振フラグ。
  • 落合以外の4番打者の得点は決勝点にならない≒落合以外の4番打者の打点で先行したときには必ず同点または逆転される。
  • 「代打 立浪」「投手交代 中里」で異常に期待感が盛り上がるのはいつものことだが、いつも結果は期待したほどのことはない。
  • 日本シリーズの前評判は常によい。
  • メジャーリーグに挑戦するような大物選手は育たない。今のとこ訳あり移籍の大塚晶則しかいない。
  • …にも関わらずなぜか勝率だけは高い。ので他球団のファンから疎まれる。

違いますか?違わないでしょう。それが、中日ドラゴンズです。世間が何となく対戦相手を応援気味な雰囲気のとき誰より早くそれを察知して負ける常勝軍団、それが中日ドラゴンズです。

だから、日本シリーズの残り試合にも強力な「スルー力」をもってのぞむべきなのです。日ハムの外野のパフォーマンスにいちいち腹を立ててもしかたありません。先発投手が1回に先頭打者を四球で歩かせても福留・ウッズがチャンスに打てなくても、それはシーズン中もあったことです。スルー力を発揮して「ああ、まただ…」と笑って済ませればよいのです。というか、むしろ「は?日本シリーズ?そんなイベントありましたっけ?」くらいの勢いでスルーしてよいのです。

…それができないわけだが。

Oct 19, 2006

Google Calendarの公開カレンダー騒動

公開カレンダーの中身が検索できてしまうというGoogle Calendarの仕様にまつわる騒動。

大西 宏のマーケティング・エッセンス:【警告】Googleカレンダーで情報流出?
スラッシュドット ジャパン | Googleカレンダーからの情報流出にご用心

その後、昨日だか今日だか対策が行われた模様で今は「デート」や「合コン」で検索できなくなっている。最初、短いキーワードでの検索を禁じただけ(「ゼミ」はNG、「セミナー」はOK)かと思ったのだが、「デモ」で検索できるという例外を見つけたのでどうもそうではないようだ。つまり、

人手で禁止ワードを設定したっぽい…

確かに仕様を維持したままプライバシーを保護するにはこれしか対策方法がない罠。でも、

「デート」「合コン」(Halfwidth Katakana variants)

では相変わらず検索できるよ(笑)

さあ、イタチレースの始まりだ。がんがれ、Google。

で、私がこのエントリーで言いたいことは何かと言えば、最終的に問題の解決をみるためには、(1)現在「公開」状態になっているカレンダーを一旦強制的に「非公開」にする、(2)公開状態にする手続きをメールなどを用いた認証を要する方式にする(さらに定期的に公開設定の確認を求めるメールを送りつけるとか)、くらいのことは必要だということだ。そうしないとヒューマンエラーの確率を(訴訟が起きない程度まで)十分下げることは難しいだろう。正論で申し訳ないけど。

2006-11-14追記: いつの間にかHalfwidth Katakana variantsでも検索できなくなってるね。

Oct 18, 2006

さくらの専用サーバのOSを新調してみた

気がつけばuptimeが241 daysにも達してしまっている、このブログをホスティングしているさくらのレンタルサーバなのだが、ひさびさに再起動することにした。これとかこれとかこれとかあってもっと早くアップデートするべきだったのだが、ようやく重い重い腰を上げて作業したからだ。

6.0-RELEASE-p4から一気に飛んで、6.1-RELEASE-p10。

最初にセットアップしてから(Ogawa::Buzz: さくらの専用サーバに「亡命」します)から一度も再起動していなかったらしい。安定しているというかなんというか。

さくらの専用サーバの場合にはGENERIC kernelで構わないので(RELENG_6_1のソースが/usr/srcにあるとすると)、

# cd /usr/src
# make buildworld; make kernel
 /usr/src/UPDATINGにはここでrebootしてシングルユーザモードで起動と書いてあるが華麗にスルー
# mergemaster -p
# make installworld; make delete-old
# mergemaster -i
# reboot

とやるだけでよい。mergemasterのときに注意する必要があったのは、/etc/groupと/etc/mail/mailer.confだけ(私の場合)。あと/etc/localtimeが古いままだったので以下のように新しいzoneinfoファイルで上書きするのを忘れずに。

# cp -p /usr/share/zoneinfo/Asia/Tokyo /etc/localtime

何のトラブルもなくてつまらんのー。

Oct 10, 2006

10月10日 Ochiai監督胴上げを安全に成功裏に実行した

キタ━━━(゚∀゚)━( ゚∀)━(  ゚)━(  )━(  )━(゚  )━(∀゚ )━(゚∀゚)━━━!!!!!

前夜祭としか言いようのないヤクルト戦(Yahoo!プロ野球 - 2006年10月9日 ヤクルトvs.中日 結果)の結果、たまたま私が買っておいた、巨人戦(東京ドーム)のチケットが優勝決定試合のチケットになってしまった。どうしよう。今更ながら自分の勘のあまりの良さに恐れおののいている。ついで言うと、この試合は東京ドームの今年の最終公式戦でもあるわけなのだけど(だから試合後に原監督のスピーチもあったっぽい、その頃抜け殻状態だったので覚えていない)、実は9月13日にフルキャストスタジアム宮城で催行される予定だった試合の振替試合でもある。だからチケットは自動的にフルキャストと同等の料金になる(フルキャストのチケットは差額なしに東京ドームのチケットに振り替えられるので、それ以外のチケットも同価格にする必要がある)。私がいつも買っている内野席Bだと3700円のはずなんだけど、この試合に限っては2500円。優勝決定試合にも関わらずなんてリーズナブルなんだ。いやそんなことはどうでもよくって。

試合の結果はというと、もうあり得ない展開。

2006年10月10日 巨人-中日 22回戦 東京ドーム

ウッズが4回表に3ランホームランを打ち、前半戦の川上を連れてくれば3-1くらいであっさり勝てそうな試合だった。7回裏に入るあたりで私のシートの20mくらい前にNOBUKO総監督入場、NOBUKOコールが始まり、川上がへそを曲げたのか、(例年通りの)後半戦の劣化ぶりのゆえか、ソロホームラン×3本で同点に追いつかれ、3対3のまま延長に突入。11回表、巨人のピッチャーが高橋尚成に交代して福留、ウッズがシングルヒットで無死1,2塁。ここで通常はウッズに代走を出すのだが、今日は出さなかったのが最大のポイント。続く3打者が連続凡退したが、つけいる隙は感じさせる。そして裏に岩瀬投入、二岡・李から連続三振を奪ってあっさり三凡、負けはなくなったと確信する。そして12回表。谷繁H、岩瀬犠打失敗、荒木がジップヒット、井端大振りでゲッツーフラグが立つもしぶとくHで一死満塁(のピンチ)。福留が華麗にタイムリーで100打点達成、なおも続く一死満塁(のピンチ)で前の回代走を出されなかったウッズがグラスラ…。三塁側ドラゴンズファンは見たこともないほどの盛り上がり。ビールが降ってくるよー。

ばんざーい!ばんざーい!ばんざーい!!

もう二度とこんな試合を生で観ることはできないんだろうね。足腰が痛いよ。


この展開は読めた(笑)
【楽天市場】ドラゴンズ優勝大特価セール

Oct 8, 2006

Create Event at Here!: Googleマップで場所を選んでそこからカレンダー登録する Bookmarklet

一年以上前、「Googleマップで任意の場所にピンを立てる」Bookmarkletを作りました。今でも問題なく使えます。

Ogawa::Buzz: Pin It!: Googleマップで任意の場所にピンを立てる Bookmarklet

で、つい最近、Going My Way: Google Mapsの任意の場所に吹き出しを表示して、好きなテキストを表示する方法という記事で、Google Calendarのカレンダーエントリーの「Where」にGoogleマップと同じ座標記法が使えることを知りました。それならば「Googleマップで場所を選んでそこからカレンダー登録する」Bookmarkletもほとんど同じ方法で作れるじゃん、と思ったので作ってみました。

それがこれ。

Create Event at Here!

上記の「Create Event at Here!」リンクをブラウザのメニューバーなどにDrag&Dropするか、右クリックで「お気に入りに追加」するかしてBookmarkletを保存します。

使い方

Googleマップで追加したいイベントが行われる場所を表示し、メニューバーの「Create Event at Here!」Bookmarkletをクリックします。

場所の説明を入力するプロンプトが表示されるので入力します(入力を省略することもできます)。

(゚Д゚)ウマー

あとは適宜イベントのタイトルや日時を入力して保存してやるだけです。簡単でしょ。


本来は、Googleが、Calendarの「Where」入力部分にGoogle Maps APIを使ったUIを用意するべきなのでしょうね。いつかそうなるのかも知れませんが、それまでのツナギとしてこのBookmarkletは重宝すると思います。

Oct 6, 2006

Captcha Plugin 0.11a公開

CAPTCHA™テストを使った簡単なアンチコメントスパムプラグイン(Ogawa::Buzz: Captcha Plugin公開)をアップデートしました。

Captcha_Plugin - ogawa - CAPTCHA(TM)テストによる簡単なアンチコメントスパムを実現するプラグイン。 - Google Code

最初に公開した時点ではプロトタイプ的なものでしかありませんでしたが、今回はなるべく柔軟に使用できるように以下の拡張をしました。

  1. ブログごとにCAPTCHAテストの有効・無効を選択できるようになりました。
  2. CAPTCHAテスト文字列の長さを変更できるようにしました。
  3. CAPTCHA 画像の格納先ディレクトリをユーザが指定できるようにしました。いくつかのWebホスティングサービスではCGIスクリプトの格納場所に制限があるため、 0.02までのように特定のディレクトリにCAPTCHA画像を生成するようになっているとブラウザで画像にアクセスできない場合がありました。
  4. CAPTCHAテストの生成時・検証時に用いるsecret keyを設定できるようにしました。
  5. その他、ちょっとした最適化。

4. のsecret keyの設定機能に関して補足しておきます。

Kazuho@Cybozu Labs: Captcha Plugin/ja についてでも指摘されている通り、このプラグインで使用されているAuthen-Captchaはbrute force attackに弱い性質がありました。

CAPTCHAテストの生成時と検証時に共有鍵を使用する方式に改めればこの問題は大幅に緩和でき、実際下記のようなパッチも提案されています(FreeBSD portsでp5-Authen-Captchaをインストールするとパッチが当たったものがインストールされます)。

#7664: improve Authen::Captcha security

Captcha Pluginのsecret keyの設定機能は、このパッチが当たっているAuthen-Captchaがインストールされている場合のみ有効になります。この機能を使用するためには、おそらくほとんどのユーザは、手でこのパッチを当てる必要がありますのでご注意ください。


Authen-Captchaはもう保守されていないっぽい。Authen-PluggableCaptchaというのもあるけど。本当はGoogleあたりがCaptcha部分だけ外部サービスとして提供してくれれば良いのにね。

2006-10-08追記: CAPTCHA表示用のテンプレートをプラグインの設定画面から変更できるようにした0.12を公開してあります。

2006-10-17追記: CAPTCHAを使用しない設定にしたブログで、正常にコメントポストできない問題を修正した(0.13)。

Oct 2, 2006

ローカル検索におけるオーソリティ

ここギコ!: Googleローカルはやっぱり純粋な意味でのサーチエンジンではないと思う

長めのコメントを書こうと思ったがいかにも冗長にすぎたのでここに私の感じていることをまとめておく。

Googleローカルはやっぱり純粋な意味でのサーチエンジンではないと思う

と言われればその通りで、ローカル検索はWebページ集合に対する純粋なサーチエンジンにはなり得ないのではないか。

というのも、Web検索の場合には検索対象となる実体がネット上に完全な形で存在するのに対して、ローカル検索の場合にはそういうものが存在しないか、類似したもの(実体に対応すると考えられるURL)は存在するかもしれないけれど現実と乖離している可能性がある、という差異があるからだ。

ナイーブに考えるなら、ネット上の住所情報の生起をハイパーリンクの生起と同様にみなしてpagerankを計算して云々ということは可能だ。現状ハイパーリンクに比べて住所情報の生起回数の方が圧倒的に少ない(例えばこのブログに登場する住所情報とハイパーリンクの比を考えてみればよい)ために、容易にexploit可能な状況にあるという技術的な問題は別途あり得るが。

しかし問題は、ローカル検索では、ネット上には存在するが現実には存在しない事象や誤った事象や無視可能な事象などの情報は排除されるべきだとか、住所以外のプロパティ(ジャンル・時刻・料金・人数・アクセス手段・ドレスコードなど)がより重要だとかとかいった、Web検索とは別の、現実世界とのマッピングや利用者側のニーズを実現するようなrankingが求められるということだろう。

これらの問題のうち前者(現実世界とのマッピング)は、結局のところ「オーソリティ」の実現方法の問題だと言い換えられると思う*1。Webページ集合の場合には集合自体がオーソリティたり得たが、ローカル検索の場合にはそうとは言えない。

例えば「ソニーを代表するページ」のURLは「ソニー」が実在の企業であるかどうかに関わらずまた「外部」オーソリティに拠らず、ページ集合から計算で求め得る。一般にWeb検索のように対象となる実体がネット上にのみ存在する場合には、オーソリティはネット上に見出すことができる。Web検索においてそのオーソリティを代理行使する者が「神」として振る舞える道理だ。

これに対して「五反田ジローナ」が確かに実在することは外部オーソリティなしには証明できない。もしそういうものがなければ「Web上で一応存在すると仮定される五反田ジローナ」に対応するURLやその地図上の場所を決定できるに過ぎない。ではその(Web上で一応存在すると仮定される)「確からしさ」とは、どの程度実体に照らして確からしいのか?

一見十分に確からしいような気もする。というより、近年その確からしさを過信する傾向が続いてきたせいもあってそのように考える人が増えてきた。メジャーな飲食店のレビューサイトは、一般にinbound linkをたくさん有しているのでpagerank上「オーソリティ」たり得ていて、その情報の多くは正しい店舗情報を与えるので「確からしい」。あまりの「確からしさ」にレビューの内容が信頼おけるものと信じてしまう人までいるくらいだ、と(そんな確からしさは幻想に過ぎないのではないか?)。別の例を考えてもよい。多数の人がある店舗に関するブログ記事を書いたとする。一部には不正確な情報があるかもしれないが集合知としてはより実体に近づけるはずだから「確からしさ」は実用的な水準以上に維持できる、と(少数しか言及されない店舗の情報は不正確な状態に放置されるのではないか?)。

しかし、その情報の正確さについて誰も何の保証もしていない以上「確からしさ」には限度がある。特に住所や緯度・経度のIDとしての確実さ・正確さと比べればもう間違いなく圧倒的に劣っている。このことはもっと重視されるべきである。地図画像は正確無比に描けてもそれに付与される情報が誤っていては何の意味もない。

私は、ローカル検索の課題というのは、結局のところ両者のギャップを埋めることで、そのために「いまだ存在しないオーソリティ」を発見・実現すること(GoogleがWeb検索において発見したように)なのではないかと思っている*2。その一つの解が、Googleローカルが採用している、ゼンリンデータだかインターネットタウンページだかの外部オーソリティに依存する方法や、一部レビューサイト*3を仮想的なオーソリティとみなす方法だろう。言うまでもなくこれらの方法にも改善の余地はあるのだが、しかし重要なのは部分的にせよ解になっているということだ。また一方でDMOZを見れば明らかなように、ナイーブにオンラインディレクトリを運営すれば解決するような問題でもなさそうだ。

この課題にどのような決着がつくのかとても興味深い。


*1 後者はセマンティックWebの問題。
*2 もちろん、それなしでも何らかのアプリケーションを実現することはできるだろう。できるだろうが、それがローカル検索の目的ではないのではないか、というのが私の観測。
*3 今のところ、飲食店情報では食べログ.comぐるなびを参照しているようだ。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com