MTのプラグインを書く10の理由。

公開日 : 2007-01-04 11:00:39

去年の11月から2ヶ月と少し、MovableTypeのプラグインばかり書いているような気がする。ここに書くネタもそればっかり。

精力的に様々なプラグインをリリースしているFujimotoさんとか、他にも何人かいらっしゃるのですが、後発? の僕なりにMT のプラグイン開発をしていて思ったことをちょっとまとめてみる。

MTのプラグインを書く10の理由

別に10でなくとも良いのだが、語呂が良いので、まぁ深く考えずに。
個人的なことと仕事のことも混ぜこぜであるが、それもまぁ、なんだ...

パターンを覚えれば後はすごく楽である。

例えば、年末のウチの会社の社内プレゼンの時に色々なプラグインをその場で書いたり改造したりというのを実際にやってみたのだが、テキストフィルター等は正規表現でテキストを置換するだけだから、基本のひな形が作れればあとは様々なものがすぐにできる。
ちょっとしたものでも実用性の高いものが書ける。

KOFの時にやったのが「丸付き数字を括弧付き数字に変換するフィルター」。基本、ビジネスブログというか企業サイトの受託をやっているので「運用」のことを問われてCMS的にMT、ということがスタートだから、ドキュメントに「アクセシビリティ指針」とかで「この文字は使わないでください」とか書かないといけなくなるケースがある。ただ、本当はそんなこと書きたくないし、使う側も気にしたくない筈である。

「この文字は使わないでください」→「この文字は使えません」→「この文字は適切な文字に自動置換されます」

どれが使い手に優しく読み手に優しいシステムだろうか。
「技」でカバーするよりスマート、且つコストを下げられる。

MTをCMSとして使う場合、例えばエントリーの並べ順をどう制御するか、等設計段階で色々気をつける必要が出てくる。

この例で言えば、エントリーのタイトルの先頭に数字を入れる（出力時に数字は切る）とか、追記欄、抜粋（概要）欄に数字を入れる、といった方法が良く知られている（←そうなのか? 実際にウチのスタッフが行っていた方法でもあるが）。

それはそれで良いのだが、エントリーが増えた時、順番を一つ一つエントリー編集画面を開いて制御するのか? 間に一つエントリを入れたいときはどうするんだ? というと、「000-001-000」とかにすると言う。間に数字を入れやすいように。

少し考えれば分かることだが、並べ替えを頻繁に行い、エントリーが増えてくると訳が分からなくなる。

運用のことを考えてのCMSなのに。

では、プラグイン書き? はこうすればいいんじゃないか? というアイデアが湧く。で実際に書く。慣れてくれば時間はさほどかからない。
MT APIが良く出来ている。

例えば、タブ区切りテキストファイルを用意して1行に1エントリの情報を入れる。左から、BlogのID、エントリタイトル、出力ファイル名、テキスト、追記、抜粋（概要）を入力、以下のようなスクリプトを走らせる。
```
require MT;
use MT::Entry;
open(FH, $file_path);
while (<FH>) {
	my $line= $_;
	my @datas = split(/¥t/,$line);
	my $entry = MT::Entry->new;
	$entry->blog_id($datas[0]);
	$entry->author_id(1);
	$entry->status(2);
	$entry->title($datas[1]);
	$entry->basename($datas[2]);
	$entry->text($datas[3]);
	$entry->text_more($datas[4]);
	$entry->excerpt($datas[5]);
	$entry->save or die $entry->errstr;
}
close(FH);
```
データベースへのアクセスは意識する必要がないし、SQL文も書かなくて良い。
# そもそも自分がSQLが得意じゃないというのもあるけど。

MT APIについては、「Movable Type オブジェクト・リファレンス」が公開されているので、これを見ながら書けば良い（このリファレンスについてはところどころ違うんじゃね? というところもあるのだが...）。

ブログ、エントリやコメント等へのアクセス方法は、MT::Objectの項を見て基本をマスターしてしまえば、あとはさほど意識する必要がない。

必要に応じてPHPMyAdmin等でDBの中身をチェックしながら作業を行えば、各種オブジェクトが自在? に操えるようになる。
簡単な割には、そこへ踏み出す人は意外と少ない。

と、いう気がするだけです...はい

ただ、こういう経験はある。外部の人にMTベースの開発案件を依頼した時、「PHP+MySQLの方が自分的には絶対早いので、MTのデータベースにPHPからアクセスして実装したい」のだと。
で、（今だから言えることではあるが）出来上がったものは、MT APIを利用した開発と比較して、やはりやり方に「力技」的な部分が多く、UIの面でも不満の残るものとなってしまった。
通常のプロジェクトと比較して、「ハック」している気分が強くなる。

TransformerプラグインでCMSのカスタマイズする場合、「MTの振る舞いを良く観察して」→「操作の流れ、どこで何が行われているかを把握して」→「その部分に割り込んだり、呼び出されるテンプレートを書き換える」という手順になることが多いのだが、

「設計」→「実装」→「検証」

が一般の開発の流れだとしたら、

「観察・検証」→「実装」

みたいな感覚である。とにかく1からゴリゴリ書く人には向いていないような気もするが、横着好きで手を抜くのが大好きな人は（もちろん、良い意味である）、ハマるような気がする。
MT自体がプラットフォームであり、ユーザーがそこに存在する。

以前、MacOS用のデスクトップアプリなんかをちょこちょこ作成したり公開したりしていたこともあるが、Macって少数派ではあるがユーザーは確実にいる訳で、だからこそ開発意欲が湧く。もちろんMacユーザーとMTユーザーの数を比較するのもナンセンスだが、何と行ってもブログのスタンダードなツールであるし、自分が作っていて面白いという以上に、ユーザーがそこに居る、というのが動機になる。
CMSのカスタマイズ系プラグイン開発では、デザインを考えなくて良い。

アイコンひとつ、テーブルのセルの色一つ、プログラム書いてりゃWebアプリがつくれるわけではない。そこにデザイナーとの協業が入ったとしても、この部分のデザインどうするの? みたいなやりとりは絶対発生する。

MTについては、MTのCSSを基本的に踏襲すれば良いわけだから、デザイン部分についてはほとんど考えなくて良い。

何よりナビゲーション部分なんかは逆に変更すると戸惑うだろうから、さわらないようにすべきだし、こういった部分で頭を使わなくて済むのはメリットだろう。
デザイナーとの協業が可能になる。

ひとつ前の項目とダブる部分もあるが、MTの場合はWebデザイナーにも認知があるから、「こんなコンテナタグ用意したし、引数でこう変化するように作ったからフロント部分はお任せね」ってなことが実際に可能である。

テンプレートエンジンとか色々あるけれど（実際MTもHTML::Template という Perl モジュールが使われている）、Webデザイナーの多くが例えばSmartyでの開発経験を持っているわけではない。そして、それらの多くは開発者側からのアプローチである。

その点、「MTとかCSSとかできなくて何がWebデザイナーよ、」くらいの感覚は浸透している（ような気がする）。

そういった面で、CMSが絡む仕事をデザイナーと進めやすいツールだと言えると思う。

# あ、別に僕はプログラマでも何でもないです。
どっちかと言えばデザインや実装の側に近い人間なのですが。
7〜8割くらいはMTで実現できるのだが...という開発案件のベースに使える

ユーザー認証やエントリーの登録・管理等の基本部分だけでも、一から設計して実装するのはそんなに簡単なもんじゃない。

実際、イチからやったら2ヶ月では絶対に無理! という案件も、MTをベースにすることで1ヶ月で骨格ができてしまった、という経験がある。仕事の場合は特に、人件費とライセンスを天秤にかけたらライセンス料かかってもこれでやっちまった方が早い、という要素は重要だと思う。

といったことで、何でこんなエントリを長々書いたかというと、MTだけじゃないんだけど、サイト制作についてこんなアプローチを最近はとっていて、それが面白いぜ! ってことが言いたかったのです。

で、一緒に誰かやらないか? ということで、当社では人材を募集中です。

僕が最近あれこれ書いているのは、仕事で書いている中から派生したものだったり、仕事でMTをCMSとして導入したい、という案件でやっている中で「何でこれができないんだろう?」「何かこれ、使いにくくないか? （CMSじゃなくてブログだから仕方ない面もあるのだが）」という中から生まれて来たものです。

経験は問いません。
何より、今こうやって「創る」ことが本当に楽しいので、教える意欲も満々です。

まぁここを見ている人で、興味が湧いたなら、一度まず話をしませんか?

MTのプラグインを書く10の理由。