_ mixiに招待してもらった (13:34)

mixiに招待してもらったんでちょっとだけ触ってみたけど、なんかあんまり好きじゃない感じだなー。システムは結構良さそうだけど、現状の利用のされ方が俺の好みじゃない。

なれ合うならもっと狭く深くなれ合った方がいい。雰囲気しか見てないけど、あの程度の浅いコミュニケーションだったら、わざわざクローズドな場所でやるほどのものでもないと思う。まあmixiを使った深いコミュニケーションは、他人（非友達）には見えないところに隠れてるんだろうけどさ。

個人的な感触（願望）としては、SNSはもっとクローズドな用途でのみ使われるようになって欲しいな。で、ちょっとだけアクセス制御を使いたいけど基本的にオープンでかまわないようなコミュニティは、今までのWikiとか日記とかblogとか掲示板とかに、TypeKeyみたいな外付けシングルサインオンの仕組みを組み合わせて実現する方がいい。

たぶんmixiのアカウントは、単にmixi内のオープンな場所にアクセスする権利としてしか使わない気がする。とかいいつつ、どっぷりmixiにはまって一ヶ月後にはSNSサイコー！とか吠えていたら笑えるな。

_ リファラエディタプラグイン (14:44)

とても便利なんだけど、バグらしきもの発見。その月の日記（というか%Y/%Y%m.tdrファイル）が存在しない状態で、プラグインを呼び出すとエラーが出る。具体的には、10月1日の日記をまだ書かない状態で、9月30日についたREFERER SPAMを削除しようとしたら、編集フォームを表示する前にエラーが出た。

たぶん、refedit_loadの頭にでも、

if File.exist?(path) == false then return {} end

とかつけておけばいいのかな？　もう今月の日記を書いちゃったんで、試すのは来月回し。

_ とおんねーなー (15:34)

ひとまずTypeKeyの動作確認だけやっておこうかと、Authen::TypeKeyを使ってみたはいいけど、リダイレクトして戻ってきたパラメータを、

$q = CGI->new;
$tk = Authen::TypeKey->new;
$res = $tk->verify($q);

とかすると、

TypeKey signature verification failed 

とか言われちゃうんですけど。なんか追加設定しないと使えないんだっけ？

ああそうか

verifyを呼ぶ前に、

$tk->token([TypeKeyトークン文字列]);

を入れないとだめなのね。これもちゃんとドキュメントに載っけておいてくれよ。

これで一応PerlでTypeKeyを使う準備はできたけど、PHPでDSAの署名をverifyするにはどう書けばいいんだろう。PEARにCrypt::DSAがあるかと思って見てみたら、まだなかった。TypeKeyのverifyだけPerlを使って、それ以外はPHPで書こうかなー。

_ TypeKeyクライアントサンプルCGI (21:04)

上記リンク先にアクセスして、loginをクリックすると、TypeKeyの認証ページに飛ぶ。そこでログインするとリダイレクトして戻ってきて、名前、ニックネーム、メールアドレス（通知する場合）が表示される。

#!/usr/bin/perl

use CGI;
use Authen::TypeKey;

print "Content-type: text/html\n\n";
print "<h1>TypeKey test</h1>";

my $q = CGI->new;
my $tk = Authen::TypeKey->new;
$tk->key_cache([公開鍵用キャッシュファイルのパス]);
$tk->token([TypeKeyトークン文字列]);
my $res = $tk->verify($q);

if (!$res) {
  print "LOGIN FAILURE: ".$tk->errstr;
} else {
  my $name = $q->param('name');
  my $nick = $q->param('nick');
  my $email = $q->param('email');

  print 'Your Name: '.$name."<br>";
  print 'Your Nickname: '.$nick."<br>";
  print 'Your Email Address: '.$email.'<br>';

  #以降、$nameと$emailを使って、ローカルの認証を行う
}

ちなみに上記段階は、あくまでもTypeKeyの認証が行われただけの話で、実際に各Webアプリケーション上でそのユーザーにどのような権限を与えるかは、$name（と$email）を使って別途処理する（というか権限データベースを作る）必要がある。あと認証状態の継続（セッション管理）も、自前でやらないといけない。まさかアクションごとにいちいちTypeKeyサーバーにとばすわけにもいかないしね。

これを使ったアクセス制御のパターンとしては、

1. 未認証
2. TypeKey認証済み
3. TypeKey認証済み＋メール通知有り
4. TypeKey認証済み＋ローカルユーザー権限あり

というユーザー権限に対して、それぞれ読み書き権限を振り分けていく感じになるんでしょう。実際には4の段階で、さらに細かい権限設定ができるけど、それはまあ適当に。

そういえば、やっぱり前に書いた微妙な動作はサーバーサイドの挙動に問題があるんだね。

「メールアドレスを通知しない」を選ぶと、最初の1回は確かに仕様通り、メールアドレスとしてSHA1ハッシュを返すんだけど、ブラウザの戻るボタンでTypeKeyの認証ページに戻ると、すでにTypeKeyサーバー上で認証済み（セッション）なんで、ログイン画面なしで自動的にリダイレクトがかかる。で、どうやら認証状態で自動リダイレクトがかかる場合には、無条件でメールアドレスを通知するらしい。

ちゃんと動作させるためには、ユーザー設定で「常時メールアドレスを通知する/しない」とかをつけつつ、後は各サーバーごとにこのセッション中に「する/しない」のどちらを選んだのか覚えておいて、リダイレクト時にはその組み合わせを見ながら、適切に処理する（メールアドレス通知リダイレクト、非通知リダイレクト、メールアドレスを通知するかのみを確認するフォーム表示）感じかなー。

_ おおきく振りかぶって (2)(ひぐち アサ) (01:19)

この本を持っている人にちょっと質問。この本って、カラー折りは先頭じゃなくて、途中に挟まるのが正解だよね？　なんか出だしにカラー折りでホームランシーンがあって、それとは全然つながらずに話が進んでいくんで、演出にしてもなんか変だなーと思ったら、中盤辺りにどう見てもここにホームランシーンが挿入されるはずの場所を発見した。肝心のページ周辺にページ数が書かれていないんだけど、80ページ〜104ページを数えてみたら4ページ飛んでいたし。すげーわかりにくい乱丁だなー。出版社に送って交換してもらうのも面倒くさいけど、Amazonで買った本だから本屋に持っていって直接交換ってわけにもいかないんだよなー。

_ PHPでverify (13:07)

BCMathモジュールは必須かなー。自前で書こうかと思ったんだけど、BCMathオプション付きでPHPをコンパイルしていなかったんで、やる気をなくしてしまった。基本的に、DSAのverifyって大規模整数演算ができれば何とかなるんだよね。

_ アニメがお仕事! 1巻 (1)(石田 敦子) (23:18)

話題になっていたんで買ってみたんだけど、なんかあまり面白くなかった。アニメーター業界裏話的には面白いんだけど、なんだかやけにオチが付かない話の連続で、まあ現実に起きる出来事はきれいにオチが付くものではないんだよ、というテーマでもあるんだったらいいけど、じゃなかったらもうちょっとそれなりにいちいちオチをつけて欲しいなー。

_ 東京物語(奥田 英朗) (23:18)

この手の話は嫌いじゃない。作者を重ね合わせた若者の、青春＆成長物語。田舎から東京に出てきて、都会に圧倒されつつも学生をして、そのうちコピーライターとして下っ端からキャリアを積んでいって、調子に乗ったり叩かれたり反省したりする。時系列は飛び飛びで、数年おきのエピソードが描かれていく。広告業界裏話的な部分もあって、地味に面白かった。

_ 天才柳沢教授の生活 (9)(山下 和美) (23:18)

ようやくコミック文庫の続きが出始めてくれたか。というだけだな。内容はいつも通り。

_ 学校を出よう!〈2〉I‐My‐Me(谷川 流) (23:18)

ちょっとだけ西澤保彦っぽい超能力ミステリー風味。でもまあ西澤保彦ほどミステリーっぽいわけではなく、結局はふつうの超能力ものだね。でも、前作よりもずっと面白かった。あと一応世界観は前作と一緒だし、最後の方で前作のキャラクターもちゃんと出てくるのは、ライトノベルシリーズもののお約束っぽい。

_ バッカーノ!2001―The Children Of Bottle(成田 良悟) (00:00)

このシリーズはファンなんで、もはや何を読んでも面白いんだけど、今回はなんだかちょっとぎくしゃくしている部分が多かった気がする。今回の村の設定が、何となく人狼BBSと重なって……ってのは毒されすぎだな。村長と息子が共有者でした。

_ 燃えよペン(島本 和彦) (00:00)

ずっと読もうかと思いつつも、なんだかずいぶん巻数が進んでしまっていて、ついて行く気力がなくなっていた。んだけど、勢い余って買ってしまった。うん、ふつうに面白い。なんかもう想像したそのまんまではあるんだけど。

_ おおきく振りかぶって (1)(ひぐち アサ) (00:00)

野球マンガはほぼ何でも好きなんだけど、これはその中でもかなり好きな方だな。表紙の絵柄があんまり好きじゃなかったんだけど、中身は別にそんなことなかった。しょぼい球しか投げれず、性格も弱よわのだめピッチャーかと思いきや、珍しい癖球とストライクゾーンを9分割して投げ分けられるコントロール、そしてそのコントロールを一試合継続できる精神力・体力を持っていた……。って感じの話。

_ 学校を出よう!〈3〉The Laughing Bootleg(谷川 流) (00:00)

また第三EMPに話は戻って、密室からの人間消失事件を茉衣子が追う。とかいいつつ、まあ超能力学園ものですから。どたばた超能力学園ものとしてはふつうに面白い。

_ ナイキ製の足袋 (13:32)

親指が分かれてるやつね。雨の日は水が入る。

_ ジョージアのおまけ (13:53)

万歩計らしい。イラストダセェ。

_ Auth-TypeKey (15:47)

ひらたさんがPHP版TypeKeyクライアントクラスAuth-TypeKeyを公開してくださったので、早速テスト。いろいろ適当だけど、細かいことは気にするな。

$result = verify();
if ($result) {
  echo 'Name: '.$_GET['name']."\n";
  echo 'Nickname: '.$_GET['nick']."\n";
  echo 'Email: '.$_GET['email']."\n";
}

function verify() {
  require_once("Auth/TypeKey.php");
  $tk = new Auth_TypeKey(array('version' => '1.1', 'token' => [TypeKey TOKEN文字列]));
  $result = $tk->verifyTypeKey($_GET);
  if (PEAR::isError($result)) {
    die($result->getMessage());
  } else {
    return TRUE;
  }
}

PHPでの大規模整数演算はGMP関数を使うのか。BCMath関数とどっちが一般的なんだろうなー。計算内容からはどちらを使ってもいけそうだけど。この辺の関数って全然使ったことない（インストールオプションとして指定したこともない。今回初めてwith-gmpなんてつけてみた）からさっぱりわからない。GMP関数はWindows環境で使えないっぽいことがマニュアルに書かれているから、BCMathで書けるならばそっちを使うバージョンも作っておいた方がいいのかな。without PEARでBCMathなバージョンもそのうち書いてみよう。

ひとまず適当な掲示板かWikiあたりに組み込んだバージョンを作ってみたいんだけど、今そんなことをやっているばやいじゃないかもしれないかもしれない。あと、Rubyに移植してtDiaryでTypeKeyを使うバージョンもつけてみたいかもしれないかもしれない。

_ 編集にTypeKeyログインが必要なPukiWiki (01:41)

まじめに改造するのがつらいんで必要最低限のみ。まずlib/typekey.incというファイル名で、

function check_typekey() {
  define('TYPEKEY_SESSION_NAME', 'TYPEKEY_SESSION_NAME');
  define('TYPEKEY_TOKEN', 'TYPEKEY_TOKEN');
  define('TYPEKEY_URL', 'https://www.typekey.com/t/typekey/login');

  session_start();

  if (!isset($_SESSION[TYPEKEY_SESSION_NAME])) {
    if (isset($_GET['name'])) {
      require_once("Auth/TypeKey.php");
      $tk = new Auth_TypeKey(array('version' => '1.1', 'token' => TYPEKEY_TOKEN));
      $tk_result = $tk->verifyTypeKey($_GET);
      if (PEAR::isError($tk_result)) {
        die($tk_result->getMessage());
      } else {
        $_SESSION[TYPEKEY_SESSION_NAME] = array(
          'name' => $_GET['name'],
          'nick' => $_GET['nick'],
          'mail' => $_GET['email']
        );
        return TRUE;
      }
    }
  } else {
    return TRUE;
  }
  $tk_url = TYPEKEY_URL.'?&v=1.1&need_email=1&t='.TYPEKEY_TOKEN.
     '&_return='.urlencode('http://'.$_SERVER['HTTP_HOST'].
     $_SERVER['REQUEST_URI'].'&');
  header('Location: '.$tk_url);
  die;
}

　もちろんTokenの設定は自分のものに。あと、自サイトのURLもちゃんとTypeKeyサーバーで登録しておく必要がある。そしてplugin/edit.inc.phpの関数の頭に、

function plugin_edit_action()
{
  require_once LIB_DIR.'typekey.inc';
  check_typekey();

  global $vars, $_title_edit;

　なんて感じのコードを追加。リダイレクトURLを生成しているところの、$_SERVER['HTTP_HOST']は嘘かも。要は元のURLに戻りたいんだけど、どうやるんだっけ？　$_SERVER['SERVER_NAME']は取れなかったんだよな。

　ともかく上記のようにすると、編集リンクをクリックしたらTypeKeyのログイン画面に飛ぶ。ログインに成功すると元のページに戻ってきて、DSAのverifyをして、問題なければセッションにユーザー情報を保存する。以降セッションにユーザー情報が入っていればいちいちリダイレクトしない。

　ユーザー情報はその後全然使っていないけど、本当は編集した人の情報として記録した方がいいんだろう。でもPukiWikiのコードを追う気力がないんでパス。

_ TypeKey SNS (18:22)

今日は隙間を見てTypeKeyを使ったSNS風味のシステムを設計してみたりしているんだけど、これ結構楽しそうだな。SNSというよりは、各人がそれぞれ公開できる情報を持ち寄って、それらの情報を人間をキーにフィルタリングして表示するイメージ。

最初の登録は誰でも（TypeKeyアカウントを作れば）できて、さらに友達登録も誰に対してでも行える。友達登録は公開・非公開の2種類あり、非公開な友達は他人からは見えない。友達というよりは、「私はこの人（の動向）に興味があります」的なイメージ。友達の友達的な関係は、両思いだった場合のみたどっていくようにするといいのかな。その辺はまだノーアイディア。

日記のRSSを登録して、アイテムを時系列でソートして、友達のものだけ選択して表示するってのは、単なるRSSアンテナだな。昔wikistmaniaでやっていたものをまた作るのか。OPMLを出力してbloglinesあたりに突っ込んでくれというのもありかも。

コミュニティ相当のものは、WikiLikeみたいに編集可能なドキュメント＋スレッド掲示板で構成。ドキュメントも掲示板もコミュニティ単位で何個でも作れる。スレッドで議論 or だべって、何らかの成果物的なものができたらドキュメントにまとめるイメージ。それぞれのread/write権限はpublic、user、member、adminで設定可能。コミュニティのadminは作成者がまずadminになって、以降admin権限を持つ者が他のadminを追加する。

ついでにMM/本のメモのDBを使ってレビュー機能も作るか。あのDBにわかりやすいUIをかぶせるだけですみそうだ。というか、MMで本（Amazon）以外のものを扱えるように拡張しちゃえば、そのデータを人間をキーにフィルタリングするだけで、結構いろいろ使えるものができると思うんだけど。

というかもともとMMはそういう目的で作っているんだけど、本読み管理DBとして使えるようになった段階で満足しちゃって、そこから先に進む気力がなくなった。SNSと絡めればちょっとはやる気が出るかな。現在でも人をキーにした集計とかできるけど、あれを友人の範囲までをキーにした集計にすれば、SNSっぽいデータがでてくるよね。ちなみに本以外のデータってのは、たとえばニュースクリッピングとかテレビ番組やイベントの情報とか、そういうのね。

あと、できればほかのサーバーで情報を利用するためのAPIも用意しておきたいな。あるコミュニティ参加者一覧を取得するAPIとか、あるユーザーの友達情報を取得するAPIとか。それがあれば、外部のWikiとかに情報が派生したときに、権限DBだけをAPI経由で取得して使うことができる。

3日くらい暇があって、サーバーに余力があればだいたい動くものはできそうだけど、そんな余裕はないだろうな。

_ 鈴鹿GP金曜フリー走行 (15:09)

なんか雨（台風）でろくに走れてないらしいな。今日のセッションは一応タイムを出しただけ程度で終わったみたいだ。しかも明日にかけてさらに雨が強くなるんで、下手したら予選は中止で、今日のタイムでグリッドが決まるかも。予報によれば日曜には晴れるらしいけど、なんかぐだぐだな展開になりそうだな。そのぐだぐだな展開がBARに有利に働くといいなー。

日本GPグリッドは前戦の結果で？

という説もあるんだとか。こっちの方がBARにはいいな。

Japanese GP in doubt?

こっちの説だと、明日予選できない場合は日曜午前に予選になるとか。ところで台風22号って「Tropical Storm Number 22」なの？

_ 似た話題の日プラグイン (17:18)

Estraierを使った似た話題の日プラグインをrubyにポーティングしたら公開するとか言っておきつつも、いろいろ後回しにしすぎてやる機会がないんで、PHP版（estrelate.php）をそのまま公開しておきます。ライセンスはGPLってことで。やっていることは単純なんで、rubyがわかる人ならば一呼吸で移植できることでしょう。ただ、tDiary側の設定に依存してキャッシュファイルのパスとかが変わってくるんで、その辺りの整合性をきちんと作るのは結構面倒かも。ほかのプラグインの@confとかを参照して動く必要が出てくるし。というか、tDiaryとestraierの連携に関しても、まだ正式なやり方ってのは存在していないっけ？

#!/usr/bin/php
<?php

//estxviewのパス。maxを変えると検索個数が変わる
define('ESTXVIEW', '/usr/local/bin/estxview -nk -nt -max 5');
//転置インデックスのパス
define('INDEX', '/home/tdiary/html/casket');
//転置インデックスに含まれるHTMLのパス
define('DOCROOTPATH', '/home/tdiary/var/data/cache/html');
//tDiaryのURL
define('TDIARY_URL', 'http://tdiary.ishinao.net/');

main();

function main() {
  global $argv;

  $targetdate = $argv[1];	//'YYYYMMDD'形式で対象の日付を指定
  $docId = getDocId($targetdate);
  if (!isset($docId)) {return;}
  $dates = getRelatedDates($docId);
  array_shift($dates);	//最初の1個は$targetdate自体が返るので除去

  $result = '似た話題の日: '."\n";
  foreach ($dates as $date) {
    $result .= '<a href="'.TDIARY_URL.date('Ymd', $date).'.html">'.date('Y/m/d', $date).'</a>'."\n";
  }
  echo $result;
}

//document idに似た文書（日付）を取得
function getRelatedDates($docId) {
  $cmd = ESTXVIEW.' -rel '.INDEX.' '.$docId;
  $result = shell_exec($cmd);
  if (preg_match_all('/<uri>.*\/([0-9]{4}\/[0-9]{4})\.html<\/uri>/', $result, $matches)) {
    $files = $matches[1];
    $dates = array();
    foreach ($files as $file) {
      list($year, $md) = split('/', $file);
      $dates[] = strtotime($year.'/'.substr($md, 0, 2).'/'.substr($md, 2));
    }
    return $dates;
  }
  return NULL;
}

//HTMLファイル名からdocument idを取得
function getDocId($date) {
  $datestr = date('Y/md', strtotime($date));
  $cmd = ESTXVIEW.' -uri '.INDEX.' '.DOCROOTPATH.'/'.$datestr.'.html';
  $result = shell_exec($cmd);
  if (preg_match('/<document id="([0-9]+)">/', $result, $matches)) {
    $docId = $matches[1];
    return $docId;
  }
  return NULL;
}

?>

ちなみにこのスクリプトを呼び出すestrelate.rbの方では、

add_body_enter_proc do |date|
   `/home/tdiary/bin/estrelate.php #{date.strftime('%Y%m%d')}`
end

ってしてるだけね。

_ 鈴鹿GP予選 (11:05)

いやー、今回の予選は面白かったなー。BARはスタートさえ失敗しなければいいところに行きそう。今回はマクラーレン、ルノー、モントーヤ、バリチェロあたりが下位に沈んでくれたんで、敵が少ない。できればスタートでウェバーはかわしておきたいところ。ウェバーの後ろについちゃうとシューマッハーズに逃げられて、その後ろが数珠繋ぎになるかも。それにしてもミハエルはなぜあんなに速いんですか？　ブリヂストンはまだ最終セクターで滑ると思っていたのに、ミハエルのアタックだけは最終セクターもロスがないんだもんなー。

_ 鈴鹿GP決勝 (16:05)

_ ベスト・オブ・常習者サイト 2004 (15:15)

ジャンルの金賞をもらったらしい。どういう賞なのかよくわかってないけど、ひとまずありがとうございます。新サーバーに移行して以来、週に1、2回気がつくと死んでいるんで、ほどほどにご利用ください。時間と根性があったら、そのうちバグ修正を兼ねたリニューアルをしますよ。MM、TypeKeySNSあたりとくっつけちゃうかも。

_ 空いてる空港 (05:23)

早くつきすぎたよ。5:40にならないと何もできないのね。

_ 携帯電話初のフルブラウザ搭載端末「W21CA」 (14:56)

まあこんなに待てなかっただろうから、W21Sを買ったことを後悔してはいないけど、USBクレードル、AF付き200万画素カメラ、画面がさらに広くなった、miniSDカード、メディアプレイヤーとしての能力が増した、ってあたりはすごくウラマヤシイ。フルブラウザは定額外ならほとんど使わないだろうけど、緊急回避用にあって困る機能じゃないし。

W21Sを買って7ヶ月経ったあたりが一つの山になるな。でもW21Sにもかなり満足しているから、できればさらにもう1世代先のCASIO端末まで待ちたいところ。

_ シャープ、4GB HDD搭載の新ザウルス「SL-C3000」 (14:56)

そしてこいつにも困ったことだ。

SL-C760には満足しているんだけど、携帯（W21S）がネット端末としてものすごく使えるようになっちゃったんで、利用機会が激減していたりする。携帯で間に合わないWebを見るときと、長文テキストを入力するとき、移動中にどうしてもサーバーに接続したいとき、くらいしか使わなくなった。でも念のためいつも持ち歩いているし、一応まだAirH"はつなぎ放題32k契約維持しているけど。

で、こいつはたぶんそれに加えて、大容量データのバックアップ・移動メディアとしても使えるようになり、もしかしたら音楽プレイヤーとしての使い方も結構いけるようになる。バッテリーの持ちがあまり良くないから、iPodほどは使えないだろうけど。

あとぱっと見、キーボードのできが前よりよさそう。というか、キーボードオンリーでの使い勝手が向上してそうに見える。今まで爪でタッチパネルを叩かなきゃいけないけど、フォントサイズ小だとそれがめちゃめちゃ難しいってことが良くあったから。こっちはたぶんカーソル＋OKでの操作がやりやすくなってるんじゃないかな？

SL-C760にも十分満足しているんで、どうしても乗り換えたいってほどではないけど、こいつ＋bitWarp PDAに乗り換えて、AirH"32kつなぎ放題を解約するのも結構悪くない。最近PCでAirH"使うことがほとんどなくなってるし。

ところで最近Linux Zaurus界って全然チェックしていないんだけど、使えるメールクライアントって出てきてるのかな？　はっきり言ってSL-C760の標準メールクライアントよりも、mobileimapの方が圧倒的に使い勝手が上で、起動＆ネット接続時間を考えるとどうしてもW21Sで使っちゃう。もしちゃんと使えるIMAP4メールクライアントがあれば、メール端末としてZaurusが復権するかも。ただもうちょっとバッテリー充電時間を短縮してくれ。

_ GoogleでPC内を検索、「Google Desktop Search」をベータ公開 (15:17)

あーあ、先を越されちゃった。「自分の見たWebページを全文検索する」「自分の見たWebページを全文検索する 2」「PKM - Personal Knowledge Management」という流れで、Estraierを使ってローカル文書とブラウザ履歴を検索するWindowsローカルアプリを作ってたんだけど、ワープロ文書のインデクシングがうまく行かない件（←たぶん文字化けで部分的にしか読めないと思う）で引っかかっちゃって、解決している暇がないままに放置してしまっていた。

一応HTMLとTEXTとメールに関してはインデクシングして、専用クライアント（インターフェースはIEコンポーネント＋HTML）で検索するところのプロトタイプはできていたんだけどな。

というか、自分の中ではマイクロソフトのLonghornに乗るはずだったDBファイルシステムをライバル視していた（というか、あれより先に実用化したいなーと思っていた）んだけど、まさか先にGoogleさんにやられてしまうとは。そういやGoogleも企業向けのイントラ用検索エンジンとかやってたっけ。あれの延長で個人向けに向かうってのもありだよな。

_ SEO コンテスト - SEO Association (18:59)

SEOコンテストとか言うのが話題らしく、「はてな携帯ゲートウェイ inspired by 「ゴッゴル！？」」なんて実験をしてみたりもしたんだけど、これって自分のサイト名とかハンドルとかを「ゴッゴル」にしちゃうのが一番強い？

というわけで、本日からishinao.netは「ゴッゴル」に変更になり、私も「ゴッゴル君」と名乗ることにします（嘘）。

_ RD-X5がAmazonで売ってる！ (21:13)

試しに検索して発見して鼻吹いちゃったんですけど、RD-X5がAmazonで予約受付中なんですが！　しかも141,500円と現時点での価格.com最安値（157,800円が3店並ぶ）よりも安くて、最大15％還元（15,000円？）までついているんですが！　思わずカートに入れて予約購入しちゃったんですが！　楽天とかでもっと安い値段付けてるところがあるのは知ってるけど、ひとまずこれはなんかすごいと思ったんですが！　ご購入の際には是非↓のリンクからどうぞ（アサマシ）。

• TOSHIBA W録 RD-X5 600GB HDD&DVDレコーダー

んあ？

エレクトロニクスのところでもらえるギフト券って、利用にやたらと制約があるみたいだけど、説明を読んでもいまいち縛りの条件がわからない。ひとまず和書とマーケットプレイスの商品には使えないってことはわかったけど、それ以外に何か制約はあるのかな？　CDとDVDに使えるなら別にかまわないんだけど。

そういや

俺のAmazonに登録しているクレカでこれ買えるのかな？　学生の頃に入ったカードでその後まったく契約形態が更新されていないんで、ものすごく限度額が低かった気が。買えなかったら恥ずかしいかも。

_ クリッピングサイト度 (08:21)

「リンクと非リンクの割合」を読んで、試しにblogmapにそれっぽいものを付けてみた。blogmapの詳細ページ「この話題を取り上げたサイト」で「◆」が頭に着いているところは、クリッピングサイトである可能性が高いかも、ってカンジっていうかー。

ロジックとしては、ドキュメントサイズとリンク数と「ドキュメントサイズ/リンク数」という3つを巡回時に記録しておき、それらから適当にそれっぽいものを抽出している。今のところ、

$docsize > 20000 && $linkcount > 100 && $docperlink < 500

とかにしているんだったかな。しばらく様子を見て適当に条件はいじるかも。あと、しばらくはキャッシュが効いているんで、判別結果が表示されない詳細ページも結構あるけど、まあ1、2日経てば一通り表示されるようになるかな。

_ 2004ブラジルGP予選 (11:20)

琢磨出だしでミスった割には残りはずっと安定していて良かったねー。それまでずっとセカンドセクターが遅かったことを考えると、最終的なセッティングはかなり決まったってことなんじゃないかな。でも出だしでミスらなければ、4番手辺りに来れたかもね。スタートでバトンとマッサを抜いて、4番手辺りにつけれるとかなりいいかも。

それにしても今回バリチェロは速い。ミハエルがプラクティスでこけて番外（＆ストラテジー変更）になってくれたってのもあるけど、それがなくてもミハエルより速かったかもね。バリチェロにこのくらいの速さがあるうちに、ミハエルには引退なり移籍なりしてもらって、バリチェロにも一度くらいチャンピオンにならせてあげたいねー。

_ 2004F1ブラジルGP決勝 (01:58)

• うわー、雨っすか。結構降ってるっぽいなー。
• アロンソ、クルサード、ヴィルヌーヴが冒険に出たらしい。
• とか書いている途中で家のネットワークが死にやがったんで、ふつうに観戦。
• ああ、琢磨最後のところで粘れない辺りが、まだまだだよなー。でもこの経験を来年につなげてほしいなー。

_ 久しぶりに更新 (11:30)

一覧表示時の各タイトルの横に「Amazon.co.jp」「Google」「読むまで死ねるかっ」へのリンクを追加。ごくごく個人的な利便性を向上させるためだったりする。

_ Ruby用のGMPライブラリを発見した (14:52)

RubyのライブラリはRAAから探すのね。ここがPerlにおけるCPAN、PHPにおけるPEARに相当する場所と考えていいのかな？　ひとまずGMPライブラリがあれば、RubyでもTypeKeyクライアントが作れそうだな。優先順位を上げたいところだけど、その前にRubyのお勉強をしなければならないんで時間がかかりそうだ。

_ 強烈な勘違い (15:03)

「ホークスタウンの高塚前社長を逮捕」より、

高塚容疑者はセクシュアルハラスメント（性的嫌がらせ）疑惑などを理由に九月末、ホークスタウン社長を解任。直後に球団オーナー代行も辞任した。抱きついたことは認めているが、「強制ではなかった」などと供述しているという。

調べでは、高塚容疑者はホークスタウン社長在任中の今年四月七日、福岡ドームに隣接する「シーホークホテル＆リゾート」内の会議室で女性社員に抱きついた疑い。また、ホークスタウン前身の会社の幹部だった二〇〇二年七月十一日にも、女性社員の肩を抱き寄せるなどした疑い。

そして、「抱擁力―なぜあの人には「初対面のキス」を許すのか(高塚 猛/中谷 彰宏)」より、

経営者が明かす恋愛論! セクハラになる人、ならない人の違いとは? 盛岡グランドホテルを皮切りに、福岡ドーム、ダイエーホークスを建て直した「再建請負人」が明かす、女性部下の心をつかむための極意。

壮大なギャグのようだ。多分本人は本気で「自分はOK」と信じていたんだろうけど。共著の中谷彰宏がどんな相づちを打っているのか気になるなー。

_ TypeKey認証でアクセス制御するPukiWiki その2 (16:54)

「TypeKeyログインが必要なPukiWiki」みたいな中途半端な対応ではなく、読み書きを完全にTypeKey認証でコントロールするPukiWikiを作ってみた。まだ配布できるレベルまでまとまってないし、Auth::TypeKeyの新バージョンのテストもまだちゃんとやってない（手元の環境で使っていると、ときどき認証がおかしくなる原因追及中）んだけどひとまず実働テストってことで。

ちなみに設定方法としては、pukiwiki.ini.phpに、

/////////////////////////////////////////////////
// TypeKey対応設定
define('TYPEKEY_NEED_EMAIL', TRUE);
define('TYPEKEY_TOKEN', 'Z2CkcIgTyFI6Agf4tH2G');
define('TYPEKEY_WRITERS', '');	//,区切りでTypeKeyのnameを記述
define('TYPEKEY_READERS', 'ishinao');	//,区切りでTypeKeyのnameを記述

なんて感じで設定しておいて、TYPEKEY_WRITERSに編集を許可する人のTypeKey nameをカンマ区切りで、TYPEKEY_READERSに閲覧を許可する人のTypeKey nameをカンマ区切りで記述。空の場合はTypeKey認証を通った人なら誰もOK。

ちなみにTypeKey認証を通らない人にはすべてのアクセスを許可しない。TypeKey認証なしでもアクセスできる設定を許可しようかと思ったんだけど、楽に修正しようとしたらこうなってしまった。PukiWikiのコードって結構コアの部分からアクロバティック（基本的な編集処理とかもプラグイン扱いなのね）なんで、ちゃんと追うのが辛くって。

できるだけ配布可能な形で修正を加えていったんだけど、簡単に差分を配布できるような形にまとめられなかったし、まだ動作確認が十分じゃないのでこの状態でしばらくペンディング。動作確認のために書き込み許可をしてほしい人は、ここのコメントにでもTypeKey nameを書き込んでいってください。暇を見て追加していきます。

とか書いているうちに思いついたけど、どうせならば、

/////////////////////////////////////////////////
// TypeKey対応設定
define('TYPEKEY_NEED_EMAIL', TRUE);
define('TYPEKEY_TOKEN', 'Z2CkcIgTyFI6Agf4tH2G');
define('TYPEKEY_ALLOW_WRITERS', '');	//,区切りでTypeKeyのnameを記述
define('TYPEKEY_DENY_WRITERS', '');	//,区切りでTypeKeyのnameを記述
define('TYPEKEY_ALLOW_READERS', 'ishinao');	//,区切りでTypeKeyのnameを記述
define('TYPEKEY_DENY_READERS', '');	//,区切りでTypeKeyのnameを記述

みたいな設定にした方が幸せになれそうだな。そのうちそういう風に変更しておこう。あと、最終的にはこの許可、拒否設定をTypeKey SNS経由で取得できるようにしたいんだけど、まだその辺まで仕様を煮詰めている余裕がない。

_ 趣味とサービスの境界 (18:30)

「受益者負担の話がなんか変だと思ったのは」とか「受益者負担の原則」「otsune さんの記事の感想いろいろ」とか、なんか個人Webサイトを大したものに考えすぎというか、読者へのサービスとしての意味を大きく考えすぎている気がするなー。

どんなに読者・利用者へのサービスの意味合いが強いWebサイトを運営していたとしても、しょせん趣味は趣味。自分のモチベーションと経済力の範囲でやれることをやればいい。俺は多分個人でWebサイトをやっている人間としては、そのために金を使っている方だと思うけど（サーバー代だけで月2万円払ってるし、運用コスト（労力）もバカにならない）、自分でそれだけ金を出してもいいと思えるくらい面白いからやっているだけで、やる気と経済力とどちらかが尽きたら適当に規模を縮小するなり、やめるなりするだろう。

ちなみに俺は『AmazonアソシエイトとGoogle AdSenseは、「Web上で自給自足するためのシステム」って感じで非常にありがたい』と思っていて、上記二つのアフィリエイトでカバーできる範囲で遊べるのが一番うれしい。逆に、直接的な投げ銭とかはあまりほしくない。そういうものを受け取っちゃうと、「俺の趣味」の範囲を超えてしまう気がするから、ありがたいと思う以上に負担に思う。

俺は自分の個人Webサイトは、まず第一に自分の楽しみのためにやっていて、それが他の理由よりも圧倒的に大きい。もちろんそれ以外の理由（公共の利益とか、利用者のためとか）もある程度はあるけど、そのために「自分の楽しみ」を犠牲にする気はない。ちなみに「趣味による自分の楽しみ」を「利益」なんて言葉にすると何かが違ってしまうと思う。「趣味」と「利益」はその評価軸がまったく異なるものだから。

_ 個人事業主の個人Webサイト (13:14)

小山さんの「受益者負担の原則」を読んでの感想なんだけど、個人事業主が運営する個人Webサイトは、サラリーマンとか学生とかが立ち上げる個人Webサイトとは、ちょっと意味合いが違う気がする。というのは、個人事業主のWebサイト（とか会社社長としてのblogとか）は、商売のツールという意味合いが強く出てきてしまいそうだから。

あと、なんとなく小山さんのやりたいことって、@ITとネタがかぶっているような気がした。というか、

技術書の出版みたいな分野が好きで、それを自分の生業としたいと思っているらしい。しかしながら既存の雑誌や書籍を扱う出版業などの指向というかシステムは、僕の期待する物とはちょっと違う

ということを目的とするなら、多分俺なら@IT的な技術系ポータルを狙ったWebサイトを自分で（趣味の範囲で）立ち上げてみるだろうなー。

前にそういうWebサイトのネタはちょっとだけ考えてみたんだけど、どう考えても俺にはそういうのを維持するモチベーションが見あたらなかったんでやめた。でも、今あちこちの個人Webサイト（主に日記とかblogとか）に分散している技術情報を、技術的な視点からまとめ上げる仕組みがあるととても便利だと思う。

前にRuby Magazineの話の時に書いたように、ある技術に関する話題（記事）をTrackBackを使って収集し、それを編集者がフィルタリングして、きちんとしたコンテンツとしてまとめ上げるようなやり方が一つ。あるいは、blogmapのように自動収集とコンテンツ判別と全文検索（というか技術キーワードを使ったインデクシング）を組み合わせて、多少ノイズが混ざったとしてもとにかく量を収集する方法が一つ。外見的には、最近流行のPlanet〜系と@ITとを融合させた感じかなー。

ある程度成功したら、そのコンテンツをまとめて出版してしまう仕組みとかまで発展させればいいだろうし。技術系のポータルとしてある程度成功すれば、そっち系の広告とかもつきそう。あとそういう特定の方向性を持つサイトならば、Google AdSenseとかAmazonアソシエイトとかの効果も大きくなる。

誰か余力がある人作ってちょうだい。自動収集である程度ちゃんとした情報を集めることができて、それを使って初期アクセス数と技術系キーワードにおけるGoogleページランクを稼ぐことができたら、成功する可能性は結構あると思う。俺の中の優先順位はものすごく低いんで、自分で作る可能性は限りなく低い。はてなあたりでやってくれないかなー。って、なんか最近の俺のこの手の思いつきの垂れ流しのオチはみんな「はてながやってくれないかなー」になってる気がするな。

具体的な話

上記のような文章では、俺の頭の中にあるイメージは具体的な内容として伝わらないみたいなんで、実装例の一つを具体的に書いてみる。

• 技術系の話題を扱うblog/日記サイトを情報ソースとして登録
• 情報ソースサイトのRSSを（あるいは記事抽出エンジン経由で）巡回し、記事を取得する
• 記事に含まれるキーワードから、各記事の技術的な意味づけを評価
  • 技術の話題かどうか。技術の話題じゃないものは除外。
  • 技術の話題だとしたらなんの話題か（たとえばプログラミングとかサーバー運用とか。さらに細分化するとPerlだったりRubyだったり、あるいはそれぞれのライブラリだったりとか）
  • 技術の話題で、その技術キーワード（＝表からはカテゴリに見える）が特定できた場合は、そこに分類する。カテゴリと言っても箱に入れるカテゴリ分類ではなく、属性を付けるカテゴリ分類。
• 上記のような処理で自動分類された内容をそのまま垂れ流すか、それとも人間が目で見てチェックしてOKだったもののみを表に出すかは、自動フィルターのできとかサイトの完成度の目標とかの兼ね合いで適当に
• サイト上では、技術キーワード・分類をベースにカテゴリをたどっていく（＝実際はキーワード検索）と、その技術分野に関係した記事が表示される。
• さらにそのカテゴリにはTrackBack Ping URLが用意されており、読者が自主的に各カテゴリにTrackBackを打つこともできる。それをそのまま載せるか、人間の目で見てチェックして……（2項目上の繰り返し）
• サイト管理者に根性や資金力があれば、各カテゴリの最近のトレンド等をまとめた記事を、サイトオリジナルのものとして用意するといいかも（@IT的）。
• 各カテゴリにWikiとか掲示板みたいな独自のコミュニティを用意するべきかどうかは微妙。変に初心者質問箱的になるくらいならば、コミュニティは用意しない方がいい気がする（個人的な趣味の問題）。

このくらいまで書いておけば、作れる人なら10日くらいで作れるよね。ハードウェアリソースとか運用コストとかを考えなければ。

_ ひどい目にあった (17:20)

MySQLの4系統のstableが出たと聞いてアップデートしてみたら、軽く血反吐を吐かされてしまった。 MySQL 4.0.20からMySQL 4.1.7は小数点2桁目が違うだけあって、ハゲシク互換性がないのね。さすがちゃんとUNICODEに対応したバージョンだけあって、charset周りの処理が全然違う。

というか、テーブルのフィールドごとに文字コードを指定しなければならなくなったんだね。で、古いバージョンからアップデートしたときには、なんか不思議な感じのcharset設定が自動的に付与される。

アップデートしたDBのデフォルトcharsetはujisにしてあるんで、文字っぽいものはujisになっている場合が多い。その場合、サイズがなんだか適当に切りつめられている。たとえばvarchar(255)とかがvarchar(32) ujisとかになってたり。あと、ときどきujisではなくlatin1になってるものもあるけど、これはujisデフォルトにする前に作ったテーブルなのかなー？

んで、結構致命的なのは、勝手に切りつめられたフィールドを含むテーブルをrepairとかしちゃうと、indexが切りつめられたサイズで作り直されて、その結果重複したフィールドがあったら自動的にそのレコードを削除しちゃったりするらしい。データがばりばり消えていくよー（消えてもいいテーブルで試したんだけど）。

さらに回復に時間がかかったのは、varchar ujisとvarchar latin1とかのフィールド同士では、whereで比較したりできなくなっちゃうらしい。いろいろ迷ったけど、結局全部ujisに統一して対処することにした。でかいフィールドだとalterするだけで結構時間がかかるな。

ここまでやってようやく一通りなんとなく動くようになった気がするけど、大量にキャッシュが消えちゃったんで、しばらく動作が遅いだろうなー。でもようやくUNICODEが使えるMySQLが手元でちゃんと動くようになったんで、これでMySQL上で日本語全文検索とかもやりやすくなりそうだな。ChaSenとかで分かち書きして突っ込んでおくだけでいけるのかなー。

追記

MySQL 4.0→4.1にアップデートする前に、

• http://dev.mysql.com/doc/mysql/ja/Upgrading-from-4.0.html
• http://dev.mysql.com/doc/mysql/ja/Charset.html

を熟読しておくべきでしょう。

_ デジカメ画像管理ツール (14:14)

はてながフォトライフというのを始めたらしいけど、よくできたデジカメ画像管理ツールが必要な人って絶対にたくさんいるよね。で、管理ツールはWebアプリじゃなくてデスクトップアプリの方がいいと思う。コピー（アップロード）が面倒くさいし。Adobe PhotoAlbumとかがよくできていると聞いて試してみたりしたけど、もう一声と言った印象だった。あとGoogleの息がかかっているというやたらとかっこいい3D風スクロールする管理ツール（名前忘れた）も悪くなかったけど、あれは日本語通らなかったしなー。

これに関しては、ずいぶん前から個人的な懸案事項で、基本線として「撮影日時をベースに管理する」というところまでは決まっていて、結構前に、画像データをまとめて日時ファイル名に変換をかけてしまうツールをGPLで配布したりしていた（んだけど、ふと探してみたらいつのまにかうちのサイトに残ってないな。サイト改変のタイミングで消えてしまったのか。多分どこかにバックアップが残っていると思うけど、まあいいや）。

で、撮影日時をベースに管理するという方針はともかく、次に難しいのはUI部分。大量の画像ファイルを処理する作業なんて、使い勝手が良くないとやってられないよね。でもデスクトップアプリでUIに凝るのってうざいしなー、とか思っていい案が出るまで放置しているうちにすっかり忘れてしまっていた。けど、はてなフォトライフを見て思ったけど、UI部分はWebアプリにしてしまうという手があるんだね。そうすればカスタマイズとかも用意だし。

ファイルシステム上にある画像ファイルを、主に撮影日時をキーに管理しつつ、それに利用者が自由に使えるキーをいくつか追加できるようにして（MM/本のメモのようなアプローチ）、そのデータをSQLite辺りに保持しておく。んでもって、キーの管理はふつうのデスクトップアプリのUIで行う。多分エクスプローラライクなUIになるだろうなー。TreeViewとListView（って標準的な表現だっけ？）を使って表示するイメージ。

ただし通常表示する際には、デスクトップアプリ的UIはほとんど使わず、埋め込みIEを使うか外部Webブラウザに対してHTTPで吐き出すかはともかくとして、HTMLベースのUIを採用する。そうすることでテンプレートHTMLなんかをいじることでユーザーが自由に出力をカスタマイズできたりするし、デフォルトテンプレートなんかもいちいちデスクトップUI作成ツールなんかを使ってデザインしなくても、HTML的な適当さで表現することができる。懲りたければDHTML（って最近言わないね。JavaScript）を使ってばりばりやってもいい。あるいはFlashと連携させてもいいよね。こっちはカスタマイズするのが面倒くさいけど。

あと、ファイルのコピー・移動・削除の追随をどうするかというのも対処方法に迷っていたんだけど、作りかけだった「Estraierでデスクトップ検索ツール」の仕組みを応用すればいいかもしれない。画像ファイルを置くディレクトリを登録しておいて、そのディレクトリの変更を常駐ソフトが監視しておく。変更情報を普段はメモリに蓄えておいて、Idle時にDB（ファイル）に更新をかけるようにすれば、そんなに負荷は気にならない気がする。

まあそんな感じの画像管理ツールを誰か作ってフリーで流してください。ああそういや会社で来年辺りまでに何かWindowsアプリを作らなければならないはずだったな。その企画に載っけてもらおうかな。でもそうするとフリーじゃなくなっちゃうな。

_ 家族全員風邪 (22:52)

俺自身は先週後半から頭痛と鼻水が出ていたんだけど、子供2人も鼻水と咳がひどくて熱が出て、オクサンも頭痛と吐き気がして、この週末はみんなそろってズルズルゲホゲホな感じ。最近年のせいか、風邪を引くと長引くんでとっとと治したいんだけど、1日寝ていても特に良くなった気がしないなー。

_ デカレンジャーショー (23:59)

みんな体調が良くないのに、よりによってこんな日にずいぶん前からムスコが楽しみにしていた消防署主催のデカレンジャーショーがあったので行ってきた。

ショーの規模（金のかけ方）はおそらく登場人物の人数に比例する。司会進行役とかは除いて、主にアクションを行う人間の数。そして、デカレンジャーのようなゴレンジャー系ヒーローものの場合は、あまり金がかかっていない場合、フルメンバーそろえるだけの人数がそろえられない可能性がある。というわけで、まずはヒーローが何人そろうかをチェック。

ちなみに私が見た中では、ヒーロー2人、怪人3人程度というのが（ゴレンジャー系の）ミニマムパターンだった。仮面ライダー系のような場合は、ヒーロー1人でも問題ないはずだが、最近の仮面ライダーはヒーローが複数というのが定番なので、結局ヒーロー2人程度は用意してくるのが基本のような気がする。それでもゴレンジャー系よりはヒーロー1人でもごまかしやすそうだ。ウルトラマン系の場合は、ヒーロー2人、悪者1人（もしかしたらヒーローの片方と悪者は、中の人が一緒だったかも）というパターンもあった。ちなみに司会進行役のお姉さん（近くで見るとおばちゃんの場合もある）は別に立てるのが無難。

人数をチェックする際にポイントとなるのは、表向き見えるキャラクターと実際の中の人とは一対一で対応するわけではないという点。デカレッドが出てきて、次のシーンでデカブルーが出てきたからといって、2人いると考えるのはまだ早い。同時に出てこない限りは、もしかしたらデカレッドとデカブルーの中の人は同じ人かもしれない。また先ほどデカレッドとデカブルーが出てきて、しばらくしてデカレッドとデカグリーンが出てきたからと言って、その2シーンのデカレッドが同一人物であるとも限らない。シーンの切り替わりのタイミングによっては、同じキャラクターを同じ人が演じるとは限らない。

ちなみに今日のショーでは、まず怪人2匹、下っ端3匹、ヒーロー1人が出てきた。それ以降シーンが変わるごとにヒーローは変わっていったが、ヒーローが複数登場するときにはたいてい下っ端は出てこなかったことから、下っ端がヒーローを兼任していたのであろうことがわかる。また怪人の片方がかなり特徴のある着替えしにくそうなキャラクターだったので、彼はおそらくずっと同じキャラクターを演じ続けていたはずだ。一方もう片方の怪人は、いかにも簡単に脱ぎ着できそうな格好をしていたので、彼はヒーローが5人揃うときにはヒーローの1人になったものと思われる。

ちなみに下っ端の衣装は、黒タイツが基本だ。そのため、ちょっと下腹部がだらしない人は、その部分がとても目立つ。というか、よほど鍛えている人でないと、黒タイツを着るとかなりだらしない体型になりがちだ。しかし、おそらく同じ人が中の人をやっていると思われるヒーローは、きちんとベルトをした衣装となっており、その服を着ている限りはそのようなだらしない体型の人は見つけられなかった。下っ端がヒーローを兼任しているという私の予想が正しいのであれば、衣装によって補正される体型の違いはかなり大きい。

というか、長々とこの文章を書いていたのは、下っ端の黒タイツの時には下腹部がぽこんと出ていた人たちが、（おそらく）ヒーロー役になったら全然そんなことがなかったことに驚いてしまい、そのことを書きたくて書きたくてしょうがなかっただけなのだ。

と言うかそれ以前に、体調が悪いのを押して寒空の下そんなショーを長々と見ていたら、俺は昨日よりもさらに具合が悪くなるし、赤ん坊は熱が38度以上出てゲリゲリゲロゲロ状態になるし、なんだかもう悲惨な状態なんですよ。ああもうきっついなー。