RPMForgeをリポジトリに追加しておけば、全てのPerlモジュールをyumでインストールすることができる。

sudo yum --enablerepo=rpmforge install \
     perl-Image-Size perl-SOAP-Lite perl-Crypt-DSA perl-XML-Atom \
     ImageMagick-perl perl-Archive-Zip perl-IO-Compress-Zlib perl-PerlIO-gzip

#DB接続モジュールはお好みでどれか一つ
sudo yum --enablerepo=rpmforge install perl-DBD-MySQL \
     perl-DBD-Pg perl-DBD-SQLite perl-DBD-SQLite2

MTが扱い難い点の一つは、依存するPerlモジュールを揃えるのが大変だという点だ。モジュール同士の依存関係はcpanコマンドで解決できるのだが、全てをコンパイルするにはそれなりの時間がかかるし、ちょっと環境が古いとImageMagickやXML::Atomなどの重要なモジュールがコンパイルできなかったりして、面倒なことこの上ない。まったくyum様々、RPMForge様々だ。

正直、現代的なサイト制作というものを侮っていた。

このブログでWordPressを使ってみて、その扱いやすさに感心したので、MTの代わりにサイト制作用CMSとして使えないかデザイナーに提案してみたところ、あっさりと却下された。

理由は「複数のブログを扱えないから」だそうだ。

詳しく話を聞いていくうちに、彼／彼女らにとって「ブログ」とはサイトを構造化する際の基本単位であり、権限の委譲もコンテンツとデザインの分離も、この単位に沿ってなされるものらしいということが分かってきた。

プログラマとしては、「ブログ」よりももっと根源的な構造があるのではないか、と考えたくなるのだが、多分それは違う。多くのCMSが提示するようなプレーンなツリー構造や、静的サイトに見立てたファイルの比喩では、そこまで役に立たない。あくまでもフル機能を備えた「ブログ」だからこそ意味がある。

• 一定の構造を持つデータ＝記事のリストである
• 記事は基本的に投稿日時で分類されるが、必要ならカテゴリ／タグといった追加の属性で分類できる
• 投稿日時や属性に基づく何通りかのビューを標準で備える
• 記事にはメディアファイルを含めることができる
• 記事は、必要ならばフィードバックを受け付けることができる
• デザインには関与しない、記事のみを書く投稿者を複数割り当てることができる
• 以上を管理するための洗練されたWebインターフェイスがある

こういう特徴を備えた構造／システムをなんと呼ぶべきか？やはり「ブログ」としか言い様がないのだ。ちょうどプログラマにとってのRDBMSをイメージすると分かりやすいかも知れない。RDBMSが便利なのは、単にある構造でデータを保存できるからというだけではない。Database/Table/Rowという標準的な構造があり、SQLという標準的なインターフェースがあり、権限管理や様々なツールを含むMS（Management System）の部分があってこそ、プロフェッショナルな道具として役に立つ。

WordPressは、ブログを基本単位として自在に扱う能力を欠いている。いわば個人向けの用途特化型データベースソフトだ。その点では現状、MTの方がずっと優れている。

プログラマとして、プロフェッショナルとして、いろいろと考えさせられる経験だった。