2002-02-07
_ デリカの意味
雪印関連のニュースでよく「デリカ」って出てくるけど、その意味は何だろうと調べてみたら、「デリカ」＝「デリカテッセン」の省略＝「店頭で買ってすぐに食べられるハムのような調製済み食品のこと」、あるいはそれから転じて「洋風総菜一般のこと」（日本のみの表現）なんだそうな。で、車の方の（三菱）デリカは「delivery car」の省略形で全然意味が違った。
_ 今日も走ったのです
三日坊主の壁突破。しかも、メモリスティックを買ったんで、with 音楽で走れるようになった。MGメモリスティック128Mの元を取るためには、せめてあと一ヶ月くらいは続けたいところだね。
_ 「【PalmSource 2002 Vol.1】PalmSource開幕――ソニーが開発中の折り畳み型CLIEを披露」
PalmSourceがらみの記事のどれを見ても、Palmの今後についていまいちっぽさが漂っている中、唯一希望を持てたのは、新型CLIEの披露によってまだソニーがPalmにそれなりの開発力を注いでいるらしいと見えたことくらいか。ひとまずあの開発サンプルを見たんで、Pocket PC方面に行くのを一、二ヶ月は我慢できそうだな。たった一、二ヶ月じゃ足りないかもしれないけど。
_ 「Frentzen confirmed at Arrows for 2002!」
正式発表されちゃいました。今のアロウズ＋フレンツェンって組み合わせはそれなりに面白そうではあるけれども、それよりもフェルスタッペンはこのままF1からさよならになっちゃうのかなー。テストドライバーのあてとかあったっけ？
_ 一息
ひとまず目先に締め切りが迫った切実なやつら二つのめどがついたかな。まだどっちも細かい検証が残っているし、どっちもその部分が特にややこしいやつらなんだけど。そういや、仮納品の状態で止めてあるものもあと三つほど残っていたなー。来月から出先で仕事月間が始まっちゃいそうだから、それも今月中に片をつけておかないと。でも今日はもう帰ろう。
_ 強くてかわいい
いつものようにつけっぱなしのカートゥーンネットワークで、パワーパフガールズが流れていた。キャッチフレーズは、「強くてかわいい生理の味方」。血が垂れそうになったら下で押さえてくれるんでしょうか？ って、「強くてかわいい正義の味方」ですね……。
_ 「ヤフー、“Yahoo！メッセンジャー”をEZweb対応に」
インスタントメッセージ系のソフトが携帯に載るといいなーとは前から思っていたんだけど、こういう形だったら載せる必要はない。っつーか、こんなのインスタントメッセージじゃないじゃん。単なるwebチャットじゃん。自分からメッセージをチェックしに行かなきゃ受信できないようなものを、メッセンジャーって名前にするんじゃねーよ。
_ 「番組を削ってコマーシャルを増やす『タイムマシン』誕生」
以前は白黒だった映画に人工的に色をつけたりする行為ほど悪質ではないとヘンダーショット社長は主張している。
そういや一昔前、モノクロ映画に色を付けてカラーにするのって流行ったよね。ヒッチコックものとか、やたらとカラー化してテレビ放映していた気がする。でももう最近はああいうのはさっぱり見かけなくなったな。って、この記事の本筋とは関係ない話だけど。
2003-02-07
_ PostgreSQLのデータ復旧 (20:11)
PostgreSQL（バージョン6.x）をしばらく運用しているとlogファイルが巨大になってくる。logファイルなんだから消してもいいだろうと、適当にmvしたりする人がまれにいる。が、PostgreSQLのlogファイルは人間が目で見るためのテキストlogファイルではなく、PostgreSQLの動作に必要なバイナリファイルであり、それを消すとPostgreSQLがまともに動かなくなる。
という状態になってしまったデータを復旧させてくれないかと頼まれていろいろ調べてみた。
PostgreSQLはupdateなどでデータを書き換える際に、実際にデータを書き換えるのではなく、既存のデータに無効フラグを立てて見えなくしつつ、新規に新しい内容のデータ領域を作成してそちらを有効にする。updateをかければかけるほどデータ領域はひたすら増え続けていく。そのため、定期的なvacuumを行って不必要なデータ領域を削除したりする必要がある。
PostgreSQLではすべてのSQLコマンドはトランザクションで囲まれているものと見なされる。明示的にbegin;commit;で囲まれていないSQLコマンドも、内部的にはその前後がbegin;commit;で囲まれているものとして処理する。そして、すべての処理は32ビット連番のトランザクションIDが割り当てられている。ある処理で変更があったデータには、その処理のトランザクションIDが記録される。
先ほどの「書き換えられたデータに無効なフラグを立てる」という処理には、このトランザクションIDが関わっているようだ。ある行の内容を書き換えた場合、その行には古いデータと新しいデータの二つが存在することになる。それぞれには、そのデータが生成された処理のトランザクションIDが記録されている。現在のトランザクションIDと比較して、より現在のIDに近いトランザクションIDをもつデータが、その行の最新のデータとなる。
logファイルはどうやらトランザクションを管理するデータらしい。logファイルを削除するとトランザクションIDがリセットされてしまう。実データは別ファイル（baseディレクトリ以下）に記録されており、logファイルがおかしくなってもそちらは影響を受けない。しかし、トランザクションIDがリセットされると、実データファイル側に記録されているトランザクションIDとの間に矛盾が生じるため、データが見えなくなってしまう。たとえばトランザクションIDが1000の状態で記録されたデータは、トランザクションIDが100の状態では見えない。
そのようになったデータを再び見えるようにするためには、現在のトランザクションIDを、実データファイルに記録されている最新のトランザクションIDよりも大きくしてやればいい。トランザクションIDを直接操作する方法は見つけられなかったが、SQLコマンドを1回発行すれば現在のトランザクションIDが1増えるので、特に意味のないSQLコマンドを必要な回数だけ発行してやればトランザクションIDを増やすことができる。
データに記録されている最新のトランザクションIDを知る方法も見つけられなかった。もしもDBの利用頻度が分かっているのならば、たとえば「1日の平均トランザクション数×運用日数」などでトランザクション数を予想して、その回数分SQLコマンドを発行してやればいい。利用頻度が分からない場合は、oidを使ってトランザクションIDが最新に追いついたかどうかを類推する方法がある。
害がなさそうな適当なテーブルに対して、1行新しい行を作成し、その行のoidを見る。トランザクションIDはリセットされても、oidはリセットされないようなので、oidはリセットされる前の最新のoidよりも新しいものが割り当てられる。その値を基準として使うことになる。
トランザクションIDを進めていくと、少しずつデータが復旧していく（古いトランザクションIDをもつデータから見えるようになってくる）。そこで既存テーブルの中で新規行の作成が頻繁であったと思われるテーブルのもっとも大きなoidをチェックする。データが復旧していくとそのoidの値が大きくなっていく。その値が先ほど得た基準となるoidの値に限りなく近くなる＝データが元の状態に復旧した、ということになる。
トランザクションIDがリセットされると、システム管理テーブルの内容も見えなくなるので、テーブルのスキーマ情報なども得られなくなる。が、トランザクションIDを進めていくことで、システム管理テーブルの内容も回復し、スキーマ情報も得られるようになる。ただし、sequenceやindexなどのデータは完全に回復できないこともあるようだ。それらはスキーマと実データを使って、再生成・設定すればいいだろう。
私の場合は「select 1;」を100万回実行するたびに、oidをチェックし、対象テーブルの最新oidが増えなくなってからさらに念のため200万回ぶんトランザクションIDを進めた辺りで、だいたい元のデータが復旧したと判断した。そのあたりの判断はDBの設計によって異なるだろう。
_ 書評リンクの話 (20:11)
あちこちでやっていてポイントを抑えてリンク張るのが難しいんで、興味がある方は上記からあちこちたどってみてください。
で、俺の場合は、「さまざまな個人Webサイトにおける各自ばらばらな行動の中から、ある一定のベクトルをもつデータを抽出して整理して見せること」一般に対して興味があって、そういうベクトルの一つとしての「書評リンク」に興味があるという立場なんで、この手の話をしようとすると話が発散する方向に向かう可能性が高い。風呂敷がでかくなりすぎるというか。という言い訳をしてから話をはじめてみる。
まずは、個人Webサイトにおけるさまざまな情報を、Webサイト同士でやりとりするための、RSSみたいなXMLベースの汎用データフォーマットを決める。んでもって、主だったWeb日記システムやコンテンツ管理システムが、そのフォーマットのデータを自動的に生成できるようにする。
それから、Webサイト間でそのデータをやりとりするためのインターフェース仕様を決める。できればシンプルな（実装しやすい）ものから、汎用性・機能性の高い（けどちょっと実装が面倒な）ものまで数パターンあるといい。あと、インターフェースの起動方法も複数用意しておいた方がいい。個人Webサイト側から送信するパターンとか、集約サーバー側からデータを引っ張ってくるパターンとか。起動に人間が必要なパターンと、必要ないパターンのどちらも用意しておいた方がいい。
そのあたりはアンテナ（サイト更新情報リンク）文化のやり方とかblog系システムのやり方を参考にすると良さそう。アンテナ文化ではLIRSとかDIとかみたいな、個人Webサイトで生成したデータを他のサイトで二次利用するという仕組みを実践的に使ってきている。あと、MovableTypeにおけるTrackBackを使ったサイト間をまたがったやりとりの仕組みとか、RSSを使ったデータ配信の仕組みとかが参考になる。
あんまり深く考えずに適当な仕様を試しに書いてみると、たとえば各個人Webサイトでは、書評を書いたら、各Web日記システムなどが以下のようなフォーマットのデータもはき出せるようにしておく。
<?xml version="1.0" encoding="utf-8" ?> <bookreview> <site> <title>ishinao.net</title> <url>http://ishinao.net/</url> </site> <item> <updt>2003-01-20 23:54</updt> <isbn>4150306931</isbn> <title>ムジカ・マキーナ</title> <author>高野史緒</author> <comment></comment> <url>http://ishinao.net/WikiLike/?sid=147</url> </item> </bookreview>
このあたりの項目に関しては、必須項目とオプショナル項目をいろいろ設定しておいて、あったらそれをちゃんと使うし、なくてもそれなりに扱えるようにしておくといい。上記は書評関連しか考えてないけど、本当はベースとなる汎用フォーマットを決めて、その上にジャンルごとの拡張フォーマットが乗ってくるようにするときれいだろう。
んでもって、それをどこかの書評リンクサイトに送信するインターフェースを用意する。実際にやりはじめると認証とかいろいろ絡んでくるけれども、ひとまず情報を受け渡すだけなら簡単だ。個人Webサイト側からPOSTしてもいいし、個人Webサイト側からはこういう情報を得るためのURLだけを渡してやって、実際のデータは書評リンクサイト側から引っ張っていってもいい。
あ、Web日記システムを使っていない人向けに、集約サイト側の方で普通のフォームから必要な情報をその場で入力してPOSTするようなインターフェースも用意しておいた方がいいだろうね。
書評リンクサイト側の内部では、受け取ったデータをどういう形式で保存管理しても構わない。けれども、書評リンクサイト側でも必ず同様の形式でデータを出力できるようにしておく。んでもって、各個人サイト側からの要求に応じて、必要なデータを個人サイト側にも返してやると、個人Webサイト側で他のサイトのデータを再利用することも可能になる。ってのはあくまでもデータの二次利用性を高めるための仕組みであって、もっともメインとなるのは書評リンクサイト上でそこに集約されている情報を見せるリンク集ページ部分だろう。
んでもって、書評リンクサイト上に集約された情報に含まれるキーワード（＝ISBNもしくは著者名もしくは作品名）をベースにしたコミュニケーションツール（それがWikiであってもBBSであって構わない）とかを用意すると「はてなダイアリー的なものをグローバルに（http://d.hatena.ne.jp/ishinao/?date=20030203#p1）」な感じになってくる。書評に限らずノンジャンルで情報を集約するようにすればそのままはてなダイアリーっぽいし、各ジャンルごとにさまざまな集約サーバーを立てて独自の文化圏を作っていっても面白そうだ。
ってな感じのものを（ひとまず動くように）作るのはそんなに難しくないけれども、将来性のあるまともな仕様を決めたりとか、各Web日記システム用のプラグインを作ったりとか、参加者を集めたりとか、本気でやろうとすると結構大変そうだね。いろんな言語用のサンプルコードを書いたりとかも必要だし、まじめに集約サーバーを運用するとなるとお金の心配とかもしないといけないし。
2004-02-07
_ Bulkfeeds: Similarity Search リリース from blog.bulknews.net (13:51)
- Bulkfeeds: Similarity Search リリース - http://blog.bulknews.net/mt/archives/000763.html
>>Bulkfeeds で「似たBlog記事を検索」する Similarity Search をリリースしました。
「そのうち遊ぼう」用メモ。単に使うだけなら記事ごとにリンクを張るなり、JavaScript呼び出しを埋め込めばいいんだろうけど、せっかくならばRSSで取得してこっちでいじって遊びたい。たとえば、うちの最近の記事一通りに対して、似た記事をRSS経由で取得して、スコアでソートして、動的にサイト単位での「関連記事一覧」を作り出したりとか。って思ったらRSSでは各記事のスコア（類似度）はとれないのか。まあ単純に各記事のTrackBack/コメントに混ぜて表示する（関連記事一覧という意味は同じだから）ってのもありかな。
_ はてなダイアリーキーワード自動リンクAPI from はてなダイアリー日記 (13:51)
2004/2/24
- 続Re:はてなダイアリーキーワード自動リンクAPI - http://d.hatena.ne.jp/uno/20040222#p3
現在の先っちょはunoさんの上記版らしい。全然追随できてないんだけど、そのうち試そう。
2004/2/7
- はてなダイアリーキーワード自動リンクAPI - http://d.hatena.ne.jp/hatenadiary/20040205#1075960162
>>はてなダイアリー外のアプリケーションにおいて、はてなダイアリー内と同じく、キーワードの自動リンクを可能とするためのAPIを試験公開しました。
これも「そのうち遊ぶ」用メモ。これも単に記事単位でヒットしたキーワードへのリンクを並べるだけなら簡単なんだよな。うちの場合はすでに自前のキーワードリンクを持っているんで、記事内にはてなキーワードへのリンクを埋め込むってのはしないけど。
ただ個人的には、Perl用正規表現の形式での配布よりも、純粋にキーワード一覧として（正規表現用エスケープなし＋改行区切りとかで）配布してもらえた方がうれしいな。その方が使い道の幅が広がりそうだし、自分でそれを正規表現用文字列に加工するのは簡単だし。
2004/2/17
むぅ。なんか思ったより手軽に遊べない。俺のローカルPHP環境ではこの巨大な正規表現の固まりは直接コンパイルできない（preg_**関数レベルでメモリ不足になるっぽい）でやんの。しょうがないから、適当に（特殊なキーワードを登録されたら通らなくなるけどまあいいか）キーワード単位でばらしてから利用することに。あと、短すぎるキーワードは嫌いなんで、ついでに指定文字数（デフォルトはマルチバイト含めて3文字）より短いキーワードは無視。とやってもまだすげー時間がかかるよ。ここのシステム上に組み込もうと思ってたけど、単語単位でばらし終わった後の正規表現のマッチングだけで10秒以上かかるとなると、とてもオンラインで実行する気になれないなー。新しいキーワードの取り込みから始めると余裕で1分近くかかるし。もっと高速化する姑息な手段を考えるか、それとも遅くても使えるような使い道を考えるか。
以下サンプルコード。使いたい人はもうちょっと確実度が高いように（エラーハンドリングとか排他制御とか）自力で改造して使うが吉。最近よくはてな関連落ちてるしね。
$hkw =& new CHatenaKeyword();
$url = 'http://mylog.ishinao.net/';
$results = $hkw->getMatchedList(file_get_contents($url));
foreach ($results as $keyword) {
echo '[<a href="http://d.hatena.ne.jp/keyword/'.urlencode($keyword).'">';
echo htmlspecialchars($keyword);
echo '</a>]';
}
class CHatenaKeyword {
var $_cacheFile;
var $_keywordUrl;
var $_cacheTime;
var $_rawKeyword;
var $_keywords;
var $_sizeLimit;
function CHatenaKeyword() {
$this->_cacheFile = 'keywordlist.txt';
$this->_keywordUrl = 'http://d.hatena.ne.jp/images/keyword/keywordlist';
$this->_cacheTime = 60*60*24;
$this->_sizeLimit = 3;
if (!$this->_loadKeywordList()) {
$this->_loadNewKeyword();
$this->_saveKeywordList();
}
}
function _loadNewKeyword() {
$this->_keywordText = file_get_contents($this->_keywordUrl);
$this->_splitKeywordText();
}
function _saveKeywordList() {
$fp = fopen($this->_cacheFile, 'w') or die;
fwrite($fp, serialize($this->_keywords));
fclose($fp);
}
function _loadKeywordList() {
$fileinfo = stat($this->_cacheFile);
if (time() - $fileinfo['mtime'] > $this->_cacheTime) {return false;}
$this->_keywords = unserialize(file_get_contents($this->_cacheFile));
return true;
}
function getMatchedList($text) {
$results = array();
foreach ($this->_keywords as $pattern) {
if (preg_match($pattern, $text, $matches)) {
$results[] = $matches[0];
}
}
return $results;
}
function _splitKeywordText() {
$this->_keywords = array();
$keywordText = preg_replace('/([^\\\])\|/', "$1\n", $this->_keywordText);
foreach (split("\n", $keywordText) as $keyword) {
if ($this->_sizeLimit != 0) {
$str = str_replace('\s', ' ', $keyword);
$str = str_replace('\\', '', $str);
if (mb_strlen($str) < $this->_sizeLimit) {continue;}
}
$this->_keywords[] = '/'.$keyword.'/';
}
}
}
2004/2/17 その2
チェックしたいテキストを入れて「はてなキーワード抽出」すると、そのテキストに含まれるキーワードリンクを表示してくれる。高速化のために文字数制限を4文字にした。
2004/2/19
- はてなダイアリーキーワード自動リンクAPI用PHPコード高速化 - http://d.hatena.ne.jp/nazoking/20040218#1077115772
- Magical Logic : HatenaTokenizer - http://nazoking.s31.xrea.com:8080/k/HatenaTokenizer
高速化版がでましたよ。このくらい速ければいろんな用途に使えそう。
※うが、なんか俺の環境では動かないな。コードを読まなきゃだめか。
_ リンクの拒否権 (13:51)
2004/2/8
「ゲストブック認証＋閲覧者数制限によるアクセス制御」へのネタ振りとして4年前の文章を再掲載しただけなのに、こっちの方にばかりアクセスが集中する（via 個人ニュースサイト系）のはなんかいやだなー。あくまでもこれは、4年前の段階での考察なんですからね、一応。まあ「ゲストブック認証＋閲覧者数制限によるアクセス制御」は技術論なんで技術者以外は楽しくないかもしれないけど。
2004/2/7
最近いろいろ話題になったネタについて、4年前に書いた（http://ishinao.net/ruins/text/01.htm#20001025224346）文章を発見したので、こっちにも転載しておこう。これからさらにいろいろ考察は進んでいるんだけど、核となる部分はこの文章にだいたい含まれているので。以下転載。
2000/1/7
リンクに拒否権はあるのか，あるいは拒否権というものが必要なのか？
リンクを拒否したいと考える人は，リンクされることによって自らに不利益を被る可能性を，拒否したいのだろう。自分にとって好意的な言及とともにリンクされるのはかまわないが，自分に対して批判的だったり悪意を持った言及を伴ったリンクはされたくない，という話だ。
確かに，リンクされることによって不利益を被る場合はあり得る。自分（の書いた文章）に対するネガティブなコメントとともにリンクされることによって，Web社会（ってのも曖昧な言葉だが）上に自分の悪評が広まるかもしれない（もちろんその批判があまりにも的はずれな場合は，リンクをした方の悪評が広まるだろう）。
これはたいていの場合，そのような批判されうる文章を書いたことに対する真っ当なつけを払わされている（という表現はあまりにもネガティブか。「発言の責任をとる」と読み替えても可）だけのようにも思える。
しかし，もしかしたら先入観無しで読んだ場合は特に問題のない文章でも，ネガティブなコメントという意識誘導を伴うことにより，本来よりも不当な悪評を生じうるかもしれない（仲間意識ってものが目の鱗となり理屈をねじ曲げてしまうことは，世の中珍しくない）。
また，自分にネガティブな印象を持った人間のアクセスが増えることによって，掲示板やメールなどで自分を攻撃する人間が増える，という不利益もあり得る。
これも基本的には自業自得の範囲内の出来事ではあるが，作者本人にとって不利益であることは間違いないし，先ほど挙げた意識誘導によって，本来の賛否両論バランス以上に不当な攻撃が増える可能性もあり得ることを考えると，そうそう自業自得とばかりは言っていられない。
しかし，不利益を被る可能性があるからという理由だけで，リンクを拒否できるものなのだろうか？
Webに限らず一般的な著作物（と言った場合，主に一般に流通する出版物を念頭においている）は，著作権法によって守られている。一般的な著作物の引用においてもWeb上のコメント付きリンク同様に，著作者が不利益を被る可能性はありうる。その不利益の内容もほとんど同じだろう。
一般的な著作物においては著作権法によって，第三者による引用が権利として認められている。「公正な慣行に合致するものであり、かつ、報道、批評、研究その他の引用の目的上正当な範囲内で行われるもの」であるならば，権利者の許諾なしで引用することが可能だ。ただし「著作物の出所を、明示しなければならない」という義務がある。
Webにおけるリンクは，引用の延長として考えることができる。「その出所を明示する」という条件は，もちろんリンク先のURLが明記されているので問題ない。「引用の目的上正当な範囲」というのは，要するに引用文が主であってはならない（引用文が主ならば，それは言及のための引用ではなく，ただの複製（コピー）になってしまう）ということだ。コメント付きリンクの場合は「引用文がゼロである引用」と考えることができる。Webでは引用元の参照が簡単にできるため，引用文を完全に省略することが可能なわけだ。
と考えると，一般的な著作物において第三者による無許可の引用が認められているのと同様に，Web上での第三者による無許可の引用と，その延長にある無断リンクは著作権法的に認められるものと考えられる。
だとすると，多少の不利益を被る可能性があるからといって，著作権法に明記された権利を制限していいものとも思えない。
発言する権利の裏にはその発言に対する批判を受ける義務が生じるのであり，自分の快不快の問題で義務を放棄するのは無責任すぎるのではないだろうか。
ただし，上記の議論はWeb上に公開された著作物を，一般的に「公表された著作物」とまったく同様に扱うという前提の上に成立している。では，その前提が本当に成立するのだろうか。
「Web上に公開された著作物は，一般的な著作物と同様に扱われるべきだ」とする人の主張は，おそらく「世間一般に公開されるWebというメディア上に自分の意志で掲載したのだから」という，発表メディアの機能から逆引き的にその一般性の根拠を見つけだしているのだと思われる。
わたしも基本的には同感なのだが，いくつかの異論も持ち合わせている。その第一としてあげられるのは，「掲載した人間の意図として，どこまで一般的な著作物として発表したかどうか」の問題だ。
Web上に公開された著作物は，他の一般的な著作物よりも，非常に手軽で私的な著作物であることが多い。多くの個人Webページは，著作者一人の手で執筆・編集・出版がなされている。またその制作にかかる日数も非常に短い。
Webにおける著作物は，世間一般に公開されるWebというメディアの一般性の強さに比べて，その制作に関してはあまりにも私的個人的な部分が大きい。
また，制作者による仮想読者の設定に関しても，おそらくは非常に狭い範囲を想定している場合が多いだろう。また実際問題として，その読者数は多くの場合ほかの一般的な著作物よりも非常に少ない。
第三者によるチェックを受けることなく，ごく個人的な作業によって制作・発表され，それをごく少数の人間が見る。そして作者本人が，そういうものだという前提で制作している。それがたまたま一般性の高いメディアに掲載されたからといって，世間一般に発表されたと言い切っていいのだろうか。
たまたま一般性の高いWebというメディアを使っているが，その読者対象としてはごくごく身内の人間だけを対象にしているつもりの，作者本人は一般性を意識していないWebページというものは少なくない。そのようなWebページをも，まったく一般的な著作物と同様に扱っていいのだろうか。
そのような私的な著作物は，一般に公開されるWebというメディアに掲載するな，という反論はあるだろう。
しかし，Webというメディアはある程度人数の多い内輪の話をするには，とても便利なメディアだ。それよりも便利なメディアが見あたらないのだったら，Webを内輪の話をする目的で使うのはありだろう。
ならば，アクセス制限などでロックをかけろ，という人もいる。
しかし，Webに著作物を掲載するだけならば，その技術的な敷居は非常に低くなっているが，それにアクセス制限をかけるという技術的な敷居はまだまだ高い。手軽で便利だからという理由でWebを使っている人ならばなおさら，アクセス制限という技術を身につけるのは難しいだろう。
この議論について考える場合，わたしは道ばたで会話している人とその周囲を通り過ぎる人の光景を思い浮かべてしまう。
道ばたで会話している人たちは，周囲の人にも聞こえるような声で話している。別に周囲に聞かせたいわけではないが，お互いにしか聞こえないような小さな声で会話をするよりも，周囲にも聞こえる程度の大きな声で話した方が手軽だからだ。
しかし，話している内容がそばにいれば聞こえるからといって，わざわざ聞き耳を立てている人がいる。そして，会話の途中で気に入らない内容があったからといって，突然会話に割り込んで文句を付けはじめる。
よほど犯罪性のあるような問題のある発言をしていたのだったら，まあそれもありだとは思う。しかし，多少問題があったとしても聞き流しておくのが，ふつうの対応だろう。
とはいうものの，やはりわたしは，基本的にはWebは公開されているメディアであるので，そこに著作物を掲載する場合はその著作物に対する批判を受ける義務が生じる，という立場を取る。
そのあたりは，田舎と都会の違いのようなものだ。
田舎では家の鍵などいつでも開けっぱなしにしており，身内の深い話なんかもご近所で簡単にしゃべってしまったりする。一方都会では，基本的に親しい人間以外は信じない方がいい。ちょっと外に出るときにも家にはきっちり鍵をかけないといけないし，人が訪ねてきても簡単にドアを開けてはいけない。身内の話を外部に漏らしたら，それを悪用されるリスクを考えなければならない。
究極を突き詰めれば都会の方が正しいのだろう。しかし，多少いい加減でもそれなりにやっていける田舎の生活は，実際問題としてそういうコミュニティとして成立しているのだから，それはそれで問題ない。
ただし，田舎の生活もいずれは都会のように変わっていくものだ。どんな田舎に行っても家には鍵がかかっており，訪ねてきた人を簡単にドアを開けて迎え入れるということがなくなるときが，いつかはやってくる。
それならば，現状は現状として容認しつつも，将来のための心構えは啓蒙しておいたほうがいい。
蛇足だが，Webの今後の発展を考えると，パブリックなWebページとプライベートなWebページを簡単に使い分けることができるインフラを整えていく必要があるだろう。現在実現可能なアクセス制限のような不便な仕様ではなく，もっと洗練されたアクセス制限の手法を考え出したら，一財産築けるかもしれない。
追記） 一行コメント付きメールで「リンクの拒否権とアクセス制限の問題をプライバシーの観点から考えています。公開する方向と範囲をコントロールしたいという欲求があるのではないかと思っています。」というコメントをいただいた。
「公開する方向と範囲をコントロールするためのアクセス制限」というのは面白いテーマだ。プライバシーについての考察は今回は意図的に省略したのだが，今から考えるとやはり絡めて考えた方が良かったようにも思える。
このネタは，まだまだ考察をする価値があるテーマだ。いずれ続きを書こう。
_ ゲストブック認証＋閲覧者数制限によるアクセス制御 (13:51)
微妙に補足説明を追加してます。
で、「リンクの拒否権」（http://mylog.ishinao.net/id/1129）の最後に出てきた、「パブリックなWebページとプライベートなWebページを簡単に使い分けることができるインフラ」に関する考察を進めてきた結果、「ゲストブックとRURIコードによるアクセス制御」（http://mylog.ishinao.net/id/1096）と「記事ごとに読める人の人数を制限できる仕組み」（すみません。どこで読んだのか忘れてしまいました）を組み合わせた、現在の私が考えつく、もっともバランスのいい匿名のままに認証＆アクセス制御する仕組みについてまとめてみる。
まず、アクセスしてきた閲覧者（ブラウザ）にランダムなIDを振り、Cookieに登録する。次回アクセス以降、CookieにランダムIDが存在した場合はそのIDを利用し、存在しない場合にのみ新しいIDを割り振る。IDは重複することが（論理的に実用時間内には）なく、閲覧者（ブラウザ）を一意に認識するためのIDとして利用できる。+[また十分に複雑なランダム性を持つIDなので、他人のIDを類推することは不可能である。]+そのIDのことを、この考えの元ネタであるHNS（Hyper Nikki System）での呼び方に準じて、ここではRURIコードと呼ぶ。
RURIコードを使うことによって、閲覧者を匿名のままに区別して扱うことが可能になる。閲覧者にID、パスワードの管理や入力という手間をかけさせることがない。ただし、Cookie盗難には十分注意する必要がある。
続いてゲストブック（記名帳）を用意する。ゲストブックとは、閲覧者がサイト管理者に対して、自分が読者であることを表明するための投稿フォームである。ゲストブックへの登録の際には自動的にその閲覧者のRURIコードも記録される。ゲストブックに登録した人（RURIコード）は、「GUESTグループ」に加えられることになる。
またこのゲストブック登録の段階で、メールによる自動認証（登録されたメールアドレスにシステムがワンタイムパスワード付きメールを送信し、そのパスワードによって正当なメールアドレスかを自動確認する）などをシステムに組み込むことができる。そのシステムを適用する場合は、ゲストブックに登録しただけの閲覧者を「弱いGUESTグループ」、その中でメールによる自動認証をすませた閲覧者を「強いGUESTグループ」に加えるなど、2段階のグルーピングを適用することもできる。ただしここではできるだけ話をシンプルにするため、1段階のGUESTグループを適用することにして話を進める。
ゲストブックは原則として管理者にのみ公開される。そこで、そこには管理者以外には知られたくない情報を記述することもできる。たとえば「○○高校で同級生だった○○だよ」みたいに個人情報を含んだ内容も登録でき、それによって管理者はあるRURIコードの持ち主が誰なのかをより正確に判別することができる。当人同士しか知らないはずの情報を含ませるほど、本人確認の厳密さが高まるだろう。
管理者は、ゲストブックに登録した人の中から自分が選んだ人を、「FRIENDグループ」に昇格させることができる。単純にゲストブックの書き込み1件ごとに対して、グループ昇格ボタンなどをクリックするような形だろう。
ここでも実際には、ごくごく親しい知り合い用の「強いFRIENDグループ」、それ以外の知り合い用の「弱いFRIENDグループ」のような複数の段階のグルーピングを行うこともできるが、ここでは話を単純化するために1段階のFRIENDグループを適用することにして話を進める。
以上のグループに含まれていない閲覧者は、「ANONYMOUSグループ」に含まれることとすると、閲覧者は「ANONYMOUS（見知らぬ読者）」、「GUEST（登録読者）」、「FRIEND（知り合い）」という三つのグループに分けられることになる。
ANONYMOUSに関しては完全な自動登録となるし、GUESTに関しては閲覧者のちょっとした作業のみで登録が行われる。FRIENDに関してはさらに管理者のちょっとした作業が必要になるが、規模がよほど大きくない限りはそれほどの手間ではないだろう。といった程度のコストで、閲覧者をそれなりに妥当な権限グループに振り分けることができる。また、この程度ならばそれほど技術に詳しい人でなくても、仕組みを理解することができるだろう。
続いて、このようにグルーピングした閲覧者に対して、どのように認証および制限を加えていくか。
システム自体の設定としては、まず閲覧者からのリアクション機能に関する設定がある。具体的にはコメント機能やメールフォーム機能を、どのグループのユーザーに対して公開するか。ゲストブックにURLも登録されているのならば、そのURLとのマッチングによってTrackBackに対する認証を行うことも可能になる。
比較的内輪向けのサイトならば、コメント機能はFRIENDのみ、メールフォーム機能はGUESTとFRIENDのみ、といった感じになるだろうか。オープンなサイトならば、すべての機能をANONYMOUSにも使わせればいい。
あるいは、許可したグループにのみリアクション機能を使わせるのではなく、他のグループにも投稿だけは許可するが、その内容をサイト上に掲載するかどうかは、管理者が決定できるようにすることもできるだろう。+[いわゆる、管理者がチェックしない限りはWeb上に投稿が掲載されない掲示板システムと同様の仕組みだ。]+
続いて公開範囲および規模の設定を、記事単位で行うことができる。基本的には、どのグループに対して何アクセスまで公開するかを設定することになる。
たとえば内輪向けの記事ならば、FRIENDに対してのみ無制限アクセスを許可（許可アクセス数=-1）し、GUESTやANONYMOUSに対してはアクセスを拒否（許可アクセス数=0）すればいい。その記事は知り合いのみが閲覧することができるようになる。
また、ある程度は一般に公開してもいいが、あまりリアクションが多くなることを恐れるのならば、たとえばGUESTには「許可アクセス数=100」、ANONYMOUSには「許可アクセス数=10」などと設定しておく。すると、GUESTグループに所属する人が100回アクセスすると、それ以降訪れたGUESTグループの人には「現在公開が停止されています」などのアナウンスが表示されるようになる。同じくANONYMOUSグループの人は10アクセスまでしか閲覧することはできない。
ちなみに、このような制限を施している場合は、（システム的に）その説明を明示しておいた方がいいだろう。
「この記事は友達登録を行った人にのみ公開しており、それ以外の方は閲覧できないようになっています。友達登録を行いたい方はゲストブックからご登録ください」
あるいは、
「この記事は100人にまで閲覧を許可しています。それ以上の閲覧者が訪れた場合は自動的に公開が停止されます」
などと提示しておく。それによって、その記事の公開範囲・規模が閲覧者に伝わり、その結果背景にある管理者の意図が、ある程度閲覧者（あるいは閲覧できない人）に伝わることになる。
もちろんこのように閲覧者を制限したところで、誰かがその記事の内容を引用したり転載したりすることによって、ネット上に広まっていってしまうことはある程度はさけられない。しかし、現状の管理者の公開意図がほとんど伝わらないシステムと比べると、ずいぶんとましな状況になるのではないだろうか。
以上の仕様では、特に難度・コストが高い技術は使っていないので、一般的なWeb技術者ならば比較的簡単に実装が可能だろう。また、細部に関しては様々なカスタマイズの余地もあるので、利用するサービスに応じて適切に応用してもいい。
2005-02-07
_ やっぱり故障らしい (12:32)
IEEE1394の6pin to 4pin変換アダプターを買ってきてつないでみたいんだけど、やっぱり認識してくれない。さらに別のPCに別のUSBケーブル（オクサンのiPod miniのやつ）を使って接続してみたんだけど、やっぱり認識してくれない。ということで完全に本体が故障しているっぽいな。
しかも、そうやって試しているうちに、満充電状態から数分でバッテリーのメモリがふたメモリも減りやがったよ。まだ買ってから1ヶ月ちょっとだし、バッテリーがへたるのには早すぎだよね。以前も満充電から3時間くらいでバッテリー残量がゼロになり、それからもう一度再生ボタンを押してみたらバッテリー残量ゼロのまま、3時間くらい再生できたことがあったし。
おかしな症状が出始めたのって、買ってからすぐだったんだけど、結局騙し騙し1ヶ月ちょっと使って来ちゃったから、今から持っていっても初期不良交換はしてくれないだろうなー。修理扱いは面倒くさそうだなー。ちょっと気合いを入れて交渉してみようかなー。
2006-02-07
_ ブログサービスの XSS 脆弱性対策はいらない その2
しかし、いくつかの仕組みを変更すれば、なりすましの回避とスクリプトの利用許可は両立できるはずなのです。
技術的にどういう問題があるのか理解した上でそういう主張をするのならば、それはそれでありだと思う*1。ただ、はてなはもちろん初めからそういう技術的な知識を元に検討を行った上で、現在のシステムデザインを採用しているわけだろうし、「ユーザビリティを下げたら対応できる」的な話は、デザインの好み（どれもそれなりに妥当な選択肢のうちのどれを選ぶか）の問題だからなー*2。
ちなみにCookieを盗難されたくなければ、別にドメインごと換えなくたって、パスで有効範囲を絞ったっていいんで、たとえばドメイン「d.hatena.ne.jp」＋パス「/ishinao/edit」で範囲を絞ったCookieを発効すれば、http://d.hatena.ne.jp/ishinao/edit以下でしか有効でない（XSSで盗難されない）認証を処理したりもできる。ドメインを換えることは必須ではない*3。
このセクションに対するはてなブックマーク
*1 レンタルサーバーとは全然違うんで、それを並立させて比べるのは論外。あと認証盗難がありうる場におけるXSS対策においては、ブラクラとかの話は基本的に関係ない。何もJavaScriptを使わなくてもブラクラを作ったり危険な外部リンクを踏ませたりできるわけだし
*2 ちなみに俺は現在のはてなのシステムデザイン（一つの認証ですべてのサービスが利用できる＝複数サービスを連携した仕組みが作りやすい）の方が、認証範囲を狭く区切り必要に応じていちいちログインするような仕組みよりも、好み。ただ俺ならそういうデザインでユーザーに自由なHTML＋CSS入力を許可しないけど
*3 ドメイン保持者にとって、ドメインCookieというものがセキュリティ的に非常に重要なポイントであることは確かだけど
2007-02-07
_ ガット張り替え
ラケット（YONEX RQS11HG）を買ってから2ヶ月近く経っても、いまだに飛びすぎる状態は解消されないんで、ガットを張り替えてきた。週3〜5ペースで使っているから、そろそろ張り替え時期だろうし。
今までは、YONEXサイバーナノ130を52ポンドで張っていたんだけど、今度はSIGNUM PROポリプラズマ118を58ポンドで張ってみた。まだガットの種類による変化も、張力による変化もどんなもんなのか見当が付かない状態だから、はっきり差が付くように変えてみたんだけど、これでどのくらい飛ばなくなるのかな。
