実際「Tweet禁止」「これは言わないでね」前提で好き勝手話しましたので外の方からはわかんなかったですよねきっと。でもまぁ、これは参加いただいた人の特典ということで。雰囲気は #mtgkで。

ここでは最終的なアジェンダだけ貼っておきます。

• 自己紹介・会社のこと
  • 自己紹介
  • Movable Typeとの付き合い
  • アルファサード有限会社について
  • 会社沿革(エピソードを交えて)
• Movable Typeのビジネス
  • Power CMS for MT誕生秘話
  • Movable Typeとは何か?
  • Movable Typeのビジネス
  • MTビジネスの特質
  • MT関連ビジネスのポイントと注意点
• シックス・アパートさんとの付き合い方(私見)
  • MTチームのみなさん
  • 相手の立場に立ってみる
  • ProNet/ProNet SOHO(パートナー制度の活用)
  • パートナー制度の本質
• 地方の小規模組織が勝ち抜くWeb構築ビジネスの戦略
  • 地方マーケットの現実と誤解
  • 東京へ行くべきか?
  • 製品・サービスを作り、展開する
  • ニッチの原則
  • アライアンス戦略の考え方
  • 価格設定と利益の出し方
• 会社の成長と自分の成長のために
  • 自社ブランディングと自社サイト
  • 社内/社外のコミュニケーションにMTを使う
  • クリエーターのワークスタイル
  • アイデアを実現する思考と行動
• 御礼と質疑応答
  • 御礼と質疑応答
  • ご提案

参考リンク

• 「第8回Creatorz × 第2回広島MT学会」終了 - The blog of H.Fujimoto
• May the hope be with you ! : 考え抜く姿勢
• 本当に聞きたい話ってここだけの話だと思うよ: 世界中の１％の人々へ

いよいよ今週末(8月7日)となりましたが、広島県内Pronetパートナーのメンバー他、藤本壱さん、私(野田純生)が登壇してMTに関するトークディスカッション、講演等で構成されるイベント「第2回広島MT学会inFUKUYAMA」が開催されます。スポンサー企業からのプレゼント等もあります。

西日本ではこのような大規模なイベントは中々開催されませんので、MTユーザーの方、仕事でMTを扱われている方は是非ご参加ください。

「第2回広島MT学会inFUKUYAMA」

• 日時 : 2010年8月7日(土曜日)13:00～17:30
• 会場 : まなびの館ローズコム 4階 大会議室1
• 場所 : 広島県福山市霞町1丁目10番1号
• 参加申込 : ATNDから申し込みをお願いします。

(野田のセッションの)テーマは、地方、東京、小規模Web制作事業、MT等

このエントリのタイトルの通りなのですが、せっかく東京でなく地方でやるわけですから、「地方」を切り口にした話をしたいと思いました。最初は「プラグイン」というリクエストで依頼があったのですが、そこは敢えて私から提案させていただきました。

実際、東京でのカンファレンスやCSS NiteのLPの時なんかは北海道とか九州から飛行機で参加したりされてるわけですし、地方でも面白い切り口で話せば参加したいと思ってくださる人もいるんじゃないかと思ってのことです。

このブログでも何度か書いていますが、ウチの会社は1人で大阪で7年前に作った会社ですし(現在は大阪-東京で12名)、つい数年前までは本当にSOHOに毛が生えたような事業を行っていました。Movable Typeを利用して(もちろんMTでなくてもいいと思うのですが)どのようなビジネススキームを企画してどう実行するか、どんな可能性があるのか、また「シックス・アパート」さんとの付き合い方やコミュニティのパワーをうまく仕事に活かすような取り組みの話とか、東京では話せない(話せないことはないですが)、「地方の、東京の、MTの本当のところ」を話したいと思います。今回は中継はないんですよね? ギリギリトークで行きたいと思います。

テーマは今日決定したのでアジェンダはこれからですが、今日のところは思うところを羅列しておきます。MTの技術的な面も絡めながらですが、Web受託、地方、小規模事業者が勝ち抜くためのヒントになれば、あるいは考えるきっかけになれば幸いです。

• 地方のウェブ制作の原状(大阪にて思うこと)
• 東京との違い
• 東京の仕事をどうするか
• MTで出来ること
• MTのビジネス
• 受託＋＋
• シックス・アパートとの付き合い方(あくまでも自分的に思うところ)
• Web制作会社の自社サイト戦略
• アルファサードのビジネススキーム
• イントラMTで自社を変える

来て良かった、と思っていただけるよう頑張ります。それでは、福山でお会いしましょう!

<MTIfAndroid>
Android向け
<mt:else>
そうじゃない向け
</mt:else>
</MTIfAndroid>

• MTIfAndroid.zip

一応、こっちもあります。基本同じですね。やり方。

• あなたのブログをiPad対応させる。

参考:

• FAQ｜Android｜開発者様用技術情報｜ドコモスマートフォンサイト | NTTドコモ

*蛇足ですが、ダイナミック対応プラグインが少ないってのは(昔書かれたものは別にして)現在では書かない人が多いってことだけかと思います。軽い重いってことじゃなくて、ハイブリッドなパブリッシングが出来るってことですからもっと可能性が色々あると思いますよ。

plugins/Viewer/tmpl/example.tmpl の場合、

mt-viewer.cgi?blog_id=1&template=example

mt-viewer.cgi?blog_id=1&template=example&id=1

とすることでid=1のページ(エントリ)アーカイブ的なものを作ったり。

テンプレートの中身を

<$mt:include module="$template" blog_id="$blog_id"$>

とかすることで各ブログ/ウェブサイトのモジュールをテンプレートとして使えるようになります。

• mt.zip

詳細はまたいずれ。お疲れさまでしたー(今頃ビール飲んでるんやろな...)。

MTのスタティック・パブリッシングにおける再構築とはつまりこういうことかと思います。

1. テンプレートをロードしてコンテクストをセットする。
2. 各タグ内で必要に応じてデータを取得したりコンテクストをセットし、
3. ブロック(テンプレート)をコンパイルしてビルドしていく。
4. この時インクルードされているテンプレート(モジュールやウィジェット)があればロードして展開する。

詳しくはlib/MT/Template/WeblogPublisher.pm (lib/MT/Template/Builder.pm とか、あと各テンプレートタグについては lib/MT/Template/ContextHandlers.pmなんか)を見れば理解できると思います。

さて、上記の4番目のロードとは、SQLを発行してデータベースからテンプレートを読み込むことを指します。SELECT * FROM `mt_template` WHERE template_blog_id=2 AND template_name='サイドバー' AND template_type='custom' みたいなやつです。

ですので、当然ながらフラット化されたテンプレートと比較すると遅くなる、重くなると思われがちで、一見この指摘は正しいように思えます。それがMTIncludeが重いといわれる原因でしょうか?

実際にやってみました。

• 新規にMTをインストール。標準以外のプラグインはなし。
• クラッシックウェブサイト以下にクラシックブログを作成。
• このブログをエクスポートしたデータをインポート(エントリー数は588)。
• ブログ記事の再構築を行う(5回計測。平均3分46.0秒)

3分43秒 / 3分44秒 / 3分48秒 / 3分49秒 / 3分46秒

さて、ブログ記事テンプレートの「サイドバー」モジュールをブログ記事テンプレートの該当箇所にそのまま貼付けて再構築を行いました。MTIncludeを使わないパターンです。結果...

3分55秒 / 3分53秒 / 3分49秒 / 3分47秒 / 3分51秒

変わんなかった(5回計測。平均3分49.2秒)。むしろ遅い?変わらないのはともかく遅くなった原因はわかんないです。が、まぁ誤差の範囲でしょう。

但し、以下の事実は知られていないかもしれないので書いておきます。

インクルードしているテンプレートモジュール(ウィジェット)のロードは1リクエストにつき1回だけ

具体的にはlib/MT/Template/ContextHandlers.pm の3598行目。MT::Requestにキャッシュされていない時だけロードされます。

ちなみに1リクエストというのは、mt.cgiへのリクエストです。MTのブログ記事の再構築は1度のリクエストで環境変数 EntriesPerRebuild の設定値(初期値は40)ずつ実行されます。40ファイル再構築後はリダイレクトして再び40ファイルの再構築を(これをエントリ数を40で割った回数分)繰り返すわけです。 588ファイルの再構築であれば、リクエストは15回です。EntriesPerRebuildの値を100にすればリクエストはわずか6回。つまり、テンプレートをロードするためのSQLのリクエストは100ファイルの再構築時にわずか(インクルードしているモジュールが1つあたり) 1   6 回です。

つまり、インクルードしていることの影響は些少といえます。

さて次。コンパイルです。ビルドする前にコンパイルします。MTIgnore云々の話はこのコンパイル時の話になります。計測のため(というか本当に速くなるんだったらいいなと思って)MTCompileCacheBlockというタグを作ってテストします。

sub _hdlr_compile_cache {
    my ( $ctx, $args, $cond ) = @_;
    require MT::Request;
    my $key = $args->{ key };
    my $id = "compile_cache_$key";
    my $r = MT::Request->instance;
    my $cache = $r->cache( $id );
    my $builder = $ctx->stash( 'builder' );
    my $tokens;
    if ( $cache ) {
        $tokens = $cache;
    } else {
        my $tmpl = $ctx->stash( 'uncompiled' ) || '';
        $tokens = $builder->compile( $ctx, $tmpl );
        $r->cache( $id, $tokens );
    }
    my $res = $builder->build( $ctx, $tokens );
    return $res;
}

テンプレートは以下のようにモジュールを囲む形で書きます。

<MTCompileCacheBlock key="sidebar">
    <$mt:Include module="サイドバー"$>
</MTCompileCacheBlock>

3分51秒 / 3分51秒 / 3分46秒 / 3分46秒 / 3分47秒

3分48.2秒。これも...誤差の範囲じゃないですか?

高速化云々の話をする時には「どこがツボ」かを考えないと無駄な努力に終わる可能性が高い。

ツボは何? そう、ツボは「ビルド」です。テンプレートキャッシュが有効なのはキャッシュした部分のテンプレートをビルドする処理を2回目以降スキップできるから劇的な効果が見込めるわけです。

では何故MTIncludeが重い(遅い)と(しばしば)指摘されるのか?

本当のところはわかりません。推測ですがおそらく「最近のブログ記事」とか「最近のコメント」等の相応に負荷のかかるブロックタグを利用したブロックがモジュール化されているからじゃないかという気がしますが。確かにそういった場合にキャッシュしていない場合に全体的に重くなることは事実で、でもそれはMTIncludeのせいではなくて各ページで共通の結果を出力する部分をキャッシュせずに処理していることが問題なわけです。MT3の頃だったか、モジュールをインデックス・テンプレートにして吐き出しておいてファイルとしてインクルードするようなTipsがあったかと思いますが、確かに劇的に効果的にはたらくケースもあります。

MT4(.xだったか記憶曖昧ですが)から実装されたテンプレートモジュールのキャッシュを使えば一定時間はビルドされずキャッシュが使われますからこれは効果があります。但し、再構築中に間違いに気づいてブログ記事を削除したりしたときに「最新のブログ記事」リストに削除したものが残ってしまうといった問題がないわけではないので、リクエスト毎にキャッシュを生成するようなプラグインなどはお手軽で、データベースでなくメモリへのキャッシュですので(最初の1回しか)クエリも発行されないといったメリットがあり劇的に軽量化できます。

• MTRequestCacheプラグイン(超シンプルなテンプレートキャッシュ)。

ということで、フロントエンジニアの人はMTIgnoreもMTIncludeも積極的に使って可読性が高くメンテナビリティに優れたテンプレートを書くことに集中すれば良いと思うのです。思うのでした。

追記

モジュールをフラット化した状態でCompile結果をキャッシュして実測。

4分1秒 / 3 分52秒 / 以下省略

あとMTIgnoreタグで囲めば処理しないという幻想がまことしやかにささやかれていた時期がありましたが、
あいつ一旦タグの内容なめてからコメントアウトしてますから、処理時間はその分もかかりますよ。
不要な記述はMTIgnoreするのではなく、テンプレート上から削除しましょう。

おっと、知らなかった。確認。

lib/MT/Template/Tags/Blog.pm の 166行目にちょっと追記。

    MT->log($name);

インデックス・テンプレートを作成

<MTBlogName>

プレビューまたは再構築してログ確認すると、ブログ名がログに残る。

テンプレートを下記のように修正。

<MTIgnore><MTBlogName></MTIgnore>

プレビューまたは再構築してログ確認すると、ブログ名がログに......残りませんね(そりゃそうだろ)。

一応念のため確認。

lib/MT/Template/ContextHandlers.pm の23行目

            Ignore         => sub { '' },

はぁ...

モジュール使わないとか直書きするとかコメント削除とか考えてないで可視性が良くメンテナンスしやすいテンプレートにすることだけ考えてたら良いと思うよ。あとはバックエンドの実装の人とか偉い人とか(ハードにお金出してくれる人とか)が考えたらいい。

で、コメントフィードはないの? と呟いたら

Twitter / シックス・アパート株式会社: 追加しました! http://bit.ly/9WU0 ...

追加しました! http://bit.ly/9WU0t8 RT @junnama: MTQってコメントフィードはないんですかね?

とのことなので、MTQダッシュボードプラグインをタブ切り替えでコメントも表示できるようにしました。

*MTFeed関係のファンクションタグが貧弱で投稿者の名前とかとれないんですよね。これ、要望あげましょうか。

• MTQ.zip

ユーザーダッシュボードの充実を希望 - MTQ | Movable Type 5 ユーザーコミュニティ

WordPress を引き合いに出すのは気分悪くする人もいるかもしれないのでしたくないのですが、しかし、あまりにも違うので議論にお付き合い下さい。

(中略)

Movable Type のユーザーダッシュボードの場合は、今後開発されるのでしょう！というような感じで、ほとんど有用な情報が表示されません。あるいは、あえてシンプルにして初心者に優しくしているのかもしれません。だとしたら、ブログのダッシュボードの方は、充実してもらいたいものです。

ということで、ユーザーダッシュボードを楽しく(そしてちょっとだけ便利に)してくれるプラグイン6種。 既にこれまでに公開済みのものも含みますが新規に2つほど追加して公開済みのものも若干手直しを入れてまとめて公開します(変更のないものもあります)。

MT_Tags

MTタグを定期的にTweetしてくれるTwitterアカウント「MT_Tags」が紹介するタグをランダムにユーザーダッシュボードのタイトル(こんにちは、Junnamaさん)の代わりに表示します。気が散る方にはお勧めしません。

• MT_Tags.zip

MTQ

MTQのフィードから新着10件を表示するウィジェットです。

MTQ.zip

QuickEntry

ダッシュボードからブログ記事を投稿出来るウィジェット(MT5.02でjQueryの扱い方が変更になっている点に対応、右カラム/メインカラムどちらに表示させることも可能にしました(出来てなかったので差し替え済み))。

• QuickEntry.zip

UserDashboard

ユーザーダッシュボードに左メニューを表示させ、This is Youウィジェットを右カラムへ移動して着脱可能にします(不具合指摘いただいていたのですが5.02で動作確認済みです)。

• UserDashboard.zip

ViewSite

ユーザーダッシュボード/システムメニューにViewSiteリンク(サイトを別ウィンドウで表示するリンク)を追加します(既に公開しているものと変更はなし)。

• ViewSite.zip

LoveRebuild

ユーザーダッシュボード/システムメニューにも再構築リンクを表示するウィジェットです(見栄えの修正 - * ふざけた画像は取り敢えず外したw)。

• LoveRebuild.zip

ちなみにこのエントリはQuickEntryダッシュボードからの投稿です。

• MT5 要望 再構築の改善

今後のMTへの要望（その1・再構築編）

1.「再構築の重さ」で多くのユーザーを失った

まぁ、これが直接の原因かどうかは僕にはわかんないんですけどね。静的パブリッシングだから採用されるっていうケースも多いのは事実です。個人ブログとしてではなく、そこそこの規模のCMSが前提ですが。

2.MT標準のダイナミックパブリッシングは不十分

多くのプラグインはダイナミックパブリッシングには対応していません。
また、テンプレート内にPHPを記述することもよくありますが、そのテンプレートをダイナミックパブリッシング化する際には、PHPの部分をSmartyの記法に書き換える必要があります。
これらのことから、既存のブログをダイナミックパブリッシングに変えるのは困難です。
実質的に、ダイナミックパブリッシングは使えないと言って良いでしょう。

不十分なのは単にプラグインの書き手の手抜きではあるわけですよね。Power CMS for MTは基本ダイナミック全対応が前提です。確かに2つの言語で書くことの負担はあるわけですが。SAKKさんに落ち度があるとしたら、ドキュメントとかサンプルの少なさですね。ことダイナミックに関しては。

まぁ、前置きはいいです。黙ってコードを書けよってことだよ。

RebildAt1stViewを書き直した

• RebuildAt1stView.zip

• MTディレクトリの直下のtools以下に「rebuild-from-fi」を設置して実行可能なパーミッション(755とか)を与える
• plugins/以下にRebuildAt1stViewディレクトリをコピー(DBのアップグレードあり)
• mtmlディレクトリのmtview_php.mtmlを出力ファイル名mtview.php、_htaccess.mtmlを出力ファイル名.htaccessとしてテンプレートに登録、再構築
• 適用したいインデックス/アーカイブテンプレート編集画面で「このテンプレートの再構築を最初のリクエスト時に行う」にチェックを入れます
• 再構築(チェックを入れてたら一瞬で終わる筈＞再構築は単なるファイル削除だから)
• 最初にリクエストがあった時点でファイルがなければ再構築されファイルが出力されます(で、ビルドされたファイルの内容がブラウザに返されます)

処理はPHPで行います。PHPがPerlスクリプトを介してビルドするから、Perlプラグインがそのまま使えます。吐き出されたファイルがPHPだったら、それもちゃんと処理されます。

何かうまく説明出来ないけどね、Perl版ダイナミックだけどPHPで動いててPHPが使えるソリューション、ってことだね。

• RebuildAt1stView.zip

Perl/PHP両方あるので管理画面や検索結果などにも適用できますが、やっぱりダイナミックパブリッシングかDynamicMTMLで同一URLでスタイル分岐させる等で動かすのが正攻法かと思います。実際はCSSとかJavaScriptだけでも出来てしまうんでしょうが。

<mt:IfiPad>
iPad向け
<mt:else>
そうじゃない向け
</mt:else>
</mt:IfiPad>

• MTIfiPad.zip

テストはしていません(一応UA情報変えて確認はしたけど...ってか、動くと思いますよ普通に)。ってまだ買ってないんだもの。

5月10日追記:管理者以外のユーザーのところで表示オプションがおかしなところに出てしまっていたので修正しました。

Twitter / にっく:【緩募】MovableTypeで、Aさん（もしくはシステム管理者）がカスタムフィールドの並び替えをしたときに、他ユーザー（Bさん、Cさん）も強制的にAさんの並び順にさせる方法をご存じの方、いらっしゃいますでしょうか。

Twitter / Seiko Kuchida:@Nick_smallworld カスタムフィールドの並び順に関して私の方でわかってるのはこのくらいですが、少しでも参考になれば。てゆか誰かプラグイン作ってくれないかなあ。 #movabletype

【緩募】って書いてあったので見逃してました...とか。要するにそういうこと(エントリの表示オプションを管理者が変更した時に全対象ユーザーに設定を適用)をするプラグインです。

ただ、単にそうすると管理者以外のユーザーが表示オプションを変更した時に違和感があるので、プラグインを設置すると管理者以外では「表示オプション(Display Options)」のリンクが非表示になるようにしました。

• EntryPrefsFixer.zip

This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

まぁ、それは置いておいて今日は裏話的なものを少し。

サイトでマニュアルやドキュメント、価格等を仔細に公表しているわけですが(現バージョンについては調整中)「公表しすぎじゃねーの?」って時々言われるわけです。「明らかに真似されてるよ」ってのがその理由らしく。

特定の何がどうという話ではないのですが、確かに明らかに模倣したようなものや意識したものが出てきてるわけなんですが、情報を仔細に公表するのは顧客のためだから仕方がない。一瞬迷いましたが今後も続けて行こうと思います(このレンジの製品で実際マニュアルまで公開してるのってレアケースみたいだし、価格も出してないところさえある)。

何故情報を仔細に公表するのが顧客のためになるか?

• 顧客は事前に機能を十分に知ることができる
• 弊社は問い合わせ等の対応を最小限に出来る(弊社には営業がいません)
• 事前の打ち合わせや問い合わせ対応を最小限にすることで結果的にコストを下げられる

だから、真似されるから隠すってのは顧客目線じゃないんですよね結局。情報を隠してインバウンド増やしてすぐに営業が駆けつけてってのは僕の目指す方向じゃない。

それでも類似品が出てくると当然「どう違うの」みたいな話になるので、どうせ作るなら仔細に情報を公開して優位性をちゃんと明確にすればいいのにそうもしないもんだから結局それって顧客を混乱させるだけじゃね? と思うわけです。

とはいえ2年間で170サイト超、お客さまと一緒に作り上げてきた製品だから、簡単に真似できると思ってもらっても困る(困りはしないんだけど、表面だけ真似して満足するなってことだ)。

ポリシーなき模倣は楽しくもなんともない

例えばPower CMS for MTにはツリー(階層)形式でサイトの構造を表示してサイト全体の構造を俯瞰できるBlogTreeダッシュボードってのがあります。これ、ツリー表示を組み立てるだけならプラグインでタグ作ってMTML書いてやれば数日あれば出来るわけですね。ただこれ本当に規模が大きなサイトで使おうと思ったらそれだけじゃだめです。重たくて使い物にならない。そこで、

• ツリーに表示するブログ/ウェブサイトを選択できる(ブログ・グループ機能)
• 表示する階層の数を設定できる。但し非表示の階層もクリック時にAjaxでリクエスト送って動的に展開表示できる
• 階層毎にキャッシュを生成して、毎回ツリーをビルドしない(ここが最も手間で重要な部分)

キャッシュの部分については非常に手の込んだ仕組みになっていて、例えば表示される内容ってユーザー毎に違うわけです(権限が違うから)。でもキャッシュは全ユーザー共通です。関連するオブジェクトに変更が加えられたらブロック単位でキャッシュをクリアし表示する際に再度キャッシュする。ではユーザー毎の表示の変更はどうしているか? (まぁそのあたりは隠しておいてやろう)。最初にこれを作ったときからCMSが重くなるのがとにかく嫌だったのでその部分については非常に手の込んだ仕組みではあるもののそんな実装をしています。MT5版になり、その部分についてもとにかく徹底した作り込みとテストを繰り返してる。

まぁ何が言いたいって分けじゃないですけど、表面を真似ることは簡単。でも作る背景というか、理念とかポリシーなき類似品作りってのは楽しくないし、何よりマーケットを混乱させるだけで顧客目線じゃないよ、ってことが言いたかっただけです。本当の模倣は理念とかポリシー、コンセプトからするもんだよ。

では月曜日にお披露目のセミナーの準備します。また来週。

<MTIfIE>
<mt:if name="ie_version" eq="6">

We love Internet Explorer 6!!

</mt:if>
</MTIfIE>

mt:var name="ie_version_id" とすると6.0が帰ります。

ダウンロード

• LoveIE.pl.zip