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);
のようにオプションを指定してあげる。
Web サイトの移行の話が出た流れで、この Web 日記についてちょっと考えたりした。
Perl で書いた自作の日記システム (CGI プログラム) で問題なく動いているが、手を入れずに使い続けているので将来環境(Perl やライブラリ)のアップデート時にハマるのではというのがあると、このまま記事が増え続けた時に問題が起きるのではというのがあり、気掛かりではある。
配信環境に依存しないように静的サイトジェネレータで生成する形に変えたらいいのではと、以前から思ったりしている。
ちょっとしか使ったことがない JavaScript を学ぶ機会としても Next.js とかどうかなとちょっと調べてみた。
個別記事ページを静的ページとして生成するのはいいとして、自動リンク機能で実現しているキーワード別ページとそのページングがちょっと厄介そう。やれるとしても今の URL 体系も一部変えなければいけないな。
Web 日記システムを2004年2月22日に今の自作のもの変えたのだが、それ以前の記事の移行が不完全なままで止まっておりでずっと気になっていた。やはりちゃんと移行しよう。
考えると過去に進まなかった原因の1つが「1日単位」の日記エントリから、「トピック単位」の日記エントリに分割することだった。
「移行すると1日の中の順序情報が失われるなー」「分割した記事ごとに URL (ファイル名)を決めるのが大変だなー」「ハイパー日記システム (hns) 時代の日記には Tweet のように短いエントリ(セクション)もいろいろあって、そのまま分割すると細分割しすぎ感が出たりするよなー」あたりがモヤモヤしていた。
自動リンク機能によりキーワードで記事を串刺し表示する今の Web 日記システム的には、1日単位ではなくトピック単位で分割した方が情報構造的にいいのだけれど、まあ「日記」なので記録として残っている(移行済みである)ことの方が大切だな。
「古いものは無理して分割せず1日1エントリにする」「そこから適宜トピックを取り出して別エントリにする」で移行しなおすことにしよ。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。