いたはし
2010年06月11日
はい、というわけで本日6月11日、19時半より北海道のIT以下略です。
待ちに待った、というべきでしょうか。そわそわしております。
念のためもういっかい！
本日19時30分～ お取り寄せダイニング十勝屋（コリドー街）にて開催です！
十勝屋さんはデュープレックス内にも鉄板ダイニング十勝屋というお店を出してらっしゃるのでご注意を！
コリドー街のほうです！コリドー街！帝国ホテルの近所のコリドー街です！
心が折れなければ私も本日参加する予定ですので、どうぞ皆さん、お手柔らかにお願いします。真剣に。
ぴろり上西
2010年06月10日
事業拡大に向けて、最近、社長とその仲間たち(上司)が面談のために頻繁に外出していたりします(事務所が狭いので、面談は隣のルノアールなのですよ) ディレクター職の募集なので、残念ながら上西のセクションが賑やかになることはないのですが、もし技術職を採用するなら、スキルを測るためにどんな入社試験を出すかなーとか妄想してました。
フィボナッチ数列;F(x)のF(10)を求めるプログラムを書け。F(0)=0、F(1)=1とする。
横３マス、縦３マスの魔方陣の解のうち任意の一つを求めるプログラムを書け。
以下のお題を Perl または PHP または JavaScript を用いて書け。足りない仕様は自由に設定してもよい。
MovableType 関係ないじゃん！って話ですが、まぁ、基礎ができていないと、MTの開発どころじゃありませんよ、ということで。あ、ちなみに妄想なので、正解できても即入社とかありませんので！
小林
2010年06月09日
先日告知させていただきました6月11日開催「北海道のITを盛り上げる会（仮）」ですが、満席となりました！ありがとうございます
。
まだ席の追加が出来るので、北海道にゆかりのあるIT系のエンジニア・デザイナーなどIT産業に関わっている方で、北海道について熱く語りたい方はぜひお申し込みください！
いたはし
2010年06月08日
なんか思ったより反響があってこわいので、もそもそ調整しました。
デザイナーサイド（html、MT構築側ね）で出来る再構築高速化について、サーバーのスペックがどうのとか、君そのアレはPerlのモジュールをアレすることでアレな感じにアレできるんだよCPANペラペーラ云々とかそういうハイソサエティなお話が鬼門な私がしてみることにします。
（いや大体わかるようになってきたけど）
※めんどくさい話は全部省きました。その辺はえらい人たちが説明してるだろうと思うので、ぐぐるか訊いてみてください。とりあえずまず使ってみたい人推奨です。
※本格的な高速化については、もっと色々手段があります。これはあくまでテンプレートベースで出来る話の一部です。
※どちらかというと、これをこうすることでタグの処理が速くなる…！とかというよりは、シンプルな記述を心がけましょうねという話です。
※はじめに言っておきますが体調悪いので話が冗長です。暇な人以外は基本読み飛ばして下さい。
※別に劇的に速くはならないです そんなに期待しないで！
で、高速化。
確かにサーバーのスペックあげれば再構築が500はじきだしたり止まったまま動かなくなったりという事はしなくなりますが、結局は底上げしているだけで、根本を解決してないので、記事数に応じてやがては同じ状況になります。
まあまたサーバーのスペック上げればいいんだけど、全員が全員リッチじゃないという話ですね。メリットの無いコストはかけたくないものです。
で、前置きが長いのは私の病気なのでそっとしておくことにして、
表題に戻りますと、再構築という処理を出来る限り速く安全に終わらせるために、あとデバッグ速度を上げるために、あとプラグインとか作る人に「テンプレートが悪いんじゃないの？ｗ」と言われないために（…）、心がけておきたいことがいくつかあります。
「MTInclude、MTInclude、なおかつ中でMTInclude！どうだ俺の入れ子構造…そんじょそこらのバカには思いつかない手だぜ！俺しびれるほどかっこいい！OK！Yes！」みたいなモジュール大好き人間がよくいるものですが、MTIncludeというタグを一つ使う毎に、再構築さん24歳独身の背中に大きな石が乗るようなものです。
なぜかというといちいちテンプレートを参照しにいかないといけないので、まあ、その辺の深い話はどっかに書いてあると思うんで省きます。
ただ、MTIncludeタグっていうのはMTのうまみみたいなものでもあるので、使わないで構築、とまでは思ってません。
共通化したほうが効率的なことも多いです。
というところで、MTIncludeタグを使うに当たっては、SSIやキャッシュを有効活用しましょう。
<MTInclude module="hogehoge" ssi="1">
ブログの設定らへんで「サーバサイドインクルードを使う」みたいな設定があったかと思いますが、
そこで選択した形式に基づいて、SSIしてくれます（要設定）。
例えばPHP選んでたら、<?php include(hogehoge);?>みたいなやつに置き換えてくれます。
「なるほど、わからん」という人は、わからんままでも大丈夫、私もよくわからんです。本当はちゃんと勉強して覚えるべきですが、その辺のモラル的な部分についてはこの記事では触れません。
注意事項があるとしたら、この内部でページのタイトルによっては…みたいな分岐が使えなくなることぐらいです。
ページ単位ではなく、サイト単位やアーカイブ単位で共通なところに使いましょう。フッターとかね。
<MTInclude module="hogehoge" cache="1" ttl="秒数">
cacheはそのものずばり、テンプレートの内容をキャッシュしてくれます。
わかりやすくいうと、一旦テンプレートの形を吐き出して、それを皆で使うみたいな感じです。
なので、Includeの処理自体はキャッシュの保持秒数内、或いは後述するキーが云々するまではたった1回のみになります。わあ、聞いてるだけで速くなりそうな気がしますね。
注意事項があるとすれば、一旦キャッシュした内容は秒数やキーで指定しない限り、デフォルトの秒数が経過しきるまではテンプレートの内容が変わらないということです。ページやアーカイブによって違う場合は、ttlで秒数を指定するか、キーを設けておきましょう。
「いやキャッシュとかキーとか言われてもよくわからん」という人です（私が）。
というわけで、keyの使い方を記載しておきます。
<MTEntryCategory setvar="cache_key"> <MTInclude module="hogehoge" cache="1" key="$cache_key">
$ってなんぞ？という人、前にsetvarした値は「$hogehoge」ってやると取り出せますって説明しましたので省きます。過去記事みてね。
要するに、カテゴリ名が同じ場合は一回作ったキャッシュを使って、カテゴリ名が違う場合は、新たにキャッシュを作ってくれます。
これにより、カテゴリやら月別やらの単位で表示内容を統一させつつも・・・みたいなことができますね。
そのIf要らないだろ…っていうIfは省きましょう。
<MTIf tag="BlogName"><MTBlogName></MTIf>とか書いちゃってる人たまに見ますが、
運用上絶対に入力するもの、または未来永劫何かのアクシデントでもない限りかわらないものは、MTタグで出力せず、直書きでいいと思います。
今は置換機能もちゃんと動くので、表記ゆれのミスさえなければ問題ないはずです。
あとMTIgnoreタグで囲めば処理しないという幻想がまことしやかにささやかれていた時期がありましたが、
あいつ一旦タグの内容なめてからコメントアウトしてますから、処理時間はその分もかかりますよ。
↑ちょっと怪しいので検証しまっす！！
まあでも使わなかった記述をコメントアウトしまくったりしていると、結局読みにくかったりなんだりなので、
テンプレート上から削除するのはおすすめしておきます。この辺は俺ルールですな。
プラグインパック売ってる会社の人間が言うことじゃないですが。
プラグインは、ひとつ読み込むだけで管理画面がちょっと重くなります。
管理画面重たいっていう人は、使わないプラグインをサーバーから削除 or 権限を落としてMTが読み込めないようにしてみましょう。あ、これ再構築関係なかったですね。
でも、たくさんプラグインを入れておくと便利なような幻想を抱いてしまいますが、サイトによって取捨選択は必要です。
便利でも、自分のサイトには必要ない、特につかわない、という場合は、削除することをおすすめします。
（使う時にまた入れられるように保存はしておこうね！）
これ先に言えば良かったかも。
Movable Typeで記事を公開保存する際、自動で再構築されるのは、MultiBlogプラグインの設定を除けば、
自記事＋前後記事＋所属するカテゴリアーカイブ（スタティックな場合）＋所属する年月日アーカイブ（スタティックな場合）＋インデックステンプレート（スタティックなもの全部）です。
スタティックなインデックステンプレートが山ほどあると、いやでも記事公開保存時に全部を再構築しようとしてしまいます。
記事保存がおわらない…！っていう人はこの手の罠にはまってるんじゃないかなと思わなくもないですよ！
スタイルシートとかJavascriptとか、毎回記事投稿する毎に再構築する必要はないですよね。
ファイルに直接ファイルリンクして、後はいじる時だけ再構築すればいいとおもいます。
あとは、MTタグで置き換えが必要でないテンプレート（利用規約一枚のみとか、ロゴだけとか）も。
というわけで、都度記事更新時に更新が必要でないものはスタティック以外の設定にしておきましょう。
リニューアルの時には手間がかかりますが、頻繁にリニューアルするわけでない場合は、日常の運用に支障がでないことにフォーカスする方が使い手的にいいんじゃないかなぁと思ってます。というか、どっちも支障がでないように設計することが大事ですね。
再構築ページ数が分割数分物理的に増えるからです。静的なのでしかたないのですけれど。
テンプレートの構造次第で気にならなくなりますが（600記事20件毎2アーカイブ＋αで3分前後とか）、乱用は気をつけましょう。
ちなみに前述した記事保存時の再構築にも含まれるので、インデックステンプレートに「すべての記事一覧」とか作って、記事全件呼び出すタグを埋め込んでスタティックにしてたりすると、毎回全ページ再構築しちゃうので気をつけましょう。
こんなところかな。
SetVarタグとかは使ってもそんなに痛くないので、ある程度同じ内容を出力する場合はSetVarしてGetしまくるという手もあります。
というか、ここまで書きましたけど、要はサイト設計とテンプレートの設計をきちんとしていれば再構築終わらない／(^o^)＼みたいなことはほとんどなくなります。
必要のないタグはかかない、必要のないプラグインはいれない、必要のないテンプレートは使わない。
「サーバーのスペック最低なんです！底上げ！底上げ！」なんていう前に、自分がわかる範囲でテンプレートを見直してみましょう。結構改善の余地はあるんじゃないかなと思いますよ。
まあサーバースペックはものすごく大事ですけどね！底上げ！底上げ！ と、言い逃げしておく。
小林
2010年06月07日
DuplicateEntry 1.2を公開しました。MT5に対応しています。
Solanowa ウェブ社内報
Copyright © 2010 SKYARC System Co., Ltd,. All Rights Reserved.
