いつものようにつけっぱなしのカートゥーンネットワークで、パワーパフガールズが流れていた。キャッチフレーズは、「強くてかわいい生理の味方」。血が垂れそうになったら下で押さえてくれるんでしょうか？　って、「強くてかわいい正義の味方」ですね……。

インスタントメッセージ系のソフトが携帯に載るといいなーとは前から思っていたんだけど、こういう形だったら載せる必要はない。っつーか、こんなのインスタントメッセージじゃないじゃん。単なるwebチャットじゃん。自分からメッセージをチェックしに行かなきゃ受信できないようなものを、メッセンジャーって名前にするんじゃねーよ。

以前は白黒だった映画に人工的に色をつけたりする行為ほど悪質ではないとヘンダーショット社長は主張している。

そういや一昔前、モノクロ映画に色を付けてカラーにするのって流行ったよね。ヒッチコックものとか、やたらとカラー化してテレビ放映していた気がする。でももう最近はああいうのはさっぱり見かけなくなったな。って、この記事の本筋とは関係ない話だけど。

これで三日坊主の大役は果たしたな（←日本語の使い方がヘンデスとグレテル）。

2ch type bbs（開発コードich）に搭載する負荷分散周りの仕組みを考えてみた。まあ実際に使うことはないだろうけど、思考実験としては面白いんで。

• クライアントからのDATファイル直読みはできない。またhtmlファイル直読みもできない。必ずcgi（phpを使うつもりだけど）を経由させ、アクセスコントロールできるようにする。
• HEADリクエストによって、Last-Modified情報をはじめ、現在のレス数などの比較的詳しい情報を取得できるようにしておく。
• HEADリクエストで得た情報を元に、DATファイル（もちろん実際のデータ形式は2chとは異なる）レベルでのデータ差分取得に対応させる（後述するキャッシュサーバー用CGIからのみ）。
• ある程度転送量が多い板については、cgiへの読み込み系GETリクエストが来た段階で、アクセスを負荷分散用キャッシュサーバーに転送する（書き込み、検索などは本サーバー側で直接受け取る）。
  • 負荷分散用キャッシュサーバーが指定された板のデータは、クライアントから本サーバーに直接読みに行くことはできない（本サーバーのcgiはリダイレクトするだけになる）。
  • 負荷分散用キャッシュサーバーのみ、直接本サーバーにアクセス（HEADリクエスト）し、必要な場合はDATファイルレベルでの差分情報を取りに行く。
  • 本サーバーから得た各スレッドの情報は、キャッシュサーバー上にDATファイルとして保存しておき、基本的にはその情報を元に整形した結果をクライアントに返す。
  • キャッシュサーバーから本サーバーへのアクセス頻度（最低アクセス間隔）を適宜設定することで、本サーバーの負荷・転送量を調整することができる。
• gzip圧縮に対応したブラウザに対しては、できるだけgzip圧縮されたデータを返す
  • 要求があるたびに毎回gzip圧縮を行っていたのでは、負荷コストがバカにならないので、読み込み・書き込みのタイミングではgzip圧縮しない。
  • cronで定期的にスレッドの状態を監視し、一定期間以上書き込みがなかったスレッドは、HTML化（HTMLキャッシュがなかった場合）＋それをgzip圧縮したデータの二つを用意する。
  • スレッドへの読み込みリクエストが来た場合、すでにHTML化されたデータがあった場合は、それをそのまま返す。gzip圧縮対応ブラウザからのリクエストだった場合は、gzip圧縮されたデータを返す。HTML化されたデータがなければ、その場でHTML化してキャッシュとして保存しつつ、クライアントに返す。
  • 新規書き込みがあった場合、HTMLキャッシュファイルとそれをgzip圧縮したデータは削除する。

って感じにすることで、ずいぶんと負荷低減＆分散ができるような気がする。どうせ負荷のほとんどは読み込み周りなんだろうから、読み込み用の専用キャッシュサーバーと連携できるような仕組みさえあれば、それでだいたい対処できるんじゃないかな。

ただ、まだ検索周りについては、自分の頭の中でうまく負荷分散と利便性のバランスを保った解決策が思いついていないんだよな。Namazuのインデックス作りは結構負荷がでかいんで、そのあたりをどうするのがいいか。

とか考えていると、どんどん構想だけがでかくなっていって、実際に作り始めることができなくなっちゃいそうだな。まあそれはそれで趣味的には楽しいんだけど。良くできた仕様を思いつけたらそれだけで十分と言えなくもない。実証テストの楽しさというのももちろんあるんだけど、このくらいでかいシステムになっちゃうと（労力対楽しさの）コストパフォーマンスが割に合わなくなっちゃうからな。

あーもう、二度とhdmlの仕事なんてやらねーぞ。規格としての余命は短いくせになんでこんなにめんどうくせーんだ。いや、こんなにめんどうくせーからこそ、規格としての余命が短くなったのか。二度と使う機会がなさそうなtipsがどんどんたまっていくよ。

この間なくしたMGメモリスティック64Mの代わりに、128Mを買ってきた。買うかどうか迷いながらビックカメラに行ったら、16000円というばかげた値段を付けていたので、げげげっと思いながらT-Zoneに行ったら12800円だったんで、なんだ結構安いじゃんと勢い余って購入。しまったはめられたか！（←誰に？）　今度はなくさないようにしないと。

textmania2の方で移転告知を出してきた。まあこっちも俺がテストしている限りでは一通り動いているっぽいし。mylist移動用スクリプトも一応書いておいたけど、ちゃんと動くかどうかは未テスト（←おい）。まあだいたい動くだろう。

あと、こっちのサーバーで取得している更新情報のうち、どう考えても表示用ではないURL（更新情報取得用URL）が流れてきているものに関して、非表示にしてみた。具体的には拡張子が.datなものと、ファイル名部分がdi.cgiなもの。

買ってきたMGMS128（ってわかりにくい省略形だな。マジックゲートメモリスティック128メガバイト）に早速ATRAC3なデータを転送してC404Sで聞こうと思い、SRX7のSonicStageで120Mバイト分のデータをチェックイン。転送が終わったんでアクセスが完全に終了していることを確認してからメモリスティックを引っこ抜いたら、Windows XPが一発で落ちた。落ちたばかりか、再起動時にSONYロゴが出るところまでで起動プロセスが止まってしまった。

うげー、SRX7を使い始めてからこんな風に致命的な感じでOSが落ちたのって、VirtualCDをインストールしたとき以来だよ（VirtualCDは、Windows XP対応となっているくせに、俺の環境でWindows XP用セットアップ手順に忠実にセットアップしても、100％OSを落とすようにしかセットアップされなかった。まあもうあれを使うことはほとんどないんで、どうでもいいけど）。これからはちゃんとメモリスティックを終了させてから抜かないとダメなのか？

またアロウズはそういうことをやるとですか。まあ正式発表があるまでは本当かどうかわからないけど、追い出されるフェルスタッペンの公式サイトでそう書かれていたんだったら、本当である可能性は十分に高そうだ。去年のデ・ラ・ロサといい、今年のフェルスタッペンといい、ほかのシートがなくなってから馘首にされたんじゃなければ、ほかのシートを見つけるだけの実力はあるのに。