WikiName とは「WikiName」のように大文字で始まり小文字が続く単語を2つ以上並べたもの。
多くの WikiEngine では、自動的に WikiPage への参照(リンク)になる。
最近 NaneyOrgWiki も少しづつではあるがページ数が増えてきた。
TheWikiWayをとりあえず一通り読み終えて「検索」機能を随分重視しているなぁと思ったのだが何となくわかってきた。
ある程度ページ数が増えてくると、index 機能は使いにくくなってくる。 ページ数が少ないうちは中身も把握しているし IndexPage のリストも短いのでそこからピックアップするのも容易である。 検索フォームにいちいちタイプするより楽。 が、IndexPage が長くなると目で追いかけて探し出すのも面倒になってくる。 そうすると、俄然検索の方が楽になってくる。
WikiPage のページ名は「そのページ名での検索」にリンクされているので関係するページに2クリックでジャンプできる。 新規にページを作成した場合もこの検索を行って、必要に応じて他のページからきちんとリンクになっているかをチェックしたりできる。
本家 WikiWikiWeb ではページのカテゴリ化も、検索を使って擬似的に実現している。 「ほにゃらら」カテゴリとしたいページには「Categoryほにゃらら」という WikiName を書いておく。「ほにゃららカテゴリ」のページから「Categoryほにゃらら」の一覧へは、
と2クリックで到達。
InterWiki をうまく組み合わせれば、1つのリンクでページのカテゴリ指定しつつカテゴリ一覧(検索結果)へのリンクも可能。カテゴリ:ほにゃららのリンク先が'カテゴリ:ほにゃらら' という文字列を検索するページになるような InterWiki の定義をしておけばよろし。
ページ数が増えて、検索機能が主役になってくると果たして「階層ページ名」はどうなのかな? とりあえず多義語を別ページに分けられるというメリットはある。 ただ、DanglingLink から新規作成されるページは、通常階層化したページ名じゃないから必要に応じて移動しなければならないんだよね。
階層ページ名の有効性は今後の成行きを見るという感じ。
仕事場に Wiki を入れて情報を入力したりすると、すぐ欲しくなった機能が。
入力してある WikiPage をメールとかにコピーしたい場合は、plan text で適当に整形したものが出力できると嬉しい。
今の WikiEngine は WikiPage のパーサとHTML フォーマッタが一体となっている。 まずはこれを分離して、HTML、テキストそれぞれの Builder を作るとするかな。
YukiWiki2 をベースにちょこちょこいじってきた NaneyOrgWiki であるが、コードもこみいってきた。そろそろ、フルスクラッチしたくなってくる季節。
ということで、さっそくコーディング開始。 名前は WiKicker。 研究社の新和英大辞典をめくりつつ、
kicker はいわゆる、「蹴る人」という意味以外に、
なんていうのもあって、まそれなりによさそげだし。 Kicker ならアイコンを作ろうと思った時に抽象的でないから作りやすそうというのもメリット。 地肌に優しい。 ただし手がまだ覚えていないのでつい、WiKicler とミスタイプしてします。
で WiKicker への移行の主なポイントは、
あたり。
新 WikiEngine の開発にははいったけれども、稼働するのはずっと後になりそうなので、今使用している engine もまだまだ手を入れて遊びます。
WikiName と違って[[, ]]で区切るページ名は DanglingLink の時に「どこまでが名前かわからない」かなと思い、 CSS で破線をつけるようしてみる。
今までは CGI スクリプトの最初で必ず exclusive lock をかけるというバカ lock だった。 これだと WantedPages のような時間のかかる処理のあるページにアクセスがあると、他のページの read が軒並み sleep させられてしまう。
なので、書き込みのないアクセス時には shared lock で flock するように修正。 これで read vs read でのアクセスが待たされたくなったはず。 それでも時間のかかる shared lock なアクセスがあると write 系のアクセスはやっぱりしばらく待たされてしまうのだけれど、write 系は頻度が低いから……。
NaneyOrgWikiのサイドバーで、長いWikiNameを表示すると折り返すところがなくてはみ出ししてしまって見苦しい。
CSS で word-break: break-all してみた。 IE6だと効く。 Galeon 1.3.11a だと駄目。
WiKicker の Wiki間連携の強化(および開発中の DiKicker との相互連携)のために、 AutomaticLink を実現しているtrieによるキーワード抽出クラスを拡張する。
本来は一つの trie に属性付きでキーワードを登録して lookup するのがよいのだろうが、
ということでもっと簡単に実装。 単純に複数の trie を作って、それぞれ順番にキーワード抽出(2番目以降は先のキーワード抽出でマッチしなかった部分文字列に対して適用)するというようにした。 キーワード集合が増えるとどんどん遅くなるが、2つぐらいだったら耐えられるかな。
通常の AutomaticLink はその WikiForum 内のページにリンクされるのだが、例えば他のWikiForum の WikiName 集合を第2キーワード集合とした場合はその WikiForum 内のページURIに resolve する必要がある。
WiKicker の設定ファイルでどうやって指定するようにするかな。 InterWikiDefinition で定義してある InterWiki にマップするのも手だな。
さらに一歩すすめて、 WRI (WiKicker Resource Identifier) に写像してしまえば InterWiki だけでなく、いろいろ活用の幅が広がるかもしれない。
一昨日実装した、 複数のキーワード集合による、AutomaticLinkモジュールを WiKicker CGI プログラムから使えるようにしてみた。
ローカルにおいておいたキーワードリストファイルを読み込み AutomaticLink 処理(WikiForum 内で AutomaticLink でマッチしていない部分文字列に対して)。 マッチした場合は InterWiki を使ってURIに変換しリンク化する。
あわせてIndexPage.txtでWiKicker WikiForum 内の PageName を取得できるようにした。
これで例えば、2つの WiKicker WikiForum が cron で互いの IndexPage.txt を定期的に取得し、AutomaticLink するようにすれば、相補的に連携する事ができるようになる(ただし AutomaticLink のみ。WikiName や BracketName は依然としてその WikiForum 内のみ)。
AutomaticLink でのリンク先は(指定した)任意の InterWiki で定義できるので、あるキーワード集合について Google の検索結果ページや「はてなダイアリーキーワード」への自動リンクも実現可能(はてなダイアリーキーワード自動リンクAPIはキーワードリストではなく正規表現を返してくるので、元に戻す必要有り。またあれだけ巨大なキーワードリストだと毎回 AutomaticLink のために、trie 再生成するのも辛いのでもう一工夫必要)。
WiKicker の Windows 上での動作確認の続き。 WiKicker のPPM パッケージを作成して ActivePerl 5.8.6.811 上にインストール。 依存するモジュールで、ActivePerl に入っていないものは以下の通り。
既に手元で PPM パッケージ化済みなので、これもインストールしておく。
後は RCS をパスの通っているディレクトリに入れてタイムゾーンを設定。
TZ=JST-9
で CGI プログラムとして実行。 お、表示できた。 書き込みはと。
エラー。
予想していたけれど、sendmail に依存していたところ。 sendmail が見つからない場合はメールの送信をスキップするように修正。
これでうまく動くかなと思ったら、日本語名のページを作るとうまく表示できない問題を発見。
WiKicker では UTF-8 文字列をURIエスケープして WikiPage のURLを生成している。 このURIにアクセスされると WiKicker は、PATH_INFO から WikiName を取り出す。 この文字列がシフト JIS になってしまっている。
Windows がファイル名に使用する charset にあわせて、Apache が変換してしまっているようだ。 調べてみると他の WikiEngine でも同様の問題にあっているという記事が見つかった。
将来の 2.0 系でパッチが取り込まれて修正されるとか、そうでないとか。
現状どうするかなぁ。 WiKicker 側でシフト JIS から UTF-8 に戻すというのもできない事はないけれど、あまりやりたくはないな。 いったんシフト JIS を介しているという時点で、シフト JIS に無い文字の扱いに関する問題をかかえてしまっているし(Apache が)。
対策案:
この日記(nDiki)で使っている自作日記システム DiKicker、開発し始めたのが2003年12月末なのでもう13年物だったりします。ここ最近大きなメンテナンスはしていなかったのですが、まだこの先10年以上使えるように手を入れることにしました。一昨日から着手。
やりたいこと
この日記の日記システム(DiKicker)は WikiEngine からの派生で作られた生い立ちをもっていて、現時点でも WikiName を特別扱いし自動的にそのキーワードへのリンクになるようになっていました。今日はコードを修正してその特別扱いをやめることにしました。
実装ですがまず WikiName を先に抽出し、そのあとに他のキーワードを AutomaticLink するようになっていました。このため例えば MacBook Pro という文字列はまず MacBook という WikiName として抽出されてしまうため MacBook Pro という文字列で自動的にリンクさせることができていませんでした(それだと困るので明示的に BracketName で書いていました)。
WikiName は WikiWiki というコンセプト的に良いものでしたが AutomaticLink を実装している日記システムではもう不要な表現です。
ようやく重い腰を上げて今回のコード修正となりました(いじったのは数行なのですけれども)。
元日に出掛けたら例年より長い列だったので拝まずに帰ってきた神社にあらためて初詣に行き、あわせて図書館にも行ってきた7連休最後の日。去年は11連休だったのでちょっと短めの年末年始でした。過去3年「年末年始にやったこと」を書き出しているので今年もふりかえってみます。
電車に乗って出掛けたのは今日ぐらい。昨年同様日記まわりやデータの整理が中心でした。昨年の年末年始で Day One をやめて Evernote に集約することにしたのですが、その後テキストファイル化を決めたため日記データが3箇所に分散している状態になっていたのですがこの年末年始でまとめることができかなりすっきりしました。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。