再構築がホットスポットだったのか!?

出遅れたっ!!

ちょっと数日「再構築」に時間が割けなかったので (「再構築」に夢中になって家庭崩壊したとか社長が「再構築」ばかりやってて会社が立ち行かなくなったとかいうわけにもいかないので(笑)) ちょいと出遅れましたが。

さて、どこから行こうかな :-)

• 再構築がホットスポットらしいので。 - Ogawa::Memoranda

古いアーカイブの再構築を行わないというのはちょっと違う気がするなあ。

スーツ (＜まだ言うか!?) な自分としては、カードを多く持つことが大切で、ケースバイケースでさっさと導入出来るカードを増やすために最も最近作ったのがこれ (BuildFileFilter4OldArchive)、ということですね。

まぁ作っているプラグインとかMT系のエントリーの多くが「再構築ネタ」なんだけど、その一つという感じ。

ワークフローとしては理解できるのだけど、キャッシュのvalid/invalidをユーザに判断させることになって結局無駄な全再構築を誘発することになるのではないか。

確かに『「わかってやらないと」駄目』が前提であることは否定しません。ただ、高速化するにしても、エントリーが数万とかになって (実際に最近そういう相談を受けた) 且つ引っ越しやハード増強が困難であれば、やはりこんな方法も必要だろうなぁ、と。運用のための一つのカードに過ぎないということです。

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

この部分については、確かに(一般的な)デザイナーはそこまでは理解していないでしょう。ただこの部分はV(View)担当が理解しなくても良いように、あるいは理解しやすくするようにC/M担当が工夫するってのが筋というか、そのあたりの分業が出来ているのであればV担当とC担当のキャッチボールの中で解決していく問題かな、と個人的には思っている。

RebuildAt1stView (Greg Packer's Publishing方式)について

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

さて、これ(RebuildAt1stView)が来ましたか(笑)。元々これも「再構築」論争? の時に勢いで作ったので、確かにbeta版ですね。ただ「永遠にbeta」ってわけじゃなくて、比較的簡単に実現できそうな気がするというか、頭の中ではイメージできてるんですけどね。

ちなみに、この方式にはちゃんと名前があって、Greg Packer's Publishing (GPP - blog.aklaswad.com) と呼びます :-)

まず、この実装の際のPermalinkっていう考え自体がエントリーアーカイブしか考慮していないというか、設計自体が駄目だな。再構築に必要なデータを格納するテーブルは以下のような感じになるでしょう。

テーブル：mt_gregpackerの構造

gregpacker_id	int(11)
gregpacker_blog_id	int(11)
gregpacker_object_id	int(11)
gregpacker_templatemap_id	int(11)
gregpacker_archive_type	varchar(25)
gregpacker_period_start	timestamp
gregpacker_archve_path	varchar(255)
gregpacker_modified_on	timestamp

で、MT3ならBuildFileFilter(MT4だと名前変わってるかな?、多分) で再構築の直前にデータベースに登録 or 更新する(で、0を返す→再構築は行わない)。一回目のリクエストの際に「構築&リプライ」→「ファイルとして書き出す」。

あとは、「プロセスの並行性」の件ですかね。基本的に、ファイルの読み書きについて独自のコードを書くのではなく、こういうのはMTならMTに任せてしまうのが良いと思う。テンプレートからHTMLを構築して、「ファイルに書き出す」部分だけ呼び出せればいいわけだよね。これって用意されてます? (コード読めばいいんでしょうが...誰か教えてくれると楽だし書いておこう)

ひとつ気になるのは、BuildFileFilterの部分でファイルとして書き出さずにDBへ登録だけすべきか、mt-view.cgiからの再構築だからファイルとして書き出すべきかの判断が必要で、そのフラグを何でセットするかの部分と、ちゃんとBuildPageとBuildFileコールバックを呼び出す部分だな (実はRebuildAt1stViewをbetaとしている最大の理由はここ)。

とまぁコード読まずに書いてますけど、これちゃんと実装できたら「キラープラグイン」になるかしら?

* 別に全部書かなくてもPerl版ダイナミックのキャッシュを「ファイル」にしてしまうっていう方法でも良いと思いますが。