2006年2月

Wikiスパムについての備忘録。

リンク 編集

連想。コメント機能の条件というか、投稿全般に対する話ではあるけど。

lily2を作ってた時のコメント機能を踏まえつつ、どうせ作るならこれは必要だろうってのは
1.IPベースで投稿を弾く
2.NGワードで投稿を弾く
3.URLの数で投稿を弾く
4.TypeKeyなどを使ってアカウント認証が出来る
5.コメントを確認するRSSを吐く
Web2.0時代のコメント機能の条件 - てくのーと Splash☆Star

「6.ベイジアンフィルタを通す口を用意しておく」というのはどうでしょう
Web2.0時代のコメント機能の条件 - textfile.org

• コメントだとURLとリンクばかり、というケースが多くて、ベイジアン・フィルタは厳しそうだな。
• そう言えば、Wikiスパムって次のような特徴があるな。
• aタグがそのまま書かれる。
• 複数のWiki向けのリンク記法が書かれる。
• ベイジアンのような文字・単語登場回数の傾向によるフィルタリング以上に、こうしたパターン（不許可HTMLタグと非対応Wiki文法）マッチングによるフィルタリングが効くかも。

ただいま未明。一晩寝ると忘れそうなので、とりあえずメモしておく。

これを敷衍すると、Wikiに限らずblogなどでも

• HTMLタグ直書きは禁止。Wiki文法、BBcode、Textile、Markdown等を使用する。
• HTMLタグ直書き、または複数の記法によるリンクが混在していれば、スパムとみなす。

というアンチ・スパム・ストラテジが成り立つかも。もっとも、いきなりスパム認定は乱暴かもしれない。手心の加え方は各々で判断ということで。

Plaggerのインストールはむずかしいか。

リンク 編集

NamingSense::Tokulog!より。

むつかしくない気がする。というか、インストールのむつかしさは想定していたものとほぼ同等だった。CPAN モジュール使いまくり系のアプリケーションだったら大体こんな感じよね、という風。
NamingSense::TokuLog! Plaggerのインストールはむずかしいか

そうそう、そんな感じ。基本的には、CPANモジュールでモジュールをインストールする手順が分かっていれば、ほとんど何も考えなくて良い。

だから、Windowsに最初からActivePerlが入ってて、大概のものをCPANインストールできるようにC/C++コンパイラ、tar、gzぐらいのコマンドが入ってて、コマンドラインがshebang行を見るぐらいの気の利き方をしててくれれば問題ない。まあ最後のは、pl2batがあれば良いじゃん、といえばその通りなんだけど。そのあたり、ClassicからOS XになってMacはめちゃくちゃうらやましい環境になったなぁ。

Windowsでは実際には、コンパイルが必要なモジュールはそう簡単にインストールできない。そこで、できるだけPPMを使う。もっとも、CPANの方が新しいバージョンがあることが多いので、CPANで試してみて、ダメならPPM、それでもダメならとりあえず諦めて状況の変化待ち、というヘタレたスタンスになるのが僕レベル。そのレベルでもPPMとCPANの使い分けなんてバッド・ノウハウな香りがするんだけど、それはだからWindowsないしActivePerlに由来するところで、Perlの問題じゃない。

あ、いや、もちりん、普段から CPAN モジュールをインスコまくりで、CPANRecent とかヲチしまくりの人にとってむつかしくないよ、という話だよw
NamingSense::TokuLog! - Plaggerのインストールはむずかしいか(2)

...ということでまあ、CPANモジュール・インストールだってろくにしてない僕でも何とかなったので、インストールまでは何とかなるかと。ただ、CPANでインストールできるDateTime::Format::MailとかTemplate::Provider::Encodingを手作業でインストールしたということは、きっとprerequireの定義から漏れてるんじゃないかと。これが自動的にfollowされてくれると、もう少し「インストール簡単」感が強くなる気がします。

余談ですが、Plagger使用時の%INCの内容。

C:\>perl -MData::Dumper -MPlagger -e "print Data::Dumper->new([\%INC])->Indent(1)->Sortkeys(1)->Dump;"
$VAR1 = {
  'ActivePerl/Config.pm' => 'C:/Perl/site/lib/ActivePerl/Config.pm',
  'ActiveState/Path.pm' => 'C:/Perl/site/lib/ActiveState/Path.pm',
  'AutoLoader.pm' => 'C:/Perl/lib/AutoLoader.pm',
  'C:/Perl/lib/auto/Storable/autosplit.ix' => 'C:/Perl/lib/auto/Storable/autosplit.ix',
  'Carp.pm' => 'C:/Perl/lib/Carp.pm',
  'Class/Accessor.pm' => 'C:/Perl/site/lib/Class/Accessor.pm',
  'Class/Accessor/Fast.pm' => 'C:/Perl/site/lib/Class/Accessor/Fast.pm',
  'Config.pm' => 'C:/Perl/lib/Config.pm',
  'Config_heavy.pl' => 'C:/Perl/lib/Config_heavy.pl',
  'Cwd.pm' => 'C:/Perl/lib/Cwd.pm',
  'Data/Dumper.pm' => 'C:/Perl/lib/Data/Dumper.pm',
  'DateTime.pm' => 'C:/Perl/site/lib/DateTime.pm',
  'DateTime/Duration.pm' => 'C:/Perl/site/lib/DateTime/Duration.pm',
  'DateTime/Format/Mail.pm' => 'C:/Perl/site/lib/DateTime/Format/Mail.pm',
  'DateTime/Infinite.pm' => 'C:/Perl/site/lib/DateTime/Infinite.pm',
  'DateTime/LeapSecond.pm' => 'C:/Perl/site/lib/DateTime/LeapSecond.pm',
  'DateTime/Locale.pm' => 'C:/Perl/site/lib/DateTime/Locale.pm',
  'DateTime/Locale/Base.pm' => 'C:/Perl/site/lib/DateTime/Locale/Base.pm',
  'DateTime/Locale/en.pm' => 'C:/Perl/site/lib/DateTime/Locale/en.pm',
  'DateTime/Locale/en_US.pm' => 'C:/Perl/site/lib/DateTime/Locale/en_US.pm',
  'DateTime/Locale/root.pm' => 'C:/Perl/site/lib/DateTime/Locale/root.pm',
  'DateTime/LocaleCatalog.pm' => 'C:/Perl/site/lib/DateTime/LocaleCatalog.pm',
  'DateTime/TimeZone.pm' => 'C:/Perl/site/lib/DateTime/TimeZone.pm',
  'DateTime/TimeZone/Floating.pm' => 'C:/Perl/site/lib/DateTime/TimeZone/Floating.pm',
  'DateTime/TimeZone/Local.pm' => 'C:/Perl/site/lib/DateTime/TimeZone/Local.pm',
  'DateTime/TimeZone/OffsetOnly.pm' => 'C:/Perl/site/lib/DateTime/TimeZone/OffsetOnly.pm',
  'DateTime/TimeZone/UTC.pm' => 'C:/Perl/site/lib/DateTime/TimeZone/UTC.pm',
  'DateTime/TimeZoneCatalog.pm' => 'C:/Perl/site/lib/DateTime/TimeZoneCatalog.pm',
  'DateTimePPExtra.pm' => 'C:/Perl/site/lib/DateTimePPExtra.pm',
  'Digest/MD5.pm' => 'C:/Perl/lib/Digest/MD5.pm',
  'Digest/base.pm' => 'C:/Perl/lib/Digest/base.pm',
  'DynaLoader.pm' => 'C:/Perl/lib/DynaLoader.pm',
  'Encode.pm' => 'C:/Perl/lib/Encode.pm',
  'Encode/Alias.pm' => 'C:/Perl/lib/Encode/Alias.pm',
  'Encode/Config.pm' => 'C:/Perl/lib/Encode/Config.pm',
  'Encode/Encoding.pm' => 'C:/Perl/lib/Encode/Encoding.pm',
  'Exporter.pm' => 'C:/Perl/lib/Exporter.pm',
  'Exporter/Heavy.pm' => 'C:/Perl/lib/Exporter/Heavy.pm',
  'Fcntl.pm' => 'C:/Perl/lib/Fcntl.pm',
  'File/Basename.pm' => 'C:/Perl/lib/File/Basename.pm',
  'File/Find.pm' => 'C:/Perl/lib/File/Find.pm',
  'File/Find/Rule.pm' => 'C:/Perl/site/lib/File/Find/Rule.pm',
  'File/Path.pm' => 'C:/Perl/lib/File/Path.pm',
  'File/Spec.pm' => 'C:/Perl/lib/File/Spec.pm',
  'File/Spec/Unix.pm' => 'C:/Perl/lib/File/Spec/Unix.pm',
  'File/Spec/Win32.pm' => 'C:/Perl/lib/File/Spec/Win32.pm',
  'List/Util.pm' => 'C:/Perl/lib/List/Util.pm',
  'Number/Compare.pm' => 'C:/Perl/site/lib/Number/Compare.pm',
  'Params/Validate.pm' => 'C:/Perl/site/lib/Params/Validate.pm',
  'Params/ValidateXS.pm' => 'C:/Perl/site/lib/Params/ValidateXS.pm',
  'Plagger.pm' => 'C:/Perl/site/lib/Plagger.pm',
  'Plagger/Date.pm' => 'C:/Perl/site/lib/Plagger/Date.pm',
  'Plagger/Entry.pm' => 'C:/Perl/site/lib/Plagger/Entry.pm',
  'Plagger/Feed.pm' => 'C:/Perl/site/lib/Plagger/Feed.pm',
  'Plagger/Subscription.pm' => 'C:/Perl/site/lib/Plagger/Subscription.pm',
  'Plagger/Template.pm' => 'C:/Perl/site/lib/Plagger/Template.pm',
  'Plagger/Update.pm' => 'C:/Perl/site/lib/Plagger/Update.pm',
  'Scalar/Util.pm' => 'C:/Perl/lib/Scalar/Util.pm',
  'Storable.pm' => 'C:/Perl/lib/Storable.pm',
  'Template.pm' => 'C:/Perl/site/lib/Template.pm',
  'Template/Base.pm' => 'C:/Perl/site/lib/Template/Base.pm',
  'Template/Config.pm' => 'C:/Perl/site/lib/Template/Config.pm',
  'Template/Constants.pm' => 'C:/Perl/site/lib/Template/Constants.pm',
  'Template/Document.pm' => 'C:/Perl/site/lib/Template/Document.pm',
  'Template/Exception.pm' => 'C:/Perl/site/lib/Template/Exception.pm',
  'Template/Provider.pm' => 'C:/Perl/site/lib/Template/Provider.pm',
  'Template/Provider/Encoding.pm' => 'C:/Perl/site/lib/Template/Provider/Encoding.pm',
  'Template/Service.pm' => 'C:/Perl/site/lib/Template/Service.pm',
  'Template/Stash.pm' => 'C:/Perl/site/lib/Template/Stash.pm',
  'Template/Stash/ForceUTF8.pm' => 'C:/Perl/site/lib/Template/Stash/ForceUTF8.pm',
  'Template/Stash/XS.pm' => 'C:/Perl/site/lib/Template/Stash/XS.pm',
  'Text/Glob.pm' => 'C:/Perl/site/lib/Text/Glob.pm',
  'Time/Local.pm' => 'C:/Perl/lib/Time/Local.pm',
  'UNIVERSAL.pm' => 'C:/Perl/lib/UNIVERSAL.pm',
  'UNIVERSAL/require.pm' => 'C:/Perl/site/lib/UNIVERSAL/require.pm',
  'XSLoader.pm' => 'C:/Perl/lib/XSLoader.pm',
  'YAML.pm' => 'C:/Perl/site/lib/YAML.pm',
  'YAML/Base.pm' => 'C:/Perl/site/lib/YAML/Base.pm',
  'YAML/Node.pm' => 'C:/Perl/site/lib/YAML/Node.pm',
  'YAML/Tag.pm' => 'C:/Perl/site/lib/YAML/Tag.pm',
  'base.pm' => 'C:/Perl/lib/base.pm',
  'bytes.pm' => 'C:/Perl/lib/bytes.pm',
  'constant.pm' => 'C:/Perl/lib/constant.pm',
  'integer.pm' => 'C:/Perl/lib/integer.pm',
  'overload.pm' => 'C:/Perl/lib/overload.pm',
  're.pm' => 'C:/Perl/lib/re.pm',
  'strict.pm' => 'C:/Perl/lib/strict.pm',
  'utf8.pm' => 'C:/Perl/lib/utf8.pm',
  'vars.pm' => 'C:/Perl/lib/vars.pm',
  'warnings.pm' => 'C:/Perl/lib/warnings.pm',
  'warnings/register.pm' => 'C:/Perl/lib/warnings/register.pm'
};

Plagger::*なんかはまず間違いなくPlaggerディストリビューションの内容だし、YAML::*なんかはYAMLディストリビューションで、Plaggerインストール時に自動的にfollowされるから良いのだけど、じゃあDateTime::*はDateTime、Template::*はTemplateディストリビューションかというと、DateTime::Format::MailやTemplate::Provider::Encodingのような例外があるから油断ならない。「gomimemoグループ - koyachiの53memo - Plagger触ってみた」によれば、File::Find::Ruleも（僕の環境には入っていたのだけど）追加インストールが必要みたい。

地道な手作業ではなく、簡単にディストリビューション単位に書き直す方法はないのかな、あればMETA.ymlのrequireを確認できるのだけど。

0.5.4で依存モジュールが細かく記述された様子。Ticket#59参照。

Windows（ActivePerl）にPlaggerインストール。

リンク 編集

Windows＋ActivePerl環境にPlaggerをインストールしてみた。ちょっとWindows周りは面倒なところもあったのでメモ。基本的には、CPANモジュールでインストールする。

C:\> perl -MCPAN -e shell
cpan> install Plagger

私の環境では、Plagger、またはオプショナル・モジュールであるWebService::Bloglinesのインストールが以下のようなエラーで何度か失敗。

#   in t/00_compile.t at line 4.
#     Tried to use 'Plagger'.
#     Error:  Can't locate Template/Provider/Encoding.pm in @INC (@INC contains: C:\.cpan\build\Plagger-0.5.3\inc C:\.cpan\build\Plagger-0.5.3\blib\lib C:\.cpan\build\Plagger-0.5.3\blib\arch C:/Perl/lib C:/Perl/site/lib .) at C:\.cpan\build\Plagger-0.5.3\blib\lib/Plagger/Template.pm line 5.

基本的には、この「Can't locale XXX」といわれているモジュールをインストールして、再度「install Plagger」という作業を繰返せば良い。ちょっとバッド・ノウハウ気味だけど、PPMでインストールできるものはPPMから、できないものはCPANから、という手順で試していくと楽。

• DateTime、XML::RSS::LibXMLをPPMでインストール。
• DateTime::Format::Mail、Template::Provider::EncodingをCPANでインストール。

「Template::Provider::Encoding」なんてものを要求されるところを見ると、Templateモジュール（Template Toolkit）も必要なのかな？とりあえず確認しないまま、バージョンだけ表示させてみる。これができれば、文句なしにインストール完了。

C:\>perl -MPlagger -e "print Plagger->VERSION"
0.5.3

使う段になるともう一つバッド・ノウハウ気味なんだけど、plaggerコマンドはすぐに使えるような形では配置されない。まず、以下を実行。「0.5.3」というところはバージョンなので、適宜いくつにすればよいか判断してください。

C:\> cd c:\.cpan\build\plagger-0.5.3
C:\.CPAN\BUILD\PLAGGER-0.5.3> pl2bat plagger

これで「plagger.bat」というファイルができるので、これを実行パスの通っているところに移動する。多分、C:\perl\binが良いのではないかと。これで、コマンドラインから「plagger」としてやれば、動作する。

C:\>plagger
Plagger->bootstrap: config.yaml: No such file or directory at C:\Perl\bin\plagger.bat line 26

あとはconfig.yamlとか用意してやる必要がある。一応Recipe: Bloglines to Gmailというサンプルがあるのだけど、とくひろさんが日記では「./plagger したら config.yaml がねーづら！とか言われたので plagger.org のックブックとか読みに走ろうかなーとか」とか言いながら、実は既にmixiを読んだりしておいでらしいので、NamingSense::TokuLog! - plaggerにHow-Toが出てくるのを待とうかな。

とくひろさん的にそこはもう終わった話なのか、プラグイン書きに走っている様子...。

0.5.4で依存モジュールが細かく記述された様子なので、DateTime::Format::Mail、Template::Provider::Encodingあたりは自動的にfollowされると思われる。近くのCPANまで0.5.4版が来ていないので、実際にどうだかは未確認。

TypeKey認証試用。

リンク 編集

inetd上で、自作CGIでのTypeKey認証試用にチャレンジしてみる。参考にするのは以下。

• Six Apart - TypeKey API。
• Authen::TypeKey - TypeKey authentication verification - search.cpan.org。
• TypeKeyクライアントサンプルCGI - いしなお! (2004-10-01)。

基本的にはAuthen::TypeKeyのSYNOPSISと、これに結果表示部分をつけたishinaoさんのサンプルCGIを見れば良いのだけど、そもそもTypeKey認証の使い方を理解してなかったので、単にこれをおいて動かせば動くのだと勘違いしてしまった。で、動かすたびに"Invalid signature"。

そうじゃなくて、_returnのに指定するURLとして、このCGIを使うだけ。だから、その前（つまりTypeKeyログイン画面へのリンクを出す）もやりたければ、こんなコードになる。ちなみに、先頭（shebang）行のPerlパスは、現在のinetd用。

#!/usr/local/bin/perl5.8.5

use lib './lib';
use CGI;
use Authen::TypeKey;

my $query = CGI->new;
my $token = '(TypeKeyトークン)';
my $return = $query->url;
my $typekey = sprintf('https://www.typekey.com/t/typekey/login?t=%s&need_email=1&_return=%s&v=1.1', $token, $return);

my $tk = Authen::TypeKey->new;
$tk->key_cache('./.key_cache');
$tk->token($token);
my $res = $tk->verify($query);

print $query->header(-title => 'TypeKey test'), $query->start_html, $query->h1('TypeKey test');
if (!$res) {
  print "LOGIN FAILURE: " . $tk->errstr . "<br />\n";
  print qq(&gt;&gt; <a href="$typekey">Login with TypeKey</a>);
} else {
  print $query->table( {-border => 1, -cellpadding => '3px'}, $query->Tr([
    $query->td({-colspan => 2}, [$query->escapeHTML('TypeKey User Information')]),
    $query->td([$query->escapeHTML('(QUERY_STRING)'), $query->escapeHTML($query->query_string)]),
    map { $query->td([$query->escapeHTML($_), $query->escapeHTML($query->param($_))]) } qw(name nick email),
  ]) );
}

print $query->end_html;

(TypeKeyトークン)というところには、TypeKeyのログイン後の画面の末尾、「コメント登録するウェブログの指定」に表示されるTypeKeyトークンを入れる。それから、ここでこのCGIを設置するURLを登録しておくこと。

inetdにこのサンプルを設置する時は、Authen::TypeKeyモジュールとClass::ErrorHandlerモジュールも必要。 正当にインストールすれば済む話だけど、手っ取り早くやりたい時には、Authen::TypeKeyはTypeKey.pmの、Class::ErrorHandlerはErrorHandler.pmのSourceというリンクのリンク先を、以下のような構成になるように取得してやればよい。

+-- sample.cgi （上のサンプルCGI）
+-- lib/
    +-- Authen/
    |   +-- TypeKey.pm
    +-- Class/
        +-- ErrorHandler.pm

これで、sample.cgiにアクセスすれば、最初はエラーが、TypeKey認証を済ませるとTypeKeyニックネームと名前、メールアドレスが表示される。実際に見てみると分かるのだけど、QUERY_STRINGには平文でemail、name、nickが入ってきている。これらとタイムスタンプ、シグネチャの照合辺りを、Authen::TypeKeyがやってくれている。

こういう話は、TypeKeyログイン画面でトークンを調べて、URLを登録するところから始めて、Walrus, Digit.にまとめておかなきゃと思うのだけど、とりあえずここにメモ。

KanaWikiは4つの王国からできている。

リンク 編集

KanaWikiをGoogleで検索したら、こんな記述が見つかった。

The High Kingdom of Kanawiki is made up of four kingdoms. They are the Kingdoms of Hawai'i, Maui, Kauai and O'ahu. The High Kingdom was created in the early 20th century, shortly after the Empire of Japan captured Kauai, Lanai, and former Russian Polynesia (modern Nittato) from Russia in the First Russo-Japanese War of 1903-1905. The official language is Kanawikian, but most speak a creolized form, with significant influence from Japanese.
Kanawiki - IBWiki

こんな感じ？High Kingdomに相当する日本語を思いつけないけど、連合王国みたいな感じでしょうか。

High Kingdom of Kanawikiは4つの王国から成っています。Hawai'i、Maui、Kauai、そしてO'ahu王国です。このHigh Kingdomは20世紀初頭、日本帝国（Empire of Japan）が第一次日露戦争でロシアからKauai、Lanai、そして当時のRussian Polynesia（現在のNittato）を占領したすぐあとに作られました。公用語はKanawikianですが、しかし大半は、日本語に大きな影響を受けたKanawiki creole語を話します。

データによれば、1906に成立、1954年に日本から独立。前王はハワイのカメハメハ大王10世で、現王はKauaiのニコライ大王。大王？国王の方が正しいのかな？よく分からないけど。というわけで、KanaWikiはかくも由緒ある名前らしいです。

本日はそんな感じで余談のみ。

はてなブックマーク・ボタンの作り方。

リンク 編集

Walrus, Digit.をちょっと前からWalWiki 2.1系で試験運用中なのですが、試験運用をはじめて以降にタイトルの文字化けしたブックマークが投稿されているのに気付いたので、改めてはてなブックマーク・ボタン（）のURL生成部を見直し。

基本的な考え方としては、はてなブックマークにログインして設定画面を開くとすぐにある、ブックマークレットの生成するURLらしきURLを作ること。このブックマークレットは、ページ・タイトルを含むURLを生成します。ですが、この日記の様に、ページ内に複数のタイトルの小文が並ぶ形式では、このブックマークレットを使ってもページタイトルでしかブックマークできない。それじゃ悔しいから、セクションごとにそこのタイトルを含むブックマークURLを、CGI側で用意しておこうというわけです。

これまでもWalWikiではそうしていたのですが、タイトルのURLエンコーディングはPerl流でした。これをJavaScriptが生成するものに似た、UCS-2コードで'%uXXXX'というつづりになるようなエンコード方式にしてみました。コードを抜粋すると、こんな感じです。

use Jcode;

sub add_hatena_bookmark_link {
  my ($url, $tite) = @_;
  my $icon = '<img src="http://yoursite.example.com/append.gif" alt="はてなブックマークに追加">'; 
  my $link = sprintf('<a href="http://b.hatena.ne.jp/add?mode=confirm&is_bm=1&title=%s&url=%s">%s</a>', &encode_like_js($title), &encode_like_js($url), $icon);
}

sub encode_like_js {
  my ($ch, $hex);
  my ($encoded) = @_;
  $encoded = join "", map sprintf("%%u%04X", $_), unpack "n*", Jcode->new($encoded)->ucs2;
  $encoded =~ s<%u00(..)>{ ($ch = pack("H2", $hex = $1)) =~ m<[^\w\@.*/+-]> ? "%$hex" : $ch }eg;
  return $encoded;
}

Walrus, Digit.には適用済みなのですが、Walrus, Visit.には未適用なので、Digit.の方でURLを確かめてみてください。そうそう、エンコード方法は、ほぼそのままこちらから持って来ています。質問者と回答者の両氏に多謝。あと文字化けしたブックマークについてコメントを下さったＯｈ！石さんにも多謝。

WikiのURL考。

リンク 編集

以前に諦めたことがあったWikiのURLがアレな点について、Wiki小話Vol.5におけるotsuneさんの「戦うblogに恋するWiki」あたりからまた気になりだしてる。

■ リサーチ：otsune提言

検討の起点として、現在のotsuneさんのアイディアを引用させていただく。

Wikiでいちいち「新規ページ」を作って投稿するのはまどろっこしい。 入り口は一つ。とにかく文章を投げればページが作成される。
ただページの名前をつける代わりに、英語圏のキーボードを打つのに慣れたユーザーの妥協案である「タグ」を入れる。 一行目はタグ。二行目からEOFまでが本文。 「タグ」は省略可能だったりする。 タグが省略された場合は一行目or本文が形態素分解されて接続詞を除去されたタグが付く。（はてなブックマークのキーワード抽出だと思いねぇ） タグの付け方が分からん場合は自然文で付けるのがよろし。適当に分解されて抽出される。
表示は「タグ」ごとに串刺しで複数ページが表示される。 タグを増やせば絞り込まれる。
　・wiki.example.com/perl.html　Perlタグの付いた全ページ
　・wiki.example.com/perl-wiki.html　PerlとWikiタグの付いた全ページ
　・wiki.example.com/mohican-perl-wiki.html　MohicanとPerlとWikiタグの付いた全ページ
みたいな感じで。
void GraphicWizardsLair( void ); // 「stdin/out Wiki」という持ちネタが有ったけど、Wiki話に行けないので放出

「〜恋するWiki」でotsuneさんご自身が提案されている内容の、より実装に近づいたアイディアだ。エッセンスとして...

• ページ名はつけない。
• タグをつける。つけないと、1行目から適当にそれっぽい単語が抜き出されてタグとみなされる。
• タグを基点として、ページへナビゲーション。

...ということになっている。

■ リサーチ：WikiのURLに関連する既存実装

このエッセンスを眺めていると、いくつかの既存Wiki実装が想起される。

まず、ninjinさんによるRandomNote。ページ名はつけない。コンテンツへのナビゲーションとして、最近検索された語（以下「検索語」）がサイドバーに並べられる。初期状態では全てのページが、検索語選択時にはマッチしたページが、更新日付順に一定件数ずつ表示される。ページ名などによるリンクの機構はないが、検索語は全てオート・リンクされ、コンテンツ間をつなぐ。編集者によるタグか、利用者による検索語かという違いはあるのだが、どちらもページ名のナビゲーションから脱却した表裏の方式だ。

次に、江渡さんによるqwikWeb。ページ作成時のページ名がURLの元になる。ただし、ページ名が英数字だけではない時には、ページ名ではなく連番でURLが決められる。ページ名は各ページ・コンテンツの1行目に記述されており、ページ名を変えてもURLは変わらない。使ってみると、ページの内容に即したURLを付けたい、でも汚いURLはごめんだ、という辺りの心理的バランスによくマッチしていることに気付く。特に意識しなければきれいなURLができるし、意識したければ英数字で初期ページ名を指定すれば良い。

ところで、otsuneさんの「〜恋するWiki」を受けて、たろうさんが実装したKanaWikiが、昨日の小話で紹介されている。「ウィキネームノ・ニホンゴカ」のように、中点を含むカタカナ語の連なりがページ名と認識される。しかも、それをローマ字表記に直したものが、URLとして採用される。これは逆に、ページ名ベースのURL決定という機構の中で、日本語ページ名に対してどうきれいなURLを作成するか、という好例だ。ただし、このためにページ名に対して制約が加えられるのは甘受する必要がある。

■ 提言

ここまでを見直すと、Wikiの「コンテンツ‐ページ名‐URL‐ナビゲーション」という強固な結びつきを、もう少し緩めてやることを、それぞれに一度検討すべき時期に来ているように思われる。

一つ目の方法は、コンテンツとURLの間を、ページ名ではなくタグ（stdin/out Wiki方式）や検索語（RandomNote方式）で結びつけ、タグや検索語によって、コンテンツへのナビゲーションを行うこと。URLはきわめて自由に、というよりblogなどのように意味を持たない連番などでつけることができ、きわめてシンプルになる。この方法は、Cool URIの考え方そのものでもある。

二つ目の方法は、ページ名とURLの結びつきを緩めること。qwikWebのように、可能であればページ名をURLに反映するが、それが難しければあきらめる。ページ名とURLを直結するのではなく、ページ名→URLを辞書引き可能にし、できればURLからページ名を想起させる程度で満足しておく。

■ 考察

シンプルで、変更の少ないCool URIは非常に有用だ。しかし、このCool URIを説明したページの「http://www.w3.org/Provider/Style/URI」というURLを見れば分かるように、ページ名やページ内容を想起できるURLは非常に親しみやすい。Wikiにおいて、過去に何度か完全にURLをID化する試みがありながらも浸透しなかったのは、この親しみやすさというもう一つの有用性、それからセンチメンタル・バリアの厚さによるだろう。傍証を挙げるなら、私が目にしたWikiにおけるURL論争は、ほとんどの場合Cool URIを目指すためではなく、日本語ページ名に基づくURLがまるで親しみにくいことから起きている。

したがって、現実的には二つ目の方法が受け入れられることが多いと思われる。そこで意識しておきたいのは、いかにURLを親しみやすく保つかで、カナ→ローマ字変換というアプローチと、KanaWikiという実装の存在を活かすべきだろう。例えばlivedoor Wikiでは新規ページ作成時に読み仮名を入力する仕組みになっており、これがページ一覧でのソートとブロック化に使われる。単にこのために使うだけであれば面倒な感を拭えないが、KanaWiki機構と組み合わせれば、非常に有用に使えそうだ。

WalWikiにこの方式を適用できるかということになると、まずURLとページ名の切り離し自体が可能かという問題になる。おそらくqwikWeb方式で一行目をページタイトルとする方式になるだろうが、現在のWalWiki（および、おそらくはYukiWikiでも）では、レンダリング時にページの概要としてコンテンツの1行目の取得する部分が、しばしばボトルネックになっている。ページ名取得でも同じことをするとなると、こうした負荷の懸念があり、検証と検討が必要である。

Wiki小話Vol.6のための資料とリンク集。

リンク 編集

今晩のWiki小話Vol.6のために用意した資料とリンク。

■ 発表資料

• Wiki_Check-it-out.pdf（PDF形式、245KB）
• Wiki_Check-it-out.ppt（パワーポイント形式、969KB）

■ Wiki紹介/比較サイト

• Moongift
• WikiYallow
• 資料/Wiki関連/Wikiエンジン/インデックス
• WikiMatrix
• 資料/Wiki関連/WikiMatrix

■ Wikiエンジン

• Wifky、HikiFarm
• RESTWiki、7wiki、MirrorMan、Wema、S式プラグイン
• RandomNote、Calki、qwikWeb、BitChannel、PalmWiki
• HashedWiki、YukiWiki（AsO改）

どんな話だったのかは聞いた人だけのお楽しみ。

Perlフレームワークを使わないということ。

リンク 編集

ちょっと前に、「Elementary, ... use Catalyst qw(初挑戦);」と「ささやかなる実験場の開発室（HSJ.jp）: ActivePerlでCatalystにチャレンジ!!」「ささやかなる実験場の開発室（HSJ.jp）: 続・ActivePerlでCatalystにチャレンジ!! (DB篇)」を真似してCatalystを触ってみた。少しだけポイントをメモしておくと...

• Catalyst::Helper::View::TTはCPANインストールできる。CPANインストールすると、Template-Timerも依存モジュールなので自動的にインストールされる。
• スケルトンのディレクトリ構成は、現在の版ではちょっと違う（違ったような気がする）。○○がありません的エラーは、ディレクトリ構成とエラー位置を見比べて直せば対処できる。

...というところ。「○○がありません的エラー」の解決さえすれば、上記2サイト3ページのスクリプトでお試しできると思う。

CGIモジュールをバリバリに（少なくともOO的に）使っている人なら分かるのだけど、やってみるとゾクゾクするほど気持ちがいい。処理に即した最適なデータ保持とかいった楽しい悩み（時間消費の最大原因）がなくなるので、さくさく作業が進む。かんさんなんかこう言っている。

何事にも可逆性と不可逆性があると思うんだけど、Webアプリに関しても不可逆性がある。 少なくとも俺は仕事でフレームワーク上でスマートに（まあ、あまりスマートに書けてないんだけど）書くようになってから、所謂「CGIプログラム」な配布物を書くのはもう無理だと思ったし、実際無理のようだ。
なんでEagletなのか - てくのーと2.0

その通り、フレームワークを利用した開発スタイルはとても甘美な蜜の味。上述の通りちょっと近寄ってみただけで、蜜の香りでクラクラしたぐらいだ。

でも、僕は専用サーバを借りたり、自宅サーバを持ったりする気はないし、一方でWalWikiそのほかを今後も使っていくし、イコール作っていく。最低限、そこらへんのレンタルサーバに簡単に設置できるものじゃないと困っちゃうし、PerlフレームワークではCGI::Application::Frameworkでもそう簡単には動いてくれなかった。

そんなわけで、僕はここらで引き返したし、当面はPerlのレベル6ぐらいでも作れて、レベル5ぐらいでも使えるものを、せいぜいCGI::Applicationぐらいまでを使って作り続けると思う。

WalWiki 2.1系。

リンク 編集

時々作っては元に戻してをしているWalWiki 2.1系ですが、Walrus, Digit.に「WalWiki2.1/試験運用というページを作成し、試験運用と試験運用版の配布を始めました。

WalWiki 2.0系と外観上はほとんど変わらないのですが、YukiWiki 2.1で採用されたプラグインが利用できる（＋ちょっと強化されている）点と、Unicodeで運用できるようにするための修正をいくつかしているところが大きな違いでしょうか。また、Unicodeに移行したいという場合は、データ変換なども大変なので、以前のconvert.cgiに相当する移行ツールも用意しています。

おまけ（というか別件というか）ですが、Unicode周りをまとめていて、ちょっと調べたことをDigit:Perlメモ/日本語の扱いにメモしておきました。

• Unicodeの破線を全角チルダに変換する。
• Unicode文字の正規表現。

こうやってちょっとずつ、それもずいぶんと間をおきながらページの持つ情報が増えていくのも、Wikiサイトの特徴じゃないかな。

WikiMatrix?の特徴リスト和訳。

リンク 編集

WikiMatrixという海外のWikiエンジンの情報に強いWiki情報サイトがあります。特徴的なのはWikiの特徴リストによる比較。複数のWikiエンジンを選択して一覧表で特徴比較、気になったものは（虫眼鏡アイコンをクリックして）スクリーンショットなどを含む詳細表示、といった見方ができます。

今時のWikiの特徴リストとしても有用で、Wiki小話Vol.6のネタ探しにも便利だと思ったので、比較に使われている特長リストの項目などを訳してみました。

• 資料/Wiki関連/WikiMatrix - Walrus, Digit.

ちょっと記法周りが気になったのだけど、Markdown、Textile、BBcodeといった記法が載ってくるところが、意外と意識されているのだなという気持ち。日本語版WikiMatrixだとText::Hatenaとかが入ってくるのかな？

圏外からのひとこと　避難所 - NHKはどこに行く？

リンク 編集

多分合理的な「戦略」と言っちゃうと、essaさんご自身が追記されているように、ちょっと微妙。ただ、「合理的な戦術」といえば、その通りだと思う。

NHKに限らず、現在団塊世代をつかまえている企業は、ひたすらこの世代を逃がさないように余計なことをしないのが、最も合理的な戦略になる。 ジリ貧で発展性はないけど、へたに年齢層のレンジを広げようとして団塊世代が離れてしまったら致命的。
圏外からのひとこと　避難所 - Moleskin Diary - NHKはどこに行く？

NHKをテレビ放送会社だと思ってるとしっくり来ないのだけど、NHKにとってテレビ放送は一つの商品でしかないと見切ってしまえば、上の指摘はいわゆるPPMに沿った指摘だ。

ボストン・コンサルティング・グループは，製品ライフサイクルを市場成長率，経験曲線効果を相対的市場占有率と解釈して二つの軸とし，自社製品を４つの象限に位置づけることにより，それぞれにどのように経営資源を配分するべきかを示すＰＰＭ（プロダクト・ポートフォリオ・マネジメント）を開発しました。

ＰＰＭ＜経営戦略と情報化計画＜経営情報システム＜Ｗｅｂ教材＜木暮

NHKにとってテレビ放送は現在、金のなる木で、当然ながら自然にゆるゆると負け犬に向かう。essaさんの言う「ジリ貧で発展性はない」状態。でも流れに逆らって花形商品に押し戻すのは非常に難しい話で、かといって流れに沿って問題児を経由して返り咲きを狙うと、そこから負け犬直行矢印に乗っちゃう可能性もある。これが「致命的」の正味の部分。だから、NHKのテレビ放送に対する戦術としては「金のなる木」延命措置、つまり「現在団塊世代をつかまえている企業は、ひたすらこの世代を逃がさないように余計なことをしないのが、最も合理的」ということで良いと思う。

戦略レベルになれば、テレビ放送という商品が金を生むうちに、少しでも多くの有望な問題児を生み出し、個々に花形に育て上げるべく戦術を練るということになる。インターネット・コンテンツなのか、インタラクティブテレビ番組なのかも知れない。「花形」選手かどうか知らないけど、出版やラジオ放送というプレーヤーも既にいる。膨大な（と言われる）映像資産を元に、次世代教科書（公立学校の生徒が全員購入する）なんてのも収益になりそう。

「NHKに限らず、現在団塊世代をつかまえている企業」は、あと数年以上は「金のなる」商品を持ってるってことだ。木陰でお昼寝にかまけてたり、その木の手入れに勤しむだけなら、将来は枯れた樹下から逃げ出す「負け犬」確定。だけど、今に限っていえば苗木を植える猶予を、それも数年間というスパンで与えられた「勝ち続ける組」最有力候補に違いはない。

ActivePerlのprintf。

リンク 編集

仕様に微妙な違いがあるのね。printfの指数形式での浮動小数の表示時、通常のPerlではe+03とかになるんですがActivePerlだとe+003になるんですよ。困るなぁ。
ActivePerlとPerl - 幾霜::残日録::2006/02/13 (月)

我がWindows XP + ActivePerl 5.8 build 815でも"e+003"になるなぁ。ちなみに、inetd（BSD系）上のperl5.005、perl5.8.5ではいずれも"e+03"になる。

あ、でも"perldoc -f sprintf"とかを見ると、なんか書いてあるな。

Note that the number of exponent digits in the scientific notation produced by %e, %E, %g and %G for numbers with the modulus of the exponent less than 100 is system-dependent: it may be three or less (zero-padded as necessary). In other words, 1.23 times ten to the 99th may be either "1.23e99" or "1.23e099".
sprintf - perldoc.com

ここはシステム依存で、指数部が100未満の時の表記は3桁以内なら表記が揺れても別に良いのかな？つまり、1.23×10の99乗は"1.23e99"でも"1.23e099"でも良い（...って、In other words以下の直訳じゃないか）。

技術者集団としてのlivedoorを尊敬できない。

リンク 編集

技術者集団としてのlivedoorは、本当に技術力のある集団だと思います。この辺りについては、ITmediaニュース：「こんな時だからこそ安定したサービスを」――ライブドアの技術者魂を基点に、ライブドアが意外と技術系っぽいことについて -- 圏外からのひとこと出張所(ライブドア編)、naoyaのはてなダイアリー - ライブドアの技術の話、にぽたん休憩所 - ライブドアの技術に限らない話などを読み進んでいただくと良いかと。そもそも僕などには、エッジ、オン・ザ・エッジのイメージが抜き難く、やはり1と言って2に下らないPerl企業の一つなのです。

じゃあ、今のWeb事業を営む部分のlivedoorを無条件に尊敬できるかというと、ちょっと微妙。

エッジ、オン・ザ・エッジにある種の憧憬を抱いていた身としては、ライブドアになってずいぶん変わったな、この地図でいえば「海を渡っていってしまったな」という感覚がありました。 それがこのところのライブドア騒動で、ポータル、そして技術者集団としてのlivedoorが単体で独自の色を見せ始め、「そうそう、livedoorってこうだよね」という風にちょっと嬉しく思ってたりします。
Walrus, Visit. - ライブドアはITバカ世界地図のどこに置く？

実はここでもう一つ変わったところを感じます。昨日付けでlivedoor knowledgeが提供開始されているのですが、Brodaband Watchの記事では「サイトのデザインは米Yahoo!のQ＆Aコミュニティサービス『Yahoo! Answers』を踏襲したものが採用されている」と紹介。もちろんこんな文言はプレス・リリースには含まれていない、記者の付け足しなのですが、さらに、この記者が自身のブログで、次のように語っています。

送られてきたニュースリリースのリンクをクリックしてサイトを開いたらびっくり。記事でも紹介した通り、忠実なまでにYahoo! Answersを模したデザインです。
こうした事例は今回だけでななく、SNS「livedoor フレパ」ではmixiを、写真共有「livedoor PICS」でも米Yahoo!のFlickrにそっくりなデザインを採用しています。 そもそもライブドアのTOPページ自体、Yahoo! JAPANを非常に意識した作りになっていますし、これもライブドアの戦略の1つなのでしょう。
Broadband Watch編集部ブログ: そのデザインは誰のもの？

どんな技術者をスゴイと思うかと聞かれれば、技術力の秀でた人。でも、どんな技術者をカッコイイと思うかと聞かれれば、やはりオリジナルな成果を挙げている人です。その点で、livedoorが最近リリースしたWebサービスには、オリジナリティを感じない。それから、オリジナリティへの畏敬も感じない。例えば、livedoor PICSの時にこうした評がありました。

livedoor PICS がリニューアルして、Flickr クローンに。livedoor フレパ, オークション についでここまでやるかのコピー具合。
そうそう、「Flickr みたいのがほしい」んじゃなくて「Flickr がほしい」んですよね。この戦略は正しい気がするなぁ。
livedoor PICS: Yet another Flickr clone: blog.bulknews.net

ユーザの欲しいベストのものを提供するのは正しい戦略で、フォト・アーカイブという局面でユーザがFlickt以上のものが欲しいというのなら、それにあった戦術を選ぶのも正しいことでしょう。大ポータル企業によるFlickrクローン提供って、利用者のスケール・メリットとか、他サービスとの連携メリットが加わるから、戦略にあった戦術という意味では合格でしょう。でも、大ポータル企業には、Flickrというサービスを買い取るとか、Flickrと提携を結ぶといった戦術だって許されたように思います。

大企業が、定評あるオリジナル・ワンを、自社で拡大再生産する。それは確かに錬金術ですよね。費用が小さく効果の約束された、Webサービスの錬金術。

でも、それが行頭の各エントリにある「技術者魂」「クリーン」「技術者のマインド」といった言葉にふさわしくは思えない。僕が思うに、技術者マインドって、オリジナリティと、それを生むアイディアやセンス、それを実現する技術への誇りでできています。そしてオリジナリティを示した先駆者への誇りと憧れ、少しのやっかみで彩られています。Webサービスの錬金術はそんな「マインドを感じる振る舞い」ではなく、そうしたマインドを蔑ろにする「心無い仕打ち」に感じられてしまうのです。

Webサービスの錬金術の使用は、技術者マインドよりビジネスの論理が先行した、ライブドアになって変わっちゃったところの一つだと思っていました。だから、株価の錬金術から（その破綻によってでも）抜け出した時に、Webサービスの錬金術も終わるだろうと喜びました。そうではなかったけど、でも技術力はもともと評価されるに足る会社で、Sledgeの公開などで技術者マインドを感じさせたオン・ザ・エッジが前身で、僕が（そのイメージをかも知れないけど）尊敬していた会社なのです。今でも尊敬したいし、それだけのポテンシャルはあって、そうなっても良いタイミングでもあるはず。

簡単にまとめちゃえば、今のlivedoorは技術者集団としても素直に「リスペクト！」と口にしにくいものを感じます。でもこの会社には、やっぱり尊敬できる技術者集団であって欲しい、と。

もう「ウィキペディア」というのはやめないか？

リンク 編集

先日は私なりにデータなどを出しながら、Wikiの特性を活かした成功形を、次のような三つのサイクルの「いずれか」を持つことではないかと示した。

• 「多くの執筆者によって、広く新しいコンテンツが提供され、短期的なアクセス数が多い」
• 「頻繁な更新によって、深く掘り下げられたコンテンツが提供され、中期的なアクセス数が多い」
• 「適切なナビゲートとメンテナンスによって、情報の寿命が長く保たれ、長期的なアクセスが多い」

このサイトは、第一のサイクルの形成はできていない（一時はあったと思うけど、私の怠惰のせいで大半が失われた）けれど、ありがたいことに第二、第三のサイクルは何とか形成でき、ページ・ビューだけを基準にすれば成功の範疇だと思う。これに対して、全てのサイクルを比較にならないサイズで形成している、文句なしの成功サイトがウィキペディア（Wikipedia）だ。現時点で、ウィキペディア日本語版を開いてみると「約179,638本の記事があります」とのこと。第一のサイクルについても、数字を持って成功が証明されていると言って異論は出ないだろう。

だから、Wiki論をやると必ずウィキペディアが引き合いに出される。でもね、もう「ウィキペディア」というのはやめないか？

話は単純なんだ。例えばGoogleは検索ページを提供し、莫大で志向性の強いページ・ビューを獲得し、そこに広告を表示して利益を上げている（らしい）。これは検索サイトにおける、華々しい成功例の一つだ。そこで、これを引き合いに検索エンジンが語られる。

「社内の共有ファイルサーバを対象にした全文検索ページを設置したいという件だが、検討結果は？」
「はい。これは実施しても失敗に終わると思います。」
「ほう、なぜだね？」
「Web検索での成功例としてはGoogleを挙げられますが、これは莫大で志向性の強いページ・ビューを獲得し、そこに広告を表示して利益を上げています。しかしここではGoogle、Yahooといったガリバー企業が既に存在し、社員だけをアクセス層とした社内検索ページでは、十分なページ・ビューも広告収益も見込めません。」
「分かった。ではこの話は打ち切ろう。」

...変だよね？だって多分、共有ファイルをもっと効率よく利用できるように、検索を容易にしたい、という話のはずなんだ。どこにもGoogle的に直接儲かる成功をする必要はない、どころかお金を払っても検索ページをおきたいところなのに、なぜかGoogleにビジネスで勝てないからってやめちゃうんだ。

確かに、ウィキペディアというのは輝かしいWikiサイトの成功例だ。でも、はっきり言えば、ウィキペディアはもう特殊な成功例だ。多くのWikiサイトは、ウィキペディアのようにどんどん新しい参加者を集めて成長していくようなものじゃない。次のエントリの指摘が、むしろ一般的なWikiサイトの使われ方を捕らえている。

wikiはコミュニティを作るツールではなくてコミュニティが使うツールなんじゃないかと。
@ parallel minds: wikiとコミュニティ

一人で、あるいはある程度固定的な（そして参加意識の高い）メンバーによるコミュニティで、手軽にWebサイトを運営したい。それが実現できるツールは、ということでWikiが選ばれる。じゃあ、Webサイトが運営されていれば成功のはずだ。そして、そのサイト運営が苦痛にならず、営々と続けられると第二の成功サイクル、第三の成功サイクルが形成されてくる。

だいたい、「共同編集ツールだ」というなら、まずウィキペディアじゃなく雑誌編集を思い浮かべればいいんだ。雑誌って各ページを別々のライターが担当する共同編集媒体だけど、ほとんどの雑誌は参加意識（職業意識）のある、ある程度メンバーの固まったライター達が、大半のページを作成するんじゃないか？そりゃ読者なんかからの投稿ページや広告をかねた寄稿ページもあるけど、完全に外からの投稿だけで紙面の大半を埋めているのは、ショッピング・カタログとかアルバイト・ニュースといったものだけだよ。

だからね、Wiki論をやるなら、もう「ウィキペディア」というのはやめないか？あれは特殊例だ。とびっきりのキラキラの貴重な、だけど特異な成功例だ。取り上げたっていいけど、ウィキペディアをWiki一般における成功例として挙げてたり、ましてやウィキペディアだけを引き合いにしてWiki全般を論じているような文章は、私はもう読む気はしない。笑い話のネタにしたり、貶すために読んでおくことはあるかも知れないけど。

Wikiエンジン/インデックス公開。

リンク 編集

Walrus, Digit.の方に「Wikiエンジン/インデックス」というページを作成、公開しました。もっとも、ページ自体は数日前からアクセス可能で、ちょこちょこ助けてくれた小人さんもいました。ありがとうございます。

情報源
　・MoongiftのWikiカテゴリ
　・WikiYallowのエンジン検索結果
　・日本発の wiki クローンリスト
　・日本発の wiki クローンリスト2
上記情報源に載っているものをマージしました。 あとは、各エンジンの配布状況と、備考欄を現状（2006年2月1日前後）で確認中。
Wikiエンジン/インデックス

そもそもの経緯は、以下のようなものです。etoさんの日本のスゴイWikiを紹介したいね、という話が発端。

日本のWikiエンジンは世界の他のWikiエンジンの状況から見てみても，非常に特殊なWikiエンジンが多数ある．そのような存在を，日本ローカルな状況に置いておいてはもったいない．それらがあまり知られていないのは，やはり日本語の壁が大きい．英語で紹介すれば，もう少し知られるようになるはずである．
Wiki小話Vol.5 - えとブログ(2006-01-23)

じゃあ、まず日本のスゴイWikiを発掘。それには「知ってる限り」でやってもつまらないので、他薦Wiki博覧会「このWikiがスゴイ！」をやろうよ、と展開。

この話を後押しする意図も含め，次回のWiki小話Vol.6は「このWikiがすごい」と題して，自分が好きなWikiエンジンを褒めたたえるというプレゼン大会にすることになった．時期は，2月の後半を予定している．主な目的が「日本のWiki状況をアピールする」という点にあるので，その趣旨にそったプレゼンを募集することになると思う．
Wiki小話Vol.5 - えとブログ(2006-01-23)

日本のスゴイWikiと言えば、WikiばなVol.4「Wiki博覧会」ではかなりスゴイWikiが集まったと思います。
ですが、あれから早や1年弱。じゃあ、今だとどんなWikiがスゴイのか？どんなWikiがとんがってるのか？そんな興味が沸いてきたので、みんながスゴイと思うWiki、とんがってると思うWikiを聞いてみたいと思います。
つまり、他薦Wiki博覧会「このWikiがスゴイ！」。2月の小話ということで、やれたらと思っています。
Wiki・ばな・うら・ばな - Wiki小話Vol.6企画中。

そこで僕なりにスゴイWikiを探そうと思って、まずは良質なガイドである上記4箇所を効率よく利用できるインデックスを、ということでした。もちろん、これからWikiを使いたいなと思った人のWiki探し、Wikiを作った人の、アナウンス先の確認（WikiYallowに自分で追加、更新できますし、Moongiftには紹介用のメール・フォームがあります）にもなるでしょう。できる限り、役立ててもらえればと思います。

Wikiエンジン/インデックスは今後も、各Wikiのガイドまで手を広げるのではなく、あくまで各エンジンのサイトおよび上記ガイドサイトへのインデックスとしてメンテナンスしていくつもりです。

Wikiサイトの成功形。

リンク 編集

「サイボウズ株式会社 経営企画室 安田智宏による IT 業界・技術動向レポート『経営企画室 調査日報: wiki』」にここ数日、Wikiについてのエントリが意欲的に挙げられている。関連エントリなどとあわせて、ご一読いただきたい。

• 経営企画室 調査日報: wiki。
• 経営企画室 調査日報: wiki の特徴と利用例
• 経営企画室 調査日報: wiki がブログほどには盛り上がりにくい理由
• 経営企画室 調査日報: wiki による「共同編集」の難しさ
• 経営企画室 調査日報: wiki の普及を妨げる技術的な障壁
• 経営企画室 調査日報: wiki をベースにしたソフトウェア「Socialtext」の考察
• YAMDAS現更新履歴 - サイボウズ株式会社経営企画室によるWikiの分析
• Hatena::Diary::int - 成功する Wiki の条件。

これらの意欲的なレポートには敬意を表すと共に、念のためにこれらの議論から抜け落ちているように感じられる点を指摘しておきたい。

■ 「Wikiサイトの成功形」の論旨を追ってみる

各エントリからは、Wikiの成功形を次のような議論で考えているように読み取れた。

• (1) Wikiサイトの成功度合いはページビューである。
• (2) アクセス数確保には、Wikiサイト上の情報が「多い」「広い」「新しい」の三面での充実することが重要。
• (3) 情報の充実には多くの活発な更新者（執筆者/編集者）が重要。
• (4) 更新者を集めるには...
• 広く興味を集めていながら、情報の充実・集約が遅れているニッチ・カテゴリを取り上げる。
• 扱うカテゴリ（主題）は一つ。ただしそこから引き出せる情報は多い。
• 垂直立ち上げ型。スタート時のコンテンツ量がないと、更新者（の候補であるサイト訪問者自体）が生まれない。
• Wiki利用の習慣を広める。Wiki普及の技術的な障壁を取り除く。

(1)、(2)については、主に経営企画室 調査日報: wikiから採っている。成功基準については、定量的に理解できる部分としては以下があった。

上に挙げた wiki の左下部の「アクセス統計」のところを見ると昨日(1/23)のアクセス数が 8587 となっています。これは個人が運営する単一のサイトのアクセス数としては十分多い部類に入ると思います。
そして変更履歴を見ると 1/20 から毎日いずれかのページが更新されています
経営企画室 調査日報: wiki の特徴と利用例

次の(3)については、経営企画室 調査日報: wikiとHatena::Diary::int - 成功する Wiki の条件でほぼ一致している。いくつかの部分を引用しておく。

wiki がその本領を発揮するのは、インターネットを介して多くの編集者を集め、「共同で有用な情報源を構築する」という目的のもと編集者が適切に協働できたときであるといえます。
経営企画室 調査日報: wiki による「共同編集」の難しさ

見た雰囲気ではサイト管理者の方が一人で更新されている様子で、特に誰かに参加を呼びかけるつもりもなく、単なる「自分用」なのかもしれませんが、これが複数のユーザーによって情報を持ち寄る形になれば情報の充実度は今より飛躍的に上がっていくのかもしれません。
経営企画室 調査日報: wiki がブログほどには盛り上がりにくい理由

コンテンツが揃わないまま月日が経過してしまった場合、それは忘れられた Wiki になる。参照されなければ執筆者は増えない。執筆者が増えなければコンテンツは増えないまま。
Hatena::Diary::int - 成功する Wiki の条件

つまり、Wikiの成功形は「多くの執筆者によって、広く新しいコンテンツが提供され、アクセス数が多い」状況になること、ということだ。これが成功形だという点については賛成。でも、それだけが成功形なのか？

■ Walrus, Digit./Visit.は失敗例？

この話に疑問を抱いたのは、自サイトのアクセス数がW-ZERO3 Wikiに比べてそれほど少ないとは思えなかったからだ。

Walrus, Digit.とWalrus, Visit.はオープン当初からのWikiサイトで、しかも今時静的HTMLサイトとも、blogサイトとも連動していない、100%ピュアWikiサイトだ。そこで上の条件と照らし合わせてみると、Walrus, Digit.とWalrus, Visit.は(2)〜(4)の条件を満たしていない。2000年ぐらいから開始されたサイトで、更新されなくなって数年というページも多い。情報はPDA、Web、Perl、Inetd関連と日記と取り止めがなく、カテゴリが絞られてもいない。そのくせ、各カテゴリ内での網羅性の高くもない。

でも、両サイトとも、(1)のページビューは悪くない。普段はアクセス・カウンターも使っていないので、上エントリ群を読んでから、あわててサーバに残っている一週間分のログをWebalizerにかけてみた。1枚目のスクリーンショットを見ると、2月のアクセス数はVisit.が12,728件、Digit.が7,294件。2枚目を見ると、解析済みのヒット数のうち9割は2月1日のものだから、1割差っぴいてもVisit.が11,500件/日ぐらい、Digitが6,500件/日ぐらいとなりそうだ。

Wikiサイトの成功度合いをページビューだとすれば、上の伝でいけばどちらも「個人が運営する単一のサイトのアクセス数としては十分多い部類」に入るはずだ。もちろんこの日だけが突出して多いわけじゃない。その前6日間の平均を示す、1月の1日の平均アクセス数は55,974件。2月1日の46,621件というのは、だからむしろ少ない数字だ。

個人サイトとしては成功している。それにもかかわらず、上で想定されたWikiの成功形ではない。他にWalWikiを使っていただいているサイトでは、memn0ckさんのWikiが、Wiki部分だけで12月が26,222件/日、1月が18,293件/日だったとのこと。ここも同じく、アクセス数は多いが、「成功形」から外れそうなサイトだ。memn0ckさん自身からも、この話で自身のサイトについてこうコメントをくれた。

PVとか勝手に編集されていくという意味では成功してる部類に入りそうですが、「テーマがひとつ」とかからずれてるし、中途半端なページも多いし、どちらかというと“自Wiki”ということですかね。

こうした個人Wikiは成功例に含まれないのだろうか？あるいは、個人Wikiは、実はWikiの恩恵なしで運用されているのか？

■ Wikiサイトの成功要因

Wikiサイトのページ・ビューを決めるのが、ページ数、ひいては更新者数か、ということをもう少し追ってみたい。参考データとしては、livedoor Wikiのランキングが有用だ。以下に現時点（「2006.02.02 12:00 更新」と表示されている）のランキングから、トップ10を並べてみる。

太字は複数のランキングでトップ10入りしているものだ。該当するのは2サイトしかない。

こうして見ると、明らかにページ・ビューは、ページ数と更新者数だけじゃ決まらない。でも、実はページ・ビューが、ページ数や更新者数だけで決まらないのは、それほど意外でもない。情報の価値が「『多い』『広い』『新しい』の三面」だとは思えないからだ。この三面は重要だけど、三面だけじゃ足りない。

まず個々の情報の深さが挙げられる。Wikiで言えばページの充実度だ。例えば、上表に挙がっているものだと、「レースクイーン補完計画」の誰かの紹介ページと、「ぱにぽにWiki」の誰か登場人物の紹介ページを見比べて欲しい。検索に引っかかったり、そこからこのページを訪れたり、後になって再訪したりといった機会の多寡には随分差があることが想像できる。

次に、情報の寿命が挙げられる。賞味期限といってもいい。上表に挙がっているものだと「Newslink Wikiβ版」などは必然的に各情報の賞味期限は短いだろう。逆に、「livedoor BlogのデザインをカスタマイズするWiki」などは、各ページがlivedoor Blogがなくならない限り見られることになるだろう。「ぱにぽにWiki」なら、少なくとも連載かアニメが続く限りだ。寿命の長い情報が多ければ、個々のアクセス数のロング・テール現象が、サイト全体のアクセス数を押し上げる。

Wikiサイトを含めたWebサイト全般の成功度合いは、ページ・ビューで測れる。ページ・ビューを生み出すのは、そのサイトの価値、そのサイトの持つ情報の価値だ。情報の価値がページ数だけで決まらないなら、ページ数と更新者数≒成功の度合いという近似は間違っている。

■ 情報の価値とWikiの効果

情報の多さ、広さ、新しさは重要で、それはページ数を指標にすることができる。それはその通り。でも個々の情報を掘り下げることも重要で、これはページ数で表わせない部分だ。強いて言えば更新回数やページサイズが指標になるかもしれない。それから、個々の情報の寿命も重要で、これもページ数では表わせない。強いて言えばページ作成からの期間と、最後のメンテナンス時期を指標にできるだろう。そして、ページ数という指標には更新者数はよく効くけれども、個々のページのサイズや更新回数、作成されてからの期間、最後の更新時期にはあまり効かない。

手前味噌だが、特にWalrus, Digit.の情報は古くからのものが多く、追加頻度は極めて少ない。時々更新するページはあるし、大きなページは多い。そして、はてなブックマークやTechnoratiなどを見ていると、少なくとも5日に一度ぐらいはこうしたページがブックマークされ、言及される。つまりリピータ効果とロング・テール効果の集大成が、Walrus, Digit.の6,500件/日の正体だ。

Wikiサイトの情報の価値と指標、その効果をまとめなおすと、次の3つを挙げられる。

これらの指標のうち、ページ数には、Wikiは「共同編集可能」という特性が効いてくる。他サイトの数倍の執筆者を要することができるので、単純計算で他サイトの数倍のページ数が作成されうる、というわけだ。この特性を活かすには、執筆者を確保すること、そのためには...ということは「『Wikiサイトの成功形』の論旨」で触れた。

ページごとの更新回数やサイズには、Wikiの「Web上で更新可能」という特性が効いてくるだろう。編集する時に元原稿を用意、アプリケーションで内容更新、サーバにアップロードといった必要がない。手間が少ないおかげで隙間時間でも更新でき、ツールやデータ不要なのでどこからでもどのパソコンからでも更新できる。またページ作成者は多くの場合そのページの情報を最も必要としている人で、最も読み直す人だ。読んでる際に誤りや不足に気付いたら、確実にその時に修正や追記ができる。

ページごとの存在期間、最後の更新時期には、直接影響するWikiの特性はない。むしろ、テーマやカテゴリの選び方が効いてくる。しかし、時系列に情報にアクセスさせるblogに比べて、一般的なWebサイトと同様に古いページにも新しいページにも同じようにナビゲートし、検索機能やオートリンク（これには賛否両論ある）により、短く多様なアクセス経路を提供し、アクセシビリティを維持する。情報の誤りや不足にかんたんに対応でき、「こびとさん」効果も加わってページの延命に役立つ。情報が古びても、新規エントリやページではなく、現行版を直接いじって最新版にすれば良い点は手軽だ。

■ 「Wikiの成功形」を考える

これらを踏まえて、Wikiの特性を活かした成功形は、次のような三つのサイクルのいずれかを持つこととまとめなおしたい。

• 「多くの執筆者によって、広く新しいコンテンツが提供され、短期的なアクセス数が多い」
• 「頻繁な更新によって、深く掘り下げられたコンテンツが提供され、中期的なアクセス数が多い」
• 「適切なナビゲートとメンテナンスによって、情報の寿命が長く保たれ、長期的なアクセスが多い」

Wikipediaは全てのサイクルを持ち合わせている。これは爆発的な成功といえる。W-ZERO3 Wikiは第一を回している（個人的には第二のサイクルも持ち合わせていると思う）。僕やmemn0ck氏のサイトは、第二、第三のサイクルを回している。これらは、個人サイトとしては「十分な成功」をしている。そして、個人サイトとしては、いずれかのサイクルを確立できれば、まずは成功ではないだろうか？

経営企画室 調査日報: wikiでは第一のサイクルを中心に話を展開されている。blogなど、短期的なアクセス数に効くツールが脚光を浴びている中で、これは当然の視点なのかもしれない。ただし、そこに限定した話であることを明確にするか、さらに第二、第三のサイクルに話を展開していかないと、Wikiの効果を過小評価することになりかねない。少なくとも、第二、第三のサイクルの効果が空論でないことは、僕やmemn0ck氏のサイトが多少の証明になると思う。