栗林健太郎

「livedoor Reader まとめサイト」なんつって、livedoor Reader 愛好者的にはかなりと必見な Wiki があったりするようです。

livedoor Readerを使う上で有用な情報や、ツール開発者、ブログオーナー向けの情報を提供していきます。

• 公式なアナウンスは開発日誌上で行われます
• ヘルプは公式なヘルプがあります。

このWikiはlivedoor Readerの開発スタッフが直接、ブログオーナー様向け情報や開発者向けの情報、現時点でわかっているバグ、あまりない質問と回答などをざっくり書き込んでいきます。

いろいろと面白い情報満載なのですが、LDR 愛好者の中でも、スクリプト等でこねくりまわして遊ぶのが好きな向きは、以下の記述に興味を引かれるのではないかと思ったりします。

Greasemonkeyで使えそうなJavaScriptのライブラリをホスティングしています。
追加で欲しいライブラリがあればコメントをどうぞ。(検討します)

というわけで、livedoor Reader から、ショートカットキー一発ではてなブックマークにぶくまする greasemonkey スクリプトにて使用した WSSE 認証のためのライブラリ wsse.js がホスティングされたりしています。
Web API を公開することも当然大切ですが、クライアントサイドでのコンテンツの自由な加工に助力することもまた Web2.0 的実践の重要なポイントなのであってみれば、こうして JavaScript ライブラリをホスティングすることで greasemonkey 等によるカスタマイズ可能性を飛躍的に高める試みは、Web2.0 などと口先で唱えるばかりでそのようなことを意識的に試みるサービスがいまだにほとんど見あたらない現在、どれだけ賞賛しても賞賛し尽くせない英断であると思うのです。

5 月 21 日追記。
「iCal天気 – Weather Hacks – livedoor 天気情報」ということで、大元の livedoor より iCal 形式のデータ配布が開始されした。このエントリで紹介している weather.subtech.org ではなく、livedoor 提供によるサービスをご利用下さい。

暇つぶしに「Weather Hacks – livedoor 天気情報」から僕の住んでる地域の天気予報を取得して、それを Google Calendar で読み込めるようにするべく iCal 形式に変換して遊んでみようと思いたったそのとき、どこからともなく「それ Plagger でよくね？」という声が聞こえてきたので、勢い余って weather.subtech.org なんてのを作った。

このサイト weather.subtech.org は、「Weather Hacks – livedoor 天気情報」にて提供されている日本各地の天気予報情報を、iCalendar 形式にコンバートして提供しています。Macintosh の iCal やGoogle Calendar など、Web 上の iCalendar 形式のファイルを扱えるソフトで利用できます。

iCal や Google Calendar 以外のカレンダーアプリって知らないので、他のアプリで使えるかどうかはわかんない。各アプリにおける外部 iCal データ取り込み方法については各自それぞれ調査していただくとして……ってんじゃ不親切過ぎるのでちょっとだけ。

1. まず、weather.subtech.org で天気予報を知りたい地域をみつけ、”ICAL” アイコンのリンク先 URL をコピーします
2. Google Calendar の場合は、画面左下の “Calendars” というボックス内のさらに下部にある入力欄に、URL を入力するだけ。カレンダーのタイトルが気にくわなければ、”Manage Calendars” で変更することができます。
3. iCal の場合は、ツールバー（っていうの？画面上部の「ファイル」とかいろいろあるところ）の「カレンダー」→「照会」を開くと出てくるボックスの「照会先」ってところに、上でコピーした URL を入力してください。

以上が上首尾にいくと、以下の画像のような感じになります。
（下図）Google Calendar での様子

（下図）iCalでの様子

ひとによってはそれなりに便利な局面があったりするのかもしれない。適当な時間をおいて定期的にデータの更新をしているので、今後ともご利用いただけたりいただけなかったりする予定です。
技術的な面を少し。とはいってもたいしたことなくて、バックエンドで決め打ちプラグインをつっこんだ Plagger をまわして「RSSフィード一覧 – Weather Hacks – livedoor 天気情報」にある日本各地の天気予報 RSS を取得・加工、んでもってそれらを iCal 形式に書き出しただけってな、まぁどうでもいい話。しっかし Plagger 便利だねぇ。最高過ぎる。もちろん、データ提供元の livedoor に多謝！

なんか数ヶ月ごとに再燃してる感のある「フィードに全文を掲載するべきか否か問題」だが、RSS フィードへの全文掲載の設定デフォルト値を「全文を掲載する」にするか否かを問うアンケートにより何度目かの盛り上がりを見せている昨今、全文に対するアクセスを、従来の HTML のみにこだわらず、もっと容易にするべきではないかということついては「「RSSに要約や全文を入れるとアクセスしてくれなくなるから嫌だ」という感覚はアクセス増には逆効果」や「はてなダイアリーのRSSデフォルト設定を、「全文入れない」に投票する、本能にしたがった感覚的な人が多いんだなぁ」で解決済の問題であり、あとは otsune さんとともに

感覚的な問題以外で「RSSには要約文しか載せたく無い」という合理的な理由はあるのだろうか？（広告やカウンターの話はもう分かっていて反論済みなので、それ以外で）

とつぶやく他はないのだし、そもそも全文を掲載するべきか否かではなく、読み手がそれを選択し得る仕組みを作ることが必要ではないかということについては、”404 Blog Not Found:Let Readers decide How RSS gets sent” にて述べられている通り、読み手に選択肢をもたせるべく、リクエストに応じて要約なり全文なりを送信するといった方法を考えるべきであり、以上の otsune さん、弾さんの指摘するところを踏まえると「フィードに全文を掲載するべきか否か」なんて、なにをいまさら……的な問題なのだけど、かといって「ただただし＠「ただのにっき」のエンジニアいとをかし／Ｔｅｃｈ総研：「みんなの意見」は正しいとは限らない」なるエントリが、「これからはWeb2.0だ、集団知だ、というわけで、「みんなの意見」は案外正しいなんて本が売れているようですが、それが成立するのは意見を求める側に十分な思慮がある場合に限られるなぁと思」いながら、「最速インターフェース研究会 :: 例えばもしも明日ボクシングのやりすぎで網膜剥離で失明した時にはてなダイアリのデフォルトが要約配信だったら残りの人生をどう過ごせばいいのだ」というエントリを評価すると同時に

RSSフィードは、それを配信する側にはたいしたメリットはありません。ほとんど100%、購読する側にのみメリットのあるサービスです。ですから、配信する側は読み手が最大限の利益を受け取れるように配慮すべきです。

などと述べるのを見ると、ややガッカリした気分を隠せないのは、フィードに全文を掲載することは、書き手にとってメリットがあるからそうするのであって、それは上掲の otsune さんのエントリでも述べられているし、そもそもひとは文章を書くことでどういう効果を期待しているのだろうかということを考えると、Web で文章を発表するに際し、いまはたまたま HTML が主流になっているだけで、オレオレフォーマットなテキストでもって表現してもいいわけで、しかしそんなことを誰もしないのは当然読まれなくなるからというだけの理由であり、要するに、一般的な Web ブラウザで読むひと、lynx や w3m のようなブラウザで読むひと、音声ブラウザで読むひと、RSS リーダですべてを完結したいひと、それぞれに対して、できるだけ広く自分の文章を読んでもらおうと思うならば、Web 標準やアクセシビリティに配慮したり、フィードに全文を掲載したりして、より幅広い層に対するアクセシビリティを確保するべきなのであり、RSS であるとか HTML であるとか、はたまたオレオレフォーマットであるとかは、単なる手法に過ぎず、もっといえば、RSS の出自である “summary” という言葉に拘泥することなく、事態を建設的に観察するならば、フィードとはいまや、HTML で書かれた「本物の」コンテンツを補強するものであるというよりもむしろ、HTML で書かれた「普通の」Web ページとなんら変わることのない、文章を広く読ませるための手段のひとつであり、そうであってみればフィードとは、全文を掲載せず要約のみの Blog エントリなどというものが存在し得ないのと同様に、もとより全文が掲載されていて当たりまえ、あるいは弾さんが提唱するような方法でもって読み手の選択により要約なり全文なりを取得できるようにするべきものなのであり、「フィードに全文を掲載するべきか否か」という問いがそもそも偽の問題なのだ。

情報収集における 1.0 なひとと 2.0 なひととの間で争いが起きているようですが、その関連で「情報収集のための11の質問」なんてのが提起されています。あんまり情報収集とか得意じゃないので後追いばっかしてる僕ですが、他人様がどうやってんのか知りたくもあるので、まずは隗より始めよってことで回答。

1. RSSリーダーを使っていますか?

Sharp Reader -> Headline-Reader と、デスクトップ型のリーダを経由して、2004 年半ばあたり？からは Bloglines を使ってます。Web サービス型の方が、なにかと便利。登録数は 487 フィード。

2. アンテナを使っていますか?

使ってない。以前は RSS リーダと並行して、なつみかんを利用したアンテナを自鯖に設置して使ってたけど、サーバがぶっとんだのを機に完全に Bloglines に統一。アンテナで見てたサイトのほとんどが RSS を出していたので、移行にはほぼ問題なかった。アンテナは更新内容検知がエントリ単位じゃないので不便。

3. ソーシャルブックマーク(SBM)を使っていますか?

はてなブックマークを利用中。delicious から移転してきました。暴力的なコメントしまくりです！！！

4. その他情報収集に使っているツールはなんですか?

IRC ぐらいかな。情報収集つーか、単におしゃべりしてるだけだがｗ

5. 他人にこれはお勧め!と思う方法は?

んー、RSS リーダは便利ですよ。

6. 逆にこれはお勧めできないな、と思う方法は?

特にない。

7. 情報収集で良く参照するサイトは?

んー、Bloglines 中心なので、どこのサイトがどうのってのはないなぁ。

8. 自分のブログで良く言及･リンクするサイトは?

はてな関連サービスｗ はてな大好きっこなので。

9. 逆にここは参照してはいけない、と思うサイトは?

はてぶのホッテントリとか。嘘ですが。

10. WEB以外で良く情報源にするものは?

書籍、雑誌、友人の話。

11. 最後にあなたが情報収集方法を知りたい人は?

id:strange さんとか百式のひととか。

補論。RSS や Atom を出してないサイトに対して、RSS 出せよ！とはあんまり思わない。そもそもフィードを提供していないサイトとか、結果的に僕の興味の範疇外であることが多いので、現実的になんの問題もなかったりする。
むしろ強く思うのは、フィードに全文を入れて欲しいってこと。理由については、すでにあちこちで議論済みなので蒸し返さないけど。個人的には、全文入ってないところはわりと流し気味な扱いです。

「hxxk.jp – はてなブックマーク de アバウトページ」が面白かった。はてなブックマークの被ブックマークページ表示ページ（ややこしいな）の内容を編集できることを利用して、第三者によってサイトやブログの about ページが作られてったら面白いんじゃないの、ってな話。

こうして手動で自由に編集できるというのは、本来作成者が用意したアバウトページではなく、第三者の客観的な視点で見た解説を書ける土壌となるという見方もできるのでは ? と思いました。

（中略）

もちろん、安易に第三者による編集を推奨してしまうと、悪意ある概要にされてしまう可能性もありますが、試みとして編集してもらうのは面白いかも。

あー、いいねそれ！と思いつつも、まぁうちの Blog について誰かが書いてくれるとも思えないので、自分で書いてみた（ぉ

• はてなブックマーク – antipop2.0

はてなのサービスはいままではわりと各サービスの面白さで成り立ってきてたような感じを受けるけど、たとえば僕は mixi では自分のホームページとして “project antipop” を挙げてたりするし、FOAF 対応やOpenID 対応を期待させてくれたりしてる感じの昨今、今後は個人の Web における活動全般をサポートするプラットフォームとしての役割を担っていって欲しいなぁと思ったりするわけで、牽強付会な感じではあるけど、はてなブックマークを上記のように利用することも、そういった観点からいっても面白いかなぁとも思ったりしました。

みんな大好きはてなさんが、新サービス「総選挙はてな」をリリースしました。

2005年8月8日、衆院が解散となり衆院選が9月11日投票の日程で行われることになりました。今回の選挙戦は、日本にとって大きな意味を持つ重要な出来事であると考えましたので、はてなアイデアの予測市場の仕組みを使って選挙の行方を予測する試みを行いたいと思います。

総選挙はてな

これは大変面白い試みだと思います。しかし、早くも重大な問題点が指摘されています。公職選挙法第 138 条の 3 に抵触するのでは？ という問題です。

（人気投票の公表の禁止）

第138条の３　何人も、選挙に関し、公職に就くべき者（衆議院比例代表選出議員の選挙にあつては政党その他の政治団体に係る公職に就くべき者又はその数、参議院比例代表選出議員の選挙にあつては政党その他の政治団体に係る公職に就くべき者又はその数若しくは公職に就くべき順位）を予想する人気投票の経過又は結果を公表してはならない。

公職選挙法第 138 条の 3

条文をぱっと見た感じ、これは明らかにマズイんじゃねーの？ 的感想を抱きます。ただ、はてなアイデアの予測市場の仕組みを使って選挙の行方を予測する試みというのが即ち公職に就くべき者を予想する人気投票の経過又は結果を公表することにあたるのかといえば、それはどうなのかなとは思われるところです。そこから直接得られる利益を最大化することを目的とする者によって構成される市場の仕組みに基づく予測と、選挙運動としての人気投票とでは、参加者が利益を得る目的も方法も異なるからです。

予測市場の仕組みを、従来、市場的な知恵が向かないとされていた、あるいは、試されたことのなかった分野に適用しようという試みは、はてな以前から存在していたりします。たとえば、計画途上でぽしゃってしまったものの「米国防総省、将来のテロ攻撃などについて賭け金を集める市場を構想」という記事に述べられている、テロの予測市場といった例がありました。

「残虐行為とテロリズムに関する、連邦政府公認の賭博場というアイディアは馬鹿げており、グロテスクだ」と28日に計画を明かした議員の1人、ロン・ワイデン上院議員(オレゴン州選出、民主党)は語った。

米国防総省、将来のテロ攻撃などについて賭け金を集める市場を構想

この計画に対しては、人道的な立場に立つ大方の意見は、上の引用とそう変わらないものになるでしょう。しかし、なぜこのような一見馬鹿げた計画が持ち上がったのでしょうか。

市場が「分散していた情報や、さらには隠されていた情報さえも」明らかにする可能性があると述べていた。「選挙結果を予想するような場合における先物市場の優秀性は証明されている。専門家の意見よりも優れている場合もしばしばある」

米国防総省、将来のテロ攻撃などについて賭け金を集める市場を構想

市場はどんな情報収集・分析機関よりも、テロや選挙結果の予測についてさえ優秀であるかもしれないのです。それをはてなという一般的に知られたサービスが「総選挙はてな」などといって提供してしまうところが、インターネットならではというか、それこそまさにインターネットによってもたらされた可能性でしょう。誰もが簡単に、瞬時に参加できるインフラが整備されてこそ現れ得たサービスです。というか、リリースに際しては、当然、上に挙げたような話が念頭にあったのではないでしょうか。

確かに、素人なので正否についてはなんともいえませんが、法律の条文を見る限り、非常にヤバげに見えます。ただ、これからのインターネットが世の中にもたらし得るかもしれないひとつの例として、非常に興味深いと思われるのもまた、事実なのです。

「なぜいまそれが盛り上がっているのだろうか」というエントリに対して、そのエントリで言及した kita_no_naka 氏がリプライしている内容がなかなか素敵な書きぶりだし、引くとみせかけて、その実、ものすごい勢いで斬ってくるあたり、攻撃力も格段に上がっていて、感心しました（謎）

昨日書いたエントリがなぜいまそれが盛り上がっているのだろうかという文書でさらし上げされていた。

kitaの中の人のはてな日記 – 老兵はただ消え去るのみ

ひとの文章は「痛い」呼ばわりしといて、自分の文章が言及されたらさらし上げ呼ばわりですか。

一応あれは「痛い文書」として挙げたつもりはないです。「書いた人には申し訳ないんだけど」と断ってるし。

kitaの中の人のはてな日記 – 老兵はただ消え去るのみ

へぇ。まぁ、御本人がそういってるんだから、そういうことなんでしょうね。

あとはどうコメントしようかなぁと思ったらPiroさんが代わりに書いてるので便乗させてもらう。

kitaの中の人のはてな日記 – 老兵はただ消え去るのみ

便乗ということは、つまり、Piroさんが述べている CSS の話と、今回の XML の件は同じ対立図式をなしている、と。んでもって、kita_no_naka 氏を含む XML の最初から想定されていた目的を普及する役割を担ってきた方々は、迫害されていたのだ、と。

Piroさんが述べている CSS 関連の話題については、僕がネットにつないで最初に興味をもった技術的な話題であったりするので、そのあたりについてまったく知らないわけではありませんし、僕自身、数年遅れ馳せ、かつ、効果の伴わないものであったかもしれないけれど、個人的な思いとしては、詳細は挙げませんができる範囲で活動してきたつもりです。Piroさんの日記の過去ログも読んでるし、その他関係リソースも広くあたったし、何が問題とされていたのかも理解してるつもりだし、Piroさんが何を嘆かれているのかについてもわかっているつもりだし、共感を覚えないわけではありません。つまり、便乗という言葉が示す対立の構図を、知らないわけではないということです。

Piroさんに便乗したという「老兵はただ消え去るのみ」の文脈でいうと、つまり、XML の本来のありかたを普及しようとしていた人々を 迫害していたのは、CSS の文脈でいえば、いわゆる「不思議マークアップ」のひとであるとか、最近メインストリームになっている、前提を成す文書のマークアップは顧みることなく小手先の CSS Tips みたいなものを乱造している考えの浅いブロガーみたいな連中であるということなのでしょう。それが XML の文脈でいうと具体的にどういう人々になるのか、それはわかりませんが、つまりは、僕や mala さんがその手の連中と大差ない、と。酷いいわれようですな。

mala さんがどう思うか知りませんが、「お前なんて CSS 普及期における不思議マークアッパー、あるいはいま調子こいてる非本質的な CSS 活動家と大差ないポジションにあるのだ」などといわれることがどれほどの侮辱か、よく理解しているつもりです。正直、なんでそこまで酷くいわれないとならないのか、さっぱりわかりません。そんなにもむちゃくちゃなことを、僕は述べたのでしょうか。お話をしようと声をかけたら、いきなりナイフで刺されたといった感じ。まぁ、こういうこともあると諦めるしかないのでしょうけど……。

del.icio.us の API を用いて作成された del.icio.us direc.tor の登場を契機に、mala さんが「XML はメタデータというより生データとしての利用価値が高まりつつあり、Ajax による UI の切り離しがそれを加速する」というエントリを書いていて、Web2.0 などと呼ばれもする昨今の潮流の前提となる考え方のひとつを解説しており、このところずっと継続して考えていた分野でもあったので、大変に興味深く読みました。

ところで、そのエントリに対して、こんな反応があったりもします。先に挙げた mala さんによるエントリは痛い文書あるいはたいした文章でもないのにブックマークが多いものであると断じ、この内容自体は普通なら読み飛ばすんだけど、何も考えずに信じてる人が多いので、ここはいっちょなにかいっておかねばという使命感にかられたらしく、以下の通り簡潔に、そのエントリの背景にあるとされる無知を、声高に暴き立てています。

…XMLって最初からそういうものだってばorz

…XSLTは最初からそういう目的で作られたものだってばorz

日記の生データをXMLで用意してHTMLで出力させることは自分が6年近く前にやってたことなんだよorz。結局Xalanが遅いのと自分でXML書くのがめんどかったので1年くらいでやめちゃったけど。

kitaの中の人のはてな日記 – サブアカウントを作成

まさか mala さんが XML や XSLT の最初から想定されていたと引用文著者が主張する目的を御存知ないとも、日記の生データを自分で書いてHTMLで出力させたことがなにかを意味していたのかもしれない6 年近く前の文脈でエントリを書いたとも到底思われず、不審な思いがしたのでした。

ところで6 年近く前などと述べられているのを見ると、AJAX breathes new life into Web apps | InfoWorld | Analysis | 2005-05-23 | By Peter Wayner にて、Brendan Eich 氏が以下のように述べていたことを思い出します。

Brendan Eich, the creator of JavaScript at Netscape (Overview, Articles, Company), says the world is just now discovering what he imagined back in 1995. He says, “We [Marc Andreessen and I] always intended JavaScript to enable client-centric apps that did not have to reload pages from a server.”

AJAX breathes new life into Web apps | InfoWorld | Analysis | 2005-05-23 | By Peter Wayner

確かに Ajax は 10 年前にすでに発想されたアイディアだったのでしょう。しかし、それがなぜ the world is just now discovering what he imagined back in 1995 な状況になってきたのでしょうか。それを考えることが僕にとっては面白い。「そんなの 10 年前に考えてたよ（ぷげら」と、Brendan Eich 氏はいいたかったのでしょうか。

バトンシリーズも混沌の様相を呈し、そしてもうみんな飽きたかなってな折り、ハテナオヤさんがMy favorite CPAN modules baton 構想 をぶちあげてらっしゃったりします。

Musical Baton に始まった○○バトンがあちこちで回覧されていて、なんだかえらいことになっているようです。個人的には二番煎じはゴッゴルの後のデースなんとかみたいでちょっと触れたくない気もしています。

でも、渡されたバトンにしたがって書かれたエントリーが、第三者にとっても有益な内容になるんならそれはありだな、と思って考え付いたのが、My favorite CPAN modules baton です。(笑) お気に入りの CPAN モジュールを質問するバトン。対象狭っ!

naoyaのはてなダイアリー – My favorite CPAN modules baton 構想

で、単に好きなモジュールをあげるだけでは面白みがないので、後から収集・再利用が可能になるような形式でもって書くことを義務づけましょう、と。神崎さんが試みられているやり方が例としてあげられていますが、こういうものこそ microformats 的にさくっとざっくりでっち上げるのがいいのかな、と思いました。入力していくだけで好きなモジュールを仕様にそってマークアップした HTML ができるようなフォームを作って、それを Blog のエントリにぺっと貼り付ければオケ、みたいな。気軽。まぁ、思っただけで具体的になにか考えたわけではないのですが！ つか、仕様を決める前にバトンブーム自体が終わりそうだしｗ