_ Noraライブラリをインストールしてみた (06:17)

「リンク元もうちょっと強化」プラグインにNoraライブラリを入れると速くなるよ、と書かれていたんで気になっていたんだけど、名前から「純正非互換の高速化ライブラリ」的な印象を受けていたんで、なんとなく導入をためらっていた。けど、ちらっと調べてみたら確かに純正（cgi.rb）非互換ライブラリの類ではあるらしいけれども、どうやらrubyではcgi.rb互換ライブラリを使うことは別に珍しいことではないっぽい感じだったので、試しに導入してみた。ついでにerbscanとやらもインストールしてみた。速くなったかな？　あとはmod_ruby化するくらいか。でも今は「似た話題の日」検索のためにいちいちestxviewを起動しちゃってるから、mod_ruby化してもあまり意味がないかも。tDiaryのcacheの使い方を勉強しないとなー。

_ のだめカンタービレ (10)(二ノ宮 知子) (13:08)

盛り上がったRSオーケストラ編の後、海外に行ってもちゃんと盛り上がるのかちょっと不安だったけど全然無問題。日本に残される人々に関しても、ちゃんと解決して（というかオチをつけて）いるし。フランス編では今度は千秋が挑戦者になる番なんだね。それにしても滞空時間の長い指揮ワラタ。

_ 削除されたコメントの引用は削除されるべきか？ from 木っ端拾いの材木流し (14:36)

この記事は「自主削除されたテキストの引用」に移動しました。

_ attacking MT 1 from SG::Acme (17:28)

この記事は「外部URLからの（自動）POST攻撃への対策」に移動しました。

はてなでは

file://と自ドメイン以外からのPOSTをREFERERを見てはじいているみたいだな。はてダラは通るのかな？　まあはてダラみたいなツールでは、REFERERを偽造しちゃえばそれですむだろうけど。

ちなみに

この問題は無差別攻撃ではなく、あくまでもピンポイントで狙われたときにのみ攻撃されるというものなんで、一般的なブラクラみたいに広範な影響はないでしょう。

広範な影響がありました

「はてなの例のexploit 続き」で例として挙げられているように、pingサイト＋trackback（or コメント）＋refererのコンボを使うと、結構大量に攻撃できそうですね。refererを使うってのは思いついていなかった。

_ タイミングが難しい (18:25)

「日記ツールで下書き、blogツールで清書」というポリシーに従って運用しつつあるんだけど、どのタイミングでコンテンツを移動するべきかが難しいな。大きく分けると、

• 書いてしばらくして、一通り言及され終わってから移動
• 書いてすぐに（まだ言及されないうちに）移動

という二つのタイミングがあるわけだけど、最終的なコンテンツURLは移動後のものになるんだから、できれば移動後のURLで言及される方がいい。けど、ほとんど寝かさずに移動してしまったのでは、わざわざ日記ツール上で下書きしている理由の一部（練りが荒い状態のテキストを日記ツール上で叩いてもらって、ある程度もまれた結果をblogツールへ移動する）に意味がなくなる。

あと、移動する際にはできるだけ元のテキストを残しつつも、独立したコンテンツとして成立するように微妙に編集していたりするんだけど、その辺の改変度合いも難しいな。自分ではどうでもいいと思って改変した部分も、人によっては重要だったり（改変じゃなくて改ざんだ！とか）しかねない。でもコンテンツが二重化するのはいやなんで、基本的に元テキストは削除した上で移動したいしな。やっぱり履歴管理ツールと連動する仕組みがほしいなー。

_ 24dをちょろっと使ってみて (21:31)

基本的なオブジェクトはあのくらいにシンプルにしつつ、ネットワークを自分を中心とした1:nよりももうちょっと先まで（n階層先まで）一気にたどれるようにして、3D表現を使って表示すると結構面白そうかも、とか思った。

前に3D方向に展開するBBSってのを考えたことがある。一般的なツリーBBSみたいに、ある発言に対してレスポンスをつけられるんだけど、そのときにレスポンスの方向をn方向（賛成、反対、別意見とか）で表現できるようにする。それを表示するときには3次元のネットワークとしてレスポンスのつながりが展開され、閲覧者は自分が興味のある方向へと話題の流れを追っていく。仕組みは（たぶん）面白いけれども恐ろしく可読性が低そうなBBS。

ただ、面倒くさそう（3次元表現を駆使するためには結構巨大なJavaScriptライブラリを作らなきゃいけなくなる）な割には、実用度が低くて一発ネタにしかならなそうなんで、実際には作らなかったんだけど、これをSNSでやると結構良さそうに思える。というのは、実用性・可読性の低さがSNS的なネットワークのつながりを表現するのに、ほどよい不自由さとなってくれそうだから。

思い通りに操作できて思った通りの結果が出てくるものは、実用性は高いけれども遊べる余地は少ない。ほどよい揺らぎや予想外の動作があってこそ、面白みが増す（って、はてなダイアリーのキーワードについて語っているみたいだな）。上記のようなインターフェースでつながりを表現することによって、きっちり正規化されたまともなデータベースを使っていても、ユーザーインターフェースのレベルで揺らぎや予想外の動作が発生してくれて、面白いことがおきそうな気がする。

「人」と「枝」と「物」という三つのエレメントから構成するといいかなー。「人」は参加者自身。「物」は参加者以外のあらゆる事物人。「枝」は、「人」と「物」、「物」と「物」とを結ぶ接続方法。「枝」はある程度種類を絞っておいた方がわかりやすいかな。「好き」「嫌い」「持っている」「興味がある」「賛成」「反対」とか。「人」と「物」のつながりはともかく、「物」と「物」のつながりをどう管理するかが肝になるな。「物」には「クラス」と「インスタンス」があって……とかまでやり始めると無限に仕様がでかくなってしまいそうだ。

なんてことを今はやっている場合じゃないのですよ。現実逃避は筆が進む。

_ TypeKey微妙だなー (22:37)

TypeKeyをちょっといじってみたんだけど、これって本当に大丈夫なんだろうか？　まだベータ版程度の出来なのかな？　正常系は動作するみたいだけど、異状系の処理とかセキュリティ関連のポリシーに不安を感じる。ってだけ書くとFUDって言われちゃうかな。一応俺の環境で起こった例を挙げておこう。

MT3.01D-jaで構築したサイトで、コメント設定をTypeKey（＋メールアドレス通知）必須にしておく（TypeKeyなしの場合は管理者チェック付きで許可）。んで、適当なページからTypeKeyのサインインに飛んで認証しにいく。メールアドレス通知が必要だといわれるけれども、「メールアドレスを通知しない」を選択して認証する。すると、認証失敗が返るんだけど、コメント投稿フォームのメールアドレス欄になにやら怪しげな16進数文字列が入っている。実害はないが気持ち悪い。

さらに、その状態で元のページに戻ると、なぜかTypeKeyの認証が通っていて、コメントが投稿できるようになっている。どうやらメールアドレスを通知しないを選んだにも関わらず、メールアドレスが通知されてしまっているらしい。その状態でコメントを投稿すると、ちゃんとコメント者のメールアドレス欄が埋まっている。

まあメールアドレスの通知・非通知は個人的には大して重要ではない部分だし、どうせTypeKeyの個人情報リンク先にメールアドレスが表示されちゃうことを考えれば、メールアドレスの通知・非通知という選択自体あまり意味がない気がするんだけど、ちゃんと動いていないっぽい雰囲気が気になる。試しにtDiaryにTypeKey認証をつけてみようかと思っていたんだけど、こんなんだと出だしからやる気がそがれるなー。