2003-12-02 [長年日記]
_ BkASPilからPOPFileに移行した (13:51)
スパムフィルターとして、BkASPil for Becky!2（http://b2antispam.s33.xrea.com/）をしばらく使っていたんだけど、仕事で頻繁にWindowsを落として（ブルースクリーン）いたら、そのたびに確実にBecky!が起動しなくなる原因がBkASPilにある（データファイルが一度壊れると致命的エラーになって起動しないっぽい）ことに気付き、しょうがないんでほかのスパムフィルターに移行することにした。で、ちょうどそこここで話題になっていたPOPFile（http://popfile.sourceforge.net/）を使ってみることにした。
ちなみにBkASPilは、インターネット上に公開されているスパムの送信元アドレスのブラックリストを使ってスパムを判別しつつ、またユーザー宛に来たスパムを簡単にブラックリストに登録することが出来る機能を用意することで、ブラックリストの鮮度を保つ仕組みになっている。結構大きなDBにネットワーク越しにアクセスするせいか、起動が重いという欠点があったけれども、スパム判別性能は結構良かった。特に海外スパム系の判別に強い。反面、国内スパムの判別にはちょっと弱いかも。
で、POPFileの方はスパムフィルターとしてはもはや定番になりつつある、ベイジアン理論を使ったソフト。ベイジアン理論ってのは、過去の統計から未来を予測するという、至極まっとうな理屈をコンピュータ上に載っけるための理論、だったはず（うろ覚え＆確認なし）。
スパムフィルターなんかで使う場合は、メールのカテゴライズ（簡単にはスパムかスパムでないか）を人手によって行いつつ、そのメール中にどういう単語が含まれていたかを蓄積学習していき、その蓄積された情報を使って、新しいメールに含まれる単語情報から、そのメールがどのようにカテゴライズされるべきかを推測する、といった感じで使われる。
って仕組みなんで、別にスパムを判別するためだけにしか使えないわけではない。「文章中に含まれる単語（文章の構成要素）から、その文章をカテゴライズする」ことが可能なんで、汎用的なメール分類のためにも使える。というか、私の場合はPOPFileをスパムフィルターというよりは、スパムも判別してくれるメール分類ツールとして使っている。POPFileを使い始めてからは、今までBecky!のフィルタリングマネージャでいろいろ分類していたのをすっぱりやめて、すべてPOPFileに分類してもらうようにしてしまった（POPFileで分類された結果を、さらにフィルタリングマネージャで分類したりはしているけど）。
POPFileのインストールは、インストールマニュアル（http://popfile.sourceforge.net/manual/jp/manual.html）が充実しているんで、言うとおりに作業するだけで簡単に使えるだろう。ただ、結構仕組みはややこしいんで、使いこなすにはそれなりの知識が必要かも。
POPFileは、POP（メール受信プロトコル）のプロキシーサーバーとして自分のPC上で動作し、メールクライアントはまずPOPFileにアクセスし、POPFileが実際のメールサーバーにアクセスしてメールを取得し、妥当なフィルタリング（＝加工）を行ってから、メールクライアントにメールを渡す、といった動作をするようになる。だから、メールクライアントの種類は選ばない。ただ、POPFile側の設定とメールクライアント側の設定の両方が必要。POPFileの設定はWebブラウザで出来るようになっている。単に動かすだけならばマニュアル通りにやればいいけど、理解して設定するにはそれなりの知識が必要だろう。
ちなみにベイジアンフィルターの説明のところで書いたように、この仕組みでは基本的に「まずユーザーがメールを手動で判別し、それによって学習した成果を利用して、新しいメールを自動的に分類する」ということになるんで、使い始めてしばらくの間は積極的にユーザーが判別情報を学習させる必要がある。作業としては、Webブラウザにメールのタイトル一覧が表示されるんで、それぞれのメールの種別をドロップダウンリストから選択していけばいい。
学習データが出来ると、POPFileはそれを元に自動判別を試みるようになる。けれど、最初のうちは情報が少ないんで結構間違える。間違っているものは正しい判別に修正して学習させると、次からは判別の精度が上がる。それを繰り返していくうちに、ほぼ自動的に正しい判別をしてくれるようになっていく。
POPFileでは、判別の種類は自由に設定できる。一番簡単な種類の設定としては、「スパム」「スパム以外」だろうけど、せっかく「あいまいっぽい」判別を行ってくれる仕組みがあるんだから、自分で便利なようにいろいろ種類を設定してしまったほうが楽しい。ポイントとしては、
- 文字列一致などで確実に判別できるものは、POPFileで判別させる必要がない（メーラーの標準機能で判別できるだろう）
- 単語要素があまりにも似通っていそうな分類は、POPFileは不得意そうなので、実用的にならないかも（やってみたら結構いけるかもしれないけど）
- 学習によって精度を高めていく仕組みなんで、後から判別種類を大幅に変えてしまったりしたら、学習のやり直しになってしまう。ある程度長いスパンで使えるような分類にした方がいいかも
- ベイジアンフィルターは結構負荷が高い処理らしいんで、あんまり無茶な数の分類にはしない方がいい（でも10個くらいなら平気そうだ）
ちなみに私は、「business」「personal」+[「admin」]+「commercial」「ml」「spam」「virus」+[「other」]+という分類で使ってみている。対象のメールアカウントは、私用・仕事あわせた全てのアカウント5個分。この分け方を使っていてうれしいのは、スパムとウイルスを判別してくれることと、正規の広告系メールをうまく分類してくれること。あと、仕事アドレスに来た私用メールとか、私用アドレスに来た仕事メールを分類してくれることも。このあたりが、通常の文字列一致系分類ではうまくいかなかったところ。
ただ残念なのは、POPFileは現時点ではAPOPには対応していないことか。せっかくうちのサーバーをAPOPサーバーにしたのにな。
2003-12-04 [長年日記]
_ AH-N401Cのアンテナが折れた (13:51)
2004/1/14
ああそういえば書き忘れていた。可動アンテナが折れた場合、根本の根本から完全に外してしまわないと、内蔵アンテナに切り替わってくれないので感度が悪くなる。しばらく気付かずに可動アンテナの根っこだけつけて使っていたところ、ものすごく感度が悪かったんだけど、それを引っこ抜いたら感度がまともになった。可動アンテナのもろさを考えると、普段は外して使っていて、どうしてもつけた方がいいときだけつけてみる、ってくらいの使い方の方がいいのかも。
2003/12/4
CF AirH"端末のAH-N401Cを使っているんだけど、これの可動アンテナって結構もろい。
今までも何度か外れてなくなりかけては、なんとか見つけてはめ直していたんだけど、2週間くらい前についになくしてしまった。でもまあ付け根の部分が残っていたんで、そこにほどよそうな長さの皮膜針金を結びつけてしばらく使っていた。ら、今度はその針金ごと付け根の部分もなくなってしまった。
補修部品で取り寄せたら3000円くらいするらしい。この壊れやすさで3000円はちょっときついかなー。
とか思いつつ、カタログページ（http://www.necinfrontia.co.jp/products/cf/ah_n401c.htm）を見ていたら、この可動アンテナって基本的には感度を上げるための補助アンテナって位置づけなんだね。可動アンテナがなくなっても、一応内蔵アンテナで使える（というか、そういう使い方も公式）みたいだ。
結構感度が落ちてはいるんだけど、でも日常使いではそれほど不便でもない（見た目の感度は落ちている（LEDの色が頻繁に赤になる）んだけど、それなりに通信は出来ている）んで、ひとまずこのまま使い続けよう。
_ VAIOノートZ1を買うかどうか (13:51)
最近仕事で私物ノートPCをメインにずっと使っていて（持ち歩く必要あり＆PCカードスロット必須）、しかもその仕事が少なくともあと3ヶ月は続くことになっているんで、会社でノートPCを買ってもいいということになった。
けれども、ノートPCを2台持ち歩く気にはなれないんで、どうせ買うならば現在使っているSRX7の替わりに、普段私用でも使いつつ、会社ではメインマシンとして使えるようなものを買おうかと考えた。
が、結構選択が難しい。というのは、現在のSRX7（Pentium3-800MHz）＋大容量バッテリ＋RAM 384M＋専用マルチドライブには特に不満がないから、日常使いもするとなると、現在の環境よりも落ちるようなものならば欲しくないし、環境移行の手間を考えたらかなり上回るくらいのスペックは欲しい。
で、ひとまず現在候補として残っているのはVAIOノートZ1（PCG-Z1V/P）を1GバイトRAMに増設したパターン。これならば、多少大きく重くはなる（俺の場合はSRX7＋大容量バッテリなんで、もともと2kgくらいある）点を除いては、スペック的に見劣りする部分はなさそうだし、画面が大きくなる（1400×1050）という利点は移行の手間分くらいカバーできそうだ。でも会社ノートとしてVAIOノートZ1ってのは今一歩踏み切れないところがある。
ThinkPadの高解像度モバイルPCがもうちょっと安ければいいんだけど、今どきプログラム開発系仕事マシンに40万円超のものなんて買えない（っつーか予算的に通らない）だろうしなー。DellのBTOノート（500mベースの奴）もそこそこではあるんだけど、重さとバッテリの持ちがいまいちなんだよなー。
XGAマシンで納得がいくものが見あたればもうちょっと選択肢が増えるんだけど、現在のSRX7を総合的に上回るものが見あたらない（持ち歩ける（家でも会社でも使う）メインマシンとしてのノートPCとして）。このままいくとVAIOノートZ1にいってしまいそうだけど、微妙に後悔しそうな気もする。一応会社マシンだから、個人データの管理も面倒くさくなるだろうしなー。
飯を食いがてら、VAIOノートZ1を見てきたんだけど、思ったよりもでかくて重いなー。これを常時持ち歩くのは結構つらいかも。これだったら、ThinkPadの小さい奴をコアとして買って、会社ではそれをドックとかで増設して使う、なんて方がいいかもなー。うーん。
ThinkPad T41って、今IBMのオンラインショップで買うと割引が効いて、結構安くなるんだな。VAIOノートZ1と値段が大して変わらないならば、こっちの方がいいかなー。メモリも2Gまで積めるし。ただこっちもA4 2kgを持ち歩くことが出来るかどうかが微妙だ。
2003-12-07 [長年日記]
_ 2003年最終戦 (13:50)
土曜日は草野球の今期最終戦。
雨っぽい雰囲気だったんで多分ダメだと思っていたら、何とか天気がもってしまい（←いかにもやる気がない）、しょうがないんで根性出して（休日にしては）早く起きて、電車で二子玉川へ。すべてとりまとめていた監督が、朝っぱらから意味不明の病気（？）でダウンして連絡が取れなくなってしまいつつも、何とか現地で集合し、二人ばかり人数が足りなかったのを相手チームから借りて試合開始。
ここ二ヶ月くらいはばたばたしていて、運動どころか日常生活すらいっぱいいっぱいだったんで、俺的には目立たない面子としてそっとすごそうと思っていたんだけど、何せ面子が足りない状態だったんでそういうわけにもいかない。出だしから三塁を守ってぽろぽろとエラーしたり悪送球したりしつつ、大量に点を取られる。が、相手もなかなかいい感じでダメだったので、こっちも点を取り返し、泥仕合っぽい試合展開で中盤へ。
んでもって、途中からうちのチームの次期エース候補にピッチャーが代わった（ついでに俺はキャッチャーに代わった）ところ、なかなかいいピッチングを見せてくれた。もともと球自体は悪くないんだけど、投手経験がないんで実戦で結果が出ない感じだったのが、ようやくマウンド慣れしてくれたか。まだ若くて体力があるんで、安定してくれると投手力の計算がとても楽になる。ついでに俺もずいぶんキャッチャーに慣れたな。フライは捕れないけど、ファールチップとかショートバウンドのキャッチングがずいぶん良くなった気がする。
で、後半比較的締まった試合になりつつも、じわじわ追い上げる展開になっていたんだけど、相手チームも球の速いピッチャーに代わってしまい、こちらの勢いもかなり減衰。それでも一応食い下がったんだけど、最終回裏に3点差まで追いついたところで終了。14対11だったかな。
7回まで終わってもまだグラウンドの方の時間が40分ほど残っていたんで、しきり直してもう一試合。今度は先発。全然投げていなかったけれども、相変わらずストレートは使えるな。1回は三者凡退。俺もコントロールが良くなったもんだ。高校の頃なんて、ストライクゾーンに入れることすらままならなかったのに。ただ、さすがに練習不足のせいで遅い球のコントロールがぼろぼろ。カーブの握りで曲げずに抜くだけの球なんだけど、手離れがコントロールできずに調整しても全然思ったところにいかない。というのではまって2回に3失点。
そこで時間が尽きたんで、その回で最終回ということになり、残すはうちのチームの2回裏の攻撃。1点差を追う展開で2アウトから連打が出て1点を返して同点に追いつき、さらに走者2、3塁という状態。そこで、1塁後方へのフライがヒットになってさよなら。一応最終戦は勝利を収めた（ような気がする）ってことで。
2003-12-09 [長年日記]
_ Re: 同好の士だけが見てくれるWebサイト from ただのにっき (13:51)
- Re: 同好の士だけが見てくれるWebサイト - http://sho.tdiary.net/20031208.html#p03
>>最初のアクセスでセッションIDを発行して、クッキーに保存。そのIDのアクセス数(のようなもの。ポイントみたいな数値)をサーバに保存しておく。で、ポイントがある程度たまった人にだけ、新しい記事や人気のある記事を読ませてあげたり、インタラクティブなコンテンツへのアクセスを許可する。知合いにはあらかじめ、多めにポイントをあげてもいいだろう。
これって、HNSがやっているRURIコード（ランダムCookie）を使ったアクセス制限を、もっとユーザーが細かくコントロールできるようにしようって感じだよな。というか、俺がIch（仮）とかWikiLikeとかでずっとやろうとしていた「ユーザーを匿名のままに認証する」仕組みの利用方法の一つだ。
俺がこの技術をなんとかものにしようと努力している裏には、「ユーザー登録（＝管理）なしで気軽に実現できるアクセス権限の制御を、一般のWebサイトに適用できるようにする」という目的がある。
昔この手の話題（儀礼的無関心）が流行ったときに、今回と同じような（技術論と慣習（儀礼）論の対立っぽい）展開になっていったのを見て、「技術的な問題は技術で解決できるだろう」と思って、その実現方法を考えてみたのがこのアプローチ（その頃のログがどこかにあるはずだけど、探すのが面倒）。
ただこのアプローチって、認証するところは簡単なんだけど、その設定回りが難しい。具体的には、「（技術的な知識のない）ユーザーが自由にアクセス制限を設定できるユーザーインターフェース（＝制御の仕組み）」を考えるのが非常に難しい。特にCookieの挙動なんてのは一般ユーザーに理解してもらうのが結構面倒だし。
その辺りを何とかするために、
- ユーザーID（＋パスワード）を使った権限管理
- トリップ（ユーザーが入力する公開パスワードハッシュ）を使った権限管理
- ランダムCookieによる権限管理
- 権限を伴わないCookieによるユーザーインターフェースの制御
をうまく連携させることによって、使いやすい仕組みを作れないかなーといろいろ試している（ここでも使っている）んだけど、なかなかいいバランスが見つからない。しかも最近そういうネタで遊んでいる時間が取れないし。
たださん案の「ポイント制度」を使った管理ってのは考えたことがなかった（けれども、よく考えたら一昔前に女子小中高生の間で流行ったステップアップ機能付き掲示板なんかで、似たような考え方はすでに採用されていたか。あれってユーザーをどうやって特定していたのかな？）んで、それとの連携も考えてみよう。こういう正面から攻める（ID→権限）のではなく、搦め手から攻める（ID→ポイント（数値）→権限）アプローチって、いったん嵌ると全然思いつけなくなっちゃうんだよな。
と書いたところで今日も時間切れ。
2003-12-10 [長年日記]
_ Suicaが壊れた (13:51)
「ソニーとドコモ合弁会社〜FeliCaを携帯に from ZDNet」で書いたように、壊れかけのまま使っていたSuicaがついに壊れた。今朝はふつうに使えていたんだけど、帰りに使おうとしたら自動改札がエラーを返す。駅員に渡したら、「ICが壊れているんで、最寄り駅で交換してもらって」とのこと。で、最寄り駅についてもう一度自動改札で試してみたら、今度はまったく反応しなくなっていた。駅員にその旨を伝えたところ、簡単な書類を書かされ、「翌日朝6時には渡せる」と、引換券みたいなものと壊れたSuicaを返された。特に身分証とかはいらないらしい。引き渡しの時にはいるのかな？ 以下次号（明日）。
というわけで、新しいSuicaを受け取ってきましたよ。引換券は改札脇の窓口でもらったんだけど、引き替え自体はふつうの緑の窓口（っていうんだっけ？ 切符とか定期とかを売っている窓口）の方で。引換券と壊れたSuicaを渡したところ、端末に16桁くらいのコードを打ち込んだら再発行されていた。申し込んでから1日必要だってのは、券の発行処理自体ではなく、その事前承認処理みたいなのに必要なのかな？ ひとまず定期券としては使えたけど、チャージしていた金額がちゃんと入っているかは未確認。今日帰りに忘れていなかったら確認しておこう。
_ TrackBackスパム対策にFOAFで認証 (13:51)
フレンドスターネタのコメント欄（http://mylog.ishinao.net/id/684#c613）で思いついたネタをもうちょっとふくらませてまとめておく。
個人Webサイトは必ずFOAFデータを用意する。FOAFデータには必ずfoaf:homepage要素を用意し、人をWebサイトURLを使って特定できるようにする。また、サイト上の任意のURLから必ずそのサイトオーナーのFOAFデータのURLを解決できるような、何らかの仕組みを用意しておく（ヘッダにFOAF URLを埋め込むとか）。
TrackBack受信制限として、
FOAFDepth = 3
などのように記述する。
TrackBackを受信したら、そのURL要素からそのサイトオーナーのFOAFを解決する。続いて、自サイトのFOAFのfoaf:knows、rdfs:seeAlsoを使って、知り合いのFOAFをたどっていく。これによって、自分から始まって3階層以内のFOAF情報に、TrackBack送信元サイトオーナーが存在するかどうかを確認する。指定階層以内にFOAF情報が見つからないサイトからのTrackBackは、無条件で弾くなり別途承認処理が必要にするなり、まあ適当に。
という仕組みを、無断リンクの制御なんかに使ってもいい。Referer URLからFOAFを解決して、n階層以内のFOAF情報にReferer URLのサイトオーナーが見つからなかったら、HTTP 403にしちゃうとか。
＃ああそういえば、最近blogmapのランキングによくtDiaryのリンク元経由RefererスパムURLが現れるんだよなー。あれって結構手動で弾くのが面倒だ。
って、相変わらず「重装備（http://sho.tdiary.net/20031209.html#p03）」な方向のネタばかり考えてしまうのでした。
2003-12-11 [長年日記]
_ 光と影の誘惑 (13:51)
まあ良くできたミステリー短編（中編？）集。貫井徳郎らしい話だったけど、一つ間違えるとワンパターンに堕しかねないくらい、貫井徳郎っぽいネタ。「多分貫井徳郎だったら、この設定ならばこのオチに違いない」という予想がすごく当たった。
2003-12-16 [長年日記]
_ 迷宮遡行 (13:50)
貫井徳郎らしい深みがあんまりなく、火曜サスペンス劇場的な、比較的薄いドラマチックな謎を追って動き続ける感じのストーリー。面白くなかったわけではないけれど、なんか俺の求める貫井徳郎とはちょっと違った。
_ Wiki Way (13:50)
ウェブログ・ハンドブックの感想を書く前に、Wiki Wayの感想を今は亡きIPWiki（IdeaProcessorWiki）のログ（DBアーカイブの生データしか残ってないよ）からサルベージしておこう。
「Wiki way―コラボレーションツールWiki」を買ってきたんで、それを読みつつIPWikiを作る際に参考になりそうな部分をメモしていく。
ブランクページへのリンクを明示する
今のところ、ブランクページへのリンク（まだ存在しないページを[[]]で囲った場合）と存在するページへのリンクは、特に表示上見分けられなくてもいいかな（リンクをクリックした後に解釈する）と思っていた。
けれど、Wiki的なコンテンツ増加アプローチにおいては、ブランクページへのリンクを明示することは重要らしい。ブランクページへのリンクを明示するというのは、そのページは今後（誰かが）記述すべきコンテンツであるということを閲覧者に意識させ、できる限りブランクページをなくさせようとする力となる。
という利点は納得できるものなので、やっぱりブランクページへのリンクはきちんと明示するようにしよう。
検索機能が重要
Wikiにおいては、思ったよりも検索機能が重要なようだ。ページがフラットに管理されていて、目次的な要素がさほど強力でない部分を、すべて検索機能で解決するというアプローチを取っているらしい。 具体的にどういう検索機能でどういう機能を実現しているのかは、もうちょっと読み進めてからまとめてみる。
逆リンク検索
検索機能の一つとして、逆リンク検索がある。あるページにリンクしているページを探すための機能だ。これはWikiシステムにおける重要な検索機能となる。
ある話題に関して検索したい人は、その検索キーワードがタイトルに含まれるページをまず検索する。それによって、その情報への一次情報（である可能性が高い）ページを見つけることができる。さらに、そのページへの逆リンクページを検索することによって、その情報への二次情報（である可能性が高い）ページを見つけることができる。
つまり、このような仕組みによって、コンテンツの全文検索を使わなくても、シンプルで高速なタイトル検索だけで、ある話題に関する主要なページを一通り検索することができるわけだ。Wikiにおいては、「ページ名＝検索キーワード」となるのが自然であることを利用した仕組みだと言えるだろう。
と、逆リンク機能の効用について、勝手に先読みして理解してみたんだけど、オリジナルのWikiでは逆リンクを検索するために、フルテキスト検索をしているみたいだなー。まあ英語だからフルテキスト検索もさほど負荷が高くないし、そういうことになっているのかな。
日本語においてはフルテキスト検索の負荷は高くなりがちだし、上記のような観点から逆リンク検索（ページ間のリンク検索）を充実させる（逆リンク用のインデックスを用意して、検索負荷を軽くする）というのはありかもしれない。
ちなみに、オリジナルWikiでは逆リンク検索機能を通常のリンク表現で記述していたところ、検索エンジンのロボットが検索機能を一通りクローリングしていくため、サーバー負荷が大きくなってしまうという弊害が生じたそうな。で、現在は逆リンク検索機能はわざわざSubmitボタンで表現して検索ロボット対策しているんだとか。
署名を逆リンク検索
署名ページで逆リンク検索を行うと、その人が書いたページが出てくるってのは、なかなか有用な機能だなー。でもIPWikiにおいては署名欄はページ外にあるんで、別インターフェースで管理することになっちゃいそうだ。
日本語対応の検索機能
日本語版において充実した検索機能を実現するためには、何らかの検索インデックスを作成する必要があるだろう。
少なくともページの逆リンク検索などは、フルテキスト検索ではなく、あらかじめ用意した検索インデックスに対して行うように変更した方がいい。ただしそのような検索インデックスを用意することによって、Wikiの手軽さ（ポータビリティ）はある程度失われるだろう。
あるいはNamazuなどのような、外部の日本語全文検索エンジンと連携することも、考える必要があるかもしれない。
キーワード検索の実装例
単純に「あるキーワードが使われているページ」を検索するだけでなく、
- 「あるキーワードが使われているページ」＋「そのページからリンクを張られているページ」＋「そのページにリンクを張っているページ」
まで一気に検索してしまい、そこに（重複して）現れたページを重複数をキーにソートして検索結果として出力することで、
- 「あるキーワードと深い関係がある（けれども、直接そのキーワードは使われていないかもしれない）ページを検索する」
ことができるかも。
たとえばDVD-RAMで検索する場合を考えると、もちろん「DVD-RAM」というキーワードが使われているページは「DVD-RAM」と関係したページだろう。
でも、「DVD-RAM」というキーワードが使われていなかったとしても、「DVD-RAM」というキーワードが使われたページからリンクが張られているページや、「DVD-RAM」というキーワードが使われたページにリンクを張っているページは、もちろんDVD-RAMとなんらかの関係があるページだ。
たとえ「DVD-RAM」というキーワードが使われていなかったとしても、それらのページに重複してリンク・被リンクされているページは、DVD-RAMというキーワードとの関係は非常に大きいと考えられる。
全文検索を実装する代わりに、検索インデックスを充実させて、こういったインテリジェント（？）な検索（だが負荷は全文検索よりは軽い）を実装することによって、Wiki的キーワードのつながりを表現する手もあるだろう。
ページ命名規則
やっぱり英語でもページ名の命名規則については、かなりいろいろな問題があるようだ。重要なキーワードになる部分だけれども自由度が高いから、揺らぎが大きくなっちゃうと大変だもんね。
で、英語においては単数形・複数形という日本語にはない問題があるけれども、それに関してはできるだけ単数形を使おうというポリシーが一般的だそうな。ただし、あくまでもポリシーであって、システム的な制約ではない模様。システム的に警告を出したりする実装もあるらしいけど。
あと、階層構造も名前空間もないWikiにおいては、ユーザーがページ名をつけるときに意識して名前空間ライクなことをしなければならない。あるページから派生したページを作成するときは、元ページ名の後ろに派生要素の単語を付加するような形で、ページ名をつけるというポリシーで対策している場合が多いらしい。
結局最終的にはユーザーがそのあたりを管理しろと言うことらしく、ちょっと初心者には敷居が高い感じがするね。
俺的にはそのあたり、限りなく掲示板ライクな使用感で使えるようにしつつ（適当に投稿するだけ）、使おうと思ったときにはWikiライクに使える（ページ名や他ページへのリンク、再編集などを意識する）ようにしたいなー。
そのためには、ページ名、名前空間＋ページ名、ページsidの3パターンのページに対する表現をうまく使い分けて、ユーザーインターフェースでそのあたりの違いを吸収する方針でいきたい。できれば掲示板ライクに使っていたユーザーも、慣れてくると段階的にwikiライクな使い方ができるようになっていくような、うまいUIが作れればいいんだけど。
主なWiki修飾フォーマット
段落の終端を空白行で表す。おそらくあらゆるブロック要素が空白行で終端となるんじゃないかな？ で、通常の段落の開始は特に明示せず、システムが暗黙のうちに開始する感じだと思われる。
「*」ではじまる行は<UL><LI></UL>相当の番号なしリストになる。**などと複数個重ねるとリストの階層化ができる。これはそのままサポートしてもいいかな。リストの終端は空白行なんだろうか？ それとも*以外で始まる行があったらそこで終わりにするのか？
「#」ではじまる行は、<OL><LI></OL>相当の番号付きリストになる。でも#は一部ソースコードでコメント行の開始を意味するから、あんまり使いたくないなー。
空白（半角スペース？）で始まる行は<PRE></PRE>相当の整形済みテキストになるらしい。けど、ソースコードとかの行頭にいちいち半角スペースを埋めるのはいやだから、これも採用したくないなー。
「----（4つ以上）」は<HR>になる。これは採用してもいいけれども、段落指向な場合は段落中に<HR>なんて使いたくなることがあるだろうか？
「!」ではじまる行は<H1>〜<H6>相当の見出しタグになるらしい。けれども、IPWikiにおいては見出しは段落タイトル＝ページタイトルのみが有効で、段落同士の（ツリー構造による）つながりによって段落の深さが決定される仕組みを採用するので、段落中に見出しタグは書けない方針にする予定。
「:用語:定義」で<DL><DT><DD>相当の定義リストになる。これはちょっといろいろ考えてみないと。リスト関連全体を含めて。段落指向においては、リスト関連はそれ単体で1ページを構成するようにした方が正しいような気もするな。リスト属性をもつページとして、オリジナルのフォーマットを用意してもいいかもしれない。リスト以外の要素は記述できないようにしちゃって。
「||cell||cell||」なんて感じでテーブルを記述できる実装もあるそうな。このあたりはもうページ内に記述させるよりも、テーブル属性をもつページ（段落）を独立した編集させた方がよさそうな気がする。
「""」から始まるブロック（終端は空行か？）は<BLOCKQUOTE>になるそうな。なんかこれもいまいちっぽいな。hnfの方がよほど表現力が高いし、範囲指定も明確だ。
[literal][/literal]とか[esc][/esc]なんて表現で、その範囲をレンダリング処理回避ブロックに指定できるんだそうな。これが使えるところでは、htmlタグもそのまま使えちゃったりするのかな？
「''」で囲まれた部分は<EM></EM>相当の強調表現になる。
「'''」で囲まれた部分は<STRONG></STRONG>相当の強調表現になる。
WikiWord文字列はページへのリンクになる。
プロトコル＋アドレス（http://serverなど）は、外部リソースへのハイパーリンクとなる。これはまあこれとして、hnfみたいなリッチなハイパーリンク表現を使いたくなりそうだよなー。でも逆にこういう表現でしか外部リソースへのリンクを張れないからこそ、内部ページリンクとの差別化が図りやすいのかもしれない。
「[-」と「-]」で囲むと<SMALL>相当、「[+」と「+]」で囲むと<BIG>相当になる。
「#-」と「-#」で囲むと<SUB>相当（下付）、「#+」と「+#」で囲むと<SUP>相当（上付）になる。
「-[」と「]-」で囲むと<STRIKE>相当（打ち消し）、「+[」と「]+」で囲むと<INS>相当（挿入）になる。
Wiki的無秩序
Wikiはどうやら「無秩序であることに意義を見いだしている」部分があるようだ。逆リンクなどを使って、後付でページ間の関係を構造化することはできるけれども、編集されていく過程でそのあたりは根本から覆されることまで積極的に認めていく、というコンセプトを採用しているらしい。
俺の目標としては、「コンテンツは基本的に（ある程度）一貫した構造をもちつつも、その構造から大きく逸脱しない範囲において拡張・再編集されていく」ようなコンテンツ管理システムが欲しい。そのことを考えると、やはり俺の作りたいものはWikiというよりは、Wikiの利点を十分に活かした別のコンテンツ管理システムなんだろうな。
となるとポイントとしては、「一貫した構造」と「自由」のバランスをどのあたりに設定して、どういう内部仕様と外部インターフェースを用意するか、というあたりか。
Wikiのセキュリティモデル
既存のWikiシステムに見られるセキュリティモデル。
- 完全にオープン
- ロック可能（一部ページの編集に認証が必要）
- ゲート（一部登録ユーザーを認証して、編集機能を解放）
- メンバーのみ（すべてのユーザーを認証）
- ファイアーウォール化（ネットワーク構成を使った制限）
- 個人用（ネットワークに公開しない。自分のみアクセス可能なネットワークに置く）
俺のイメージとしては、1〜4までを簡単かつ自由に設定できる感じにしたいなー。自由に設定する方針についてはなんとなく見えてきたけれども、簡単にする方針とそれでいてセキュリティ的に強固（重要な機能は解放しない）にする部分は、まだ固まっていない。
セキュリティ対策としてディレクトリを分ける
特権ユーザー向けに別スクリプトを用意することによって、重要な機能を一般ユーザーには使わせないようにできる。特権ユーザーに対しては、スクリプトレベルではなくサーバーレベルあるいはネットワークレベルでの認証を用意すればいい。
同様に、閲覧専用と編集用ではディレクトリを分けて、閲覧側から編集側のCookieを読めないようにしておけば、もしもXSSが見つかってもそう簡単には重要な情報がもれないようになるかも。
ファイルアップロードとかの機能についても、ディレクトリを分けてそのディレクトリにおける設定をがちがちに固めておけば、かなりセキュリティ的な安全度は高まりそう。あるいは直接ファイルへのアクセスはできないようにして、cgi経由でファイルをできるかぎりbinモードで出力するようにしたほうが安全か。
Wikiの敷居の高さ
Wikiは、「（一見取っつきが悪そうな）Wikiフォーマットでページを編集できる＝Wikiに参加できる」という敷居を設けることによって、参加者のレベルをコントロールしている（とWikiWayの筆者は考えている）らしい。
確かにオープンなコミュニティにおける自浄作用の効果を期待するのだとしたら、オープンの範囲をそういう方法で縛る（参加者を選別する）方法は有効だろうし、俺もそういうやり方はスマートで好きだ。
けれども、（本書の表現を借りるところの）「テレビを観て満足している層」も参加することによって、2chのように、コミュニケーションの量的爆発とそれによるある種の成果が得られる可能性も捨てがたい（S/N比は高いが、有用なコンテンツの絶対量も多い）。
でもWikiも捨てがたい
でもWiki的アプローチで得られるものの中にも、捨てがたいものが多いんだよな。掲示板方面からアプローチするとどうしても組み込みにくくなりそうだし。
やっぱりひとまずWiki方面からのアプローチでできることをピックアップして、それらを中心に（掲示板的なやり方じゃないと実現しにくい部分は捨てて）作ってみようかな。
英語であることの利点・欠点
オリジナルのWikiは、基本的にそこで使われる言語が英語であることを前提に考えられている。英語であることの利点をうまく利用しているのが、オリジナルのWikiの実装だ。
Wikiの英語に依存している部分
たった26×2種類の文字（大文字・小文字）で表現でき、単語間が半角スペースで区切られている。そのため、非常にシンプルなパターンマッチによって、WikiNameをはじめとする特徴的なキーワードを設定することができる。
ある短い文章を表現する際の、文章表現上の揺らぎが比較的少ない。そのため、適切なWikiNameを設定することが（日本語と比べると）比較的易しい。たとえば日本語では、類義語の数が多いし、同じ単語でも漢字・カナなどさまざまな表記法がある。動詞の場合はさらに送り仮名の付け方にも揺らぎがある。
文字種類が少ないことから、検索負荷が小さくて済む。また、日本語のように文節の区切りを解析する必要もない。そのため、特に検索インデックスを用意しなくても、ある程度複雑な検索機能をシンプルに実装しやすい。
どのように日本語化するべきか
Wikiシステムはもともと英語という言語の特性に依存している。そのためWikiシステムを日本語化する際には、その部分をどのように対処するかがもっとも重要になる。
単純にシステムを移植するだけでなく、「その機能を割愛する」あるいは「似たような意味を持つ別の機能（日本語に向いた）で置き換える」などといった対処を行うことになる。
英語を使うからこそ手軽で便利に実装できた機能が、日本語にすると複雑で使いにくくなってしまうのだとしたら、それは実装する価値がないのかもしれないからだ。
WikiNameの日本語化
現在日本語化されたWikiシステムにおいては、英語版でのWikiName表現に加えて、一般的な文章ではあまり使われない区切り文字（[[]]など）でWikiNameに相当する部分を囲む（ブラケットネーム）という方法が用いられている。
ただし後者の方法（ブラケットネーム）は、WikiName方式の手軽さに比べると、入力の手間が大きくなってしまう。
WikiNameというのは、単語間の区切りとなる空白をなくすことによって、複数の単語を接続しつつ、単語の区切りとして大文字を使用することによって、コンピュータにも人間にも理解しやすくキーワードを生成することに成功している。
ポイントをまとめてみると、
- 半角空白でキーワードの前後が区切られる
- 大文字小文字を適切な規則で使い分けることによって、その部分がキーワードなのかどうかをシンプルなパターンマッチで判別する
ということになる。これと類似の機能を日本語においても実現可能だろうか？
少なくともキーワードの前後を半角空白で区切るというのは、日本語においてもさほど難しいことではないだろう。では半角空白で区切られた部分がキーワードかどうかをどうやって表現するべきか。
ひとまず思いついたパターンとしては、
- 接頭辞をつける。たとえば?なんかを使って『このように ?WikiName を使う』
- 接尾辞をつける。『このように WikiName? を使う』
- 前後を囲む。ブラケットネーム方式と似ているが、半角スペースという区切りが明確なので、ここでは[[]]ほど一般的ではない文字列を使う必要はない。たとえば『このように 「WikiName」 を使う』
- 単語＋助詞＋単語（＋助詞＋単語……）。たとえば『このように WikiNameの識別 を行う』。助詞として「は」「の」「が」「を」「に」……などを登録しておき、「単語＋助詞＋単語」形式にマッチした場合のみ、それをWikiNameとする。あまりにも短すぎる（言葉足らずな）WikiNameを排除することができる効果もあるだろう。
などがある。
できるだけ英語風に日本語WikiNameを実装する方法
できるだけ英語での扱いと同じように日本語WikiNameを実装するとなると、WikiNameの日本語化における4のやり方が近いのではないだろうか。ただし、4で述べた方法では誤認識の可能性が大きいので、できるだけ簡便かつ誤認識の可能性を低めた方法を考える必要がある。
ポイントは、半角スペースで区切られた部分にどのような特徴を付加すれば、そこがWikiNameにしたい部分であってほかの文章とは異なるのだということが明示できるか、だろう。
4では「助詞を区切りに使う」としたが、日本語の助詞はさほど明確な区切りとはならない。しかし、下手な記号を使う場合よりも、表現が自然になるというメリットがあるだろう。では助詞以外に、ある程度自然な表現を維持したまま、区別が明示できる要素はあるだろうか。
モーニング娘。方式
たとえば、「モーニング娘。」のように、日本語WikiNameの区切りとして必ず句点をつける、というのはどうだろう。
というのは半分冗談だが、前後に半角スペースをあけ末尾に「。」をつけるという表現は、そんなに悪い案ではないように思う。単語末（文の途中）に「。」がつくことに対する違和感は、多くの日本人にとっては「モーニング娘。」効果で薄れているだろう。
ここで重要なのは、「。」はコンピュータにとって明確な識別子となると同時に、人間が読む場合にそれを暗黙のうちに無視して読解することができる、という点だ。「。」は日本語文章中に混ざっても特に問題のない要素であり、なおかつ日本語環境において入力するのが簡単な要素である。
って、これは4方式ではなくて2方式だな。
日本語WikiNameを実際に実装するとしたら
今のところ一番無難そうに感じるのは、WikiNameの日本語化における1の方法だ。
おそらく4は、複数の半角スペースが一文中に使われた場合、WikiNameにしたい部分とそうでない部分を区別するのが難しくなるだろう。単純に「助詞」ではなく、もう少し特徴的な区切りを設定すれば、なんとか実用的な仕様になるかもしれないが。 では1の仕様を採用して、WikiNameにしたい部分に対して、「その前後に半角スペースを入れる」「WikiNameの頭に“?”をつける」とした場合のメリット・デメリットを考えてみる。
全角で文章を書いているときに、半角スペースを混ぜるのは面倒だという初心者は結構いるかもしれない。たいていのIMEではSHIFT＋スペースで半角スペースが打てるはずなので、それを活用してもらうよう啓蒙すればいいだろう。 WikiNameの部分だけ連文節変換できなくなる（前後に半角スペースを挟むため）というデメリットもあるが、現在のIMEの能力から考えれば（どうせまとめて変換したときの信頼性はそれほど高くない）許される範囲だと思う。
接頭辞の“?”は全角でも半角でも可としておけば、入力が面倒だという人はさほどいないと思う。また、WikiName以外の部分で文頭に“?”を使いたいという場合もほとんどない（外国語の一部に行頭に？を使うのがあった気がするけど）だろう。未解決なページリンクの一般的なWikiにおける表現との親和性も高そうだ。あとでその修飾を削除したい場合も、「s/\\s\\?([^\\s]+)\\s/$1/g」なんて感じで一発で消すことができそうだ。
関心空間的アプローチによる日本語化
日本語環境において、英語に依存したWikiシステムをそのまま再現することが難しいのならば、そのエッセンスだけを抜き出して、根本的に違うシステムを構築してしまうという手もある。 たとえばWikiのエッセンスをひとまず、
- 手軽にWebインターフェース上で新規投稿・再編集が可能なコンテンツ管理システム
- コンテンツ内のキーワードを手軽にハイパーリンクでつないでいくことができる
の2点だと捉え、その機能を実現するまったく新しいシステムを構築してしまうことも可能だろう。
そういうアプローチでどのようなシステムを作るかというと、たとえば関心空間的にキーワードをつないで他のコンテンツへと接続するインターフェースを、Wiki的ではない仕様の元に実装してしまえばいい。
コンテンツ管理部分は、普通の掲示板的なものでかまわない。ただし、各投稿は「タイトル」と「本文」を持ち、「タイトル」と「本文」の内容から自動的に（あるいはユーザーが明示的に）検索インデックスとなる「キーワード」を生成する。
あとは、コンテンツを出力する際に、それに関連するキーワードをもつコンテンツへのリンクを表示してやればいい。Wiki風にするならば、本文中のキーワード文字列に対して、そのキーワードに関連したページへのリンクを自動的に付加したり、まだ関連ページが存在しない場合は、そのキーワードに関する新規コンテンツの作成画面へのリンクを付加することも簡単だろう。
英語では入力者が簡単に登録できるキーワード（WikiName）が、日本語においては簡単に登録できないのならば、「入力者が（すべての）キーワードを設定する」という部分をばっさり切り捨て、システムがキーワードとおぼしきものの登録・検索を補助することに特化したシステムを作ってしまうわけだ。
_ ウェブログ・ハンドブック (13:50)
関連ネタ
2003/12/27
で、全体を読み通したあとの感想は後回しにして、あちこちで話題になっているデザインについて、blogmapの方のコメントに書いたのをこっちにも転載しておく。
>>ちなみに私はあの難読デザインを、作者（および編集者・デザイナー）による意図的なものなのだろうと深読みしすぎていた（わざと難読化することにより何かを表現しているのかな？とか）のですが、そうでなかったとしたらデザイナーの能力に問題があると思います。あれだけ過度にユーザビリティの低いデザインを、ユーザビリティを低めるという意図のもとではなく採用するってのは、ちょっと普通じゃない、どころか、かなりおかしい。
ちなみに、最初見たときにあれは、「てんかんピカチュウ並のインパクトだな」と思いましたよ。
2003/12/16
yomoyomoさんに献本していただきました。ありがとうございました。
で、一通り読み終わってから感想を書こうと思ったんだけど、この本はあまりにも興味深い話が多すぎて、後からまとめて感想を書くのはもったいなすぎるんで、読みながら思ったことをつれづれに書いていくことにする。
ひとまず半分くらいを読んだ感想としては、この本は今まで発売されたハウトゥ色の強い情報提供系ウェブログ本とは、その方向が全然違う。
アメリカでウェブログという（草の根的）文化が立ち上がり、ブーム（流行）として急成長していった中、その文化を初期から構成する面子の一人として関わってきた著者レベッカ・ブラッド氏（女性）が、当事者（中の人）という立場で、自分自身を含めたウェブログ文化というものを考察・定義し、そこで培われた経験知（個人的なものもあるし、コミュニティとして共通のものもある）を後進のために文章としてまとめたもの、というのが（私が今まで読んだ）前半部の内容だ。
もちろん「ウェブログ・ハンドブック」だし、著者がアメリカのウェブログ文化に関わってきた人間なので、この本ではあらゆることを「ウェブログ」という切り口で語っている。しかし実際のところWebコミュニティにおける経験知というものは、コミュニティ（国境）を越えてかなり普遍性が高いようで、そこで語られている内容は、一般的な「個人Webサイト」の運営および「Webコミュニティ」との関わり方、としても十分に成立する内容となっている。
それはたとえば日本で言うならば、「日記猿人（あるいは津田日記リンクス）」に初期から登録していた「Web日記作者」が語るWeb日記文化というものの考察・定義および経験知のレクチャー、だったり、あるいは「ReadMe! JAPAN」に初期から登録していた「テキストサイト管理者」が語る「テキストサイト文化」というものの考察・定義および経験知のレクチャー、だったりするのだろう。
日本のWebコミュニティにおいても、そのような文章はあちこちで断片的に語られてきたが、このウェブログ・ハンドブックほど網羅的にまとめて書かれた文章はなかっただろう。
＃ 日本には2chという特殊なWebコミュニティが存在していることを考えると、2ch初期から関わってきた人が、2chの中の人という立場で語る2ch文化の考察と定義および経験知のレクチャーを読んでみたいなー、などと思ってしまったりもするが、そっち方向を語ると話が逸れすぎるので割愛。
この本は、ウェブログというキーワードにこだわることなく、個人Webサイトを作っている人ならば誰でも一度は目を通す価値がある。どちらかというと初心者向けのレクチャーが多いけれども、長く続けている人でも、この本を読むことによって自分が漠然と感じていたこと（経験知）を明確に把握することが出来るようになるだろう。
できれば、日本版の「Web日記ハンドブック」的なものを日本の誰かにもまとめて欲しい気がするなー（そういえば、かつて漏れ聞こえたWeb日記本の企画ってどうなったんだろう？ 消えちゃったのかな？）。
などといったところで、前半部の感想はおしまい。
2003-12-17 [長年日記]
_ 個人新聞 (13:50)
「個人新聞（personal newspaper）」。Web上であることを明記するために「オンライン」とつけてもいいかもしれない。
「新聞」といっても、ここではいわゆるマスメディアの一員としての意味合いは二義的であり、どちらかというと「学級新聞」や「壁新聞」のような「狭いコミュニティにおける読み物」という意味合いが強い。
「新聞」には、いわゆるニュース記事のみが掲載されているわけではない。書評や訓話的な文章（天声人語とか）、関係者による雑記（編集後記とか）、読者からのコメント（各種読者投稿欄）など、さまざまな記事が掲載されている。
全国紙よりも地方紙、地方紙よりも各種コミュニティ紙の方が、その内容に関する自由度が増して行くように、個人紙ともなるとそこに掲載される記事の自由度は非常に高くなる。しかし、それでもなお「新聞」という言葉でくくることは可能だ。
「個人によるWeb公開」を「新聞」のアナロジーで捉えようという考え方は、特に目新しいものではないが、今現在の個人Webサイト（blog系ツールの流行）を表現する言葉としては、「Weblog」「blog」「Web日記」などよりも、「個人新聞」の方がしっくりくる気がする。
いわゆるblog的なサイトを運営している人ならば、簡単に「個人新聞」というアナロジーを受け入れることが出来るだろう。またそれによって（「blog」や「Web日記」という言葉から脱却することによって）、自身をしばる見えないしがらみから自身を解き放つことができるかもしれない。
また、いわゆる個人的な日記に近いものを書いている人たちには、「個人新聞」というアナロジーを適用することによって、「どれだけ個人的な、日記的な内容を書いていても、それはあくまでも新聞（他人が読むもの）である」ことを自然と意識させることができるかもしれない。
などと「ウェブログ・ハンドブック」を読みながら考えた。まあ「個人新聞」とそのまま書くのはあまりに字面的にダサいので、流行らせたいならばなんらかの略称なり別表現を考えた方が良さそうだが。
_ 2373-G4J欲しいのぉ (13:50)
仕事用にノートPCを買い換えよう計画は、ひとまず急ぎじゃないんで来年頭のDothan搭載機発表（Dothanの出荷が2月だから、年明け辺りから各機種のモデルチェンジが発表され始めるかな）以降に持ち越そうと思っていたんだけど、ThinkPad T40p（2373-G4J）が最安値で33万円くらいまで落ちているのを見かけてしまい、ついつい惑ってしまうのです。いや、33万って十分高いんだけど、でもスペックを考えると結構いいよなー。1G RAMモジュールだけでも結構高いものだし。むぐぅ欲しい。でも買わないけど。
_ 平成軒 (13:50)
ラーメンアカデミー各店感想。
2004/1/5
風邪で体調が悪いのに空いていたんで思わず食ってきた。前回あまりにもまずかったのに、世の中の評判がいい方なのが納得いかなかったんで。
で、今回はごく普通の醤油ラーメン。650円だったかな。全部入りみたいに変な（冷たい）具が入っていなかったんで、前回のようにぬるいと言うことはなかった。変わったスープだ。なんかいろいろ入っている感じで濃いめの複雑な味がする。こうやって熱いスープで食べると結構嫌いじゃない方向性の味なんだけど、なんかもう一声俺の好みの味じゃない。なんかちょっと酸っぱすぎるというか。もうちょっと脂っこくてしょっぱい感じの方が好きなんだよな。
というわけで、前回の最悪の印象は脱したんだけど、特に好印象というほどでもなく、ちょっと変わった普通の（おいしさの）ラーメンといった印象。醤油以外も今度食べてみようかな。
2003/12/17
今日は平成軒。これで全6店ひとまずコンプリート。頼んだのは全部入りだったんだけど、ちょっとこれはきついな。今まで全部完食（ほぼスープも全部飲んだ）してきたんだけど、ここは全部食う気になれなかった。というのは、具のひどさ。
特徴的なのは、大きく薄く切った大量のネギ（辛くない）と、何を考えているのか分からないくらいでかく切った大量のシナチク（5ミリ×10ミリ×150ミリくらいの大きさのものが、15本くらいか？ 短めで太めの四角いエンピツが一ダースほど浮いていると思いねぇ）なんだろう。どっちも見た目のインパクトはあるけれども、大してうまくない（というか、俺的にはシナチクはまずいと言ってもいい）。それだけではなく、冷たい（温められていない）そいつらが大量に入れられるもんだから、ラーメン自体が冷却されてしまい、なんともぬるい代物になってしまっている。別に熱ければ熱いほどいいという訳じゃないけれども、これはちょっとダメだろう。
麺とスープ自体は、ぬるくなければ結構嫌いじゃない感じではあった。濃いめの醤油味と結構味が染み気味な麺。チャーシューは味に癖がある（ちょっと臭くてえぐい系）の薄めのもの。特に好きじゃないけど、たまに食うとそれなりにうまい。
ともかく、冷たいネギとシナチクを大量に入れて、ラーメンをぬるくするのはやめれ。多分もう二度と行かないけど。ラーメンアカデミーなんかに入っていなかったら、二度と行かないなんてことにはならないだろうけど、さすがにあそこの中の店でこれだけ第一印象が悪いときついよ。
でもなんかこの店って、ほかの店と比べて結構客の入りがいいっぽかったんだよな。実は俺の味覚が変なの？ それとも単に場所がいい（入って目に付きやすいポジション）から？ ラーメンアカデミー本の表紙でも一番上に掲載されているしな。謎だ。
_ 来味 (13:50)
ラーメンアカデミー各店感想。
2003/12/16
ちょっと間が空いたけど、今日は来味に。頼んだのは全部入り。
で、今のところここが一番好きかも。あっさり気味の魚系だし醤油味スープに、特に特徴のない麺。具は、岩海苔がたくさん乗っていて歯ごたえと風味がなかなかいい感じ。チャーシューはちょっと厚めのさっぱり系。あと味付き半熟卵。量はふつうかちょっと多めくらい。
海苔とスープが特徴なんだろうけど、特徴的にうまいというよりは、なんかふつうにうまい醤油ラーメンって感じだった。まあその日の腹の空き具合なんかによっても変わるだろうけど、今のところ俺の一押しはここ。
_ 麺えるびす (13:50)
ラーメンアカデミー各店感想。
2003/12/11
今日は麺えるびすに行ってきましたよ。いつもよりちょっと遅れて11時半頃に行ったら、そこそこ混み始めていた。さすがに昼時は結構人が来ているのね。
今までの店は、お薦めっぽいものがわかりやすかったんで、メニューの選択が楽だったんだけど、ここは醤油と塩のどっちがメインなのかよく分からなかった。で、一番高級だったネギチャーシューの塩を選択。1250円なり。あと、中盛りが無料サービス中だったんで、それも選択。
そうしたら、具がものすごい盛りでやってきてしまった。柔らかく崩れやすいタイプのぶ厚いチャーシューがたくさん＋山のような辛ネギで、ラーメン本体が見えないくらい。チャーシューは好みの味だったんで良かったんだけど、大量の辛ネギで舌が麻痺してしまって、ラーメン本体に行き着いた頃には味が良く分からなくなってしまった。しかも具を食っているうちに腹一杯になってしまって、後半はかなり強引に詰め込む感じになってしまったし。
というわけで、ひとまず味の評価は保留。量と具の満足度は高かった。次はふつうの量の醤油味でも食ってみるか。
_ 鹿まる (13:50)
ラーメンアカデミー各店感想。
2003/12/10
さて今日は鹿まるに行ってきましたよ。今日も店は空いていましたよ。選んだのはまた全部入り。で、鹿まるは今まで行った中では一番好印象でした。俺には、九州ラーメン系の味がよく分からない（どれを食べてもそこそこうまく感じる。まずいと感じたことがない）という特性があるんで、その辺がちょっと困ったものなのですが。
具は、でかい角煮がひとかたまり（さほど好きな味ではなかった）と、薄いチャーシューが数枚（これは結構好きなあっさりチャーシュー）。あと半分に切った半熟卵（これは好き）。あと、薩摩揚げかなにかを細目に切ったものも入れてあった。ラーメンの具としては珍しい。麺はまあふつうにちょっと堅めのまっすぐ麺。スープがちょっと粘りけがある感じのもので、これは結構好きだった。
感動的にうまいってほどではなかったけれども、まあふつうにうまかった。それなりに豪華だし。あと全部入りが一番豪華なメニューだったけど、それ以外に数量限定の特別メニューっぽいのもあるらしかった。一周回ったら、今度それも食べてみようか。
_ 鏡花 (13:50)
ラーメンアカデミー各店感想。
2003/12/9
さて、本日もラーメンアカデミーに行ってきましたよ。11時ちょい過ぎに行ったら、やっぱり空いていましたよ。全店制覇する前に撤退されちゃったらいやなんで、早めに一通り食っとかないと。
で、どこにしようか迷いつつ、なんとなく鏡花を選択。特盛とかいう1200円のやつにしたのですが、なんですかこれは。なんか変に柔らかい麺（伸び気味だったのか、もともとそういうものなのかは不明）。厚く切っただけのチャーシュー（この年になると、大してうまくもないチャーシューを厚く切って大量に入れられてもあまりうれしくないのー）。そのおかげで量はまあまあかな。スープは喜多方ラーメンチェーン系っぽい醤油味（ここって魚系のダシなんだっけ？ あまりそれっぽく感じなかった）だったけど、そこらの喜多方ラーメンチェーンとかの方がうまいかも。
なんかすげーありきたりの要素で構成されていて、どれも大してうまくない（まずいわけでもない。いや、麺は俺的にはまずいに入るかな？ でもそれ以外は並か並よりちょい上程度）。辛ネギが唯一の特色っぽかったけど、別にそれほどうまいもんでもないしなー。
なんかこれはものすごくだまされた気分ですよ。すげーふつうのラーメン屋だ。ラーメンアカデミーなんてところに入っていなければ、こんなにネガティブな評価にならないんだろうけど、うまいまずいよりも、特色のなさっぷりがものすごく悪印象。
なんかこのラーメンアカデミーって、「ラーメン名店街」程度の名前に変えて、地味に営業した方がいいんじゃないか。大々的にイベントっぽく宣伝して営業すると、逆に羊頭狗肉的なマイナスイメージを強化しそうだ。
_ はまんど (13:50)
ラーメンアカデミー各店感想。
2003/12/8
そういや先週土曜日に、ようやく初ラーメンアカデミーしてきましたよ。土曜日の夕方くらいと、結構混んでいてもおかしくない時間帯だったのに、全然混んでいない屋内。このタイミングでこの客の少なさはちょっとやばいんじゃないかい。まあ食いに行く方としてはうれしいけどさ。
で、どの店も列ができていなくてすぐに食える状態だったんで、ひとまず最初は評判が良さそうだった讃岐ラーメン屋のはまんどへ。すべての店舗は各店入り口のところの食券自動販売機を買ってから中に入る方式になっていた。はまんどで一番豪勢な品らしい全部入り1000円なりを買って店内に。席は半分くらい埋まっている感じだったかな。
ラーメンは結構すぐに出てきた。第一印象は「少ない」。主食って感じの量ではないな。これ一杯で大人が腹一杯にはなるまい。あと、麺がラーメンっぽくない。というか、これってちょっと細いうどんじゃないの？ 具とか容器とかでラーメンっぽさを醸し出しているけど。
で、味はというと、なんだかとてもふつう。ただ、麺のこしが売りっぽかったのに、全然こしを感じない麺だったな。それが悪い訳ってほどじゃないけど、期待を裏切られた感じ。あと、スープは一見関西風の透明っぽい出汁じるに見えた（これもうどんっぽい）けど、飲んでみると意外にしょっぱかった。具もごくふつう。半熟卵はうまかったけど、今どきさほど珍しくもないしな。
というわけで、ともかくトータルの印象としてふつう。わざわざもう一度食いに行こうとは思わない感じ。まあ期待が大きかったからかもしれないけど。
2003-12-19 [長年日記]
_ 個人サイトの分類と定義
「ウェブログ・ハンドブック」と「儀礼的無関心」ネタあたりにインスパイアされたのか、今までにも何度かやった記憶のあるメタ定義ネタを久しぶりにやってみたくなった。過去ログ（http://ishinao.net/ruins/）を漁るとかつて行った同様のネタは見つかるかと思うが、下手に読むとそちらに引きずられそうなんで、現時点の脳みそのみを使って新規に書いてみよう。思いつきをだらだら並べていくんで、この記事は時間とともに編集されていきます。
想定する読者層
Webサイトというメディアを使う利点
- 情報伝達手段としての利点
- 不特定少数あてのメッセージを伝えやすい
- 不特定多数あてのメッセージを伝えやすい
- 特定多数あてのメッセージを伝えやすい
- ※特定少数あてのメッセージならば、他に有用な手段がある
- 閲覧する側に情報受信の選択権がある
- 公開相手を限定しない
- 新しい相手に同じ情報伝える際の手間が省ける
- ※メールなどだと再送しなければならなかったり
- ログの蓄積がしやすい
- 固定URLを使ったログ保存スタイルによって、蓄積された話題の個別記事の特定が可能
- 検索機能や日付によるインデックスによって、過去の記事を見つけだすことが容易
アクセスコントロールについて
- 基本的には、コントロールなし
- サイトにアップロードしたら無制限の公開
- サイトから削除したら非公開
- ただし、一度公開された情報は第三者（ロボット含む）によって公開されうる
- 著作権によって法的に非公開権を制御可能なはずだが、現実的には個人で非公開権を徹底するのは難しいだろう
- システム的な問題
- 大量アクセスによるサーバー過負荷
- データ転送量制限によるアクセス拒否
- その他、システム（サーバー、プロバイダー）管理者による制御
- サーバー設定（主にBasic認証）による制御
- 制御キー
- IPアドレス
- ホスト名
- 独自のID、パスワード認証
- ※がんばればDB連携を使って複数サイトをまたがった認証も可能かも。個人サイトレベルでは現実的ではないが。
- その機能が利用できるサーバーである必要がある
- 設定方法を理解できる（調べることが出来る）技術的な能力が必要
- 設定のメンテナンス性が良くない
- 制御キー
- アクセスコントロールを持つ専用システムを利用する
- はてなダイアリー（http://d.hatena.ne.jp/）
- はてな登録ユーザーIDを利用したアクセス制御
- 設定はWeb上から比較的簡単に行うことが出来る
- 比較的細かい要望が通りやすいので、具体的な提案があれば言ってみるとさらに柔軟性が増すかも
- DI:DO（http://www.di-do.net/）
- DI:DO登録ユーザーを利用したアクセス制御が可能
- 設定はWeb上から比較的簡単に行うことが出来る
- 記事ごとにアクセスレベル（一般公開記事と特定ユーザー向け）を変更することが出来る
- シンプルなCookie認証なのでセキュリティ的には厳密ではない（アクセス制御の部分は悪意のある攻撃に弱いが、管理系の重要な機能はきちんと保護されている）
- 関連する話題
- ほかに特筆すべき認証機能を持ったシステムは？
- はてなダイアリー（http://d.hatena.ne.jp/）
- HNS（http://www.h14m.org/）
- RURIコードとグループ設定を使ったアクセス制御
- RURIコードとは、ユーザー（ブラウザ）ごとに永続Cookieとして記録されるランダムユニークID。
- ユーザーID（＋パスワード）ではなく、あるアクセスを行ったブラウザに割り振られたユニークIDを利用することによって、匿名のユーザーを特定することが可能
- 実際には、アクセス履歴などから特定のユーザー（たとえば自分自身や知り合い）の持つRURIコードを特定し、そのRURIコードに対してアクセス権限（グループ設定、管理者設定）を付与する
- 管理者設定されたRURIコードを持つユーザー（ブラウザ）は、各種管理者機能にアクセスすることが出来る（ログインが不要）
- 記事ごとに対象グループを設定することができ、その記事は対象グループに含まれるRURIコードを持つユーザー（ブラウザ）がアクセスしたときのみ表示される
- セキュリティ的にはかなり厳密に作られている（XSS関連の洗い出しが行われ済み）
- 設定は面倒（必要スキルはかなり高めに設定されているし、上記のような仕様の理解にも技術的な素養が必要）
- RURIコードとグループ設定を使ったアクセス制御
Webに公開する目的
- 情報交換
- コミュニケーション
- 知識交換
- 自己主張（アピール）
- ウケたい
- 共感を得たい
- 意見を聞きたい
- 認められたい
- 実利目的
- 知識DBの作成
- 自分用のメモ
- 特定第三者向け
- 一般の第三者向け
「つもり」のずれ
書いている側の「つもり」と読んでいる側の「つもり」にずれがあると、驚いたり、当惑したりするのでしょうね、と考えた。
なるほど、自分は書き手の「つもり」しか考えていなかったけど、読み手側の「つもり」のバラエティも考えた方が良さそうだな。書き手の「つもり」と読み手の「つもり」の順列組み合わせによって起こりうる可能性、ってところまでたどり着けるかな。
このセクションに対するはてなブックマーク
2003-12-20 [長年日記]
_ REFERER SPAMでラノベの宣伝 (13:51)
REFERER SPAMの手法を使って本（日本のライトノベル系）の宣伝を行った事例が出たらしい。
- http://scientificclub.edisc.jp/diary/d200312b.html#19
- http://scientificclub.edisc.jp/diary/d200312b.html#20
- 「よく解るリファラースパム」事件（勝手に命名）続報 - http://scientificclub.edisc.jp/diary/d200312c.html#21
- 「よく解るリファラースパム」現在までのまとめ - http://scientificclub.edisc.jp/diary/d200312c.html#22
- http://scientificclub.edisc.jp/diary/d200312c.html#23
- http://bm.ishinao.net/detail.html/1705495
- http://bm.ishinao.net/detail.html/1663404
_ 個人Webサイトの歴史を書き残そう (13:51)
2004/4/15
>>そういえば、月刊アスキーの大森望氏のコラムが3月号から、日本の個人サイト創成期の話になってます。4月号でishinaoさんや自分の名前が何の説明もなく出てきて、まるでネット上のテキストを読んでいるような気分に。
とあったんで久しぶりに（たぶん5年じゃ効かないな）月刊ASCIIを立ち読みしたら、このネタの話だったんで、ちょっと反省。自分版も書くと言っておきながら、絶賛放置中だったんだよなー。書き始めたことは書き始めたんだけど、細かく書きすぎて途中で発散してしまい、放り投げてしまった。
ひとまずこの記事をageておくと同時に、ToDoリストの順位も上げておこう。さらに上位にまだまだ積み気味だけど。
2003/12/20
これも「ウェブログ・ハンドブック」と「ご長寿ブログを探せ（http://nais.to/hiki/hiki.cgi?%A4%B4%C4%B9%BC%F7%A5%D6%A5%ED%A5%B0%A4%F2%C3%B5%A4%BB）」あたりからインスパイアされたネタ。
「ウェブログ・ハンドブック」では、「ウェブログ」という切り口によって、アメリカにおける個人Webサイト文化のある一時期の歴史が描かれ、書籍という形で定着した。
特にその視点として、当時その内部で活動した人間が、自分自身の目で見て感じたことを元に、できるだけ客観的に（と私は感じたが、それがどれだけ確かなのかは定かではない）描いているところが優れている。第三者が歴史を振り返って書くことはいつでもできる。しかし、当事者が自分が体験した歴史を描ける時期は限られている。しかもその内容の正確さを保てる期間ともなるとなおさらだ。
今までにも、日本の個人Webサイト（主にWeb日記方面やテキストサイト方面、ちょっと個人サイトとは違うが掲示板文化系）コミュニティにおいて、さまざまな人がそれぞれの観点から歴史をまとめた文章を書いてきている。しかし、それらは個々人の独自の（その場限りの）活動として行われており、まとまった資料として利用することが難しかった。
今はちょうど、「ご長寿ブログを探せ」のような企画が活動しているときでもある。みなさん、自分が関わった個人Webサイト（に限らず、ネットワーク絡みの文化やコミュニティなどに関してならなんでも）に関する歴史の記録を書き残しておきませんか。ある程度俯瞰して客観的に描くのもいいでしょうし、「歴史」という観点から個人的な活動の記録をまとめてみるのもいいかもしれません。
今のうちに、できるだけ正確な情報をまとめておくことは、決して無駄にはならないと思います。後々になって、妙な俺定義やねつ造歴史が広まらないように。ひとまず私も後で自分の過去ログを振り返りながら、自分なりの資料をまとめてみることにします。
情報集積所としては、ここのコメント欄を使ってもいいですし、一応うちのPukiWikiにもページを作っておきました。あるいはどこか別のところ（YukiWiki本家とか、あるいは2chにスレを立てるとか）を使ってもいいでしょう。
できるだけさまざまな人が、さまざまな文化・コミュニティにおける、当事者（の一人）としての視点での文章を書き残してくれることを期待します。
2003/12/25
「（しょうもないねつ造歴史に対抗できるように）みなさん、自分なりの歴史の資料を書き残しておきましょう」という提言であって、「（俺のために）作ってください」とか「みんなで集まって何か作りましょう」と言っているのではないんだけどな。
「情報集積所があると便利だよね」ってのは、確かに後者に属するんだけどそっちは本筋ではない。そっちが本筋ならば「個人サイト歴史資料館を造りましょう」なんて感じの提言になる。
ちなみに「しょうもないねつ造歴史」というのは、たとえば『ウェブログ・ハンドブックに書かれていた「自分がウェブログ（スタイル）を発明した」とか言いだして叩かれたジャーナリストの話』とか、あるいは『日本にMovableTypeが紹介され始めたときに「ウェブログというスタイルの日本の創始者は俺たちだ」と言い出した（パラフレーズあり）人たち』とか、あの辺りをイメージ。
そういうしょうもないねつ造歴史を言い出す人間が出てくるのは、個人サイト系に関する歴史資料が少なすぎるからではないか。ならば個々人がそれぞれ関連テキストを書き残しておけば、そういうのが少しは防げるのではないか。という話。
その他価値観の相違については、それはそれってことで。
2003/12/24
>>そもそも他人をアテにしているのが非常にマズイ どんなに客観性を持たせても多少は主観が入るので資料として比較できる対象が多ければ多いほど後に研究する人にとっては良いのですよ つか歴史は今生きてるオレらのためじゃなくて後世の人のためだと思っているよ
うーん、なぜそういう感想を持たれたのかわからん。俺の文章が悪かったのか。
「どんなに客観性を持たせても多少は主観が入る」ので、「資料として比較できる対象が多ければ多いほど後に研究する人にとっては良い」から、「みなさん、自分が関わった個人Webサイト（コミュニティ）に関する歴史の記録を（それぞれ独自の視点で）書き残しておきませんか」と提案し、それらの情報を比較検討するためにはどこかにポインター（情報集積所）が存在した方が便利だから（というか、今まではそういうものが存在しなかったため、さまざまな資料が散逸しがちだったから）、ひとまずWikiを用意しましたよ。
という話なんだけどな。「私が歴史を書くための素材をみんなで書いてくれ」っていうんじゃないですよ。「みんなが自分自身の体験を歴史という視点からまとめた文章を（今後のための資料として）書き残しておこう」って話ですよ。為念。
そういうアプローチだと理解をした上で、「吐き気がする」と思われたのならば、俺にはお手上げだ。相互理解のためのキーが根本的になにか足りていない。
2003-12-22 [長年日記]
_ REFERER SPAMでラノベの宣伝 (2) (13:51)
ちなみに私はREFERER SPAMの“手法”を使った宣伝について、完全に否定しているわけではありません。たとえば、ある種「ドッキリカメラ」的な、後で許される範囲の身内なんかでやるのはありかなー、なんて思っています。今回の件が、それに当てはまるかどうかは知りませんが。
_ RSS を基本にした分散掲示板 from おのひろきおんらいん (13:51)
- RSSを基本にした分散掲示板 - http://onohiroki.cycling.jp/index-log200312.html#d20031212n3
- RSS を基本にした分散掲示板(2) - http://onohiroki.cycling.jp/index-log200312.html#d20031215n2
- RSS を基本にした分散掲示板(3) - http://onohiroki.cycling.jp/index-log200312.html?d20031221n1_#d20031221n1
前に似たようなことを考えたことがある（し、どこかに書いたような気もする）けど、個人的には、特に掲示板ということを意識せず、RSS（じゃなくてもいいけど、何らかのメタ情報）によって、さまざまなWebサイト上に公開されているテキストが集約されれば、それでいいんじゃないかと思っている。
blogmapがもともと目指していたものもそうなんだけど、同じ話題に関して書かれたさまざまなWebサイトの記事（Web日記、blog、掲示板）を、一カ所に集約して閲覧することができるのならば、それは機能的には分散掲示板みたいなものになる。blogmapは、コメント機能も持たせていて、これがすなわちいわゆる掲示板的な（Webサイトを持たない人でも意見を言える）機能になるけど、私的にはそっちは主ではないイメージ。
今ならば、無料・低価格のblogツール・Web日記ツールがたくさんあるんだから、掲示板的なものに参加したい人がそれぞれ自身のWebサイトをもつことはさほど難しくないだろう（し、掲示板とは違って、各人の文章に関する文責も明確になるという利点もある）。あとは、それぞれの人が自分の管理するWebサイトに書いた投稿を、集約して閲覧できるような仕組みさえあれば、それが次世代の分散掲示板に相当するものになる。
ひとまずは、blogmapみたいに自動的にデータを収集してなんとかしようと試みてみたんだけど、このアプローチだと（資金力がないと）限界が見えすぎていて厳しい。一昔前のコミュニティの規模が小さい頃はそれなりに行けそうだったけど、最近みたいに人口が爆発的に増えてくると個人レベルでこういうアプローチを成功させるのはちょっと無理そうだ。
blogmap的手法にトライする前には、更新報告型リンク集（日記才人、ReadMe! Japan、テキスト庵みたいなもの）に言及情報をつけることで、そういうものを実現させようと思ったり（http://ishinao.net/diary/?200201c&to=200201281#200201281の更新報告型リンク集ってやつ）もしたんだけど、これは各Webサイト運営者が負担しなければならないコスト（いちいち言及系メタ情報を意識して更新報告をしたり）があまりにも大きすぎて、実用レベルにはならない（ユーザーが集まらない）だろうと思い、実際には作らなかった（設計だけはしたけど）。
今ならば、個人サイト上に書いた記事を、サイトをまたがって連携させるための基本的な枠組み（RSSやTrackBack）はすでに実用レベルになっているから、それらの機能をうまく組み合わせてそれなりのものを作る（一応blogmapもそういうアプローチの一つのつもりではあるけど、そういう用途としてのできはあまり良くない。Bulkfeeds（http://bulkfeeds.net/）もそういう用途で使えなくもないけれども、こちらもそれほどそういう用途での機能性が高いわけではない）か、あるいははじめからそういう用途で使うためのとんがった仕様を考えて（RSSやTrackBackの拡張というアプローチで結構いけるはず）普及させるか、って感じだろうなー。
個人的には、重装備系の後者に惹かれるんだけど、そこまで重装備に遊んでいる余力はしばらく出ない予定。後者のポイントとしては、
- 「話題（＝2chでいうスレッド）」を特定する仕組み（blogmapだとURLの多数決だけど、これはちょっと不便だ）をどうするか。また特定した話題キー（blogmapだとURLだけど、本当は同じ話題を扱った複数のURLがあり得る）をどのように（不特定多数のWebサイトで）共有するか（PingProxyとか言葉交差点的なアプローチを使って、中央サーバーがメタ情報化されていない本文内容を解釈して、自動的にメタ情報を抽出する仕組みが適当かなー、などと漠然と考えている）
- どのようにして各Webサイト管理者がそこに情報提供するか（まあTrackBackを拡張したような仕組みだろうな）。その際のコスト（手間）を低くするか。
あたりだろうなー。
ああそういえば、ちょうど話題のネタとしては、
みたいなアプローチもあるよね。
多分Googleなんかは、検索機能を利用してこういうアプローチを行いつつ、さらにGoogleNewsみたいな機能と連携させてblogmap的なアプローチも混ぜたりしていそうだ。
2003-12-24 [長年日記]
_ 黄泉びと知らず (13:51)
「黄泉がえり」のサイドストーリーである「黄泉びと知らず」を含めた短編集。「黄泉びと知らず」は「黄泉がえり」を読んだ後に読むととてもいい感じのサイドストーリーだった。ちなみに「黄泉びと知らず」とは黄泉がえってもらえなかった人のこと。
その他の短編は、なんかすごく60年代日本SF的というか、具体的には筒井康隆とか小松左京とかの昔の短編を読んでいるような感じのものだった。それなりに面白かったけれども、なんかちょっと今どきっぽさが足りなかった。ネタをストレートに（あまり複雑にひねらずに）使った短編って感じ。
_ ベルセルク (13:51)
あれ、ベルセルクって項目作っていなかったんだっけ。ってことで26巻。
最近全然連載はチェックしていないんで、コミックスが楽しい。新鷹の団が出てきた辺りで、ちょっと今後の展開に不安になったりしていたんだけど、魔法使いとその弟子（少女）なんてべたなネタに持っていったくせに、ストーリーのクオリティが落ちていないのは偉いな。これだけサイドストーリー的な要素が充実しているくせに、ちゃんと地道にメインストーリーも進行させているし。でもこの人ってもしかして、これからずっとベルセルクだけ描いて生きていくんだろうか。まあこの人のほかの作品で面白かったものってあんまりないから（というか、オリジナルが少ない？）いいんだけど。
2003-12-25 [長年日記]
_ REFERER SPAMでラノベの宣伝 (3) (13:51)
スラド（http://slashdot.jp/articles/03/12/25/0126200.shtml?topic=66）の方のコメントにも書かれているけど、REFERER SPAMとTrackBack SPAMは別物ですよ。TrackBack SPAMはどちらかというとコメントスパム（掲示板スパム）に近く、HTTP POSTで特定のURLに特定の情報を投稿する仕組み。REFERERはHTTP_REFERERに値をセットしてURLにアクセスするだけだし、その情報は必ずしもWeb上に公開されるとは限らない。で、うちはメリットデメリットつき合わせた結果、REFERERの自動表示はやめてしまった。わざわざアクセス元をGETして、自サイトのURL文字列が含まれているかチェックする気にはなれないし、管理者チェックとか不正URLのメンテとかするコストをかける気にもなれないし。
2003-12-26 [長年日記]
_ TrackBackによる書評サイト from ただのにっき (13:51)
- TrackBackによる書評サイト - http://sho.tdiary.net/20031225.html#p04
もともと現行バージョンのblogmapシステムは、
- blogmapベースの書評リンク - http://ishinao.net/pukiwiki/?%5B%5Bblogmap%A5%D9%A1%BC%A5%B9%A4%CE%BD%F1%C9%BE%A5%EA%A5%F3%A5%AF%5D%5D
などの、Wikiでやっていた書評リンク集ネタを意識しているので、書評サイトとしての機能（というのは、つまりはタイトルや著者名、出版社名などによるインデックスや検索）も用意する予定だったんだけど、あまりにも書評データ量が少ないんで頓挫中。tDiaryが対応してくれたら、データ量が増えそうなんで、そっち系の機能を追加するモチベーションも増すかも。
ちなみに放置運用中のPingProxyでは、記事中にISBNらしき文字列が見つかった場合は、自動的にblogmapにTrackBackを送るんで、システムをいじれない人はそちらを使うと便利です。
- PingProxy送信フォーム - http://pingproxy.ishinao.net/requestform.html
- いしださん作デスクトップ版TrackBackクライアント - http://www.ksky.ne.jp/~naoto/39_akiary/n3/200310.html#20031013_1066057303
※（私信）いしださん、提案無視しっぱなしでごめんなさい。
それにしても、blogmapのデザインは不評だよなー。真面目にちゃんと設計し直してみようかな。
そういや、最近ようやくblogmapを単なるランキングサイトではなく、「関連リンク集」とか「書評リンク集」とか、個人サイト（の記事）を結びつけるハブ的に使ってくれる人たちが増えてきたなー。どちらかというと、そっちの用途の方がメインのつもりだったんで、この流れは嬉しい。
NOGさんのところにも早速対応していただけました。
ってことで、この年末年始の間にでも、書評リンク集としてのUIも充実させておこうかな。
_ viewsic 岡村靖幸スペシャル (13:51)
「岡村靖幸“フレッシュボーイTOUR”」の模様を放送したviewsicの番組。録画しようとして取り損ねたんで、人から借りて見た。
やっぱりかなり太ったままで、動きの切れがちょっと鈍くなっていて、声もいまいち出ていなかったけど、一応ちゃんとやっている。昔と同じような（岡村靖幸がめちゃめちゃがんばる）ライブの構成だ。
ただ、昔だったらダンサーズよりも切れの良かったダンスが、今では一番切れが悪くなってしまっているのが悲しい。けど、このくらい動けるのならば、そのうち体重も絞れて復活してくれそうな気もする。っつーか、37才であれだけ動けるってのはすごいんだけどね。
あと、ライブではいつものことなんだけど、歌いながら作曲する（本来のメロディ通りに歌わない）ときに低音方向に逃げすぎだったのが気になった。放送分のライブって5回公演の4回目だから、声がかれていたのかな。まあ喉は歌っているうちに復活してくるだろう。
放送はあと2回予定されているんで、見逃した靖幸ファンは是非チェックを。今後に期待できる感じ。ただ、「岡村と卓球」の「The Album」は人から借りて聞いたけど、「いつもの卓球＋ちょっとだけ岡村の声も聞こえる」な感じだったんで、買うのはやめた。悪くはなかったけど、なんか「岡村と卓球」と言う名前には見合わない感じ。
2003-12-27 [長年日記]
_ Google AdSense (13:50)
2003/12/27
日本でもGoogle AdSense（https://www.google.com/adsense/）が使えるっていうんで、申し込んでみたら許可が下りた。んで、試しに採用。なんかもう、うちはGoogleとAmazonという、現時点でのWebの勝ち組べったりな構成になりつつあるな。っつーか、便利なんだからしょうがないんだけど。
そういやGoogle AdSenseってのは、基本的にJavaScript出力なんだね。普段JavaScriptオフなんで、意識しないと自分では見ることができない。
Google AdSenseは、Googleが各ページに含まれるキーワードを解析し、そのページに最適だと思われる広告を表示する機能を持つ。ということは、逆に言うとそのページに表示されたGoogle AdSenseによって、そのページが第三者の目から（主に商業的な意味で）どう見えるのかがわかる、と言えなくもない。
しばらくの間、自分で書いたテキストをGoogle AdSenseがどのように評価するのかをチェックする、というネタで遊べそうだ。トップページに表示されるGoogle AdSense広告によって最近のテキストの傾向を、各ページに表示されるGoogle AdSense広告によってそのページが自分の意図とどれだけマッチしているかを推測する、とか。
2004/1/6
mylogページに貼って10日。（規約で禁止されていたので、収入やクリックレートに関する情報抹消。秘密情報に属する技術情報とかも載せちゃいけないのね。どの辺までが秘密情報なんだろうなー）
ひとまずもうちょっと可能性を追求するためにblogmapの方にも貼ってみた（さらにデザインがひどくなった）。が、あっちはGoogleのクローリング対象にほとんどなっていないんで、ろくな広告が出ないなー。あれじゃダメっぽい。が、もしかしたらGoogle AdSenseを貼ることによって逆に、blogmapの方もGoogleのクローリング対象になったりするかも。
2003-12-28 [長年日記]
_ 運命の息子 (13:50)
同じくジェフリー・アーチャーの「ケインとアベル」とか「ロスノフスキ家の娘」とか「めざせダウニング街10番地」とか、あの辺の要素をごった煮にして設定（時代背景）をちょっと変えた話。とか言いたくなるくらい、同じようなパターンだ。学校、政治、経済、法律（裁判ネタってのはちょっと珍しいかな）を舞台に主人公が闘いながら成長していく（というか、目的を達成していく）話。戦争（実戦）ネタってのもちょっと珍しかったかな。相変わらず面白いんだけどね。
ただ昔の作品よりも面白かったのかというと、そうでもない。特にこの作品は、二人の話を交互に切り替えるスピードが煩雑なほどに速すぎるのと、せっかくスタート地点を大きく違えたはずなのにあまりにも成長の過程が二人で似すぎている（兄弟だからそうなる、ってことなんだろうけどね）のがいまいち。
アーチャーを読んでない人ならばひとまずこれを読むよりも、古い作品から順番に読んでいった方が幸せでしょう。
2003-12-29 [長年日記]
_ わかりにくい中途半端な症状 (13:51)
うちのムスコ（とオクサン）は、長期休みの終了間際に具合が悪くなる（＝休みが延長される）という技を持っているのだけれど、今回は病院が長期休みに入るタイミングで具合が悪くなる、という非常に面倒くさい技を使ってくれました。えーっと、今腹に来る風邪とか流行っているんだっけ？ 普段はほとんど元気なんだけど、ときどき急に弱ってへたり込む感じ。で下痢気味。あと、鼻水は前からひどかったんだけど、それが喉に来てゲロっぽく（でも吐くのは鼻水混じりの唾だけ）なったりとか。病院が開いていたら病院に連れて行って一安心できるんだけどなー（ちなみに病院最終日に耳鼻科に行って鼻水の薬はもらってある）。大して重病でもなさそうだから、わざわざ救急病院に連れて行くほどでもないし。こんなタイミングで、わかりにくい中途半端な症状にならないで欲しい＆
_ uk [POPFileはAPOPに対応しています。 http://popfile.sourceforge.net/cgi-b..]
_ ishinao [実はもうPOPFileを使ってないのです……。 でもまた使うときがあるかもしれないので、そのときのためにAPOPが使..]