これを使えば、MMにNow ReadingだけじゃなくてNow Playingを登録する機能も簡単につけれそうだな。それ以前にASIN以外のデータを扱う部分を作らなきゃいけないけど。

この辺の仕様はiTunes COM SDKに書かれているらしいんで、ダウンロードしておこう。

ちなみにtDiary（Wikiスタイル）＋Sleipnirだと、

var pnir;
var document;
var id;
pnir     = new ActiveXObject("Sleipnir.API");
id       = pnir.GetDocumentID(pnir.ActiveIndex);
document = pnir.GetDocumentObject(id);
if (document == null)  {
pnir.MessageBox("Document オブジェクトを作成できません");
}
else {
var iTunes = WScript.CreateObject("iTunes.Application");
var track  = iTunes.CurrentTrack;
var strNowPlaying = "![Now Playing] " + track.Artist + " - "
+ track.Name + " (" + track.Album + ")";
document.forms[0].body.value += strNowPlaying;
document = null;
}
pnir = null;

なんて感じのスクリプトを登録して、tDiaryの編集画面を開いているときに実行すると、

なんて感じになる（最後の時刻はふつうはつかない。うちは改造しているんでtDiary（サーバーサイド）の方でつけている）。本文に!見だしじゃちょっとうざいな。フッタのサイドバー部に特定の書式で埋め込む、とかの方が実用的か。

ああしまったorz

「最後に追記したセクション」でtrackbackを送ったら、テストセクションの方のURLで送られちゃったよ……。

ってのはなんか変な表現だな。「特定の記事データをRSS形式で取得する方法」といった方が正確か。いや「特定の記事のRDFデータを取得する方法」の方がより正しい気もするけど、欲しいのは単なるメタ情報ではなく、既存のRSSリーダー等で扱いやすいRSS（アイテムが1個しかないもの）形式のデータなんだよな。別にATOMでもいいんだけど。

ともかく、そういう方法（APIとか）って現在は用意されていない（新着RSSからその記事が外れてしまうともう取得できない）気がするけれども、あった方がいいよね。まさかいちいちBulkfeedsみたいなRSSの集積所を介して取るわけにもいかないし。一応trackback auto-discoveryなんかで使っている、HTML内に埋め込むRDFデータがその手のソースとして使えそうだけど、できればもっときれいな方法が欲しい。

というのは、Rubyist Magazineの巻頭言を読んでいて、

また、まとまったサイトを自力で立ち上げ、そのサイト運営と執筆とを兼務するのは何かと困難がつきまといがちであるし、載せる内容もある程度絞り込んでいかないと収拾がつかなくなりやすい。さりとて昨今流行の blog や web 日記などでは、 Ruby 関連情報の紹介とともに最近読んだライトノベルの感想や今夜のおかずや猫の写真を載せてしまいがちになるし、そのうちラノベサイトやごはんサイトや猫サイトになってしまう危険性も否めない。

ってあたりと、最近のtrackbackセンター系のネタを組み合わせると、いろんなblogツールから送られたtrackbackを使って、Webマガジンみたいなものが作れそうだなーと思ったから。

どんな感じのものかというと、Webマガジンはtrackback Ping URLを用意しておいて、そのWebマガジンで使ってもいい記事からtrackbackを送ってもらうようにする。しかし、そのtrackbackがそのままWebマガジンに掲載されるわけではない。Webマガジンの編集者がtrackbackをチェックして、Webマガジンに掲載したいものを選別する。んでもって、一回分の記事がたまったら、trackbackから取得した記事情報を使って、Webマガジンを発行する。

たぶんトップページはGoogleNewsみたいにタイトルと要約あたりを使って構成することになるだろう。でも、構成やグルーピング、見出しなどはWebマガジンでコントロールする。

さらに、表題にあるような「特定の記事のRSSを取得する方法」があり、しかもそのRSSにはcontent:encodedが含まれていた場合、見だしレベルではなく本文自体（余計なナビゲーション要素など抜き）もWebマガジン側で扱えるようになる。content:encodedの内容は編集できないだろうが、記事のデザインをWebマガジンにあわせることができるだろう。

そうすることで、本文記事の体裁もWebマガジン側でコントロールすることができ、ずいぶんWebマガジンっぽさが増す。トップページだけしかコントロールできないんじゃ、単なる豪華なリンク集になっちゃうしな。

また、利用するRSSデータはWebマガジン側で定期的に更新チェックをかけるようにすると、記事内容の更新権限は各サイトの記事執筆者が持ちつつ、Webマガジンとしての（レイアウトやデザインの）編集権限だけをWebマガジン側で持つことが可能になる。

次にtrackbackセンターを作る人は、どうせならそのくらいまでやってほしいなー。単にPing URLを公開してtrackbackを受け付けるだけじゃ公開データベース止まりだ。きちんとした編集者が自分なりの観点で編集（取捨選択、グルーピング、レイアウト）すれば、結構面白いものができると思うんだけど。

特に技術系のネタなんかは、こういうやり方でもかなりいいものができるんじゃないかな。

うがー

試しにRubyist Magazineにtrackbackを送ってみたら、全文掲載されちゃったよ。tDiaryのtrackbackってデフォルトで全文送るんだっけ？　今日はtrackbackの失敗が多い……。

この記事はネタばれ防止プラグイン集に移動しました。

というアプローチを取ることにした。というのは、「それぞれの用途に特化した複数のシステム上にコンテンツを生成し、それらのコンテンツをライトウェイトに後付で結びつけて運用するアプローチ」の一環。

元々tDiaryに移行したときからそうしようと思っていたんだけど、用途ごとに特化したblogツールを自作しようと思っていたらいつまで経っても完成しないんで、そっちもありもの（Movable Type）にして稼働開始。

基本的に、tDiary上にジャンルにこだわらないさまざまな思いつきを時系列で書いていき（フローテキスト）、そこから何かコンテンツとしてまとまったものが浮かび上がったら、それらをとりまとめてblogツールの方に移動する（ストックテキスト）といった運用イメージ。

というのは、本来コンテンツとしての有用度が高いのは、ストックテキスト的な部分なんだけど、はじめからストックテキストとしてコンテンツを作るのは難しい。なかなか完成しないと出力ができず、出力がないと反応もないので、何もかもが沈滞する方向に向かってしまう。かといって、気軽にフローテキストとして出力していくと、コンテンツの完成度が高まらないし、また有用なコンテンツも時間とともに流されがちだ。

WikiLikeとかで試していた、フローテキストもストックテキストもどちらも同じツール（枠組み）できちんと扱えるようにしようという試みは、あきらめた。コンテキストによって見せ方（ユーザーインターフェース）を変えればそれなりにいけるかと思っていろいろ試してみたけど、どうにも（保持するデータ形式もユーザーインターフェースの作りも）中途半端になりがちだ（というか納得のいくレベルの完成度と汎用性を両立できなかった）。

ちなみにフローテキストの集積所としてはtDiary以外にも影舞（プロジェクト管理）があるし、ストックテキストの集積所も基本はMovable Typeにするつもりだけど、場合によってはWikiや静的HTMLを利用することもあるだろう。あとsubversionも使うつもりだけど、どうやって統合するか考え中です（学級委員会風）。

で、コンテンツの移動管理はリンクやrewriteやredirectを駆使して手動で行いつつ、全体をライトウェイトに結びつける手段の一つとして、Estraierのestmerge.cgiを使った全文検索を用意し、複数システム（サーバー）にまたがったコンテンツを串刺しで検索できるようにしておく。

estmerge.cgiは複数システムにまたがった関連文書検索もできるから、各コンテンツに「関連記事」リンクとかを用意しておけば（まだ作ってない）、ある程度自動的に複数システムにまたがったコンテンツを連動させることができるだろう。

あと「MM/本のメモ」のような、ライトウェイトな外部データベースでURL情報を管理し、RSS出力を介して利用しておくことで、あるコンテンツのURLが移動した場合にそちらのURLさえ更新すれば、自動的に各所の（RSSを利用して生成した）URLも最新の情報に追随することになる。

現状はまだ作りかけだけど、今後の方針としてはそういう方向でサイト全体を再構成していく予定。

tDiaryに単純なネタばれ防止プラグインが見あたらなかったんで、自分で作ってみた。

tDiaryスタイルだったら適当なスタイルを指定してそのスタイルを使えばいいんだろうけど、Wikiスタイルを使っていると気軽にスタイル指定とかできないんで。

ChangeLog
2004-09-11   ishinao <ishinao@ishinao.net>
* 作成＆公開
2004-09-13   ishinao <ishinao@ishinao.net>
* 透明度の計算がぼろぼろだったので修正。
* iroaseは@modeがdayの時以外は完全墨消しに変更。

墨消し sumikeshi

• 概要
  • スタイルシート設定で指定部分の背景色と文字色を墨（黒）にする。不透明度は引数で変更可能。

• 記法
  • sumikeshi(str, opacity)
• 例
  • <%=sumikeshi("隠したい文章", 60) %> → 隠したい文章
• 引数
  • str 隠したい文章
  • opacity 不透明度(%)。省略時100%（完全墨消し）。

コメントアウト commentout

• 概要
  • HTMLソース上にコメント（<!-- 文章 -->）として出力し、代替文字列を表示する。
• 記法
  • commentout(str, replace)
• 例
  • <%=commentout("隠したい文章", '(ほにゃららら～)') %>→ (ほにゃららら～)<!-- 隠したい文章 -->
• 引数
  • str 隠したい文章
  • replace 代わりに表示する文章。省略時「(HTMLソースをご覧ください)」。「""」を指定すれば表示上は隠し文字があるかどうかもわからなくなる。

色あせ iroase

• 概要
  • 基本は墨消しと同じ。ただし時間が経てば経つほどはっきり表示されるようになる。けど、tDiaryはキャッシュがあるから、キャッシュが更新されないと、不透明度も更新されないだろうなー。プラグインはキャッシュされないそうなので、ちゃんと不透明度も更新される模様。
• 記法
  • iroase(str, days)
• 例
  • <%=iroase("隠したい文章", 10) %> → 隠したい文章
• 引数
  • str 隠したい文章
  • days 隠しておく日数。省略時7日。

ソース

</p> <h1 id="tdiary-sumikeshi-rb">tDiary ネタばれ防止プラグイン集 sumikeshi.rb</h1> <h1 id="author-ishinao-ishinao-ishinao-net">Author: ishinao <a href="mailto:ishinao@ishinao.net">ishinao@ishinao.net</a></h1> <h1 id="distributed-under-gpl">Distributed under GPL</h1> <h1 id="changelog">ChangeLog</h1> <h1 id="2004-09-11-ishinao-ishinao-ishinao-net">2004-09-11 ishinao <a href="mailto:ishinao@ishinao.net">ishinao@ishinao.net</a></h1> <h1 id="part-911ce27162e111fb">* 作成＆公開</h1> <h1 id="2004-09-13">2004-09-13</h1> <h1 id="part-b21e284cd20c2659">* 透明度の計算がぼろぼろだったので修正。</h1> <h1 id="iroase-mode-day">* iroaseは@modeがdayの時以外は完全墨消しに変更。</h1> <p>def sumikeshi(str, opacity = 100) color = 'black' if opacity >= 100 bgcolor = 'black' elsif opacity <= 0 bgcolor = 'white' else bgcolor = '#' + sprintf("%02x", Integer(255 * (1 - opacity.to_f / 100))) * 3 end <<-HTML <span style="color: #{color}; background-color: #{bgcolor}">#{CGI::escapeHTML(str)}</span> HTML end def commentout(str, replace = '(HTMLソースをご覧ください)') <<-HTML <span>#{CGI::escapeHTML(replace)}<!-- #{CGI::escapeHTML(str)} --></span> HTML end def iroase(str, days = 7) if @mode == 'day' then elapse = Time.now - @date full = days * 60 * 60 * 24 if elapse >= full opacity = 0 else opacity = Integer(255 * (elapse.to_f / full)) end else opacity = 00 end bgcolor = '#' + sprintf("%02x", opacity) * 3 <<-HTML <span style="color: black; background-color: #{bgcolor}">#{CGI::escapeHTML(str)}</span> HTML end

blogmapで取得している各種サイトの更新状況を試しにグラフ化してみたところ、まあそれなりに面白いデータなんじゃないかと思ったんで試しに公開。縦が1時間あたりの更新サイト数。「k」は「×1000」ね。のべ数＋URLの揺らぎ誤差あり＋個人サイトじゃないものも含まれているんだけど、まあなんとなく個人サイトの更新時間の傾向が出ているんじゃないかなー。

3日間

1週間

1ヶ月

0時ちょっと前にピークを迎え（ゴールデンタイム）、6時ちょっと前にはもっとも少なくなり（さすがにみんな寝たか）、昼過ぎには小さい山ができる（昼休み中・明けの更新）、ってのがデイリーの基本的な動き。平日は、月～木はあまり変わりがないんだけど、金曜日の夜は結構減るあたりから、金曜の夜に遊びに行く人の割合もなんとなく計算できるかな。土日は平日よりも更新が少ないけれども、思ったよりも減らないな。1割も減っていないか。

ちなみにblogmapで更新チェックしているサイトというのは、

1. 情報を二次配信している各種アンテナサイト
2. 登録数が多いはてなアンテナ（はてなダイアリーアンテナ含む）
3. PING.BLOGGERS.JP、BlogPeople、Bulkfeedsなどの公開pingサイト
4. Seesaaブログなどの新着情報を配信しているblogサービス

あたりがソースなんで、最近はblog系サイトにデータが偏り気味かも。昔は1が中心だったんで、老舗の日記系サイトが多かったんだけど。

コンピュータを使った処理に対して、無意識に完璧さを求める人って結構いそうだけど、単純な計算処理以外に関してはコンピュータ（というか、その上で動くプログラム）は結構いい加減なものだ。日本語処理に関するプログラムなんかは特に。そういうプログラムは、完璧な処理を行うことが目的なのではなく、完璧にはなり得ないことを知りつつもできるだけ世の中を便利にするために作られているのだから。

というわけで、はてな公聴会議事録より近藤さんの、

簡単で馬鹿な仕組みを、馬鹿だなあと思って使ってほしい

ってものをはてなダイアリーのポリシーとして周知させれば、トラブルの多くは解決するんじゃなかろうか。「完璧なシステムを作る（ために複雑なプログラムロジックや運用ルール、煩雑な調停作業を持たなければならない）ことが目的なのではなく、手軽で面白い（けど厳密に考えると誤爆やいたずらなどの問題もある）仕組みを使って楽しもうよ」なんだよってことで。

ただ、すでに使っている人の中で「そんなポリシーには賛同できない」って人に対する救済措置は必要だと思うけど。前に、「はてなコミュニティのもめ事を見ていると」で、

有料ユーザーと無料ユーザーにコミュニティ（技術的には、キーワードリンクやrefer自動送信などの及ぶ範囲）を分割しつつ、どちらに所属するかをユーザーが決められるようにする（有料ユーザーはどちらにも同時に所属することが可能）と、ちょっとはすっきりするのかもしれない。

って書いたけど、上記の「有料ユーザー」を「簡単で馬鹿な仕組みを、馬鹿だなあと思って使ってほしい」に賛同するユーザー、「無料ユーザー」を賛同できないユーザーに読み替えて適用するのが妥当かも。

ふーん。一応S＆Mシリーズのキャラクターが準主役的に出ているんで、シリーズファンとしてはそれなりに楽しかったけど、内容はふーんって感じだ。海月くんのキャラクターも微妙だなー。周辺のキャラクターとの絡みで別の面白さが出てきたりするのかなー。まあシリーズファンだから今後も読むだろうけど、なんか意図がよくわからん。まさか