一昨日実装した、 複数のキーワード集合による、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 再生成するのも辛いのでもう一工夫必要)。
行毎のプロファイリングを実現する Perl モジュール。 メジャーどころの Devel::DProf がサブルーチン毎なのに対して、こちらはより細かい粒度で実行回数などを計数できる。
WiKicker だと、PageName <-> FileName の部分がページ数が増えるに従って気になりだしたな。 PageName リストファイルとか作ってそれを読み書きするのとどちらが速いだろうか。
www.naney.org のアクセスログをローカルにもってきて統計解析をするのに、今回は analog ではなく AWStats を使うことに。
以前 www.naney.org に入れてみた時より、随分使いやすくなった感じ。
Debian パッケージを入れた後、awstats.naney.org というバーチャルドメインをローカルのApacheに用意(/var/www/awstats.naney.org)。
Alias /icon/ "/usr/share/awstats/icon/"
も設定に追加しておく。
ファイルレイアウト:
/var/www/awstats.naney.org/ | +-- .htaccess | +-- awstats.conf <-- 作成 | +-- awstats.pl <-- コピーしてきて一部修正 | +-- cache <-- DNSキャッシュ用 (まだ未使用) | +-- data <-- データを保存 | +-- plugins <-- プラグイン | +-- wikicker.pm <-- /wiki/(.*).html を $1 で表示するプラグイン(自作)
awstats.pl はパッケージのものをコピー。DecodeEncodedString の中で Jcode.pm を使って文字列を UTF-8 に変換するように修正。
ローカル用なのであまり気にせず DocumentRoot の下にもりっとファイルを置いておく。
awstats.conf はこんな感じ。
LogFile="/path/to/downloaded-log/access.log" LogType=W LogFormat=1 LogSeparator=" " DNSLookup=2 DirData="./data" SiteDomain="www.naney.org" HostAliases="localhost" DNSStaticCacheFile="cache/dnscache.txt" DNSLastUpdateCacheFile="cache/dnscachelastupdate.txt" URLWithQuery=1 URLReferrerWithQuery=1 LevelForWormsDetection=2 ShowWormsStats=1 LoadPlugin="wikicker" ValidHTTPCodes="200 304 -"
ValidHTTPCodes の '-' というのは、本来不要。自前のSSIで似非 Combined Log を生成する際に '-' を出力する事があるので追加。
日本語もきちんと出るしいい感じ。 指定した月ではなく、指定した日のログを見れるといいのだが設定すればできるようにならないかな。
analog と違ってプラグインが使えるのが良い。 Perlスクリプトだから、その気になれば簡単に awstats.pl 自体を変更する事もできるし。
今回は ShowInfoURL 用プラグインを書いて、/wiki 以下のURLの際は unescape して PageName を表示するようにしてみた。
その他いろいろ遊べそう。
Windows で「最後がピリオド(.)で終わるファイル名」を新規作成する。 最後のピリオド(ドット)が無くなる。
……。
8.3形式の名残なのか? Explorer 上で作成しても、プログラム(Perlスクリプト)から作成しても駄目。
環境は Windows XP Home Edition SP2 + NTFS。 Windows 2000 + NTFS でも同様。
これは WiKicker のテストをしていて気がついた。 WiKicker では「PageName の base64 を生成し 『/』 を 『.』 で置き換えたもの」をファイル名にしている。 例えば UTF-8 で「タ」は
44K/
となるので、ファイル名は 「44K.」となる。 で最後の文字が消えてしまうので、デコードするとおかしくなると。
これを機会に Windows 環境でのエンコーディングは RFC3548 「4. Base 64 Encoding with URL and Filename Safe Alphabet」を使うように変更するか。
本当は全てこれに変更したいのだけれど、すでに動いている WikiForum の事を考えると移行は難しいかも。
WiKicker では PageName を エンコードした文字列を URI に埋め込んだり、サーバで保存する際のファイル名にしたりしている。 このため、PageName の最長文字数はそれらの最長文字数に依存しているはずである。
今まで確認を後回しにしていたのだが、新しい機能の追加の際に確認しておく必要があるので調査してみた。
WiKicker の実装がらみとして最長を決める要素としては
がある。
上記の中ではファイル名による制約が一番大きい。
WiKicker 内部でファイル名として base64 (の亜種) でエンコードしたものを使っているので、元の文字列はは最長 189バイトまでなければならない。base64 だと3バイトで4文字になるため、189バイトで 252文字となる。
WiKicker ではここでさらにファイル名に ',v'、'-lock' をつける事があるので、実際には元の文字列は最長 186 バイトまでとなる。
PageName が 186 バイトまでだとすると、URL エスケープしたとして558バイト。 WikiEngine のスクリプトの URL や他のパラメータとあわせても、これぐらいなら大丈夫のはずである。
ということで WiKicker では Linux 上だと通常 PageName は 186 バイトが最長と言ってよさそうだ。 日本語の文字はだいたい UTF-8 で3バイトになるので、62 文字までということになる。
そのうち、WiKicker に制約チェックを入れることにしよう。 そのうち。
パケ・ホーダイを契約してから、MovaTwitter・RTM・モバイル Gmail などで携帯電話を活用するようになった。そんななか、決定打がないのが、ノートアプリケーション。電車の中などの隙間時間に、この nDiki の 下書きなどはケータイでできるようにしたい。
Google ドキュメントが使えればいいが、前年ながらまだiモードでは使えない。 メールベースでやる手もあるが、メモには良いものの再編集を繰り返したいようなものに難がある。
ということで自前でプライベート Wiki を立てそこに書き込んでみることにした。
使う WikiEngine はいつも通り自作の WiKicker。
書き込んだテキスト内のキーワードを nDiki へ自動リンクさせることができるので、パーソナルナレッジベースとして自分にとっては一番便利。書式も同じなので、Wiki に書いた下書きを、そのまま nDiki で使える。
肝心のケータイからの書き込みだが Ajax 等凝った技術を使っていないおかげで、問題なく FOMA 端末(D703i)からiモードで読み書きできた。WiKicker は UTF-8 でページを出力しているが、網側か端末側の処理かは知らないが今のところ問題なし。
なお認証は簡単に Basic 認証で済ますことにした。 安全とは言えないがそれほど重要なデータを置くわけではないしいいかな。 cookie は必要ないし WikiEngine に手を入れなくてもよいので、すぐできるのはコレ。
ユーザ名とパスワード付きのトップページ URL を端末でブックマークしておけば1発でアクセスできる。
これでケータイ(と PC)から使えるプライベート Wiki を設置できたわけだが、なにぶんもともとケータイをサポートしている WikiEngine ではないため、長いページの分割機能などはないのがちょっと不安。PageName で生成される URL が長くなった時の振る舞いもちょっと不安。
そこで Google Mobile Proxy (http://www.google.co.jp/gwt/n) 経由で Wiki を使うことにした。 ページを携帯端末向けに変換してくれる proxy で、Basic 認証もできるしフォーム の POST もできる。
Google Mobile Proxy 経由で見たページ内のリンク先も全て自動的に proxy 経由になるので、 PC 向け Web ページの URL を書いておけばそのまま携帯電話で見ることができる。
安全のためか、比較的短い一定時間立つと認証の再確認画面が表示されてしまうが、ユーザ名とパスワードを入力すれば、セッションは継続される。 テキスト編集に時間がかかってしまうと POST する時にひっかかってしまい認証の再入力がちょっと面倒だが、再認証が通れば POST リクエスト自体は有効で書き込みがロストすることはないようだ。
しばらくはこれで読み書きしてみよう。
「(自前の) Markdown ビューアじゃなくて Wiki に……」って言われた。もっとも。できるだけオープンに情報共有された方がハッピーだと常々思っているので、ちょっと耳が痛い。
なぜ Wiki じゃなくて howm + Markdown ビューアなのかの言い訳。 うーん Wiki といいつつ、もはや (ハワイ語的) WikiWiki じゃないからかな。
整理してストックしておくものはきちんと Wiki に書き直すのがもちろんいいんだけれどね……。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。