2009年1月アーカイブ

また同じようなものを書いてしまった...

ドキュメントは明日くらいに時間があったら書きます。要はmt:sectionタグとかMTのテンプレートキャッシュのように時間ベースではなくて、オブジェクトが更新された時にしかるべきキャッシュがクリアされて欲しい...ということで名前の通り元々はCMS(管理画面)用に作ったのですが、デザイン・テンプレートにも使えると思うので晒しておきます。

例:ダッシュボードのタグ・クラウドとか「mt:section」タグ使う事でキャッシュされてます。これ、mt_sessionテーブルにsession_kind「CO」、session_dataにBLOB型のデータとして保存されてるみたいなんですが、有効期限が時間で設定されているだけで、オブジェクトに変化があったかどうかを考慮してキャッシュをクリアしてくれるわけではありません。例えば「タグ」をひとつ削除してもダッシュボードの「タグ・クラウド」は一定時間変更されません。この辺、「割り切った」実装であることはわかるのですが、明示的に関連するデータが変更された時にキャッシュがクリアされるような仕組みがあったらいいな...と思って。

先日公開したMTRequestCacheタグもちょっと仕様を変更してマージしてあります。

テンプレートにもよりますけど、適切に設定してやれば2〜3倍くらいのスピードは出るかも。


# *** Default expires time is 600 (sec)
# If you want to change expires time, add to mt-config.cgi like this,
#
# CMSTemplateCachePeriod 600
#
# *** Template Tags
#
# <MTCMSCacheBlock key="CategoryEntries" blog_id="$blog_id" object_ds="category" 
#                            object_id="$category_id" by_user="1" children="1" primary="1" ttl="3600">
#     Some template tags here.
#      ( Clear cache when entry ( page ) is in ( primary ) category ( folder ) (Id:$category_id) changes. )
# </MTCMSCacheBlock>
#
#
# <MTCMSCacheBlock key="EntrySummary" blog_id="$blog_id" object_ds="entry" object_id="$entry_id" children="1">
#     Some template tags here. ( Clear cache when entry ( page ), comment and trackback changes. )
# </MTCMSCacheBlock>
#
#
# <MTCMSCacheBlock key="TagsBlock" blog_id="$blog_id" object_ds="tag" object_id="0" children="1">
#     Some template tags here. ( Clear cache when tag and tagged entry changes. )
# </MTCMSCacheBlock>
#
#
# <MTSetVarBlock name="key">RecentEntries_<$MTCategoryId$></MTSetVarBlock>
# <MTRequestCacheBlock key="$key" blog_id="$blog_id">
#     Some template tags here. ( Clear cache when application request exit. )
# </MTRequestCacheBlock>

今だから敢えて書いてみるよ。

少ない理由はわかんないけど、今起業すべき理由を書くよ。もちろん逆も書けるんだけどね(今起業すべきでない10の理由ってのも書けるよね。簡単に。でも、ここは敢えて今起業すべき理由を書く)。

※ひとつだけ

「どの程度くだらんことに耐えられるか」については、この耐性がない人は起業とかしない方がいいと思う。

変化の時代だから

4月、年度が変わるわけですが「我が社を取り巻く環境は益々厳しく...」っていう企業が「発注先の見直しをしなさい」っていうのは想像出来るよね。発注先を見直すってことは、新規参入のチャンスだよね。そのへんの変化がある方が参入しやすい。

つぶれる会社が増えるから

景気が悪いから普通に考えて潰れる会社が多くない? 競合が潰れたらその分の仕事が浮くよ。新規参入のチャンスじゃない?

景気が良くない事を前提に計画できるから

景気が悪い「今」を前提に計画するわけでしょう? 景気が良いことを前提の計画じゃなくて、悪いこと前提の計画でしょう? それでやっていける計画なら手堅いよね。

人材調達のチャンスだから

景気の良い時はよい人材をとれないよ。ベンチャーとか零細企業は。だってあいつらが(誰?)本気になったら競えないもの。その点で、今はチャンスだよ。

資産運用とかやりにくいし

1,000万円を元手に投資で10%の利回りを得るのと1,000万円を元手に商売はじめて10%収入Upするのとどちらが現実的? 少なくとも前者はやりにくいよね、今の時代ならなおさら。

周囲の理解を得やすい時代だから

大きな会社に勤めていてもそれで安泰っていう時代じゃないよね。いつリストラあるか分かんないんだし。だったらチャレンジしたいってのも理解得られやすいんじゃないの?

小さな会社にとってチャンスの時代だから

氷河期に身体の大きい恐竜は生き残れなくて、生き物は個体を小さくして生き残ったわけです(多分?)。景気が悪いときほど、個体としては小さい方が生き残りやすい。

国の制度とか税金とか

取り敢えず調べてみればいいと思うよ。色々あるさ。

デフレの時代だから

安くモノを調達しやすい世の中じゃない。オフィスを借りるのだって、有利な筈だよ。

いつだって起業は素敵なチャレンジなのだから

まぁ、楽しもうよ。どんな時代であってもさ。


とはいえご利用は計画的に、ってか自己責任でお願いしますね!

昨日の続き。ちょっと思いつきで書いた。後悔はしていない(誰か同じもん書いてるかもしれないんだけど...という意味で)。

MTRequestCacheBlockタグで囲まれた部分は、単一の(cgiへの)リクエスト中であればキャッシュを使うようになります。

参考 : Movable Type オブジェクト・リファレンス - MT::Request

まぁ、移動の電車中にてちょっと書いたってくらいのものです。ご利用は自己責任でお願いします(多分問題ないと思うけど)。

テンプレートは以下のような感じです。idとblog_id属性を指定できるので、複数箇所指定する際は重複のないようにご注意ください。

<MTSetVarBlock name="blog_id"><MTBlogID></MTSetVarBlock>
<MTRequestCacheBlock id="RecentEntries" blog_id="$blog_id">
	Some template tags here.
</MTRequestCacheBlock>

MT4.2でテンプレートキャッシュ機能とか高速化にはかなり拘っているMovable Typeですが、チューニングの選択肢が増えた分そのあたりをうまく使いこなすためにはやはりそれなりに理解する必要が出てきます。正直、チューニングちゃんとやろうと思ったらかなり詳しくならないと難しいような気がします。

それでも、標準状態で結構色んなところで高速化図られてます。例えばカレンダーなんか勝手にキャッシュされるんですよね(実はハマった経験あり)。

MT3系の頃は以下のエントリーでも書きましたが、共通部分をインデックス・テンプレートにしてインクルードファイルにするという方法を良くとっていました。

この方法はすごく効果がある反面、一点だけ問題があります。それは「再構築の順番」です。

基本的にMTではエントリー(ブログ記事)アーカイブ等を先に再構築してインデックステンプレートは最後に再構築されます。理由は明らかで、最後にインデックステンプレートを再構築しないと一時的とはいえリンク切れを起こすからです。

よって、例えばこのエントリーを最初に公開した瞬間には、ページ右側の「最近のエントリー」にこのエントリー自身が含まれないことになります。よって、反映させるためにはもう一度再構築を行う必要があります(全再構築すれば済む話ですが)。

とか、そのあたり考えずに使えるといいかなと思って書いた、ということです。

何か「部屋とYシャツと私」みたいなタイトルですね(笑)。もういいや、この話題。って思ってたけどまた盛り上がってるみたいだから。

どっちやねん! まぁえーけど。


ウチの近所にスーパーが2件ある。

今年の年末年始、両方のスーパーでおせち料理の特売があったのだが、その売り方の違いが面白かったのでその話をまず書こう。

両方の店長から聞いたのだけど、どちらのスーパーも料理の仕入れは同じところからなんだ。だから内容に違いはない。
食材が届くのは両方とも同じく朝の8時。スーパーWは朝8時半からおせち特売、スーパーMは午後1時からおせち特売。

スーパーWでは、お客さんの注文があった段階で重箱におせちを詰め合わせして出すということみたい。

スーパーMは届いた食材を重箱に詰め合わせ完了してからおせちの特売をはじめることにしたようだ。だからどうしても午後1時になってしまう。

両方の店長は互いを気にしているから、スーパーWの店長は朝から機嫌が良かったみたい。スーパーMの店長は不機嫌きわまりない。
スーパーWに客が流れてるじゃないか!って。

ところが午後3時、2人の立場が逆転したんだね。スーパーWでは行列ができたにもかかわらず待ち時間が長過ぎて客が怒っちゃってかなりのお客が帰っちゃったらしい。

スーパーMでは、午後1時の特売スタートに客が殺到したけど、お客さんにはすぐにおせちを渡せたから、売上げも急増、お客さんも笑顔だったって。

結局、どっちの売上げにもあまり差はなかったみたいだ。

====

って位の差なんじゃないかな。動的生成と静的生成の差ってのは。

「再構築」が好きとか嫌いとかってのは、この店長たちのどっちがいいか? ってくらいの差しかないもん。

PerlかPHPのどちらが好きかってのは、好みだからどっちが好きでもいいしね。

MT3であれば、MTよりWPがいいじゃん! っていってる方が挙げてる多くの点が以下のプラグインで解決できます。 MT4.2であればほぼ標準でサポートしてるので書くまでもないですし。

編集画面へのリンク
http://junnama.alfasado.net/online/2007/06/mt4Movable Typebookmarklet.html
見たまんまプレビュー
http://junnama.alfasado.net/online/2007/03/Movable Type_3.html
再構築ストレスだったら
http://junnama.alfasado.net/online/2007/04/Movable Type_background_rebuild_6.html
http://junnama.alfasado.net/online/2007/07/rebuildat1stviewbeta.html

ついでに...

Movable Typeをめっちゃ高速化する20の方法。
http://junnama.alfasado.net/online/2007/07/Movable Type_9.html

Facebook

Twitter

このアーカイブについて

このページには、2009年1月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年12月です。

次のアーカイブは2009年2月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 6.2.6