DiKicker には自動リンクベースの記事串刺し表示機能があって、同じキーワードを含む記事をまとめて読むことができる。 結構便利なのだが、この機能ではキーワードの設定は Blog の書き手に委ねられている。
社内で DiKicker を一部使ってもらっているのだけれども、それら他人の Blog を読んでいると「あのキーワードで串刺し表示したいな」と思うことがしばしばあることに気がついた。 やはり任意の文字列で串刺し表示する機能が欲しい。
書き手にとっても「自動リンクキーワードにするような文字列ではないけれども、串刺しで読みたい/探したい/見せたい」と思うことが少なからずある。
実現には全文検索を行う必要があるが「設置・運用の手間」「ディスク容量」という点から、事前にインデックスを生成するような方法は今回は避けようと思う (www.naney.org 上で自分が使う上での制約からくる理由が一番大きかったりする)。
ということで今回は grep 型で実装することにした。 もともと WiKicker の方の検索機能も現在のところ grep 型である。 WiKicker では自前で WikiPage をスキャンしているが、DiKicker では grep コマンドに任せることにした。 こういうのは専用の grep を使った方が速いはず。呼び出しは
grep -Flre $escaped_string dir...
というオプション指定。Web ページとしてのページングなどは、自動リンクによる串刺し表示機能のものを流用。
で試したところ www.naney.org サーバでは、load averages が 1 以下の時でだいたい50秒前後。対象ファイル数は 2800弱。予想より時間がかかる。
ただし1回実行した後、ファイルがファイルシステム/OSのメモリ上にのっている状態では 0.1秒程度で完了する。
検索結果ページの permalink が検索エンジンにそれなりに捕捉されて、定期的にアクセスがあるようになれば、ファイルがメモリにのっている割合が増えるであろうから平均して実用に耐えられる速度が出るかもしれない。
「が」や「は」など頻出する文字の WikiPage を作ってしまった場合、それらに対して自動リンクが働いてしまうと大変なことになるので、WiKicker では2文字以上のみ対象とするようにしていた。
しかし nDiki を書いていて、1文字のキーワードも自動リンクしたいという風に思えてきていた。 誰でも書ける Wiki の場合には危険で制約が必要だけれど、全てのキーワードが著者のコントロール化にある DiKicker では1文字のキーワードに対して自動リンクが働いても問題ないだろう。
ということで自動リンクが働く最低文字列長をプロパティで設定できるようにした。 2004年ぐらいからほとんど手をつけていなかった、AutomaticLink 処理モジュールを久しぶりにメンテナンス。 もともと2文字以上を前提でコーディングしてあったので、trie 部分などが1文字できちんと動くか確認した上で、文字列長チェックを可変に修正。 WiKicker、DiKicker 両方で設定で変えられるようにした。
またあわせて、英単語の部分文字列に対して自動リンクしないようにする処理も改善。 今までは `downloaded' に対して `loaded' はマッチしないようにしていたものの、'download' はマッチしてしまっていた。 このあたりを改善。
www.naney.org がどうもまた最近重い。
load average が 30 前後まで上がっている。 しばらくするとだんだん落ちついてくるのだが、3 以下になったところでまた 30 前後までまた一気に上がるというのを繰り返している。 load average で振る舞いを変えるのは WiKicker / DiKicker の特徴なので、これはうちが原因かも。
調べてみると SpeedyCGI のフロントエンドのプロセスが順番待ちで大量に起動している。
どうやら先日追加した自動リンクの機能改善にかかわるコード修正による、若干の処理速度の低下がまずいようだ。
速度が上がるようにちょっと修正してみたけれどまだ駄目なようなので、しかたなく単語の連接チェック部分を一時コメントアウトして対応。
今後、自動リンクまわりの更なる高速化がする必要がありそう。
去年の12月3日以来、約半年ぶりのリリース。 リリースしそびれて、随分変更を累積してしまった。 以下主な変更点。
前回の 0.41 に対して、今回は 0.420 とした。 浮動小数点数的には、増分 0.01 で今まで通り。
今後 version.pm が普及した時のことと、developer release を出す時のことを考えて小数点以下3桁ずつのスタイルに移行することにした (関連記事)。
2007年1月に実装。 編集ページや履歴ページが検索エンジンに登録されないようにするための機能。
2007年1月に実装。 リンク spam 対応。
2007年3月に実装。 特に DiKicker で1文字キーワードによる自動リンクを有効にするために追加した。
前述の機能で1文字での自動リンクを有効にしたら、不便な面が出た。
WiKicker / DiKicker では '/' を階層の区切り文字としても扱うことができるようになっていて、サフィックス部分だけでも自動リンクするようになっている。 自動リンクを1文字にしたら「OS/2」というキーワードに対して '2' でも自動リンクが働き、望まないリンクが張られるようになってしまった。 DiKicker では階層的キーワードは無くてもあまり困らないので、'/' の前を省略した自動リンクを無効にできるようにした。
2007年2月に実装。自分としては重宝している。
Google AdSense 挿入用。
2007年4月に実装 load average をチェックして負荷が高い時は、503 を返すようにした。
ソースコードを結構いじった。 deprecated なメソッドの削除も実施したので、0.41 以前から派生しているソフトウェアは多くの場合修正が必要。
公式の Flash 版 Twitter badge をこのページのサイドバーに表示していたが、以下の点でちょっと不満だった。
「自分の過去のステータスを一覧的にサイドバーに表示する」のがしたいことなのだが、ちょっとマッチしない。 ということで Twitter から RSS フィードを取ってきて、サイドバーに表示することにした。
使ったモジュールは URI::Fetch + XML::RSS + Date::Parse。 それとユーティリティとして WiKicker::HTML と WiKicker::URI。
と簡単に実装してみた。機能的には概ね満足。
パケ・ホーダイを契約してから、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 で書いて、Plack::App::Directory::Markdown (記事) (に手を入れて grep 検索や recent リストを表示できるようにした) Markdown ビューアで参照したり、関係者に見せたりしている。
重宝しているんだけれど、内部で使っている Text::Markdown Perl モジュールは、テーブルや GitHub Flavored Markdown にある fenced code blocks (``` で挟むやつ) が使えないのでちょっと不便になってきた。
Text::Markdown::Discount Perl モジュールはこの辺の拡張が使えるので、こちらに切り替えることにした。
このモジュールは discount というC言語書かれた Marrkdown 処理コードを使うもので、Text-Markdown-Discount 内に同梱されている。
そのままインストールすると fenced code blocks が有効になっていないので以下のようにしてインストールする。
$ tar zxvf Text-Markdown-Discount-0.11.tar.gz $ cd Text-Markdown-Discount-0.11 ここで Makefile.PL 中の qq{( cd $extdir; CC='cc -fPIC' sh configure.sh; make )\n} を qq{( cd $extdir; CC='cc -fPIC' sh configure.sh --with-fenced-code; make )\n} に変更する。 $ cpanm .
で Text::Markdown::markdown() のかわりに Text::Markdown::Discount::markdown() を使うようにすれば OK。
なお自動リンクをしたい時には
my $html = Text::Markdown::Discount::markdown($markdown_text, Text::Markdown::Discount::MKD_AUTOLINK);
のようにオプションを指定してあげる。
Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。
nDiki は1999年1月に始めたコンピュータ日誌を前身とする Naney の Web 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。
※内容は個人的見解であり所属組織とは関係ありません。