feed-tagcloud-appengine: フィードからタグクラウドを生成するためのAppEngineアプリ

フィードからタグクラウドを生成するためのGoogle App Engineアプリを作りました。

http://feed-tagcloud.appspot.com/json?url=feed_url

のようにフィードURLを指定してGETすると、

{"Movie":1,"JR":1,"Livedoor":1,"Book":1,"cat":3,"TV":1,"NHK":1,
"subversion":1,"Automobiles":1,"Train":1,"Baseball":2,"MovableType":6,
"sancha":5,"Buzz":1,"Microsoft":3,"Macintosh":3,"Google":6,"Office":3,
"Money":1,"Dragons":2,"API":1,"Hatena":5,"Blogger":7,"FeedBurner":3,
"AppEngine":5}

のように、フィードの各エントリのタグ情報を集計して、JSON形式で出力します。あとは適当なJavaScriptコードを書いてレンダリングするだけです。フィードは一時間キャッシュします。試していませんが、AtomでもRSSでもいけるはずです。あ、タグやカテゴリーが付与されていないフィードを食わせても意味ありません。

ここからが本題。

何のためにこれを作ったかというと、フィードからタグクラウドを生成するGoogleガジェットを実現するためです。

上のリンクをクリックすると、下のように確認画面が表示されます。

「Googleに追加」してやると、iGoogle上にタグクラウドを表示できます。

デフォルトでこのブログのタグクラウドが表示され（てしまい）ますが、設定を変更すれば、フィードURLやソート順、フォントサイズなどが設定できます。

このガジェットは（正直iGoogleに追加してもあんまり意味はなくて）このページの右サイドバーに表示されているように、Bloggerのサイドバーなどで使うと便利なガジェットです。というか、そのために作りました。

Bloggerの「ガジェットを追加」画面で「独自に追加」という項目を選択してください。

「http://feed-tagcloud.appspot.com/」というURLを入力して「追加」すれば使えます。

細かい設定はiGoogleの場合と同様に変更できます。

タイトル

タイトルを入力します。

高さ

ガジェットの高さをピクセルで指定します。デフォルトで200ですが、タグの数に応じて適当に変更しましょう。

Feed URL

フィードのURLを指定します。blogspotでホスティングしている場合「http://blog-name.blogspot.com/feeds/posts/default」というURLになるはずです。「http://blog-name.blogspot.com/feeds/posts/default&orderby=published&max-results=100&redirect=false」などとオプションを付けてやると最近100件のポストを対象にすることができます。オプションについての詳しい情報はDeveloper's Guide: Protocol - Blogger Data API - Google Codeを参照。

Tag base URL

タグの表示ページのベースURLを指定します。blogspotなら「http://blog-name.blogspot.com/search/label/」などと指定します。MTなら「http://blog.example.com/mt/mt-search.cgi?blog_id=X&tag=」などと指定すればOK。

Order By

「Tag name」を指定するとタグ名の昇順、「Count」を指定するとタグの頻度の降順で表示します。

Algorithm

フォントサイズの計算方法を指定します。「Linear」を指定すると頻度から線形補完し、「Logarithmic」を指定すると対数補完します。

Link Color, Background Color

リンクの色、背景色を指定します。

Min font size, Max font size

タグ表示の最小フォントサイズ、最大フォントサイズをptで指定します。

実はほとんど同じ機能を提供するガジェット(Sachin's Tech Place: Dynamic Label Cloud Gadget)が既にあります。Bloggerユーザでは、こちらを利用している方が結構多いかもしれません。ただし、IE8でエラーになって表示できない、最新のgadgets.* APIを使っていない、好きなようにカスタマイズできないなど、いくつか不都合な点があります。

feed-tagcloud-appengineは、IE8でも問題なく表示でき、gadgets.* APIを使っており（そのせいでGadgets Directoryに登録できないのですけど）、タグクラウドのソートができます。また、JSONのインタフェースが切ってあるので、それを利用してカスタマイズしたガジェットを作ったり、ガジェット以外から利用したりすることもできます。

ソースコードは例によってGoogle Codeに上げてあります。

feed-tagcloud-appengine - Google Code

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

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レスポンスに必要な要素を追加するのに便利ないくつかのテンプレートタグを実現しています。

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

Re: Let Readers decide How RSS gets sent

404 Blog Not Found:Let Readers decide How RSS gets sent

別にORの論理に囚われてはいないだろう、と思った。

選択肢を読者の側にもたせることは当然のことである。読者が全文だけではなく要約を、日本語だけではなく英語を望むのならそれを実現したらいい。

ではしかし、極端な話をすると、視覚に障碍を持つ読者に対して、音声データに変換したcontentを持つFeedを配信するだろうか?

…しないだろう。…いやもちろんしてもいいよ、でも手元にしかるべきリーダーがあり、それを用いて音声データに変換した方が認識率の点でもスピードの点でも優れた結果が得られるし、点字ディスプレイもある。また、言語間翻訳についても同様のことが言えそうな気がする。generalなスキーマを用いた機械翻訳の結果をFeedとしてサービスされるよりは、書き手と読み手が共通に持っていると期待されるスキーマを機械翻訳に役立てた方がより良い意思疎通が可能だろうから。

もっとつまんない話をしてみようか。「本文の先頭200文字を切り出したものが『要約』」とする書き手と、「そんなものを『要約』だなんて笑止」という読み手は永遠に折り合えない、と。あるいは、読み手がひらがなのみのFeedやルビ付きのFeed、仮名と常用漢字のみを使ったFeedを求めたら、と。

つまり何が言いたいかと言えば、選択肢を読者の側にもたせることが重要なのは事実だが、それをすべて単体サーバ上で実現あるいは提供でき、かつそれが最良だと信じることには、少なくとも現時点では懐疑的にならざるを得ない、ということだ。もっと悲観的な書き方をすると、実のところ書き手は読者のことをよく理解してはいないし、機械はもっと理解していない(だから集合知なんてものに大それた期待をもってしまう、と蛇足)。

であるならば、次善の策は最もgenericな情報を、as isで、メタ情報として与えることだ。

全文を提供されていれば、その要約を生成することはそう難しくない一方、いい加減な要約から意味のある要約を生成することは困難を極める。原文(日本語文)で提供されていれば、その他言語訳を生成するのは外部サービスやFeed Reader上で既にできるかいずれはできるという期待が持てる一方、低品質な(機械翻訳された)英文訳から高品質な他言語訳を生成することは至難だ。半構造が与えられていれば、音声リーダは効率良く読み上げることができる一方、構造を除去した文章の塊を読み上げるのは甚だ効率が悪い上、あらかじめ失われた構造を再現することもまた困難だ。

だからすべての可能性を否定しないために全文を提供すると言っているのであり、これが現時点での「究極のAND解(つまりはas isで何もしない)」なのだ。残念ながら。

---

それとは別の話をすると、「選択論理的な何か」がしばしば作用するのは主にFeed Readerソフトウェア/サービスの問題だ。本質的には「URL」がuniqueなのであって、それに対応付けられるFeedがuniqueである必要はない。しかし、多くのソフトウェア/サービスは「FeedのURL」を登録し、その内容を閲覧するようになっている。したがって読者は「FeedのURL」のuniquenessを意識せざるを得ず、それゆえ、「どちらのFeedを読ませるか」「どちらのFeedを読むか」ということがしばしば議論の俎上に上がるのだし、Feed提供者はFeedのURLを軽々に変更することを許されないのだ。

これは明らかにおかしい、登録するのはURLにすべきだ、登録されたURLに対して複数のFeedを読者のpreferenceに従って、「取得して」もしくは「生成して」、表示すべきだというのがひとつの素朴な意見である。「取得する」部分の実装に難しい点は何もない(弾さんが指摘している通り)。

複数のFeedをremixしたFeedを配布する場合のように、remixed FeedのURL自体がそのコンテンツセットの意味を規定していると考えるのが自然なこともある。だから、Feed URLを登録するのが統一的で自然なやり方なのだという意見もあるかもしれない。しかし、そうしたmachine-generatedなFeedは、そのURL自体に関連付けられたFeedだと考えればよいのであって、本質的にFeed URLの所在を意識することを読者に強いることは一切なくなるべきだろう。

FeedBurner の Item Stats をオフした件について。

FeedBurner(RSSやAtomなどのXMLフィードを中継配信してくれるサービス)を300日ほど使用し続けています。私の借りているサーバーの代わりに各種形式でXMLフィードを配信してくれるのに加えて、ブラウザヴィジブルにしてくれたり、統計を取ってくれたりと重宝しています。

Ogawa::Buzz: FeedBurnerに移行した件について。

この手のフィードの中継・変換サービスで重要になるのは機能だけでなく、中継配信の信頼性や、もし何らかのマニピュレーションをフィードに対して施すのであれば、その操作の透明性も重要です。Web上のサービスである以上「信頼性」に関しては「それなり」のものでしかあり得ませんし、「操作の透明性」に関しては仕様が明文化されているとは言い難くやや不満が残ります。

さて、Item StatsはFeedBurnerの機能の一つでフィードに含まれるitemのクリック数をトラックすることでitemごとの利用統計を与えるサービスです。クリック数をトラックするために、FeedBurnerはitemのlink要素を「http://feeds.feedburner.com/ogawa?m=18」などに書き換え、このURLへのアクセスは元のlink要素のURLへリダイレクトされるようになっています。

FeedBurnerのフィードをブラウザ経由で利用する場合にはこれで問題ないのですが、そのフィードを操作するソフトウェアでは問題が起き得ます。例えば、naoyaのはてなダイアリー - はてなブックマークの概要取得の処理の、

1. 該当エントリーに Feed Auto-Discovery を実行する
2. その中で最初に見つかった Feed (link タグで一番上にあるもの) を GET する
3. Feed を parse して、ブックマークされた URI を link 要素にもつ要素を探す
4. その要素に content 部分 (RSS 1.0 なら content:encoded、Atom なら content) があればそれを取得、なければ description を取得

という処理を考えてみると、link要素がリダイレクトURLに書き換えられているFeedBurnerフィードでは、このロジックが機能しません(だから中途半端な概要がはてなブックマークに引用されてしまう)。bulkfeeds.netやlivedoorブログ検索などがうまくインデックスしてくれないのも似たような事情なのではないかと疑っています。link要素のURLを全部HEADしてから比較してもらえばよいのかもしれませんが、すべてのサービス・アプリで対応することを期待するのは馬鹿げています。

また、無料アカウントでもItem Statsが使えるのに、PROアカウントでないとAwareness API経由でItem Stats情報を取得できません(GetItemStatできません)。この非対称性には正直苛っとさせられますね。

さらに、他の人のブログで引用されるときにリダイレクトURLをReferされたり、リダイレクトURLをブックマークされたりしても、Item Statsのページ以外の方法では観測できません。というより、Item Statsのページは各アイテムのクリック数しか表示しませんから、実際には観測不可能だということになります。前述のようにAPI経由で利用するためには有料アカウントが必要で、APIで取得できる情報は(Item Statsのページ同様)やはりサマリー情報だけに縮約されます。要は、ユーたちの大事なREFER(R)ER情報がFeedBurnerに掠め取られているんだゼ、ということです。

ではどうすればよいのかというと、実はItem Statsの機能をdisableするとFeedBurnerはlink要素を書き換えないので、disableすればすべてが解決します。デメリットはItem Statsが使えなくなるというただ一点です。私は問答無用でdisableしました。

方法はいたって簡単。(1) 各フィードのAnalyze画面で「StandardStats」を選び、(2) 「Feed item link clicks」のチェックボックスを外し、(3) 「Save」するだけです。

この件でお悩みの方はお試しあれ。

2005-12-12追記:

この設定を行うと既存のリダイレクトURLはすべて無効になり、「http://feeds.feedburner.com/ogawa?m=18」はそのフィードURL自体を指すようになるようです。つまり、すでに誰かがリダイレクトURLをブックマークしている場合には到達不可能になってしまいます。これはまあデメリットですね。

フィードURLとItem IDから実URLをresolveするAPIを提供してくれてもいいのだが＞FeedBurner

georss2kml.cgi: GeoRSSをGoogle Earthにマップするスクリプト

GeoRSSをGoogle Earthにマップするスクリプトを作ってみました。

georss2kml.cgi: Maps the GeoRSS onto Google Earth

宮川さんのMap geocoded RSS/Atom to Google Mapsを再利用しています。

例えば、RSS Photo Album view: Tokyo LandscapeをGoogle Earthで表示するには、

http://as-is.net/maps/georss2kml.cgi?url=...(以下省略)

にアクセスすればよいわけです。具体的には以下のように表示されます。

http://as-is.net/maps/georss2kml.cgi?url=...(以下省略)が生成するKMLを静的に利用することもできますし、URL自体をGoogle EarthのNetwork Linksとして保存しておけば、更新がオンラインで反映されることになります。

すでに同じことができるものが公開されているかもしれませんが、次のアーティクルへの布石です。

オプション

• url=GeoRSS URL
  変換するGeoRSSのURLを指定します。
• xml=0 | 1
  KML出力時のContent-Typeを指定します。xml=0の場合にはGoogle Earthでの表示用にapplication/vnd.google-earth.kml+xmlを返し、xml=1の場合には(他のアプリケーションからの利用できるように)text/xmlを返します。前者がデフォルトです。

"Subscribe with Feedbringer" Bookmarklet

RSSリーダーFEEDBRINGER.net、良いですねー。Bloglinesのもっさりさ加減に比べると非常に快適です。

「FEEDBRINGER」はかなりおすすめ！！ : 亜細亜ノ蛾 - Weblog
the meager: FEEDBRINGER

私の方からは以下のリクエストを出しておきました。

• フィードの表示順がアイテムの作成時刻の昇順に固定されていますが、これを降順にも変更できるようにしてください
• CrawlerのUser-Agentに「FEEDBRINGER/0.1 (http://feedbringer.net/; XX subscribers)」のようにsubscribe countをいれてください

それにしてもOPMLを共有するサービスというのを誰かやらないものでしょうか。現状データ形式しか定義されていないわけですが、その上に操作用のプロトコルを定義してそれをサービスとして提供してくれれば、一箇所で行ったブックマークへの更新が他のところでも(デスクトップでも)反映されたりするわけです。ときどき広告表示用のブックマークを挿入しさえすればビジネスモデル的に成立しますよね。

それはともかく、「Subscribe with Feedbringer」Bookmarkletです。

Subscribe with Feedbringer

上記の「Subscribe with Feedbringer」リンクをブラウザのメニューバーなどにDrag&Dropするか、右クリックで「お気に入りに追加」するかしてBookmarkletとして保存するとよいでしょう。

2005-08-05追記: 本家にも同じようなの用意されましたね。それとも気が付かなかっただけで最初からあったのかしら...。でも本家版だとURLに&などを含むときに正しく動作しないと思うんですけどね。

2005-08-19追記: 本家のBookmarkletもencodeURIComponentするようになりました。またリクエストしていた点が改善されましたね。あとFeedburnerでFeedbringerのsubscribers countが反映されないみたいなので、そっちのフォーラムに書き込んでおきました。
FeedBurner Support :: View topic - Some minor online RSS readers

SVN::Web導入

Quasi-Spam Filter Pluginをアップデートしました。スパム判定ルーチンを定義するis_comment_spam, is_tbping_spamのインタフェースを若干変更したので、判定ルーチンを改造している方は若干注意が必要です。またロギング機能を追加してあります。

Ogawa::Buzz: Quasi-Spam Filter Plugin

で、本題ですが、プラグインの更新のたびに新しいエントリーを作るのは結構面倒なので、私はリリース時のエントリーに更新を加えています。しかし、それだとユーザーさんが更新に気が付かない場合も当然にあるわけで、どうしたものかなあと思っていました。

そこで今回プラグインのリポジトリーをWebで公開することにしました。

SVN::Web

何のご利益があるのか分かりにくいかとは思いますが、例えば最新のリリースをウォッチしておきたい場合、下のURLをRSSリーダーなどに登録しておくと、リポジトリーの更新を察知することができます。

http://svn.as-is.net/svnweb/mt/rss/

また、開発中のバージョンや過去のバージョンを手に入れることもできます。

2005-04-18追記:
イマイチ不安定っぽいなー。私の環境ではsvnserveとSVN::Webがリポジトリーを触ることになり、前者はread/write、後者はread onlyなわけですが、subversionはBerkeleyDBを使っているのでCGI(SVN::Web)経由readするだけでもロックを獲得してしまい、簡単にstarvationを起こしてしまうみたいです。ちょっとこれでは使い物にならないのでそのうち対策をする予定です。

2005-04-18追々記:
mod_perlを使うように変更してみて様子見中。URLが変更されましたが、Redirectするようにしてあります。

2005-04-19追記:
ん、ダメでした。mod_perlでの動作自体は快調ですが、mod_perl2でないとResponse Headerが無茶苦茶になるっぽいです。というわけでCGIに戻しますです。

FeedBurnerに移行した件について。

Movable Typeの再構築が遅いの速いのという話がありますが、よくよく考えるまでもなくメイン・インデックスが再構築される(エントリー投稿・更新、コメント、トラックバック)時、RSS 1.0, 2.0, Atomの3つのXML Feedも一緒に再構築されています。ASP型のサービスでは大抵いずれか一つしか提供していないのにMovable Typeの親切ぶりはどうよ、どうなのよ、ねえ、と思わなくもありません。

個人的には一つだけにして当社比3倍(実際には他のアーカイブも再構築されるのでそんなに速くなりません)と行きたいところですが、Bloglinesで他のフィードにもまんべんなく読者が付いていることから判断するに、適当な方法で他のFeedのユーザーを誘導してやる必要が明白にあるということです。

とりあえずindex.rdf, index.xmlからatom.xmlにリダイレクトしてみたのですが、Bloglinesが3回ずつアビっていかれるご様子。また、AtomとRSSが将来統合されたらAtomという名前ですらなくなったりする気もしてその時またatom.xmlから変更するのかよ、と。将来Jabber/XMPP Botがフィード更新の通知を受け取ってから即時GETに来るようなフレームワークが一般的になったときに、今よりFeed Provider側(つまりは私の使っているサーバ)にトラフィックが集中しそうじゃんか、と。更新通知する仕組みを皆が用意するのは結局現実的でなくて適当なアウトソース先に丸投げしてそこが勝手に「アドバンストなテクノロジー」を発揮してくれればいいじゃんか、と。要するにもう少しユニバーサルで賢いやり方はないかと思ったわけです。

そこでFeedBurnerﾀﾝ(FeedBurner - Point your feed here. We'll do the rest.)の登場ですよ。

FeedBurnerについてはGoogle 検索: FeedBurner。おいらの代わりにXML Feedの配信してくれるのに加えて、ブラウザヴィジブルにしてくれたり、統計を取ってくれたり、他のFeedをマージしてくれたりと(簡単にできることは)色々してくれます。多分「アドバンストなテクノロジー」も勝手に導入してくれるでしょう。

私のやった作業はこんな感じです。

当初Atom Feedを生成して、それをFeedBurnerに配信させる方法を記述していましたが、それだとbulkfeedsを含め多数のアプリケーションで正常に読み込めない問題があるようです。以下はRSS 2.0 Feedを生成するものとして記述を修正してあります。

1. RSS 2.0 Feedを昔の名前(index.xml)以外の名前で生成するようにします。
2. FeedBurnerでアカウントを作って1.で生成したFeedを指すようにします。これで「http://feeds.feedburner.com/AS-U-LIKE」という名前で配信できるようになりました。
3. テンプレートで昔のFeedを参照している部分を2.で作ったものに書き換えます。私の場合例えばヘッダは以下のように書き換えてあります。

   <link rel="alternate" type="application/rss+xml" title="RSS"
         href="http://feeds.feedburner.com/ogawa" />
   <link rel="alternate" type="application/atom+xml" title="Atom"
         href="http://feeds.feedburner.com/ogawa" />
   

   なぜAtom形式でも宣言しておくかというと、RSS形式からAtom形式への変換はFeedBurnerが自動的にやってくれるからです。前者だけでも構わないと思います。
4. 「移転しました」Feedを作っておきます。
5. 適当な期間放置して、4.の「移転しました」Feedを削除します。
6. やっぱり4.,5.は良くないっぽい(Bloglinesのsubscribe情報が全部消えた)。代わりに旧Feedから新Feedへpermanentなリダイレクトを設定した方がよいです。

   RewriteEngine on
   RewriteRule ^index\.rdf$ <新FeedのURL> [L,R=permanent]
   RewriteRule ^index\.xml$ <新FeedのURL> [L,R=permanent]
   RewriteRule ^atom\.xml$  <新FeedのURL> [L,R=permanent]
   

   Redirectでもできますからお好みで。

さてこの作業を行うと、ただでさえ遅かったBloglines(多分他のWebでサービスしているRSSリーダーも)の更新がより遅くなります。私の作ったFeedを適当な間隔でFeedBurnerがフェッチして二次公開し、それをBloglinesが1時間ないし2時間に一回フェッチするという二段構成になりますから。ただし、Ping-o-Matic!に更新Pingを打てばFeedBurnerに更新が即時に伝わって即フェッチに来ます。したがって一応二次公開に伴う遅延は限定的です。この場合、むしろMovable Typeが新規投稿時にしか更新Pingを送らないこと、従来からあるRSSリーダーの巡回遅延が大きいことの二つが問題です。

前者を解決するにはパッチを当てるかプラグインを入れるかして機能拡張する必要があります。

Ogawa::Buzz: Update-n-Ping Plugin

後者に関しては、私の場合2日に一度も更新しないので構いませんが、そのうちブレイクスルーが起きて如実に速くなることに期待しています。

また、Bloglinesの旧Feedに対するsubscribe情報は、新Feedに書き換わったみたいです。これを自動的にやるのは無理っぽい気がするので中の人が作業してくれた(=301 Redirectを検出してマージしてくれた)のだと思います。あるいは全読者が一斉に移行作業をしてくれたとか？アリエナーイ。

RSSリーダーを使っている読者様はお手数ですが下記URLから購読くださるようお願いいたします。

http://feeds.feedburner.com/ogawa

おまけ: RSSBarについて

FeedBurnerを使うとこのようにRSSリーダーごとの振る舞いも見られるわけなのです…。

しかし…、RSSBarというリーダーはユーザーベースでのシェアは3.6%(=6人/167人)なのですが、Feedのダウンロード回数でのシェアは43%(=478回/1112回)もあるのですね。24時間リーダーを使っていたとしても18分に一回クロールに来ている計算になり、他のツールと比較すると尋常でない頻度です。If-Modified-Sinceヘッダ付きで取りに来ているでしょうから、ほとんど304 Not Modifiedが返っているのでしょう。だけど、一方でリクエストしているクライアント側もそれなりの負荷がかかるわけで、遊休PCを使っているわけなのかしら？

こういうデータが見られるのは面白いです。

MSN Search RSS Feeds

宮川さんのところ(MSN Search Results as RSS: blog.bulknews.net)で知りましたが、MSN Search betaがRSSを生成するようになっていました。

RSS Feeds for Search Results

早速、Ogawa::Buzz: mt-search.cgiを捨てて簡単メタサーチにしてみようでやっていた、サイト内検索にGoogle Web APIsを使う方法を放棄しました(待てど暮らせどうちのサイトにはGoogleがクロールに来てくれないので役に立たないのデス)。で、こっちに乗り換えました。

どういうことかと言うと、例えば、「小川」をサイト内(as-is.net内)検索したい場合、

http://beta.search.msn.co.jp/results.aspx?q=%E5%B0%8F%E5%B7%9D+site:as-is.net&format=rss

というURLで検索結果のRSSが得られます(「%E5%B0%8F%E5%B7%9D」は「小川」をUTF-8に変換してURLエンコーディングしたもの)。したがって、このRSSをMagie RSS(Magpie RSS - PHP RSS Parser)などを使って読み込んで表示するだけで、真っ当なサイト内検索として機能してくれるというわけです。

ざっくり書くとこんな感じ。

<?php
define('CHARSET', '<$MTPublishCharset$>');
define('BLOG_HOST', '<$MTBlogHost$>');
define('BLOG_SITE_PATH', '<$MTBlogSitePath$>');

$search = isset($_GET['search']) ? htmlspecialchars(trim($_GET['search'])) : "";

echo <<<EOD
<form method="get" action="{$_SERVER['PHP_SELF']}">
<h3>サイト内の検索</h3>
<p><input name="search" size="30" value="{$search}" /><input type="submit" value="Search" /></p>
</form>

EOD;

if ($search) {
  $qstring = urlencode(mb_convert_encoding($search, 'utf-8', CHARSET));
  $cond_site = urlencode("site:" . BLOG_HOST);

  echo "<h2>MSN Search betaのサイト内検索結果:</h2>\n\n";

  require_once BLOG_SITE_PATH . 'rss_fetch.inc';
  define('MAGPIE_CACHE_DIR', BLOG_SITE_PATH . 'cache');
  define('MAGPIE_OUTPUT_ENCODING', CHARSET);
  $url = "http://beta.search.msn.co.jp/results.aspx?q={$qstring}+{$cond_site}&format=rss";
  $rss = fetch_rss($url);
  if ($cnt = count($rss->items)) {
    echo "<p>{$cnt}件見つかりました。</p>\n\n";
    echo "<ul>\n";
    foreach ($rss->items as $item) {
      $title = htmlspecialchars($item['title']);
      $url = htmlspecialchars($item['link']);
      $snippet = htmlspecialchars($item['description']);
      echo "<li><a href=\"$url\">$title</a>\n<div class=\"note\">$snippet</div></li>\n\n";
    }
    echo "</ul>\n";
  } else {
    echo "<p>見つかりませんでした。</p>\n\n";
  }
  echo "<p><small>[Powered by <a href=\"http://blogs.msdn.com/msnsearch/archive/2005/01/11/351064.aspx\">RSS Feeds for MSN Search Results</a>]</small></p>\n\n";
}
?>

上のコードはMovable Typeのテンプレートに張り込むことを考慮して、一部MTタグを使って書かれていますが、先頭で定義しているCHARSET、BLOG_HOST、BLOG_SITE_PATHという三つの定数を適当に変更するだけで、大抵のサイトで利用できます。

Feed2jsやprocfeedのように貼り付け用のJavascriptを生成してくれるサービスを利用してもよいのですが、こうしたサービスは総じて負荷が集中しやすく動作速度も遅いため、ページ全体のレスポンスを悪化させるので、私は使っていません。