nDiki : DiKicker

2006年11月7日 (火)

DiKicker の DB に余分な情報まで保存していた

DiKicker の関連記事表示機能で、同じ記事がリストアップされることがある。 どうも Term DB のデータに不整合が起きるようだ。

とりあえずリストアップの段階で重複は取り除くようにして対応。

コードのチェックをしているうちに、記事 DB の方に余計なデータまで Storable で freeze していることに気がついてしまった。 こちらも修正。

スポンサード リンク
[ 11月7日全て ]

2006年11月15日 (水)

[ DiKicker ] ページの中の最初の記事に1回だけ文字列を挿入する機能

DiKicker で表示するページに含まれる記事の中で、最初の記事にのみプロパティで指定した文字列を挿入する機能を追加してみた。

主な用途としてはやはり広告挿入ということになるが、例えばそれ以外の全部の記事に埋め込むには重すぎるサービスを使いたい時にも、使えると思う。

ここで「最初の記事がいいのか」「最後の記事がいいのか」という判断があるのだが、その辺りは見る人の行動パターンの傾向を考えなければならない。 まずはやってみて、自分も含めてどっちが便利か確かめてみることにする。

[ 11月15日全て ]

2006年11月21日 (火)

[ DiKicker ] 語リストを Term DB に保持

自動リンクなどで語リストが必要な時に、今までは Term DB (Berkeley DB で実装)をスキャンしてリストアップしていた。 これだと語数が増えていくにつれ線形に遅くなるので、一度リストアップしたら Term DB の別レコードに Storable で freeze してキャッシュするようにしてみた。 ちょっと速くなることを期待。

あわせてロックまわりも改善。 DiKicker では Article DB と Term DB をセットでオープンすることとし、Article DB の方で排他制御をしている。 ただし、Term DB の方には排他ロックでオープンされているか、共有ロックでオープンされているのかの情報を伝えていなかったため、実は共有ロックの時にも書き込みをしてしまう部分が残っていた。

Term DB オープン時にどちらで開いているかを通知するようにし、キャッシュ情報などの書き込み時にはこれらを参照して間違えた書き込みをしないようにした。

[ 11月21日全て ]

2006年12月3日 (日)

WiKicker 0.41 リリース - cookie まわりの処理を変更

11月1日以来、約1カ月ぶりのリリース。

ドメイン名なしの URL でセッションがはれない問題を修正。

DiKicker の方は、「n 年日記機能」、「diary-article:」の追加など。

[ 12月3日全て ]

2006年12月8日 (金)

DiKicker に TermDB が肥大化するバグ

DiKicker の TermDB まわりの処理の見直しをしていて、データベースがどんどん肥大化するという痛いバグを先日発見。

記事の更新を検出すると TermDB にも更新が入るのだが、この検出で「更新」ではなく「新規」と間違えることがあるようで、TermDB に同じ記事を再度新規登録してしまっているようだ。 で TermDB 側ではノーチェックだったので、どんどん追加されてしまういう状態になっていたと。

あちゃ。

とりあえず TermDB 側で登録処理時、既にあれば更新処理へ飛ばすようにして回避。

[ 12月8日全て ]

2007年1月11日 (木)

週次レポートは社内 Blog には邪魔

去年の11月から会社で、電子化した週次レポートをベースに週次定例ミーティングを行うようになった。 それにあわせて、書いた週次レポートを DiKicker で立てている 社内 Blog に毎週載せておいたのだが、これが思ったよりよろしくない。

DiKicker でキーワード串刺し表示を行うと、これらの週次レポートが記事リストに毎度のように沢山表示されてしまうのである。 自分が担当している各プロジェクトの1週間の成果・進捗報告なので当然各プロジェクトのキーワードを使って文が書かれているわけで、キーワードで一覧表示すると大概ひっかかってしまうというワケ。

週次レポートはその他のプロジェクトの情報も浅く広く書かれているから、串刺しで見るには邪魔なのである。肝心のキーワードに関する情報も、週次レポートという要約記事の前に別途詳細の記事があることも多いし。

ということでとりあえず週次レポート専用に社内 Blog を作って、それらの記事はひとまとめにしておくことにした。 社内 Blog にしておいて役立つかどうかちょっと様子見。

[ 1月11日全て ]

2007年1月27日 (土)

DiKickerはてなブックマーク数表示機能を追加

各記事毎に、「はてなブックマーク数表示」と「はてなブックマークエントリーページへのボタン」を追加する機能を追加。

DiKicker の構造上 HTML フラグメントへ変換する visitor を拡張する形で実装したけれど、やはりこの辺りはテンプレートベースでユーザがいじれるようにしたい。

WiKicker 開発時に速度の面で外した Template Toolkit 採用をまた検討してみるか。

[ 1月27日全て ]

2007年2月2日 (金)

DiKickergrep 検索機能を追加

DiKicker には自動リンクベースの記事串刺し表示機能があって、同じキーワードを含む記事をまとめて読むことができる。 結構便利なのだが、この機能ではキーワードの設定は Blog の書き手に委ねられている。

社内で DiKicker を一部使ってもらっているのだけれども、それら他人の Blog を読んでいると「あのキーワードで串刺し表示したいな」と思うことがしばしばあることに気がついた。 やはり任意の文字列で串刺し表示する機能が欲しい。

書き手にとっても「自動リンクキーワードにするような文字列ではないけれども、串刺しで読みたい/探したい/見せたい」と思うことが少なからずある。

ということで、検索ベースの串刺し表示機能を実装してみた。

grep ベース

実現には全文検索を行う必要があるが「設置・運用の手間」「ディスク容量」という点から、事前にインデックスを生成するような方法は今回は避けようと思う (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 が検索エンジンにそれなりに捕捉されて、定期的にアクセスがあるようになれば、ファイルがメモリにのっている割合が増えるであろうから平均して実用に耐えられる速度が出るかもしれない。

今後は様子をみながら検索結果のキャッシュ等を処理を整備していく予定。

[ 2月2日全て ]

2007年3月1日 (木)

WiKicker / DiKickerAutomaticLink 長を可変にした

「が」や「は」など頻出する文字の WikiPage を作ってしまった場合、それらに対して自動リンクが働いてしまうと大変なことになるので、WiKicker では2文字以上のみ対象とするようにしていた。

しかし nDiki を書いていて、1文字のキーワードも自動リンクしたいという風に思えてきていた。 誰でも書ける Wiki の場合には危険で制約が必要だけれど、全てのキーワードが著者のコントロール化にある DiKicker では1文字のキーワードに対して自動リンクが働いても問題ないだろう。

ということで自動リンクが働く最低文字列長をプロパティで設定できるようにした。 2004年ぐらいからほとんど手をつけていなかった、AutomaticLink 処理モジュールを久しぶりにメンテナンス。 もともと2文字以上を前提でコーディングしてあったので、trie 部分などが1文字できちんと動くか確認した上で、文字列長チェックを可変に修正。 WiKickerDiKicker 両方で設定で変えられるようにした。

またあわせて、英単語の部分文字列に対して自動リンクしないようにする処理も改善。 今までは `downloaded' に対して `loaded' はマッチしないようにしていたものの、'download' はマッチしてしまっていた。 このあたりを改善。

[ 3月1日全て ]

2007年3月7日 (水)

自動リンク機能改善による悪影響

www.naney.org がどうもまた最近重い。

load average が 30 前後まで上がっている。 しばらくするとだんだん落ちついてくるのだが、3 以下になったところでまた 30 前後までまた一気に上がるというのを繰り返している。 load average で振る舞いを変えるのは WiKicker / DiKicker の特徴なので、これはうちが原因かも。

調べてみると SpeedyCGI のフロントエンドのプロセスが順番待ちで大量に起動している。

どうやら先日追加した自動リンクの機能改善にかかわるコード修正による、若干の処理速度の低下がまずいようだ。

速度が上がるようにちょっと修正してみたけれどまだ駄目なようなので、しかたなく単語の連接チェック部分を一時コメントアウトして対応。

今後、自動リンクまわりの更なる高速化がする必要がありそう。

[ 3月7日全て ]

About Me

Naney Naney

Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

About nDiki

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Other Notes

ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。

最近検索されている記事

月別インデックス
Process Time: 0.081569s / load averages: 0.25, 0.48, 0.46
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker