Aug 28, 2007

MT 4.0をpdo_sqliteに対応 (ただし非公開)

Movable Type 4.0のダイナミックパブリッシングは、MySQL、Postgresと、SQLite version 2に対応しているが、SQLite version 3には対応していない。これにはちょっとした面倒な事情があって、phpではMySQL、Postgres、SQLite2の拡張モジュールはあるのだが、SQLite3の拡張モジュールは標準的には存在しない。PDO (PHP Data Objects)という拡張モジュールを経由すればSQLite3を利用することができるが、MT4はそれには対応していない。

だから、SQLite3を使ってセットアップすると、MT4 CMSではダイナミックパブリッシングに変更するためのオプションすら表示されないはず。

[これはうざい]
のでMT4をpdo_sqliteに対応させてみた。

大した改造ではないのだが、ここにその詳細を示すのは派生著作物をpublishすることになるのでやめておく。ただし変更内容はSixApartに送付してあり、4.0xでは反映されるかもしれない。仮に反映されなかったとしても、さらにもう少し待てばMTOSがリリースされ、その時には公明正大にGPLで公開するつもり。

というわけでもう少しお待ちいただきたく。

追記:
MTのPHPのDBアクセス周りはちょっとひどすぎかもなーと思った。D::ODを作った連中なのだからもうちょっと何とかしてくれることを期待してしまう。ezsqlの仕様に引っ張られているのは理解できるのだけど、prepared statementを一切使わずescapeしまくってるあたりとか、「サニタイズ言うな」と。

Aug 25, 2007

FiscalYearlyArchives Plugin 0.01公開

年度別アーカイブを生成するためのMT4専用プラグインを作ったのでリリースします。プラグインのファイルや詳細なドキュメントは以下にあります。

FiscalYearlyArchives - ogawa - Google Code

MT4は、ユーザがプラグインを使って新しい種類のアーカイブを追加・拡張できるように設計されています。このプラグインはその機能を使って実現されています(ですから当然、MT4以外では動作しません)。似たような拡張を必要とされている方は、このプラグインのソースコードがきっと役に立つでしょう。

ついでで恐縮ですが、このプラグインは、MT4専用「年度」アーカイブ用プラグイン。 (Junnama Online (Mirror))にインスパイヤされています。

2007-08-26追記:
年度の開始月を設定できるようにした0.02をリリースしました。

Aug 22, 2007

TagSupplementals Plugin 0.06公開

Movable Type 3.3以降でサポートされた「タグ」に便利機能を追加・拡張するTagSupplementals Pluginを例によってちょびっとアップデートしました。

今回のアップデートはMovable Type 4.0に対応するための変更です。

Ogawa::Buzz: TagSupplementals Plugin 0.05公開のときに、MT3.3で追加された機能を使ってテンプレートタグの定義をするようにしたのですが、どうやらこの機能はMT3.3一代限りでなくなってしまった様子。MT4のregistry機能を使うように書き直しました(もちろん、MT3.3でも引き続き利用できます)。

他にもこんな機能があったらなという希望があったらコメント・トラックバックでお知らせください。簡単に実現できる機能から順に気まぐれに更新していきます。

TagSupplementals - ogawa - Google Code

Aug 5, 2007

再構築がホットスポットらしいので。

「そんな餌で俺様が釣られクマー!」って感じ。

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

なぜ高速化が重要かというと「速度が永遠のフロンティアだから」。言い替えると、機能によって達成できることもあるが、速度によって達成できることが「私にとっては」同等かそれ以上に重要だから。

このブログの再構築時間に興味がある方もいらっしゃるだろう。サーバーがえらくしょぼいことはさておき、エントリー約1000個で91秒かかる。このうち77秒、つまり全体の85%の時間をエントリーアーカイブの生成に費している。エントリーアーカイブのあるタグを外せば全再構築に63秒(エントリーのみなら49秒)しかかからないことも分かっている。要は再構築においては、エントリーアーカイブの生成時間がドミナントであり、したがってエントリーあたりの生成時間をO(1)に抑えることが肝要である。

だが一方で、MTの仕組み上このルールを破ってO(n)とかO(n2)かかるテンプレートを書くことはごく容易である。WebSig7/24の折にMTのテンプレートはデザイナーが理解できる唯一のテンプレート言語であると指摘していた方がいたのを記憶しているが、今のところは「テンプレートプログラムの性質」まではデザイナーの領分としてカバーし切れていないのかもしれない。悲観ばかりしているわけではなくて、knowledgeとして共有されてくれば徐々に解決していくと思う。

さて、junnamaさんの再構築に関するエフォートの中で一番示唆に富んでいる(と私が思う)のは、実はRebuildAt1stViewである。

RebuildAt1stView(Beta) (Junnama Online (Mirror))

まず、再構築によって生成される「ファイル」は「キャッシュの実装」であると考える。

つまり、全再構築時に行われているのは、すべてのキャッシュエントリーを無効化し、すべてのキャッシュエントリーをプリフェッチする操作である、と考える。

ファイルをopenし、writeし、closeするのには1マイクロ秒くらいしかかからないのに対して、(上でも述べた通り)エントリーの再構築には数十マイクロ秒(約77/1000秒)かかる。つまり、リードにもプリフェッチにも一エントリーあたり数十マイクロ秒かかるという、かなり深刻なメモリーウォールが存在する「記憶システム」だと見なすことができる。

このような場合、全キャッシュエントリーをプリフェッチするのは時間がかかり過ぎる。RebuildAt1stViewは、プリフェッチを一切行わず、最初にメモリアクセスがあったタイミングでフェッチするという戦略でプリフェッチのコストを回避している。別の方法としてはホットスポットのみ投機的にプリフェッチするという戦略も採り得る。

残念なのは、junnamaさん自身beta版と呼んでいる通り、やや実装が不完全なことである(対応しているのがエントリーアーカイブのみであるとか、プロセスの並行性を考慮していないとか)。

もし実装をMT4に限ってしまえるなら、RebuildQueue相当の機能が組み込まれているので、よりスマートにより完全な実現が可能になるように思う、ほとんどPerl版のダイナミックパブリッシング並みに。例えば、複数のクライアントが同時にアクセスした場合にRebuildAt1stViewで起き得る問題は、TheSchwartz::Jobの排他処理の問題としてより抽象化して取り扱えるし、ホットスポットをプリフェッチするのも特定のTheSchwartz::Jobのみをバックグラウンドかcronジョブで実行するような仕組みを用意すれば済みそうだ。時間があれば実装したいのだが、それがいつになることやら。

実は再構築にめちゃめちゃ本気な訳。 (Junnama Online (Mirror))

に書いてある、古いアーカイブの再構築を行わないというのはちょっと違う気がするなあ。ワークフローとしては理解できるのだけど、キャッシュのvalid/invalidをユーザに判断させることになって結局無駄な全再構築を誘発することになるのではないか。私としては自動的にinvalidationしてくれるRebuildAt1stViewの肩を持ちたいところ。

About Me

My Photo

つくばで働く研究者LV15

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com