2004-12-03 [長年日記]
_ また風邪か (21:19)
一昨日の夜から下の子が39度台をずっとキープするという死にそうな風邪をひいていて、座薬をつっこんで強引に熱を下げてしのいでいたらようやく今日になって熱が引いてほっとしたのもつかの間、今度はまた俺にうつったっぽい？ なんか急激にものすごい頭痛が始まったんですが。っつーかもう、1ヶ月くらいずっといろんな種類の風邪をひき続けているんですが。「顔色悪い」がデフォルトになりつつあるのですが。
2004-12-07 [長年日記]
_ しばらくトップページ以外は動作がビミョーです (17:45)
blogmapを大幅にリニューアルする予定です。で、バックエンドの処理だけ先行して新しいエンジンに変え、旧エンジンは止めてしまいました。一応トップページだけは新しいバックエンドのデータを使って更新をかけていますが、それ以外のページの更新は停止しています。いろいろ不整合があったりするかもしれませんが、完全リニューアルするまで生暖かい目で見守っておいてください。よろしくお願いします。
2004-12-09 [長年日記]
_ 音質不具合改善ファーム (11:56)
「東芝、RD-X5/XS36の音質不具合を修正するファーム」ってことだったんで、「ＨＤＤ＆ＤＶＤビデオレコーダー ＲＤ−Ｘ５／ＲＤ−ＸＳ３６ 音質改善ソフトウェアのご案内」に行って早速アップデートしてきた。
ちなみにうちは、スカパー！をD1端子で接続しているんで、スカパー！はすべてR2録画になっていたんだけど、音飛びはかなりひどかった。番組の視聴に差し障りがあるほどではない（致命的に台詞が聞き取れなかったりすることはほとんどない）けど、ふつうに見ていて番組中数回以上は必ず「ぷつっ」と音がとぎれるというかノイズが乗っていた。
最初のうちは「まあどうでもいいや」と思っていたけど、結構いいところでノイズが入るなんてことが何度かあって、だんだんむかついてきたんで、一昨日あたりにR2の予約はすべてL-PCMに変更したところだった。けど、アップデートしたんでもう一度M1に戻しておいた。これで音飛びがなくなってくれるとありがたいな。別にどうでもいい番組ばっかりしか取らないんで音飛びが致命的な問題にはならないんだけど、精神衛生上良くないし、あと子供用におろしたRD-X2にコピーする時間を短縮するためにもいちいちL-PCMにしてらんないし。
_ こっそりテスト (21:33)
まだ完成度10％くらいだけど、ひとまずランキング系のページはこんな感じになる予定です。
いろいろエラーが出たり、一時的にアクセス制限をかけたりするかもしれませんが、試しにちょろっと使ってみて、感想とか要望とかがあったらツッコミください。
ちなみに今回からNetscape Navigator 4系対応は捨てました。逆にテキストブラウザーならばそこそこちゃんと表示されると思います。
2004-12-13 [長年日記]
_ 携帯版 (15:27)
リニューアル開発中サイトに、携帯対応のテストページを作ってみました。
「基本はiモード用だけど、他のキャリアでもそこそこ見えるよね」あたりを狙ってみたのですが、どんな感じでしょう？ 一応うちのW21Sではそれなりに見えるっぽいけど。
2004-12-14 [長年日記]
_ やっぱり新サイトに移転しちゃいます (21:32)
まだ完成度は高くないんだけど、ほとんど機能していない旧サイトをうごかし続けるよりも、作りかけの新サイトを使って反応を見ながら拡張していった方が良さそうな気がしてきたんで、主要な機能は一通り新サイトの方をメインにしてしまいました。
- blogmap新サイト - http://1470.net/bm/
新サイトに移行し終わったのは、
- URL、メディアランキング
- URL検索
- trackbackによる投稿
で、まだ移行していないのは、
- クリッピングサービス
- メディア検索
- テンプレート生成機能
あたりです。移行した機能についてはだいたい、旧サイトのURLにアクセスすると自動的に新サイトにリダイレクトします。
ちなみに新サイトの特徴としては、
- 巡回するURLを従来のトップページからRSSに変更したんで、記事単位の情報が取得できるようになった
- 代わりに、RSSに収録されている範囲でしかURL等の情報が得られない
- いろんなリストをRSSで取得できる
- 携帯電話からのアクセスに対応
- 多分基本的なレスポンスが早くなったんじゃないかな？
- 「関連する話題」の精度が高くなったんじゃないかな
って感じです。
一応移行していない機能は、旧URLにアクセスすることで利用できるようにしてありますが、主要なページに対して新サイトへの転送をかけてしまっているんで、直リンクとかしていないと不便かもしれません。順次移行していない機能も、新しいサイトに上位互換の機能として取り込んでいく予定です。
ちょっと強引な移行をしてしまいましたが、たいていの機能は新サイトの方ができがいいと思うんで、ひとまずこっちを使ってみてください。要望・不具合報告等は適当にツッコミください。
2004-12-15 [長年日記]
_ associateに対応 (09:13)
blogmapのメディア系RSSに「associate=[アソシエイトID]」という引数を追加することで、アソシエイトIDを好きな内容に変えられる機能を追加しました（MM/本のメモと同じ機能ね）。自分のサイトのサイドバーなんかにRSSを取り込んで表示する場合なんかにご利用ください。
なんて感じで使います。デフォルト（指定省略時）では私のアソシエイトIDが使われます。
_ pingサーバーを追加 (15:42)
blogmapに更新を通知するweblogUpdates.pingサーバーを用意しました。
がping通知先URLになります。ping通知先に上記URLを入れておくことで、blogmapからの巡回処理が確実に行われるようになります。また、現在巡回先から漏れているサイトも、巡回対象として追加されます。
まだあまりテストしていないので、問題があったらごめんなさい。
_ メディアの関連ページリンク (17:12)
メディア系詳細ページに、「関連するメディア」を追加。
2004-12-16 [長年日記]
_ ランキングRSSにcontent:encodedを追加 (08:41)
ランキングRSSのdescriptionの代わりにcontent:encodedを追加し、従来よりもちょっと詳しい内容を埋め込むようにしました。あと、ついでにtrackback:pingも一応入れておいたけど、これに対応しているリーダーってあるのかな？
_ 巡回ロジックについて (09:32)
blogmapの巡回方法は、
- 公開されているアンテナ（LIRS）やRSS配信サイトから定期的に、さまざまなサイトの更新時刻情報を取得する
- blogmap weblogUpdates.pingサーバー（http://1470.net/api/ping）にpingが送られたサイトはリアルタイムで更新時刻を変更する
- 更新されたサイトが、
- 未登録サイトの場合は、RSS AutoDiscoveryを試み、RSSが見つかった場合はそれを情報収集先URLとして登録する
- 既登録サイトの場合は、RSSのURLが登録されていれば次回巡回時にRSSを取得し、descriptionもしくはcontent:encodedに含まれるURL、ASIN情報を解析する
となっています。現在更新時刻情報を取得しているサイトは、
- http://bulkfeeds.net/app/new.rdf
- http://ping.bloggers.jp/index.rdf
- http://www.di-do.net/cgi-bin/lmnew.cgi?mode=lirs
- http://a.hatena.ne.jp/hatenadiary/source?mode=lirs
- http://www.blogpeople.net/changes.rdf
- http://blog.seesaa.jp/contents/xml/recent_blog.rdf
- http://najo.cc.sakura.ne.jp/~alimika/satomican/rss/all.rdf
- http://semicolon.jp/ussy/mican/natsumican.lirs
- http://kisouma.com/cgi-bin/decopon/deco.lirs
- http://www.h14m.org/hoshino/natsumican.lirs
- http://www14.cds.ne.jp/~not/antenna/nantenna.lirs
- http://club.h14m.org/gachapin/natsumican.lirs
- http://blog.livedoor.com/xml/recent_blog.rdf
- http://blog.dion.ne.jp/xml/recent_blog.rdf
- http://diary.jp.aol.com/applet/newlist?__mode=rss
- http://suk2.tok2.com/new_list_rss.php
- http://www.mypress.jp/rss.rdf
- http://autopage.teacup.com/applet/post/recent?rss
- http://www.tdiary.net/tdiary.lirs （現在orz中）
です（要は記事単位ではなく、サイト単位での更新時刻が取得できるところ。記事単位の更新情報からもデータを集めることは可能なんだけど、いろいろ問題がありそうなんでやめた）。あと、上記から更新時刻情報を取得できていないサイトのうち、私が個人的にチェックしているサイトは自前で適当に更新チェックをかけたりしていますけど、これは将来的に内蔵のアンテナ機能に置き換える予定です。
というわけですので、blogmapに確実に情報を収集される方法としては、
- RSSを配信し、できるだけ多くのURL、ASIN情報をRSSに含める
- RSS autodiscoveryに対応する
- 更新情報取得先アンテナ、pingサーバーにpingを送る（更新情報取得タイミングによっては、たまにデータ収集対象から漏れてしまう場合もある）。あるいはblogmapのpingサーバーにpingを送る（こっちの方が確実）
としておくといいかと思います。RSS autodiscoveryに対応していないけれども、RSSを配信しているという場合は、ツッコミかメールでRSSのURLを教えていただければ、手動で登録します。逆に現在情報収集先に登録されているが、データ収集をされたくない場合も、申し訳ありませんがメールかツッコミでサイトのURLを教えてください。巡回対象から外します。
_ サイト情報を追加 (15:27)
「サイト情報」ページを追加しました。ちなみにうちの場合は、
なんて感じになります。現状では、
- 他サイトからリンクされている記事一覧
- そのサイトで今まで紹介したメディア一覧
を表示しています。自分のサイトの情報を見てみたい場合は、SEARCHから自サイトのURLで検索し、[サイト情報]をクリックしてみてください。
なんかこの機能をつけたら、ずいぶん本来の目的であったblogmap（blogサイト関係図）っぽい感じになったなー。ってあたりで、そろそろサーバーの負荷的に限界が見えてきたかも。まだつけたい機能はたくさんあるんだけどなー。
_ 今日のREFERER SPAM (17:04)
ちょっとたちが悪いなー。いつもの絨毯爆撃系なんだけど、1日に3回もIPアドレスを変えてやってきているし、しかもIPアドレスも80.58.46.235 80.58.34.237 80.55.195.214と最初のオクテットしかあってない。プロバイダもひとつじゃないみたいだし。
しょうがないんで、80.で丸ごとアクセス拒否することにした。けど、どうやらこのSPAMスクリプトはHEADリクエストしか使わないみたいなんで、ひとまず、
<Limit HEAD> deny from 80. </Limit>
ってことで。なんかまずい人がいたら言ってください。
_ 蒼穹の昴(1)(浅田 次郎) (19:24)
西太后は民主主義の英雄だったというすごいストーリーを骨格に、清朝末期の中国を、
- 貧乏な糞拾い出身の少年宦官
- 不良少年出身の英才官僚
- 西太后を始めとした、滅びつつある清朝政府首脳陣
- 各国中国特派員たち
というさまざまな視点から描いた大作。西太后関連の話があまりにもトンデモすぎて、そこだけがいまいちむずがゆかったけど、後は相変わらずの浅田次郎節で面白かった。
特に最後ぐだぐだになりつつあったところで、主人公が見得を切るところがなんかやたらと格好良かった。なんかもう「チャー！」って感じ（意味不明）。
ところでこの辺の歴史的事実ってほとんど覚えてないから、どう見てもトンデモ度が高いこの小説の話が、俺の中で史実になってしまいそうな予感。
2004-12-17 [長年日記]
_ 引数にURLを使った情報ページへのリンク (18:19)
URL情報およびサイト情報ページのURLは、blogmapが内部で割り振った数値IDを使って、
- http://1470.net/bm/urlinfo/[URLのID]
- http://1470.net/bm/siteinfo/[サイトのID]
となっていますが、これを、
という表現でもアクセスできるようにしました。
たとえばうちのサイトならば、
- http://1470.net/bm/siteinfo?url=http://tdiary.ishinao.net/
- http://1470.net/bm/urlinfo?url=http://tdiary.ishinao.net/
- http://1470.net/bm/siteinfo?url=http%3A%2F%2Ftdiary.ishinao.net%2F
なんて感じになります。ちなみにurlパラメータ文字列は、上記一番下の例のようにURLエンコードされている方が確実です。
もしも登録されていないURLが渡された場合は、検索ページにリダイレクトされます。
_ 忘年会 (20:25)
焼酎はまわりが早い。
2004-12-20 [長年日記]
_ サーバー止めてます (12:54)
すみません。ちょっと実験君をしていたら大がかりになりすぎちゃったんで、急遽サーバーを止めちゃってます。1時間くらいしたら復帰させると思いますので、それまでアクセスした方ごめんなさい。
_ 復帰しました (16:09)
一応動いてるけど、まだ実験は継続中。ちなみにどんな実験をしているのかというと、「はてなCTOの伊藤直也氏が語る「はてな開発の裏側」の、
はてな検索では、はてなダイアリーのデータが入力されている検索用のデータベースをメモリ上に用意、さらに検索用のレプリケーションDBを用意することで、はてなダイアリーのパフォーマンスが下がらないよう対策を施している。
を読んで、検索用のレプリケーションサーバーを作ってみた。といっても、マシンは1台しかないんで、同一マシン上にMySQLサーバーをもう1個動かしてレプリケーションしつつ、スレーブ側は検索専用に使うという方法。
はてなの場合は、「別マシン上でメモリを潤沢に使った専用検索サーバー」だからこそパフォーマンスが出ているんだろうし、それに対してここの場合、同一マシン上で複数サーバーを立ち上げたのではマシンリソースが分散されてしまうから意味がないかもしれないけど、各サーバーの設定（主にメモリ使用量）によっては、見かけのパフォーマンスが向上するんじゃないかと思って。lockが分散できるというメリットも大きそうだし。
それに、いったんこうやって同一マシン上でスレーブサーバーを動かしてしまえば、後々別マシン上にレプリケーションサーバーを構築するとき、スレーブを新しいスレーブサーバーのマスターとしてload data from masterすれば、メインのサーバーはread lockなしで簡単に初期導入できそうだ。
とかいいつつ、単にMySQLのレプリケーションを試してみたかったってのが一番大きな理由だったりするんだけど。
2004-12-22 [長年日記]
_ うがー、また風邪だ (01:22)
今度の風邪は下痢系らしいですよ。というか、また下の子、上の子、私と順番にうつってきていますよ。昨日休んだんだけど、全然治る気配がないなー。
_ 空から音楽が降ってくる再発動 (05:11)
ちょっと気を抜くとトイレに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系の速度違いメディアって、互換性低いなー。
2004-12-24 [長年日記]
_ XML_Parserとpreg_match (22:09)
また、「はてな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関連のオブジェクトは強制的に解放する関数が用意されているけど、通常の変数領域を強制的に開放する手段はないのか？
2004-12-26 [長年日記]
_ 交通事故 (19:40)
昨日の昼過ぎ、交通事故りましたよ。オクサンの運転で買い物に行く途中、信号待ちしていたら、後ろからがくんと衝撃。追突されますた。なんかもうメリークリスマスって感じですよ。後ろからちょっと早歩きの人にぶつかられた程度の衝撃だったんで、多分ぶつかった車はスピードがほとんど出ていなかったことでしょう。ぶつけた本人の弁によれば、落とし物を拾おうとしてブレーキから足が離れたんだとか。
うちの車の被害としては、リアのブレーキランプのところのカバー（はめ込み式＋ねじ止め）が衝撃で外れかけ（その場でつけ直してもらった）、給油口のカバーが開き（単に閉め直して終わり）、リアについている車名のバッジ（両面テープ）がはがれかけた（これは両面テープでつけ直す必要あり？）、って感じ。相手の車はちょっとだけバンパーにこすれた傷がついたくらい。
まあたいしたことはないと思ったんだけど、子供も乗っていたし、後でむちうちとかの症状が出たりしたらいやだから、一応警察を呼んで現場検証してもらった。
ちなみに相手は近所の自動車修理会社の人だとか。しかも、友達の車を修理して回送中だったとか。今のところ、大したことはなさそうな感じだったんで、その人の会社で修理してもらう予定。バンパー交換になるかどうかは微妙だけど、一応交換してくれるのかな？ まあ100％向こうが出すだろうし、その辺はどっちでもいいや。見た目上もその後乗っていても、特に変なところはなさそうだし。
当事者に預けるってのがちょっと気持ち悪いけど、あまりにも大したことない損傷だからまあいいよなー。ただ年内は部品とかの手配ができないとかで、年明けてから預けに行く予定。もしこれで人身事故になったりすると、誰の保険を使ってどうするのか、とかがえらいややこしいことになるでしょう。一応うちの保険屋さんにも連絡をしておいた方がいいのかなー。停車時に後ろから追突ってパターンなんで、こっちの保険屋さんの出る幕はないと思うけど。
2004-12-27 [長年日記]
_ WebNikkiExplorer再公開 (16:55)
なんかyucoさんのところからtrackbackを受け、この手のネタがまた復活しているらしいことを知ったんで、昔のアーカイブを掘り起こして再公開。っつーか、単にリンクを張り直しただけだけど。
.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アクセスでたどらないようにしたりするあたりが、ちょっと気を遣うところだったかな。
2004-12-29 [長年日記]
_ ゲロ血便 (12:38)
下の子供がゲロゲロになった。ひどいときは10分に1回くらいのペースで吐く。しかも、まだ1歳2ヶ月なもんだから、洗面器に吐かせようとしても吐きながら暴れる。吐いていないときも、腹減った喉が渇いたと暴れる。そして、吐く。さらに血便＆血尿というおまけまでついてきた。
という一晩を過ごし、夜が明けてから最寄りの病院に問い合わせてみたらはみんなもう冬休みに入っていたんで、雪の中救急病院まで車で行ってきた。診断の結果は、ウイルス系の風邪でしょうということで、胃と腸の薬をもらって帰宅。様子を見ながらちょっとずつ水分とおかゆをあげて行きましょう、とのこと。冬休み中に治るかなー。
_ trackbackの追跡機能 (12:43)
「[blogmap] そういや」で触れた、trackbackの追跡機能を載せてみた。けど、さすがにこれはちょっと重いなー。ということで、汎用的なtrackback追跡機能としては載せず、blogmapでデータ収集しているサイトのみ追跡可能なようにしてみた。
呼び出すリンクは、「サイト情報」ページにのみ用意してある。
みたいな感じで、trackbackを追跡したいサイトの「サイト情報」ページを呼び出すと、最近10件の更新記事と他のサイトから言及された記事のリストが表示される。そして、それぞれの横に「trackbackを追跡する」というリンクがある。それをクリックするとその記事に対するtrackbackを再帰的に追跡する。
たとえば、うちで比較的多くtrackbackがたどれる記事は、
あたりかな。
ちなみに追跡していった先に、既出の記事が存在した場合はその枝はそれ以上先まで追跡せず、[この枝と一緒]というリンクが付加される。それをクリックすると、その記事を追跡した枝へページ内アンカーリンクで飛ぶ。
あと、あんまりtrackbackの追跡先が（再帰も含めて）多い場合は、最大100件まで追跡したところで追跡を打ち切る。その場合、「trackback数が多いため、追跡を中断しました。」と表示して、その枝から先の追跡を中断する。たとえば、
の下の方みたいな感じ。
このセクションに対するはてなブックマーク
_ 「ここから追跡」を追加 (14:32)
trackback追跡が中断された末端の枝に、その枝からの追跡結果を表示するための「ここから追跡」リンクを追加。ただし、その枝の記事URLがblogmapに登録済みURLじゃない場合は、ページ検索に遷移しちゃいます。大量trackbackで追跡が途中で終わっちゃった場合なんかに続きを追いかけるのに、このリンクを使ってください。
あと「trackbackの追跡機能」の、
こっちにも是非RSS出力をヽ(´Д`；)ノ
についてはどうしたもんでしょうねー。RSS化しちゃうとツリー構造という重要な情報が表現できないんだよなー。適当に拡張してツリー構造を表現したところで、対応するリーダーがないと意味がないだろうし。せめてtrackbackから取得できるRSSがdc:dateくらい持っていてくれれば、フラットなリストとして出力してもそれなりに意味があるデータになるんだけど。
ツリー構造情報を生かしつつ、RSSリーダー等でも使えるような、なんかほどよい表現方法を思いつけば、この機能でもRSSを配信するかも。
_ 追跡階層を5階層までに (15:04)
「ここから追跡」をつけたんで、一度に5階層以上は再帰追跡しないようにした。ときどきものすごい深い階層まで追いかけて、HTMLレンダリングがゲロ重になっちゃう場合があるみたいだし。5階層より先を追いたい場合は、「ここから追跡」でたどってください。この方が使い勝手のバランスがいいでしょう。
というわけで、trackback追跡時の制限としては、
- 最大100記事（URL）まで
- 最大5階層まで
という二つがあることになります。
_ blog記事からtrackback追跡へのリンク (19:11)
blogサイトのある記事から、その記事に関するtrackback追跡へリンクする方法としては、
- http://1470.net/bm/map?url=[記事のパーマリンク（をURLエンコードしたもの）]
なんて表記が使えます。ただし記事のパーマリンクに、アンカーリンク（index.html#p1）とかQUERY_STRING（?a=123&b=xyz）とかが含まれるような場合は、記事のパーマリンクは必ずURLエンコードしておく必要があります。たとえばうち（tDiary）の場合だと、
なんて感じ。ちなみに、trackback追跡の結果は最長2時間キャッシュされるので、一回アクセスするとその後2時間以上経たないとその内容は更新されません。
_ trackback追跡のRSS (23:17)
結局すげーてきとーな実装にしてしまった。というのは、ツリーの階層構造をtitle要素の頭に階層の深さ分だけ「*」をつけて表現するという方法。
みたいな感じね。って、全然メタデータじゃねー！ けど、ふつうのRSSリーダーでタイトル一覧を表示させた場合は、一見ツリー構造っぽく見えてくれるんじゃなかろうか。凝ったXML表現を使うよりも実用性はこっちの方が高いと見た。
2004-12-30 [長年日記]
_ 追跡のバグフィックス (01:51)
trackback追跡のキャッシングで、階層の途中から追跡をやり直したときに、不完全なキャッシュを再利用してしまい、本来たどれるはずの枝をたどり損ねるバグを修正。
あと文言を、「trackbackの追跡」を「議論追跡」、「ここから追跡」を「再追跡」に変更しつつ、「再追跡」は枝の末端だけでなく、すべての枝から実行できるようにリンクを追加した。
2004-12-31 [長年日記]
_ 自前の更新チェックを追加 (15:37)
blogmapは基本的に、他のアンテナ・pingサイトから取得した更新時刻情報を使って、各blogサイトが更新されたかどうかを確認し、更新が確認できたサイトに対してのみ巡回を行っているわけだけど、それだと他のアンテナ・pingサイトから更新情報を取得できなくなってしまった場合に、クローリングできないことになってしまう。それはそれでいいかと思っていたんだけど、やっぱりそういう場合でも更新されているところには巡回した方がいいような気もしてきたんで、自力で更新チェックをしつつ巡回する機能を追加。48時間以上更新が確認できなかったサイトには、自動的に更新チェックを兼ねた巡回を行う。ただ、毎回48時間おきというわけではなく、巡回時に最終更新日をチェックして、最終更新から現在までの更新されていない期間に応じて、更新頻度を調整する。要は、長く更新されていないサイトには、滅多に更新チェックには行かなくなる。ただし、アンテナやpingを通して新しく更新を確認できた場合は、通常の巡回処理対象に戻る。というわけで、なにやらそういう処理が追加されたという報告兼メモでした。
_ 自前更新チェックを始めた関係で (15:45)
古いRSSをばしばし食いまくっているんで、ランキング上位にちょっと古いRSSの内容を反映したデータが出てきちゃっています。自前更新チェックの最初の1周が終わったら、ちゃんと新しい情報のみを使ったランキングに戻ると思いますので。
Before...
_ いしだなおと [・item/@about item/link はblogmapのURI ・item/ag:sourceURL に元記..]
_ ishinao [aggregationって語彙は結構使えそうですね。ただ「item/linkをたどる」1クリックって、たいていのユー..]
_ yoosee [ありがとうございます > content:encoded 埋め込み]