2007年8月アーカイブ

Googleが技術者を募集中らしいので、腕に自慢の方はぜひGoogleに応募して広告の質を判定してAdWords広告の事前審査を行うアルゴリズムを開発してください!

でも70万円くらいならAdSenseで稼げるらしいのでGoogleに応募するよりAdSenseで稼いだ方が賢いかも :-P

で、このページに表示される広告は何でしょうね? 教えて! Googleさん。

ウチの会社で作成したサイトは全部MTで作ってんじゃねぇの? と思われているかもしれませんが、もちろんそんなこたぁありません。

但し昔っからCMS的なサイトの制作を行っていて、「よくこんな小世帯でこんだけのボリュームのサイト作ってんね!?」と言われる答えの一つは「自動化」なわけです。徹夜でガシガシHTMLコーディングってのがWeb屋のイメージなのかもしれませんが、ウチは徹夜はしません。

面接の際に意外によく聞かれるんですけど「徹夜はありますか?」って、世間のWeb屋はどんなんやねん、って思いますよ。

あ、一応答えは「年2回」って答えてます。実際は2回ないけどね。まぁ1回あるかないか。ただ、徹夜になるってことは誰かが何かミスした時しかあり得ないですが、まぁ人間だもの、ミスもあるさっ。

のっけから話それまくりですが、来月こんなイベントがあるそうなのでちょっと前フリというか、ウチでよくやる方法についてちょっと晒してみる(わりと普通なのかなぁ)。

まぁ実際はMTのAPIでもって詳細なカテゴリの関連づけとかブログの切り分けとかテンプレートのインポートとか色々やるわけですが、MT4でエクスポート/インポート形式がちょっとだけ進化したので(ファイル名なんかを引き継げるようになった)、Excelで作成したデータをもとにMTのエクスポート形式のファイルを生成して読み込むって方法が簡単なので紹介したい(もちろん、MT4のバックアップのフォーマットのXMLを気合いを入れて作るって方法もあるよ)。

まず、ExcelとかOpenOfficeとか何でもいいけれどスプレッドシートを作成できるソフトウェアでマスターデータを作る。構造は何でもいいけど、この例ではページのタイトル, カテゴリ, ファイル名, テキスト, 追記なんかを各セルに入力。

保存形式を「テキスト(タブ区切り)」にして保存。

スクリプトはこんな感じ

#!/usr/bin/perl -w
$fp = $ARGV[0];
open(FH, $fp);
while(<FH>){
my $line = $_;
my @datas = split(/¥t/, $line);
my $html = &_read_tmpl($datas[0], $datas[1], $datas[2], $datas[3], $datas[3]);
print $html;
}
close(FH);
sub _read_tmpl {
my ($title, $cat, $basename, $excerpt, $text, $text_more) = @_;
return <<"MT_TMPL_HTML";
--------
AUTHOR: junnama
TITLE: $title
BASENAME: $basename
STATUS: Publish
ALLOW COMMENTS: 1
CONVERT BREAKS: __default__
ALLOW PINGS: 0
PRIMARY CATEGORY: $cat
CATEGORY: $cat
DATE: 08/30/2007 00:00:00 PM
-----
BODY:
$text
-----
EXTENDED BODY:
$text_more
-----
EXCERPT:
-----
KEYWORDS:
-----
MT_TMPL_HTML
}

Macだったらターミナルから引数にマスタ、出力をファイルに指定して実行。WindowsだとActivePerlを入れておく必要があるけど。

perl ./tsv2mt.pl master.tsv > mt_html.txt

生成されたテキストをMTからインポートすればOK。ね、簡単でしょ? コツ、という程じゃないけど、カテゴリは英数文字で指定しておくとカテゴリーのbasenameがこれになってくれる(インポートした後にカテゴリー名とbasenameの関連づけを行う必要があるのだけど、これこそMTのAPIを使えばチョチョイと作れる)。

つまり、ここで書いたことのひとつの具体的な事例ね。

• マークアップエンジニアが次に取り組むべき5つのテーマ。

ということで、このエントリーをよく読んでから、以下のエントリーを読むと幸せになれるかも(笑)。

• マークアップエンジニア募集。

先日来のProNetミーティングや開発者向けカンファレンスで 上ノ郷谷さんがしきりに「ハイブリッド・パブリッシング」と言っていたのでRebuildAt1stViewをハイブリッド・パブリッシングに対応させてみた。これで、テンプレート毎に「インデックス等、頻繁にアクセスされるページは静的生成」その他のページは「最初のリクエストがあった時点で再構築」という使い分けが可能になります。さぁ、再構築の新しい選択肢を今すぐキミも体験してみよう! とかなんとか。

ダウンロード(Ver.0.2)

• RebuildAt1stView.zip(8KB)

以下、プラグインがどうこうというよりもMT4のお作法で書き直しつつ新しいフィーチャーを取り入れてみたいということでメモ的なエントリーになりますが。

オブジェクトの拡張もコールバックも「それ、Registryで」

MT4ではデータベースのテーブルの拡張がとても簡単になっています。Hack-a-thonの時にFujimotoさんが「簡単だよ!」って言っていたので (早速公開された「カテゴリーとフォルダを並べ替えるプラグイン（MT4専用）」でも使われています。

今回はmt_templateテーブルを拡張してテンプレート毎に静的再構築、RebuildAt1stView対象を設定できるようにするフラグ「template_rebuild_at」フィールドを追加しました。

拡張の仕方は本当に簡単。Pluginを->newする時に「schema_version」を指定して「init_registry」で拡張するテーブル名、フィールド名とタイプを指定するだけです。

コールバックのところもこれまでは、

MT->add_callback('MT::App::CMS::AppTemplateSource.edit_template',9 ,$plugin, ¥&_ rebuld_option);

とか書いていましたがMT4では「init_registry」の中で指定します。

この他に、タグの追加や__modeの追加も「init_registry」。init_registryがMT4対応プラグイン作成のキモ? かもしれません。

ということで、RebuildAt1StViewのinit_registryはこんな感じ。

sub init_registry {
my $plugin = shift;
$plugin->registry({
object_types => {
'template' => {
'rebuild_at' => 'integer',
},
},
callbacks => {
'build_file_filter'
=> ¥&_build_file_filter,
'MT::App::CMS::template_source.edit_template'
=> ¥&_rebuld_option,
'MT::App::CMS::template_param.edit_template'
=> ¥&_rebuild_flag,
},
});
}

日本語版のドキュメント充実にも期待していますが、当面はここでMT4の新しいお作法? のお勉強が可能です。

• Movable Type Developer Guide | Movable Type Docs

本日、国立国会図書館のウェブサイトで「写真の中の明治・大正−国立国会図書館所蔵写真帳から−東京編」が公開されました。国立国会図書館の所蔵する明治・大正期の資料の中から、著名な建築物や観光名所など東京の風景写真約500点を選んで紹介するもので、アルファサードが制作を担当しました。

様々な切り口(カテゴリーや地図)で情報にたどり着けるわけですが、Flashを使った地図からの移動においても出来る限り1ページ1URLの形なるように構成されていること、JavaScriptを用いて現在位置(パンくず)表示を閲覧ルート毎に動的に変化すること、Flashが閲覧できない/JavaScriptがOFFの環境でも閲覧に支障がないように配慮されていること(Flashの地図の代替で通常のイメージマップ、等)、最大幅を指定したリキッドレイアウト等、細かなディテールにもこだわったサイトになっています。

このブログを見ている人は同業の制作業界の人が多いと思いますが、そのあたりのディテールにもぜひ注目してもらえればと思います。

最新版はこちらから。

ハイブリッド・パブリッシング(アーカイブ毎に設定できるように)に対応しました!

• RebuildAt1stView.zip(8KB)

関連エントリー

• RebuildAt1stView(Beta) ハイブリッド・パブリッシング対応版。

概要

Greg Packer's Publishingの世界へようこそ!

先日のHack-a-thon の後に話していた中でRebuildAt1stViewの話が出ていたのとOgawaさんにも釣られて? いただいたので、ちょっとやってみる。

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

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

但しTheSchwartz::Jobのみをバックグラウンドかcronジョブで実行するような仕組みのところとか排他処理のところとかはまだやっていない。BackgroundRebuilderをMT4向けの単純なTheSchwartz::Jobのバックグランド処理版で実装したいとは思っていて、このあたりの組み合わせが「再構築」対策の一つの方向性になればと思う。だから、これはまだ途中段階のサンプル。 動作については一切無保証です。改造等はご自由にどうぞ。

MT4対応/全アーカイブ対応/インデックスアーカイブの再構築オプション

今回は、MT4正規版でエラーになっていたらしいのでそのあたりをふまえて全面的に書き直し＋全アーカイブ対応とした。以前よりずっとシンプルなものになった。DBの拡張もなし。

• RebuildAt1stView フォルダをpluginsフォルダにアップロード。
• 各ブログの「公開」の設定は「すべてのテンプレートを静的に構築する」(画像の通り)。
• 設定はブログ毎の「プラグインの設定」→「RebuildAt1stView」から行う。個別テンプレート毎の設定はまだできないが、「アーカイブ・テンプレート」のみを対象とすることが出来るようになった(チェックを入れるとインデックス・テンプレートは再構築の際に通常通りファイルが生成される)。

• 同梱されている _htaccess のパス情報を環境にあわせて修正し、.htaccessにリネームしてドキュメントルートに設置する。

Options -Indexes
ErrorDocument 404 /mt/plugins/RebuildAt1stView/RebuildAt1stView.cgi
ErrorDocument 403 /mt/plugins/RebuildAt1stView/RebuildAt1stView.cgi

ダウンロード

• RebuildAt1stView.zip(8KB)

このプラグインが有効な状態での「再構築」とは即ち「ファイルを削除」することです。 全再構築を行うと生成されているファイルは (設定によりインデックスアーカイブを除いて) すべて削除されます。もちろん見かけ上の再構築処理は非常に軽くて速い。

また新規にエントリーを作成してもファイルは生成されませんし、エントリーを更新したり削除した場合、本来更新されるべきファイルは削除され、最初にそのページへリクエストがあった時点で再構築されファイルシステムに書き出されます。

mixiの擁護をするつもりもないし、なに真面目に反応してんだよオっさんって自分で思わないでもないけれど。

• mixiに通報しても消えない情報商材販売業者の謎があきらかに*ホームページを作る人のネタ帳
• はてなブックマーク - mixiに通報しても消えない情報商材販売業者の謎があきらかに*ホームページを作る人のネタ帳

もうちょっと考えて書こうぜってことと、安易にブクマしないでくれ、ということが言いたい。

* ちなみに、こっち↓のエントリーで書かれていることは正論だと思う。

• WEB自習室（oppappy） - 自分なりに頭を使って真意を検証すべき

普段から意識して考えていればこれがOvertureのリスティングとかGoogle AdSense広告の種のものであることは直感的にわかると思う。というか僕の頭の中ではそう思った (どうやらこのケースはOvertureらしい)。

問題の本質はOvertureやGoogleが広告の審査をまともにしていないことにある。これまでにも感じるところは何度か書いたが。

関連するエントリー

• Googleはそろそろ広告についてもスパム対策を行ったらどうか?
• スパムサイトの増加はGoogleの自作自演か?

* このブログ自身ににAdSense広告貼っておいて何を? というツッコミが来るのは覚悟の上で書くが、少なくとも僕は表示させたくない種類の広告はマメにフィルタリングしている。

Googleは検索で稼いでいるのではなく広告で稼いでいる。ところが検索のスパムには過反応するが広告のスパム (スパムというべきかどうかわからないが、少なくとも明らかに根拠の無い広告、見る人を騙しにかかる広告をそう呼ぶことにする) に対してはまったく寛容である。

フィルタリングをまめにしているとご丁寧にこんな感じでアドバイスをいただける。

システムでお客様のサイトを確認しましたところ、下記の方法を実行することでより多くの収益を獲得いただける可能性があります。
フィルタにより、サイトの収益となる広告が除外される可能性があります。

いや、収益じゃなくて道義的な問題を考えているのだし、僕のエントリーが「不労所得」とマッチングするとGoogleは判断しているのかね? どんなアルゴリズムだよ。

* 今回はOvertureの話でGoogleを引き合いに出して恐縮だが、Google AdSenseで、「アドセンスで○○万円稼ぐ」とかいう広告が平気で出ているわけだ。ちゃんと審査しているの? だいたい「○○万円稼ぐ」方法とか実体験を明らかにしたらその時点で規約違反じゃねぇのか?

本題に戻る。「内部」って一体何を指すのだ?

本題に戻ると、先のエントリーで (* 太字強調は筆者)

mixiに通報しても消えない情報商材販売業者の謎があきらかに

「あきらかに」の根拠を問いたい。「あきらかに」というにはあまりにお粗末な内容じゃねぇか。これを「釣り」というのか? で、皆釣られていると。

と思っていた矢先、内部からこんな情報が飛び出した。

「内部」って何の内部なのか? 読者は国語のテストだと思って考えていただきたい。

Q.このエントリーの「内部からこんな情報が飛び出した。」における「内部」が何を指していると考えられるか? 以下の3つから選択せよ。

1. 「ホームページを作る人のネタ帳」と「2ちゃんねる」の運営主体が同じ。よって、「ホームページを作る人のネタ帳」の内部である「2ちゃんねる」のことを指す。
2. 「mixi」と「2ちゃんねる」の運営主体が同じ。よって、「mixi」の内部である「2ちゃんねる」のことを指す。
3. スレッド主が「mixi」の内部の人であり、このスレはmixiの内部告発スレッドであることを指す。

どれも指さないんじゃね? 少なくとも僕なら出題者にケチつけるよ。どれも違ってるぜって。少なくともどれも「根拠」がない。

「mixiに通報しても消えない情報商材販売業者の謎」と言うけれども「mixiに通報しても消えない情報商材販売業者」ってのが本当にあったのかはっきり書かれていないし、通報したという経緯も書かれていないように見える。

この問題の本質はWeb2.0的なネット広告におけるの審査の甘さ、そして「インターネットにおいてはその情報が正しいかどうかを自分自身が考えて判断しなければならない」ってのは「広告」においても同じであって、ネット広告配信者は「検索結果に責任も負わないし、広告の真偽にも責任を負わない」というところにあるのではないのか? そしてそれを誰も問題にしないのは何故か? mixiは怪しいけどOvertureとかGoogleはそんなことないよねってのが君たち (誰に言っているのかわかんねぇけど) の思考なのか?

そして、検証もせずに話題になりそうな「ネタ」を簡単に取り上げる著名ブロガーと著名ブログのエントリーを簡単に鵜呑みにするブックマーカー。そして皮肉にもそのブログとブックマークページ等に表示される「スパム広告」たち。

少なくとも2大検索エンジンのスパム解析・検出技術が「広告審査」に活用されない限り、あるいは「広告」という収益に依存しているからといってどんなスポンサーでも無条件に受入れているような事実があるのだとしたらこのモデルが破綻するのも時間の問題じゃないだろうか? そしてそうならないようにするためにはユーザーが正しい判断をして「そんな広告相手にしない」こと、あるいは「信頼性低くて使い物にならなくね?」という声をあげて行くこと。そして強力な対抗メディアを誰かが作って既存メディアに喧嘩を売って行くことが必要ではない?

だから、mixiに対して言うべきところがあるとしたら、そういったアカウントは規約違反だし削除すべきじゃね? ということと、少なくとも広告で収益を得ているのであれば、規約と矛盾する広告くらいはフィルタリングすべきじゃね? ということくらいである。それは「やっぱりグルだった?」という問題とは根本的に異なる。

まとめ

• ネタになりそうだからといって検証も根拠も無く記事をポストするのはやめてくれ
• 著名ブログだからといって内容鵜呑みにしてブクマしないでくれ
• リスティング広告、検索連動広告はちゃんと審査して少しは信頼性を高めてくれ

ということで、繰り返し言おう。

本質を見よ、思考停止するな、頭使え、流されるな。

まずはじめに言っておく。

• 僕は怖い人ではありません。いたって陽気な大阪のオっさんです。
• 立ち位置はスーツです。でも昨日はハッカーの日だったのでスーツを脱いで行きました(何か裸で行ったみたいやな...)。
• MT歴は一年ほどです。
• 女子高生に負けない速度で携帯メールが打てるというのは嘘です。
• ブログを書いたりMTプラグインを書くのはモテるためです。モテるためにMTを選んだのです。WPよりはモテるかなぁ〜っていうのが真実ですって嘘だよ。
• Hack-a-thon っていうよりむしろ Mac-a-thon みたいやなって思ってましたというのは本当です。

あーいう場[謎]で名刺交換する時の名刺なんやけど、ブログのキャプチャ入れておくといいんじゃないかなぁと思います。もしくは名刺渡すときにブログ名を言いあうのです。

- こんにちは、「Web2.0言うな!」
- あ、こんにちは、「ヒビノアワ」!

あのときこんなコメント入れやがったあいつがこいつか! とかしつこくトラックバック飛ばしやがって重いんだよゴルァとか色んな複雑な感情が微妙な空気を醸し出してくれること間違いなしですって嘘だよ :p

えーなんだかいつもまとまらないブログで恐縮ですが、面白かったので今度大阪でやりませんか Hack-a-thon。ベストプレゼンテーターには特別に串カツのソース二度づけを許可しますとかなんとか。

ちなみに昨日の成果は年度別アーカイブ (Ogawaさんのコード見てお勉強とついでにカッとなって年度の開始月設定できるようにしちゃったよ) とHyper Estraierを使った検索。MTの管理画面から検索のインデックスを更新したりエントリーの追加や削除と連動してインデックスを自動で更新するプラグイン。公開するの? って聞かれたけど...一応メシのタネなんで、、っていうか仕事しないでブログとかプラグインとかばっかり書いてるYo! ウチの社長! って言われないようにしたいのでご興味のある方はウチの会社の方へ問い合わせください。

今日はHack-a-thon。午前中のお題はできたので (っていうかやろうと思ってたのにOgawaさんが書いちゃったのでコード読みながらごにょごにょしてた) 、次は何をやるかなぁ。とりあえずページやエントリーの並べ替えかなぁ。検索かなぁ...

エントリーとかページとかカテゴリーとかブログとかの並べ替えをってのはCMSには必須かと思う訳ですが、とりあえず考え方だけ。

エントリーやページに単純に番号を振るってのでもいいんですが、エントリーやページが複数カテゴリーに属する場合とか、それぞれの中で順番制御できた方がいいなぁということで。

• ソート順を複数定義できるようにする
• そのために、ソート順のグループを作って名前を付けられるようにする
• 名前を定義するテーブルとソート順を定義するテーブルを作る(mt_categoryとmt_placementの関係みたいに
• 並び替えはエントリー、ページ、カテゴリー、ブログに対応させる

そいうことで、こんな感じのテーブルかなぁ。インターフェースがかなり面倒だな。ってかMT4の場合、バックエンドよりViewの実装の方が大変な気がする。半日じゃできなさそうなので、今日はフロント部の拡張方法について把握するとしよう。

SixApartさんにおじゃましてます。

• TechCrunch Japanese アーカイブ » Movable Type v4.0、正式バージョンがリリース

残念ながらMovableTypeのオープンソース版が出るのは今年の終わり頃になるようだ。

ちょwwwまて! 聞いてねーし! (笑)

気にならないかと言えば嘘になるけど、憶測なのかソースの根拠な記事なのかわからん書き方せんといて欲しいわ。

ということで、MTOSウォッチャーの Junnama Noda です。「開発者向けカンファレンス」でMTOSはいつ出ますか? なんて質問はしない程度に空気読めるヲっさんです。で、恒例? のmovabletype.org/opensource/ ウォッチング。

MTOSについて

• Welcome to MTOS: the Movable Type Open Source Project
• Movable Type オープンソースプロジェクト (Junnama Online (Mirror)) - 和訳
• MovableTypeオープンソースプロジェクト(補足)。 (Junnama Online (Mirror)) - コメントについての追記

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

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

Smitthi
August 17, 2007 2:08 PM

Hi Byrne,

Would I be able to modify MTOS into other languages such as Chinese or Thai?
and when MTOS will actually come out , next month?
Thanks
S

Byrne、やぁ。
私が、他の言語（例えば中国語またはタイ語）にMTOSを修正することができますか? MTOSは実際いつリリースなの? 来月かな?
Thanks
S

(中略)

Mike
August 21, 2007 12:26 PM

So does '3Q' mean September 31, 2007? Are you on target? Or is this slipping to some time in 2008?

第三クオーターが意味するのは2007年9月31日ですか? (訳者注: 9/31ってありえないし!) 現状狙い通りですか? それとも2008年になりそうですか?

Byrne Reese
August 21, 2007 12:30 PM

I really hate committing to dates until I am 100% certain, but I can confidently say that MTOS will be released in 2007. It may not be released by September 2007 however. As of right now, October 2007 seems like a more realistic release date.

100%確信が持てるまで、私は日付に縛られるのが本当に嫌いなんです。しかし私はMTOSが2007年にリリースされると自信をもって言うことができます。但し2007年9月までにリリースされないかもしれません。現状では2007年10月が現実的なリリース日と言えるかもしれません。

わりとどうでも良い追記

ところで「開発者向けカンファレンス」でほんまに「ブログ」っていう言葉聞かなかったな。MTはブログじゃないよ。ブログだと思ってると損するよ。

どんな話だったかというと、こんな話だった。

今日のひとこと

もしMT4に拡張できない部分があったとしたら、それはバグだ。

by Brad Choate

明日はHack-a-thon!

プラグインの設定

「年」アーカイブテンプレートの作成

「デザイン」→「テンプレート」→「アーカイブテンプレート」(ブログ記事リスト)を作成。名称は「busuiness_year」(名称は固定)。

アーカイブマッピングの設定

*このテンプレートは通常は再構築されません。

年度別アーカイブを再構築するには、どこかインデックス・アーカイブに<$MTRebuildBusinessYearArchives$>を指定。このインデックスアーカイブが再構築されるタイミングで年度別アーカイブが生成されます。

• BusinessYearプラグイン(4KB)

• Movable Type 4を検証 : ブログヘラルド

もしこれらの欠点が受け入れられれば、MT4はブログプラットフォームとして生き残っていくことができるだろう。しかし受け入れられなければ、少なくともしばらくの間は、プラットフォームのアプリとしてはワードプレスや別のプラットフォームに太刀打ちすることができないだろう。

なるほど。

どっちにしても、それはもはやブログではないような気が。初めてブログを作るなら、MTもWPもどっちもあり得ない選択肢だよ。はじめてブログを開設する顧客に勧めるのはWPでもMTでもないね。MT4が逆の方向(めちゃめちゃシンプルな方向性)を目指したら面白かったのになぁ、と個人的には思う。

でもね、そんなことはどうでもいいんだな。僕はMTを使う。MTの本質はブログなんかじゃなくて、Webでやりたいことを実現するための「Web application framework」なんだな。WordPressは残念ながらそうじゃない。

僕にとってのWebはビジネスで、彼ら(6A)にとってのWebもビジネスで、それでいいじゃない。結局はプロとして、何ができるかじゃね。

• Movable Typeを開発プラットフォームとして使う。
• Movable Type を開発プラットフォームとして使う (Part2)。
• Movable Type as a Web application framework.

• *プラグインにしました。

「MovableTypeな夏。」で書いたように、今週末に開発者向けカンファレンス(8月24日)とMovable Type 4 Hack-a-thon(8月25日)があって参加する予定なんだけど、色々忙しくてMT4をいぢくったりソース読む時間がないので、ちょっと助走というか頭の体操がてらに「年度別アーカイブ」が作れないかやってみた (&ProNetミーティングで質問したんだけど「ごにょごにょ...今度開発者向けMtgとかHack-a-thonとかありますので...」ってな回答だったので!)。

使い捨て気味のプログラムですがさらしておきますね。文字通り年度別アーカイブを作れるかどうかやってみよう! ってなことで書いたもの。IR系のウェブサイトなんかだと必須だもの。

MT4からは「年」アーカイブが作れる...ということは年度もできるかも!?

「デザイン」→「テンプレート」→「アーカイブテンプレート」→「ブログ記事リスト」で「新しいアーカイブマッピングを作成」、種類「年別」を選択。

コードは以下。エラー処理も再構築(スタティックなファイルの書き出し)も何もないし4月〜3月決めうち! だけど許してね。うまくいったら来週あたりプラグインになってるかも...なってるかな? なってるといいね(誰?)

#!/usr/bin/perl -w
my $MTDIR;
use strict;
BEGIN {
if ( $0 =~ m!(.*[/¥¥])! ) {
$MTDIR = $1;
} else {
$MTDIR = './';
}
unshift @INC, $MTDIR . './lib';
unshift @INC, $MTDIR . './extlib';
}
use MT;
use MT::TemplateMap;
use MT::Template;
my $mt = MT->new(Config => $MTDIR.'./mt-config.cgi');
use CGI;
my $q = new CGI;
my $at = 'Yearly';
my $year = $q->param('year');
my $blog_id = $q->param('blog_id');
my $start = $year.'040100000';
my $end = $year+1;
$end .='0331235959';
my $tmap = MT::TemplateMap->load(
{	blog_id => $blog_id,
archive_type => $at,
is_preferred => 1
},);
my $blog = MT::Blog->load({ id => $blog_id });
my $template = MT::Template->load({id => $tmap->template_id});
my $page_tmpl = $template->text;
my $ctx = MT::Template::Context->new;
$ctx->stash('blog', $blog);
$ctx->stash('blog_id', $blog_id);
$ctx->{current_archive_type} = $at;
$ctx->{archive_type} = $at;
$ctx->{current_timestamp} = $start;
$ctx->{current_timestamp_end} = $end;
my $build = MT::Builder->new;
my $tokens = $build->compile($ctx, $page_tmpl);
my $html = $build->build($ctx, $tokens);
print "content-type: text/html; charset=utf-8¥n¥n";
print $html;

http://localhost/mt/f_year.cgi?blog_id=1&year=2006

ってな具合にアクセスすると...出来てるっぽいな。

うまくいったら来週あたりプラグインになってるかも...なってるかな? なってるといいね(しつこい!?)

つまりMT3からMT4へ移行する時に、データベースのアップグレードじゃなくてエクスポート/インポート機能を使って移行したかったので (だって、せっかくだから「まっさら」にしたいじゃん)。

MT3.xの場合、エクスポート/インポート機能を使ってブログを移行すると エントリーの (カテゴリーも) basename が引き継がれません。つまり「パーマリンク」が変わってしまう。

何のための「パーマリンク」やねん! ってことで basename を引き継いで移行する方法を書いておく(さっきローカルのMT4にこのブログをエクスポート/インポートした。だってテストとかプラグイン開発とかするのにエントリー空っぽじゃなんだかやりにくいし)。

手順は以下の通り。

• もしエントリーの「使っていないフィールド」があれば、そのフィールドに basename フィールドの値を移す。
• 「使っていないフィールド」がなければ、どっかのフィールドにHTMLのコメントとかにしてbasename フィールドの値を突っ込む。
• エクスポート/インポートする。
• エクスポートインポートした方のブログで、別の場所に突っ込んだ basename を basenameフィールドに突っ込む。
• いらなくなった basename を削除する。

このブログでは「使っていないフィールド」が無かったので、以下のようなスクリプトを書いた(MTフォルダに置いて実行)。

#!/usr/bin/perl -w
my $MTDIR;
use strict;
BEGIN {
if ( $0 =~ m!(.*[/¥¥])! ) {
$MTDIR = $1;
} else {
$MTDIR = './';
}
unshift @INC, $MTDIR . './lib';
unshift @INC, $MTDIR . './extlib';
}
use MT;
my $mt = MT->new(Config => $MTDIR.'./mt-config.cgi');
my $iter = MT::Entry->load_iter({blog_id=>1});
while (my $entry = $iter->()) {
my $basename = '<!--basename['.$entry->basename.']-->';
my $text = $entry->text.$basename;
$entry->text($text);
$entry->save or die $entry->errstr;
print $basename;
print "¥n";
}

エクスポート/インポート後、以下のスクリプトを走らせる(whileの中身だけ書くね)。

while (my $entry = $iter->()) {
my $text = $entry->text;
my $pick_basename = $1 if {$text=~/<!¥-¥-basename¥[(.*?)¥]¥-¥->/};
$text =~ s/<!¥-¥-basename¥[.*?¥]¥-¥->//;
$entry->text($text);
$entry->basename($pick_basename);
$entry->save or die $entry->errstr;
print $pick_basename;
print "¥n";
}

ついでに、元のブログの方も entry_text フィールドに追加したコメントを削除。

while (my $entry = $iter->()) {
my $text = $entry->text;
$text =~ s/<!¥-¥-basename¥[.*?¥]¥-¥->//;
$entry->text($text);
$entry->save or die $entry->errstr;
}

アーカイブマッピングの関係で、カテゴリーの basename を引き継ぐ必要がある場合は、上記の方法と同時に以下の処理を行えばOK。

• カテゴリ名をカテゴリーの description にHTMLのコメントで突っ込む(上記エントリーのやり方と同じ)。
• カテゴリー名をカテゴリーの basename にする。
• インポート/エクスポート後に元に戻す。

あ、一応やる場合はデータベースのバックアップとっておくってのと、自己責任だからね!

この週末に色々? あるので、MT4をローカル環境にインストールした。以前初期不良? で修理に出していたMacBook黒が帰ってきてからずいぶん経っているので、ほぼまっさらの状態からインストールしたのでメモ。

MAMPのダウンロード

• living-e AG: MAMP - Mac - Apache - MySQL - PHP

インストールはフォルダごとコピーして起動するだけ。

/etc/hostsの編集

ローカルのテストでもドメインネーム風? でやりたい。

$sudo vi /etc/hosts
127.0.0.1       mt4local.alfasado.net

MAMPのApacheポートを80番に変更

Mac標準のWeb共有とぶつかるのでWeb共有はオフにする。

sudo vi /Applications/MAMP/conf/apache/httpd.conf
# 291,351行目
Listen 80
ServerName localhost:80

MAMPを再起動。

MTの設置

とりあえずは、http://mt4local.alfasado.net/mt とする。

ダウンロードしたMT4を /Applications/MAMP/htdocs/mt に設置。このままではmt/以下CGIが有効にならないので、.htaccessを置く。

sudo vi /Applications/MAMP/htdocs/mt/.htaccess
Options -Indexes
Options +ExecCGI
AddType application/x-httpd-cgi .cgi

これで、http://mt4local.alfasado.net/mt/mt-check.cgiで環境設定確認画面が表示されるようになる。

モジュール関係

モジュール関係は基本CPANから。ImageMagickはFinkを利用してインストール。

• Fink

* DBD::mysql のところだけメモしておく。

cpan> install DBD::mysql

エラーが出てそのままではインストールできないので、

cd ~/.cpan/build/DBD-mysql-4.005
sudo perl Makefile.PL --cflags=-I/Applications/MAMP/Library/include/mysql --mysql_config=/Applications/MAMP/Library/bin/mysql_config
sudo perl -pi -e's/MACOSX/env MACOSX/' Makefile
sudo make
sudo make install

データベースの作成

MAMPにはPHPMyAdminが含まれているので、とりあえずDBを適当な名前を付けて作成するだけ。

ウィザードから作成

あとは http://mt4local.alfasado.net/mt/mt.cgi を叩いてウィザードから設定。MySQLのポートは8889、ソケットは /Applications/MAMP/tmp/mysql/mysql.sock

まぁ...簡単とは言いがたいですが設定完了。これで開発関係を再開できます!

たまには普通に書評なぞ。といっても古い本だけど(たまたま今日読み返した)。

この本が書かれたのは1996年。既に10年以上前のものである。著者のクリフォード・ストールは天文学者なのだが、ローレンス・バークレー研究所にいた時にハッカー(当時の表現)の追跡のおかげでネットワークセキュリティの専門家と言われるようになる。この時の事件については彼の最初の著書「カッコウはコンピューターに卵を産む(上) (下)」に書かれており、この本は世界的なベストセラーとなった。

エントリーの標題の「インターネットはからっぽの洞窟 (原題 : Silicon Snake Oil -- Second thoughts on the Information Highway)」はストールの2冊目の著書である。

この本(日本語訳 : 倉骨 彰氏)のカバーにはこうある。

インターネットで仕事が変わり、社会が変わり、世界が変わる−でも、本当にそうなんだろうか?

題名からも分かる通り、当時の既に過剰とも言えるインターネットブームに対して負の側面を当時のネットワークの「ヘビーユーザー」であった著者が指摘したものだ。

もちろん10年以上も前のことであるから彼の主張や当時懸念されていたことの多くは現状解消されている。インターネットでのショッピング(決済)や優秀な検索エンジンの登場、書籍を探すのも随分簡単になった。

ところが、ネットワークについて無知な学者が書いたインターネット悲観論ではないがゆえに現在のネット社会について示唆的な記述が多く見られる。

実は何ら解決していないのが現在のインターネット社会じゃないか、という見方もできる(そういう表現が多くある)。

僕はたまたま今日埃っぽい本棚からこれを取り出してそれこそ10年ぶりにぱらぱらと読んでみた。以下少しだけ引用する。

モデムにご主人をとられてしまったジェニーが教えてくれた。(中略)「でも、デービットに比べたらまだましかもね。彼、私の友達なんだけど、毎晩3時間もネットワークするようになっちゃって。奥さんもいい人で夫婦仲も良かったんだけど、彼をネットワークにとられたと感じて離婚しちゃったのよ。」

誰でも意見を自由に発表できるというのは本当だが、ネットワークでは誰もがいっぺんに好き勝手なことを言いはじめるから、真面目な議論などかすんでしまう。

ネットワークユーザーの中には極端な意見を述べる人が多く(中略) まともな議論になかなか発展しなかったりする。

(中略)

まともに始まった対話が、フレイムウォー (侮辱合戦、誹謗中傷合戦) にまで発展してしまう割合は驚くほど高いのだ。

コンピューター自体の演算速度は速くなっているのに、プログラムの実行速度は遅くなっているのも解せない。

その他にもジャンクメールの話とか、メールが増えすぎたがフィルター使うと大切なメールまでフィルタリングされたりしないか気が気じゃない話とか、ネットワークや電子メールをコピー＆ペーストした論文に質の高いものがあるのだろうか、とか...

結局のところ、インターネットとはいっても根本のところでは何も進歩してないんじゃないかと思うような指摘が多くあって、楽しめるというのもおかしな話だが、結構考えさせられる。

ことインターネットについて言えば10年前に書かれた未来予測を読む価値はあまりないように僕自身感じるけれど、この本については (特に) 若いIT/Web業界の人は読んでおいて損はあるまい。送料はともかくユーズド (amazon) なら安いものだし。

• Hiisi Proxy 開発日記: スパムブログ対策はないのか？

ただし、最近はアフィリエイト狙いなのか、単にキーワードばかり羅列しただけの「スパムブログ」が多く引っかかって閉口しています。 Technorati による検索結果の方がスパム数は少ないけど、ヒットするエントリが少ないから単純に Technorati の方が優秀という訳にもいかないし。

テクノラティは結構マメにスパムを排除していると思う(感覚的なものですけどね)。どこまで機械化されているのかわからんですが。

テクノラティのブログランクを見ているとそんな感じがする。順位は相対的なものなので上下するのはあたりまえだろうが、リンクされているブログの数やリンクの数がわりとマメに増「減」しているのだ。

いずれにしてもスパムブログ対策ってのは昨今の重要テーマであることは間違いない。検索エンジンのノイズ、トラックバックノイズ、コメントノイズ、ブックマークノイズ、そしてもちろんスパムメール、ウェブ/インターネットは雑音だらけである。

そして、サービス提供者はCaptchaを導入し、視覚障害者はサービスを利用できなく(あるいは極端にしづらく) なっていく。

「イタチごっこ的な対策ではない何か」はあるのか?

多分そんなものは無いのだろう。ただ、スパムを解析するアルゴリズムの研究とそれを突破するアルゴリズムの研究とかは置いておいて別の方法も考えてみたらどうか。

例えば「スパマーの収入源を元から絶つ」方法。

例えばGoogleにとって「スパムブログを検索結果から排除する」行為と「スパムブログに貼られたAdSenseのアカウントを剥奪する」行為のどちらが有効な手段だろうか?

*収益とユーザーの批判を気にしたら、まぁ後者の方法はとれないんでしょうけどね。

また、サイトに表示される広告の質も疑問である。

• ミク○ィで毎月○○円稼ぐ方法
• 携帯アフェリで月○○○円稼ぐ
• 元ニートが○○○円稼いだ方法とは?
• アド○ンスで○○万円稼ぐ

で、あんまり露骨なのは嫌なのでフィルタリングする。するとGoogleからご丁寧にメッセージが来る。

システムでお客様のサイトを確認しましたところ、下記の方法を実行することでより多くの収益を獲得いただける可能性があります。
フィルタにより、サイトの収益となる広告が除外される可能性があります。

Googleは間違いなく各種スパムを排除する優秀なアルゴリズムをもっている企業であろう。ところがGoogle自身の収益源である「広告」においてその真偽性や質によるフィルタリングはかけられていないようだ。

別にスパム云々ではないケースだが、以前広告 (内容は公共的なもの) をGoogle、Overtureに出稿した時、GoogleはノーチェックでパスしたがOvertureのチェックは結構厳しかった。

アフェリエイトにしてもAdWordsにしても、審査を厳しくして違反行為を取り締まることにこそ重点を置くべきでないのだろうか? そっちの方が余程効果がありそうなものだ。

もちろん、Googleが「ミク○ィで毎月○○円稼ぐ」広告をユーザーの利益につながる広告であると本気で思っているのであれば話は別だが。

それとも本当に「自作自演なのだろうか?」

• スパムサイトの増加はGoogleの自作自演か?

...などというエントリーに広告を貼付けると一体どんな広告が表示されるのだろうかね?

違う、我々が欲しいのは電源が長持ちして熱くならない携帯電話だ。

「ワンセグ」なんて要らなくね? 重さとか大きさが倍だっていいぜ! これ本音。他にも、

違う、我々が欲しいのは「題名」と「内容」と「投稿ボタン」だけのシンプルなブログソフトだ。

とか、「シンプルさ」を追求するところからヒット商品やサービスが生まれるかもしれない。

Movable Type4をベースにしてウェブサイト制作・運用のための高機能CMSを開発しよう

Movable Typeを利用したサイト制作やウェブアプリ開発なんかをこの1年くらいでかなりやってきたのですが、これまでは社内でサイト制作のための色々な独自のプラグインとかCMSテンプレートとかを作って使っていました。MT4がリリースされたこと、当社内に色々なノウハウが蓄積されて来たこと、当面受注済みの案件でMTを使う方針になっているものが少なからずあることから、『MT4をターゲットにした「高機能CMS」を作ろう』プロジェクトが社内で進行中です。

完成したあかつきには、当社内で制作する各案件で使う他、公開しちゃっていいじゃない! 的なものは一部公開するかもしれませんし、ニーズがあればパッケージで販売するかもしれません。MTOSが出た際には、MTOSベースの何かとしてリリースするかもしれません。

で、どうせ作るのだったらいっそ「そのプロセスを公開して、こんなものが欲しいとかそんな意見があれば吸い上げてみたら面白いんじゃね? 僕たちのような制作現場の制作者のニーズを集めてこそ良いものが作れるんやし」という考えで、今社内MLでやりとりしている内容をオープンにしちゃいます。

このやり取りの中で出てくる「PowerCMS」というのが当社の社内で使っていたMT3.3用の(非公開の)プラグインセットです。フィールドの拡張やエントリーの並び順制御、エントリーの複製とかエントリーのひな形を作れたり承認フローが組み込まれています。

以下のエントリーでキャプチャとか一部見られます。

• My MovableTypeのご紹介。
• MTのプラグインを書く10の理由。

ちなみに、携帯(モブログ)完全対応とか高速全文検索なんかは基本既に出来ているので話題に上がっていません。

まずは僕から社内MLに投げた一通のメール

＞各位

野田です。お疲れさまです。

MTベースで作成するCMS系案件が今後増えて来ます。というか、意図的にそういう営業というか情報発信を行っているせいですけど。

すべてをゴリゴリ開発するのはいかにも効率が悪いよな。
そこで、以前から話していたように、「マークアップエンジニア＝MVCのV担当」相当のスキルと知識があればCMSが顧客向けにカスタマイズできるプラグインセット（以前作成していたPowerCMSプラグインのMT4向けさらに強化されたもの）を作りたいと思います。

そこで、

• まずはどんな機能が制作者として欲しいのか
• どんな機能があればクライアントは喜ぶのか
• どんなものだったら他の製品と比較して優位性があるのか
• どんなものだったら当社の優勢性が活きるのか

についてまずはアイデアフラッシュをメールベースでやりとりしたいと思います。

PowerCMSにあった機能としては、

• フィールドの分割
• エントリーのテンプレート化機能
• 承認フロー
• エントリーやカテゴリーのソート機能(Drag&Dropは欲しいところ)
• アップロードしたファイルの管理(エントリーとの関連付け、公開・非公開の設定)
• エントリーのプレビュー機能

今後欲しいもの

• 「付箋」機能(修正指示とかを付けられる)
• 簡易スケジューラー(以前**の案件で作った施設予約・管理みたいなインターフェイスで各スタッフのスケジュール共有ができるもの)
• 完璧なファイル管理(アップロードしたファイルだけでなく、再構築で吐き出されたファイルも管理できる)
• (機能ではないが)高速化のためのソリューション
• 認証付きページが簡単に作れるインターフェイス
• 複数ブログの連携(同時再構築)機能
• エントリー以外のプレビュー(インデックスアーカイブとか日付/カテゴリーアーカイブもプレビューできる)
• 年度別アーカイブ
• 各ブログへの掲示板やメーリングリスト機能
• 簡単なファイルアップロード
• より賢いWYSIWYG

できればファイルアップロードや並べ替えはAjaxだけじゃなくてFlexとかを使ってFlashによってすごく使いやすいものにしたらどうかなぁ。

まずは各人が欲しいものをMLベースでやりとりしましょう。

以下、各スタッフが思い思いに好きなことを

地味な機能ですが

<MTIfPageDirectory directory="foo"></MTIfPageDirectory>
<MTIfPageParentDirectory directory="bar"></MTIfPageDirectory>

のようなタグが欲しいです。
エントリーではなくページを作成するときにカテゴリーが存在しないため、
テンプレートの分岐はタグを使用することになります。
タグはエントリーとも紐付いてしまうので、
できれば特定のディレクトリで分岐できるテンプレートタグがあると便利かと思
います。
また、「親ディレクトリが○○の場合」の分岐もあると便利かと思います。
（Alfasadoのサイトはタグで分岐しています。）

ひとまず一つ希望です。

・簡単なファイルアップロード
に含まれているかもしれませんが、
画像などのファイルアップロードを複数同時にできるとすごく便利だと思います。
それも、一つ一つ「参照」で選ぶのではなくて
がばっと選択してドラッグドロップできるのがいいと思います。
（FTPと同じくらいの使い勝手）

例えば**様の案件などでは「イントラでの知識の蓄積と共有」がテーマとして大きな比重を占めていることもあり、掲示板という路線で行くわけですが、これに関連し、ユーザ個々人が参考になった掲示板の発言をワンクリックでどこかにとっておく機能があれば、少なくともこのテーマ上では役に立つような気がします。

googleの「メモをとる」に相当する機能です。
google上ではクリックミス以外でこの機能に関わったことはありませんが、いちいち掲示板を見に行って、過去に見た発言を探したり、エディタにコピペしてローカルに保存するよりは手間が省けると思います。
もちろん、個々人が判別され、とったメモを閲覧するマイページが存在することが前提となりますが…

PowerCMSでも、「エントリーテンプレート」ってありましたけど、エントリーのひな形を視覚的にサムネイル一覧から選択して新規投稿とかできると良いですよね。

他に、「付箋」や「並び替え順」**さん指摘の「ファイルアップロード」の件で欲しいのは「Drag&Drop」ですよね。

特にファイルのアップロードについては、現実的にブラウザのセキュリティ制限等から難しいところがあります。

そこで、

・アップロードはZipアーカイブ等で一時ディレクトリに一括アップする
・ブラウザ上でエクスプローラーっぽいインターフェイスでDrag&Dropで登録していく

というような発想でできないでしょうか。

ところで、やっぱ、アクセス解析は要るでしょうねぇ...

加えて、検索ログビューアがついていれば
ユーザの挙動の把握については完璧ですね。

**の案件で使っているHyperEstraierのように、**さんの**にログを吐き出させて、検索結果のアンカーにパラメータをつけてクリックログをとるような感じで。

ないとすごく不便とかそういったものではないですが、DreamweaverやFlashのActionscript欄のように、入力しているタグの属性を補完して
くれる機能が欲しいです。

エントリー内容のエディタで<a まで打ったら、<a [href=]のようにツールチップで出てきて、タブやエンターで選択してで補完できるものです。

タグ全部を打つのが、間違ったり面倒くさかったりするので、個人的にあったら便利かなあと思います。

さて、何か欲しいものありますか?

とまぁ、こんな感じでまずは好きなことを言いあっています。一応全員が何らかの役割を担うということで担当割り振りは済んでいます。

さて、もし何か「こんなものがあれば便利なのに!」ってなことがあれば、コメントなりトラックバックなりブクマなりで列挙してもらえればいいかなぁ。もちろんやるかどうかの判断はあくまでウチの都合なんですけど。

Nakedがじわじわ?来てるので改めて紹介。というか何をやっているかが分かりやすいようにサンプルページを作ってみた(CSSと画像をオフにする以外特別なことをするのかな? とかいう反応もあったことだし)。オリジナルと変換後を具体的にHPRとかに読ませてみて欲しい(誰か音声ファイルとか作ってくれないかな?)。読み上げ向けと他のモードの違いとかも是非試してみてください。単に画像切ってるだけじゃないので。

じわじわ...

• Naked (del.icio.us)
• Naked (はてなブックマーク)
• Naked (Twitter 検索)
PDFをテキスト化するツールNaked (kuruman.org > Kuruman Memo)
• 友加の日々の記録:ありがたい検索エンジン

サンプルページ

• Naked変換用サンプルページ(オリジナル)
• Naked変換用サンプルページ(読み上げ向け変換後)
• Naked変換用サンプルページ(携帯向け変換後)
• Naked変換用サンプルページ(ルビ振り変換後)

実は、このプログラムを書いた僕自身は本職のプログラマではないしどっちかと言えばマークアップとかアートディレクションとかが本来の立ち位置である人間なのでして、このエントリーに書いた(5は別にして)「正規表現」とか「Perl」とかを覚えるとこんなものが作れるのです。

• マークアップエンジニアが次に取り組むべき5つのテーマ。

でも、むしろこれを作るのに必要な知識ってのは、Perlや正規表現よりも「どんなHTMLが読み上げにくくて、音声ブラウザユーザーやスクリーンリーダー利用者はどんなところに困るのか」という部分の知識です。で、この知識に強い人たちこそウェブアクセシビリティとかに配慮してHTMLを正しく書こうと思っている人とかウェブ標準とか大切と思っている「マークアップエンジニア」の人たちなのではないかなぁ。プログラムなんて実現のための手段でしかないし。

Nakedのコンセプトというか何をやっているかは以下のエントリーに殆ど書いてます。イケてないところも沢山あると思うけれど、「ここがイケてない」と思うそこのあなた! 有用なアイデアや確かにイケてないところがあったらまだまだ改良して行こうと思うのでひとつ宜しく。

* 一応言い訳しておきますが、このブログは駄目です。汚いし、突っ込まれるところ沢山あるのでそこはまぁ大目に見ていただけると幸い。

関連エントリー

• ウェブコンテンツ・テキストバージョン・ジェネレーター(Naked Beta)。
• 音声ブラウザと相性の良いHTMLを作る(1)。
• 音声ブラウザと相性の良いHTMLを作る(2)。
• 音声ブラウザと相性の良いHTMLを作る(3)。
• 音声ブラウザと相性の良いHTMLを作る(4)。
• 音声ブラウザと相性の良いHTMLを作る(5)。

ちなみに、ウチの会社でリニューアルなんかの仕事を受けた時には、まずこんな感じで既存のコンテンツをてきるだけらくちんな方法でクリーンアップして再利用できないか考えます。あとはうまくMTに放り込む方法を探ります。

と、まぁこんなことやってる制作会社やってます。だから、ね、ヲチはこちらね。宜しく。

• マークアップエンジニア募集。

あれこれブログに書いているわけですが、単純に今日一番嬉しかったのは実はこのエントリーです。

• ありがたい検索エンジン

某SNSでのやりとりをきっかけに、自分からお願いして「マイミク」になっていただきました(この時点で既に「某SNS」じゃねぇな)。目から鱗っていうか、実際にウェブをどう使っているのか、どんなサービスとか技術とかが役に立つのか、色んなヒントをもらいました。

StrictだとかValidだとかが重要なわけではなくて、本当に「使う人にとってどうなのか」が知りたいってのが作り手の本当の気持ちなわけです。だから、現場で認められないとかクライアントがわかってくれないとか上司がわかってくれないとかブロゴスフィアで批判されたってのは実はつまらん話であって、本当に自分が大切だと思っていることがあるのだったら、時間を捻出して何か作ってみよう。

そこから得られるものこそが大切で「作り手としての自分」を進歩させてくれるものはそれ以外にはないからです。

実際にはブログを書きはじめたのは3年ほど前なんだけど、当時は『「ブログ」流行ってるし書いとかないといけねぇ』くらいの気持ちでアカウントのあったニフティのココログで書きはじめたわけだが(一応その頃は30代でしたけど)。

* で、この数字(3万PV/月はこのブログのアクセス数というか現状です。アルファブロガーってのにはほど遠いですが、ベータブロガー2.0(?)くらいの数字ですかね。

真面目に書き始めたのはサーバー移転してMTが仕事の中に入って来てから、この2月からだな。つまり半年くらい。

そんでもって、更新頻度が急激に上がったのが今年の4月。3月に仕事のピークが来るからそれが一段落付いてから。まぁとにかくブログ(MT)をいぢくりながらあれこれ書きまくって来たわけです。

カテゴリーとしては、Web業界の人でアクセシビリティの人でMTの人で40過ぎたオッサンで...てなところに属しているわけですが、ほぼ毎日ブログを書いて見えて来たことがあります。で、そのことを書いてみようかと。

1.毎日書く

読むのがしんどいとか言われたこともあるのですが、読む読まないは読み手に任せておけば良いわけですし、とにかくまずは毎日書くことです。書くことなんていくらでもある筈です。なにせ40年程生きている訳ですからね。

2.毎日書けるテーマで書く

とはいえ、書けることって限られている筈です。自然に書けること、例えればメールを一通書くような感覚で書けるテーマ、つまりあなたの仕事とか生活とかに近い身近なテーマでまずは書きましょう。

3.書いて良いことと悪いことをわきまえる

仕事や生活に近い身近なテーマだからこそ、書けないこともあるでしょう。仕事上の機密事項とか。もちろん書くべきでないことは書かないべきです。

4.書いて良い「ギリギリ」を狙って書く

書いてはいけないことでこそ面白いネタが転がっていて、それがあなたのブログを面白くしてくれるわけです。でも書けないこともある。大人の事情ってやつです。だからこそ「わきまえた」上で書けるギリギリの線を書きましょう。世の中「白か黒」ではなくて「殆どがグレー」ってなことをわかっているのが大人なわけです。そしてグレーな部分が面白いのです。

5.自分のイタさ加減をわきまえる

40歳になってブログを書きはじめる訳ですから、その時点で既に「イタい」存在です。この世界では自分より若い人たちが殆どです。だからこそ自分のイタさ加減をわきまえて、逆にそれを武器にすれば良いのです。

6.実世界の自分の価値を捨てる

既に書いたことですが、「年功序列」な世界ではないわけです。むしろ自分の子供くらいの連中が「α」なことも多い。説教くさいオっさんは嫌いだったですよね。若い頃は。

7.若者に敬意を払う

だからこそ、郷に入っては郷に従う。この世界の先輩として敬う気持ちを持ちましょう。

8.ユーモアとか明るさを忘れない

何を書いたって良い訳ですが、ストレートに伝えたかったことがストレートに伝わるとは限りません。自分のイタさ加減をわきまえつつ自分の主張を述べたければ、ユーモアを忘れないことです。ユーモアは炎上の火種を和らげてくれます。

9.適度に絡む

これはまぁ普通のことかもしれませんが、ウザいと思われない程度にこの世界の実力者に絡んでみましょう。コメントとかトラックバックとか。向こうから絡んでくるようになればしめたものです。

10.愛!

最終的には「愛」を持って参入すること。このひと言につきます。ブログを書くことで生まれる出会いがあるし、新しい自分の居場所が見つかるかもしれません。だからここ(ブロゴスフィア)は「愛すべき場所」です。

さぁ、今日からあなたもブログを始めませんか?

最近のエントリーへの「反応」に「反応」してみる。

* タイトルが釣り気味ですね。すいません!

「スルー力なんて実は要らない」とか書いちゃったわけだが、昨日書いた2エントリー(派生してその他のエントリーとかにも)に対して色々と反応もらっちゃったので、ちょっとマジレスという程じゃないが反応してみる。昨日今日は特にネガティブコメントとかなかったけどね。

とはいえ、ブログに対するコメントもトラックバックもなくて、チェックしたのは「はてなブックマーク」 「del.icio.us」 「livedoor クリップ」「Twitter」 あたり。とにかくまぁこれがウェブにおけるコミュニケーションの現状だったりするのかなぁ。

もちろん、チェックっていっても各ページの検索結果をRSSリーダーに登録しておいて移動中とかに携帯電話からチェックしているわけですが。

「コミュニティ2.0は叱ってくれる大人のいない世界」への反応から。

こういう権威主義的な人向けのコミュニティはそこそこ需要あるかも。村長じゃなくて総統がいるような。女王様でもいいけど。／権威を可視化する仕組みが肝か。

う〜ん、権威主義が頭にあったわけではないのだが。ただこんな風にコミュニケーションが分散型になってしまうと「発信者対読者」という構図ではなくなっているわけで、その「コミュニケーションの場」に「座長」がいないし「叱ってくれる大人」がいないのだよな。それで、これまでのウェブのコミュニケーションってのはイタイ質問をすると「おめぇそんなんじゃ駄目だ」とかなんとか言われるというような失敗というかイニシエーションというかそんな過程を踏んでからコミュニティの一員になっていくようなところがあったのだが、今はそんなのが無いもんな。

「女王様」ってのはいいな。その発想は無かったわ。例えば「はてなブックマーク」には女王様がいて、ネガティブコメントとかにピシッっとお仕置きをするわけだ。

そうは言ってもマジレスする人が今のWWWにどれだけいるのやら

あんまりいないのかな。いなくなっちゃうことが損失だとか何とか言ってる人がいるけど、イメージとしてはそのあたりの人じゃないんだよな。コメント書いている人の属性にもよるんだけど、例えばギークな若い人たち (「コードも書かない人に言われたくない!」とか言ってる連中) に対する dankogaiさんとかね。そんなイメージかな。マジレスというよりもピシッと言って終結、みたいな感じね。

もちろん僕が目指すオッサン像もそのあたりにあるのだけど(danさんとかより僕のほうが随分オッサンやけどね)。

「マークアップエンジニア募集。」への反応から。

すてきなバズマーケ

「コミュニティ2.0は叱ってくれる大人のいない世界。 」を書いたきっかけってのはエントリに書いた通り田舎での先生方との会話なんだが、頭の奥の方にあるのは例? のCSSer騒動なのはいつもこのブログを読んでいただいている方なら想像できるのかもしれないけれど、最近僕の心の中にあるのは

何でお前ら黙ってんだよ!
いつからそんなに大人になったんだよ!

ってな思いなんだな。

* 何で俺がこんなにムキになってんだろ。どっちかと言えばプログラマにも近い人種なのにってのは不思議だったりするわけだけど、少なくともウチの会社にマークアップ・エンジニアっているわけで、そこに文句付けられたような感じなのかなぁ

だからこそ、そんな黙っちゃうような業界のリーダーたちに対してCSSerが抱いている閉塞感とかそういうものに対して、俺は違うぜ、そこに価値を見いだしてるしもちろんその先も考えてるからこそウチに来てみない? というようなエントリーを上げたわけですよ。「すてきなバズマーケ」ってのは褒めてもらってるわけですが(多分)、だって混乱はチャンスだもの。良い人材はいつだって喉から手が出るほど欲しいじゃない。この業界最終的には人材しかないわけだし。ウチみたいな零細企業だって一人採用するのにうん百万円ほどかかるわけだからブログのエントリー1つで良い出会いがあったら って考えたら (あるいは結果として良くない出会いであったにしても) 今このエントリーを書かなくてどうする! って思ったのだ (むしろちょっと遅かったと思っているくらいだ)。

だから、これで良い出会いがあったなら騒動に感謝だな。でもまぁこのエントリーだけがこれだけの反応に繋がったわけじゃなくて、一連のエントリーが伏線になってこのブログの読者にCSSerが増えて、という流れがあるのは織り込み済みである。だからタイミングを狙っていたわけだが、お盆の前が忙しくて夏休みは呆けてしまったからちと遅れたかも。

まぁ「応募したい!」的なコメントも付けてもらってるけど、そんなにタイミング良く「今」仕事変わろうという段取り付けてる人ばかりじゃないと思うのでもしこれをきっかけに応募いただいた人がいたら、できるだけ多くの人と会って気長に選考したいと思ってます。

だから、真剣な応募もそうですけどウチの会社とか僕に興味があって一回話してみたいっていう方がいたら気軽に連絡くださいませ。

応募資格: あなたの採用プロセスや採用の件をブログのネタにしても構わない! という広い心。 → 今後、ブログにネタとして出てくるのかな

どっちかと言えば、このページ(ウチの会社の求人ページ) の右側の4コマとあわせて見ていただいて反応いただきたかった!

「SEO言うな!」への反応から。

続いて、これはまぁ昨日今日の反応ではなく少し前の話だが。

一理あると思う。でも、そうするとそのうちアクセシビリティ言うなっていう議論もあるか。HTMLは元々アクセシビリティを重視しているんだから、それをメインにするってどういうことよ？みたいな。いや、言い過ぎか。

いや別に言い過ぎなんてことはないし気にするこたぁないんだけど、状況的にはSEOの方がとにかく「嘘っぽい」「偽物っぽい」匂いを発散している会社が多い気がするんだな。アクセシビリティの方がその辺はまだ少ないというか。というよりも「SEO」の場合、すごく「商売」と直結しているから「本質」を見ずに小手先のテクニックとか検索エンジンを欺くというかギリギリのところを突いている会社も多いだろうし、そのあたりに対する何だか釈然としない思いがあるわけだ。

あと「アクセシビリティ」については、ウチのサイトとかこのブログを「点」ではなく「線」で見てもらえればわかると思うけれども「アクセシブルなサイトを作る」制作会社から一歩二歩進んで行こうと思って日々精進しているわけです。例えば音声系UAの実装の半端さをカバーするためのゲートウェイとかHTML変換エンジンとかそのエンジンのCMSへの組み込みとか。

そういう点で、業界をリードできるだけの実装力や開発力を持った会社になりたいと大真面目に思っていて(思っているだけじゃなくてあれこれ取り組んでいて)、その取り組みと身に付けた力に相応しい情報発信をして検索エンジンから相応の評価が得られればそれで良いわけで、そのためには会社のウェブサイト自身もそしてこのブログにおいても情報をアウトプットしていかないといけない。

だからリンクを買うとかどうこう考える前に「アウトプットせよ」と。またアウトプットするにしても実体の伴わないものをアウトプットしようがないわけで、ウェブサービスを立ち上げたりソフトやプログラムを公開したりといったアウトプットも同時に行うことにしたのだ。そしてその結果が現れて来ているんだな、ということが書きたかった。

もちろん、こうやってアウトプットしてそれが検索エンジンの評価に繋がっていることを実感できるからこそ顧客にビジネスブログとか提案できるわけです。自分でブログも書いてないで顧客に「書きましょうよ」って良く言えるな、と。またどの程度書いてどんな効果が得られるかを実感したこともなくて「Movable TypeはSEOに良くて」「ビジネスブログで発信しましょう」ってどの口が言う!?

「Another HTML-lintとかマークアップエンジニアとか。」への反応から。

このエントリーは何だかちょっと自分でイタい。嫌な気分の時に酒とか飲んでブログ書くもんじゃねぇな、と思ったわけで案の定これについては (大人しい方だろうが)ネガティブなコメントが付いたわけだね。

何が言いたいのかわからない

ということで、これについては整理して言いたいことを改めて書き直した。

• マークアップエンジニアが次に取り組むべき5つのテーマ。

rss読めなかった
→http://farm2.static.flickr.com/1408/1048700431_5d1e18791f_o.png

ブクマコメントだけじゃなくて某SNSとかにも書かれたな、これ。正直なところムっときたりしたのだけど(晒して面白いかよ! ってね)、このブラウザのXMLパーサのエラーは実はこのプラグイン(MTのtag2xhtmlプラグイン)のバグだったわけで、書いてもらったおかげでバグ一つ潰せたよ。だから「ありがとう!」ってな感じになっちゃって。たかだかブログで「クレームは宝」ってな奇麗ごとを言うつもりはないけど、ネガティブな反応に気づきがあることも多いし、あぁこういう書き方が不快になるわけだな、っていう気づきや学びは別のところで役に立つことも多いよ、マジで。

「MovableType4のWYSIWYGエディタが生成したHTMLをクリーンアップするプラグイン(グローバルフィルター版/IE対応版)。」への反応から。

ここだけはちょっとマジレスしてみよう。

B, I, U, STRIKE, FONT 等の物理要素をそれぞれ STRONG, EM, INS, DEL, SPAN要素に置換します → U を INS に変換するのはダメでしょう。たまたま、見た目が同じになる実装が多いだけで、他の実装もあり得ます。

そんなことは言われなくても分かっていて、だからこそ「簡易的な対応ではありますが、主な視覚系UAのデフォルトスタイルが同等な論理要素に置換します」と書いているわけだしライセンスを「パブリック・ドメイン」って書いてるじゃねぇか。自分の実装方針にあわせて修正して使ってくれればいいわけだよな。違うか!?

って書くと「スルー力の無いオッサン」になるわけだな。まぁ何を書いても良いと思うけど、ついカッとなって何か書いたりしちゃ駄目さ(俺もね)。だからこのプラグインは自由に改編してください。

「Web制作はサッカー型で行こう。」への反応から。

最後にこれ。どうでもいいツッコミって実際にそう書いてあるけど。

「BK」よりも「DF」の方がしっくりくる（どうでもいいけど）。

そ、そうだったのか! って確かにBK(バックス)ってしっくりこなかったんだよなぁ。そうだよなぁ、DFか。オッサンが小学校の時はバックスだったんだよ! (←これこそ、どうでもいいわな)

長くなったのでイタいオッサンの台詞っぽく締めてようと思う。

お前らどこに何書いたってちゃんと見てるからな!

今後ともひとつよろしく! :-)

募集要項

ついカッとなって募集する。

何年かぶりにお盆に普通に墓参りをしてきた。

鳥取市と宮津市という共に日本海側の町というか村のようなところで普段話をしないような生活圏も仕事も全然違う人と話ができて新鮮というか、色々と興味深かった。

昨日は田舎で先生をしている方お二人の会話に混ぜてもらった。お二方とも僕よりも一回りほど年上の方だ。その中でちょっと自分なりに感じたことを書こうと思う。

大学を出た新任教師が田舎町の学校に赴任してくる。先輩教師(先輩というよりもむしろ親くらいの人、以下先生と表現する)が下宿先の荷物の整理を手伝ってやる。「大家さんにちゃんと挨拶しとけよ」という。
翌日、学校へ出て来た新人に「ちゃんと挨拶したか?」と聞くと「まだ行けてないんですよ」という。先生は叱る。物事の大切さや優先順位がわかっとらんのだ、と。

この話は一つの例なのだが、「最近の若者は...」のように世代の問題ということもできそうだし、現代社会の一般的な(つまりは地域や周囲との関係が希薄であるといったような)問題だということもできるだろう。もちろん都会と田舎という地域の差もあるかもしれない。都会ではこういったことに対する必要性が比較的薄い。「都会育ちの最近の若者」にすれば、何でこんなことで叱られるんだろう? くらいに思っているのだろう。

先生曰く「親や大人がちゃんと叱ってやれるかどうか」が重要だという。うん、うんと頷きながら聞いていたのだが、後でふと思ったことがある。この話が僕の頭の中でネットにおけるネガティブコメントやネットイナゴの話と何故だか繋がってしまったのだ。

* 帰りの列車の中で携帯電話でRSSをチェックしていて、このエントリーを読んだことと関係しているのかもしれないけれど。

• 僕がネガティブコメントに喜んでしまう5つの理由 | 住 太陽のブログ

コミュニティ2.0は叱ってくれる大人のいない世界

ネット上に形成されるコミュニティにおいて、コミュニティ1.0の時代はまだ「叱ってくれる大人」がいた。叱る理由がどこまで正当かは置いておいて。「過去ログ読め」「マルチポスト禁止」等は一例だが「タコは育てよ」という合言葉がLinuxの世界にあったように、コミュニティ1.0においては「イタい」発言をしてしまった者に対して「叱ってくれる大人」が存在した。

コミュニティ2.0では「叱ってくれる大人」は存在しない。というか、「叱ってくれる大人」が入って来られない場所にみんなで移動してしまったのだ。

メーリングリストのような一カ所での対話から個々のブログという分散型のコミュニケーションへ、そしてブログのコメント欄もトラックバックによる言及もだんだんと使われなくなり(スパムの問題もある)、ソーシャルブックマークやSNSや一行ブログ(?) で誰かを罵ったり卑下したり間違ったことを発言しても誰も叱ってくれない(そもそも誰を叱って良いのかもきわめて分かりにくい)。コミュニティ2.0は座長のいない会議のようなものだ。

だがしかし、少数ながらそんな大人は存在する。ネガティブコメントに切れてマジレスするオッサンたちである。そう、僕のような(笑)。

スルー力なんて実は要らない

スルー力ってのは、若者を叱ったら逆切れされて金属バットで殴られてイタイ目にあうのが嫌だから目をつぶって何も言わずに無視する力のことだ。

だから僕はスルー力の無いオッサンが好きだ。そして何言われてもアウトプットを辞めないオッサンが好きだ。そういう「痛い」オッサンがいなくなったらコミュニティ2.0は随分殺伐とした世界になってしまうだろう。

なんてことを僕よりも一回り年上の先輩オッサンたちと一升瓶を囲みながらぐだぐだと話していた後に大阪へ帰る道中「明日からまたネットの世界に戻るのか」などと考えている時にふと思った今年の夏休みであった。

Web2.0言うな! ってのは実は会社の今年の年賀状に使ったコピーなんだけど、結構インパクト強くてこれに勝てるキーワードを来年考えられるかどうか自信があまりないのだけれど、実はもう一つ「SEO言うな!」ってのも考えていたりして。

考えていることは自然に出るもんで、リニューアルしたサイトから「SEO」って言葉が見事に消えていた...ことには実はさっき気がついた。(検索結果)

気がついたからキーワードをこれから散りばめようとは思わない。むしろこれでサイトへの問い合せとか今後の仕事にどう変化があるか楽しんでやろうと思っている。

何故「SEO言うな!」か。

「SEO」とか「SEO+制作会社」とかで検索すると出てくる制作会社系のサイトがどれも似たり寄ったりで面白くない。

いかにも「上位表示狙いました」っていうサイトに対して何だか「お腹いっぱい」な気分になるんだ。

個人的にはこのあたりが理由かなぁ。被リンクをコントロールしたりするのも何だかなぁ、という気もするし。

「SEO」以外の本来ウチの会社が力を入れているところのキーワードについても、あんまり露骨にやるのは「格好悪いなぁ」と思ってしまうのだ。

サイトのデザインをひっぱがして「裸」にしちゃうゲートウェイとかも作ったし、脱がしてみたら「何だこれ、スパムじゃねぇの」みたいに見えてしまうのも嫌だ。

もちろん、検索順位を軽視しているわけではない。どころか、いくつかの「上位に表示されて欲しい」キーワードで結構良い成績だと思うのだがいかがでしょう? (全部一位ってわけじゃないけどね。まぁいい線行っているんじゃないかと)

• アクセシビリティ + 制作会社
• ウェブ制作会社 + Movable Type
• アクセシビリティ + Movable Type
• MT + 制作会社

もちろん、それなりに上位表示されている結果のみ紹介したわけですが、実際のところ今回のリニューアルで「下がらないこと!」という方針はマークアップ担当に伝えはしたが、逆に「読み上げて"ウザい"」コードにはするな! ってのもあわせて言った (というかいつも言っているのだ)。

一方で、今回のサイトリニューアルの前後にやったことと言えば、ひとことで言えば、

ひたすらアウトプットした

これにつきる。

• ひたすらブログを書いた。
• MTのプラグインとかを沢山公開した。
• 機会があれば人前にも出た。

まぁ、こんな感じ。で、これが会社のサイトのSEOに結果として役立っているということは事実だと思う(それなりに根拠もある)。

ブログをひたすら書くことでの変化については、いずれまた別のエントリーで書いてみたいと思うが、高い予算をかけるとかスパムサイトを作るとか、スパムぎりぎりの手口で上位表示を狙うとかそんなことちょっとでも考えている方がいたら...

そんなこと考えてるエネルギーがあったら、ひたすらアウトプットしましょう!

と言うことが言いたい。

まとめ。

SEO言うな! アウトプットせよ!

これもまぁ以前勤めていた会社の社長の台詞の受け売りというか (当時と今とで自分のポジションが違うしテーマも違うから受け売りではないつもりなんだがね)。

きわめて「駄文」的なこの↓話の続き。

• マークアップエンジニアが次に取り組むべき5つのテーマ。

* あと、この話はもうこれで(多分)終わりにするね。

職種間の軋轢と言うかやり合いってのは例えば同じ会社の中での「スーツとギーク」とか「営業と制作」とか「直接部門と間接部門」とか色んなところで見られる現象で、決して「マークアップエンジニアとJavaScripter」とか「デザイナーとプログラマ」とかの構図が珍しいわけではないんだよな(同じ会社の話ではないんだろうけど)。

僕の会社のような小さな会社の場合、まぁ営業的なことやプロデュース的なことは僕しかやらないけど、少なくとも「マークアップ」については全員が何らかの形で担当することがある。

っつーか、同じことばっかじゃ「飽きる」じゃない(ってのは半分は嘘だけど半分は本当)。デザインもHTMLもCSSもJavaScriptもPerlも何だってそうだけど、「俺プログラマだからこれだけしかやらんもんね」とか「私デザイナーだからマークアップとかわかんないしやんないもんね」とかだと現実的に回らないもの。

話は全然違うけど、野球(というよりむしろアメリカンフットボールとかの方が顕著だけど) のように、はっきりと攻守、投打という役割が分かれている場合、どちらかはうまく機能するが他方は駄目みたいなことがままあって、むしろサッカーの場合だと、中澤とか闘莉王がゴール決めたり、リードされた試合終了間際に川口が敵陣へ攻め込んだり、逆に敵のCKとか攻め込まれた時に高原がゴール前でシュートボールをクリアしたりって普通にあるわけじゃん(例えとしてはかなり極端だけどね)。

Web制作のような様々な工程や技術が必要でな場合、強いのはここで言うサッカー型チームじゃないかと思うのだ。全員がオフェンスの意識もディフェンスの意識も持っているからこそ、GK→BK→MF→FWにもそれぞれ良いパスを渡せる。例え点取る技術はFWに負けてたってゴールの意識は持つ必要があるし、FWだってディフェンスの意識が必要だ。そして時には別のポジションもそれなりにこなすことができる。

但し、ポジション毎のプロ技能ってものは絶対必要なわけだ。

上手い奴はやっぱFWだよね。BKとかやりたくねー、出来の悪いのがBKだよ。俺点取りてーからFWだぜ文句あっか、みたいな子供の草サッカーでもあるかないかわかんないような論点はわけわかんなくて、誰も高原の方が中澤より偉いし中澤はBKだけじゃだめだからGKの練習とかFWの練習もやって、脱BKだよね、みたいなことは誰も言わないことは明らかなのに。

目指すのはチームの勝利であって、そのために必要な役割を全うする、そして相手が力を発揮できるパスを出すために相手のポジションの特性や必要な役割を理解したり、時にポジションを超えてカバーリングするためにサッカーそのものをよく勉強したりするんだな。

Web標準とかマークアップってのはいわばサッカーにおける「パス出し」「パス受け」みたいなもので、すごく「基本」的な部分であるからこそ「それだけやってる奴なんてどんだけいるんだ?」みたいな話も出てくるわけだが、シュート一本打たなくても勝利に貢献できるわけだし、何より

パサーにも超一流ってのは存在するんだぜ。

それに「良いパスとは何か」ってテーマだけで本だって何冊も書けるだろうし、徹夜で議論もできるだろうよ。

と、いうことも駄文的に付け加えておくよ。あぁ本当にどうでも良い話を書いてしまった。S社長、すいません!

あ、ひとつだけさっき気づいたんだけど(遅!)

マークアップだけってのは結局のところデザイナー・プログラマー・ディレクター・ライターが創り出したのをWebで見えるようにしているだけで、価値が下がるのは当然だと思います

「Webで見える」は「Webで"聴ける"」であったり「Webで"触れる"」*も含めないと本当はいけないんだ、ってことや、「GooglebotだってそのWebを見る」ってことも視野に入れておかないと彼ら(誰?)のことを理解なんて出来ないと思うよ。ってか、「見える」ってすんごい価値じゃね?

* 理解出来ることも操作できることも再利用出来ることも(将来に渡って互換性を確保出来るようにすることも) 必要だってのはWCAG2.0を見て理解して欲しいものだ。Webに関わる人ならば。

性懲りも無くまた書くとする。このエントリーは「マークアップエンジニア」に向けて書く。

* 前回何故あんな書き方をしたかというと、やっぱり書き方が見下してるというか、嫌〜な匂いがしたからだ。で、案の定そのノリで反応来るしなぁ。ちなみに僕はマークアップエンジニアではなく最近はPerlばっかり触っているスーツです。

次にやるべきは何か。結局はあなたが何者になりたいか次第だけど、あなたの周りにも左右されるだろう。それは決して (このブログも含めて) ブロゴスフィアの世論? ではなくて例えばあなたの (今の、そしてこれからの) 属している業界とか会社とかあなたの仕事仲間とかのことね。

だからこれは僕の会社や僕が属している業界の場合の話と予めお断りしておく。
また表現者になりたいのか、ビジネスとして極めたい/稼げるようになりたいのかによっても違うが、ここでは後者の話。あくまでも「あなたのマークアップエンジニアとしての仕事をさらに極めるための5つの取り組みテーマ」ということ。

1.改めて(X)HTMLとCSS。

正しい(X)HTMLとCSS、美しく、高いアクセシビリティを保って。これは言うまでもないだろう。
但し Mobile はやっておこう。無視できないよ、やっぱり。

2.テンプレート言語。

あなたの周りが PHPer だったり会社で使用しているフレームワークやテンプレートエンジンがあるのであればまずはそこから。無いのなら周囲に相談してみれば良い。Smarty でも Django でも何でも良いが、テンプレート言語を通したプログラマとの連携ができればみんなが幸せになれる。

周囲にプログラマがいない (みんながみんな分業できねぇとかいう意見もあるようだし) とか、特に指定がないのなら、 やっぱ MT::Template でしょう。プログラマが周りにいなくたって誰かが書いたプラグインを組み合わせたりすればかなりのことができる。

そして、注目すべきは MT4になってから MT自体の CMSが MT::Template (+HTML+CSS) で書かれていることだ (MT3まではHTML::Template)。顧客の要望にあわせたCMSのカスタマイズとかにも MT::Template は使える。

もちろんあなたがフリーランスやSOHOスタイルで仕事をしているならば、制作会社との共通なテンプレート言語である MT::Template をマスタしておいて損は無いと思う。僕がMTの人? だから言うのではなく、マークアップエンジニアにも比較的浸透しているでしょう? やっぱり他のテンプレートエンジンは、プログラマ側からのアプローチで作られているように見えるし MT::Template と比較して習得が容易だとは思えない。

MTの場合「触ったことがある」程度から仕事で使えるところまで行くためにやることは沢山ある。デフォルトの MTタグを使ったサイトの骨格づくりから、様々な分岐処理、プラグインを使ったカスタマイズ、さらには高速にページがレンダリングできるテンプレート・タグの設計とかまで行ければ言うことなし。ついでにデータベースの構造 (MTの「何」がどこに入っているか) も勉強してしまおう (後で役に立つ)。

問題はここから。

さて次。ここで考えておかなければいけないことは、マークアップエンジニアを自分の立ち位置 (本拠地) とするかどうか、である。

今後もマークアップエンジニアを自分の立ち位置とするのであれば、マークアップエンジニアリングが「よりパワーアップする」ようにスキルアップを図って行くべきだ。

「明日から使える」あるいは「明日から自分の目の前の仕事を楽にしてくれる」ことから取り組みましょう、ってのはすごく自然なことだから。

3.正規表現。

何らかのプログラミング言語を学ばないまでも、正規表現を使った検索・置換ができるテキストエディタ等を使えばかなり柔軟な処理ができる。結局、マークアップ・エンジニアの仕事におけるテンプレート設計以外の部分ってのは (もちろん、画像編集ソフトでパーツを切り出すとかそのあたりは別にして) テキスト処理である。ページの作成も、ページの修正も、ページのチェックも結局 HTMLとCSSというテキストファイルの処理である (時には大量のファイルを処理する必要があるだろう)。

そこで、正規表現である。サイトがCMS化されていないとき、サイト全体に修正が入ったが単純な置換処理では不可能な時、あるいはサイトのリニューアル時に旧サイトのデータを再利用する時。こんな時に正規表現という「芸は身を助ける」。

同じ理屈で、grepとかfindコマンドとがターミナルから叩けるようになっておくと「マークアップエンジニア」としての作業効率は絶対大幅にアップするよ。

4.何でも良いから言語をひとつ (但しファイルの読み書きができる言語)。

ここが一部の人と意見が分かれるかもしれないけれど、JavaScriptやActionScriptではない。いわゆるLLというやつを何か一つ先に身につけよう。

理由は正規表現のところで書いた通り。大量のテキストファイルから情報を抽出したり加工したり修正したりするケースはマークアップエンジニアであれば日常茶飯事でしょう? だったらファイルの読み書きの出来ない言語では意味が無い。つまりJavaScriptやActionScriptではなく、Perl | PHP | Ruby | Python 等のLLでしょう。これによって、クライアントが用意したExcelデータをTSVとかCSVにコンバートしてHTMLで作ったテンプレートにデータを流し込んでファイル出力する、とかの処理もできるようになる。一つ身に付ければマークアップ・エンジニアの世界が変わること間違いなし。

特に好き嫌いがなければ Perlがお勧め。

(順番にいけば既に身に付けたであろう) 正規表現が柔軟に扱えてテキスト処理に強いPerlがお勧め。Perlならドキュメントや書籍にも困らないし、もちろんオンラインに豊富な情報があるし何より CPANがある。Mac OS Xなら標準で使えるし、Windowsには ActivePerl、旧MacOSには Mac Perlもある。そして、CGIとしてサーバーサイドで動かすことも殆どの環境で可能だ(サーバーサイドで動かす場合は基本的なセキュリティのところはやっておく必要があるが)。あなたが大好きな? CSSや、JavaScriptと違ってクロスブラウザを気にする必要もないし、PHP程バージョン間の差異に気を遣う必要もない (ここで言語論争をするつもりはないですごめんなさいPHP)。

実は Perlを選ぶもう一つ理由がある。

* 誰かが「勝手に添削」してくれる等という理由ではないよ :-)

お分かりの方はお分かりだと思うが、MT が Perlで書かれているから。既に覚えた MT::Template と正規表現のスキルを活かして、自分でプラグインを書けるようになると これは強い。Web業界ならPHPも悪くないと個人的には思うが、MT/Perlという「芸は身を助ける」。

* 追記:
別にPerlを「極める」必要はないです。
ファイルの読み書きが出来てHTMLをパースしたりHTMLの構造やパターンから必要な部分を引っぱったり書き換えたりしてからまた保存する、みたいな処理やリンクチェックとかミスを見つけるのに使えるレベル+簡単なMTプラグインが書けたらマークアップエンジニアとしては充分すぎる。

5.「言語」というものに慣れたら JavaScript (→ ActionScript)へ進もう。

もちろん、getElementById('foo').style.color="bar" とかでスタイルをちょっと変えたりくらいはもっと早い段階でやっておくべきかとは思うが、優先順位としてはPerl (or 別のLL) を覚えてからで良いというか、「マークアップエンジニアが表現や演出の領域を広げる」 (JavaScript/ActionScript) よりも、先に「マークアップエンジニアを極める」(Perl) 方が、今日・明日から役に立つ。

一方、JavaScriptにはブラウザ上での「CSS(あなたの大好き? なCSS!)」を扱えるという強みはある。そう言う面ではCSSでの表現力を補ったり、CSSを書く際にスマートに書けるという「芸は身を助ける」面もある。

JavaScript → ActionScriptという流れは (言語としては) 難しくない。兄弟のようなものだから。Flash特有の部分を覚えて行けば、さらに幅が広がるだろう。

* 追記:
同じくJavaScriptを「極める」必要はないです。特にCSSをJavaScriptから自在にコントロールできるようになれば、マークアップエンジニアとしての幅が広がる。

さて、ここまで行けばディレクションというかプロジェクトの設計を担当しても、何だか今までと違った「プロジェクト設計」が出来るようになるだろう。

もちろん、順番に全部やらなくても良いし飛ばしてもよいし途中まででも良い。ディレクションとかそっちに行くのも良いでしょう。

ただ、「マークアップエンジニア」は何か「ガシガシ」とエディタで書いてページやサイトを組み立てたり、基本「作る (not 創る)」のが好きな特性がどっかにあるような気がするんだな。

ただ漠然と将来が不安っていっても、どのみち言語を覚えたって何を覚えたって技術や状況は変化するし10年後はどうだって誰も言えない。逆に、やるなら一気にやるべきだ。そう、今日から。そして、1年で何者かになってしまえ!

いくつかの壁はあるだろうが、すぐになれるよ。若いんだから (若くない人ごめん)。

ちなみに、冒頭のところ( 表現者になりたいのか、ビジネスとして極めたい/稼げるようになりたいのか) で、もしあなたが前者 (表現者になりたい!) の場合、まずはアートディレクターの目線を持つことが第一だと思う。デザインが「できる | できない」は置いておいて良い。AとBの「どちら」のウェブデザインが、「何故」優れているのかが適切に判断できる能力を磨こう。そして、どこをどう直せばもっと良くなるかを見抜いて指摘出来る力。

良いデザインや良いユーザー体験に沢山触れて、自分の眼力を鍛えること。それから表現技術を身につけていけば良いと思う。目線が低い人は仕事しててもうまくいかないが、目線が高ければ他人を使ってでも良いものができるようになるので。

さて、いかがでしょう?

ギリギリまで時間がかかったのはサイトのリニューアルのため?

中の人お疲れさまでした。

心なしかサイトが重いように感じますが、まぁアクセス多くて当然っていうかアクセス無いと逆に、ね。

• Six Apart - Six Apart: Movable Type 4 を出荷開始します

僕が心配することでもないですが、マーケットや制作者の反応はどうなんだろう。

早速カスタマイズというかCMSのバリエーションを作りたいと思っている。できれば今月末までに。ウチの会社らしいアプローチで、MTがこんな顔を持つんだ! ってなものを。内容は今は内緒。

* えー、既に書いた通り、当社のサイトはいち早くMT4を使って構築されています。今から正式版にアップグレードの予定。

すいませんタイトルまんま使わせていただきました。

• 404 Blog Not Found:どんな風に書いたところで、あなたのよう書けるのはあなただけ

「高校生のための文章読本」pp.208

1. 良い文章とは
   1. 自分にしか書けないことを
   2. だれが読んでもわかるように書いた文章

ということで、ね。

1. 良いCSS(er)とは
   1. 自分にしか書けないCSSを
   2. だれが読んでもわかるように書いたCSS

「だれが読んでもわかるように」の部分はむしろHTMLの方ですが何かっ?

* 何かこんな話題がホットなみたいなので↓

• F's Garage：マークアップエンジニアのキャリアパス
• IT戦記 - マークアップエンジニアはどこへ向かうべきか（を考えてたらカッとなって LL の資料公開）

価値が認めてもらえんとかBlog界隈で何だからとか気にする必要ないし、よろしければこちらからご応募くださいませ。要は提供する価値とニーズのマッチングの問題だけなんだよな。

みんな知っているようなこと書くけれど本当のことは知らない、というか僕も知らない世界だらけ。自分の価値観や知っている範囲の狭い世界の価値観とか雰囲気で他人の拘りや、他人がやっていることにケチつけて何になる (ケチつける自由はあるが) 。

まぁ、僕自身も気をつけます。

動的生成のメリット

再構築! 再構築! 再構築! ばかり書いてるけど、僕はケースバイケース派ね。ていうか当然だけど。

明らかに動的生成が有利というか動的生成じゃないと困難なケースをいくつか挙げると (全部あたりまえの話ばかりだけど)、

1. クライアント毎に返す結果を変えたい場合。携帯電話向けウェブアプリの場合等。絵文字とか機種毎の差を反映させるためには静的生成の場合はUA毎のすべてのページを生成しなければ不可能。
2. ユーザー毎にログインを必要とする場合。
3. リクエスト毎にリアルタイムで処理を行いたい場合。例えばリアルタイムにアクセス解析を行う場合等 (最近は見ないけどカウンタとかも)。

こういう場合における負荷分散とかクライアント/サーバーそれぞれにおけるキャッシュの実装とか、そのあたりが腕の見せ所になってくるわけですが、1.の場合であれば各キャリアで共通の部分をサーバーキャッシュ、リアルタイム更新の不要なところではクライアントキャッシュを使わせるとか。2.の場合は実態はスタティックなページを返しても良いので「前処理」の部分で認証処理を行うようにして、認証をパスしたら静的データを返すとか。3の場合も1と同様、動的処理が不要なところは同じくサーバーキャッシュとか。
もちろん動的生成が効率よく行われるような組み方をするのが大前提だけど。

というのを考えたのはVOXってどうやってるんだろう? と思ったことが一つと、MTの静的生成のもう一つのデメリットである「ゴミ」が出来る問題について昨日ちょっと話題に登ったから (というか僕が話題にのせたのだけど)。

静的生成と「ゴミ」

静的生成と比較した動的生成の最大のメリットは「ゴミ」が出来ないこと、というかファイル管理の必要がないことだと思う(速度や負荷の話は不毛なので敢えてここではしない)。だからサイト制作段階においては動的生成、納品・公開時には静的生成とか、そんな方法も(ウェブ屋的な使い方としては) あり得る。

ゴミの件はそのあたりを掃除するプラグインを書くのは実は簡単で、これもラフラフなバージョンは出来ていて、CMSのViewのところでAjaxとか使おうかなぁと思ってウチのV担当に指示して作成中なわけで、CMSの拡張においてもちゃんとVとCが分担出来るMTって素敵とか思う今日この頃。

MTの静的生成と「ゴミ」についての関連エントリー

• CMSと静的ファイル管理に関する考察。
• CMSと静的ファイル管理に関する考察の続き。
• CMSと静的ファイル管理に関する考察の(更に)続き。
• DeleteFilesAtRebuildの半端さ加減。
• ステータスが「下書き」のエントリー(permalink)が残っていたら削除する。

さて、いよいよMT4

まぁ雑文ですが、本日V4リリースだよね。さっきの段階ではまだ見つけられなかったので取り敢えずRC4落として新幹線の中でいじってみることにします。

おそらく遅くまでバタバタされたであろう中の方にはお疲れさまと言いたいです(が、まだ本番はこれからです! 引き続きよろしくお願いしますね)。

えーっと、まぁ何だ、何が言いたいねん? って人はこっち↓を見てください。このエントリーには「毒」が盛られているので。

• マークアップエンジニアが次に取り組むべき5つのテーマ。

面倒くせぇけどたかだか大阪のウェブ屋がどうとか言われるとムカつくので自分の立ち位置からちょっと述べると、

• マークアップ・エンジニアこそが会社のコア・コンピタンスであり且つマークアップ・エンジニアが高い給料を取れる(小さいながらも)会社を経営していて、マークアップ・エンジニアが金を取れるかどうかもスーツ次第と思っているスーツだけどそれが何か?
• Another HTML-lintにはお世話になっていてK16さんの日記に「だれか要りませんか」と書かれていたMac(Performa)を買い取るという名目でビール代を払ったことがあって、そのPerformaは家内が「使ってないものをいつまでも置いておくな」ということでドナドナされてしまったけれどビールだと税金的に面倒(嘘)なので中古ハードの購入という名目にしたので良かったと思っているけどそれが何か?
• ウチの会社のサイトをリニューアルしたついでにJavaScript+CSSでプレゼンツールを作ってそれが簡単に作れるMTのプラグインも一緒に公開したりしてそのJavaScript+CSSはウチのマークアップ・エンジニアが作ったわけだけどそれで彼はエフェクト重要じゃなくてアクセシブル且つ作りやすいことこそ大切と言っていたのでエフェクト左程重要じゃなくね、という意見に同意してそのままにした判断は誰がしたかというとスーツ兼任プログラマ(＜これでいいですか? 皆の衆) な僕がしたわけだけどそれが何か?
• 例えば「アクセシビリティ」＋「制作会社」でググると今日現在ウチが一番上に表示されるけどそれが何か?
• サイトをガラッと変えて検索順位が落ちたらウチが間違っているんじゃなくてGoogleが間違っているのだとマジで思うわけですがそれが何か?
• ウチのクライアントは発注先の選定にあたってMarkup Validation Serviceを活用していて酷い点数のサイト制作会社は除外していてウチに名指しで声かけてくれるわけだけどそれが何か?

ついでに...

• MT4が今日リリースなわけですね。6Aさんから徒歩一分の赤坂のホテルからこのブログ更新していますがそれが何か?

立ち位置の説明で終わっちまったなぁ。結局のところ、そうやってあーだこーだやってるわけだがWeb業界がどうだとかCSSだとかJavaScriptとかWeb標準だとかアクセシビリティだとか全部大切でそのあたり真面目にやるのが全部大好きだけど結局大切なのはクリエイティブだったり、まぁ何だ、皆んな仲良くやればいいのになんて思う僕だけどそれが何か?

あっち(どっち?)の人に対してわかりやすく説明するなら、MVCのVをきちんと担当できるマークアップエンジニアがいればCを受け持つ人間にしたらすんごい楽なわけですよ。

こっち(どっち?)の人に対してわかりやすく説明するなら、MVCのCの人とうまく連携出来るくらいの知識をマークアップ・エンジニアは持つべきだし、そういう面で真剣に第二の何かを探したほうがいいというのはあながち何[謎]でもないことも考えておいた方がよいわけですよ。

ただ、テンプレートエンジンとか上手く使って魅力的なWeb(サービス|サイト)とか作ろうと思ったら、両者は「車の両輪」の如しだっていうのはスーツの戯れ言ですかそうですか。

何て思ったりするわけですけどそれが何かっ!?

あ、一応このあたり↓への言及ね。

• IT戦記 - マークアップエンジニアはどこへ向かうべきか（を考えてたらカッとなって LL の資料公開）
• HTML文書を書く人は、とりあえず仕様書読め。

あと、一応補足というか、僕の本音(というか、そのあたりについて思っていることへの言及というか、つまりは読んで欲しいエントリー)も言い訳程度にご紹介しておきますね。

• Web標準やWebアクセシビリティの分かりやすいビジネスメリットをうまく説明できるのは実はプログラマである。
• CSS が valid でなければいけない理由。
• 音声ブラウザと相性の良いHTMLを作る。
• Movable Type as a Web application framework.
• Webサイトは会議室で作られてるんじゃない! 現場で作られてるんだ! (WebSig会議雑感)
• アクセシビリティはボランティアじゃないっ!
• Web標準+MT+Nakedで作る「ワンソース・マルチユース」なWebSite (Naked Slide + MTプラグイン公開)。
• ウェブコンテンツ・テキストバージョン・ジェネレーター(Naked Beta)。

出遅れたっ!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

実はめちゃくちゃ本気で取り組んでます。

• 再構築の高速化に本気になれない訳。
• 小粋空間: Movable Type 再構築の本当の問題

お分かりの方は既にお分かりかとは思うのですが、「本気になれない」と書いたのは実は「めっちゃ本気」の裏返しなわけです。「再構築」でこのブログエントリーの10%強がヒットしますし。

とにかく遅いのは嫌だしストレスも嫌いだから、「高速化」というテーマでも色々書いています。

• MovableTypeをめっちゃ高速化する20の方法。

僕の場合はWeb屋 (企業や団体、公共機関のWebサイトを構築する仕事) が本業なので、例えばPhotoshopが重かったらメモリ増やすとかの対応をとれる立場にあるわけですし、ハードウェアの力にある程度頼っていることは否定しません。ただ、ここで書いたことは全て実行したこと、つまり実体験にも基づいています。今までテンプレートを変更したりエントリーが増えたりして何度も再構築時間が30秒を超えそうになりましたが、都度対策を行い時間を短縮しています (現在は300エントリー強で15秒弱)。

確かに「趣味のブログ」だからコストもあまりかけたくないという面はあると思いますが、エントリーが1,000とか極端な話10,000を超えたりするっていう状況で、しかもレンタルブログサービスでなく自分でMovable Typeを使っているわけですから、そこは再構築の高速化も含めたカスタマイズのプロセスを楽しめないとなぁ、という思いが根底にあります。

話を本題に戻します。

やばいな、と思ったら一旦リセットする。

これまで色々やってきましたが、最も簡単で効果があるのは「ブログを一旦リセットする」ことです。

もちろんブログを辞めて移転して一から始めるという意味ではありません。実際にはもう触ることも無く自分も閲覧する人もほとんどなくなった古いエントリーや日付アーカイブ群を再構築プロセスから切り離すことです。

このブログでは、過去2ヶ月以前のエントリーや日付アーカイブは再構築しないようにしています。もちろんテンプレートやデザインを変更した時には全再構築をかけられる状態にしていますが、普段のエントリーの追加・更新の際には再構築されるファイルは全体の約10%、この2ヶ月以内のエントリーや日付アーカイブのみです。

例えば、「アーカイブ」ページ。通常ならDBのエントリーテーブルにアクセスして、全てのエントリーをループ処理、リストにして表示します。これはすごく無駄の多いことだと思うわけです。最新の1件が先頭に追加されるだけなのに、全てのエントリーのデータにアクセスしてループ処理を回すわけですから。

例えば今年の6月以前のリスト部分は外部ファイル化してモジュール化しています。リストの先頭から6月までの部分だけが毎回再構築されます。

もちろんプラグインの設定一つで強制的に全再構築できるようにしていますから、明示的にすべてを新しくしたい場合は全再構築が可能になっています。

基本的には、以下の2つのプラグインの組み合わせに＋このエントリー(MovableTypeでMTIncludeもPHPもSSIも使わずテンプレートをモジュール化する方法。)＋このエントリー(MovableType, 再構築の高速化(<$MTInclude file...$>とBackground Rebuilder Plugin)。)で書いている手法を組み合わせています。

• BuildFileFilter4OldArchive
• Background Rebuilder

そして、最後にメイドさんが表示されれば完璧!?

まぁなんかまとまらない話で恐縮ですが、これだけレンタルだったり安価なブログサービスが普及している昨今、わざわざMTインストールしてカスタマイズしてってのが楽しい人は、全再構築30秒切ったぜ! とか15秒切ったぜ! ってなことにも楽しみを見いだせる筈だと思うのです。

たかだかブログですから! 楽しみましょう、色んなプロセスを。ということが実は一番言いたかったりすることです。

利用方法

<MTEntryBody RichTextFilter="1">

処理内容

対応バージョン

ライセンス

ダウンロード

はっきり最初にお断りしておくと、別にどっちが勝ったって構わんし何か主張するわけでもないのでその点宜しく。

• 小粋空間: Movable Type が WordPress に負けた本当の理由
• Movable TypeがWordPressに負けない理由 - Ogawa::Memoranda
• MovableTypeとWordPressの話

基本GPLのツールと個人ライセンスはあるにせよ商用ソフトウェアの比較をインストール数とか検索数で比較しても勝ち負けを論ずることには繋がらないわけで。

例えば「どっちが多くの売上を上げたか」ってのが勝ち負けだったら全然違う結果になるわけだよね。

僕にとっては自分あるいは自分の立ち位置(Web屋)としての勝ち負けで判断をするわけだが、このエントリーでそのことをとりあげるつもりは無い。

検索数が多いのは、単に分かりにくかったり情報が少ないからなのかもしれないし、検索数が勝ち負けってわけでもない。

まぁこれ以降は何も書かずにキャプチャを並べるので。あとは勝手に盛り上がって頂戴。一応、地域 - 日本においての話ね。

Google Trends - PHP vs Perl (2007年, 地域日本)

WordPress vs MovableType (2007年, 地域日本)

WordPress vs MovableType vs Movable Tylpe (2007年, 地域日本)

Google Trends - WordPress vs MovableType vs Movable Tylpe vs MT (2007年, 地域日本)

キーワードアドバイスツール - Movable Type

キーワードアドバイスツール - MovableType

キーワードアドバイスツール - MT

キーワードアドバイスツール - WordPress

キーワードアドバイスツール - WP

ブログをまたがったインデックス再構築用プラグイン

劇薬につき注意!?

利用方法

<$MTRebuildIndexById tmplate_id="3,5"$>

ライセンス

ダウンロード

約300エントリーの再構築が13秒程だったので、まぁ気にするほどではないか、と。いやマジで。1,000エントリーなら...でもせいぜい一分以内でしょう?

何が問題なんだか、よく分かんない。

Web標準+MT+Nakedで一体何ができるのか

WebSigのプレゼンの時にも使いましたがアルファサードのウェブサイトでも使っているXHTMLベースのスライドショーシステム Naked Slide (XHTML+CSS+JavaScript) を公開しました。

アルファサードのウェブサイトのトップ及び主要な各ページの右上に「閲覧モード」のボタン群を付けているわけですが、一番右側の「プレゼン」ボタンクリックで新しいウィンドウでプレゼンテーションスライドが開始されます (各ページ上でクリックすると該当ページが表示されます)。

JavaScriptが有効である必要があります。

使用しているCSS+JavaScriptとスライド用にClass指定をするためのMTプラグイン、また使用しているMTのテンプレートも同梱しました。

ダウンロードは当社のウェブサイトから行えます。

• XHTMLベースのスライドシステム Naked Slide を公開 (Alfasado, Inc.)

Slidy や S5 等が既に同様のツールとして公開されているわけですが、 Naked Slide の名前からも想像できる通り、ウェブコンテンツ・テキストバージョン・ジェネレーター(Naked Beta) の1つのモードとして、同一のHTMLから様々なバージョン (音声ブラウザ最適 / 携帯電話向け / ルビ付きバージョン / スライドプレゼンテーション用) を自動生成して動作させることを最終的な目的として作成したものです(まだこの部分は出来ていません)。

既存のソリューションと比較してテキスト量が多くなった時にスクロールできるようにして情報が画面サイズによって欠損してしまうことがないように (情報が溢れた場合は) スクロールバーが表示されるようにしているとか、出来ることも限られていますがその分指定が簡単とか、その辺を意識しています。

アルファサードのウェブサイトでは 今回のリニューアルにあたって Movable Type を導入しましたが、スライド用のテンプレートを別に作り、スライドに表示させたい部分を excerpt (概要(抜粋)) 部分に入れること、且つスライド用のタグ(クラス)設定にはMTのプラグインを書くことによって自動的にClassを振るようになっています。

これによって、通常PCやMacで閲覧する画面デザインの他、MT拡張アプリによる携帯版、Nakedゲートウェイを利用した音声読み上げに適したテキストバージョン、濃い背景色に明るいテキストの色反転バージョン、ルビ付きバージョンに加えてプレゼンテーションバージョンをMT上に登録された完全に同一のデータから生成することが可能になりました(MTのテンプレートとプラグインも一緒にダウンロードしていただけるようになっています)。

「完全に同一なソースからどこまで多様な表現が可能なのか」を分かりやすい形で示そう

もちろんMT(CMS) のアーカイブを適切に設定してやればテキストバージョン等の同時生成は可能ですが、今回は当社でこれまでに取り組み開発して来た様々な技術をフルに実装して「Web標準+MT+Nakedで一体何ができるのか」を「クリエイティブを犠牲にすることなく」実現することを狙って構築しました (今後も改良を加えて行く予定)。

これからも仕事「内」「外」で色々とWeb技術に関する面白いものをリリースしていきたいと思っているので、このブログの読者の方は是非ウチの会社のサイトのRSSもCheck It!

* そのために「Labs」なんてページも作りましたし!