埼京線はよう止まるのぉ。今日も昼過ぎに出かけようとしたら止まっていた。東武線経由で振り替え輸送しているという放送が流れていたが、遠回りするのはきつかったので昼飯を食いがてら復旧を待ったが、1時間経っても復旧していなかった。とかしている間にまた体調が悪くなってきたのでいったん帰宅。

ちなみに関東地方のJR線におけるトラブル状況は、

• JR東日本関東エリア列車運行情報 - http://www.jreast.co.jp/train_info/kanto.asp（※このurlはRefererチェックして外部からの直リンクを弾いている模様。トップページに飛ばされちゃうんで、そこから「列車運行情報」-「関東エリア」を選んでください）

で分かる模様。ただしこのページのシステムは腐っているっぽい。ここで表示されている更新時刻は、情報が更新された時刻ではなくて、単にページをロードした（aspを実行した）時間を返しているだけだ。更新時刻が不明なもんだから、更新履歴がほとんど意味をなしていないし。

読むまで死ねるかっのPukiWiki版が仮公開されている。私ももともとこういう用途でWikiを使いたかったんだよな。情報系のコンテンツは、キーワードリンクとはとても相性がいいから、読書感想とか情報提供とかのコンテンツをWikiベースに移行すると気持ちいいだろうなーと思って。世の中にたくさんある日記系システムみたいな時系列系ではうまく扱えないからね。

でも実際にいろいろ試してみたところ、既存のWikiEngine（というかWikiの基本的な考え方）は私の使いたい用途ではうまく使えなかった（運用で回避することは出来なくもないんだけど、主用途の部分で工夫が必要なシステムは使いたくない）。しょうがないんで、自分でいろんなWikiもどきを作り始めて現在に至る、といった感じ。

ちなみに、私が既存のWikiEngineで我慢できなかったのは、キーワード＝ページ名であるという原則を曲げられないこと（名前空間とかグループとかで逃げているシステムもあるけど）。書籍情報なんかは書籍名をページ名にしたくなるけど、同じ書籍名の書籍なんていくらでもありうる。それらの情報を同じページにつっこむか、あるいはちょっとだけ名前を変えた別ページにするか、あるいはページ名自体にもっとユニーク性の高いキーワードを付属させるか（ISBNとか）、なんてことを考えはじめたらちょっといやになった。

あと、日本語系のWikiEngineは基本的に検索処理が遅そう。Namazuあたりと連携するシステムが出てくればいいけれども、普通にパターンマッチしていたんじゃ日本語ではつらい。たぶん日本語Wikiで英語と同じようにパターンマッチベースの実装をしていると、英語版よりもかなり早い段階で速度的な問題が出てくるだろう。まあその辺はそのうちNamazuと連携するとか、あるいは自前でインデックスを生成するシステムが出てくるだろうけど。

あともう一点はコンテンツ保護の問題。ユーザー認証周りを実装しているWikiEngineは少ないし、認証周りの仕組みも大仰すぎるかあるいはあまり使い勝手が良くない。まあWikiWayに則れば、Wikiには「誰でも編集可能」であることは必須なのかもしれない。でも「キーワード検索」で簡単につながるページを「手軽にWeb上で編集」できる「コンテンツ管理システム」が欲しいだけの用途で既存のWikiEngineを使おうとするとちょっと面倒くさい。

などなど私が既存のWikiを使わなかった理由を並べてみたわけだけれども、ただ私の場合は既存のWikiEngineについては、ちょっとだけ使ってみてそれから長いこと思考実験をして、それでもって使わないことに決めちゃったという経緯がある。実際に運用で回避しつつどのくらいのものができるのかは結構気になる。もしかしたら私が思考実験において出した結論の多くは、単なる杞憂である可能性もあるし。

というわけで、読むまで死ねるかっが、既存の（一般的な）WikiEngineをどこまで情報系コンテンツ管理システムとして実践的に活用できるのかとても注目している。って、実験台みたいに言ってごめんなさい。

TrackBack（嘘）

• Wikiで本の感想コンテンツを運営していくこと - http://bm.que.ne.jp/text/?200212a&to=200212071#200212071

TrackBack to

• Wikiで本の感想コンテンツを運営していくこと - http://bm.que.ne.jp/text/?200212a&to=200212071#200212071

ところで いしなおさんのオリジナルの WikiLike 、できれば使ってみたい人は山ほどいると思うんですけど公開しないのですか？そしたらそっちを使いたいかも。

WikiLikeは公開できるところまでたどり着ければ公開する予定ではいます。ただ、自分の中で乗り越えなければならない課題がまだいくつもあるので、予定は未定と言った状態です。

結構致命的なレベルの課題としては、

• まだ思想（コンセプト）自体が固まっているとは言い難い（IPWikiみたいに設計途中にコンセプト自体を投げ出す可能性がある）
• このコンセプトで続けるとしても、まだ現状のデータ形式を維持し続けるかどうかわからない（気軽にバージョンアップは出来ない。私も現在の実験スペースは最悪、データを捨てる覚悟をしている）
• Wikiレンダリングエンジンとして暫定的に、IPWikiSimpleのときに作った「複数のレンダリングメソッドを簡単に切り替えることが出来る」設計のものを使っているが、これは「Wikiライクなレンダリングメソッドとhnf風のメソッドを同時に成立させつつ、今後の拡張性も高い」設計のものに置き換えたい

なんてものがあって、これをクリアすることは自分の中で絶対条件です。

あと、ちょっと微妙な課題として、

• 現状はDBMS依存で作成しているが、公開するのならば動く環境を増やすために、ファイルベースでも動くようにしておくべきか
• データ入出力周りなんかは、新規に設計しつつあるフレームワーク上で動くようにしているので、もしもファイルベースで動くようにするのならば、フレームワークの方を完成させないといけない
  • でもフレームワーク側はWebアプリ関連の一通りの機能を持たせるつもりなんで、そっちを完成させるとなるといつになるかわからないなー。
  • あとファイルベースで簡単なDBMSもどきの機能（インデクシングによる検索の高速化とか）を実装するのも大変そうだなー。
  • っつーかまじめに作り始めちゃったら、フレームワークの方がWikiLikeなんかよりもよっぽど時間がかかる。
• 本筋とは関係ないけれども、どうせならばTrackBack関連の機能も一通り実装し終えておきたいなー。

なんてのもあるんだけど。

今後どうなるかわからない（たぶんWikiLikeの完成形とは互換性がない）現在私が使っているものをそれなりにまとめて公開することは不可能ではないけれど、そんなドッグフードは俺一人で食っていればいいかなーと思うし。まあどうしても使ってみたいと言う人がいたら、連絡ください。php4以降＋MySQLで動作します。ほかのDBMSに移植するのはそんなに難しくないはず。

• http://clicri.takenaka.com/

略称（愛称？）クリクリらしい。Wikiでの編集作業がページ単位（ParagraphOrientedならば段落単位）なのに対して、文字単位で編集範囲を指定できるようにしたシステム。細かい編集単位を指定してきちんとロックしている分、ちょっとインターフェースがうざくなるのは仕方ないか。編集単位が細かいことよりも、その細かく編集されていく過程を追っていきやすい点が売りなんだろう。

ただ実用上は、編集単位を文字単位まで細かくしなくても、構文解析して一文もしくは文節単位で指定できれば十分って気がする――って案も結構面白そうだな。WikiLikeにそういうインターフェースを用意してもいいかもね。ただWikiの基本的に全文編集って考え方は捨てたくないから、文節単位編集とかと両立させるのはちょっとうざそうだ。せいぜい段落か一文（改行から改行まで）かのどちらか単位でも編集範囲を指定できるようにするくらいか。それでもまだ標準インターフェース化するとうざいかな？　文章量がある程度大きくなった場合（数段落分）のみ、編集パーツを選択できる画面（各文頭にパーツ編集用リンクをつけて表示しつつ、全文編集用リンクも用意する）を編集操作の間に挟むようにすれば、そんなにうざくないかな。でもしょせんWikiだからロック単位は全文になっちゃうだろうけど。それともパーツ編集と全文編集を同時に成立させる仕組みを思いつけるだろうか……。

ああそういえば書いていなかった。昨日は雪が降ったんでムスコともどもお休み。雪の中ムスコを保育園に送っていくのが面倒くさかったんで（←おい）。んでもって、ムスコとちょっと外で雪遊びをしたり。といっても俺がムスコに雪玉をぶつけて遊んでいただけだけど（←おい）。埼玉南部では10センチくらい積もっていたみたいだけど、都内は1センチ程度だったの？　やっぱ埼玉は南部とはいえ東京とは気候が違うんだなー。そういや今年はスタッドレスタイヤどうしようかなー。去年までの幅が合わないタイヤをもう1年履くか、それとも新しいタイヤを買うか、それとも他人（の車）任せで1年過ごすか。

CLIE PEG-N700Cのスタイラスをなくしてしまったよ。（中古で）買った当初から緩くて落ちやすいからいつかなくすとは思っていたけれど、先週の金曜日に家に帰ったらなかった。てっきり会社の自分の席周辺に落としたと思っていたんだけど、会社に来ても見あたらない。まあCLIEのスタイラスはよく純正品が売っているから、そこらの店で簡単に代替品は手にはいるだろうけど。でもNシリーズの周辺機器はそろそろ危険かな？　サードパーティ製のペン付きとかにもちょっと興味がある。

• http://member.nifty.ne.jp/ippo/s_d200212.html#d7_t2
• http://bm.que.ne.jp/text/?200212a&to=200212103#200212103

あたりを読んで、やっぱり私と同じようなことを考えている人は結構いるんだろうなーと思った。

結局ポイントは、（日本では（？））個人Webサイト文化の中心があまりにもWeb日記に寄りすぎてしまったため、時系列でコンテンツを管理するシステムばかりが高度に洗練されてしまい、それ以外のコンテンツ管理手法を採用したシステムがあまり発展しなかった、ってことなのかな。本来ハイパーテキストのキーワードでドキュメントを結んでいく仕組みからすれば、キーワードをコンテンツ管理の要として利用するコンテンツ管理システムがもうちょっとたくさん出ていてもおかしくなかったのに。

ちなみに私が2年くらい前に作ったWeb日記システムは、内部的にはかなりキーワード指向に作っていた。ドキュメントには複数のキーワードを設定することができ、そのキーワードと生成更新時刻の2軸を使ってドキュメントを検索し、一覧・詳細表示するという仕組み。はっきりいって現在のWikiLikeは、そのWeb日記システムをWikiっぽく作り直したものだ。

あと、キーワードで複数のサイトを結びつけたいという欲求は私ももっている。たとえばWikiLikeでは、キーワード検索を自サイト内検索であると同時に他サイト検索でもある、といった感じにもっていこうと思っている。現在のところはキーワード検索すると、

• それに一致した自サイト内のドキュメントの内容を表示
• 類似キーワードをもつ自サイト内のドキュメントを一覧表示
• 登録されている他サイト（Googleおよび他のWikiサイト）の該当キーワード検索リンクを一覧表示

を行うようにしている。このあたりはもうちょっと進化させて、他サイトのRSSをもってきて該当ドキュメントが存在するかどうかをもうちょっと詳しく表示したりできるといいかなーと思っている。これによってたぶん「同じ本の感想を複数のサイトにまたがって検索する」なんてことあたりは実現できるだろう。

ただし、このあたりはコンテンツ管理システム側が実装するよりも、実はGoogleのような検索エンジン側が（Webサービスインターフェース経由で）より細かいクライアントからの要求を受け付けるようになればそっちを利用した方が話が早いかも、と思ってもいるけど。

ひとまず私はWikiLikeという方向性でいろいろ試してみるつもりだけど、いろんな人がいろんな枠組みで（できればWiki方面からのアプローチだけでなく、新しいWeb日記システムという方向からのアプローチも）キーワード指向のコンテンツ管理システムを作ってみたりすると、そのうちできのいいシステムが出てきたりするんじゃないかなー。blog方面もかなり有望なんだけど、あっちはニュース指向があまりにも強すぎる気がする。もっと色がないシステムとして開発された方が使いやすくなりそうだ（色は後から付ければいい）。

その他文章としてまとめきらなかったポイントを列挙。

• コンテンツ管理とコミュニケーションのバランス。コミュニケーションは面白くていろいろ発展性もあるけど、コンテンツ管理とは本来別枠に考えた方がいい。→TrackBack
• 認証周りの問題。あるいはコラボレーションの是非というか。コミュニケーションとも絡んでくる。その辺り、根本的なところから考え直す必要がある。

なくしたスタイラスの代替品として、純正のスタイラス3本パックPEGA-ST500/Jを購入。ビックカメラ渋谷東口にはぱっと見た限りではもうCLIE Tシリーズ以降のスタイラスしか置いてないように見えるけれども、Tシリーズ以降用の純正品スタイラスがぶら下がっているところの一番後ろにそっとN/Sシリーズ用スタイラスも置いてあった。

ついでに、とても使いにくいトラックボール風味センターボタン付きマウスArvel Magic ball MFB3USM-MTの代わりに、マイクロソフトのMobile Optical Mouseを買ってきた。Magic ballというのは、センターのスクロールボタン部分がトラックボールみたいなボールになっている製品で、最近のマウス過当競争においてはそれなりにインパクトのあるギミックとして興味を引いている製品っぽいけれども、たぶんこれは一度使ったことがある人たちがある程度以上増えたらそれ以上は売れなくなる代物だろう。

はっきり言ってこのボール式センターボタンは、引っかかりも指向性もないため、通常のスクロールボタンの代替としてはとても使いにくい（思った方向に思った量回転させることが難しい）。またこのボタンは最悪の場合でも、トラックボールの代わりに使えるのではと期待させるのだが、少なくとも現状の（Windows XP用）ドライバーにおいてはそのような使い方は出来ない（パッケージにはそれっぽいことが書いてあったのに）。また、ボールボタン部は通常のスクロールボタンと比べてとても壊れやすい（トラックボールと同じような仕組みだけど、しょせんおまけだからトラックボールほどその部分にお金をかけていない）。

まあどうしても試してみたいという人は一度使ってみればいいだろうけれども、たぶんこれは「着眼点は面白いけれども、実際に使ってみたらとても使いにくい」という感想を持つ人が多いのではないだろうか。

帰り道にぼーっと、WikiLikeみたいなツールは別にWeb上に公開しておかなくても、PC上で単体で動作するものがあってもそれなりに有用だよなーと考えていて、そして気がついた。

WikiLikeの場合WikiNameやBracketNameで修飾したキーワードは必ず、ドキュメントのキーワードとして別途保存されるんで、それを使えばドキュメントのどの部分をリンクしたいのか分かるんだから、データを保存する際にわざわざ本文にBracketNameを指定する大カッコなんて保存しておく必要はないよな。最初にキーワードを設定するときにだけ指定してやればそれでいい。

そうすれば、ドキュメントのRawデータによけいな装飾をもたせておく必要性がなくなって、再利用性とか可読性が高まるし、同じキーワードに何度もリンク指定を書く必要もなくなる。キーワード最長一致でリンクを張っていけば、キーワードの部分一致関連はだいたいなんとかなるだろう。

WikiLikeのページレンダリング処理にキャッシュを追加したら、処理がずいぶん軽くなったな。やっぱりレンダリング処理は結構重かったか。特にここのサーバーはCPU負荷がきついときが結構あるみたいなんで、効果が大きいみたいだ。

ただし効果が大きいのはページのデータサイズがある程度以上大きい（というか、フォーマットが複雑な）ときだから、現状のページはすべてキャッシングする仕組みよりも、キャッシングするかどうか判断するロジックをつけた方がいいかもしれない。ただ、そんなロジックを入れて効率化を図ったところで、そのロジック分で食われておしまいかもしれない。

あと微妙なのはコメントだよなー。コメントのほうこそ、データサイズを見てキャッシングするかどうか決めればいいのかな。現状はコメントはキャッシングしていません。