小粋空間  -  a cheap joke and a play on words site

Movable Type 再構築の本当の問題

最近、「Junnama Online (Mirror)」さんのところで再構築ネタが多く上がっているのですが、「再構築の問題の本質は何だろう」と思っていたところ、タイムリーに下記のエントリーがあがっていたので、再構築の問題について記してみたいと思います。

Junnama Online (Mirror)：再構築の高速化に本気になれない訳。

おそらく1番の問題は、「再構築時の500エラー」ではないでしょうか。具体的には、再構築の途中で500エラーが発生するため、ページを最後まで再構築をすることができないという事象が過去、多く発生していました。「再構築 500」で検索すると、Movable Type の500エラーに関するかなりの記事がヒットします。

原因の一端にはサーバ環境もあると思いますが、個人ユーザの Movable Type の評価を下げる一因になっています。

2番目の問題は、再構築速度（エントリー数に比例して再構築時間が増大）。ただし個人的には、時間がかかってもきちんと再構築できれば1番目の問題ほど深刻ではないと思ってます（早いに越したことはありませんが）。

ちょっと前に「MovableTypeからWordPressへパーマリンクを引き継いで移行する方法」で「16000エントリー（の再構築）に2時間」というくだりがありましたが、当サイトは現在1/10の1600エントリー位で、インデックス／エントリー・アーカイブ／カテゴリー・アーカイブ／月別アーカイブ／日別アーカイブ全ての再構築を計ってみると、なんと20分強かかりました。

もしかしたらサーバ環境によってはその位かかるのが普通かもしれません（当サイトはさくらのスタンダードプラン+MySQL）。カスタマイズ内容にもよりますが、「16000エントリーで2時間」は結構早いかも。

話は変わって、再構築の目的は、「テンプレートやスタイルシートの変更を反映させたい」ことです。サイト全体の再構築が1?2分で終わるのであれば何も考えずに全再構築をしますが、膨大なエントリーがある状況では、個人的には下記の手順を踏みたくなります。

• 変更の反映について、トップページと各アーカイブで数ページを確認（NGであれば繰り返す）
• OKであれば一気に再構築

そういう意味では、ダイナミック・パブリッシングや WordPress では再構築時間云々よりも、変更が即座に反映されたページを閲覧できるのが魅力なのではないかと思います（ページ表示時の再構築のコストはおいといて）。

「変更が即座に反映されること」をもう少し突き詰めて考えると、ミスのないデザインが公開できる仕組み（あるいはミスを即座に修正できる仕組み）が最も重要なのではないかと思いました。
もし16000エントリーを全て再構築してしまった後で何らかの不具合が発覚した場合、一番最後に再構築されるエントリーは修復までに2時間かかる訳ですので。

ということで、当サイトでは「エントリーのプレビューを行うプラグイン(MT3.2/3.3対応版)」を使って事前にページを確認してから再構築するようにしています。「StylePreview」でも同様の効果を得られます。

またMT4では「ブログ記事の確認（ウェブページの確認）」で公開デザインでの見栄えを確認できるようになっているので、あとは最重要問題である500エラーの解消と、再構築のさらなる進化の追求（下記）でしょうか。

• Ogawa::Memoranda：WebSig24/7の参加報告+MT4の高速化あれこれ
• Junnama Online (Mirror)：Background Rebuilder
• Junnama Online (Mirror)：RebuildAt1stView(Beta)
• Junnama Online (Mirror)：BuildFileFilter4OldArchive