ちょっと気を抜くとトイレにGO!状態で寝てられませんよ。

そういやCCCDのせいでほとんど聞かなくなっていたいまどきの（流行物の）音楽を、CCCDがなくなる方向に変わったってことで、再び聞くようになった。音楽視聴環境がPCメインの人間には、地雷（CCCD）混じりの音楽なんて暢気に聞いてられなかったし。でもまだ最新譜以外には地雷混入率が高いんで、あんまり暢気でもいられないわけだけど。

ただここ数年（1、2年くらい？）ろくに音楽を聴いていなかったんで、いまどきの人たちは何がなにやらさっぱりわからない。ひとまず無難に、東京事変「教育」（すげー、ピンの椎名林檎と変わってねー）とイエモンのベストを買いつつ、「花」が良かったんで試しにORANGE RANGEの「musiQ」を買ってみたら、なんだかものすごい代物だった。いや別に聞き慣れてみればそれなりって感じなんだけど、このポリシーのなさはすごいな。「花」のようなものを期待して買うと裏切られる。

で、ちょっとアルバム単位で適当に買うのはリスクがおおきそうなんで、昔チャレンジしようとしてデジタル入力付きサウンドカードを入手するのが面倒で挫折した、「空から音楽が降ってくる」計画を再発動。幸いスカパー！はブルーパック契約なんでデジタルラジオは聴けるし、長時間録画が可能なRD-X5もある。RD-X5のスカパー！連動はデジタルラジオには効かないみたいだけど、まあどうせ4時間単位のループを録音するだけだから、ふつうに外部機器を時間指定で予約しておけばいい。

手順としては、画質1Mbps・音声LPCM設定でRD-X5に録画し、VirtualRDでPCに転送し、TMPGEncで音声を分離し、WaveSplitterで自動分割＋手動調整し、できあがったWaveファイルにSTAR digioのWebサイトからダウンロードしたPDFを見ながら曲名・アーティスト名をつけ、iTunesに取り込んでMP3エンコードし、さらに楽曲情報を修正する、といった感じ。ちなみに4時間分のデータは4Gバイトを越えるんで、PCに取り込んでから面倒なこと（2G超のファイルを扱えるソフトは少ない）になるのを避けたい場合は、RD-X5の段階で曲の切れ目でファイルを分割してから転送するといい。

まだちょっと手順的に面倒なんで、しばらく試してから手順を最適化する手段を模索してみる予定。PDFからの自動リネームツールってまだ試してないんだよなー。ちなみに2G超のWaveファイル編集ツールとしては、Audacityが使えるみたいですよ。って書いていて、ふと思ったけどもしかしてVirtualRDを使うよりも、5倍速DVD-RAM経由でPCに持ってきた方が話が早い？　RD-X5のネットワーク周りは10baseらしいからなー。そういや5倍速のDVD-RAMって5倍速非対応のドライブにマウントすると「ディスクが汚れているので書き込めません」とか出たりするのね。DVD系の速度違いメディアって、互換性低いなー。

また、「はてなCTOの伊藤直也氏が語る「はてな開発の裏側」がネタもと。

「Perlの正規表現はとても優秀で、モジュールと比べても桁違いに早い。（速度という観点から）XMLモジュールよりも現実的なほうを実装している」。

というのを読んで、PEARのXML_ParserベースのAmazon WebサービスのレスポンスXMLパースクラスと、preg_match(_all)を使ったパースクラスを作って、

$amazon =& new パースクラス();
$amazon->setInputString(レスポンスXML);
$amazon->parse();

なんて処理を100回ループして速度を比較してみたら、XML_Parserベースの場合、

real 0m4.423s
user 0m2.970s
sys  0m0.020s

preg_match(_all)を使った場合、

real 0m2.493s
user 0m1.120s
sys  0m0.000s

なんて感じだった。しかもテストコード内で最初パース処理を1000回ループしようとしたら、XML_Parserベースの方はmemory-limit（8Mバイト）に引っかかって途中で落ちやがるし。

ってことで、確かにXMLライブラリを使うよりも、正規表現を使った方が速度的にも上だし、メモリ効率的にも上みたいだな。RSSも同じくって感じなんだろうなー。AmazonとRSSのパースライブラリを一通り正規表現ベースに書き換えるべきなんだろうか。AmazonはともかくRSSは（バージョンが多くて）辛いよなー。

そういや、PHPって明示的にunsetしても（たとえば上記の最終行にunset($amazon);したり）メモリは解放されないみたいだけど、これってどうにかならないのかなー。DB関連のオブジェクトは強制的に解放する関数が用意されているけど、通常の変数領域を強制的に開放する手段はないのか？

昨日の昼過ぎ、交通事故りましたよ。オクサンの運転で買い物に行く途中、信号待ちしていたら、後ろからがくんと衝撃。追突されますた。なんかもうメリークリスマスって感じですよ。後ろからちょっと早歩きの人にぶつかられた程度の衝撃だったんで、多分ぶつかった車はスピードがほとんど出ていなかったことでしょう。ぶつけた本人の弁によれば、落とし物を拾おうとしてブレーキから足が離れたんだとか。

うちの車の被害としては、リアのブレーキランプのところのカバー（はめ込み式＋ねじ止め）が衝撃で外れかけ（その場でつけ直してもらった）、給油口のカバーが開き（単に閉め直して終わり）、リアについている車名のバッジ（両面テープ）がはがれかけた（これは両面テープでつけ直す必要あり？）、って感じ。相手の車はちょっとだけバンパーにこすれた傷がついたくらい。

まあたいしたことはないと思ったんだけど、子供も乗っていたし、後でむちうちとかの症状が出たりしたらいやだから、一応警察を呼んで現場検証してもらった。

ちなみに相手は近所の自動車修理会社の人だとか。しかも、友達の車を修理して回送中だったとか。今のところ、大したことはなさそうな感じだったんで、その人の会社で修理してもらう予定。バンパー交換になるかどうかは微妙だけど、一応交換してくれるのかな？　まあ100％向こうが出すだろうし、その辺はどっちでもいいや。見た目上もその後乗っていても、特に変なところはなさそうだし。

当事者に預けるってのがちょっと気持ち悪いけど、あまりにも大したことない損傷だからまあいいよなー。ただ年内は部品とかの手配ができないとかで、年明けてから預けに行く予定。もしこれで人身事故になったりすると、誰の保険を使ってどうするのか、とかがえらいややこしいことになるでしょう。一応うちの保険屋さんにも連絡をしておいた方がいいのかなー。停車時に後ろから追突ってパターンなんで、こっちの保険屋さんの出る幕はないと思うけど。

なんかyucoさんのところからtrackbackを受け、この手のネタがまた復活しているらしいことを知ったんで、昔のアーカイブを掘り起こして再公開。っつーか、単にリンクを張り直しただけだけど。

• Web Nikki Explorer α版

.NET Framework 1.0が必要なんで、それに対応した環境である必要がある。Windows 2000/XPあたりで.NET Frameworkがインストール済みなら大丈夫。あと、IEもインストール済みである必要があるけど、これはまあ前記環境ならOKだよね。最近はWindows Updateで.NET Frameworkってインストールされるんだっけ？

アーカイブを展開すると、5ファイルくらいできる中の、WebNikkiExplorer.exeを実行する。すると味も素っ気もない3ペインのウィンドウが表示されるんで、[Item]-[Add Documnet]から、追跡したいblog記事ページ（パーマリンク）を開く。たとえばうちの、http://tdiary.ishinao.net/20030315.htmlとか。

すると、左側のペインにその記事のURLが登録され、さらにtrackback autodiscoveryに成功すると、そのtrackback送信先URLをたどって、ツリー上に話題のつながりを表示する。初期状態では1階層先までしかたどらないんだけど、ツリーのルートを右クリックして、[Trace All Trackback]を実行すると、再帰的に枝のtrackbackをたどっていき、運がいいと巨大なツリーが展開される。

（追記）↑嘘だった。[Trace All Trackback]は指定した枝の子枝すべてに対して1階層trackbackをたどるだけで、再帰的にはたどらなかった。再帰的にたどるとバグってた時にやばい挙動になりそうだからやめたんだったかな。というわけで、再帰的にたどりたい場合は、各小枝に対して手動で[Trace All Trackback]を実行してください。

まあこんな感じで、trackback autodiscoveryとtrackback ping URLの__mode=rssに対応しているサイトならば、自動的にtrackbackの送受信関係をたどっていくことが可能ですよ、という技術デモなわけです。

ちなみにこのツールは簡易RSSリーダー的な機能も持っていて、[Item]-[Add RSS Feed]からRSSのURLを食わせてやると、RSSも読み込める。んで、RSSのルートで[Trace All Trackback]すると、そのサイトの直近の記事のtrackbackを一通りたどってくれるんで、trackbackが多そうなサイトで試してみたりするといいかもしれない。ただ、「trackback autodiscovery→__mode=rss→さらにその先をたどる（再帰）」とHTTPアクセス回数が結構多くなるんで、同じサイトに頻繁にアクセスをかけたりしないようにしましょう。

このネタのうちのサイトの初出は、「Trackback情報を使って、サイト横断的に議論を閲覧できる未来 from void GraphicWizardsLair( void ); //」あたりだったらしいです。ちなみにこのプログラム、現在ソースは行方不明中。でもまあ大したことやってないんで、作れる人なら1日で作れるでしょう。RSSにtrackback ping URLが含まれている場合はautodiscoveryせずにそっちを使ったり、複数サイトにtrackbackを送っているサイトがあった場合は、同じ枝を2回HTTPアクセスでたどらないようにしたりするあたりが、ちょっと気を遣うところだったかな。

blogmapでもある程度ランキング上位に入ったblog記事に関してのみ、trackbackの追跡をやろうかと思ったりもしているんだけど、最近はちょっとは意味のある情報が得られるようになったのかなー。多分あれから1年半以上経った今でも、（blogmapが現在行っている）リンク解析で得られる情報以上に有意な情報は得られないだろうと思っているんだけど。でもまあ、サイトの質によってはちゃんと意味のあるtrackbackが集まっているところもあるんだろうけど。

下の子供がゲロゲロになった。ひどいときは10分に1回くらいのペースで吐く。しかも、まだ1歳2ヶ月なもんだから、洗面器に吐かせようとしても吐きながら暴れる。吐いていないときも、腹減った喉が渇いたと暴れる。そして、吐く。さらに血便＆血尿というおまけまでついてきた。

という一晩を過ごし、夜が明けてから最寄りの病院に問い合わせてみたらはみんなもう冬休みに入っていたんで、雪の中救急病院まで車で行ってきた。診断の結果は、ウイルス系の風邪でしょうということで、胃と腸の薬をもらって帰宅。様子を見ながらちょっとずつ水分とおかゆをあげて行きましょう、とのこと。冬休み中に治るかなー。

「[blogmap] そういや」で触れた、trackbackの追跡機能を載せてみた。けど、さすがにこれはちょっと重いなー。ということで、汎用的なtrackback追跡機能としては載せず、blogmapでデータ収集しているサイトのみ追跡可能なようにしてみた。

呼び出すリンクは、「サイト情報」ページにのみ用意してある。

• http://1470.net/bm/siteinfo?url=http://tdiary.ishinao.net/

みたいな感じで、trackbackを追跡したいサイトの「サイト情報」ページを呼び出すと、最近10件の更新記事と他のサイトから言及された記事のリストが表示される。そして、それぞれの横に「trackbackを追跡する」というリンクがある。それをクリックするとその記事に対するtrackbackを再帰的に追跡する。

たとえば、うちで比較的多くtrackbackがたどれる記事は、

• http://1470.net/bm/map/8650484

あたりかな。

ちなみに追跡していった先に、既出の記事が存在した場合はその枝はそれ以上先まで追跡せず、[この枝と一緒]というリンクが付加される。それをクリックすると、その記事を追跡した枝へページ内アンカーリンクで飛ぶ。

あと、あんまりtrackbackの追跡先が（再帰も含めて）多い場合は、最大100件まで追跡したところで追跡を打ち切る。その場合、「trackback数が多いため、追跡を中断しました。」と表示して、その枝から先の追跡を中断する。たとえば、

• http://1470.net/bm/map/8162108

の下の方みたいな感じ。

trackback追跡が中断された末端の枝に、その枝からの追跡結果を表示するための「ここから追跡」リンクを追加。ただし、その枝の記事URLがblogmapに登録済みURLじゃない場合は、ページ検索に遷移しちゃいます。大量trackbackで追跡が途中で終わっちゃった場合なんかに続きを追いかけるのに、このリンクを使ってください。

あと「trackbackの追跡機能」の、

こっちにも是非RSS出力をヽ(´Д`；)ノ

についてはどうしたもんでしょうねー。RSS化しちゃうとツリー構造という重要な情報が表現できないんだよなー。適当に拡張してツリー構造を表現したところで、対応するリーダーがないと意味がないだろうし。せめてtrackbackから取得できるRSSがdc:dateくらい持っていてくれれば、フラットなリストとして出力してもそれなりに意味があるデータになるんだけど。

ツリー構造情報を生かしつつ、RSSリーダー等でも使えるような、なんかほどよい表現方法を思いつけば、この機能でもRSSを配信するかも。

「ここから追跡」をつけたんで、一度に5階層以上は再帰追跡しないようにした。ときどきものすごい深い階層まで追いかけて、HTMLレンダリングがゲロ重になっちゃう場合があるみたいだし。5階層より先を追いたい場合は、「ここから追跡」でたどってください。この方が使い勝手のバランスがいいでしょう。

というわけで、trackback追跡時の制限としては、

• 最大100記事（URL）まで
• 最大5階層まで

という二つがあることになります。

blogサイトのある記事から、その記事に関するtrackback追跡へリンクする方法としては、

• http://1470.net/bm/map?url=[記事のパーマリンク（をURLエンコードしたもの）]

なんて表記が使えます。ただし記事のパーマリンクに、アンカーリンク（index.html#p1）とかQUERY_STRING（?a=123&b=xyz）とかが含まれるような場合は、記事のパーマリンクは必ずURLエンコードしておく必要があります。たとえばうち（tDiary）の場合だと、

• http://1470.net/bm/map?url=http%3A%2F%2Ftdiary.ishinao.net%2F20041227.html%23p01

なんて感じ。ちなみに、trackback追跡の結果は最長2時間キャッシュされるので、一回アクセスするとその後2時間以上経たないとその内容は更新されません。