2005-01-31  Movable Type導入の課題

こんばんは,yumi-iiサイトをMovable Typeに移植する作業をしておりました。ローカル環境のWWWサーバ(WindowsのIIS)にMovable Type Ver. 3.122-jaをインストールして諸設定,さらにはテンプレートの書換えとログの一部のインポート(読み出し)までしてみました。

Movable Typeに移植したyumi-iiサイト

<画像の説明>Movable Typeに移植したyumi-iiサイト。印刷プレビューの画面。

すぐに運用できそうな状態に見えますが,使ってみていくつかマズイところを発見しておりますのでお話します。まだ試用して1日なのでおかしなことを言っているかもしれませんが,そのへんは気にしないでください。

記事にユニーク値が割り振られているのか

ユニーク値とは「ほかのモノと重複しない値」です。例えばこの記事のユニーク値は「11071007915」です。yumi-iiサイトでは「YUMI-CODE」という独自のコンテンツ識別値を導入しており,コンテンツを正確に区別できるように工夫しています。私はMovable Typeにも似たような機能があると思っているのですが,まだ発見していません。

トラックバックIDがどうもBLOG内でユニークらしいので,この値をユニーク値の替わりに使ってしまってもよいのかもしれませんが,用途が違う気がします。元々WWWに公開されたコンテンツを結びつけるためのものだろうし,管理画面で利用者が意識できるものでもないので,記事のユニーク値をどう扱っているのか(どう考えているのか)不明です。

ファイル名が不気味である

過去の記事にリンクを張りたい,ということがよくあります。普通だとHTMLファイルのURLを書けばよいだけなのですが,パス名とファイル名を見ると「...2004/12/post_6.html」だったり「...2005/01/2.html」だったりします。いかにも一時的に生成したファイルみたいです。再構築するたびにファイル名が変わってしまうのではないか,という不安があります。ファイル名の書式を指定できるのかもしれませんが,気になるところです。

長期間運用できるのか

いちばん気になっているのは,長期間運用した場合の性能です。例えば記事が数千件を超えると計算量が増えてまともに動かないとか,記事の書き出しができなくなるといった問題です。「2000件処理するためには1000件処理するための倍の時間が掛かる」だと良いのですが,これが指数的に増大するようだと大問題です。私は大量の記事を扱ったときの性能を,とても重視しています。ちょっと使ったくらいでは気づかないし,問題に気づいた頃にはすでに手遅れなんてことになるからです。