「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経由で取得できるようにしたいんだけど、まだその辺まで仕様を煮詰めている余裕がない。

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

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

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

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

小山さんの「受益者負担の原則」を読んでの感想なんだけど、個人事業主が運営する個人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日くらいで作れるよね。ハードウェアリソースとか運用コストとかを考えなければ。

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

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

はてながフォトライフというのを始めたらしいけど、よくできたデジカメ画像管理ツールが必要な人って絶対にたくさんいるよね。で、管理ツールは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アプリを作らなければならないはずだったな。その企画に載っけてもらおうかな。でもそうするとフリーじゃなくなっちゃうな。

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

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

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

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

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

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

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

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

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