電話番号を構成する三つのパートがあるじゃないですか。aa-bbbb-ccccみたいな感じで。このabcそれぞれを表す名称ってあるんでしょうかね？　aaは市外局番って表現でだいたい理解してもらえるかなと思うんですが（携帯とかだとちょっと違っちゃうけど）、2番目と3番目のことをなんて表現すればいいのかわからない。くそー、やっぱりWAPむかつく。

「直感的なインターフェース」と言われると、超感覚的知覚を駆使しなければ使えないような気がしてしまう。サイコミュシステム？

ひとまず二日目。平日一週間続いて、さらに週末を乗り越えると、ずいぶん習慣化すると思うんだけど。

昨日発見したロッテ浦和球場そばのディスカウントストアが開いていたので、中をのぞいてみた。まあごく普通のディスカウントストアだった。同系統で巨大なロヂャースが近所にあるけれども、あっちはいつも駐車場がゲロ混みなんで、手軽に買い物に行けるのはこっちかな。うちで消費量が多いジンジャーエールが200円だたよ＞オクサン。

やっぱり、「最近コメントがついた記事リスト」も表示できるようにした方がいいな。現状のデータ構造では、いちいちすべてのbbsデータをさらわないとリストが得られないから、新たに別ファイルとしてbbsの新規書き込みを管理する方式にした方がいいだろう。なんて機能拡張を続けていたら、いつまで経っても書き直しが終わらない。本家hnsbbsのPerl版の開発がすでにずいぶんと進んでいるみたいだから、まあいいか。

「浜崎発言に関するコメント」が釈明コメント本体の方。でもこれを読んだところで、噂で流れている説と釈明コメントの説のどちらが正しいかなんて、なんとも言えないよなー。少なくとも「前の方座らないでくださ〜い。ねっ、どう思う。座ってたよ、今、一番前で見てんのにさぁ座ってたよ。感じ悪いね〜（笑）」と言ったことは事実だとavexも認めているんだね（まあビデオ見ればわかることだから否定しても意味ないけど）、ってことを確認できたくらいか。

っつーか、噂の方の説である「たまたま足の不自由な子がいて座っていただけで、言われた子は泣き出して大変だった」ってのは嘘くさすぎて信じないけど、どちらにしろ「前の方座らないでくださ〜い。ねっ、どう思う。座ってたよ、今、一番前で見てんのにさぁ座ってたよ。感じ悪いね〜（笑）」なんて発言をするやつは、ある程度いやなやつだと思われて非難されても仕方がないんじゃん。

どういう立場の人がどういうルートでその席に座る権利を得たのかはわからないけど、少なくとも浜崎あゆみはその人を立って見る気にさせれなかったことは事実でしょう（本当にそのとき体調が悪かったのかもしれないし）。だからって、「前の方座らないでくださ〜い。ねっ、どう思う。座ってたよ、今、一番前で見てんのにさぁ座ってたよ。感じ悪いね〜（笑）」と口撃する方が、よほど感じ悪い。

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

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円だったんで、なんだ結構安いじゃんと勢い余って購入。しまったはめられたか！（←誰に？）　今度はなくさないようにしないと。