2007年7月アーカイブ

MTカスタマイズ系の話題になると必ず RightFields が出てくるのだが、僕も似たようなものを作っていて社内で使っている (というかView担当に使わせている)。

これが結構印象に残ったみたいだが、僕はむしろ質疑応答時の小川さんの「LeftFields」発言が面白くて印象に残った。

よし、まずは名前から。LeftFields(TM) ということで夏休みの宿題にしよう(笑)。

まぁ冗談は冗談として、MT4になって実装されるような予感がしていたが実装されなかった(現状では) ものなんかを中心に、作っておきたいものをいくつかメモ程度に。

  • 承認フロー
  • 各アーカイブの並べ替えインターフェイス
  • 年「度」別アーカイブ
  • 再構築された静的ファイルとアップロードしたアイテムを統合的に扱うマネージャ
  • 複数ファイルのアップロード
  • エントリーと関連付いたアップロードアイテム管理
  • ログ解析
  • LeftFields(TM) (笑)
  • モブログ
  • 高速化関連
  • サイト運営者サイドの情報共有のしくみ
  • 会員制(認証付き)ページ
  • Backgeound RebuilderのV4対応

商用パッケージみたな本格的なものではなく、各プラグインがチョイスできる「手軽さ」を持ったものを作りたい。何となくそう考えている。

ウェブ制作 - アルファサード(アクセシビリティ, Movable Type ,モバイル)

WebSigには絶対間に合わせようと思っていた自社サイトのリニューアル。概ね評判は良いようで。というより、「らしくない!」「意外!」「絶句!」というか、僕のことを知っている人ほど「ありえねー」な感想をもらしておられた。ザマーミロ(笑)。「ありえねー」のが狙いだったのです。

まだ一部は作りかけだけど...モバイル版を作りました。MTのBootstrapアプリとプラグイン、Cron実行用のスクリプトのセット。かなり大規模なもの。MT4が出たおかげで対応の時間がかかったけれども、まぁ基本セットアップは丸一日あれば大丈夫な感じ。ただMT4から「ページ」と「エントリー」があるので、モブログも「ブログ」から「サイト」へ移行する使い方をしなければならない。やはりパッケージ化は難しいかもしれない。MT4の場合特に使い方が多様化されるから。

QRコード
http://alfasado.net/mobile/

Movable Type で高機能モブログを

ということで、パッケージ提供は当分無理かもしれませんが、モバイル版作成サービスを始めます。構築・運用のコンサルティングからデザイン・実装まで。

Movable Typeベースで作られているウェブサイトのモバイル版作成サービスを承ります。

当社のサイトではMovable Type (MT) 向けに開発した当社オリジナルのモバイルサイト拡張プログラムを利用しています(このブログでももう一つのブログでも使っています)。このプログラムをベースにお客さま向けに導入とカスタマイズを行います。

  • 携帯用に別途ページやエントリーを作成しなくても同一データから携帯版を作成。
  • 長いページのページ分割や画像の外部リンク化、画像のサムネイル自動生成が可能。
  • 携帯電話から画像付きのエントリーの投稿、エントリーの修正、再構築、コメント / トラックバックの承認・返信が可能。
  • 携帯電話からの投稿に外部サービスを利用する必要はありません。
  • コメント機能、トラックバック機能、検索に対応。
  • 別途PC用サイト構築やホスティングも対応します。
  • MT3 / MT4の両バージョンに対応しています。

画像付きエントリーの投稿も外部サービスを介さずに

携帯電話からの画像付き投稿を行う際、従来は外部サービスを使うのが一般的でした。このブログのシステムは、投稿専用のメールアドレスに投稿されたメールデータをこのサーバーからPOPで取得しに行くため、外部サービスを介する必要がありません。

また投稿可能な携帯電話のアドレスの事前登録とともに、メールに一定時間有効なパスワードを含めるしくみとか、携帯電話から投稿したデータは「下書き」状態になる等 (公開はMTの管理画面若しくは携帯用のオリジナル管理画面から行う) セキュリティ対策も考慮しています。

動作環境

本システムの動作にはUnix系のサーバーが必要です。またいくつかのPerlモジュールを必要とするため、サーバーにモジュールをインストールする権限が必要です。詳細はお問合わせください。

はっきり言おう。タイトルはネタ! (笑)

昨日のWebSigで質問いただいた件の補足。というか元々は別々の質問だったんだけど何かうまく答えられなかったような気がして帰りの新幹線の中で何となく考えていたこと。

静的生成とアクセシビリティは実は良く似たテーマ

「ウェブアクセシビリティの人からMTの人になったのは何故(<ちょっと表現違うけどこういうことだよね。)」「静的生成と動的生成とMTとWPと...Why MT?」という2つの質問。

サイト作成側が楽しようと考え過ぎ

* これはWeb屋の話ね。個人のブログとかは別。好きなもの使えばいいと思うし。

再構築うぜぇからWPだよね、ってのは安易すぎるんじゃねえか、と思うのだ。作り手がユーザーに配慮して苦労するってのはWeb屋なら普通のことじゃね?

アクセシビリティ実装うぜぇから「なんちゃってマークアップ」マンセーってのとどこが違うというのだ。

* 何だか前にも書いた↓気がするな。

従来のサイト制作は制作者が"がしがし"コーディングして作ってたわけだろ? いつからそんなに偉くなったわけ? あんた作成者だぜ? ユーザー気分になってないか? クライアントが再構築重いって? 「御社のお客様のためです。我慢してください」って言えよ。いやマジで。

何と言うかちょっとだけ真面目に書くと、CMSのユーザーとしての自分とサイトを訪問してくれるユーザーのどちらの利益を優先するか、ということ。CMSの普及によってそのあたりがまぁ何だ、勘違いする人が増えたりしてないかな、ってことだ。

動的生成と静的生成で一つ付け加えておくと、「動的生成は常にセキュリティリスク考えなきゃならない運命にある」ってことも忘れないようにしようね。

だから、まぁ何だ、「趣味は再構築」ってのは結構マジで言ってるわけですな。

結論:「静的」対「動的」ってのは全然本質的な議論じゃねぇんだよ。

と、ここまではネタ(長っ!)。

高速化とキャッシュについて真面目に考えてみるかも

小川さんに「真面目に高速化する気ないの?」って言われちゃったので少し考えてみた。考えただけだけど。

このブログのように、右カラム以外再構築が必要ない場合、再構築不要な部分をキャッシュに入れてしまえば良いわけだ。つまり、エントリー自身は更新されていないわけだから、右側のメニュー以外の部分は一旦再構築したらキャッシュしておいて、次回の再構築の際にはそれを使うわけ。そして右側のカラム部分はMTIncludeでも良いけどキャッシュを使っても良いようにする。

ファイルをディスクに書き込むから再構築は負荷、というのは 「ガセ」

良くある誤解だからこれまでにも書いたが念のため。ファイルをディスクに書き込むのが負荷、というのはガセ。こういうこと言う人は信用しないこと。

もちろんディスクに書き込まない方が負担は軽減されるが、節約できる部分って実は知れているのだ。

時間がかかるのは「テンプレートを読み込み、テンプレートタグを解釈し、データベースから必要なデータを読み込み、グローバルフィルター等による処理を行ってHTMLを組み立てる」部分である。ソース読めばわかるしいくつかの実験をしてみれば明らかである。つまりはMTなら$build->compileして$build->buildするところね。

例えばMT::BuiltChacheとか

builtcache_idint一意なID
builtcache_object_idintオブジェクトのID
builtcache_object_typevarcharentryとかcategoryとか
builtcache_blog_idintブログID
builtcache_template_namevarcharモジュール名(IDでもいいかな)
builtcache_modified_ontimestampキャッシュされた日時
builtcache_htmltext構築されたHTML(テキスト)

<MTIncludefromCache module="hoge" type="Individual">
<MTIncludefromCache module="hage" type="Index">

例えば type=Individual だったらエントリーIDとテンプレートモジュール名「hoge」からキャッシュの有無をチェック。キャッシュが存在すればキャッシュの modified_on とエントリーの modified_on を比較して、キャッシュを使うべきであれば builtcache_html を返す。

キャッシュを使うべきではない場合、テンプレートモジュール「hoge」を再構築してキャッシュに保存すると同時にリプライする。

type=Indexの場合は単純に modified_on を見て一定時間内であればそれを使う。そうでなければ再構築してキャッシュに保存すると同時にリプライする。

問題はモジュールに使えるMTタグが限定されることかなぁ。つまり各エントリーのブロックとかはキャッシュできるけど、カテゴリーのエントリー一覧とかのコンテナタグごとモジュール化しても実質無意味だし。

う〜ん、どんなもんでっしゃろ。むしろやっぱりメモリにキャッシュですかねぇ。

Webサイトは会議室で作られてるんじゃない! 現場で作られてるんだ! (織田裕二風!<嘘) な会議(<嘘) であるWebSig会議に参加して来ました。

プレゼン直前のMacBook

ひと言でいうと「参加して良かった」です。スピーカーの藤本さん関根さん小川さん、モデレーターの蒲生さんを始め色んな人にお会い出来た(話題?の鷹野さんにもお会いしたよ!)。あ、僕は大阪人ですけど少なくとも隔週では東京に来るのでまた機会があったら誘ってください(名古屋でも沖縄でも北海道でもハワイでもOKですよ!)。

* ちょっと飲み過ぎ喋り過ぎは反省してます! みなさんごめんなさいもうしません。

プレゼンの中でひとつ言い忘れたことがあった。MTのメリットの一つは、認知度・普及度が高いから「開発環境」の確認が楽なこと。「データベースは使えますか?」とか「言語は何が使えますか?」とか「PHPのバージョンはいくつですか?」とか聞かなくて良いもん。

「MTは動作しますか?」

サーバー管理会社とかに聞くときもひと言で済んじゃう。些細なことだけど現場では結構大切。

以下、まとまりのない雑感。

僕と「立ち位置」が同じ方々が多かったこともあってか色々聞かれたわけですが、僕が当初感じていたMTの「使いにくさ (for サイト制作 as a CMS)」はやはり多くの方が同じことを感じていて、それをプラグインなんかでカスタマイズしてっていうのが制作現場の「良くある風景」なんだよなぁ、と改めて。フィールド分割は意外? に需要があるんだな、ということも分かった。

僕の場合は自力でコード書く方向へ走ったわけですが、少しでもPerlに覚えのある方であれば一度書いてみればいいと思う。これは是非。WordPressでPHP書くくらいだったら...(ってのはWPあんまり知らない僕が言うべき事じゃないけど) 。

結局、僕のMTに対するスタンス (& 昨日の話の中で言いたかったこと) は「脱! テンプレ屋・脱! インストール代行屋」なわけです。これを去年の秋以来やっていてここまで来た感じですね。ちなみに昨日の「大人の事情タイム」にお見せした「フィールド分割、承認フロー、エントリー複製」のあたりのしくみは実は去年の年末には出来てました(ということは、プラグイン書き歴3ヶ月くらい)。公開してないのは、まぁ結構まじめに商用プラグインとか考えていたのもありますが、本当は「汚ったねぇコードだなぁ」って(o)さんに言われたくないからです(笑)。CHEEBOWさんが「同じようなもの作ってるんだねぇ」と仰せられてましたが、実際サイト制作現場で欲しいものって似たようなところに落ち着くのよね。

ちょっと話がそれましたが「スーツ」な僕でさえ (<冗談と思われてましたね) この位のカスタマイズは出来ます。いやマジで。話題にも出ていましたが分科会があるのなら書き方とかノウハウとか濃ゆ〜い話を、っていうか自分で企画すればいいんだよね。ニーズありますかね。制作会社向けMTプラグイン作成講座とか。「MT業界のフジロック ウッドストック!」とか銘打ってやっちゃおうか。場所は大阪。東京の人が来たくなるイベントに...ってどうです? >各位(誰?)。

何だかまとまらない感想になりましたが、お誘いいただき感謝。ありがとうございました!

Web2.0言うな!

| コメント(0) | トラックバック(0)
Web2.0って何ですか?
Web2.0っていうのは「ウェブニーテンゼロって」発音して...ブログが云々
私はそれで何ができるんですか?
...

この漫画は何? というと、リニューアルした当社のサイトの各ページ用に作った4コマ漫画のうちの一つ。

他に アクセシビリティ, ブログ/CMS, モバイル, 求人ページ用の各パターンがあります。今後も増やせる限りは増やしていこうと思うので、どうぞお楽しみください。

リニューアルについての考え方

少し真面目に書くと、今回のリニューアルにあたって「ウェブ制作会社の自社ページはどうあるべきか」について考えみたわけだ。

デザイン・表現においては『ウェブ制作会社の自社ページは「ショールーム」であり、「自社をどんなクリエイティブや技術で表現するのか」をお客様に評価いただく場である』という視点で全体を作り直し (その一つが「漫画」というアイデア)、コンテンツも現状の仕事の実状に合うように変更 (Blog/CMSモバイル等に新たにフォーカスをあてた)。

今回はMovable Typeで構築。今までクライアントにこのブログ (Junnama Online) 見せながら技術系のデモをしないといけないので中々恥ずかしかったのもある。

これまでもサイトから仕事はそれなりに来ていたし、実際はクライアントの多くが「リピート」や「紹介」なのでさほど (どころか全然) 自社サイトの更新ってしてなかったのだが (紺屋の白袴?)、やはり人材確保の面からも今後の発展の面からもきちんとしておかねばという強い思いがあって、一気に1週間程度でやり遂げた。僕たち自身が楽しんでサイト作ってないと、伝わらないし。

実はこれは序章にすぎなくて「この発想はなかったわ」的なアイデアが既にいくつかあるので、今後もどんどん新しいアイデアを取り入れて「制作会社の楽しいサイト」にしたいと思う。

楽しんでいただければ幸い。そして、ツッコミ歓迎、どんどん良くして行きたいと思うので。


クリエイティブって何だ?

このリニューアルのプロセスでもう一つ思い出した事がある。

例? のごとくブレスト後、内部でのデザインコンペをしたのだが、僕がオリエンした内容の中の言葉で「シンプルで力強いもの」という言葉に引っぱられてしまったスタッフが多かったのだ。採用案は「どこがシンプルやねん」というもの。

何故このデザインが採用になったか?

ひと言でいうと「僕は"本当は"これが欲しかった」からだ。

その昔 (もう5年近く経つのか...) サラリーマン時代に勤めていた会社の社長の言葉。

クリエイティブってのは『「顧客が実は気がついていなかったもの(*) だが、本当は"それ"が欲しかった」もの』を提供すること。

* 気づいていなかったわけだから、オリエンの時の言葉には「直接は」出てこないことがあるのだ。

作成した経緯

MT4から導入された「ウェブページ」と「エントリー」を紐付けるために作成したものです。他に「タグ」を利用する方法等もあるかと思いますが同等の事を実現する簡単で良い方法が見つからなかったので作成しました (「RelatedCatEntriesByBasename」ってタイトルが長過ぎ?)。

* このページの右下の「関連する新着情報」の表示のために作成したものです。

サンプル出力ページ

利用方法

<MTIfRelatedCatByBasename>
エントリーとbasenameが一致するカテゴリーが存在していれば真
<MTIfRelatedCatEntriesByBasename>
エントリーとbasenameが一致するカテゴリーにエントリーが存在したら真
<MTRelatedCatEntriesByBasename lastn="4" sort_order="ascend">
エントリーとbasenameが一致するカテゴリー内のエントリーを出力 (lastn (出力するエントリーの数)、sort_order (並び順 ascend|descend))
<MTIfRelatedCatByBasename>
  <MTIfRelatedCatEntriesByBasename>
    <MTRelatedCatEntriesByBasename lastn="4" sort_order="ascend">
      <MTEntryTitle><br />
    </MTRelatedCatEntriesByBasename>
    <MTElse>
      そんなエントリーはこのカテゴリーには無い!
    </MTElse>
  </MTIfRelatedCatEntriesByBasename>
  <MTElse>
    そんなカテゴリーは無い!
  </MTElse>
</MTIfRelatedCatByBasename>

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

ダウンロード

このネタ(あ、ネタじゃないのか)、実はこんな風に将来はなるんだろうなぁって考えていて、来年のエイプリールフールにリリースとか言って打ってやろうかと考えていたのだが。

テレビが見られるわけだし「液晶」なんだから、こうなるのは時間の問題な気がするな。でね、次は多分キーボードがつなげるようになるのではないだろうか。折り畳み式のキーボード。

OSはWebベース、ストレージもオンライン。で、携帯1台あればパソコンは不要。そんな風に妄想している今日この頃。

WebSigのスライド作成中 (もちろんMTで作成中!)。

タイムテーブルには「開発ネタ」と書かれているのですが、現在のところ以下のような内容を考えています。

タイトルは開発者向け*っぽいんですが、視点は「制作会社」というか、MVCでいうところの「V」を想定した視点で喋りますのでウェブ制作系の方に「へぇ」ボタン(古!?)押してもらえるよう頑張ります。

*何かいつの間にかプログラマにされてるし(笑)

Movable Type as a Web application framework.
〜開発プラットフォームとしての Movable Type〜

  • The Inside of "Junnama Online."
  • 制作会社はMovable Typeをこう使う
    • CMSとしてのMovable Type
    • Movable Typeを使ったコンテンツの再利用
    • クライアントの"わがまま"にとことん応える (←あとで消す)
  • 開発プラットフォームとしての Movable Type
    • MVC (Model-View-Controller) パターンとMovable Type
    • アルファサードの開発スタイル
    • Bootstrap.pmを利用したウェブアプリ開発
  • MT4とMTOSで何が変わるのか

関連エントリー

Junnama.com。

| コメント(0) | トラックバック(0)

以前名前+「.com」っての取得してどうとかいうやりとりがあってその時勢いで取ったドメインがあるのでMT4のお試し用にインストールしてみた。

何か「食ログ」みたいになってますが。

WebSigの準備しないと...(時間的にやばいけど、ちゃんと用意しますからね!) ということもあってMTを使ったサイト制作ネタを少しメモ的に書いておく。

SpecificFieldプラグイン, Path2AliasプラグインとIfMatchEntryプラグインの利用例

これまでに書きためたプラグインが結構な数になってきたので先日「Movable Typeプラグインアーカイブ」として纏めた。

エントリーにも書いたとおりこれまでは都度ブログのエントリーに作成、公開、修正等を書いて来たのでプラグインの「パーマリンク」が一定でないし古い情報のページからリンクを貼り直すのも大変。しかも途中でブログを一回移転してURLも変わっているし、SMOの観点からも良くないよね。ブックマークURLがばらけるから、ランクも上がりにくいし。

というのがMovable Typeプラグインアーカイブを作成した理由なのだが、同じようにエントリーを立て直すのも何だし、ちょっとした構成上/テンプレート上の工夫をしたのでメモしておく。

特定カテゴリーアーカイブの表示パターンを変更する

プラグインカテゴリーアーカイブの構成についての考え方

アーカイブのレイアウト

サイト制作の際にMTを使う際に「シンプルな構成を保ちメンテナンス性を犠牲にしない」ためのポイントの一つは「例外に引っぱられない」ことだと思う。特定の例外条件のためにブログをもう一つ立てたり挙げ句の果てにはカテゴリー毎にブログが乱立してしまいテンプレート数が増えてしまうとか、再構築が一度に出来なくなる等の構成にならないようにすべき(これは経験上から断言出来る) 。

今回特定のカテゴリーアーカイブとそのカテゴリーに属するエントリーにおける例外は以下の通り(上記の表参照)。

  • カテゴリーアーカイブの上部に任意のエントリーを表示したい。今後は更新履歴等をこのエントリーを修正していき、更新の際には日付を変更してトップページやRSSで周知できるようにしたい。
  • よって上部に表示させる任意のエントリーはトップページや右カラムの「最近のエントリー」「アーカイブ」「月別アーカイブ」「RSS」に表示させたい。
  • 一方、各プラグインのページはトップページや右カラムの「最近のエントリー」「アーカイブ」「月別アーカイブ」「RSS」には表示されないようにしたい。
  • 各プラグインは名称と概要のみ掲載し、詳細はプラグインを紹介した各エントリーのパーマリンクにリンクさせたい。
  • 但し新規作成したプラグインはエントリーとして表示されるようにしたい。
  • プラグインの表示順は任意に指定できるようにしたい。

言葉で説明するとややこしいが、上記の図をご覧頂くか他のカテゴリーアーカイブと比較していただくなりすると理解いただけると思う。

具体的なテンプレートにおけるプラグインの利用例

あとは...表示順の制御だが、これも実はオリジナルのプラグインを使っている。次回はこれを紹介したい(ドキュメントが整備出来次第公開したいと思う)。

MTOS (Movable Type Open Source Project) についてはおそらくMT4の正式リリース後でないと追加情報は出てこないと思いますし、1ユーザーとしては製品リリースに集中いただきたい思っていますので憶測めいた発言は避けたいと思いますが、以前ご紹介した Movable Type.orgMTOSのページのコメント欄にいくつか言及があるので引用して紹介しておきたいと思います。

MTOSについて

Welcome to MTOSのコメント欄より (一部抜粋*)

* 訳には誤りが含まれているかもしれません。

onoh June 12, 2007 7:15 PM

hi, i have 2 questions.
1)
can i upgrade "Movable Type Open Source" from
"MT4 Beta" ?
2)
can i get japanese version of "Movable Type
Open Source" ?


2つの質問があります。
1)
私は「MT4ベータ」から「Movable Type Open Source」へアップグレードすることができますか?
2)
私は「Movable Type Open Source」の japanese バージョンを得ることができますか?

Byrne Reese June 14, 2007 12:32 PM

@onoh - thank you so much for your questions. I am sorry I have not had a chance to reply sooner.
1) Yes, you absolutely can upgrade from MT4 to MTOS. However, how the app will change is still being worked out. That is what I want to discuss soon on the mtos-dev mailing list. But more importantly, MT4 will be available in two forms as MT is today: a free personal edition and a paid commercial edition. The open source version is actually going to be a slightly different product (they will share probably 99% of the same code and will look the same)... But I am getting ahead of myself. This is exactly what we will be discussing on the mtos-dev mailing list.

2) We are still working on internationalization of MT4. Eventually a japanese version will be made available for MTOS, but I am not sure when that will be.

Thank you so much for your inquiries!


@onoh - あなたの質問に感謝します。返事が遅くなってごめんなさい。
1) はい、絶対にMT4からMTOSにアップグレードすることができます。しかしながら、それはまだ作成中のものであるため appがどのように変わるだろうかはまだわかりません。この件については mtos-dev メーリング・リスト上で議論したいものです。
しかし、より重要なことは、MTが今日あるように、MT4は2つの形式で利用可能になります:自由なパーソナル・エディションおよび払われた商用版。オープンソースバージョンは、実際にわずかに異なる製品(それらは、恐らく同じコードの99%を共有し、同じに見えるでしょう)になるでしょう...しかし、説明は性急すぎるかもしれません。これはまさにmtos-devメーリング・リスト上で私たちが議論するべきものです。

2) 私たちは、現在もMT4の国際化に取り組んでいるところです。結局、japaneseバージョンはMTOSに利用可能になるでしょう。しかし私はそれがいつになるかは分かりません。

質問をどうもありがとう!

Terry Heath June 16, 2007 9:31 AM

Could you clarify the licensing for MT4? What is the difference between acceptable uses of the Open Source and Commercial versions? For instance, could an internet marketer use the open source version to operate a group of blogs that are designed to generate Adsense income?


MT4のためのライセンスについてはっきりさせていただけませんか? オープンソースとコマーシャルバージョンの許容できる用途の違いは何ですか? 例えば、インターネットマーケッターは、AdSense収入を得るためにデザイン・設計されたブログのグループを運営するのにオープンソースバージョンを使用することができますか?

Byrne Reese June 16, 2007 10:12 AM

Under the terms of the GPL, the license we are currently planning on using with MTOS, users of the software are completely unrestricted in how they can use the software. They can use it to power a blog that generates $1,000,000 in revenue if they wanted to. So MTOS is unrestricted in terms of use, allows for redistribution but with restrictions. Here is perhaps a good way to describe it all:

MTOS MT4 Personal MT4 Commercial
Cost FREE FREE Depends
Commericial use ok? Yes No Yes
Personal use ok? Yes Yes Yes
# of Blogs unlimited unlimited unlimited
# of Authors unlimited unlimited $$ per user
Can redistribute Yes No No
Support Avail? From Community From Six Apart From Six Apart
Features Base only Base + more Base + more


私たちがMTOSに適用を計画しているGPLライセンスのもとでは、ユーザーはMTOSを完全に無制限に利用できます。お望みであれば100万ドル稼げるブログの運営にそれを使う事もできます。MTOSは使用は無制限で、再配布についても考慮されていますが、制限があります。 皆さんに説明するには以下のような表現が良いでしょう。

MTOS MT4 個人利用 MT4 商用利用
費用 無料 無料 有料
商用利用はok? Yes No Yes
個人的利用はok? Yes Yes Yes
作成出来る
ブログ数は?
無制限 無制限 無制限
ログイン
ユーザー数は?
無制限 無制限 ユーザー数に
よって課金
される
再配布可能? Yes No No
サポートは? コミュニティ
から
Six Apartから Six Apartから
機能 基本機能のみ 基本機能 +
追加機能
基本機能 +
追加機能

Byrne Reese July 10, 2007 12:02 PM

One question we have received from a number of users is about the use of the name "Movable Type" in association with products that utilize MTOS source code.

The open source license associated with MTOS pertains to the project's source code only. The name "Movable Type" is actually a registered trademark and thus cannot be used without the express and written permission of Six Apart. In other words, third parties are not permitted to redistribute altered versions of MTOS under the product name "Movable Type."

It is however safe to say that "this project utilizes, or is based upon code from the Movable Type Open Source Project." I hope this clarifies any questions you might have. If not, please contact us and we can help resolve any remaining concerns or questions you might have.


私たちが多くのユーザから受け取った質問はMTOSソース・コードを利用した関連製品における 名称 "Movable Type" の使用についてです。

MTOSによってオープンソース化されるのは製品のソース・コードのみです。

「Movable Type」は実は登録商標で、シックス・アパートの許可(書)なしでは使用することができません。言いかえれば、サードパーティーは製品名「Movable Type」の下で、MTOSの変更されたバージョンを再配布することは許されません。

しかし、このように表現することは問題ありません。
「このプロジェクトはMTOSを利用しています、あるいはMTOSのコードをベースにしています。」

私は、この答えが皆さんの質問に対する明確な答えとなることを望んでいますが、もしそうでなければ連絡してください。私たちは、この件に関して皆さんが抱いている質問等の解決を支援することができるでしょう。

MT4雑ネタあれこれ。

| コメント(3) | トラックバック(1)

Movable Type 4 Beta7

MT4もベータ7まで来ました。はっきり言って追いつきませんわ。
ベータ5〜6は試せず、ベータ7を取り敢えずインストールして会社のサイトのリニューアルに使おうとしている。何せ今週中に完成させないと週末のWebSig会議で話すネタに困ってしまう。ということで、とばっちりを受けるのはFくん、SさんのMo[e]vableType開発チームだな。まぁ頑張りましょう。

えーっと、ライセンスはProNet会員向け提供の件はどうなるんだろう? まぁ聞いてみてライセンス必要なら購入しましょう。Web系のスタッフでログインユーザー数5だからちょうどいいし。

ちゃんとフィードバックしてる?

最近 Livedoor Reader 使い出してMT関連のブログ検索結果のRSSとかソーシャルブックマークのMTネタとかは欠かさずチェックしているわけだが、みんなブログに書くのは良いのだがちゃんとフィードバックしてる?

まぁそろそろリリース候補版ということで機能の追加ではなくてバグ対応になっていくのだろうが、これだけ新機能があるとバグの方もね...

ちょっと気になっているのはJavaScript, Ajax風? なCMSであるが故にクロスブラウザ関係のバグ対応が結構大変じゃないかな、という点。

あなたがつまずいた箇所はきっと誰かもつまずいている件

というわけで? 中の人も忙しいでしょうからいくつかMT4絡みのブログのエントリーから気づいたところを勝手に返答してみる(聞かれてもいないのに...)。

FastCGI環境でプラグインの追加や更新が反映されない件。
よろしければTouchMe プラグインお使いください。

リッチテキスト(WYSIWYG) の生成するソースの件ね。これはブラウザによる部分だそうで、おそらくFirefoxだと"まし"じゃないかなぁ。
っていうかこれも tag2xhtmlプラグイン 作ったのでお使いください。

フィードバックするだけじゃなくてちゃんと情報収集しようね! って俺がもうちょっと有名ブロガーだったら良かったのか!?

いっそのことWebアプリのテンプレート管理にMTを使ってみたらどうか

話しそれまくって恐縮だが先のエントリー「OpenPNE」にちょっと触れたのだけど、MTのGPL版が出たらいっそのことOpenPNE のテンプレート自体をMTで管理したら面白くないかな?

結局Smartyのテンプレートな訳だよね。別にOpenPNEじゃなくてもいいんだけど、静的生成ができるMTならではの面白い使い方だと思うんだけどね。

もちろん現状のMTママではゴミファイルが残ったりする可能性もあるし辛い面もあるけど、再構築された (ファイルシステムに書き出された) ファイルさえきちんと管理できるようにすればMT自体がWebアプリのテンプレート管理システムとして使えてすんごく面白いと思うな。このネタいずれ改めて書くかも。

コメント/トラックバックスパムが本当にこない件

いや、本当にこない。見事に。スパムフィルターとかじゃなくてCGI叩かれないから負荷一切かからないです。お勧め。

もちろん、ちゃんとした? コメントやトラックバックは来ています。

ところで、WordPressって人気なのね

ところで、WordPressって人気なのね。エントリーの内容ってそんなに特別なこと書いてるわけじゃなくてすごく基本的なことなんだと思うんだけど(はてブのホッテントリ入り、200ブクマ超えてら...

これなんか↓ すんごく気合い入れて書いたんだけどなぁ。37ブクマか...

ってのはWordPressかMTかという問題じゃなくて俺が人気ないからか...失礼しました!

スクリーンリーダー利用者とのやりとりから理解できること

「ウェブコンテンツ・テキストバージョン・ジェネレーター(Naked Beta)」なるものを作っているのだが、先日某SNSの「視覚障害者のパソコンサポート」コミュニティにて「PDFの扱い方」スレが立っていたので初めて書き込ませていただいた(Naked(Beta)ではPDFをテキスト化することができる)。

その後メンバーの方が参加しているメーリングリストで紹介いただいた関係で何通かメールをもらった (感想や要望など)。早速いくつかは反映させていただいたが、そのメールでのやりとりから改めて「音声ブラウザやスクリーンリーダーといってもその使い方は様々」ということを実感したので、ちょっと紹介させていただこうと思う(これまでにお会いして話を聞いた他の方の例もあわせて紹介したい)。

以下、利用環境の一例。

  • OSはWindows。
  • VDMW300 (PC-Talker系列) を利用。
  • ブラウザはInternetExplorer 6。
  • Orbit (ダウンローダー) を「スタートアップ」に登録している。

ウェブの利用の方法の一つとして、この方の場合はウェブページやPDFをクリップ・ボード経由でエディタに貼り付けることが多いとのこと。

ポイントは、PDFへ移動しようとする際にOrbitが起動してしまうこと(単に拡張子の問題だろうな)。Naked経由でPDFを読み上げる場合はOrbitのダイアログで「キャンセル」を選ぶ必要があるらしい。

エディタに貼付けるとかエクセルに(テーブルを)貼付けるってのは他の方にも聞いた事があって、スクリーンリーダー+エクセルだと「矢印キー」でセルの移動ができるから表を読み上げるのには便利だよ、というお話をしておられた(この方には少々驚かされた。エクセルもそうだが、ページ内で欲しい情報はエディタに貼付けてエディタの検索機能を使うから、ほら、こうやって...速いだろ? って...*)。

* もちろんこの方はかなりの上級者だからこうできるのであって、一般のユーザーだとこうはいくまい。

また、他の方の場合 (弱視の方) ルーペを使えば見えるけれども (つまりソフトウェア的に拡大ではなくて、実物のルーペを使ってディスプレイに顔をくっつけて情報を見る)、音声ブラウザは楽だから読み上げソフトはよく使うよ、と言っておられた。

これは完全に余談だが「目の見える人は不便やのう(笑)。わしら重たいモニターとかいらんもん。」ってな冗談で僕らを笑わせてくれたおっちゃんもいた。

携帯ブラウザでPCサイトを閲覧する

私事で恐縮だが、Naked(Beta)を最も活用しているのは誰あろう自分自身である。用途は携帯からのPC用サイト閲覧。

スポーツのリアルタイム中継とかでPC向け無料、携帯向け有料ってサービスが結構あるので(セコいな! 俺)、Naked(Beta)の「携帯」モードのURLをブックマークに登録しておいて外出中はそこからウェブサイトを見ていることが多い。

僕の携帯には一応フルブラウザが入っているのだが、僕にとっては使いやすいものではないし、何より画像込みの重たいページをダウンロードするには電波状況がかなり良くないと途中で切れてしまうことが多い (回線速度も決して速くない)。またあの小さなディスプレイの上ではやはり携帯向けのページの方が使いやすい。

Googleのモバイルゲートウェイやライブドアの「モバウザー」とか同じようにPC用のサイトを携帯用に変換するサービスは存在するが、これらのゲートウェイで変換して「読みやすい」サイトと「読みにくい」サイトがある。これらのゲートウェイで変換して読みやすいページは、音声読み上げでも理解しやすいと考えてほぼ間違いないだろう。装飾が排除されシンプルに構造化されたテキスト情報こそが携帯ブラウザで読みやすいページであるからである。

ウェブサイトやソフトウェアは意外な使い方をされている

覚えておきたいのは、それがソフトウェアであってもウェブサイトであっても、どんな利用のされ方をされているかは全く分からないということだ。

VDMW300のほうはともかく、Orbitの開発者たちは視覚障碍者がこんな使い方をしているなんておそらく想像もしていないだろう。

サイトの中での「文字の画像化」がエディタを使ってページ内検索をする人にとってはマイナス要因になっているということも普段僕たちはあまり気にしない。

PCでの閲覧を前提にサイトを作成していて「携帯版は想定外」な場合でも、ゲートウェイを使って携帯で閲覧しているユーザーがいるかもしれない。

「サイトのターゲットはこうだから...」という考え方をするのは構わないが、そのサイトやサービスをどう使うかはユーザー次第であり、全然自分たちの想像から離れたところで有益なものとして使われているかもしれないのだ。

「色んな使い方ができる」のが「Web標準」

で、まぁ何と言うかここからが答えになるわけだが、「そんなに色んなブラウザやユーザーをターゲットにして制作する側の負担ばかり増える...」という思考の対極にあるのが「Web標準」なんだな。

表現は視覚だけじゃなく音声だけでもない。また音声にしたって使い方は一通りじゃない (だからこそIAとかペルソナ/シナリオ法とか...それはそれで大切であるが「想定外」の使い方にも耐えられるつくりにしないといけない、それがアクセシビリティ)。

どんな使い方をしてもらってもいいよ。色んな使い方ができるよ、ってのが「Web標準」の本質なのだ。

制作者とクライアントにメリットはあるか

これはもう滅茶苦茶あるね (日本語滅茶苦茶...)。まずユーザーにメリットがあること=制作者の幸せでありクライアントへのメリットじゃないか。

まぁ、ありきたりのことを書いてもつまらんだろうから少し目線を変えてウェブプログラマ向けに書いてみようか。

思いつくままに羅列すると、工数短縮・コードの短縮、分業化、メンテナンス性の向上、出力されるHTMLの減量→トラフィックの節約、等々。

これらの殆どは制作者のメリットでもあるが例えば受託の開発であればクライアントのメリットに直結する。工期とコストの縮減、メンテや改良コストの縮減、さらにウェブサイトやウェブサービス利用者へのメリットがあるとなれば、もう「やらない理由が無い」ではないか。

と、まぁこのあたりで息切れして来た。「早い段階での分業化が可能」「テンプレートを半分に減らす」あたりを続いて書こうかと思っていたが、続きはいずれ書く予定。

あ、そうそう具体例を一つだけ。

SNS構築案件の時に「OpenPNE」を試してみたことがあるのだが、テンプレート数の多さとテーブルレイアウトのコードのあたりで嫌になってしまい結局採用を見送った (今のバージョンは良くなっているのかもしれないが)。何もそこまでmixi真似することもなかろうに。

これ「Web標準」ベースだったらテンプレート数とコード量おそらく半分近くになるだろう (これ本当)。テンプレート数が減ったらカスタマイズ工数も大幅減ですよ。

と、ここまで書いたところでこんなエントリー見つけてしまった...

アクセシビリティはボランティアじゃないっ!

ということでタイトル改題。まだこんなこと言ってるのか...何年前の議論だろうか。

ここまでお読みいただいた方は既にお分かりだろうが「アクセシビリティ」は何も障碍者のためだけのものではない。特にページを処理するプログラムを書く人間に対するアクセシビリティが高ければ高いほど様々なメリットが享受できるようになる。

確かに冒頭のNaked(Beta)の話はボランティアというか、実際にパソコンサポートという形でボランティアされている方とのやりとりがきっかけで...という話なのだが、何も僕自身はNaked(Beta)をボランティアで作っているわけでも趣味でつくっているわけでもない。

このプログラムの本質はHTMLの構造を保ったままてきるだけシンプルなテキストバージョンのHTMLに変換する「アクセシビリティ・テキスト変換エンジン」なのだ。で、この変換エンジンはサイト制作現場というきわめて「ビジネス」的な世界で様々な活用が可能である*。

もちろんこのプログラム自体への引き合い(製品やサイトへの組み込み)も頂いているが、変換エンジンの部分はもっと多様な利用方法を想定して作成している。

いくつか例をあげよう。

サイトリニューアル時の既存ページの変換・再利用

サイトを新しいデザインに変更するだけなのに、既存のページをいちいちコーダーがひぃひぃ言いながら流し込み直し、マークアップし直しとかするの? 何か無駄じゃない? 旧ページを機械処理でCMSにインポートして、新しいデザインテンプレートを適用して出力(某方面では「再構築」と呼ぶアレ)し直したらリニューアル終了! ってな形で活用している。

もちろん、ページの構造がきれいであればあるほど変換は容易である。

どっか(どこ?)の制作会社に騙されて(!) 「Web標準」で作ってみたけどリニューアル見積もりとったら全然安くないじゃん! というクライアントの皆さんはどうぞウチの会社にご連絡を。きっとびっくりするようなワークフローと見積もりの提案が可能かと*。

* もちろん、ウチ的にちゃんとそれで利益があがるわけです。スタッフも「ひぃひぃ」言わないし。

サイト運用におけるアクセシビリティの継続確保

せっかくCMS入れたのに覚える事沢山すぎる...あんたらフォームの全半角揃えとかはサーバー側で行うべきとか言うくせに、CMSへのテキスト入力の際は私らが気をつけないといかんのか? というクライアントの皆さんはどうぞウチの会社にご連絡を。ガイドラインに違反した入力は可能な限り機械的に修正・出力するという考え方でCMS構築します。

何か単なる宣伝になってきたな...まぁ、工数短縮・コード縮減のあたりでも書いたが、「Web標準」ベースだとサイト全体にわたる修正とかも楽だから、「えー!! ここまできて全ページにかかる修正ですか!? 勘弁してください」とか言われなくて済むようになるし。

とか...本当に息切れしてきたので続きはまた今度書く...かもしれない。

殆どがここに書いた事だけど。

トラックバックスパムもコメントスパムも来ないと何だか寂しい...。

まだ対策して数日ではあるけれど、今までは2〜3日したらスパムが来てたから。

ここ数日トラックバックスパムもコメントスパムも来ない。何だか寂しいな。 ログを見ると相変わらずmt-comments.cgiとかmt-tb.cgiは叩きに来てる。阿呆が。 CAPTCHAは絶対使いたくなかったのでまぁこれが正解だろう。現状では多分。

  1. テンプレートから「<$MTEntryTrackbackData$>」を削除する。これで「自動検知」できなくなる。
  2. トラックバック、コメントCGIをリネーム。単にリネームするだけでなく拡張子も変えてしまおう。トラックバックCGIについては更にhtmlファイルに見せる技を使おう。
  3. コメントは「確認」画面を経由させるようにして直接ポストできないように。但しJavaScriptオンの場合は直接ポストできるようにする。そもそもJavaScriptオンの人は意識せずに済むし。
  4. 古いエントリーのトラックバックやコメントを閉じてしまおう。攻撃のターゲットは少ない方がいい。
  5. トラックバックやコメントのCGIに対してGETリクエストを制限しよう。

背景・経緯

MT4のWYSIWYG編集では、例えば "<br>" が "<br />" にならないとか IMG要素が閉じられない (つまり空要素が />で終わらない) 問題があります(Beta2の時にフィードバック済み)。

またWindows版 Internet Explorer, Opera* だと要素タイプ名/属性名が大文字になってしまいます。

*Macintosh版 Safariでも要素タイプ名/属性名は大文字になりますが、そもそもSafariではWYSIWYGがうまく動作しません。

テンプレートはXHTMLで書かれていますのでこれらの部分はXHTMLとして正しくないことになります。

また、B, I, U, STRIKE, FONT 等の要素が使われることからWYSIWYGを敬遠する人も多いかと思います。

簡単に修正できるのか? と思っていましたがBeta7で修正されていないところを見るとコード数行で済む問題でもないようです。

H.Fujimotoさんのエントリーによると、

動作からすると、リッチテキストエディター部分のinnerHTMLプロパティをそのまま出力しているようです。

とあります。となるとブラウザがHTMLを生成しているわけで、修正するには根本的に実装方法を変える必要があるという、ちょっとやっかいな仕様ということになります。

MT4のWYSIWYGエディタについて言及している他サイトのエントリー

ということもあって、MT4のWYSIWYGエディタが生成したHTMLを出来る限りクリーンアップするプラグインを作成しました。

利用方法

プラグインフォルダに tag2xhtml.pl をアップロードします。

再構築の際 (ファイルがディスクに書き出される直前) にファイル全体に対して処理を行います(「確認」段階では処理は行われません。またデータベースに格納されるデータは変換されません)。

ダイナミックパブリッシングには未対応です。

処理内容

  • 要素タイプ名と属性名を小文字に変換します。
  • 空要素タグを /> で閉じます。
  • B, I, U, STRIKE, FONT 等の物理要素をそれぞれ STRONG, EM, INS, DEL, SPAN要素に置換します (簡易的な対応ではありますが、主な視覚系UAのデフォルトスタイルが同等な論理要素に置換します) 。

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

ダウンロード

Naked (Beta)について

「音声ブラウザと相性の良いHTMLをつくる」というコンセプトで開発を始めた「ウェブコンテンツ・テキストバージョン・ジェネレーター(ゲートウェイ)」です。

以前にも紹介しましたが、その後色々と調整を行い実用レベルになったと思うので、このブログの各ページに各モード(スキン)変換のためのリンクを設置したついでにブックマークレットを作りました。宜しければご利用ください。

これは何?

  • HTMLからCSSや装飾部分, JavaScript等を削除します。
  • 一定サイズ以下の画像はALT属性の文字列に置き換え、一定サイズ以上の画像は外部リンクに変換します。*
  • 音声読み上げの際に問題になることの多いいくつかの問題 (日付のフォーマット、機種依存文字、DEL要素,INS要素、スペースによる日本語の分割等) の解決 (読み上げやすい、あるいは読み上げて意味の通りやすいフォーマットへの変換) を試みます。
  • レイアウト用のテーブル要素 (らしきもの) を削除してできるだけプレーンなHTMLに変換します。
  • PDFをテキスト化します。
  • 上記の変換を行った上で、各スキンの適用やルビ振り処理を行います。

* 画像については実際はもう少しインテリジェントな? 処理を行っています。見出し要素の中の画像は「テキストが画像化されたものだろう」、とかアンカーの中の画像は「ボタン」だろうとか。詳しく知りたい方は関連エントリーをご覧ください。

ブックマークレット

サイト貼付け用JavaScript

このブログに貼っているJavaScript↓そのまま使っていただいても構いません。


<script type="text/javascript" src="http://junnama.alfasado.net/online/naked.js"></script>

H3要素で「スタイル:」というラベル、各リンクはUL, LI要素によるリストです(このブログではCSSで一行に並べています)。

より詳細な仕様について

関連エントリーをご覧ください。実装の課程で書いたものです。どういうコンセプトでどのような処理を行っているかを書き連ねています。

関連エントリー

制限事項

  • httpsからはじまるURLのページには対応していません。
  • クッキーが必要なページやログインが必要なページには対応していません (ブログのコメント程度であれば問題ないと思います)。
  • HTMLやPDF文書の容量は4MBまで対応しています (実際に視覚障害者の方に要望をいただいたため、1MBから4MBに制限をゆるめましたが、サーバー負荷の問題もありますので暫く様子を見たいと思います)。
  • サービスは予告なく停止する場合があります。

プライバシーについて

  • フォームからポストされたデータ等は運営側では一切保持しません。
  • ゲートウェイから実際のサーバーへのHTTPリクエストヘッダ (UserAgent情報) にIPアドレスが付加されます(匿名プロキシとしての利用対策)。
  • IPアドレスと閲覧ページのURLについてはログに保存しています。

ちょっと宣伝

CMS製品への組み込みや企業や自治体様のサイトへの導入やカスタマイズについてはご相談ください。

また、Nakedと共通(一部のみ)のテキスト変換ルーチンを組み込んだMovable Typeのプラグイン(Movable Type Jaccessibilityプラグイン)を提供しています。

タイトルの通り、以上。

Twitterみたいに見えないかなぁ...

自分がどのポジションに属しているかは関係なく客観的に語るね。僕はいつでもニュートラルだから悪く思わないでおくれ (<誰に言っとんねん?)。

一つ前のエントリーはネタ的に書いたのだが、改めて見ると「JavaScript/Ajax/DOM」のトラックが唯一あるくらいで (何が話されたかは知らないわけだが...ブログに書くくらいなら行けば良かった) 、Webプログラマのトラックが無いように見える (CMSの話が無いのは良いとして、モバイルの話が無いのはどうなんだろう)。

コンテンツの再利用やワン・ソース・マルチユースの「理論上の」話はそれはそれで良いのだけれど、実際の現場ではWebプログラマの力によってUAの互換性のなさをうまく吸収したり、コンテンツの再利用をプログラミングによって省力化したり、CMSと連携させたり大量のコンテンツを効率良く生成したりといったことがあたりまえに行われているし、その際のディレクターやデザイナーやコーダーやWebプログラマー (だけじゃなくてAPI開発者やブラウザ開発者、あついはハードウェア開発者) の共通言語が「Web標準」なのではないだろうか。そして最終的に実装系で一番「標準」や「互換性」と闘っているのは実はプログラマではないか?

そして開発のスピード向上やコスト削減に「Web標準」が有効であることを肌で感じているのが彼らである。


標題の件ここまで。以下、またまた余計な事を言う俺...


「CSS Nite」なら良い。「Web標準」って誰 (というかどの立ち位置の人間) のものでもないし、そのあたりのバランスを考えないと「業界の底上げ」とかままならないし、今回のような誤解か理解か近いか遠いかわからないような何かあまり気持ちのよくないものが残るわけだ。

もちろんプログラマだけじゃない。支援技術開発者とか、あるいはユーザーを巻き込むともっと良くなると思うな。

僕が「あったらいいな」と思う視点を勝手に書くと、

  • プログラマトラック (ウェブアプリのアクセシビリティの視点やXML/HTMLパーサ等を書いている人の視点、ブラウザ開発の視点)
  • ハードウェアトラック (PC, Mac, 携帯電話、そしてハード面の支援技術開発者の視点)
  • ブラウザトラック (に追加して「携帯ブラウザ」「携帯フルブラウザ」「音声ブラウザ」etcの開発者側の視点)
  • ユーザートラック (障害者支援、高齢者のユーザーグループとかあるいは教育現場 (情報教育担当者) の視点)

このあたりがあると素敵だし、「Web標準」という言葉がもっと明確な意味を持ったメッセージとして伝わると思うな。

一応付け加えておくと「勝手なことほざいてないで何か手伝え」っていうのなら手伝うよ。「じゃぁお前がやれ!」とかじゃなくて、建設的な議論の中で良いものを一緒に作ろうっていうことなら喜んで。

「内容はネタ、タイトルは釣り」なので宜しく>各位(誰?)


勿体ねぇ! 勿体ねぇ! 勿体ねぇ!

主催者はWeb標準の日々プログラマーのトラックがない件についてどう考えているのだろうか。

もうこの時点で、この企画は終わっている。

ValidなXHTMLが本当にパワーを発揮するのは優秀なギークがいてのこと。

そのことを無視して「凄い人」も何もない。断じてない。

*ってか、最後のブロックは要らなくね? Danさん。

論点がぼやけるし。

まぁ、本件についてはここに既に書いたので、以上Danメソッドでお送りしました。

Junnama as a Blog Nite.

続きまして、yuuメソッドで[謎]

とりあえず、立場が違えば発言も違うわけで[謎]。

香ばしい[謎]とはいえこういう話が上がって良かったのではないかと[謎]。

今日はこのへんで[謎]。

このエントリーは「ネタ」ですが、ロジックとしては筋が通っている気がしないでもない...

AdSenseの広告の質が落ちてきたなぁ、と。マッチングの精度ではなくて「質」ね。

他の広告の場合精度が悪いというよりも絶対量が少ないだろうからマッチングが悪いのは割り引いて考える必要があるけれども。

どうも僕の中ではGoogleは「技術」はあるけど「サービス品質」はあまり良くないイメージになりつつある。

「情報商材」イコール「マルチ」ではないけれども最近は結構被っているイメージがあって、mixi とかだと「足あと」を奇麗なお姉さん (事実は違うのだろうけど) が踏んでいってプロフィールとか見ると見事に「私は"これ"で会社を辞めました(古!)」じゃなくて何て言うか「ネットワークビジネスで人生が変わりました!」とかのオンパレード。

「足あと」というより「犬のオシッコ」だな、こりゃ(*)。

* 何故SNSをやらないの? という会話である方曰く『「犬のオシッコ (「足あと」のこと)」みたいのが気持ち悪い』って...名言だな。

ちょっと話がそれた。本題に戻る。

↑このエントリーの内容でどんな広告が出てくるのでしょう?

「Adsense」「アフェリエイト」というキーワードで検索すると出てくる「不労所得」とか「副収入」を謳う広告の数々 (もちろん、まともなものもあるが)。

ともかく、従来のメディアでは審査に通らない広告を配信出来るメディアである。さらに、そういった広告主に収益を上げる手段すら提供してしまった。AdSenseで得る収入 (あるいは情報商材の売上げ) (←nofollow付きリンク) がAdWordsで出て行くお金を上回れば利益が上がるのだから。広告もGoogle、収入もGoogleである。

さらに...AdSenseで稼ぐために自動生成される記事のネタはGoogleアラートで集めるのだそうだ。スパムコンテンツのネタまでGoogleか!

そもそも検索エンジンにおける通説? のうち、

  • 独自のコンテンツを持ちましょう→ 独自のコンテンツなしに大きくなったのがGoogle
  • リンクを買うのはやめましょう → クリック課金という形でリンクを売っているのがGoogle

なのだ。

さらに穿った見方をすれば「スパムサイトが増えることで検索結果の質が落ちる」ことをGoogleが狙ってやっているようにも見える。スパム排除の技術や技術開発コストを持たない検索エンジンは使い物にならなくなるだろうから、そこでGoogleである。

GMailで味をしめたのだろうか(GMailのスパムフィルタは良く出来ているらしいし)。スパムが多い程ユーザーを囲い込めるのがGoogleなのだ。

つまり、Googleにとっては「スパム」こそが他社を排除し、競争力をさらに高める。 ご丁寧にスパマーに収益まで上げさせてそれをやってしまうところが、まぁ何だ。

ということで、スパムサイトの増加はGoogleの自作自演なのだろうか?


本当に言いたいのは、

もうちょっとまともに広告審査したらどうかということだが。

前回 (数日前) <$MTEntryTrackbackData$>も削除したしトラックバックとコメントCGIのリネームもしたわけで、今のところ殆どトラックバックスパムもコメントスパムも来ないわけだが...この間一通来やがった。

スパム防止プラグインの優秀さは認めるけれども実際のところCGIを叩かれること自体が嫌なわけだ。何故なら「言及の有無」を調べるためにCGI起動してトラックバック元へHTTP_GETしてソース調べて...って何でこっちがそこまでせなアカンのや? っていうか負荷かかりまくりである。

またトラックバック飛ばして「HTTP error: 403 Throttled」とか帰って来たら悲しいでしょ? 実際僕がトラックバック打ってもそうなっちゃうケース増えてるし。

ということで先日来トラックバックスパム系のプラグインを外すどころか各種設定も甘く甘くした。

mt-config.cgi


ThrottleSeconds 0
OneDayMaxPings 100
OneHourMaxPings 100

つまり...

CGI叩かれたら負けかなと思っている!

いくら<$MTEntryTrackbackData$>削除してもCGIもリネームしても、MTであることを決め打ちであるなら、機械的にCGIのURL探してしてトラックバックスパム飛ばすことくらい簡単である (少々プログラミングに覚えのある人ならすぐに思い浮かぶだろう)。

諸君! ここはひとつスパマーの気持ちになって考えてみようではないか。

  1. エントリーの中のURLを抽出して、さらに.cgi(.fcgi)+数字で終わっているアドレスを集める
    (http://example.com/.{1,}\.(cgi|fcgi)\/[0-9]{1,}みたいな感じ)
  2. 末尾の数字の部分を削除して各エントリーに共通のアドレスがあればトラックバックURLじゃねぇか? と判断する
  3. あるいはとにかく.cgi/数字のアドレスにGETリクエスト送ってそれっぽいレスポンスが帰って来たらトラックバックCGIだ! と判断できる

1 トラックバックの送信は、HTTP POSTメソッドを使う必要があります。

日本語版MT3.xならこんなレスポンス返ってくるから、それ確かめてからトラックバックスパム送りつければいいわけだ。簡単簡単!...

では対策。スパマーの心理(違!?)を読めば百戦して殆うからず!

トラックバックアドレスっぽくないURLを作る。GETアクセスを制限する。

まず、.cgi(.fcgi)以外の拡張子にしてしまおう。今回は.mtにしてみた(単純?)。さらにGETアクセスを弾く。

mt-config.cgi


TrackbackScript xxxxxxxxxx.mt
CommentScript xxxxxxxxxx.mt

.htaccess


AddType application/x-httpd-cgi .mt
<Files ~ "¥.mt$">
<Limit GET>
Order Deny,Allow
Deny from All
</limit>
</Files>

少し考えれば気づくと思うが、MTのTrackbackScriptの場合トラックバックIDの後にスラッシュ付けて後に適当なファイル名っぽい文字列くっ付けてもちゃんと機能するんだな。


<$MTEntryTrackbackLink$>/<$MTEntryBasename$>.html

出来たアドレスはこんな感じ。


http://junnama.alfasado.net/mt/xxxxxxxxxx.mt/1918/path2alias.html

ね、何だかただの静的ページに見えるでしょ? (見えない? mod_rerwiteを使う手もあるけどね)

コメント投稿ボタンをJavaScriptで挿入。

コメントについては前回「送信」ボタンをJavaScriptで挿入するようにした。


document.write('<input type="submit" accesskey="s" name="post" id="comment-post" value="&nbsp;&nbsp;送信する&nbsp;&nbsp;" />');

<script type="text/javascript" src="../../entry.jp"></script>

この部分はアクセシビリティというかJavaScript前提ってのが気になっていたわけだが、JavaScriptオフでも「確認」ボタン経由であればちゃんとコメント投稿はできるから矛盾は出ないだろう。もちろん機械的に「post」で投稿すれば投稿は出来てしまうが単にフォームをsubmitすれば良いわけではないからね。

これも前回行った対策だが、古いエントリーのトラックバックアドレス表示とコメントフォーム非表示、古いエントリーの再構築制限をかけたので、『比較的新しいエントリーで「トラックバックURL」「コメントフォーム」の判別が出来た』という条件を満たした場合のみスパムが飛んで来ることになる。

引き続き課題。

あとは...HTMLか。デフォルトのテンプレートにはClass名やIDにそれっぽい名前が振ってあるからソースを解析してアドレス抽出しやすいだろう。だからCSSと一緒にClass名等を推測しにくいものに変えてやれ…ってのはちと面倒なので次回とする。

もう徹底的にスパムと戦うというか...来るなら来やがれ!

関連エントリー


その後の追記

その後ですが、やはり来ないですね。いまのところ。

Trackback Auto Discoveryの無効化は確かに有効。ただ結局のところ、スパムフィルターがどれだけ有効であろうとCGIが起動してフィルターが動作している限りサーバーの負荷は軽減されないわけです。そこがあんまり分かっていない人が多いような気がする。

↑事実正常なトラックバックが重くて受け付けられなかったら意味ないしね。現にHTTP error: 500 read timeout となって受け付けられないし。

ということで、5つのポイントとしてまとめます。内容はこのページの内容の殆どどのままですけど。

これまでブログのエントリーに書いては都度アップしていたのですが、探しにくいとか最新版がどこにあるかわかりにくい、あるいは古いエントリーにリンクされたりブックマークされたりしていたので (ブログのエントリーってのはやはりこういう用途には向かない、というか僕の計画性が無いだけですが...) 新たに「Movable Type プラグイン」カテゴリを作成し、各プラグインの (本当の意味での) Permalinkを設定し改めて公開します。

Movable Type4への対応状況等も追記しています。

このアーカイブの作成用に新たに書き下ろした2本を加えて公開時点で16本。今後も逐次アップしていきます。

今後はこのカテゴリからリンクしている Permalink が各プラグインの固有のURLとします。修正はこれらのページに対して行っていく予定です。

利用方法

エイリアスに置換したいタグ「<$MTEntryPermalink$>」「<$MTArchiveLink$>」等に タグ属性「Path2Alias="1"」として指定します。

<$MTEntryPermalink Path2Alias="1"$>

プラグイン設定画面でエイリアスを5つまで指定できます。URLはhttpから入力してください。

Path2linkの設定画面

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

ダウンロード

利用方法

「<$MTSpecificField id="エントリーのID" field="フィールド名"$>」のように指定します。

エントリーIDが「1」のエントリーの「title」を出力する場合は以下のように指定します。

<$MTSpecificField id="1" field="title"$>

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

ダウンロード

Background Rebuilder

| コメント(0) | トラックバック(0)

利用方法

設置・調整

MTフォルダ以下にBackgroundRebuildフォルダごとアップロードします。

  • /plugins/BackgroundRebuild/BackgroundRebuild.cgi の1行目「#!/usr/bin/perl -w」を環境に応じて修正。
  • /plugins/BackgroundRebuild/BackgroundRebuild.cgi には実行権限 (755等) が必要です。
  • /plugins/BackgroundRebuild/tmp/ ディレクトリはCGIプログラムから書き込み可能 (666, 777等) である必要があります。

「メイン・メニュー > プラグイン > Background Rebuilder > 設定を表示」以下の設定が行えます。

  • 再構築の実行結果を取得する (このチェックを入れない場合、再構築の実行結果を表示しません)。
  • E-mailによる通知 (再構築の完了結果をE-Mailで受け取る場合にチェックします)。
  • E-mailアドレス (再構築の完了結果を受け取るE-Mailアドレスを指定します)。
  • 実行結果の取得開始(ミリ秒) (再構築の実行結果を取得するプログラムをページ表示後何秒で開始するかを数字で指定します)。デフォルト値は3000 (3秒)。
  • 実行結果の取得間隔 (ミリ秒) (再構築の実行結果を取得するプログラムを何ミリ秒単位で実行するかを数字で設定します)。デフォルト値は1000 (1秒)。
    この場合、1秒おきに /plugins/BackgroundRebuild/BackgroundRebuild.cgi へアクセスし、実行結果の取得を試みます。
  • 実行結果の取得回数 (再構築の実行結果を取得するプログラムの実行回数を指定します。 デフォルト値は180回。実行結果の取得間隔が「3000」で実行結果の取得間隔が「1000」の場合、ページ表示後3秒後から1秒おきにMax3分まで再構築実行結果の取得を試みます。実行結果を正常に取得できた場合は処理を終了します) 。
  • すべてを再構築時の実行待ち秒 (「すべてのブログを再構築」ボタンをクリックした時、プログラムはブログ単位で順番に再構築プロセスを走らせますが、次のブログの再構築プロセスを走らせる前に待ち時間(秒)を設定できます)。デフォルト値は0秒です。
  • バックグラウンド再構築が有効になるケース

    • 「再構築」ウィンドウから「バックグラウンド再構築」または「すべてのブログを再構築」実行した時。
    • エントリー編集画面でエントリーを保存した時 (ステータスが「公開」の場合)。
    • エントリー一覧画面で複数エントリーを処理した時 (ステータスの変更や選択項目の再構築等)。

    再構築画面に新たに追加されたボタン

対応バージョン

Movable Type3.3

ライセンス

クリエイティブ・コモンズ・ライセンス (表示-非営利-継承 2.5)

関連エントリー

ダウンロード

StylePreview

| コメント(0) | トラックバック(0)

利用方法

プラグインを設置するだけで有効になります。エントリー編集画面で「確認」ボタンをクリックするとテンプレートやCSSが効いた状態でプレビューでき、ページの下部に各コントロールが表示されます。

プレビュー画面下部のコントロール

対応バージョン

Movable Type3.x, Movable Type4.0 β版と仕様が変わっているためMT4では正常に動作しません。

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

QuickEdit

| コメント(0) | トラックバック(0)

利用方法

  • 「Quickedit.pl」をプラグインフォルダへアップロードします。
  •  同梱されている「Bookmarklet.html」の以下の部分を環境にあわせて変更します。
  • 「Bookmarklet.html」をブラウザで開いてブックマークレットとして登録します
  • ※ http://example.com/mt/mt.cgi の部分を環境にあわせて書き換え。


<a href="javascript:window.document.location.href='http://example.com/mt/mt.cgi?quickedit=1&permalink='+document.location.href;">=&gt;Quick Edit</a>

ブックマークレット

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

RebuildAt1stView(Beta)

| コメント(0) | トラックバック(0)

利用方法

テンプレートの設定(ブログ毎)

「設定」→「公開」→「ページ構築方法」で「テンプレート別にスタティックHTMLもしくはダイナミック・パブリッシングを選択します」にチェックを入れて変更を保存します。

設定→公開→ページ構築方法

エントリー・アーカイブ編集画面→「再構築オプション」で「このテンプレートをダイナミック・ページにする」にチェックを入れて変更を保存します。

エントリーアーカイブ編集→再構築オプション

ブログ全体を再構築します。

*これまでに生成された静的ファイルはファイルの末尾に.staticが追加されてバックアップされます。これらのファイルは不要ですので動作確認後削除して構いません。

プラグインのアップロード

pluginsフォルダ内のRebuildAt1stViewディレクトリをMTのpluginsディレクトリ直下に(ディレクトリごと)アップします。

データベースのアップデート

プラグインをアップロードして最初にログインしようとするとアップグレード画面が表示されます。そのままID/Passwordを入れてアップグレードを完了してください。

アップグレード画面

設定完了画面

システム全体のプラグイン設定

システム全体のプラグイン設定画面で「サイトのベース」(http://〜最初のスラッシュの手前まで)、「ドキュメントルート」(両方とも最後にスラッシュを含まないことに注意)、エラーテンプレート(404ページのテンプレートのサイトルートからの絶対パス)を入力して変更を保存します。

システム全体のプラグイン設定

ブログ単位のプラグイン設定

設定を有効にしたいブログのプラグイン設定画面で「プラグインを有効にする」にチェックを入れます(デフォルトは「オン」です)。

プラグイン設定画面→プラグインを有効にする

テーブル (mt_permalink) へのデータの登録

ここまでの設定が完了したら、プラグイン設定画面のプラグイン名「RebuildAt1stView」をクリックします(インストール時に作成した mt_permalink テーブルにデータを登録されます)。

プラグイン設定画面→テーブルの更新
テーブルmt_permalinkのアップデート結果

ブログの設定(アーカイブマッピング等)を変更した時や動作が不安定な時は、この操作を再度行ってmt_permalinkテーブルを最新の状態にアップデートしてみてください。

.htaccessの編集

ブログのルートフォルダに「.htaccess」ファイルが生成されていますので(「設定」→「公開」→「ページ構築方法」の設定を行った際に生成されている筈です)これを削除, 同梱の「_htaccess」をアップロード。「.htaccess」にリネームします。


ErrorDocument 404 /mt/plugins/RebuildAt1stView/mtview.cgi

ErrorDocumentのパスをアップロードしたmtview.cgiのパスにあわせてください。FastCGI上で動かす場合は、mtview.cgiをmtview.fcgi とし、cgiのファイル名も同様に修正します。

動作の検証

新規にエントリーを作成するか、既存のエントリーで動作を検証します。

本来エントリーアーカイブが保存されている場所をFTPクライアント等で確認し, ファイルが存在しないことを確認します。その後Webブラウザでページを表示, 再度FTPクライアント等で確認、ファイルが生成されていれば正常に動作していることになります。

ファイル生成のテスト

生成されたファイルの全消去

この方式の場合、(エントリーを追加したりテンプレートを変更し, すべてのページを更新する場合)エントリーアーカイブを再構築する代わりに生成されたエントリーアーカイブの静的ページを全て消去する必要があります。

通常の再構築(すべてのページを再構築)した後に、各ブログのエントリー一覧ページの右下の「プラグインアクション」→「エントリーキャッシュの全削除」をクリックすることで生成された静的ファイルがクリーンアップされます(再度ページへのアクセスがあった時にページは再生成されます)。

エントリー一覧のプラグインアクション

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

BuildFileFilter4OldArchive

| コメント(0) | トラックバック(0)

利用方法

プラグイン設定画面

「いつ以前に作成もしくは更新されたエントリー/日付アーカイブを再構築対象から外すか」をタイムスタンプ(例:20070101000000)で指定します。再構築対象期間を短くすればする程短時間で再構築が済むようになります。

エントリーの created_on(作成日)とmodified_on(更新日)のどちらをキーにするかをラジオボタンで指定します。

フィルターを有効にする前に、古い日付のアーカイブを一旦再構築します (今後再構築されなくても差し支えないような内容のテンプレートにする必要があります。例えばフィルターを有効にした場合コメント投稿やトラックバック受信はページに反映されなくなります。

古いエントリーアーカイブからコメントフォームやトラックバッくURLを非表示にするためには条件タグ「<MTIfOlderArchive>」を使います。

<MTIfOlderArchive>
20070101000000以前に更新(作成)されたエントリーです。古いです。
<MTElse>
古くないです。
</MTElse>
</MTIfOlderArchive>

テンプレートの修正が終了して保存したら一旦全再構築をかけます。

再びプラグイン設定画面に移動して、「Filter Active.」にチェック→「変更を保存」して設定を完了してください。

以後、指定した日数以前に更新(作成)されたエントリーアーカイブは「再構築」が行われなくなります。

対応バージョン

Movable Type3.x (MT4未検証)

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

IfItemIsOdd

| コメント(0) | トラックバック(0)

利用方法


<li<MTIfItemIsOdd key="label"> class="odd"</MTIfItemIsOdd>>
    <a href="<$MTCategoryArchiveLink$>"><MTCategoryLabel></a>
</li>

出力結果の例

カテゴリーの1行ごとに色をつけた様子

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

RandomLink

| コメント(0) | トラックバック(0)

利用方法

テンプレートタグ「<$MTRandomLink$>」として指定します。リンク先の登録はブログ毎に管理画面の「プラグイン」から行います。

プラグイン設定画面

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

Unicode::Normalize

| コメント(0) | トラックバック(0)

利用方法

例えば<$MTEntryBody$>に適用する場合、以下のように指定します。


<$MTEntryBody normalize="NFD"$>

属性値に指定できるのは以下の4種類。デフォルトはNFKCです。

  • NFD(Normalization Form D)
  • NFC(Normalization Form C)
  • NFKD(Normalization Form KD)
  • NFKC(Normalization Form KC)

尚、<, >, &, “, ” の5文字はそれぞれ &lt;, &gt;, &amp;, &quot;, &quot; に置換します。

Perl5.8, 文字コードUTF-8環境でのみ検証済みです。

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

CleanUp

| コメント(0) | トラックバック(0)

利用方法

プラグラムをpluginsフォルダにアップ後 [メイン・メニュー→ブログを選択]、もしくは[エントリー一覧] 画面にリンクが表示されます。このリンクをクリックするとEntryPermalinkとステータスを調べてステータスが「未公開(下書き)」のファイル及び「指定日公開」のファイルをリストアップします。削除したくないファイルのチェックボックスを外し「Clean Up!」をクリックしてください。

プラグインアクションへのリンク表示

対応バージョン

Movable Type3.x

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

Jaccessibility

| コメント(1) | トラックバック(0)

利用方法

<$MTEntryBody jaccessibility="0"$> のように指定します。

フィルター処理の概要

  • 全角英数字は半角に変換されます
  • 半角カタカナは全角カタカナに変換されます
  • (株)(有)等の記号は括弧付き文字に変換されます
  • 1/2 等の記号も同様に変換されます
    (注:Ⅰ, Ⅱ, Ⅲ (ローマ数字)は「I」(アイ)等で表現される(I,II,IIIのように)
  • 円,ユーロ,ドル,ポンド,セントは日本語に変換されます
    (例:$10,000 → 10,000ドル)
  • 日付 (らしき) 文字列は日本語フォーマット化されます
    (例:2007.2.9 →2007年2月9日)
  • スペースで分割された日本語は詰められます
    (例:東   北 → 東北 , 北 海 道 → 北海道)
    (注:「2007年2月9日 新着情報...」等とすると「2007年2月9日新着情報...」のように詰められます
    「<span class="date">2007年2月9日</span> 新着情報」は詰められません)

属性値について

  • <$MTEntryBody jaccessibility="1"$>:正規化 (全角→半角や記号の置換等)
  • <$MTEntryBody jaccessibility="2"$>:日本語の分割を詰める
  • <$MTEntryBody jaccessibility="3"$>:通貨の変換
  • <$MTEntryBody jaccessibility="4"$>:日付の変換
  • <$MTEntryBody jaccessibility="0"$>:上記すべてを有効にする

明示的に複数の属性を指定する場合は、

  • <$MTEntryBody jaccessibility="1,2"$>

のようにカンマで区切ります。

画像のALT属性について

alt属性値の入力フィールド

アップロードインターフェイスに画像のALT属性入力フィールドを追加します。アップロードしたものが画像でない場合、入力したテキストは「リンクテキスト」になります。

対応バージョン

Movable Type3.x (MT4未検証)

ライセンス

クリエイティブ・コモンズ・ライセンス (表示-非営利-継承 2.1 日本 ライセンス)

関連エントリー

ダウンロード

LiteSearch

| コメント(1) | トラックバック(0)

利用方法

readme に従って各ファイルのパスを修正。下記の3ファイルを設置。mt-lite-search.cgi には実行権限を与えてください。

  • mt-lite-search.cgi -- CGI本体
  • config.pl -- 設定ファイル (mt-lite-search.cgi と同じ階層に設置)
  • extlib/MTLiteSearch.pm (検索プログラム mtフォルダ内の extlib 内に設置)

readme に従い検索ページ用のテンプレートを「mt-lite-search」という名前で作成し、保存します。

CGIに渡すパラメータについては以下の通りです。

  • start (表示開始位置)
  • limit (1ページあたりの表示件数)
  • blog_id (0を指定するとすべてのブログが対象となります)
  • search (検索する文字列, スペースで区切るとand検索となります)

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

クリエイティブ・コモンズ・ライセンス (表示-非営利-継承 2.1 日本 ライセンス)

関連エントリー

ダウンロード

TouchMe

| コメント(0) | トラックバック(0)

利用方法

プラグイン一覧のページに行くとAdminScript, CommentScript , TrackbackScript, SearchScriptを touch します。スクリプトに対して書き込み権限が必要です。

対応バージョン

Movable Type3.x, Movable Type4.0

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

CatIndexKiller

| コメント(1) | トラックバック(0)

利用方法

管理画面上の表示

  • 管理画面のカテゴリー編集画面にチェックボックスが追加されます。
  • チェックを入れたカテゴリーは再構築されません。
  • つまり、特定のカテゴリーのインデックスページだけエントリーで代用できるので、別途エントリーのbasenameを「index」等としてカテゴリーアーカイブの代用エントリーを作成できます。

また、条件タグによってbasenameが「index」の場合のみ分岐させることができます。

<MTEntryIfIndex>
# 出力ファイル名が「index」の場合のみ出力される
<MTElse>
# それ以外の場合出力される
</MTElse>
</MTEntryIfIndex>

尚、実装上の都合で「カテゴリーの説明(description)」にコメント(<!--DoNotRebuild-->)が入りますのでこのコメントを出力したくない時は

<$MTCategoryDescription CatIndexKiller="1"$>

としてください。

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

IfMatchEntry

| コメント(1) | トラックバック(0)

利用方法

<MTIfMatchEntry search="Movable Type" item="text">
	entry_text(MTEntryBody)に"Movable Type"を含む場合
<MTElse>
	entry_text(MTEntryBody)に"Movable Type"を含まない場合
</MTElse>
</MTIfMatchEntry>

属性値itemに指定できるのは title, text, text_more, excerpt, keywords, basename。 item="all" とするとこれらすべてを検索対象とします。

上述の例のようにコメントタグにマッチさせたい場合は「<」や「>」をエスケープしてください。また、正規表現で検索しているので、search="(Movable Type|MT)" とすると、"Movable Type" または "MT" にマッチするかどうかで分岐できます。

ライセンス

パブリック・ドメイン

関連エントリー

ダウンロード

台風一過。

| コメント(0) | トラックバック(0)

青空

祭りの風景

晴れてら。

1日遅れの祭りの準備も着々と。

先日の続きね。いや、このブログって色んな実験や技術のオンパレードやから時々仕事中にデモでお客さんに見せるんよ。だからあんまり続けると恥ずかしいやないか! とかいいながら調子に乗って...

いやね、キミたちの気持ちはよーく分かった。俺が一週間前に気合いを入れて書いて「注目のエントリー」入りもしてアクセスも伸びたMovable Typeをめっちゃ高速化する20の方法。とかよりも...結局は「萌え」がえーんやな。

こんなもんまで作ってくれちゃって...→

しかもコメントで「再構築中にも何か出して欲しい」とか書いただろ。

どーすんねん、ウチの社員が目覚めて「やりましょう! やらせてください! 社長!」とか言い出したら。

いやね、しかしおまいらの気持ちは痛い程分かった。

ということで、今回は再構築中に何か出す編である (前置き長っ!)。

しかし、今回は萌えは無し。

ちょ待て! 黙って立ち去るんじゃない。ひとの話聞け!

* 休日に「ブログが受けたからもう一発萌え萌えのキャラ書いてよ」とか社長から連絡来る会社で働く社員の気持ちになってみろ。少しは我慢というものを...(脱線長っ!)

再構築の進行状況をプログレスバーで表示する(MacOS X風)

今回はMT3.x用のみ。かなり横着な実装で「全てを再構築」且つ「type=Individual,Monthly,Category,index」の時だけ表示する (月別アーカイブを無くしてる とか、週別/日別アーカイブを作ってるとか、デフォルト状態からアーカイブの種類を増やしたり減らしたりしていると表示しない)。また、エントリーがめちゃめちゃ多い場合などプログレスバーが後退する時があるかもしれない。

前回と同じくプラグインでなく alt-tmpl と mt-static に放り込むタイプなのでJavaScriptに心得のある方は自由に改造してください。

再構築の進行中のプログレスバー

前回の「萌え」は確かに半分以上冗談だけど「ユーザーにストレスを感じさせないために進行状況をうまくフィードバックする」ってのは王道なわけです。デスクトップアプリケーションでもユーザーが「あれ、固まっちゃったかな?」とか感じるような重い処理を行うときは進行状況をプログレスバーでフィードバックすべきでしょう (例え「実際はそんなことしない方が速い」場合であっても)。

プログレスバーを表示させることで受ける印象がどう変わるかは是非確かめてみて欲しい。そして最後は「再構築お疲れさまでした♥」ということで癒されてください(笑)。

ダウンロード(MT3.x専用)

あとね、まぁ付け加えるならばMTのカスタマイズって別にプラグイン書かなくても前回や今回のように alt-tmpl と mt-static の組み合わせで結構簡単にできるんですね。

さぁ、みんなでMTマスターして当社へ転職しよう!

今回は特に制限は設けませんので改造等ご自由にどうぞ。

はてなスターで某方面が盛り上がっているようだが、似たようなことは"はてな"でも過去にあったようだし"Mixi"でも3カラムレイアウトの時にあったし"ドリコム"では広告位置の件であったよね。全ては僕のようなおっさんにとっては記憶に新しいところなのだがドッグイヤー(ってのも死語なのか?)というかWeb2.0の世界に生きる若い人たちにとってはもう昔の話なんだろうか。

* もちろん今回のはてなスターの件とMixiの件とドリコムの件はすべて意味やバックボーンが違うことは理解した上での話ね

まぁ、このくらいの反応は織り込み済みかとは思うが、やり方がまずいとユーザーが離れてしまうという当たり前の結末が待っているわけだし、他にもっと上手いやり方があるのではないかな。

以前にも書いたことがあるが、ユーザーコミュニティの上に成り立っているサービスに新しいサービスを追加導入する時には色々と考えないといけないことがある。特にブログやSNS系のサービスにおいては、しくみは確かに運営者が構築したものであるがその「画面」内の世界は各ユーザーの「我が家」のようなものであり、そこへ異質なものを強制的に放り込まれたら反発が来るのは目に見えている。それがどんなに素晴らしいものであっても(運営者の都合の場合はなおさら)。

簡単に言うと、自分が借りている賃貸マンションの部屋の中が帰って来たら変わっていたようなものだ。確かに不動産は家主のものだし、仮にそういう契約もしているとして、

  • ひと言ぐらい言ってよね
  • できれば事前に相談して欲しいな
  • 他の住民の方は何て言ってるの
  • これって絶対元に戻せないの

とか。ポイントは事前の告知と選択の自由をユーザーに選ばせることのできるオプションにあると思うわけだが、あのYahoo! Japanだって新画面のテストとアンケートを結構長い間行っている。

Mixiの件でもドリコムの件でも振り返って色んなブログ等を読むと「オプションとして元に戻せるようにすべき」「事前にユーザーの声を聞くべき」といった声が多いように思う。「そもそもユーザーコミュニティを大切にしているのか」とか「口コミ」をもっと上手く活用すればいいのに、とかいう意見もある。

基本はこれらの意見の通りなのだが、特に「ユーザーの声を聞く」件についてはサービス提供者の側はこう思っているのかもしれない (思っていないかもしれない)。

"ユーザーにお伺い立てながらやっていてはいつまでたってもサービスの投入なんてできないし、色んな意見があるのは当然だしユーザーの意見がまとまるなんてこともあり得ない。とにかく企画したら素早く実装してリリースすることこそが大切。"

まったくもってその通り、な部分もあるわけだが実はユーザーの声を聞くことにはもう一つの意味があってそれは「ユーザーに自分たちが作ったと思わせること」なのだ。この言い方が偉そーなら「ユーザーと一緒に作った」という表現でも良い。事実ユーザーがサービスを使う中で生じた様々な「文化」が新サービスの背景にあるという部分もあるだろうし (特に"はてな"の場合)。

*この件は以前書いたが、受託におけるクライアントと受託者の関係にも似たところがある。

"あぁ、このサービスについて実はjkondoから意見求められちゃってさ、エッヘん、次のベータでは俺の言う通りに変更なっててさ、ほらこのページに「すぺしゃるさんくす」ってところに俺のidあるだろ? エッヘん"

とかいうのは極端だけど、やり方は色々あるし、そのためのメディア (コミュニティ内でこそ強力なメディア) も持っているわけだ。

だから、次のリリース時には「リリース後のポジティブな反応をこれだけ獲得し、退会者を1人でも上回る新規ユーザーをこれこれの期間で獲得できること」という具体的なゴールを設定してそのための戦略を練ってみてはいかが?

具体的な数値は実は実現出来なくても構わないのだが、仮説を立てることで深く考えるようになるしプランの検証もできるようになる。「この施策でほんとうにこの数字になるか?」を何度も繰り返すこと。そしてもう一つ、どんな結果になろうとも想定し得る次の打ち手を予めできるだけシミュレーションしておくこと。そしてリリース後に変化することを厭わないこと。

もちろん、そんなことは既にやっているよね。次の打ち手は何ですか?

関連するかもしれないこのブログ内の他のエントリー

(7月18日 19時45分 追記しました)


大分前のことだけど、ウェブアクセシビリティに関わる仕事をしていて障碍者の人にもヒアリングをしたいということでウェブアクセシビリティ系のMLとかでゆるやかな面識のあった方にコーディネイトをお願いしてユーザーテストというかヒアリングをお願いした時に「あなたは障碍者を食い物にしているんじゃないか!?」という「きつい」お言葉をいただいたことがある。

正直その時は凹んだ。そんな気持ちはさらさらなかったけれども。でもどう受け取るかは相手次第だし、その言葉があったから今の僕がある、というのは事実。

言いたいのは表題の通りのことで、ビジネスにだって理念もあれば拘りがあって当然。例えば僕が「現場の仕事に対してはキツイくせに社長は自分の趣味でイベントに熱心だからね」とスタッフに言われるようなこと (且つ全然利益が出ないこと) はできないわけです。

*もちろん利益は短期的なものだけでもないし有形無形の利益ってのが存在することも忘れてはならない。

だから気にしなくても良いし、良いイベントができて利益が上がれば尚良い。

ただ、Web標準とかウェブアクセシビリティとか、テーマがそれであることで誤解を受けることはあると思う。それだけは意識しておくべきだと思うな。

(追記)
むしろ別のことろでツッコみたいわけですが、東京だけで回してても先は見えてますぜ。「文化は西から」ですよ(昔IBMの方に「アクセシビリティチェッカー」のMac版を公開してもいいですか? と質問した時に返信いただいたメールより)。


(7月18日 19時45分追記)
僕的には書いてからかなり経過している気分なんだけどそれなりに見られているようだしちょっと補足。

3年くらい前から時々大阪で「ウェブアクセシビリティ研究会 (手弁当イベント)」をやっていたのだが、その会のMLには視覚障碍者の方がいらっしゃって研究会にいつも来られるんですね。で、一通り講演や質疑応答が終わった後に挙手されて「ガツン!」と言われるわけです。

「お前ら(←もちろん「お前ら」とは言いませんが) そんな理屈言うてるけど、こういうことがあるわけ。分かってますか!?」「ひとこと言っておきたい!」

和やか? な小さな会場が緊張に包まれる一瞬なのだが、ほぼ毎回の出来事なんだ。で、その方が聞いていらっしゃるのが視界に入るから、話す時も「下手なこと言えへん」良い意味の緊張感が生まれるようになった。

「Web標準」がテーマだし「ウェブアクセシビリティ」の話に限らないけど、冒頭の「障碍者を食い物にしているんじゃないか!?」という指摘も含めて「ウェブアクセシビリティ」ってひと言発する時の重みというか、そういった「重み」の部分と「Web業界のフジロック」というフレーズが何らかの違和感になったことが関係していなくもないかな、と僕は勝手に想像している。

僕自身、出演者側の方の何人かとは面識もあるし、精力的に活動されていることを尊敬し羨ましく思うのが正直な気持ちだが、テーマ的なことを考えると襟を正して事にのぞまないといけないところはある。

別に誰が何と言ったって信念は曲げなくても良いけれど、ロックフェスティバルに例えるにはシリアスなテーマだったのかもしれない。

いずれにしても『今一度「原点」に戻ろうよ』ってのはブロゴスフィアの誰かの発言のせいではなくて、制作者が作ったサイトにアクセスする様々なユーザー (障碍や年齢や状況に関わらず) の問いかけなのかもしれないよ。

CGIリネーム・<$MTEntryTrackbackData$>の削除・古いエントリーのコメントフォーム, トラックバックURLの削除

エントリー「ブログの軽量化・高速化等。」のところで書き忘れたが、今回スパム対策でcgiのリネームも行った(これで2回目)。
あと<$MTEntryTrackbackData$>も削除した。「トラックバックの自動検知」は無効になるが、元々まともなトラックバックよりスパムの方が圧倒的に多いし、トラックバックURLをちゃんと入力すれば受付られるわけだから。

あと、せっかく<MTIfOlderArchive>というタグをつくったので、古いアーカイブについてはトラックバックURLとコメントフォームを無くした。

<MTIfOlderArchive>
<MTElse>
<!--コメントフォームやトラックバックURLをここに-->
</MTElse>
</MTIfOlderArchive>

古いエントリーにはコメントもトラックバックも実際来ないし。

ブログの設定で受け付けなくしたわけではないので、ポストすればちゃんと受け付けるのだがページにトラックバックURLもコメントフォームも無い状態で果たしてコメントスパムやトラックバックスパムは飛んでくるだろうか?

「トラックバック」というキーワードに反応?

以下ちょっと仮説というか何というか。実はこのブログに対するトラックバックスパムが一番多いのが以下のエントリーなのだ。

4月のエントリーなのだが、その前後のエントリーへのトラックバックが多いわけではないし、このエントリーが話題になったりホットエントリーになったわけでもない。何かこのエントリーにヒントがあるのだろうか。「Trackback」,「トラックバック」というワードに何か関係が?

以前にCGIのリネームを行った時に、ついでに「このエントリーのトラックバックURL:」のところを「このエントリーのTBPingURL:」というテキストに入れ替えてみたのだが、これで逆に「トラックバック」という文字列を多く含むエントリーへのトラックバックスパムが突出する結果を招いたのかどうかは...わからない。ただ、何か話題が「トラックバック」だけに何か不思議な気がする。

メジャーどころからリンクされるとスパムは増える

あと、メジャーなブログからリンクされると明らかにスパムは増えるね。これは確か(あたり前か)。

最近では、このエントリーの後でMovable Type Background Rebuilder Plugin.のページ(2006年12月)へのスパムが一気に増えた。

*紹介されるのは嫌どころか嬉しいので別に紹介されたことがどうとか全然思っていませんので!

関連エントリー

(追記)コメントの投稿ボタンをJavaScriptで挿入するようにした。一応JavaScriptオフでも「確認」→「投稿」は可能。効果のほどは後日。

先日、打合せの帰りの道中で冗談まじりにこんな会話をしていたのですが。

再構築がストレスやったら「ストレスを和らげるキャラ」とか作ったらえーんちゃうん!?

ウチの会社の東京オフィスのウェブデザイナーでありイラストレーターのSさんが本当にイラスト書いてくれたので(マジかよ!?)、alt-tmpl 用のテンプレートとCSSを同じく東京オフィスの "スーパーCSSハッカー!" F君にサクっと書いてもらって (ネーミングも彼ね) 僕がちょっと添削して出来た一品。

一応ちゃんと「MTカスタマイズの理解を深める」っつーことで決して「ネタに必死な制作会社ではないのでお断りしておきます!

再構築が完了すると...

「もえ」バブルタイプの再構築完了画面

MT3/4両方対応版あります(笑)。

MT3.x

  • alt-tmpl/以下にrebuilt.tmpl
  • mt-static/plugins/以下にMoevableTypeフォルダ

MT4.0

  • alt-tmpl/以下にpopupフォルダ
  • mt-static/plugins/以下にMoevableTypeフォルダ

ライセンス

営利目的に使う人いないと思うけど...「クリエイティブ・コモンズ 表示-継承 2.1」ということで(営利目的もオッケーね)。

Creative Commons License

この作品は、 クリエイティブ・コモンズ・ライセンスの下でライセンスされています。

ダウンロード

最終電車はN700系。

| コメント(0) | トラックバック(0)

フロントフェイス

グリーン車の車内

ひじ掛けにコンセント

喫煙ルームの灰皿

21時20分東京発。ダイヤ改正で2分遅くなった。
わざわざ先頭まで行って写真撮るおっさん多数(俺のことね)。

エクスプレスカードのポイント使ってグリーン車に。

喫煙車がなくなって、喫煙ルームに。これが狭い。

テーブルは広い。コンセントはちょっと分かりにくかったがひじ掛けのところに。

仕事するには申し分ないが、今日は仕事しません。

では、「ほんのり屋」のおにぎりをたべながらビールをプシッとね。お先に!?

「20の方法」をしてとりまとめてそれなりに反響もあったから、実際に書いたけどやってなかったところ等を自分のブログに適用しておこうということで昨日と今日でやったことのメモ。

古い日付のアーカイブの再構築をしないように

昨日作った「BuildFileFilter4OldArchiveプラグイン」を導入して (BackgroundRebuilderもあわせて有効にして) 古いアーカイブ (エントリー及び月別アーカイブ) の再構築処理をしないようにした(今年の5月以前のエントリー及び月別アーカイブは再構築しないように)。

これに伴い古いアーカイブの右カラムをJavaScriptモジュール化。再構築しなくてもJavaScriptが有効であれば最新情報が表示されるように手を入れた。

詳細は以下のエントリー参照。<MTIfOlderArchive>タグを使って古いエントリーはJavaScriptモジュール化したファイルを読み込むようにして一旦全再構築。その後フィルターを適用。これで再構築時間が35秒→15秒へ短縮。

カテゴリーアーカイブの軽量化

エントリーが増えてページが長くなりすぎたので10件分は従来通りの表示、それより古いものはタイトルと最小限の情報のみ表示とした。

これは「20の方法」には書いていなかったものだけど、MTデフォルトのカテゴリーアーカイブはエントリーが増えると際限なく長くなってしまうので、エントリーが溜まってきたらこういった方法やページ分割を検討した方が良いだろう。


<MTEntries sort_by="created_on" sort_order="descend" lastn="5" offset="0">
<!--ここは全文表示-->
</MTEntries>

<p>以下タイトルのみを表示します。</p>

<MTEntries sort_by="created_on" sort_order="descend" lastn="1000" offset="5">
<!--ここは日付・タイトル・TB数・コメント数のみ表示-->
</MTEntries>

各アーカイブのフッタ部への最低限のナビゲーション追加

これは高速化・軽量化とは関係ないが、各アーカイブのフッタ部にトップページとアーカイブぺージへのリンクを追加。

ブログってページが長くて、ページの最下部まで見た時に次のアクションがないのが (自分が) 嫌なので付けた。

ちょっとした改良だけど、自分で見ている分にもかなり軽い感じになった。もちろん再構築も素早く終わる。快適!

赤坂「かおたん」。

| コメント(0) | トラックバック(0)

かおたんの塩ラーメン。

担々麺が美味いが、今日は塩。
ピンぼけしてるな。スーパーウルトラ手ぶれ補正付きやのに〜。

Movable Typeな夏。

| コメント(0) | トラックバック(0)

WebSig会議は既にキャンセル待ち状態、ProNetミーティングは会員企業専用ですが。

「Movable Typeな夏」ですね。僕は今のところ全てに参加する予定です。宜しければ飲みに行きましょう(違?)。

Six Apart - Tech Talk Blog: Movable Type 4 Hack-a-thon のお知らせ

既報のとおり、8月24日にあのBrad Choateが来日します。8月25日は土曜日です。土曜日といえば、ハッカーが集ってハックする日と昔から決まっています。Movable Type界最強のハッカーが東京にいるのに、東京でハッカソンをしないわけにはいきません。

Six Apart - Six Apart: Movable Type 開発者向けカンファレンスのお知らせ【参加無料】

Movable Type 4 の公開にあわせて、Movable Type をご利用いただいている開発者様を対象に、カンファレンスを開催いたします。

生まれ変わったMovable Type、その新たな可能性について、開発者自身からご説明させいただきます。本カンファレンスのために、Movable Type の開発責任者である、Brad Choateがサンフランシスコより来日します。基調講演においてMT4の魅力をお伝えするだけでなく、Movable Typeを最も深く知るエンジニアとして、MT4の設計思想や、プラグイン開発のベストプラクティスなど、日本の開発者様にご満足いただけるようなプレゼンテーションを予定しています。

【第14回】WebSig会議受付開始 「Movable Type 4のポテンシャルを探る~GPLライセンス版登場でMTはどう変貌するか?」 (WebSig24/7)

第14回WebSig会議は7月18日に正式リリースされる、Movab Type 4および、近々リリースされるであろう、Movable Type GPLライセンス版をテーマに取り扱います。

MT4ベータ版から取り組まれ、またプラグイン作者として著名な4名をお招きし、今までのMovable Typeとは、どのように変わったのかはもちろん、MT4でサイト構築する上でのTIPS等もお伝えできればと考えています。

久しぶりに見慣れた日本の銀行のサイトをターゲットにしたフィッシングメールを受け取った。
まぁ英語だし日本のユーザーは騙されやしないだろうが一応おさらい。ユーザーとして、だけじゃなくサービスを企画する側の立場としても気をつけることもあわせて。

* とはいってもやはりメールやフォームから問い合わせが出来ないのは不便だ。せっかくの情報を通知するにも方法がない (電話して番号押して...ってどこまで必要か? やっぱりフォーム位必要だ)

新生銀行を偽ったフィッシングメール(クリックで拡大)

*拡大画像に番号を振っています。

  1. Fromは簡単に偽装できるので (S/MIME等の安全な方法の(且つメールソフトが警告を出さない)メールでない場合は) 信用しない。
  2. Replay-To:が別ドメインになっている。疑わしさ満点。
    サービスを企画・提供する時も同じことをしないようにね。
  3. リンク先は正しいドメインを指しているように見えるが実際のリンク先は別の場所になっている。そもそもHTMLメールなのでリンク先として表示されているアドレスはあてにできない。マウスポインタを持っていくとこんな感じで表示されるので間違ってもこんなアドレス踏まないように。
  4. 別に©2007になっていたら安心出来るわけではないが何で2001なんだろう...って実際のサイトもそうなっているんだね。

* ところで何で新生銀行のサイトのドメインは www.shinseibank.com なんだろう? 「co.jp」ドメインを使うこと、そして「しつこいくらいに」ドメインを周知することこそ重要なのに。

フィッシングサイトの画面(クリックで拡大)

  1. で実際にページを表示すると (良い子はページに行ったりしちゃ駄目) このような画面となり、アドレスバーを見ると別のサーバーへ誘導されていることがわかる。そもそもHTTPSじゃない時点でアウト。間違っても情報を入力したりしないこと。

ページはきちんとデザインされているがそんなことに騙されてはならない。本物をコピーペーストすれば「まんま」のページがすぐにできるのだから。

で、注意喚起等の情報がないかどうかサイトに行って確認する。7月12日13時の時点ではインフォメーションが無い(英語版サイトにもない)。11日時点でウェブ上では報告が上がっているから、このあたりの対応は迅速に行う必要があるかと (元々が掲載情報に多くのチェックが必要で時間のかかる業種こそ体制と事前の手順化がなされていないと素早い対応は無理だ)。

*今見ると注意喚起が掲載されている。しかもアドレスバーの無いポップアップウィンドウだ!

ところで「フィッシング詐欺」への注意喚起は今やどこのウェブサイトでも行っているが、注意喚起のページの中でアドレスバーなしのポップアップウィンドウを使っているところがあって"これはイタイ"。

フィッシングに関する注意喚起画面(アドレスバーが無い)(クリックで拡大)

インターネットバンキングだけじゃなく、ウェブサイト内で一貫して「安心出来るユーザー体験」を提供することを考えなければ啓発しても意味がなくなる。*

*口座開設でもあるなぁ。このパターン(アドレスバーなしポップアップ)。せっかくhttps〜なのに意味がない。

制作者は気をつけられたし。制作者がちゃんとしないとこんなわけのわからないことを書かれてこっちまで不快になるのでね。

この件に言及している他サイトのエントリー

まだやるか!(笑)

前回の問題の答え

「何日以前」に更新されたエントリーは再構築しないという方法だと、例えば前回再構築した時から次の再構築の間の日から「何日以前」に更新されたエントリーが場合によってはおかしなことになってしまうわけですね(わかりにくい表現ですけど、まぁとにかくそういう問題があったわけで)。

なので、「20070101000000」のようにタイムスタンプで指定して、「その日以前に更新(作成)されたエントリーアーカイブを再構築しない」仕様にするとともに、日付アーカイブに対応させた。つまり月別アーカイブとかも古いものは再構築しないように指定できる。

実際にこのブログも前のエントリーで書いたJavaScriptモジュール化と組み合わせて以下のように変更してみた。

  • 2007年6月以前のエントリーアーカイブ、2007年6月以前のマンスリーアーカイブの再構築をしない。
  • 再構築をしない古いアーカイブはJavaScriptモジュールで新しいページと同様の「サイドバー(右カラム)」を表示。
  • JavaScriptがオフの環境のために、MTのデフォルトテンプレートに近い「前後のアーカイブへのリンク」と「全体のアーカイブページへのリンク」からなる「代替サイドバー」をnoscript要素内に配置。

*これで全再構築(実際は全再構築じゃないけど)の所要時間が35秒前後から15秒前後へ短縮された。

例えば古いエントリーはこちら。

古いエントリーの右カラム
古いアーカイブの右カラム
JavaScriptオフの場合

新しいエントリーの右カラム
新しいエントリーの右カラム又は古いアーカイブでJavaScriptがオンの場合

ダウンロード

*効果を実感するためにBackground Rebuilderと一緒に使って欲しい。

ライセンス

パブリックドメイン。自分の作成するプラグインのライセンスについてはちょっと考えるところがあって、MTOSについての何らかのアナウンスがあった際に再度定義し直そうかと考えている。
あと、ライセンスの件とは関係ないが、V4では動作確認していないので。

利用の手順

プラグイン設定画面

何日以前に作成もしくは更新されたエントリー/日付アーカイブを再構築対象から外すかをタイムスタンプ(例:20070101000000)で指定。再構築対象期間を短くすればする程短時間で再構築が済む。

エントリーの場合 created_on(作成日)とmodified_on(更新日)のどちらをキーにするかをラジオボタンで指定する(まだこの段階では上のチェックボックスはオフのまま)。

条件タグを一つ用意したので、エントリーアーカイブのテンプレートに手を入れる。

<MTIfOlderArchive>
20070101000000以前に更新(作成)されたエントリーです。古いです。
<MTElse>
古くないです。
</MTElse>
</MTIfOlderArchive>

テンプレートの修正が終了して保存したら一旦全再構築をかける。

再びプラグイン設定画面に移動して、「Filter Active.」にチェック→「変更を保存」。以上で設定終了。

指定した日数以前に更新(作成)されたエントリーアーカイブは「再構築」が行われなくなる。

利用方法についてのアイデア

  • 古いエントリーや日付アーカイブへのアクセスが殆ど無い場合、古いエントリーアーカイブはモジュール部分をSSI,PHP,JavaScript等でインクルードする。新しいアーカイブはアクセスが多いので静的生成する。
  • 古いエントリーではモジュールは使わない (最近のエントリーとか最近のコメント/トラックバックとかは表示させない)。
  • 古いエントリーのコメントやトラックバックを無効にする。
  • RebuildAt1stViewやダイナミックパブリッシングと組み合わせる。アクセスの少ない部分はダイナミック、アクセスの多い部分は静的生成という使い分けが可能になる。

関連しそうなエントリー

もっと普及している考え方かと思ったけどそうでもなさそうなので書いておく。 別にMovable Typeじゃなくても使える方法だけど。

PHPもSSIも使わずできるしMTIncludeと比較してもこの方法だと古いページの再構築を一切不要にできる。

関連しそうなエントリー

モジュールをJavaScript化する

要は最近のエントリー等インクルードしたい部分をJavaScriptで吐くわけ。

JavaScript前提じゃん! ってそーですWeb屋の皆さんは「業務」で使わないように。 個人のブログでサーバー管理者から怒られたらやってみれば? くらいのTips(とも呼べないレベルやけど)。

*あと、JSONとかXMLで吐かれるようにしてXMLHttpRequestで...とか言うなよ。JavaScriptで通信させる意味ないし。

まず新規テンプレートを作る。

  • テンプレート名 : RecentEntry
  • 出力ファイル名 : include/recent_entry.js
  • インデックス・テンプレートを再構築するときに、このテンプレートを自動的に再構築する: Check!

テンプレートの内容(最近のエントリー15件を表示する)


document.write('<ul>');
<MTEntries lastn="15">
document.write('<li class="module-list-item"><a href="<$MTEntryPermalink$>"><$MTEntryTitle encode_js="1"$></a></li>');
</MTEntries>
document.write('</ul>');

あとは表示させたい箇所に以下の通り。


<script type="text/javascript" src="/include/recent_entry.js">
</script>
<noscript>
<!--最近のエントリーとか最近のコメントなんかを
まとめたページへのリンクとか置くとより丁寧-->
</noscript>

まぁ、僕はやらないけど役に立つ人もいるかな、ってことで。

実際に「古い」アーカイブにだけ適用してみた。

*JavaScriptにヒア・ドキュメントがあればいいのに...

自由だ!

| コメント(0) | トラックバック(0)

企業が自社製品をOSSであったりデュアルライセンスであったり、つまりはそういう形態でリリースする時に、自分がそのソフトウェアのユーザーでそのソフトについて思うところがあってもし可能ならこんなことやあんなことしてみたいと思ったりした時に、どうせなら自分が単なる利用者ではなく何らかの成果をフィードバックしたり何かをコミットできたら良いな、と。

で、最終的にどんな形でリリースされるのかどうかまだアナウンスがないのであればそれを話題にしてみたり声を上げてみたりするべきじゃないか、でないとリリースする側だって「そうすること」の影響 (インパクト) が予測できないだろうし。

そういった活動を行う時に、それが例えば自分たちの利益とかと一致することで「やりやすく」なることは事実だろうし、ウチの場合だったらそのソフトウェアに取り組むことがビジネスとしてGo! であればフルタイムで専任(たかだか1名くらいだけど) とか雇うことだってやってみたいなと思っているわけで。

そしてそれによって得たものはもちろんライセンスに沿ってオープンしていくか、あるいはライセンスによっては開発元にフィードバックしていくことを考えているわけで。 それがOSSのコミュニティじゃないかって思ったりするのは...

自由だ!


(追記)
ということで、この話題は一旦終わり。引き続き建設的に行こうぜ皆の衆。

世界遺産「姫路城」。

| コメント(0) | トラックバック(0)

天守閣

扇の勾配

鯱

僕が知りたい(笑)。

ということで久しぶりに人前に出ます。

以下、コピペで失礼します。

【第14回】WebSig会議受付開始 「Movable Type 4のポテンシャルを探る~GPLライセンス版登場でMTはどう変貌するか?」

7月28日(土)に第14回WebSig会議:「Movable Type 4のポテンシャルを探る~GPLライセンス版登場でMTはどう変貌するか?」を開催します。

詳細は決定次第、順次告知していきます。

■開催趣旨
第14回WebSig会議は7月18日に正式リリースされる、Movab Type 4および、近々リリースされるであろう、Movable Type GPLライセンス版をテーマに取り扱います。

MT4ベータ版から取り組まれ、またプラグイン作者として著名な4名をお招きし、今までのMovable Typeとは、どのように変わったのかはもちろん、MT4でサイト構築する上でのTIPS等もお伝えできればと考えています。

討論会ではGPLライセンスになればどうなるかを推測し、シックス・アパート株式会社に対する要望・提案などもあげてみたいと思います。

質問コーナーも充分に時間をとりますので、Web制作者の方にとって、明日から使える情報も得られることでしょう。

■テーマ
Movable Type 4のポテンシャルを探る~GPLライセンス版登場でMTはどう変貌するか?


■スピーカー
Movable Typeのプラグイン作者として著名な、4氏に参加表明をいただいております。

○テクニカルライター 藤本壱さん
テクニカルライターとして、Movabl Typeの書籍を書かれ、またプラグイン作者としても著名な方です。
・The blog of H.Fujimoto
http://www.h-fj.com/blog/

・著書
 『AjaxとPHPによる Movable Type高速&最強システム構築法』
 『Movable Typeでつくる!最強のブログサイト プラグイン&カスタマイズ編』
 『Movable Type Plugins Directory』

○エムロジック株式会社 取締役:関根元和(CHEEBOW)さん
プログラマでありつつ、数々の書籍を書かれ、またプラグイン作者としても著名な方です。ハンドルネーム「CHEEBOW」としてブログも運営されてます。
・エムロジック株式会社
http://www.m-logic.co.jp/

・エムロジック放課後プロジェクト
http://labs.m-logic.jp/

・ヒビノアワ
http://cheebow.info/chemt/

・Movable Typeで行こう!
http://cheebow.info/docmt/

・著書
 『改訂新版 Movable Type 標準ハンドブック 』
 『Movable Type Plugins Directory』他

○アルファサード有限会社 代表取締役 野田純生
Webアクセシビリティに配慮したWebサイトの設計と制作を行う、Web制作会社アルファサードの代表取締役であり、Movable Typeプラグインの作者でもあります。

・アルファサード有限会社
http://alfasado.net/

・Junnama Online (Mirror)
http://junnama.alfasado.net/online/

○産業技術総合研究所 小川宏高さん
Movable Typeを超えてアルファブロガーとして活躍されています。Movable Typeのプラグインも多種作成されています。

http://iddy.jp/profile/ogawa/

・Ogawa::Memoranda
http://as-is.net/blog/

・Ogawa::Code - Trac
http://code.as-is.net/public/wiki/WikiStart.ja_JP


■会場
デジタルハリウッド大学 2号館 7階
東京都千代田区外神田3丁目1-16
ダイドーリミテッドビル
http://www.dhw.co.jp/profile/access.html
Google Maps:http://tinyurl.com/2yqmds

■タイムテーブル(予定)
12:30 受付開始
13:20 開演
13:30~17:00 セミナー
17:00 撤収

※詳細なスケジュールに関しては後日アップデート致します。

■お申し込み方法
○メールでのお申し込み
以下のフォーマットによりメールでお申し込み下さい。

宛先:event0728@websig247.jpまで
件名:【20070728】第14回WebSig会議参加申込
本文:
お名前
お電話番号
会社名、屋号、学校名
懇談会参加有無
順次確認のメールを送信させていただきます。
(手作業となりますので、時間がかかる場合がございます)

○mixiからのお申し込み
第14回WebSig会議
上記イベントよりご参加ください。

■懇談会
会議終了後懇談会を実施致します。
詳細は決まり次第、お知らせします。

■会議参加費用:2,000円
※通常会議費用は3,000円ですが、デジタルハリウッド様会場支援により、今回は1,000円引きとなっています。

領収書発行可

■キャパシティ:約100名

■協賛
・デジタルハリウッド株式会社

■ご連絡事項
○受付け、当日の座席について
毎回多数のご応募を頂いており、キャパシティーの都合上、事前で締め切りをすることも多くあります。

ただ、連絡を頂かない当日キャンセルの方が少なくない人数でいらっしゃるので、前日までキャパシティーを若干超えても募集を受付ける予定です。

当日は遅れていらっしゃるかたは場合によっては立ち見の可能性がございますので予めご了承ください。

○申し込み、キャンセルについて
上記の通り、当日キャンセルで参加できない方を減らす意味でも、前日までにキャンセルを頂けない方からは参加費用を頂戴することも検討致しますので併せてご了承ください。

問題!

さっき電車の中で気づいてしまった。さて、このプラグインの問題点は何でしょう? まぁ、答えは来週 (コードの問題ではなくてしくみ自体の問題) 。

*修正版をアップ済みです。

「再構築」快適化3部作(謎)第3弾!

指定した日数以前に更新(作成)されたエントリーアーカイブは「再構築」しないプラグインを作ってみた。

何でこんなの作ったかって? だって趣味「再構築」やし。それなのに...それなのに..シックス・アパートって酷いやん。「再構築」→「公開」に変更したって!? 趣味は「公開」って笑いとれへんわ! 戻してくださいおねがいします。

Change references in app from "rebuilding" to "publishing"

WPユーザーに「ふん? 何?再構築って」なんて言われながらMTユーザーは我慢してたんやぞ! それでも実はみんな「再構築」が大好きだったんだ!

>もーえーわ!


簡単に出来そうなので作ってみました。恒例のMovable Type10分間Cooking!

導入手順

ちょっとコツというか手順を踏まないといけないけれど。

まず初期状態では以下のようになってます。

プラグイン設定画面

何日以内に作成もしくは更新されたエントリーを再構築するか数字で指定。当たり前だけど短くすればする程再構築が短時間で済む。

created_on(作成日)とmodified_on(更新日)のどちらをキーにするかをラジオボタンで指定する(まだこの段階では上のチェックボックスはオフのままね)。

条件タグを一つ用意したので、エントリーアーカイブのテンプレートに手を入れる。

<MTIfOlderEntry>
180日以前に更新(作成)されたエントリーです。古いです。
<MTElse>
古くないです。
</MTElse>
</MTIfOlderEntry>

色々な使い方が出来ると思う。

  • 古いエントリーは殆どアクセスが無いので、古いエントリーアーカイブはモジュール部分をSSIとかPHPでインクルードする。新しいアーカイブはアクセスが多いので静的生成する。
  • 古いエントリーではモジュールは使わない (最近のエントリーとか最近のコメント/トラックバックとかは表示させない)。
  • 古いエントリーはコメントとかトラックバックを無効にする。

等々。で、テンプレートの修正が終了して保存したら一旦全再構築をかける。

その後再びプラグイン設定画面に移動して、「Filter Active.」にチェック→「変更を保存」。以上!

指定した日数以前に更新(作成)されたエントリーアーカイブは「再構築」が行われなくなる。

できればBackground Rebuilderと一緒に使って欲しい。効果がより実感できるので。

このプラグインのライセンスは...『「公開」→「再構築」に戻してよシックス・アパートさん』ウェアとします(大嘘です...GPLね、何かと話題のGPL)

* GPL版MTOSがリリースされるまではパブリック・ドメインとします(もちろん、同じソースのライセンスを変更すると混乱の元ですから、このバージョンのソースはずっとパブリック・ドメインとします)。
MTOSについての何らかのアナウンスがあった時に各プラグインについてのライセンスを再度定義したいと思います。

みんなでここ (Six Apart - Movable Type に関するフィードバック投稿フォーム) から『Beta5から「再構築」が「公開」に変更されていますが、「再構築」に戻して欲しい。』と入力して送信すること! 送信しないとこのプラグインはMT4に対応しません(嘘!...っていうかMT3しか確認してないのでそこんとこよろしく!)。

ダウンロード

いつかちゃんと書こうと思っていた。

こういうタイトルのEntryをM回以上かくとブログがつまらなくなるらしいのだが、まぁいいや。問題は中身だよ。

ここで言う「高速化」とは、CMSを操作している発信者側、ブログを訪れる訪問者側双方を対象にしている。全てが全てどんな環境でも出来るとは限らないが(特にサーバーに対する権限の問題で出来ない部分も人によってはあるかもしれないが)何しろ20もあるから1つや2つは誰にだって出来るだろう。


環境まわり。

1.ハードウェアのスペックを上げる。

当たり前のことだけど、メモリを増やす、高速なHDDに入れ替える、あるいはサーバー自体を変える。

レンタルサーバーとかだったらプランを変更する。 金かけたくない? とはいえメモリーもHDDも昔と比べたら安いものだ。

それでもお金が...というのであればちょっと考えてみて欲しい。レンタルサーバーA社のプランaとプランb, B社のプランcとプランd。価格とスピードは必ずしも比例しない。

2.mod_perlあるいはFastCGI化する。

MT3.34以降の場合は特に後者がお勧め。導入が簡単になっている。mod_perlは高速だがメモリー喰うのでサーバースペックアップとあわせて検討。

参考

(追記)
mod_perlが多くのメモリーを要する件について以下のエントリーで解決の一例が示されている。簡単に言うとApacheを2つ立ち上げて(1つは例えば8080ポート)片方のApacheは静的ファイル群、もう片方のApacheでmod_perlということ。

この例では mod_proxy で説明されているけれども、僕としてはPoundがお勧め。軽い。このサーバーでも使っている。

(追記ここまで)


データベース関係。

3.RDBMSを変更する。

MySQLかPostgreSQLが速いといわれているが、サーバーとユーザー数とかによってそのあたりは変わってくる。僕の経験では意外(?)と速いのがSQLite。

(追記)
ちなみにここはMySQLね。まぁ無難なところかな。(追記ここまで)

参考

4.DBの最適化を行う。

特にSQLiteでは顕著。VACUUM コマンドで定期的に最適化する。

参考


正攻法?

5.テンプレートのモジュール化。

例えばこのブログのように「最新のエントリー」とかを全てのページに表示させる場合、1ページ変更すると全再構築が必要になる。

再構築について誤解があるといけないので書いておくが、一般的には「ファイルをディスクに書き出す」処理よりも「DBからデータを呼び出してHTMLを組み立てる」方に時間がかかる。MTは内部的にはキャッシュを様々なところで利用していて出来るだけ無駄がないように工夫している。実際のところ「全てを再構築」しても全てのファイルが更新されるわけではない。静的HTMLファイルのタイムスタンプを一度チェックしてみると良い。

この方法は環境に依存せずに実行できる手法であるから是非検討すべき。

詳細は下記のエントリー参照。MT内でIncludeする方法もあるし、PHPやSSIでインクルードする方法もある。

6.テンプレートタグのクリーンアップ。

コメントを受け付けているかどうか、とかCCライセンスかどうか、等はそうそう変更するものでもあるまい。余分な分岐や余分なDBへのアクセスを減らせばその分速くなる。これも先のエントリー参照。

(追記)
少し引用。つまり、デフォルトテンプレートには結構不要な分岐処理のタグなんかが含まれているのだ。

また <MTBlogIfCCLicense> とか一度決めてしまえば不要なもの、あるいは「追記(more)」を使用していないのであれば「 <MTIfNonEmpty tag="EntryMore" convert_breaks="0">」のブロックとかも不要。 カテゴリーアーカイブが必ず吐かれる設定であるのなら「<MTIfArchiveTypeEnabled archive_type="Category">」のブロックもいらない。「タグ」を使っていないとか、自分のスタイルにあわせて不要な部分を削除していく。その分プログラムがデータをチェックする(僅かではあるが)処理が省略できる。

(追記ここまで)

7.アーカイブの数を減らす。

そもそも「月間アーカイブ」って必要? 一度ログをとって解析してみれば良い。不要ならアーカイブマッピングを削除して要らないアーカイブを吐かれないようにしてしまおう。

(追記)
アーカイブだけじゃなくて不要なインデックス・テンプレートもないかチェック。静的生成で運用しているのに mtview.php が毎回再構築されるなんて設定になってない? CSSやJavaScriptは毎回再構築の必要ある? (インデックス・テンプレートの場合は「インデックス・テンプレートを再構築するときに、このテンプレートを自動的に再構築する」のチェックを外せばよい) (追記ここまで)

8.アクセスの少ないページや古いページを再構築対象から外す。

1日1回更新するブログで10,000エントリーを超えていて1日のPVが1,000程度だったら...再構築から再構築の間にアクセスが全くないページが多いわけで(少なくとも9,000ページは無駄な再構築)。

古いページは静的HTMLで置いておき再構築対象から外してしまえば良い。アーカイブとかサイトマップとかトップページへのリンクをちゃんと貼っておけば興味のある人は辿ってくれるだろうし。

ファイルを予めバックアップしておいてMT上でエントリーを削除あるいは下書きにする。全再構築後バックアップファイルをサーバーへ戻してやればよい。というかそんなプラグインはないのだろうか。無ければ作ればいいし。

→作ってみたので宜しければどうぞ。

9.不要なプラグインは外す。

どのプラグインがどうとは言えないが、そのプラグインがどこで何をしているかを把握できない人は不要なプラグインを外すべき。処理が必要かどうかにかかわらず、ロードされる僅かな時間だけでも短縮できる。


プラグインやフリーソフトの手を借りる。

10.高速化のためのソリューションを検討する。

僕の書いたものであれば「Background Rebuilder」「RebuildAt1stView」など。他にもPerl版ダイナミックパブリッシング(MT4対応版が今日リリースされています)RebuildQueueFast Searchとかいくつかのソリューションがある。ブログの状況に応じて役に立つものがあるかもしれない。

11.高速な全文検索システムを導入する。

mt-search.cgiは重い。

代わりのソリューションを検討しよう。Fast Searchとか、僕も一つ作ったものを公開している(MTLiteSearch)

エントリー数が少なければAjax化とか、あるいはもっと手軽にGoogleやYahoo!を使う手もある。

サーバーへソフトウェアのインストールが可能なら、全文検索システムを入れてしまえば良い。お勧めはHyper Estraier。このブログでも使っている。以下のエントリーで紹介している。


負荷対策、というかスパム対策。

(追記)
まとめ記事

(追記ここまで)

12.トラックバックを無効にするか、検知されにくくする。

無効にするのが嫌ならば<$MTEntryTrackbackData$> を削除する。「自動検知」ができなくるが、普通にトラックバック機能は有効。尚、無効にするのであればCGIは削除しておこう。CGIが叩かれたらどのみち負荷がかかる。
スパム検知のソリューションで外部へHTTPで通信するタイプのものは場合によっては外すことも検討する。処理に時間がかかるのでそれなりの負荷がかかる。DBへのアクセスが嫌か無駄なHTTPが嫌かは状況に応じて。どのみち事前承認制にしているのであれば自分が嫌な気分になるのさえ我慢すれば良い。

13.コメントを無効にするか、わかりにくくする。

もちろん無効にするってのは根本的な解決法ではない。JavaScriptでコメント欄を組み立てるとか、ダミーのフォームを作って(ダミーのフォームはCSSで非表示)だまくらかす、等。但しアクセシビリティに注意。

14.コメントやトラックバックのCGIのファイル名を定期的に変更する。

上記の2つと被るかもしれないが、CGIファイルの定期的なリネーム。自動化している人もいるようだ。

15.ウェブサーバー側でスパムを排除する。

どんなに優秀なスパムフィルタであっても、CGIを叩かれまくりDBアクセスやHTTP通信が発生していたら負荷かかりまくりである。上記で紹介した「スパマーを騙す」方法にも限界があるし、Apache(に限らないがWebサーバー)側でスパムを弾こう。.htaccess等でdeny指定してやれば良い。但し.htaccessの設定項目が多いとApache側に多少負担がかかる。コメントやトラックバックスパム対策であれば、該当するCGIプラグラムやCGIディレクトリだけを対象にしてやれば良い。

.htaccessでの弾き方の例は例えばこちら↓


サーバーチューニング、HTTP通信関係。

16.ウェブサーバー自体を高速化する。

ApacheならApache自体を高速化する。ログのDNSルックアップを無効にするとか (そもそもログ必要?) 不要なディレクティブを削除するとか.htaccessを使わないとか。そもそもルート権限があるのであれば不要なモジュールを外して再コンパイルする等。

mod_cacheも検討しよう。

17.ダイナミック・パブリッシングではサーバーキャッシュとクライアントキャッシュを使わせるようにする。

サーバー側でキャッシュ機能を使うようにしているWebアプリは多いがクライアントキャッシュをきちんとコントロールしているものはまだまだ少ない(ように思う)。具体的にはConditionalGET(条件付きGET)に対応させること(If-Modified-Sinceをちゃんと見て適切に304を返す)。 これは負荷対策だけでなく転送量も減らしてくれる。

MT4にはダイナミックパブリッシングにおいてこれらの設定が可能になった。

ダイナミックパブリッシングのオプション設定

以下のエントリーもご参考にどうぞ。


その他の方法。

18.「全再構築」をコマンドラインから行う。

mt-rebuildを使うとコマンドラインから再構築が行える。シェルが使えないのであればRebuildQueueとかBackground RebuilderであればCGIとは別プロセスで再構築を行えるので同様の効果が期待出来るだろう。

19.更新は夜中(明け方?)に行うか「指定日公開」を使う。

共用レンタルサーバーとかであれば全体の負荷が少ない例えば明け方とかに更新・再構築すれば負荷は少ないが、健康にご注意を。

健康を気にされる方は (気にしろよ!>俺) 指定日公開でなくとも良いが、cronでmt-rebuildを走らせてもよいし、とにかく負荷の少なそうな時間帯に再構築を行うようにする。

20.JavaScriptやFlash製のブログパーツを外す。

これは閲覧者側の速度に関わるものだが (俺も広告貼ってんじゃん!) ブログパーツや広告の多いページは「重い」。特に別のサーバーにアクセスして動的にJavaScriptで組み立てるタイプのものは重くなる。広告配信サーバーが重ければそのとばっちりも受けなければならない。静的な広告はそうでもないが。


動的とか静的とかいう以前になんぼでも方法はあるのですね。

ところで、あなたのブログが仕事に欠かせないビジネスブログであったり重要なマーケティングツールであったり、ビジネスサイトの運用にMTをCMSとして利用している場合、上記の20項目を簡単に実行するたった一つの方法がある。

21.ウチの会社に連絡する。

ということで、ブログ高速化コンサルティング(コンサルティングだけじゃないよ)、お受けします! (笑)

がいよう。

「TrackBackはもうなかったことにしてはどうか?」とは? - Ogawa::Memorandaに反応してGoogleに買われる妄想を膨らませてみるエントリー。

実はこのモデルはユーザの負荷を外部サーバにオフロードすることによって利便性を提供しているという点でFeedBurnerと似通っている。誰か立ち上げてGoogleに買われるまで頑張ってみては(嘘)!!

例えばこのエントリからこのエントリへトラックバックを打つとして。

しようしょ。

http://example.com/ping.fcgi/http://as-is.net/blog/archives/001257.html へ以下のようにPOSTする(トラックバックの仕様通り)。

my $url = 'http://example.com/ping.fcgi/http://as-is.net/blog/archives/001257.html;
my %TBdata = (
	'url' => 'http://junnama.alfasado.net/online/2007/07/trackback_google.html',
	'blog_name' => 'Junnama Online(Mirror)',
	'title' => 'TrackBackをなかったことにしてGoogleに買われるまで頑張ってみたりして。',
	'excerpt'=> '「TrackBackはもうなかったことにしてはどうか?」とは? - Ogawa::Memoranda に反応してGoogleに買われる妄想を膨らませてみるエントリー。');
my $request  = POST($url, [%TBdata]);
my $ua = LWP::UserAgent->new;
my $res = $ua->request($request);
print $res->as_string;

受け取ったデータをスパムフィルターにかけてからHyperEstraierの文書ドラフト形式に変換してデータベースへputする。

@uri=http://example.com/ping.fcgi?__mode=get&to=http%3A%2F%2Fas-is.net%2Fblog%2Farchives%2F001257.html&rf=http%3A%2F%2Fjunnama.alfasado.net%2Fonline%2F2007%2F07%2Ftrackback_google.html
@title=TrackBackをなかったことにしてGoogleに買われるまで頑張ってみたりして。
@author=Junnama Online(Mirror)
@cdate=2007-07-05T12:00:00+09:00
@mdate=2007-07-05T12:00:00+09:00
rf=http://junnama.alfasado.net/online/2007/07/trackback_google.html
to=http://as-is.net/blog/archives/001257.html

「TrackBackはもうなかったことにしてはどうか?」とは? - Ogawa::Memorandaに反応してGoogleに買われる妄想を膨らませてみるエントリー。
estcmd search -vx -sn 300 100 200 -attr 'to STREQ http://as-is.net/blog/archives/001257.html' casket

とするとXMLで帰ってくる(一応ちゃんとやってみたからね)。

<?xml version="1.0" encoding="UTF-8"?>
<estresult xmlns="http://hyperestraier.sourceforge.net/xmlns/search" version="1.4.9">
<meta>
<hit number="1" auxiliary="off"/>
<hit key="[UVSET]" number="3" auxiliary="off"/>
<time time="0.000896"/>
<total docnum="3" wordnum="92"/>
</meta>
<document id="1" uri="http://example.com/ping.fcgi?__mode=get&to=http%3A%2F%2Fas-is.net%2Fblog%2Farchives%2F001257.html&rf=http%3A%2F%2Fjunnama.alfasado.net%2Fonline%2F2007%2F07%2Ftrackback_google.html">
<attribute name="@author" value="Junnama Online(Mirror)"/>
<attribute name="@cdate" value="2007-07-05T12:00:00+09:00"/>
<attribute name="@digest" value="ae74279b347acb5284ddbb66d6a92a15"/>
<attribute name="@mdate" value="2007-07-05T12:00:00+09:00"/>
<attribute name="@title" value="TrackBackをなかったことにしてGoogleに買われるまで頑張ってみたりして。"/>
<attribute name="rf" value="http://junnama.alfasado.net/online/2007/07/trackback_google.html"/>
<attribute name="to" value="http://as-is.net/blog/archives/001257.html"/>
<snippet>「TrackBackはもうなかったことにしてはどうか?」とは? - Ogawa::Memoranda に反応してGoogleに買われる妄想を膨らませてみるエントリー。<delimiter/></snippet>
</document>
</estresult>

なので、http://example.com/ping.fcgi?__mode=get&to=http%3A%2F%2Fas-is.net%2Fblog%2Farchives%2F001257.html へリクエストを送るとこのXMLをそのまま返すようにして...あとはAjaxでごにょごにょと...

めも。

スパム判別の部分がキモになるわけですが各ブログのオーナーが自分のブログのエントリーに対する公開・非公開・スパムといった判定を反映できる管理画面を提供して、そのデータを共有するようにすればいいかな。他にもスパム判別のアルゴリズムはあれこれあるからそのあたりを組み込んで。あとはスパムデータの共有とトラックバックデータの検索をノードサーバーでP2Pで処理させて負荷分散が図れるように最初から考えておくわけだな。

おまけ。

HyperEstraierのトップページの見出しにいつも密かに笑っているのだが、さっき覗いたら「超超超超イイ感じ迷子: コードも書かない人に言われたくはない。」だった(笑)。コード書くから言わせてね。虎苦罰区検索系夜露死苦!

Googleに買われるまで頑張ってみては(嘘)!!って...よく見たら(嘘)!!って書いてあったのに今気づいた(嘘)。

1ヶ月あたりの転送量制限が10GBで、先月の「転送量」が 31.7 ギガバイトに達した、とある。

すんごいなぁ。ただ、同じプランを選択している人たちの転送容量はどのくらいあるのだろうか?

1ヶ月あたりの転送量制限が10GBで、その実1GBしか転送料がないユーザーがいれば9GBは浮くのである。で、そういうケースは少なくないと想定される(同様の話題の少なさから想像できる)。

つまり、31.7 ギガバイトの転送量はこの「許容されてはいるが使われない転送量」と相殺されるかお釣りが来る筈である。ところがASPサイド(TypePad)側が悲鳴をあげた。

これはつまり「契約者に許可されている目一杯の転送容量を皆が使い切ったらそもそもサービス自体が存続できない」ことを前提にされている、と言い換えられる。

これって、一定の人が使わないことを前提としている「ポイントカード問題」とどこか似ていると思った。

つまり...ブログにモノを書くことに対するコストは誰かが負担しなければならなくて、無料で色んなことが出来るといったまやかしに早くみんな気づくべきではないかと。

で、無料の何かに広告を載せることで収益を上げている会社のロボットが実は収益のしくみを確立できない弱者(弱いサービス事業者)を苦しめているのではないか、などということを考えてみたりする今日このごろ。

31.7 ギガバイトのうちのどれだけがGooglebotなんだろう...

だいたい大人がこういうことを言うときには疑ってかかるべきだ。

お題は「どうして若者はうまく働くことができないのか?」
一方に引きこもったまま労働しない若者がおり、一方に過労で倒れそうな若者がいる。
いずれも「うまく働いている」わけではない。
どうしてなのか。

「どうしてもなにも、昔から若者はうまく働くことができなかったし、今もそういうもんだ」というのが正しいのだと思う。
もちろん元ネタに「今どきの」とは書いていないわけだが。

むしろ私には「昨今の若者」たちが、「いい仕事をすること」「いい汗をかくこと」に対しては貪欲でも、「それに対する代価を要求し、その権益を確保することにはさほど興味がない」ように見受けられる。

たしかにそうだが、それは本質ではない。

労働(ろうどう)とは、人間が道具を用いて対象にはたらきかけ、人間にとって有用で価値のあるものをつくりだす行為である。
また、商品としての労働力は、肉体や頭脳を提供する代わりに、賃金を得る行動であるとも定義される。賃金を得ない活動はボランティアと呼ばれる。

確かに能力があったりや努力することは知っていてもそれを「換金」するのがうまい若者は少ない(ってか、うまくなくていーじゃん!)。「ニコニコ動画」にすごい才能やエネルギーを投じていたとして、それは「労働」ではない。だから「ボランティア」なのだ。

やっかいなのは、そんなボランティアであっても「ネットの力でとにかく沢山集めるとそれがお金に換わってしまう」ということを若者が知っていることだろう。Web2.0的な、何か。

そして、現代の若者たちはそのような「特例」だけしか知らない。

ほらまたこういう書き方をする...

レッテルを貼るほどパターン化されてるわけじゃあるまい。

ただ、「特例だけしか知らない」かどうかはともかく「特例」を実感として知っているのも現代という時代の事実。例えばAdSense、例えばアフェリエイト。そんでもってWeb2.0。

人と接すること無く、会社や上司の指示もなく、とにかく例えば1日に100円を稼ぐのは容易いのだ。0円と100円ではすんごい差である。とにかく100円は稼げる。

だからといってブログ書いていても食えない。これが現実。でもそれで食える人がいることを知ってしまっているのが現代の若者...じゃないかなぁ。

別に「うまく」なくていいじゃない。それが若者の特権なんだから。

過労で死なない程度に努力し、工夫して学び成長することさえ忘れなければ。

などとオっさんが書くとやっぱり何だか...な感じに見えるのかなぁ。本日の駄文は以上。

これがどうにも理解できなかったんですよね(俺だけ?)。

小粋空間さんのところで紹介されていたプラグインのソースを眺めていて...あぁやっと分かった。PHPでインストーラとか用意したりしなくて良かったんですよね。

実はちゃんとオブジェクト・リファレンスには書いてあるわけですが (みんなこれで理解してたんだ...すげぇ) ってかやってみたら簡単やった...ってのが多いな、最近。

schema_version

プラグインでいくつかのオブジェクト・クラスを宣言している場合、これらのクラスのインストールまたはアップグレードが必要かどうかを判断するためにschema_versionを用います。Movable Typeでは、プラグインのschema_versionをMT::Configテーブルに保存し、参照できるようになっています。

object_classes

MTのアップグレード処理で保持すべきMT::Objectの派生クラスのリストを宣言します。

object_classes => [ 'MyPlugin::Foo', 'MyPlugin::Bar' ]

当該オブジェクト・パッケージのスキーマも保持するため、schema_versionも併用してください。

つまり, インストール(データベースのアップグレード)について特にコードを書く必要は無いんだな。Permalink.pm を用意して,

package MT::Permalink;
use strict;

@MT::Permalink::ISA = qw( MT::Object );
__PACKAGE__->install_properties({
	column_defs => {
		'id' => 'integer not null',
		'blog_id' => 'integer not null',
		'permalink' => 'string(255)',
		'modified_on' => 'timestamp',
	},
	indexes => {
		blog_id => 1,
		permalink => 1,
		modified_on => 1,
	},
	child_of => 'MT::Blog',
	datasource => 'permalink',
	primary_key => 'id',
});
1;

プラグインの中で schema_version と object_classes を加えてやる。

use vars qw( $VERSION $SCHEMA_VERSION );
$SCHEMA_VERSION = '0.50';

@MT::Plugin::RebuildAt1stView::ISA = qw(MT::Plugin);

my $plugin = new MT::Plugin::RebuildAt1stView({
	name => 'RebuildAt1stView',
(中略)
	'schema_version' => $SCHEMA_VERSION,
	object_classes => [
		'MT::Permalink',
	],
});

プラグインをアップロードしてログインしようとすると...

アップグレード画面

設定完了画面

ということで, 導入がより簡単になった RebuildAt1stView(Beta) をアップしました。

要は静的生成で再構築が嫌じゃんっていうのは「閲覧する人」「サーバーの管理をする人」よりも「自分(Blogのオーナー)」の都合最優先、「オレが楽したい」わけです。

一方で、ブログサービスの提供者にしたら「自分(Blogのオーナー)」ってのが今度は「客」に早変わり。「客」と「客の客」のどっちを優先するかというあたり受託のウェブ制作と近いところがあるわけですな。

「これだとMacで見れないんですけど」
「でも、手間かかるの嫌だし。みんな本業忙しいからMacとか気にしてられない」

で、そのあたりを吸収して意識させないソリューションを提供するのがウチの会社なわけです(格好ええわ!)。

ってのは本題ではなくて、このあたりを解決する有効なソリューションになり得るんだと思うわけです。これは。

問題はですね、「ネーミング」なんです。

「ダイナミックパブリッシング」ってのは一般化してきた。「静的生成」とか「再構築」ってのも一般化してきた。だからこの形式にもネーミングが大切なんだよなぁ。

「逐次再構築」ってのは見るからにイマイチだし...

  • ジャスト・インタイム・リビルディング(J○v○かよ...)
  • オンザフライ・リビルディング(違うなぁ)
  • バーチャル・ダイナミック・パブリッシング(バーチャルかよ)

ということで、素敵なネーミング募集中。

# 名詞の肩書きに「再構築マニア」と入れるかどうか迷っている今日この頃...


追記:
こんなエントリーを見つけました。「イベントドリブン型静的生成」という表現をしていますね。

あと、トラックバックいただきました。

Greg Packer's Publishing「包装係グレッグの出版???」...駅前留学しようかな...いや固有名詞か。http://en.wikipedia.org/wiki/Greg_Packer...

あ、こいつか! 汗くさそうー!(笑)

まぁ英語がアレなのでROMってるわけなんですが、何か盛り上がりに欠ける印象を持っていました(<<お前が言うな :-) )

さっき流れて来たメールを見て「あぁ、ようやくOSSらしくなってきたかなぁ」と (ただそれだけですが)。

I have made a Simplified Chinese language pack for MT 4 Beta 4. ということでChinese language packだそうです。

昨日改めて公開したMovable Type RebuildAt1stView(Beta) のことを当初「Movable Type用「逐次再構築(仮称)」プラグイン+α(β版)」と表現したわけですが、実際「プラグイン(.pl)」だけではなくて様々なファイルで構成されています。以前にも何度か書きましたが「Movable Typeを開発プラットフォーム」であると捉えれば「プラグイン」以外にも様々な拡張方法があります。

参考エントリー

これまでに色々やって来たまとめという意味もありウチのスタッフへの説明の意味も込めて「高いメンテナンス性を保ちながらMovable Typeを本格的に拡張するためのヒント」について少しまとめておきたいと思います。

「良い習慣」と書きましたが、受託ベースのWeb屋の思考回路での考え方です。もちろんオープンソース(GPL)版をベースにコミュニティベースで開発を進める場合にもなんらかのルールは必要だと思いますし、そのあたりを考える意味もあって書いてみました。

このエントリーは以下のプラグインを例にとって書かれています。

MT3/4両対応。エントリーアーカイブへの最初のアクセスがあった時点で再構築(静的ファイル生成)を行うMovable Type用のプラグイン, CGIスクリプト等で構成されています。

RebuildAt1stView(Beta) の構成

プラグインの構成

参考ページ


さて、ここからが本編となります。

1.出来る限りイリーガルなDB利用は避ける。素直に新しいテーブルを作る。

『このサイトでは「コメント」は受け付けないので「mt_comment」テーブルを別の用途に使おう』、とか『「created_byとmodified_byは、現在使われていません。」とあるのでこの2つは別の用途に使えるじゃん! 』みたいなイリーガルな使い方(本来のDBの設計の考え方から外れた使い方)を僕自身もしていた時期がありましたが、MTのバージョンアップ時にデータベース構造が変更になったり以前のバージョンでは未使用だったフィールドをMTが使うようになったり、あるいは別のプラグインで同じような考え方をしていた場合(例えばcreated_byとmodified_byを使おう、というプラグイン作者が他にもいた場合)当然コンフリクトがおこってしまいます。

MTには新しいテーブルを作ってアクセスする方法が用意されています。MT::Objectのサブクラスを作る方法です。この方法で拡張した場合、MTの他のテーブルと同じようにSQLを意識せずに読み書き検索などが可能です。

今回のプラグラムでは PerlmalinkからEntryのidを割り出す必要があって、これはもちろん可能なわけですが(例えばこちらのプラグインではその処理を行うようになっています)検索に時間がかかったり処理に負荷がかかっては意味がないわけです。何ぶん動的生成・静的生成の良いところをとってできるだけ負荷が少なく作成者にも閲覧者にもサーバーにもメリットがある方法を探ろう、という意図で作ったものだからです。 そこで、perlmalinkとentry_idを紐付けるだけのmt_permalinkというテーブルをデータベースに追加することにしました。

テーブル:mt_permalinkの構造
permalink_idint(11)
permalink_blog_idint(11)
permalink_permalinkvarchar(255)
permalink_modified_ontimestamp

データベースをさわる関係でインストールや設定が大変という面はありますが、素直にMT::Objectのサブクラスを作って拡張した方が後々悩まずに済みますし、フィールド名もわかりやすく設定できますからコーディング時にもわかりやすくなります。

(追記)MT::Upgradeを使ってアップデートすれば簡単...だわ。さっきようやく理解できた...↓ということで See also...

2.MT::Objectのサブクラスを定義した.pmファイルは/plugins/foo/lib/MT/以下に置く。

「mtフォルダのlib/以下やextlib/以下にfoo.pmを設置してください」というタイプのプラグインやソリューションがありますが、インストールの箇所が複数になるのはいかにも面倒ですし、削除する時に忘れてしまう可能性もあります。インストールが面倒だと開発途中で自分自身が面倒です。/plugins/foo/lib/MT/以下に設置しておけばプラグイン/plugins/foo/foo.plからはパスが通っていますのでフォルダ丸ごと上書きアップロードでインストールやバージョンアップが可能です(もちろんアンインストールもフォルダを削除するだけです)。

3.Transformerプラグインを利用したCMSのテンプレート書き換えは最小限に留める。

CMSに新しいボタンを追加したり管理画面を拡張するTransformerプラグインはいかにも「派手」なのでついついテンプレートをぐちゃぐちゃと書き換えることに楽しみを見いだしてしまいがち(違?)ですが、以前も書きましたがCMSのテンプレートを正規表現で検索してバギバキ置換して書き換えるのは極力避けた方が良いと思っています。バージョンアップでテンプレートが変更になった時にすぐ動かなくなりますし、これも他のプラグインとコンフリクトを起こす可能性があります。

但し、V4からはDOMがサポートされたようですので、これまでのように数文字変更されただけで正規表現にかからなくなってTransformerプラグインが動かなくなるということはないようです。

以下「Movable Type v4.0 (Athena): A Developer's Perspective (Movalog: Movable Type Tips & Tricks)」より

これまでは粗雑な検索に頼って必要なコードの行を捜し求めて、それを私たちが欲しかったものに置き換えるテクニックを利用してきた。この方法には少しの変化でプラグインが動かなくなる問題があった。

V4.0では、一連のDOMのような方法を導入した(getElementById、getElementsByTagNameなどを含んでいる) 。

これらのメソッドは、私たちが(APP)CMSテンプレートの中から簡単にフィールドやとマークアップを見つけることを助けるだろう。

これはTransformer pluginsがより「壊れにくく」なったことを意味する。

テンプレート編集画面の「インクルード」テンプレートを表示する部分

これがどのように役立つかについての素晴らしい例が「テンプレート編集画面」にある。 新しくなった4.0のテンプレート編集画面ではテンプレートがMTIncludeタグを含むとき、テンプレートへのリンクがサイドバーで自動的に表示される。

CMSのテンプレートをカスタマイズする最も簡単な方法は、mt/alt-tmpl/以下にtmpl/cms以下のテンプレートを(必要なものだけ)コピーしてコピーの方をカスタマイズする方法です。この方法のメリットは「ノンプログラミング」でカスタマイズが可能なことです。「抜粋(概要)」を「スペック」に書き換える、といった作業であればHTMLコーディング程度の知識でカスタマイズできます。

但しこの方法もコンフリクトやバージョンアップの際の問題は避けられません。また、設置場所が複数に分散するのでインストールや更新が煩雑になる問題も解決出来ません。

やはりTransformerプラグインは(コードの保守性の面からは)最小限にすべきかと思います。

4.既存テンプレート書き換えでなく「__mode」と新規テンプレートを追加する。テンプレートはプラグインフォルダ内/tmplフォルダに置く。

ではどうするか。ケースバイケースですが、単に新しい画面を用意するだけであればこの場合のグッド・ノウハウは『新しいアプリケーションのモード(__mode)を作って「プラグインアクションから」呼び出す。CMSのテンプレートは新しく用意して/plugins/foo/以下に置く』というものです。/plugins/foo/以下に置くのは前項と同じくインストールや更新を楽にするためです。今回は/plugins/RebuildAt1stView/tmpl/ 以下に置いています(V3.tmpl及びV4.tmpl)。

新しい__modeを定義する

app_methods => {
	'MT::App::CMS' => {
		'remove_all_entry_archive' => ¥&_remove_all_entry_archive,
		'update_permalink' => ¥&_update_permalink
	},
},

以下のように呼び出すことができます。

mt.cgi?__mode= remove_all_entry_archive&...

今回作成したのは、「ボタンをクリックするとmt_entryから各エントリーのid,permalink,modified_onを取得してmt_permalinkに登録する(初期化)ための機能と」「ボタンをクリックすると静的に生成されたエントリーアーカイブファイルを全消去するもの」です。これらの機能のためには「ボタンを追加する」「実行結果をユーザーにフィードバックする」といった(各々)2種類のテンプレートが必要です。

5.(ユーザビリティにこだわるところでなければ, )ボタンの追加には「add_plugin_action」または「config_link」を使う。

逆に言えば, CMSのユーザビリティにこだわるところではTransformerプラグインで書く、ということになります。MTの拡張の場合はユーザービリティとコードのメンテナンス性がトレードオフの関係になる場合があることを意識しておいた方が良いと思います。

ボタンを追加するだけであればテンプレートのカスタマイズは不要です。管理画面のユーザビリティを向上するためには「ボタンの位置」等が大切ですが、メンテナンス性とコードの可読性を優先するのであれば「add_plugin_action」または「config_link」を使うと良いでしょう。

config_link => '../../'.MT->config('AdminScript').'?__mode=update_permalink'

プラグイン設定画面→テーブルの更新

あるいは

MT->add_plugin_action(	'blog',
							'../../'.MT->config('AdminScript').'?__mode=remove_all_entry_archive',
							$plugin->translate('Remove All Entry Cache')
						);

オープンソース(GPLバージョン)をベースにコミュニティで開発する場合等は__modeの命名規則等を定めておいた方が良いと思います。

エントリー一覧のプラグインアクション

6.MT3.xとMT4のバージョン判別・処理切り分けはできるだけシンプルにする。

MT3.xとMT4では管理画面のデザインが大幅に異なっていますので、さすがにここは共有できませんが、単に実行結果を表示するだけであれば非常にシンプルなテンプレートを用意すれば済みます。

plugins/RebuildAt1stView/tmpl/V4.tmpl

<$mt:include name="include/header.tmpl"$>
<TMPL_VAR NAME=DIV><a href="javascript:void(0)" onclick="javascript:hide('saved');" class="close-me"><span>close</span></a>
<TMPL_VAR NAME=CONTENT>
</div>
<$mt:include name="include/footer.tmpl"$>

plugins/RebuildAt1stView/tmpl/V3.tmpl

<TMPL_INCLUDE NAME="header.tmpl">
<h2><span class="weblog-title-highlight"><TMPL_VAR NAME=PAGE_TITLE ESCAPE=HTML></h2>
<TMPL_VAR NAME=DIV><TMPL_VAR NAME=CONTENT></div>
<TMPL_INCLUDE NAME="footer.tmpl">

plugins/RebuildAt1stView/RebuildAt1stView.pl (プラグイン本体の抜粋)

# バージョン判別
my $mt_version;
my $transform_tmpl;
my $div_success;
my $div_error;
my $v = MT->version_id; 
#->4.0 Beta 1 

# バージョン毎にCMSテンプレート関連の定義
if ($v =~ /^4/) { 
	$mt_version = 40;
	$transform_tmpl = 'V4.tmpl';
	$div_success = '<div id="saved" class="msg msg-success">';
	$div_error = '<div id="generic-error" class="msg msg-error">';
} else {
	$mt_version = 30;
	$transform_tmpl = 'V3.tmpl';
	$div_success = '<div class="message">';
	$div_error = '<div class="error-message">';
}

(中略)

sub _update_permalink {
	my $app = shift;

# プラグインから呼び出すテンプレートの設置場所のパスを指定
	$app->{plugin_template_path} = 'plugins/RebuildAt1stView/tmpl';
	my $user = $app->user;
	my %param;
	$param{page_title} = $plugin->translate('Update "mt_permalink"');
	if ($user->is_superuser) {
		MT::Permalink->remove_all;
(中略)
		$param{div} = $div_success;
		$param{content} = $plugin->translate('Entry Archives List was Updated.');
		return $app->build_page($transform_tmpl, ¥%param);
(以下略)

MT4.0での結果表示

テーブルmt_permalinkのアップデート結果(MT4)

MT3.3での結果表示

テーブルmt_permalinkのアップデート結果(MT3)

7.ログインなしで動作させる箇所やアドレスを晒したくない場合、あるいは軽快さを求める箇所ではMT::Bootstrapを利用する。

__modeで新しい動作を定義する方法もありますが、コメントやトラックバック等は「ログインしていないユーザー」が利用するわけです。こういったケースではMT::Bootstrapを利用するの良いでしょう。RebuildAt1stViewではmtview.cgiからMT::Bootstrapを利用してMTViewCGI.pmを走らせています。MT::Bootstrap を利用したアプリケーションは (MT3.34以降であれば) そのままFastCGIに対応できるというメリットもあります。またmt.cgiのパスを晒さなくて済みます(例えばApache側でmt.cgiのアクセスを制限すればセキュリティも向上させられます)。

plugins/RebuildAt1stView/mtview.cgi (あるいはmtview.fcgi)

#!/usr/bin/perl -w

use strict;
use lib 'lib';
use lib '../../lib';
use lib '../../extlib';
use MT::Bootstrap App => 'MTViewCGI';

plugins/RebuildAt1stView/lib/MTViewCGI.pm

package MTViewCGI;

use strict;
use MT;
use MT::App;
(中略)
use MT::Permalink;

@MTViewCGI::ISA = qw(MT::App);

sub init_request {
	my $app = shift;
	$app->SUPER::init_request(@_);
	$app->add_methods( MTViewCGI => ¥&_MTViewCGI );
	$app->{default_mode} = 'MTViewCGI';
	$app->{requires_login} = 0;
	$app;
}

my $mt = MT->new(Config => '../../mt-config.cgi');
my $plugin = new MT::Plugin::RebuildAt1stView({ name => 'RebuildAt1stView' });
# プラグインの設定値を得る
my $base_url = $plugin->get_config_value('base_url');
my $base_pth = $plugin->get_config_value('base_pth');
my $error_tmpl = $plugin->get_config_value('error_tmpl');

sub _MTViewCGI {
	my $app = shift;
# ここに処理内容を書く

8.設置調整時にできるだけソースに手を入れなくて良いように設定項目は管理画面から行わせる。

「環境にあわせてプログラムのパスを修正」とかやると導入の敷居が一気に高くなってしまいます。ただでさえプログラム未経験者は呪文の固まりのようなプログラムに手を入れるのを嫌がります。趣味のプログラムなら良いでしょうが、多くの人に使っていただくあるいは仕事で客先に納入するものであれば極力プログラムソースに手を入れる必要がないようにすべきでしょう。

プラグインの設定

プラグインの設定画面のテンプレートはHTML::Templateに則った形式/拡張子を.tmplとしてをplugin/foo/tmpl/以下に置きます。

今回のケースでは plugins/RebuildAt1stView/tmpl/sys_config.tmpl, plugins/RebuildAt1stView/tmpl/blog_config.tmplの2種類。

9.Blog毎にプラグインの有効・無効を設定するために blog_config_template を用意する。

標準ではブログ毎にプラグインを有効・無効にすることはできません(と思う、多分)。プラグインを有効にするとすべてのブログが動作対象になってしまうので、ブログ毎にプラグインの有効・無効を指定したい場合はプラグイン設定テンプレートにチェックボックスを一つ追加してこの値で分岐させます。

plugins/RebuildAt1stView/tmpl/blog_config.tmpl

<div class="setting">
<div class="label">
	<label for="rebuild_at_fview"><MT_TRANS phrase="Enable plugin:"></label>
</div>
<div class="field">
    <p><label><input value="1" type="checkbox" name="rebuild_at_fview" id="rebuild_at_fview" <TMPL_IF NAME=REBUILD_AT_FVIEW>checked="checked"</TMPL_IF> />
    <MT_TRANS phrase="Plugin Active."></p></label>
</div>
</div>

plugins/RebuildAt1stView/RebuildAt1stView.pl (プラグイン本体/ブログ毎のON/OFFの判別部分)

sub _post_save_entry {
	my ($eh, $app, $entry, $original) = @_;
	if (&plugin_active($app)) {
# ...プラグインが有効なら処理する

# プラグインの有効・無効を判別するルーチン
sub plugin_active {
	my $app = shift;
	my $blog = $app->blog;
	my $blog_id = $blog->id;
	my $get_from = 'blog:'.$blog_id;
	return $plugin->get_config_value('rebuild_at_fview', $get_from);
}

10.日本語版だけで良くても国際化対応させる。

何故なら, こうすることでUTF-8とかEUCとか気にしなくて良くなるからです。

ということで、このあたりを反映させたプラグインの登録(設定)部分のコードは以下のような感じになります。

plugins/RebuildAt1stView/RebuildAt1stView.pl (プラグイン本体/設定関連)

my $plugin = new MT::Plugin::RebuildAt1stView({
	name => 'RebuildAt1stView',
	version => '0.5',
	author_name => 'Junnama Noda',
	author_link => 'http://junnama.alfasado.net/online/',
	description => '<MT_TRANS phrase=¥'_PLUGIN_DESCRIPTION¥'>',
	app_methods => {
		'MT::App::CMS' => {
			'remove_all_entry_archive' => ¥&_remove_all_entry_archive,
			'update_permalink' => ¥&_update_permalink
		},
	},
	settings => new MT::PluginSettings([
		['rebuild_at_fview', { Default => 1 }],
		['base_url'],['base_pth'],['error_tmpl']
	]),
# ↑PluginDataに保存する設定項目
	system_config_template => 'sys_config.tmpl', 
# ↑システム全体のプラグイン設定
	blog_config_template => 'blog_config.tmpl',
# ↑ブログ毎の全体のプラグイン設定
	l10n_class => 'RebuildAt1stView::L10N',
# ↑国際化対応

	config_link => '../../'.MT->config('AdminScript').'?__mode=update_permalink'
});

MT3/4両対応。エントリーアーカイブへの最初のアクセスがあった時点で再構築(静的ファイル生成)を行うMovable Type用のプラグイン+α。

Movable Type用「逐次再構築(仮称)」プラグイン+α(β版)。として一旦公開しましたが, 設置調整をできるだけわかりやすくし(基本的にソースをさわる必要はなくなりました)、MT3.x/4.0/FastCGI等に対応させました(結果、インストール方法/ファイル構成や設定方法が大きく変わってしまったので主にインストールと設定の方法を中心に再度ご紹介します)。

インデックスアーカイブ, カテゴリーアーカイブ, 月別(週別)アーカイブ等は静的生成、エントリーアーカイブは動的生成(ダイナミック・パブリッシング)とし、動的生成のページに対しては「最初にそのページにアクセスがあった時」に再構築(静的HTMLファイルを生成)を行います。ダイナミックパブリッシングによる再構築の負荷軽減と静的生成による閲覧時の負荷軽減の両方のメリットを享受できる方式です。

ダウンロード

ライセンス

パブリック・ドメイン

このプログラムは「GPL」に従って配布します。

* GPL版MTOSがリリースされるまではパブリック・ドメインとします(もちろん、同じソースのライセンスを変更すると混乱の元ですから、このバージョンのソースはずっとパブリック・ドメインにします)。
MTOSについての何らかのアナウンスがあった時に各プラグインについてのライセンスを再度定義したいと思います。

以下, 設定方法です。キャプチャはMT4.0Beta4のものです。画面の見た目は違いますがMT3.3でも動作確認しています。

*インストーラは現在のところMySQLのみ対応しています。

「installer」ディレクトリをWebサーバーへアップロードします。

index.phpを表示しデータベース名, ユーザー名, パスワード(データベースのユーザー名とパスワード)を入力して「Create Table」ボタンをクリックしてください。

インストーラ画面

「Update was successful.」と表示されたらデータベースのアップデートは成功です。

*この後必ず「installer」ディレクトリごとサーバーから削除してください(セキュリティ上必ず削除してください)。

その他のRDBMSでご利用の場合は以下の構造のmt_permalinkテーブルを追加してください。

テーブル:mt_permalinkの構造
permalink_idint(11)
permalink_blog_idint(11)
permalink_permalinkvarchar(255)
permalink_modified_ontimestamp

テンプレートの設定(ブログごとに設定)

「設定」→「公開」→「ページ構築方法」で「テンプレート別にスタティックHTMLもしくはダイナミック・パブリッシングを選択します」にチェックを入れて変更を保存します。

設定→公開→ページ構築方法

エントリー・アーカイブ編集画面→「再構築オプション」で「このテンプレートをダイナミック・ページにする」にチェックを入れて変更を保存します。

エントリーアーカイブ編集→再構築オプション

ブログ全体を再構築します。

*これまでに生成された静的ファイルはファイルの末尾に.staticが追加されてバックアップされます。これらのファイルは不要ですので動作確認後削除して構いません。

プラグインのアップロード

pluginsフォルダ内のRebuildAt1stViewディレクトリをMTのpluginsディレクトリ直下に(ディレクトリごと)アップします。

データベースのアップデート

プラグインをアップロードして最初にログインしようとするとアップグレード画面が表示されます。そのままID/Passwordを入れてアップグレードを完了してください。

アップグレード画面

設定完了画面

システム全体のプラグイン設定

システム全体のプラグイン設定画面で「サイトのベース」(http://〜最初のスラッシュの手前まで)、「ドキュメントルート」(両方とも最後にスラッシュを含まないことに注意)、エラーテンプレート(404ページのテンプレートのサイトルートからの絶対パス)を入力して変更を保存します。

システム全体のプラグイン設定

ブログ単位のプラグイン設定

設定を有効にしたいブログのプラグイン設定画面で「プラグインを有効にする」にチェックを入れます(デフォルトは「オン」です)。

プラグイン設定画面→プラグインを有効にする

テーブル mt_permalink へのデータの登録

ここまでの設定が完了したら、プラグイン設定画面のプラグイン名「RebuildAt1stView」をクリックします(インストール時に作成したmt_permalinkテーブルにデータを登録されます)。

プラグイン設定画面→テーブルの更新

テーブルmt_permalinkのアップデート結果

ブログの設定(アーカイブマッピング等)を変更した時や動作が不安定な時は、この操作を再度行ってmt_permalinkテーブルを最新の状態にアップデートしてみてください。

.htaccessの編集

ブログのルートフォルダに「.htaccess」ファイルが生成されていますので(「設定」→「公開」→「ページ構築方法」の設定を行った際に生成されている筈です)これを削除, 同梱の「_htaccess」をアップロード。「.htaccess」にリネームします。


ErrorDocument 404 /mt/plugins/RebuildAt1stView/mtview.cgi

ErrorDocumentのパスをアップロードしたmtview.cgiのパスにあわせてください。FastCGI上で動かす場合は、mtview.cgiをmtview.fcgi とし、cgiのファイル名も同様に修正します。

動作の検証

新規にエントリーを作成するか、既存のエントリーで動作を検証します。

本来エントリーアーカイブが保存されている場所をFTPクライアント等で確認し, ファイルが存在しないことを確認します。その後Webブラウザでページを表示, 再度FTPクライアント等で確認、ファイルが生成されていれば正常に動作していることになります。

ファイル生成のテスト

生成されたファイルの全消去

この方式の場合、(エントリーを追加したりテンプレートを変更し, すべてのページを更新する場合)エントリーアーカイブを再構築する代わりに生成されたエントリーアーカイブの静的ページを全て消去する必要があります。

通常の再構築(すべてのページを再構築)した後に、各ブログのエントリー一覧ページの右下の「プラグインアクション」→「エントリーキャッシュの全削除」をクリックすることで生成された静的ファイルがクリーンアップされます(再度ページへのアクセスがあった時にページは再生成されます)。

エントリー一覧のプラグインアクション

関連エントリー

Facebook

Twitter

このアーカイブについて

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

前のアーカイブは2007年6月です。

次のアーカイブは2007年8月です。

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

Powered by Movable Type 6.2.6