トップ «前の日記(2004-01-13) 最新 次の日記(2004-01-15)» 編集

2002|01|02|03|04|05|06|07|08|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|02|03|04|07|

2004-01-14 [長年日記]

_ CNET Japanリニューアルしました&ごめなさいx2 from Kotaro Yamagishi's bJournal - 山岸広太郎のBlog(ブログ)(2)

今回、CNET JapanではSPAM TrackBack対策としてTrackBackで指定されるURLとPingを打ってきたサーバーのアドレスが一致するかどうかを確認し、違う場合はTrackBackを受けない仕様にしました。

という対策をしているんだそうな。なるほど、URLから解決したサーバー名と送信元アドレスを比較してみるってのは、確かにTrackBack SPAMはじきの手段としては、そこそこ有効そうだ。

もちろん今回のようにPing代行サーバーが別途存在する場合(PingProxyなんかもそうだし)とか、あるいはIPベースで複数ドメインを運用しているサーバーなんかからのPingも弾かれてしまう可能性があるけど、そのリスクよりは「あるサーバーから複数サーバーに置かれたURLを大量宣伝するTrackBack SPAMを弾ける」というメリットの方が大きそうだしな。DNSを引くコストで実装できるし。

_ ゲストブックとRURIコードによるアクセス制御

あたりから、アクセス制御の単位を「ケータイのメモリーに登録されているかどうか」に模しているところからインスパイアされたネタ。

いわゆるゲストブックという仕組みとRURIコード(ランダムCookie ID)によるアクセス制御の仕組みを組み合わせれば、かなり妥当なアクセス制御が実装できそうだ。

アクセス制御レベルは4段階。まずは「PUBLIC」=完全に一般公開。アクセス制御なし。続いて「GUEST」=ゲストブックに書き込んでくれた人。そして「FRIEND」=ゲストブックに書き込んでくれた人の中から管理者が選択した人。そして「ADMINISTRATOR」。管理者自身。

サイトにアクセスするとユーザー(ブラウザCookie)には自動的にユニークなRURIコードが割り振られる。ゲストブックに書き込む際には、その書き込みにRURIコードが付随する。ゲストブックに書き込んだ人のRURIコードは、自動的にGUESTグループとして追加される。

ゲストブックを管理者モードで開くと、各書き込みごとに「FRIEND」に昇格させるかどうかのチェックボックスが用意される。FRIENDに登録したい人を選んでPOSTすることによって、その書き込み者のRURIコードは、FRIENDグループに追加される。

管理者のRURIコードは別途「ADMINISTRATOR」グループに登録しておく。管理ツールへのアクセス制御や、下書き(ドラフト)機能、自分専用の非公開メモ機能に活用する。

記事を書くときには、その記事単位に「PUBLIC」「GUEST」「FRIEND」「ADMINISTRATOR」というアクセスレベルを設定しておく。PUBLIC設定の記事は、誰が閲覧したときにでも表示される。それ以外のアクセスレベルの記事は、各グループに所属している人が閲覧したときのみ表示される。

アクセスレベルをもっと細かくしたり(ゲストブックの管理者モードからの選択肢をドロップダウンにするとか)、あるいはアクセスレベルの設定単位を記事単位でなく段落単位にしたり(<FRIEND>〜</FRIEND>みたいな独自タグで囲んだりとか)、いろいろカスタマイズしようはあるけれども、あんまり細かくするよりはシンプルにしておいた方がよさそう。

ゲストブックの公開・非公開は選択できた方がいいかもね。非公開にしておくとケータイのメモリーっぽい感じになるし、公開にする場合はどうせならばFOAFとかの汎用フォーマットで公開するとさらに活用しがいが出そうだ。

とか、仕事が忙しいときって現実逃避の筆が進むよなー。上記みたいなものを作るのは難しくないから、隙を見てちゃらっとプロトタイプを作ってみよう。

_ 【特集】Efficeon大研究 〜新しくなったCMSを徹底チェック from MYCOM PC WEB (13:51)

今まで見た中では一番詳しいTransmeta系CPU(Crusoe、Efficeon)のソフトウェア的解析記事だ。さまざまなコードを実行するのにかかったクロック数をCPUレベルで計測することによって、CMS(コードモーフィングソフトウェア)がどんなことをやっていて、どういう効果を発揮しているのかを見てみようというもの。

こんなに癖が強いとは思っていなかったなー。これくらい癖が強いとなると、もっさりと評判だったCrusoeですら、あらかじめ最適化したコードを書いたり専用コンパイラでコンパイルすれば、もっといいパフォーマンスが出たのかも。というか、もっとシェアが取れていればそういうのが出せたのかも。ってのはまさしく、卵が先か鶏が先か。