結局だらだらとワールドカップをスカパーで見続けた週末。見事に何もしなかったな。

手軽にアンテナを作成できるサービス「はてなアンテナ」ってのが最近始まったらしい。アンテナってネットワーク負荷が高いんで、全部自前で更新情報を得るってのは結構大変そうな気がするけど、企業としてやる分にはなんとかなるのかな。ユーザー数が増えても安定して動くならば、textmaniaなんていらなくなるかも。これってどのくらいの頻度で更新チェックしてくれるんだろう？

ひとまず自分がtextmaniaでチェックしていた分を、一通りはてなアンテナに登録してみることにしよう。LIRSとかHINAとか一般的な形式で更新情報を出力してくれる機能もあるみたいだし、自前でアンテナを立てていた分だけでもこっちに移行してしまうこともできるな。

* 追記

HEADで更新時刻を返さないサーバーは結構あるから、どうせGETしなければならないことを考えればページのデータ自体を得ることはさほど大きな負担にならない。最近はハードディスクも安くなってきているから、データを保存すること自体も大したことはないんだろう。ページの更新差分を得る処理の負荷が一番きつそうだけど、まあうまく書けば軽く済ませることができるかも。更新情報取得先ページ数は、ほとんどのユーザーでリストが重複するであろうことを考えると、ある程度以上増えないのかもしれない。また、たくさんの人のリストに登録されているページは更新チェック頻度を高く、あまり登録されていないページは更新チェック頻度を少なくすることで、それなりに負荷コントロールもできそうだ。といった感じの読みなのかな。

* 追記

更新チェック頻度はあんまり高くないみたいだな。もしかしたら1日に1回くらいなのかな？　あと、自分でなつみかんとかでアンテナを立てるよりも制約が大きいかもしれない。まあその分メリット（更新差分を取得してくれる）もあるんだけど。あと、本格的に使うんだとしたら、まじめにセットアップしなきゃいけないみたいだな。基本的に全文取得して解析する方針みたいだから、カウンターみたいなものまで変更差分として取得＆更新されたと認識するみたいだ。大量にURLのみ登録してみたんだけど、これをちゃんとしたアンテナとして使うためには、一個一個の設定を考えて変えていかないと。

今日はムスコに5時半に起こされてから眠れなくなってしまい、だらだらと早起きしてしまったので、とてもだるい。WC日本戦があることだし、今日は早く帰ろう。

最近よけいな（といってもときどき必要になる）サービスを常時起動しているせいか、SRX7の動きにメモリ周りが原因っぽいレスポンスの悪さが目立つようになった。負荷が高いなりに動くように設定してあるんだけど、やっぱり開発マシンにするには256Mバイトじゃたりないか。しょうがないからメモリを384Mにしようかなー。既存の追加分128Mを捨てることになるのがむかつくけど。

設定して一日経って一通り更新が反映されてみた感触では、はてなアンテナ結構良さそうかも。完全に移行するんではなく、textmania用の俺系サブアンテナ＆ざっとヘッドラインを見たいとき用として使う感じかな。もうちょっと設定を詰めてから、textmaniaのサブアンテナとしてちゃんと使えるかどうかを試してみよう。textmaniaでは腐った情報でない限りは、いくら重複する情報ソースがあってもかまわないからな。前はCPU負荷の関係で重複する情報ソースを利用するのは好まなかったけど、家サーバーにしてからはCPUパワーにはずいぶん余裕ができたんで、それならばいくつかのアンテナが死んでいても安定して更新情報が取得できるような、多少無駄のある体制の方がいいし。

* 追記

はてなアンテナで作った自分のアンテナのデータを、textmaniaのデータソースとして取り込んでみた。LIRSのlast_modifiedとdetectedが普通とちょっと違っている気がするけど、そのあたりはこっちで対応できるし問題なさそう。あとは、設定の腐っているデータをどれだけきちんと修復できるか、だな。

使い始めた頃はまだphp3だったこのサーバー。二ヶ月くらい前にふと気づいたらphp4にバージョンアップされていて、ラッキーと思っていたんだけど、ただちょっと古いバージョンだったのが気になっていた。が、今日見てみたらいつの間にか最新バージョン（追記：よく見たら全然最新じゃなかった。4.0系から4.1系にあがっていただけ）にあがっていた。良かった良かった。phpは3と4はずいぶん違うけど、4の中でも初期バージョンと4.1以降のバージョンは結構違うからな。最新バージョンにあわせてもらえると、家サーバーとまったく同じコードが動かせるんで楽。Apacheとかもちゃんとバージョンアップされているようだ。使い始めた当初は、いかにも再販業者がノーメンテナンスで運営している（から安い）っぽかったけど、結構ちゃんとメンテナンスするんだね。

URLはできるだけ正確な表記で登録しましょう。たとえばアンテナ系リンク集なんかで、URL末尾に機能的な意味のない更新日時付加情報（?0206061424とか）がついている場合は、それをちゃんと省きましょう。また、URLがディレクトリで終わっている場合は、URL末尾は「/」で閉じておきましょう。あと個人的にはURLの末尾がインデックスファイル（index.htmlとか、ファイル名を省略しても同じ内容が開かれるもの）になっている場合は、それも省く方に統一する方が好みです。ただし、index.htmになっているけど、サーバーでindex.htmがインデックスファイルとして登録されていない場合があるので、要注意。

数字カウンター付きページで、カウンター部の更新を無視したい場合は、更新無視文字列を「\d+」にしておきましょう。あと、tDiary系の「本日のリンク元」を無視したい場合は「\d+\|」にしておきましょう（\d+だけでもいけている気がするが）。それ以上複雑なのは、まあそれなりにがんばってください。

* 追記訂正

上記は嘘です。「更新無視文字列」は、行内に一部でも含まれていれば有効なんで、上記のように設定したら、数値が入っている行はみんな無視されちゃいます。マッチした部分だけ無視するんだと思ってたよ。

●そういえば、はてなアンテナなるサイトがあって
って、アンテナなんですが、なんだか

わしらのリモート元にするにはどうしたらよいのでせうか？

編集画面の一番下にリンクが用意されているはずです。たとえば、ダメあんてな出張所の場合ならば、LIRS、HINA、DIとなります。ただ、LIRSはLast-Modifiedが0固定で、Last-Detectedに最終更新（認識）日時が入っているので、そのデータをそのままなつみかんがリモートアンテナ用として使えるかはわかりません（なつみかんでリモート設定をしたことがないんで）。ほかのフォーマットの出力が正しいかどうかも確認していません。たぶんどれかはそのままでも使えると思いますけど。

textmaniaでは、はてなアンテナからのLIRSのLast-DetectedをLast-Modifiedで読み替えるようにして使っています。

もうずいぶん放置していた2ch type BBSを作ろう計画（コードネーム：Ich）。最近ずっとVB.NETばっかりやっていて脳みそが腐ってきた気がしたんで、ちょっと脳みそのリフレッシュのためにPHPを使ってリハビリすることにした。

Ich関係は頭の中でかなりいろいろこね回し続けていたんだけど、そう簡単に究極的な設計が思い浮かぶとも思えないんで、ひとまず思いつきの中からよさげな部分だけでも、実際に実装してみて、どんな感じになるのかをテストしてみることにした。で、いろいろパーツ的なものを作っているんだけど、プログラミング以外のところで一番悩みが深いのが、カテゴリ分類のこと。

2chなんかは長く続けているだけあって、かなりいい感じのカテゴリ（板）分類を持っているんだけど、ああいうフラットなやり方ではかなり制約が大きい。そこで、2chのようにカテゴリにスレッドが所属するという仕組みは捨て、スレッドは独立してフラットに存在しつつ、複雑な構造を持つカテゴリがスレッドへのポインタだけを持つ、という形式を考えてみた。

カテゴリは、それに所属するスレッドへのポインタ（ユニークID）のリストを持っている。複数のカテゴリが同じスレッドへのポインタを共有していてもかまわない。というか、共有しているのが前提。そうすることで、複数のカテゴリに所属するスレッドというものが表現できるようになり、自由度が大幅に高まる。

という前提の元に、カテゴリの構造を考えてみる。実装サンプルを別ウィンドウで参照しながら読むと、ちょっとは説明がわかりやすくなるかも。

カテゴリは、基本的に親子関係を持つツリー構造で表現される。ツリーのすべてのノードが、カテゴリとしての意味を持つ。子カテゴリに所属したスレッドは、自動的にすべての親カテゴリにも所属することになる。

ツリーで表現されるカテゴリは、できるだけプリミティブな意味を持つ厳選されたものだけにする必要がある。似たような意味を持つ違ったツリーが乱立しては、分類の意味がなくなってしまうだろう。ただし、ものごとをカテゴリ分類していくと、カテゴリ自体が複数のカテゴリに所属するようなものが出てくる。スレッドを複数のカテゴリに所属させるだけでは、そのあたりは表現しにくい。そういうものにも対応する必要がある。

そこで、カテゴリにリンク情報を持たせられるようにする。これはそのカテゴリに所属するスレッドは、リンクされた別のカテゴリにも自動的に所属することとなる、という意味を表すものだ。サンプルでは、各カテゴリの下に一段頭を下げて書かれている行が、リンクカテゴリとなる。たとえば、「/Computer/Hardware/PC本体/AT互換機/メーカーPC/VAIO」カテゴリは、「/組織/企業/ソニー」カテゴリへのリンク情報を持っているので、前者のカテゴリに所属するスレッドは自動的に後者のカテゴリにも所属することになる。今のところは、リンク先のさらにリンク先までは見ないことにする（懸案事項）。

といった感じでカテゴリというものを表現すれば、かなり柔軟にスレッドを表現できるのではないだろうか。ちなみにサンプルではテストのためにかなり細かい部分までカテゴリを用意してみたが、実際には最初の内は2階層程度まで用意しておき、それより深い部分についてはカテゴリわけする意味がでたら（＝そのカテゴリに人気が出たら）、さらに子階層で細分化していく、といった感じの運用になるだろう。

ひとまずざっとやってみた思考実験では、これでかなりうまくいきそうなんだけど、一番問題なのは「ツリーで表現されるカテゴリは、できるだけプリミティブな意味を持つ厳選されたものだけにする必要がある」という部分。いろいろ考えてみた結果が、現在テスト実装に載せているような感じのものなんだけど、こういう方向でいいんだろうか？　ツリーの作り方が間違っていたからといってルートから造り直すようなことになると、それまでのカテゴリ情報は破棄しなければならなくなるからな。

かといって、あんまり理想論的にツリーを作ってしまうと、意味なく複雑な（深い）ツリーになってしまって利便性が失われる。現実的に有用な（意味のある）レベルのルートから始めつつも、プリミティブ性は確保するという方針で作ってみているんだけど、結局こういうカテゴリってなものは、それで“森羅万象を表現できる”みたいな高度すぎる理想を持っているため、いくら思考実験してみても納得いくということがない。難しい。

ちなみに、こういう風にカテゴリ−ツリーデータを持たせると、カテゴリ内のスレッド一覧とかヘッドラインとかを生成する負荷がかなり高くなるんだけど、一応運用上は現実的な負荷（個人レベルのサーバー資産で）で収まる設計は思いついたんで、単なる理想論ってだけでなく実装も可能だと思う。ただ、基本的にPHP（Perlでもいいけど）＋テキストファイルで完結して動くように設計していたんだけど、カテゴリ→スレッド方向のデータ連携はやっぱりDBに持たせないときつそうなんで、そこだけDBに（も）持たせる方針。なくても動くけれども、そうすると総カテゴリ数はかなり少なめにしておかないと、まともに（速度的に）動かなくなりそうだ。

最低限の機能を実装したIch（仮）のプロトタイプが動き始めたので、お暇な方テストしてください。ひとまず家サーバーで動かしています。