Movable Type 技術情報
方川
2008年06月26日
こんにちは、方川です。
さっそくですが、タイトルにも書きましたＭＴＩｆＡｒｃｖｈｉｖｅＴｙｐｅタグの不具合について、
望ましい動作へ修正するプラグインを用意しました。
この不具合の原因は、MTIfArvhiveTypeの内部で比較しているアーカイブタイプが
確認画面の場所だけ違う名称になってしまっていることによります。
この動作はいまのところ修正されていない部分で、MTIfArchiveTypeを利用して
構築した場合、確認画面以外の場所と同じアーカイブタイプの名称を使っていたりすると、
きちんとプレビューできないことになります。
もちろん、確認画面で使われているアーカイブタイプの名称を利用することで、
対応できますが、確認画面の為だけにコードを用意したりするのはテンプレートの
コードが増えてしまうだけで、すっきりしません。
そこでスカイアークでは、確認画面のアーカイブタイプの名称を
他の場所と同じ名称に変更するプラグインを作成し対応しています。
このプラグインはあくまで、この問題がバージョンアップにより修正されるまでの
場つなぎ的なプラグインです。
利用方法
プラグインディレクトリに「IfArchiveTypeBugFix.pl」を保存するだけです。
プラグインのダウンロード
IfArchiveTypeBugFix.zip
プラグインの注意点
ぴろり上西
2008年02月25日
こんにちは，上西です。今日のネタはかなり地味(?)かも知れません。Movable Type でのログ出力について。
プラグインやシステムを開発していると，プログラムの動作を MovableType のシステム ログに書き出すことがあると思います。普段は余程複雑なログ出力が要求されない限り，MT->log を使うだけで十分です。
ところで MovalbeType には Custom Log という仕組みがあって，ベンダ定義の Log Object を自由に追加することができるようになっています。これを使うとベンダが自由に定義した書式でログに書き出したり，そのログだけをフィルタすることもできるようになります。地味な機能の割りには実はかなり便利です。
カスタム ログについては，一応，MT::Log オブジェクトのリファレンスにその記述があります。ただ，詳細なところがかなり端折って書いてあるので，とりあえず自分でカスタム ログ オブジェクトを作って動かしてみるとよく判るのではないでしょうか。
カスタム ログ オブジェクトはプラグインの形で提供すると簡単です。プラグインを書く要領で以下のようなファイルを作り，例によって plugins ディレクトリ以下にコピーしてやります。
カスタム ログ オブジェクトは /plugins/MyCustomLog/lib/MyCustomLog.pm に定義されていて，以下のように MT::Log のサブクラスとして定義してやります。今回，実験用に以下の非常に簡単なものを用意しました。
以上で準備は完了です。管理画面からログを確認すると以下のようになっているのが確認できると思います。MyCustomLog オブジェクトでオーバーライドした各メソッドと画面上での表示の対応は以下の通りになります。
フィルタの設定から "My Custom Log Label" を選択すると，MyCustomLog によって記録されたログだけが抽出されて表示されます。
ところで，ここが追試不足でイマイチ不明なのですが，MT::Log->add_class するときの key と value は同じ文字列にしておかないとフィルタが上手く動作しないようなんですね。うーん。
MT と他システムと連携して機能するサイトなどでも，その動作ログを MT に集約すると管理がし易くて便利です。フィードも生成されますし再利用性が大きく増します。ただ，普通に system レベルのログに吐いてしまうと，他のログに混ざって検索が大変だったりします。そんな時に活躍してくれるカスタム ログは縁の下の力持ち的な存在と言えるでしょう。
小林
2008年01月24日
小林です。
SAKKからMT4.1がリリースされました。
MT4.1は投稿画面が大幅に変更されました。また、カスタムフィールドを正式に実装し、今後WEBデータベースとしての利用用途拡大が期待できます。カスタムフィールドについては私のあすなろブログで詳しく書いていますので御参照下さい。
Movable Type4.1のカスタムフィールドがWEBシステム構築を変える
投稿画面ですが、オプション設定がすべて右側に移動し、投稿画面の縦長が解消されて使いやすくなりました。
ちなみにMT4.0だとこうでした。
MT4.1はカスタムフィールドによって、WEBシステムとしての魅力が大きく向上しました。
弊社もMT4.1を活用したサービスを近日中にリリース予定ですので、ご期待下さい。
ぴろり上西
2008年01月11日
構造化されたデータをテキスト形式で保存しようと思って，最初はXMLで保存すればいいかなぁと考えていました。しかし，そもそもそんなに複雑な構造を持ったデータでもないし，そういえばYAMLってあったっけ？と思い出しました。
YAMLはその構造が単純な分，動作パフォーマンスについて期待ができます。XMLではXPathなどの周辺技術と組み合わせて使うことで威力が発揮できそうです。今回はデータ量が少ないので，実際はどちらでも構わないのですが，とりあえず，読み込みパフォーマンスと消費メモリに注目して調べてみました。
XML::Simple 2.14
| データ件数 [件] |
1件あたりの処理時間 [ミリ秒] |
オブジェクトのサイズ
[Bytes] |
| 3 | 5.203 (1000 件の平均) | 218 |
| 30 | 24.22 (100 件の平均) | 442 |
| 300 | 187.8 (100 件の平均) | 2,234 |
| 3000 | 1777.5 (100 件の平均) | 16,570 |
YAML 0.66
| データ件数 [件] |
1件あたりの処理時間 [ミリ秒] |
オブジェクトのサイズ
[Bytes] |
| 3 | 10.11 (1000 件の平均) | 218 |
| 30 | 77.34 (100 件の平均) | 442 |
| 300 | 596.7 (100 件の平均) | 2,234 |
| 3000 | 5,567 (10 件の平均) | 16,570 |
最初の比較対象はPPMでインストールしたXML::Simple 2.14とYAML 0.66です。
生成されたハッシュリファレンスは同じデータ構造で，サイズは同じでした。
YAMLのほうが構造が簡単な分，速度的にも勝るかと思っていましたが，
XML::Simpleの方がパフォーマンスが倍以上に良かったのでした。
あれぇ...YAMLってダメなのかなぁ...？
そういえば，Movable Type 4でもYAMLが利用されていますが，
こちらはYAML::Tinyと呼ばれるモジュールを使っているようです。
YAMLからリファレンスやエイリアスなどの機能が制限されたサブセットのようですが，
こちらでも調べてみることにします。
YAML::Tiny 1.21
| データ件数 [件] |
1件あたりの処理時間 [ミリ秒] |
オブジェクトのサイズ
[Bytes] |
| 3 | 1.938 (1000 件の平均) | 1,746 |
| 30 | 9.469 (1000 件の平均) | 14,390 |
| 300 | 87.50 (100 件の平均) | 140,382 |
| 3000 | 720.1 (100 件の平均) | 1,396,718 |
速度的には全く問題ありません。
ただ，同じ内容の重複するデータを素直に持ってしまっているためか，
変数のサイズはデータ件数に比例して増加していることがわかりました。
読み込みパフォーマンスを見ればYAML::Tinyが最速ですが，
大量のデータを持つのであれば，
パフォーマンス以上にXPathなどによるデータ操作が利点となるであろうXMLも候補として考えられそうです。
小さなデータであれば記述のわかりやすさがメリットになるYAMLが良さそうです。
使途に応じて最適な選択はまた変わってくるかと思いますが，何かの参考になれば幸いです。
いたはし
2008年01月10日
皆さんこんばんは、板橋です。
今回は、プラグイン・アーカイブを使わずに更新日順年別リストを作成する方法をご紹介します。
完成時は、以下のようになります。
表示例）
2007年
- 11月19日 エントリータイトル
- 11月18日 エントリータイトル
- 11月14日 エントリータイトル
2006年
- 12月19日 エントリータイトル
- 3月12日 エントリータイトル
実際に記述するタグは以下のとおりです。
<MTSetVarBlock name="setThisYear"><$MTDate format="%Y"$></MTSetVarBlock>
<MTSetVar name="setEntryYear" value="$setThisYear">
<MTEntries sort_by="modified_on" sort_order="descend">
<MTEntriesHeader>
<h2><MTGetVar name="setEntryYear"></h2>
</MTEntriesHeader>
<MTSetVarBlock name="setEntryYear"><$MTEntryModifiedDate format="%Y"$></MTSetVarBlock>
<MTIf name="setThisYear" ne="$setEntryYear">
</dl>
<h2><MTGetVar name="setEntryYear"></h2>
<dl>
<dt><$MTEntryModifiedDate format="%m月%d日"$></dt>
<dd><$MTEntryTitle$></dd>
<MTSetVar name="setThisYear" value="$setEntryYear">
<MTElse>
<dt><$MTEntryModifiedDate format="%m月%d日"$></dt>
<dd><$MTEntryTitle$></dd>
</MTElse>
</MTIf>
<MTEntriesFooter>
</dl>
</MTEntriesFooter>
</MTEntries>
解説
まずブログの最新更新年をsetThisYearにセットし、setEntryYearにsetThisYearの値をセットします。
例えばブログの最新の更新年が2007年だとしたら、setThisYear、setEntryYearには2007が入ります。
<MTSetVarBlock name="setThisYear"><$MTDate format="%Y"$></MTSetVarBlock>
<MTSetVar name="setEntryYear" value="$setThisYear">
次にエントリーの一覧を更新日順に並べます。
sort_byでmodified_onを指定すると更新日順に並びます。
EntriesHeaderで最初のアーカイブ用の見出しを作成します。
最新更新年を出すのでsetEntryYearを出力させます（この時点ではsetThisYearでも構いません）。
※EntriesHeaderタグはEntriesの一番最初に一度だけ中身を出力するタグです。
<h2><MTGetVar name="setEntryYear"></h2>
次に、エントリーの更新年をsetEntryYearにセットします（後ほど比較対象に使います）。
<MTSetVarBlock name="setEntryYear"><$MTEntryModifiedDate format="%Y"$></MTSetVarBlock>
<MTIf name="setThisYear" ne="$setEntryYear">でsetThisYearとsetEntryYearの値を比べます。
setThisYearの値とsetEntryYearの値が同じでない場合、次行からMTElseまでの処理を行います。
次行からMTElseまでの処理は、一度リストを切って、見出しを追加するよう処理してます。
例えばsetThisYearが2007で、setEntryYearが2006の場合、一度リストが終了し、2006年の見出しが入ります。そのあとまたリストが作成されます。
MTElse内の処理は、setThisYearとsetEntryYearの値が同じだった場合、次行から</MTElse>までを処理します。
同じ年である限り、同じリスト内に行が追加されていきます。
日別、月別にしたい場合は、setThisYear、setEntryYearのformatを%dにすれば日別に、%mにすれば月別になります。
modified_onを指定しなければ、作成日順に並びます。
古い順にしたい場合は、sort_orderをascendにしてください。
