2007年6月アーカイブ

第四期末, 社内研修。

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

社内研修のヒトコマ


今回は大阪で。東京のスタッフは1泊2日。昨日の夜は打ち上げ。

今日の午前中は外部から講師を招いて「デザインのプロセス」をテーマに社内研修、午後からは僕が講師でMT絡み(社内プロダクトやMT4等)の話題やWebアクセシビリティについての話しを。

携帯からの投稿のデモを行うから, まず写真を...って何で隠れんねん。シャイ? まさかね。

お疲れ! 7月から第五期。気を引き締めて。良い一年にしたい。


エントリーアーカイブへの最初のアクセスがあった時点で再構築(静的ファイル生成)を行うMovable Type用のプラグイン+α

*設定方法等大きく変更しましたので、以下の別エントリーを立てました。ダウンロードもこちらから可能です。

一通りの実装とテストが終わったのでベータ版として公開します。
まだまだ荒削りな部分もあるかと思いますがお気づきの点等ありましたらご指摘いただけると幸いです。

追記:
Unix+Apache+MT3.xで動作します。Windows環境では動作検証は行っていません。

インデックスアーカイブ, カテゴリーアーカイブ, 月別(週別)アーカイブ等は静的生成、エントリーアーカイブは動的生成(ダイナミック・パブリッシング)とし、動的生成のページに対しては「最初にそのページにアクセスがあった時」に再構築(静的HTMLファイルを生成)を行います。ダイナミックパブリッシングによる再構築の負荷軽減と静的生成による閲覧時の負荷軽減の両方のメリットを享受できる方式です。

MySQL用のテーブル作成スクリプト(php)を付けました(by 当社K君)。その他のDBの場合も以下の構造のテーブルを追加していただければ動作可能かと思います。

テーブル:mt_permalinkの構造
permalink_idint(11)
permalink_blog_idint(11)
permalink_permalinkvarchar(255)
permalink_modified_ontimestamp

ダウンロード

  • RebuildAt1stView.zip(12Kb)
ちょっと止めます。MT3/4両対応してFastCGIにも対応させた版を明日? くらいにアップしますので。

* ダウンロードは以下のエントリーのページから。

インストールと設定

  1. mtview.cgiの編集。
    
    use lib qw (/path/to/mt/lib/);
    use lib qw (/path/to/mt/extlib/);
    my $mt = MT->new(Config => '/path/to/mt/mt-config.cgi');
    my $base_url = 'http://example.com';
    my $base_pth = '/path/to/htdocs';
    1行目のPerlのパス及び4〜8行目を環境にあわせて修正。
    7行目・8行目の$base_url, $base_pthはそれぞれ「httpからドメインまで」「ドキュメントルートのフルパス」を記述してください(最後に/(スラッシュ)は含めません)。
    修正後、ファイルをアップロードして実行権限を付与してください。
  2. mtフォルダのlib/MT以下にPermalink.pm をアップロードします(lib/MT/Permalink.pm)。
  3. Installerディレクトリのpermalink.cgi の1行目のPerlのパス及び4〜18行目を環境にあわせて修正します。その後InstallerディレクトリをWebサーバーにアップします(シェルが利用できる方はシェルから実行してください(mt_permalink.sql及びpermalink.cgi)。Web経由で実行される方は(セキュリティのために)実行後必ずInstaller ディレクトリごと削除してください。)
  4. (Web経由でデータベースのテーブルを作成する場合)create.php にデータベースに関する必要な情報を入力して「Create Table」をクリックします。「successful」と表示されたらテーブルの追加は成功です。
  5. permalink.cgiを実行します(Web経由で実行する場合には実行権限を与える必要があります)。
  6. Installer ディレクトリを削除します。
  7. 「設定」→「公開」→「再構築オプション」で「テンプレート別に、スタティックHTMLもしくはダイナミック・パブリッシングを選択します」にチェックを入れて変更を保存します。
    設定→公開→再構築オプション
  8. エントリー・アーカイブの編集画面で「このテンプレートをダイナミック・ページにする」にチェックを入れて変更を保存します。
    エントリー・アーカイブの編集画面
  9. サイト全体を再構築します。
  10. *これまでに生成された静的ファイルはファイルの末尾に.staticが追加されてバックアップされます。
    これらのファイルは不要ですので動作確認後削除して構いません。
  11. pluginsフォルダ内のRebuildAt1stViewディレクトリをディレクトリごとMTのpluginsディレクトリにアップします。
  12. 有効にしたいブログのプラグインの設定画面でRebuildAt1stViewの設定を表示, 「プラグインを有効にする」にチェックして変更を保存します。

  13. ブログのルートフォルダに「.htaccess」ファイルが生成されていますので削除, 同梱の「_htaccess」をアップロード。「.htaccess」にリネームします。
    
    ErrorDocument 404 /mtview.cgi
    
    ErrorDocumentのパスをアップロードしたmtview.cgiのパスにあわせてください。

プログラムの動作と利用方法

エントリーアーカイブを再構築してもエントリーアーカイブは基本的にダイナミックパブリッシングなので静的なファイルは生成されません。

エントリーアーカイブへのリクエストがあった場合、ページが存在しないので.htaccessで設定されたmtview.cgiが呼び出されます。mtview.cgiによってページが構築されデータをブラウザへリプライすると同時に静的HTMLをディスクへ書き出します(*)。

*但し、UserAgentにGooglebot,Yahoo! Slurp, msnbotのいずれかの文字列が含まれる場合はHTTP_IF_MODIFIED_SINCEとEntryのmodified_onを比較し、エントリーが更新されていなければNot Modifiedを返します(ページの生成は行いません)。

ファイルがディスクへ書き出された後のリクエストに対しては静的HTMLが使われるためmtview.cgiは呼び出されなくなります。

構築されたエントリーアーカイブは以下のタイミングで削除されます(その後再度ページへのアクセスがあった時に再生成されます)。

  • エントリーを更新した時, エントリーのステータスを下書きにした時(前後のエントリーアーカイブの静的HTMLが存在した場合、それらのファイルも削除されます)
  • コメント, トラックバックを更新した時

エントリーキャッシュの全消去

すべてのファイルを削除したい場合(つまり、全てのページを最新のものにしたい場合は、管理画面の各ブログトップ(mt.cgi?__mode=menu&blog_id=x)及びエントリー一覧の画面(mt.cgi?__mode=list_entries&blog_id=x)の「プラグイン」アクションの「エントリーキャッシュの全消去」をクリックします(すべてを再構築した直後に行うか、全てを削除した後に全再構築を行うと良いでしょう)。

MTのバージョンについて

MT4対応しました。Movable Type4には対応していません。動作確認済みのバージョンはMovable Type3.3のみですがバージョン3系であれば動作するのではないかと思います。


ちょっと宣伝します

私が代表をつとめるアルファサード有限会社ではこんな風にMovable Typeに関する様々な課題解決が得意です。MTは使いやすいけれど「もっとこんな風にならないかなぁ...」「こんなことができるといいのに...」とお感じになられている企業や団体の皆様はお気軽にお問合せください。

関連エントリー

動的生成・静的生成がちょっとした話題になっている? わけですが、拙作のプラグインBackground Rebuilderも某所でとりあげられてたりしてますね(一時アクセスが増えました)。

少しこのプラグインについて補足しておきます。

まず、ちょっと誤解を招く書き方をこれまでしていたかもしれませんが、このプラグインで全再構築を行った場合、全再構築をコマンドラインで行った時とほぼ同様の負荷がかかります。ですのでプロセスが一定時間を超えるとkillされる環境ではこのプラグインを入れてもおそらく解決はしないでしょう。

『「CMSの体感速度を上げる」ことで制作者のストレスを軽減する』のがこのプラグインのコンセプトだと考えてもらった方が良いでしょう。

むしろ全再構築よりも各エントリーの保存時の体感速度の速さが僕には重要です。静的・動的の話の際に書き忘れましたが、MTをBlogではなくサイト制作ツールとして使う場合(しかも運用ではなくオーサリングプラットフォームとして使う場合は)閲覧者はクライアントと制作会社だけです。ページの閲覧よりもCMSを操作している時間の方が長いわけです。

こういった場合は、制作する側がストレスがないのが一番です。動的生成でも良いのですが、「MTを使用して静的生成ベースでサイトを制作している際に制作者のストレスをなくし作業効率を上げること」がこのプラグインを作った一つ目の理由です。

以前以下のエントリーを書きましたが、このエントリーの最後で書きかけのまま放置していた事実? についてここで紹介しておきます。

(要は、Movable Type Background Rebuilder Plugin に手を入れて、再構築の順番を変えたのだ。)

高速化のために<$MTInclude file=...による共通部分の外部ファイル化という方法があるわけですが、共通部分をインデックス・アーカイブとしている場合に一つ問題が起こります。

モジュール化された部分

新規のエントリーを保存時する瞬間は、外部の共通ファイルは古いままです。例えばこのブログの「最近のエントリー」等が反映されないのです。全再構築を行う際も「エントリー」が先に再構築され「インデックス」が最後に再構築されますから、右側の共通部分は普通に再構築を行う限りは常に1バージョン古いものになってしまいます(インデックスが先に公開されると時間差の関係で一瞬リンク切れ状態になりますのでCMSの振る舞いとしては正しいのだと思いますが)。

Background Rebuilderプラグインでは、エントリーの保存時、あるいは全再構築時に「インデックス・アーカイブ」を先に再構築するようにしています。こうすることで常に最新のファイルがインクルードされるようになります。

インクルードファイル化したことで「こっちを先に再構築しなきゃ」といったことを意識する必要がなくなります。

これが僕がBackground Rebuilderを作った「もう一つ」の理由です。


こちら↓のエントリーで書かれていることは、つまりはこういうことではない? ...のかな?

試しにやってみようとソースコードを見てみましたが、まだ良くわかっていません。テンプレートを外部ファイル化して、外でスクリプトを使うか人手でのテンプレート修正と組み合わせでやるほうが楽そうです。使い勝手的にはプラグインに出来ればベストかもしれません。

追記(2007年7月2日):
一連のエントリーで作成したものを取りまとめて公開しました。


驚くのはまだ早い!(なんて言ったりして)

そして、今回頂いた反応の中で、一番驚いたのがこれ。

* ↑トラックバックがHTTP error: 403 Throttledで弾かれる...

ここまで来たら...やっちゃえ!

Movable Type10分間Cooking!(Part4)

まぁ10分で出来るのはこれまでに書きためたプラグインの各種パターンがあるからですが、テストやドキュメント、設定のUIとかそのあたりは手抜きで。

関連エントリー

静的生成されたファイルの全削除

今回の件でいえば「再構築」の代わりが「全削除」です。全削除しておくとあとは各ページが最初に閲覧された段階でそれぞれ再構築されます。リクエストのないページに対する無駄な再構築もありません。

my $plugin = new MT::Plugin::RebuildAt1stView({
	name => 'RebuildAt1stView',
	app_methods => {
		'MT::App::CMS' => {
			'remove_all_entry_archive' => ¥&_remove_all_entry_archive
		},
	},
});

MT->add_plugin($plugin);

MT->add_plugin_action('blog',
	'../'.MT->config('AdminScript').'?__mode=remove_all_entry_archive',
	'Remove All Entry Archives'
);

MT->add_plugin_action('list_entries',
	'../'.MT->config('AdminScript').'?__mode=remove_all_entry_archive',
	'Remove All Entry Archives'
);

プラグイン・アクション

全削除の場合はプログラム書くだけじゃなくて管理画面へのインターフェイスが必要です。add_plugin_action を使うと簡単です。

mt.cgi?__mode=remove_all_entry_archive;from=blog_home;blog_id=3

上記のように呼び出して動作させます。app_methods についてはこちらのエントリーに少し書いていますのでそちらも参考にしてください。

全削除は以下の通り。たかだか250程度のエントリーですが、感覚的には1秒以内で全削除できます(本当はちゃんとHTML組み立てて結果を返した方が良いですしエラーも拾った方がいいですけど)。

*ちょっと修正。is_superuserでスーパーユーザーかどうかチェックするようにした。


sub _remove_all_entry_archive {
	my $app = shift;
	my $user = $app->user;
	if ($user->is_superuser) {
		my $blog_id = $app->param('blog_id');
		my $iter = MT::Entry->load_iter({
			blog_id => $blog_id},{
			sort => 'modified_on',
			direction => 'descend',
		});
		if (defined $iter) {
			while (my $entry = $iter->()) {
				$app->publisher->remove_entry_archive_file(Entry => $entry, ArchiveType => 'Individual');
			}
			return 'エントリーアーカイブを削除しました!';
		} else {
			return 'エントリーが見つかりません。';		
		}
	} else {
		return '権限がありません。';		
	}
}

あとは各エントリーの保存や削除時に前々回のエントリーで作成した mt_permalink テーブルの更新が必要ですが、CMSPostSave.entry, CMSPostDelete_entryコールバックが呼ばれたタイミングで処理させます(MT4ではコールバック名が変更になっているかもしれませんがおそらく同等のコールバックは用意されていると思います)。


MT->add_callback('CMSPostSave.entry', 10, $plugin, ¥&_post_save_entry);
MT->add_callback('CMSPostDelete_entry', 10, $plugin, ¥&_delete_entry);

sub _post_save_entry {
	my ($eh, $app, $entry, $original) = @_;
	my $permalink = MT::Permalink->load({id => $entry->id});
	if ($entry->status != 2) {
		$app->publisher->remove_entry_archive_file(Entry => $entry, ArchiveType => 'Individual');
		if (defined $permalink) {
			$permalink->remove or die "Removing permalink failed: ", $permalink->errstr;
		}
	} else {
		if (defined $permalink) {
			$permalink->permalink($entry->permalink);
			$permalink->modified_on($entry->modified_on);
			$permalink->save or die "Saving permalink failed: ", $permalink->errstr;
		} else {
			$permalink = MT::Permalink->new;
			$permalink->id($entry->id);
			$permalink->blog_id($entry->blog_id);
			$permalink->permalink($entry->permalink);
			$permalink->modified_on($entry->modified_on);
			$permalink->save or die "Saving permalink failed: ", $permalink->errstr;
		}
	}
}

sub _delete_entry {
	my ($eh, $app, $entry) = @_;
	my $permalink = MT::Permalink->load({permalink => $entry->permalink});
	if (defined $permalink) {
		$permalink->remove or die "Removing permalink failed: ", $permalink->errstr;
	}
	$app->publisher->remove_entry_archive_file(Entry => $entry, ArchiveType => 'Individual');
}

残りタスク

ということで、ソースはこちらに晒しておきます。一旦削除します。後ほどアーカイブとして最新のものをアップします。ライセンスはGPLです! (しつこい?)
っていうか誰か完成させてください。以下残りタスクを挙げておきます。

追記:ソース一式を以下のページからダウンロードできます。
  • (何よりもまず)動作の検証・テスト
  • コメント・トラックバック反映時の再構築(というかページの削除)対応済み
  • Googlebot以外のロボット対策取り急ぎYahoo! とmsnbot対応
  • データベーステーブル mt_permalink 作成, 初期データ登録のインターフェイス(ウィザード?)
  • mtview.cgiをFastCGI対応させる(Bootstrap.pm を使ったアプリケーションにする)
  • 各処理の中のエラー処理
  • 全削除後の表示画面対応済み
  • ブログ毎の設定(オン・オフできるようにする、等)対応済み

良く考えてみたら。

「コスト」をそのまま「コスト」と解釈すれば、

  • 閲覧する人が快適であることが何よりも大切
  • そのために制作する側・発信する側がコストを負担すべき
  • 自分のサイトに訪れてくれる人へのホスピタリティこそ重視すべきこと

例えば

  • ウェブアクセシビリティに関するコストは誰が支払うべきなのか

と言い換えることもできるかもしれない。

  • 制作者に負担がかかるから
  • ユーザーエージェントがなんとかしてよ
  • 制作者がしんどいのは勘弁、ユーザーが少々不便でも作る方が負担がない(軽い)ほうが良い

CMSの場合は「制作者」もユーザーだから「再構築が重い」とかいう議論になるわけだが、そもそも何のためのウェブサイトであり何のためのブログなの? 「サイトに来てくれる人のためにどのようなホスピタリティ・アクセシビリティを提供するか」が基本だよな。

だから、例えばコストを2万円かけてサーバーのメモリを増やす、っていう選択肢もありだし、レンタルサーバーのプランをワンランク上げて快適にするという選択肢もある。

すべてはサイトを訪れてくれるあなたのために、という姿勢で考えるべきじゃないんだろうか、などと考えてみたり。

追記(2007年6月29日):
一連のエントリーで作成したものを取りまとめて公開しました。


何でこんなことやってんだろ(笑)。

まぁこういう負荷軽減のためのあれこれって結構楽しいわけです。動けばえーやん、から一歩進むための色んなコツみたいなものがあって、昔非力なMac、速度の出ないスクリプト言語(AppleScriptとかREALbasicとか)で工夫しながらやっていたことがこんなところで使えるとは...

関連エントリー

Movable Type10分間Cooking!(Part3)

今回はMovable TypeというよりHTTPヘッダを使ったクライアントキャッシュのコントロールが本題。ステータス404をちゃんと返さないと弾さんに怒られちゃうし。

前々回, 前回のはそのあたり全く考慮していないので、以下きちんと実装する。

  • 最初のページへのリクエストがあった時(ページとファイルを生成する時)にクライアントに Last-Modified, Content-Length を返す(クライアントにきちんとキャッシュさせる)*
  • ロボットからのアクセスの場合 HTTP_IF_MODIFIED_SINCE をチェック。entry->modified_on と比較してエントリーが更新されていなければ304 Not Modifiedを返す。ブラウザからのアクセスであればページをBuildしてファイルを構築する(その際ファイルのタイプスタンプを entry->modified_on にあわせる。
  • エントリーが見つからなかった場合は404 Not Foundを返す。

*ETagは使わない。参考:14 rules for fast web pages (Skrentablog)

今回は理屈の説明はなし! (説明書くと15分かかるので10分間Cookingにならないし!)

チェックしているUserAgentはとりあえずGooglebotのみ。

touch しているのは、この方法だとファイルのタイムスタンプは常に modified_on よりも新しいものになってしまうので2回目のアクセスの時にHTTP_IF_MODIFIED_SINCEと時間があわなくなってしまうのでその対策。

  • テスト用ブログ : Junnama Online (Dynamic)

mtview.cgi

#!/usr/bin/perl -w
use strict;

use lib qw (/path/to/mt/lib/);
use lib qw (/path/to/mt/extlib/);

use MT;
use MT::Blog;
use MT::Entry;
use MT::Builder;
use MT::Template;
use MT::TemplateMap;
use MT::Template::Context;
use MT::Permalink;
use HTTP::Date;

my $mt = MT->new(Config => '/path/to/mt/mt-config.cgi');

my $base_url = 'http://junnama.alfasado.net';
my $base_pth = '/path/to/htdocs';

my $blog_id = 3;

my $request = $ENV{"REDIRECT_URL"};
my $url = $base_url.$request;
my $permalink = MT::Permalink->load({permalink => $url});
if (defined $permalink) {
	my $modified_on = $permalink->modified_on;
	my $yymmdd = substr($modified_on, 0, 8);
	my $hhmmss = substr($modified_on, 8, 8);
	my $yymmddhhmm = substr($modified_on, 0, 12);
	my $ss = substr($modified_on, 12, 2);
	$modified_on = $yymmdd.'T'.$hhmmss.'Z';
	my $touch = 'touch -t '.$yymmddhhmm.'.'.$ss.' ';
	$modified_on = &str2time($modified_on);
	my $http_if_mod = $ENV{'HTTP_IF_MODIFIED_SINCE'};
	$http_if_mod = &str2time($http_if_mod);
	my $ua = $ENV{'HTTP_USER_AGENT'};
	if ($ua =~ /Googlebot/i) {
		if ($http_if_mod && ($http_if_mod >= $modified_on)) {
			print "Status: 304 Not Modified¥n";
			print "Last-Modified: $modified_on¥n¥n";
			exit;
		}
	}
	my $entry = MT::Entry->load({id => $permalink->id});
	if (defined $entry) {
		my $tmap = MT::TemplateMap->load(
								{	blog_id => $blog_id,
									archive_type => 'Individual',
									is_preferred => 1
								},);
		my $template = MT::Template->load({id => $tmap->template_id});
		my $page_tmpl = $template->text;
		my $blog = MT::Blog->load({ id => $blog_id });
		my $ctx = MT::Template::Context->new;
		$ctx->stash('entry', $entry);
		$ctx->stash('blog', $blog);
		$ctx->stash('blog_id', $blog_id);
		my $build = MT::Builder->new;
		my $tokens = $build->compile($ctx, $page_tmpl);
		my $html = $build->build($ctx, $tokens);
		if ($html) {
			$modified_on = &time2str($modified_on);
			my $len = length($html);
			print "Status: 200 OK¥n";
			print "Last-Modified: $modified_on¥n";
			print "Content-Length: $len¥n";
			print "Content-Type: text/html¥n¥n";
			print $html;
			my $buildfile = $base_pth.$request;
			$touch .= $buildfile;
			open (OUT,">$buildfile");
			print OUT $html;
			close(OUT);
			my $res = system($touch);
			exit;
		}
	}
}
print "Status: 404 Not Found¥n";
print "content-type: text/html¥n¥n";
print "404 Not Found.";

さらにさらに続きはこちら↓。

追記(2007年6月29日):
一連のエントリーで作成したものを取りまとめて公開しました。


もうちょっとだけやります。えーっと必要な方は是非完成させてください(で、完成させたら僕にください!)。前回のエントリーの続き。

さらに続きまで書いてしまった...

先のエントリーで何だか面倒だったのがbasenameからentryを検索するところ。File:: Basenameを使うともう少し楽か...。ただbasenameは一意な値じゃないからやっぱり検索は非効率です。

そこで、データベースを拡張することにします(実は本題はここだったりする)。

Movable Type10分間Cooking!

データベースにmt_permalinkというテーブルを追加し MT::Objectのサブクラスを作成して利用します。

テーブル:mt_permalinkの構造
permalink_idint(11)entry_idと対応したユニークな数字
permalink_blog_idint(11)ブログID
permalink_permalinkvarchar(255)URL(Permalink)
(追加)
permalink_modified_on
timestamp更新日時

データベースはMySQL。もちろんPostgreSQLでもSQLiteでも良いです(そこがMTの特長)。

CREATE TABLE `mt_permalink` (
  `permalink_id` int(11) NOT NULL,
  `permalink_blog_id` int(11) NOT NULL,
  `permalink_permalink` varchar(255) collate utf8_unicode_ci NOT NULL,
  `permalink_modified_on` timestamp NULL default CURRENT_TIMESTAMP,
  UNIQUE KEY `permalink_id` (`permalink_id`),
  KEY `permalink_blog_id` (`permalink_blog_id`),
  KEY `permalink_modified_on` (`permalink_modified_on`),
  KEY `permalink_permalink` (`permalink_permalink`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

続いて MT::Objectのサブクラス「MT::Permalink」を作成。

Permalink.pm として mtディレクトリの lib/MT/ 以下に置きます。(mt/lib/MT/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' => 'integer',
	},
	indexes => {
		blog_id => 1,
		permalink => 1,
		modified_on => 1,
	},
	child_of => 'MT::Blog',
	datasource => 'permalink',
	primary_key => 'id',
});

1;

これで下準備OK。エントリーのpermalink, id, blog_id をデータベースに登録するスクリプトを書いてシェルから実行。

#!/usr/bin/perl -w
use strict;

use lib qw (/path/to/mt/lib/);
use lib qw (/path/to/mt/extlib/);

use MT;
use MT::Entry;
use MT::Permalink;

my $mt = MT->new(Config => '/path/to/mt/mt-config.cgi');

my $blog_id = 3;

my $iter = MT::Entry->load_iter({
	blog_id => $blog_id,
	status => 2 },{
	sort => 'modified_on',
	direction => 'descend',
});

while (my $entry = $iter->()) {
	my $permalink = MT::Permalink->new;
	$permalink->id($entry->id);
	$permalink->blog_id($entry->blog_id);
	$permalink->permalink($entry->permalink);
	$permalink->modified_on($entry->modified_on);
	$permalink->save;
}

phpMyAdminで確認する。

テーブル:mt_permhttp://junnama.alfasado.net/online/2007/06/26/permalink.jpg

ちゃんと入っているな。
これで, 前回のmtview.cgiの前半部分がすっきりして無駄な検索処理もなくなる。

my $request = $ENV{"REDIRECT_URL"};
my $url = $base_url.$request;
my $blog = MT::Blog->load({ id => $blog_id });
my $permalink = MT::Permalink->load({permalink => $url});
if (defined $permalink) {
	my $entry = MT::Entry->load({id => $permalink->id});
	if (defined $entry) {
...

新しいテーブルを作るのは面倒...な場合はサイトの運用にあわせて使っていないフィールド(entry_keywordsとか)に対してINDEX指定しておいてpermalinkを放り込んでおくという手もあるか。まぁ本来の? 使い方ではない方法で拡張するのは気持ち悪いし、MT::Objectのサブクラスの作成, 利用方法を理解していると何かと便利。SQL文を書かなくて良い(データベースの種類にかかわらず同じ書き方ができる)ところがMTのGoodなところ。

今回は本当に10分間クッキング。でもやっぱりエントリー書くのに15分かかった...

MT::Objectについては以下のページを参照くださいませ。

残りタスク

前回の残りタスクも放ったらかしですが, mt_permalinkを作ったのでエントリーを追加したり削除したりした場合にデータベースも更新しないといけない。これはプラグインで書くことになります。

post_save_entry, post_delete_entry(だったかな?)コールバックが呼ばれた時にそれぞれ「更新」「削除」すれば良いでしょう。

さらに続きはこちら

追記(2007年6月29日):
一連のエントリーで作成したものを取りまとめて公開しました。


もうちょっとだけ掘り下げてみたいと思います。というかあれこれ考えているよりTryしてみる方が早いし建設的かな。WordPressは触ったことがないのですがMTならこんな解決法もあるよ、ということで。

関連エントリー

このエントリーを書くきっかけとなった他の記事

Movable Type10分間Cooking!

再構築はインデックスやRSS, カテゴリー・アーカイブ等に限定し、エントリー・アーカイブはダイナミック生成とする。但し最初のリクエストがあった時にスタティックなファイルを生成してしまう(DBにキャッシュを保存するのではなく、そのhtmlを生成してしまう)。

※まだクライアントキャッシュのところ出来ていないのでGoogleさんに来られると嫌なので rel="nofollow" 付きリンクですが, テスト用サイトを用意してみた。そのうち削除するかも。

  • テスト用ブログ : Junnama Online (Dynamic)

まず現状のサイト(エントリー数250程度)をMTからエクスポート、新規ブログを作成してインポート。テンプレートは適当。

  1. 「設定」→「公開」→「再構築オプション」で「テンプレート別に、スタティックHTMLもしくはダイナミック・パブリッシングを選択します」にチェック。
    設定→公開→再構築オプション
  2. エントリー・アーカイブの編集画面で「このテンプレートをダイナミック・ページにする」にチェック。
    エントリー・アーカイブの編集画面
  3. サイト全体を再構築(インデックスやカテゴリー関係のみの再構築なので軽い。7秒くらいで完了)
  4. mtview.cgiを用意。実行権限を与える。
    
    #!/usr/bin/perl -w
    use strict;
    
    use lib qw (/path/to/mt/lib/);
    use lib qw (/path/to/mt/extlib/);
    
    use MT;
    use MT::Blog;
    use MT::Entry;
    use MT::Builder;
    use MT::Template;
    use MT::TemplateMap;
    use MT::Template::Context;
    
    my $mt = MT->new(Config => '/path/to/mt/mt-config.cgi');
    
    my $base_url = 'http://junnama.alfasado.net';
    my $base_pth = '/path/to/htdocs';
    my $blog_id = 3;
    
    my $request = $ENV{"REDIRECT_URL"};
    
    # /online/2007/06/mt4Movable Typebookmarklet.html
    
    my $permalink = $base_url.$request;
    my @pathes = split(/¥//,$permalink);
    my $counter = @pathes;
    my $lastpth = $pathes[$counter-1];
    my @basenames = split(/¥./,$lastpth);
    my $base_len = @basenames;
    my $basename = '';
    my $lastnum = $base_len-1;
    for (my $i = 0; $i < $lastnum; $i++) {
    	$basename .= $basenames[$i];
    	if ($lastnum-1 != $i) {
    		$basename .= '.';
    	}
    }
    
    # basename  => mt4Movable Typebookmarklet
    
    my $blog = MT::Blog->load({ id => $blog_id });
    my $iter = MT::Entry->load_iter({
    	blog_id => $blog_id,
    	basename => $basename},{
    	sort => 'modified_on',
    	direction => 'descend',
    });
    if (! defined $iter) {
    	$iter = MT::Entry->load_iter({
    		blog_id => $blog_id},{
    		sort => 'modified_on',
    		direction => 'descend',
    	});	
    }
    my $build_entry;
    while (my $entry = $iter->()) {
    	if ($entry->permalink eq $permalink){
    		$build_entry = $entry;
    		last;
    	}
    }
    
    # read template
    if (defined $build_entry) {
    	my $tmap = MT::TemplateMap->load(
    							{	blog_id => $blog_id,
    								archive_type => 'Individual',
    								is_preferred => 1
    							},);
    	my $template = MT::Template->load({id => $tmap->template_id});
    	my $preview_tmpl = $template->text;
    	my $ctx = MT::Template::Context->new;
    	$ctx->stash('entry', $build_entry);
    	$ctx->stash('blog', $blog);
    	$ctx->stash('blog_id', $blog_id);
    
    # build entry
    	my $build = MT::Builder->new;
    	my $tokens = $build->compile($ctx, $preview_tmpl);
    	my $html = $build->build($ctx, $tokens);
    	
    	print "content-type: text/html¥n¥n";
    	
    	if ($html) {
    # replay and write static file
    		print $html;
    		my $buildfile = $base_pth.$request;
    		open (OUT,">$buildfile");
    		print OUT $html;
    		close(OUT);
    	}
    } else {
    	print "content-type: text/html¥n¥n";
    	print "404 Not Found.";
    }
  5. MTが生成した.htaccessファイルがサイトのルートディレクトリにあるので削除。 新たに以下の1行のみ記述した.htaccessを生成。
    ErrorDocument 404 /dynamic/mtview.cgi

10分じゃ...終わらなかったけど、まぁ30分コース。

再構築時にはインデックス、カテゴリーアーカイブ等は再構築され、エントリー・アーカイブの再構築は行われない。

最初にリクエストがあったときに「ファイルが存在しなければ」NotFound、つまりmtview.cgiにリクエストが渡されるので、ページを生成してクライアントに返す(同時にファイルを生成する)。

アクセスがあるかどうかわからない古い奥の階層のページまで再構築する必要がないし、データベースへのアクセスは最初の1リクエストのみ、以後は生成されたスタティックなページが使われるのでCGIの起動もデータベースへのアクセスもない。

残りタスク

もちろんこれで完成ではない。「再構築」の代わりに「全消去」のプログラムが必要になる。ただMTのプラグインとか書いたことのある方ならこの処理は簡単なことがわかるだろう。

全消去が出来たらとりあえず運用は可能だけど、「ページをビルドするコストは最初に見た人に支払ってもらう」どころじゃなくてこのままじゃGoogleが全再構築してしまうので、あといくつかの工夫とチューニングが必要。

絶対にやっておきたいのはクライアント・キャッシュを有効に使う方法。
更新されていないページへGoogleが2回目以降のアクセスにやってきたらステータス304を適切に返すこと。

あとは、Permalinkからエントリーを特定するのが非効率的なので別途Permalinkとentry_idを紐付けるようなデータベーステーブルを作っておけば処理も速くなるでしょう。

その他にも再構築の範囲や全消去する時にどこまでを対象とするかを検討したり(このあたりはまさにサイトの内容とポリシーによって最適解を検討していけば良いと思う)。

WordPressだMTだってのは「ダイナミックだスタティックだ」ってな議論とは別の部分で行うべき。逆にWordPressでもこのような考え方をすればスタティックなファイル生成も割と簡単に実現できるんじゃないだろうか。

以上、Movable Type30分Cookingのコーナーでした(エントリー書くのに15分かかった...)

続きあります。

以前のバージョンからブックマークレットの記述方法が一部変更になります。お手数をおかけしますが再度以下の手順に従って設定お願いします。

ブックマークレット

設定方法

  • 「Quickedit.pl」を/plugins以下にコピー
  •  同梱されている「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>

編集したいエントリーをブラウザで表示している状態で、ブックマークレットをクリックすると該当エントリーの編集画面にジャンプします。
エントリー以外(例えばトップページ等)の場合は単に管理画面のトップへリダイレクトされます。

ライセンス

パブリック・ドメイン

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

* まだはっきりしていない部分のあるMTOSのライセンスですが, 今後公開するものについては基本的にこのMTOSのライセンスに準じるものにするつもりです。私は, MTOSについての議論がもっと盛んになり, Movable Typeというソフトウェアが(商用ライセンス版のMTを含めて) さらに良いものになって行って欲しいと思っています。

ダウンロード

関連するエントリー


MT4向けプラグイン開発についてのメモ。

新たな実行モード(例: mt.cgi?__mode=foo)を追加する方法について。

3.3までは動作していた以下の書き方($app->add_methods(%arg))はできなくなったようだ。

sub init_app {
	my $plugin = shift;
	my ($app) = @_;
	return unless $app->isa('MT::App::CMS');
	$app->add_methods(quickedit => ¥&_quickedit);
}

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

$app->add_methods(%arg)

アプリケーション・クラスに、利用可能な実行モードのリストと、それぞれのモードのコード・リファレンスを提供します。%argは、メソッド名とそれに対応するコード・リファレンスのハッシュでなければなりません。たとえば次のように呼び出します。

$app->add_methods(
    'one' => ¥&one,
    'two' => ¥&two,
    'three' => ¥&three,
);

4.0では以下のように書く(というかこれまでも(3.3で確認)既にこの書き方はできた)。

my $plugin = new MT::Plugin::Quickedit({
	name => 'Quickedit',
	version => $VERSION,
	app_methods => {
		'MT::App::CMS' => {
			'quickedit' => ¥&_quickedit
		},
	},
	description => 'Quick Jump to Entry Editor.',
	author_name => 'Junnama Noda',
	author_link => 'http://junnama.alfasado.net/online/',
});

その他のMT4プラグイン開発についてのエントリー

実のところ、僕がMovable Typeを初めて触ったのは昨年の夏以降のことです。まだ一年経っていません。プラグイン書いたりあれこれ学び出したのは秋以降です。"自分の中では"「埃を被っていたPerl」を過去の記憶から引っ張り出してきて、今や「このツールでウチのクライアントの要求は100%解決できる」自信があります。

きっかけは、去年の春に遡ります。

「CMSを導入したい。予算はあんまりない(←ありがち?)」

ここで、ウチのスタッフにオープンソースのCMSを中心に商用製品も含めて調査せよ、要件にあう物をピックアップせよと指示を出しました。

ここで選択肢に上がったのが Drupal, Nucleus。Drupalは実際にある案件で導入もしました。

この時口を酸っぱくして言ったのは「オープンソースを使うのならば、そのオープンソースコミュニティに自分がコミットしていくくらいでなければ駄目だ。クライアントが望むことがそのCMSで実現できなければ "お前が解決する" そのくらいの意識でないと駄目なんだ。」ということです。

オープンソースでなく商用製品の場合も「選択したお前が責任を持つこと(もちろん最終的には僕が責任を持つ)」を求めました。

結局、様々な条件を検討した結果(主にスタティックなファイル生成の必要が必須であった理由から) MTを選択することになりました(MODxTypo3も選択肢にあがりましたが(注1)。

さて、そこからです。

クライアントの要望、担当者のやりとりについて報告を受けているときに「それはできません」が結構多いことが気になりました。例をあげると「ページの表示順をコントロールできない」ことや「"ゴミ"ファイルができてしまう」ことなどです。

特に、「PDFファイルをアップロードして「新着情報」に載せる時、新着情報に掲載するためにダミーのエントリーを生成して追記(more)欄にPDFのURLを入力する」みたいなトリッキーな方法(文章だとわかりにくいかもしれませんがMT使っている制作会社系の人はわかると思います)で設計するものですから、PDFひとつにつき1つのゴミ(ダミー)HTMLファイルが出来る。

表示順の制御は概要(excerpt)欄に番号を入れる。入れ替えることを考慮して番号は「001-0010」「001-0020」...(こうしておくと順番の入れ替えが可能だから)。

「ありえんやろ!」

これは上司である僕の見解です。担当者にしたら「MTじゃ出来ないんだよ。無茶いいやがって気楽な身分だよなあんたは。」という気分だったことでしょう。

もちろんコストの問題や納期の問題はあるにしても、クライアントが「できるんじゃない?」といったこと(しかもすごく合理的で良くあるであろう要求)が出来ないと簡単に言うことが僕には苦痛です。クライアントから期待されているプロなのだから。

MTについて自分で色々やりはじめたのはそこからです(結局その時点の彼(担当者)はプロではなかったし、その責任はもちろん僕にあります)。

カスタマイズや拡張できる方法はないか? 結果、殆どのことは出来ることがすぐにわかりました。ライセンスの問題はあるにしてもPerlスクリプトなのですからソースを追っていけばどのように動いているかは理解できますし、APIのリファレンスも公開されています。検索すれば様々なノウハウも公開されていますから。

この時以来あれこれ制作してきましたが、そのあたりを再度整理し直したものがこのページで紹介しているものです(一部です)。

自分たちが選択したのだから自分たちはその製品のプロである必要がある。結局、僕の「プロ意識」っていうのはそういうところにあるのでしょう。もしMT3.3のセキュリティ脆弱性が発見された時にSixApartがサポートを終了していたら、僕はパッチを書いて送りつけるでしょう。それで自分の顧客が不利益を被るのであればそうします(注2)。

オープンソースであればパッチを送るもなにもなくさっさと直せば良いのです。そういう面で僕はMTが(製品とは別の何かであっても)GPL化されることに期待しています。

注1)
アウトソースも検討して実際にTypo3やMODxについて扱っている(とWebサイトで謳っている)何社かに声をかけました。でも結局僕の問いに明確に答える程ツールを熟知している人ではありませんでした。つまり、僕の定義する「プロ」ではなかったということになります。

注2)
MTのような「既にコードにアクセスできる」ものがオープンソース化される場合というのは例えばNetscapeのソースコードが公開されたっていうのとちょっとニュアンスが違います。MTの場合はソース自体はこれまでも誰でも見ることができました(よって、どこに問題があるかは第三者が見つけることが可能です。もちろん修正方法を見つけることも可能です)。あとは純粋にライセンスの問題です。
但し、コードをオープンソースにすることの価値においては、それがCだろうがPerlだろうが変わりはないと思います。

このエントリーを書くきっかけとなったページ

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


ちょっと補足。

Mobavle Typeを顧客に導入しているウェブ屋の大半が同様なんじゃないかな。SI業界だったらありえないだろうな。まだまだウェブ業界は未成熟ということなんだろうけど。

from: Movable Type 3のサポート期限での議論にみるウェブ屋としてのプロ意識というもの その2

iwaiさん流の表現なんだろうと思うわけですが、どうなんでしょう? 業界の人。
はい皆さん(誰?)「Movable Typeとの出会い, 僕のウェブ屋としてのプロ意識。」というお題でエントリーを書くこと。宿題ね(嘘)。

この話題はGPLとの件とは違うわけですが、以下のOgawaさんのご指摘にも繋がることなんだろと思っています。MT3→MT4の変化が劇的であればある程混乱する現場が出てくる。

あとはオープンソースってどうなるのでしょう。オープンソース版を商用利用するSOHO業者がGPLを理解できないせいで発生するであろう混乱が今から目に見えるようです。面白いので私の公開しているプラグインもGPLにしてやろうかな(笑)。

from: Movable Type 4ベータテスト - Ogawa::Memoranda

石川さんとは今度飲みに行って(笑)お話するとして(札幌かぁ...)、このあたりは(特にプラグインの話)はやっぱり脇が甘かった(僕ほどじゃないけど)かも...というか、プラグイン公開している人にすると, 例えばフリーで公開しているプラグインなんかにサポートとか新バージョン対応を求められても困る。かといって、これをシックス・アパート側に言うのも違うでしょう。

○実現したいページ生成・動作を、あれこれたくさんのプラグインを使って解決している ○「管理画面をより使いやすく」といったオーダーが結構ある
ゆえ、シックス・アパートに確認した、
Q3:サードパーティのプラグインは正常に使えるのですか?

from: Movable Typeが優れものであることとシックス・アパートへ要望があることは別な話

プラグインの作者へ不信感を表明するわけにもいかないでしょうから「プラグインの導入」についても「ライフサイクル」や「サポート」について考えておかないといけない。そういう点で選択したお前が責任を持つこと(もちろん最終的には僕が責任を持つ)ということになるわけですね。

かといって、サポートが云々で何でもかんでもリスク避けて...ばっかり考えていても面白くない。それ以上にそのツールに惚れ込んだのならそこは一歩踏み込んで行くのが面白いのだし自分たちの成長、他社と比較した優位性につながっていくのだと思うのです。

だからウチの場合は「基本的にプラグインは社内開発。その他のサードパーティーのものを入れる場合はライセンスを要確認(いざとなったら改編可能なら自社責任で導入OK、そうでなければ導入はNG)」となります。

あとは、ちゃんと対話すること(粘り強く, 前向きにね)。MT4Betaについてはこれまでに3通フィードバックしましたがちゃんとすべてに明確な返事をいただいています。バグレポートだけじゃなくて、今後もプラグインに関する互換性の持たせ方とかデベロッパーへの情報提供とかを求めていくつもりです。またそれだけじゃなくて僕は僕なりに分かったことをこのBlogなりで今後も書いていこうと思います。

(追記)一連のエントリーの成果品? が出来ました。

MT3/4両対応。エントリーアーカイブへの最初のアクセスがあった時点で再構築(静的ファイル生成)を行うMovable Type用のプラグイン+αのプラグラム群です。(追記ここまで)


「静的生成だとリビルドに時間がかかりすぎる。記事数が増えるにつれ、どんどん時間がかかるようになって来た。このツールは重すぎて使えない。動的生成の CMS に乗り換えたら快適になった。動的生成最高。」

「動的生成だから軽い。だからWordPressだよね!」っていうのは「俺のBlogアクセス殆どねぇから」という発言とセットである場合は正しいわけです。

アクセスが多い場合、そうは言っていられません。再構築は不要ですが、逆に閲覧時に負荷がかかります。Yahoo! Newsなんかにとりあげられたら(僕のBlogではそんなことまずあり得ませんが)データベースが悲鳴を上げることは間違いありません。

サイトの特性やアクセス状況等の前提の議論もなく「再構築不要、動的生成マンセー!」って言っている人はバカです。

動的生成と静的生成どっちが良いってのは、状況とサイトの性質、ポリシーによるのです。

「1000ページあるBlogがあって、毎日1エントリー追加。1000ページのうち900ページは5日に1回しかアクセスされない。最新の100ページはそこそこアクセスされる」というケースで、毎日1000ページすべてを再構築するのは時間の無駄ですから。

(こういったケースでは、比較的アクセスの多い100ページは静的ページを再構築してその他のページを動的生成にすると幸せになれます。)

表示されりゃぁOK! であれば別の解決方法もあります。

その昔、JavaScriptが登場した時に(こんな話すると年齢がばれるわけですが)、「JavaScriptはクライアントマシンで実行されるからサーバーでCGIを起動させる負荷が生じない」という説明がなされていてそれは正しいってことが改めて証明されている昨今ですね。

『各ページ共通部分で更新の頻繁な「最近のエントリー」とかいっそのことJSONかXMLで構築してJavaScriptで引っ張ってくればいいのに』っていうのがもうひとつの解決策です(もっと単純にObject要素でインクルードしてしまう手もあります)。

「やっぱりHTMLとしてStrictなものであるべきだろうしそれってアクセシビリティ的にどうなのよ」みたいな考え方はGoogle AdSense(このblogもそう)やその他のブログパーツを貼りまくったことでクライアント側が「重いなぁ」って感じるサイトにおいては何の説得力も持ちません。

もちろん再構築の負荷や時間を短縮するための正攻法ってのも存在します。まずはやれることからやるべきでしょう。このBlogでは以下のような考え方で再構築時間を短縮しています。

一方で動的生成の場合はサーバー・クライアント双方でのキャッシュの使い方次第で負荷軽減が可能です。サーバー側のキャッシュについては後述しますが、クライアントマシンのキャッシュを上手に使うためにはHTTPヘッダの扱いを工夫します。

以前に少し触れましたが、「動けばオッケー」的なWebアプリではHTTPヘッダとか殆ど意識されないケースが多いようですが(自分が作る時もそういう傾向は無きにしもあらず、ですが本当に負荷やレスポンスを考えるのであれば真っ先に検討すべき課題です)、この部分(HTTPヘッダによるクライアントのキャッシュの利用)の工夫をするかどうかでレスポンスや負荷は大きく変わって来ます。

但し、この方法の有効度合いもサイトの性質やユーザーの性質によって変わって来ます。

リピーターが比較的多い場合には、このようにクライアント・キャッシュを有効に扱う効果が最大限発揮されます。一方で、「リピーターはあまりいない」のであればこの方法はあまり効果を発揮しません。

そう、つまりはサイト次第なのです。

「何を重視するか」によっても変わって来ます。

「とにかくページが見られること」が最優先であれば断然静的生成です。データベースが悲鳴を上げてもページは閲覧できますし、サーバーが死んでもファイルのバックアップをどこかにコピーすれば見ることができます。

一方で、動的に動く部分(BBSやフォーラム、Wikiとか主体で動的に動く部分)が死んだらサイトとして成立しないような場合、例えばコミュニティサイト等なんかであれば、ページが見えても「使えない」わけですから、負荷はおさえる工夫はするにしても動的生成で運用すべきです。というか動的生成でないと使えません。

最後に(ここが本論なのですが)、サーバー、クライアントのキャッシュを上手に使いつつ、最初の動的生成時に静的ファイルを生成してしまう、って言う方法が実は一番合理的じゃないかと思っています。つまり、はじめてそのページにアクセスしたユーザーが「再構築」の負荷を負担する、という方法です。この方法であれば「アクセスの無い古いコンテンツ」は再構築の必要もなく、コンテンツ制作者にも全体再構築の負担がなく、最初のアクセス以後は静的生成されたページを送り返すだけですから。

このあたりの思想? をCMS(多分MTになるんでしょうが、他にも選択肢はあるでしょう)に反映させたようなソリューションを作りたいと考えています。


追記:
キャッシュの実装方法にも色々あるけれど、昔MacOS9でWebサーバーを動かしていたとき(10年くらい前) は「すべてのコンテンツをメモリに入れてしまう」という方法をとっていたなぁ。かなり強引なやり方だけどそりゃぁ(当時としては)高速だった。

実際にやってみるとこんな感じになります...

このエントリーの続き。

Google Newsとかも結局は他人のコンテンツを引っ張って来て機械的に処理してリンクを貼って「Media」を「Generate」しているわけだが、結局のところ(MashUpとかとも繋がると思うが) 他者のコンテンツを引っ張ってこようがどうしようがわかりやすい「付加価値」をユーザーに提供できればそれはスパムサイトにはならないと思うのだ。

また様々な権利的な絡みもあるだろうがGoogle Newsには直接的に広告は表示されていない。

スパムサイトが鬱陶しいのは読む価値がなく、検索した際にもノイズになってしまって邪魔だからである。

W3Cによると, 現在(2007年6月23日現在) 「WWW上には4秒に1つのスパムサイトが産まれており、15秒に1つのスパムサイトが閉鎖されている」という。 (嘘です、ゴメンナサイ!)

まぁ嘘というか根拠はないけれど、機械的に生成されるスパムコンテンツは本当に人間の書き手の作るコンテンツをはるかに上回る勢いで増殖しているように思う。検索エンジンの質が落ちたとはいわないが、ブログ検索ではどのサービスを使ってもノイズが多くなっている。もちろんスパムとノンスパムの境界ギリギリのコンテンツもあるだろう。

スパムとノンスパムの違いはそのコンテンツに価値を認める人がいるかどうか(広告主やサイト運営者を除いて)。

このようなリンクの引用がベースであるWebコンテンツの価値とは「編集」であり「表現」である

特にマッシュアップというか他のコンテンツを再利用して構成し直すタイプのコンテンツの場合、そこに「編集」や「表現」といった意図がなければ無価値であるしノイズでしかない。「価値の提供に対する収入を得る」ということから逃げ出している人を見ていると怒りを通り越して悲しくなってくる。

またそういった人を対象としたスパム生成マシーンを作っている似非プログラマの人たちに言いたい。

別に他者のコンテンツを加工しても構わない。でもどうせやるなら価値を提供できるアルゴリズムを作って大いに儲けたまえ! あなたも明日のGoogleだ!

ということで、「編集」と「表現」の一例を示す!?

アルゴリズムは秘密手動。何かにツッコミを入れたブロガーの記事の中から最も印象深いセンテンスをピックアップして淡々と紹介する。さらにインパクトの強い語をさらに強調する、という感じで以下のようになる。

皆さんネタにしてすいません。申し訳ないのでトラックバック飛ばしません!

Bloggerがツっこむ時

(ちょっとした編集アルゴリズムを加えることで価値!? を付ける例)

わかってない。わかってない。わかってねえ!

From: 404 Blog Not Found:書評 - Rubyクックブック

Rubyクックブック @ 2007年04月 @ ratio - rational - irrational @ IDMのあるパラグラフに対する小飼弾さんのツッコミ。

ニュースを見てこんなに腹が立ったのは久しぶりです。

From: 無印吉澤 - プライバシー侵害の幇助者 / Winny特別調査員2

Winny特別調査員2(ネットエージェント)のリリースに対する吉澤さんのツッコミ。

ブログの世界はこれからどんどんつまらなくなる。

From: 深町秋生の新人日記 - ブログ衰退論

資本主義の大波がブログ界に押し寄せていること、ブログが広告化していることなどに対する深町秋生さんのツッコミ。

馬鹿は死ねと言いたい。

From: 高木浩光@自宅の日記 - キンタマウイルス頒布にマスコミ関係者が関与している可能性

日経ビジネスオンラインの記事「ウィニーこそ史上最強の「ジャーナリスト」?」武田徹氏の記事に対する高木浩光さんのツッコミ。

さあ、GIVE ME A TRUTH あなたの真実は?

From: 21人の弁護士に懲戒請求を求める - 光市母子殺害事件 (Web屋のネタ帳)

表題のサイトに対するWeb屋のネタ帳さんのツッコミ(エントリーの締めくくりの一文)。

それって結局「大衆ウケしないと意味ない」ってのとほぼ同義だろ。

From: つまらなくて役に立つ物を作るということ (最速インターフェース研究会)

ゲームプログラマとWebプログラマについて? 最速インターフェース研究会さんのツッコミ。

日経BBって何だよ!*

このページこのページの両方を見た俺のツッコミ!

*日経ブロードバンドニュースのことね。

ね、ちょっと手を加えるだけでこんなに素敵になったでしょ!?(違)

というかスパムサイトは死ねといいたい。

えー、SOHO事業者でWeb屋で有料ではないけどCCライセンスとかでプラグイン公開しちゃってた人として、これはこれでちゃんと考えておかねばなるまい。

Movable Type 4ベータテスト - Ogawa::Memoranda

あとはオープンソースってどうなるのでしょう。オープンソース版を商用利用するSOHO業者がGPLを理解できないせいで発生するであろう混乱が今から目に見えるようです。面白いので私の公開しているプラグインもGPLにしてやろうかな(笑)。

Movable TypeのラインセンスがGPL化されることが意外と知られてない/理解されてないらしい - Web屋のネタ帳

システム屋からすると「ふーん、ようやくGPLになりますかそうですか」程度のことなのだが、Web屋(デザイン寄りの人)からするとGPLという言葉の意味自体からして???なのかもしれない。

hiromasa.zone :o) » WordPress と Movable Type と GPL と

無料になってわーいっていう感じもありますが、ふと有料プラグインとか作っている人たちが微妙に困ったことになるような気がしてきました。

今日 (おそらく初めて) シックス・アパート社 (日本法人) から「オープンソース」についてのリリースがなされた。

重要なポイントは先のエントリーにも書いたが、以下の部分である。

Movable Type のオープンソース版は、これまでMovable Typeとは異なる領域への、新たな挑戦となります。まず、誤解のないように定義しますと、Movable Type 4 と Movable Type オープンソースは、別のプロダクトとなります。もちろん多くの部分は共有されることになるかと思いますが、それぞれのプロダクトは、異なる目標をもっています。

すんごく申し訳ない見解ですが「なかのひと」が「ブログ大好きな」個人ブロガーであるかどうかは(多分)あまり関係ない(SOHO Web屋的事業者にとっては)。多くのSOHO事業者にとってはライセンスの問題は結構大きいんじゃないかと思う。

(追記)↑良く考えてみたら大した問題じゃなかった。少なくとも自分にとっては。っていうのと、開発者が「想い」を持てるプロダクトに参加できているっていうのはすんごく幸せなことだ。だからこそライセンスの問題やコミュニティとのコミュニケーションに失敗して寂しい思いをして欲しくないと(切に)願う。

嫌な書き方をするようだけど、僕はいつでもWordPressやDrupalやMODxやTypo3に移行する準備はしている。その一方で、これまでにつくりためたMTのプラグインとか、商売のネタとか考えずにぜーんぶ公開しちゃおうか, GPLライセンスにしようか? っていう気持ちもなくはなくて何だか悩ましいと感じている。

とにかく今でもMTはライセンスの解釈が難しいと思うが、以前にも色々あったらしい。「らしい」というのは僕はまだユーザー暦半年ちょっとでしかなくて、そのあたりのニュアンスを肌で感じることがなかったからだ。


※ちょっと酔い気味かも...↑ということでここまでは酔っぱらいの戯れ言。

ということで翌日になって続き。

GPL版と商用版が分かれるということで、

  • 商用版にオリジナルのプラグインや拡張プログラムやテンプレートを付加してパッケージ作成するのはOK (もちろんMT本体は購入してもらう)。
  • GPL版をプリインストールしたホスティングサービスとかを商売でやるのはOK、GPL版を拡張するためのプラグインやGPL版本体のMT自体に手を入れることもOK、但しそのバージョンはGPLライセンスとなる。

とこういう認識で良いのだろうか、違うかな。というかまだ決まっていないのでしょう。

ただ、この場合だとGPL版のMTに対して第3者が凄い「キラーアプリケーション(プラグイン)」をリリースした時に、その成果をSixApart社が商用版に取り込むことができるのか、できないのか。できないのだとしたらSixApart社にとっては値上げに対するユーザーコミュニティの反発を和らげる以外にメリットがないように思える。

僕の場合は、MTが好きで個人的にごちゃごちゃいじくったりプラグイン作ったりするのが好きな「個人」の部分と、受託のサイト制作のCMSとしてMTを使う部分と両方あって (特に酔っぱらうと) 両者が入り交じってくるのでわけがわからなくなるのだけど、えーっと、このエントリー的には後者の見解を書かないといけないのだな。

オーダーメイドの受託制作の場合は、GPL版と商用版を比較して5万円が充分な付加価値になるか5万円分の開発コストの縮減が見込まれるのであれば商用版を使う。そうでなければGPL版を使う。ということでWeb屋の自分としては何も困らないということが明らかになったな(何か違うか!?)。

結局雑文になってしまって真面目に読んでくれた中の人ゴメンナサイ。

ただ最後に要望・質問的なこと(というか疑問? か、日本語って難しい)をいくつか書いておきます。

  • 日本語でのMTOSに関する(中の人と外の人を含んだ)情報交換の場は設ける予定はないのでしょうか?
  • 独自に作成したプラグインのライセンスはどうすべきなのでしょうか?
  • 独自にオープンソースでない商用製品を開発するにはどのようにすべきなのでしょうか?

なんか本当にわけのわからない文章になってしまった。みんな(誰?)ゴメンナサイ。

あ、あと全然何も深い考えはないのですが、mtos.infoってドメインとってMT4βをインストールしてみた。

小粋空間さんのところでホットなエントリーが上がっていたり, Web屋のネタ帳さんのところでは「もろに」GPL化の話が触れられており (両エントリともソーシャルブックマーク等で大量にブックマークされています), そのあたりを受けてようやく国内でも反応がぼちぼち上がって来ています。

僕もmixiのMTコミュでも話題を振ったり地道に? やっていたわけですが, MT4の値上げの話やGPLの件が日本法人のリリースにないのはどうなのよ!? みたいな論調もちらほら見られており僕も少々責任を感じて...(嘘!)。

というのが関係あるのかないのか分かりませんが、シックス・アパート株式会社(日本法人)の「技術情報提供ブログ」にてオープンソースについての話題が(初めてでしょうか?) 触れられています。

何故「技術情報ブログ」 ? とかこれまでの技術情報ブログではエントリーに「投稿者」が入っていたのに今回は入っていないとか(6月23日追記:投稿者欄にJun Kanekoさんとあります)穿った見方をすればきりがないわけですが、まずはしっかりと読んでみたいと思います。

感想等は後ほど書くことにしますが、色々言われていた件ですがMT4とオープンソース版が「別のプロダクト」であることがはっきりと述べられています。

Movable Type のオープンソース版は、これまでMovable Typeとは異なる領域への、新たな挑戦となります。まず、誤解のないように定義しますと、Movable Type 4 と Movable Type オープンソースは、別のプロダクトとなります。もちろん多くの部分は共有されることになるかと思いますが、それぞれのプロダクトは、異なる目標をもっています。

巷では商用ライセンスの売上げに影響するからどうとかいう指摘もあるようですが、僕はそうは思っていませんでした。遅かれ早かれ話題として火がつくのは分かっていたと思いますし、むしろ火がつかなかった時の方が(きっと)ヤヴァイわけですから。

関連する話題など


追記:
Movable Type4とMovable Typeオープンソース版は一応別物らしい - Web屋のネタ帳経由。

Movable Type.org: Welcome to MTOS: the Movable Type Open Source ProjectにおけるByrne Reese氏のコメントにこんな表現が。

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

長いタイトルになってしまった...。つまり、5つまでのリンクを登録しておいてランダムにリンクを生成して出力するプラグイン。あ、MT4対応ね、一応。

使い途あんまりないと思うけど(Perl版MTでダイナミックなページってあんまりないだろうから)このサイトの携帯版でアフェリエイトとかやる時に便利かなと思って(10分間Cooking!)。

何となくアマゾンのアソシエイトのリンクとか貼ってみたので、ラクダ本とか「大人買い」する時は是非(この間O'reillyのPerl関連本4冊程、紀伊国屋で「大人買い」しました。重たかった...)。

タグは、<$MTRandomLink$>。リンク先の登録はブログ毎に。

ライセンスはGPL(違)...いや、まぁ10分クッキングなので必要のある方がいらっしゃいましたら自由にお使いください。

プラグイン設定画面

Download

あんたがスパムやろ(nofollow付き)ってのは置いておいて。

10,000万件ほどTrackback打って9999件が無視して1件が受け付けてくれたら...立派な「ロングテール」やな。

トラックバック代行サービスって、どうせやるなら「受信代行サービス」やりなはれ。

ってことで、今はCGMとかはもう古くてSGM(Spammer Generated Media)の時代。SGMっていうのが今はナウいんでっせ!

こんなエントリー書いてていうのもなんだけど...いいや、書いちゃえ。

バカは死ねと言いたい!

関連するエントリー

ニュースを見てこんなに腹が立ったのは久しぶりです。このソフトは、明らかな害悪だと思います。

以前からOne Point WallなどのWinny対策製品を販売しているネットエージェント社が、「Winny特別調査員2」という製品を発表しました*1。以下は、ネットエージェント社のサイトに掲載されている、この製品の特徴です。

紹介というか、言及されているのは以下のソフトについてらしい。

Winny特別調査員2は、「調査員CD」を会社が従業員に配布し、従業員が自宅のPCにCD-ROMをセットすることで、会社関係のファイルを自動的に見つけ出し、ファイル回収専用サーバにそのファイルをアップロードします。また、自宅PCからはファイル復旧ソフトを使っても、ファイルが復活されないよう完全に削除します。

僕は法律の専門家ではないから法的なことに関するコメントは差し控える。

プライバシーの件についても思うところはあるが、僕がひっかかったのはどうやって仕事関連の書類であるかを判断するか、そのアルゴリズムについてである。まさか単なるキーワードのマッチングだけじゃあるまい。
いくらキーワードを登録するのが調査をする側だとはいえ「間違ったファイルがアップされたり消去されたら、返却すれば良い」問題だろうか?

検索のアルゴリズムについてはサイト上では触れられていないようだ(どこかに書いてありますか?)。この部分の設計と開発はとても難しい筈だ。検索エンジンの検索結果が気に入らなければ舌打ちをすれば済むが、この手のプログラムが意図しないファイルをひっかけてしまったら舌打ちでは済まない。

意図しないファイルをヒットさせてしまったら色んな意味で不幸である(もちろんヒットして欲しいものがヒットしなければ何の意味もないわけだが)。

何も社員や下請け事業者だけじゃなく、調査を実施した会社も不幸になりかねないと思う。


実はここからが本題だったりする...

仮にヒットした書類が優秀な社員の職務経歴書と履歴書、他社への転職のための応募資料だったらどうだ。会社のPCならともかく、個人所有のPCである。応募書類には(もちろん職務規程に反しない範囲で)仕事上のことや会社名が書いてあるだろう。そしてそれは個人の自由である筈だ。

「しょくぎょうせんたくのじゆう〜 ぁはは〜ん」(古っ!)

会社側はファイルを開かずにそれが何かを判断できるのだろうか? 収集されたファイルは開くのだろう。

こうなったらもうお互い不幸である。警察の書類に名前を書かれていた女優さんも不幸だが(真偽は不明というか僕には分かりませんが)、「見たくなかった」けど見てしまったあなたはどうするのだろうか。まさか「応募書類見たぞ。ちょっと考え直してくれないかね」なんて言えますか?

恋人の携帯電話をチェックすることで不幸になるのは覗かれた方だけではないのだ。


追記:
ファイルを持ち出されるのが嫌、あるいは流出が怖いのであれば既にいくつかのソリューションがある。目先を変えたいのはわからないでもないが、このアプローチはどうなのだろう、というか「調査員」というネーミングにも違和感を感じる。


ところで、無印吉澤さんのページではウチの会社がコーディングしたページも引用されていて世間は狭い(<違)と感じましたというのは全くの余談。

注:エントリーのタイトル変えました

5万円って、たかだか1日か1.5日じゃねぇか(200万円の案件で考えたら余計にそうじゃね)。MTを使うことでその程度の工数が短縮出来るのであれば利益も出るだろう。

でなければ無理して使う必要はない。

オープンソース化されるわけだ。使いたかったら使えばいいし。
むしろ何を提供できるかね。GPL化されるMTに対して。

ましてや「コミュニティと対話する」と言っているわけで(日本法人じゃないけどね)。

自分たちの立場(都合)を主張してるだけのお気楽な「制作会社」は淘汰されればいい。どうすれば共存できてどうすれば「共に」発展出来るか。もっとシンプルに考えるべきではないのだろうか?


追記:
あ、一応僕は「とにかくわかりやすいマップ普及推進委員会」のファンですので。

各所で話題の? Transformerプラグインが4.0で動作しない! 件 (あんまり話題になってないのか?) ですが, 両対応するプラグインをひとつ書いてみました。プラグインの書き方や改造のヒントになれば。

関連エントリー

Transformerプラグイン開発関連ページ

今回改造したプラグインはエントリーの編集画面のプレビューにテンプレートタグやCSSを反映させるStylePreviewプラグイン

プラグインのダウンロード

え? そもそも4.0でデフォルトでちゃんとプレビューできるって?

そうかい, そんなこと言うなら, じゃぁ、書かねぇよ!というのは冗談で。

4.0ではエントリー編集画面で「Preview」ボタンをクリックすると, 表示された画面にiframeが入っていてフレーソ内に再構築された一時ファイル(716e33a47fa625eea57c6c428664685d923cf5ca.html みたいな名前で生成される)が入るようになっています。画面を遷移するとちゃんと一時ファイルは消えますが、プレビュー画面でブラウザウィンドウを閉じると一時ファイル(つまりゴミ、というか意図しない途中段階のファイル)が残ってしまうので注意が必要です。もちろんベータバージョンなのでリリースまでに改良される可能性はあります。

このプラグインは「一時ファイルを生成せずに」CSSやテンプレートタグが適用された状態でのプレビュー画面を表示させるものです。いずれにしても4.0になったら需要は殆どないと思いますが、今回はTransformerプラグインを両バージョンに対応させる例ということで。

MT4.0でのTransformerプラグイン

やっと本題。

以前にも書きましたが、MT4.0ではTransformerプラグインのためのコールバック名称が変わっています。

AppTemplateSource => template_source (テンプレートのソースに対する処理)
AppTemplateParam => template_param (テンプレートに渡されるパラメタに対する処理)
AppTemplateOutput => template_output (テンプレートエンジンの出力結果に対する処理)

lib/MT/Compat/v3.pm に以下の記述があるように、「大切でない(コールバックのエイリアス)マッピング(何故ならv3のレガシーなコールバック達はおそらくうまく動かないだろうから」ということのようです。コメントアウトで「一応」書いてはあるので最終リリース時にどうなるかはわかりませんが。

    # Unnecessary to map since all the v3 legacy callbacks would fail
    # anyway.
    # $MT::CallbackAlias{'AppTemplateSource'}   = 'template_source';
    # $MT::CallbackAlias{'AppTemplateParam'}    = 'template_param';
    # $MT::CallbackAlias{'AppTemplateOutput'}   = 'template_output';

まずはバージョンを取得して変数に入れておきます (プラグインの先頭付近に書くと分かりやすいかと思います) 。

my $mt_version;
my $v = MT->version_id; 
#->4.0 Beta 1 
if ($v =~ /^4/) { 
	$mt_version = 40;
} elsif ($v =~ /^3¥.3/) {
	$mt_version = 33;
} else {
	$mt_version = 32;
}

TransformerプラグインはMT3.3からの機能ですから, 4系であれば「40」3.3系であれば「33」それ以外であればここでは仮に「32」とします。「32」の場合は BigPAPI が使えるので, できるだけ多くのバージョンに対応させるのであればこの3種類を分岐させて処理を書けば良いでしょう。

バージョンを取得したら, バージョン毎に MT->add_callback を分岐させます。

if ($mt_version == 40) {
	MT->add_callback('MT::App::CMS::template_output.preview_strip',9 ,$plugin, ¥&_StylePreview);
} elsif ($mt_version == 33) {
	MT->add_callback('MT::App::CMS::AppTemplateOutput.preview_entry',9 ,$plugin, ¥&_StylePreview);
	MT->add_callback('MT::App::CMS::AppTemplateSource.preview_entry',9 ,$plugin, ¥&_PreviewTmpl);
} elsif ($mt_version == 32) {
	# BigPAPI用のコールバックを書くのであればここに
}

あとはバージョン毎のテンプレートやメソッドの変更等に応じて適宜コードを分岐させます。

今回はさほど変更点は多くありませんでした。テンプレートの部分以外では一カ所のみ (4.0では $app->translate_templatized($template->output); としないとページを生成できませんでした)。

	if ($mt_version == 40) {
		$preview_tmpl = $app->translate_templatized($template->output);
	} else {
		$preview_tmpl = $template->text;
	}

個人的に思うことですが、Transformerプラグインの場合, テンプレートを正規表現等で置換していって管理画面をバリバリ・バキバキとカスタマイズしていく場合がこれまで多かったように思うのですが(自分もそうしていました)、このやり方にはインストールが簡単である(プラグイン本体を設置すればそれだけでOK)というメリットがある反面、今回のようなメジャーバージョンアップでCMSのテンプレートが大きく変わった時には何とも大変な修正を強いられることになります。

メンテナンス性のことを考えれば、今後はできるだけテンプレートのカスタマイズは「alt-tmpl」で行って(tmplフォルダ内のCMSのテンプレートをalt-tmpl以下にコピーしてそちらに手を入れるようにする), 動的な処理のみをプラグインにようにした方が良いと思います。

...って、書き終わったらベータ3が出てるやんけ!

書き手を選ぶのでなければ「編集」という言葉の意味を少しは考えるべきではないか。

何故にWeb屋は黙っていられるかね。


※こんなのに好き放題言わせていていいのかね?

こちら経由↓

このうち開発会社の問題は深刻であり,「中小規模のWebサイト構築で顕著だが,Webのデザイン制作を主体とする開発会社の場合,セキュリティ意識が無い会社が多い」という。納期が短い上に,仕事はいくらでもあるため,1つの顧客,1つの案件について脆弱性の検査などしていられない,というのが制作会社の実態というわけだ。

氏はセキュアスカイ・テクノロジー設立以降6カ月に渡って,Web制作会社10社と対話を繰り返したが「制作会社に期待してはいけないとの結論に達した」(乗口氏)。

ウチのような会社のことですね。ご指摘有り難く存じます。

ところで、氏に質問させていただきたいと思います。

※答えは期待しておりませんが、万が一お答えいただけましたら本ブログにてご紹介させていただきたいと思います。
もしご回答いただけるのでしたら、こちらまで電子メールにていただければ幸いです(もちろん何らかのメディアを通してのお返事であっても歓迎いたします)。

  1. Web制作会社10社とありますが、選定はどのような基準で行ったのでしょうか。
  2. 「制作会社に期待してはいけないとの結論に達した」根拠はどこにあるのでしょうか。
  3. 「企業のWebアプリケーションには100%脆弱性がある」のはどの程度の事実に基づいているのでしょうか。
  4. 「企業のWebアプリケーションには100%脆弱性がある」わけですが、あなたの会社の(あるいはあなたが運営に携わる)サイトに脆弱性はないのでしょうか? 脆弱性は100%存在するわけですからやはり「脆弱性はある」と捉えて宜しいでしょうか。

質問は以上です。何卒よろしくお願いいたします。

氏には是非とも納得のできるご返答をご用意いただきたいと思っております。

こういう書き方をするとまた「本筋から離れた議論」とかいうツッコミが来るのか来ないのか来ないなら来ないで寂しいような...ってのは置いておいて、これまでちょっとふざけたエントリー続けてたから、今回は普通に。

僕は生産的なことが書ける「専門家」でもなければ「SNS」に逃げ込んだりもしないが、 現状の「はてなブックマーク」は僕の中では「PG12」以上「R15」以下、くらいの位置づけか。

ウチの長男(小学生中学年)との話を想像してみる(勝手に登場させてごめんな、Tさん)


※Junnama(私), 長男=T

Junnama:
ほら、こんな風にお父さんが作ったウェブサイトをみんながこんなに褒めてくれているんやで。
T:
すごいやん。
Junnama:
すごいやろ。Tもさぁ、好きなホームページとかあったらこんな風にしてみんなに紹介すると、ほら、こんな風にみんなで共有できるんや。ウェブって面白いよなぁ。
T:
うん、こっちも見ていいかな? これ何て書いてあるの? 「しればいいのに...」
Junnama:
ああ...そ、それはな、もっとお勉強して良いこと書けるように頑張れよ、っていう意味...かな?
T:
じゃぁ、これは? 「しねば...いいのに」うわ...いっぱい。
これって...ひょっとして、いじめ?

ということで、僕にとっては現状では立派なPG12扱いである。

12歳未満(小学生以下)の鑑賞には不適切な表現が含まれるものには、成人保護者の同伴が適当。性・暴力・残酷・麻薬描写・ホラー映画・小学生が真似をする可能性のある映画が審査の対象になる。

まぁ、成人保護者の同伴があってもちょっと現状では説明しにくい。もちろん物事のどんな面もきちんと教えていきたいと思う。ただ大の大人が侃々諤々やってもちっとも噛み合ないことを「これ!」とスパっと説明できるレベルの問題でもないだろうし。


T:
「ゆーざー登録」って、お父さん、登録してもいい?

さて、どうなんだろう。利用規約を読んでみる。

ざっと見たところ年齢に関する制限事項は見当たらない(間違っていたら教えて欲えてください)。
※登録フォームのセレクトメニューは「2007」から選択できるようになっているし...(ゼロ歳から登録できます?なんだろうか、とかそういう言い方はしないでおこう。)

一方、第6条(禁止事項)のところを見てみると以下のようになっている。

2.ユーザーは、本サービスを利用するに際し、以下のような社会的に不適切な行為を行ってはなりません。
(略)
 3.倫理的に問題がある低俗、有害、下品な行為、他人に嫌悪感を与える内容の情報を開示する行為。ポルノ、売春、風俗営業、これらに関連する内容の情報を開示する行為。
 4.迷惑行為、嫌がらせ行為、誹謗中傷行為、正当な権利なく他者に精神的被害・経済的被害を与える行為
(略)
 7.その他、公序良俗に反するかあるいは社会的に不適切な行動と解される行為

結局、「他人に嫌悪感を与える」というところには主観的な要素もあるが、少なくもと何人かは「嫌悪感」を抱いたことは事実であろう。『どこからどこまでを「禁止行為」とし、「禁止行為」を行ったユーザーをどうするか』求められるのはまずはこの部分の説明なのだろうと思う。これは決して「コードで解決するかどうか」といった問題ではなく、『利用規約』に同意を求めてユーザー登録したユーザーに対して説明が必要なことである筈だ。


何でこの問題に(僕に限らず)拘るかというと、これは何もはてなだけの問題ではなくブログをひとつ開設する、とか (ましてやネットに限らず) パブリックなスペースに身を置くということだけで誰もが遭遇する可能性のある問題だからだ。

コンビニエンスストアを開けばコンビニ強盗(強盗と一緒にするな、とか書くなよ)の脅威とか入り口のドアの前にたむろして他のお客が入りにくかったり地域のPTAから疎まれたりとか、飲み屋を開けば酔っぱらいに絡まれてアルバイトの女の子が泣いてしまうとか、色んなことに直面するリスクは避けられない。

で、その時店長というか経営者は女の子が酔っぱらいに絡まれて泣いてしまったら放っておいてはいけないのだ(池田先生が泣いてる女の子かい! とか書くなよ)。


僕が常々ウチのスタッフに言っていることだが (面接の時にも言うけど) 「会社が小さかろうがなんだろうが、やっている仕事には誇りを持てるようにしよう」「少なくともあなたの身近な人、恋人や両親や子供に『(例えば)お父さんの仕事って、どんな仕事?』って聞かれた時に自信を持って説明できる仕事をしよう」「そんな会社にしよう」といつも思っているし言い続けている。

だからこういう問題から(運営者は)逃げちゃいけない。


原典がちょっと見つけられなかったので別のところから引用させていただく。

何億円持っているとか、いいクルマを乗り回しているとか、そんなことは死ぬときには何の自慢にもなりません。それより「ネットでたくさんの人が使っているあのサービスはぼくが考えたんだ」といえるなら、それは死んだ後も自慢になる。ぼくはそういうものを作っていきたいんです。

THINK!2006夏号 はてな近藤淳也氏インタビューより


「お父さんは仕事でこんなものを作った」と目の前のTに言えること。
僕にとっては、まずはそこが一番大切だ。

もちろんどっかの誰かが流出させやがった...ということも考えられるわけだが、何らかのページ(MLの過去ログとか、酷い場合にはWebアプリの管理画面とか)がGoogleとかにキャッシュされているかもしれない。

以下、メモ。

そのメールアドレスをGoogleで検索する。見つかった! というとき。

ログイン後のページがGoogleにキャッシュされていたら(検索インデックスに登録されてしまっていたら)以下のページから削除申請。

Webpage removal request toolの画面

最初の画面では Information or image that appears in the Google search results. にチェック。 自分が管理していないページだった場合, 次の画面では I've been unable to work with the site owner, but the information appearing in the search results is one of the following: にチェックを入れる。

次の画面でURLコメントには「My email address is open to the public. (by エキサイト 翻訳!)」とか何とか入れておく。だいたい0.5日くらいでキャッシュとスニペット(要約)が削除され(まだこの時点で検索結果にはひっかかる), 1日後には検索結果も表示されなくなる。

ありがちな問題を防ぐためのメモ(PHPの場合)

PC向けサイトでは(.htaccessかApacheのconfファイル)

php_value session.use_only_cookies 1

としてGETパラメタ(PHPSESSID等)でのセッションを無効とする。

携帯サイトでは(Cookieに対応していないもの向け)

php_value session.use_only_cookies 0

とし、この場合はリファラからセッションIDが外部へ流出するのを防ぐため外部サイトへのリンクは直接貼らない(セッションIDの付いていない中間ページを経由させる...基本か。)

GETパラメタでセッション管理をしているページやメールアドレス等が含まれているページについては

<meta name="ROBOTS" content="NOINDEX, NOFOLLOW">
<meta name="ROBOTS" content="NOARCHIVE">
<meta name="GOOGLEBOT" content="NOSNIPPET">

を指定しておく(保険程度と認識しておくこと)。もちろんセッションの有効期限を短くしておく等の基本的対策はおさえた上で。

MLの過去ログなんかで「検索させたい」ページである場合はメールアドレス等や電話番号等を削除して掲載するようにする(自分が管理していないページであれば依頼する)。

ええ、タイトルはネタで且つ釣りです。ごめんなさい。僕は弾さんに同意ね

はてブにて「マジレスは筋違い」とか書いてる人もいるけど、「誰の会社か」ってのは本質じゃないんだ。

マッシュアップ基盤の提供等で世界60億人のクリエイティビティがGoogle等に集約されるようになり脅かされ始めている。

たかだかネットの話で60億人はねぇだろ。ウチの3人家族(1人小学生含む)のうち1人はGoogleはおろかYahoo!も知らない(あ、Yahoo!キッズは知ってるか)。あとは...ブログパーツ(←ブログパーツが重要なのかよ!)なんて知らないけど「価格.com」は知ってるぜ、もう一人は。

See also↓

A社の彼(誰だかわかんないけど)は「ココギコ」氏に愚痴ってる暇あったら(愚痴ったんじゃないのだったらココギコ氏に喋った時点で残念ながらイタイ失敗したわけだし), とっととブログパーツ(しつこいか?)の会社にでも行けば良いし、あ、Googleが良いんだったか、Googleに行けばいいわけだな。

まぁ他人のことばかり言うのは何だから自分のことを言えば、スーツ着て営業してマネタイズして時間作って余った時間でコード書いてます。えぇ、楽しいですぜ。ブログパーツは作っちゃいませんけどね。

えーっと、あとは何だ、「さっさと辞めちゃえば!?」

と、たまには煽り気味に書いてみるテスト。


あ、コメントくれるんだったら炎上防止のために「ルー語変換プラグイン」入っているので怒らないでね。

MT4Beta2をFastCGI環境で動かしてみた。特に問題なく動く。ひと安心。

で、さぁこれから色々触ってみようということでTouchMe Pluginを放り込む。

だめだってさ。

MT4のソースを見てみる。$app->add_methods(%arg)がなくなってる。 ちょっとしたショック...代わりっぽいのも見つからない。仕方ないな...

エラーが表示された様子

ということで、MT4対応(MT3非対応) TouchMe Plugin。FastCGI上でMTを動かしている環境で、プラグイン一覧のページに行くとAdminScript, CommentScript , TrackbackScript, SearchScriptを touch します。スクリプトに対して書き込み権限が必要なので、僕はとりあえず該当スクリプトのオーナーを apache にしました。

Download:

何かオープンソース化で盛り上がってるのって俺だけ?

mixiのMTコミュで書いても誰ものってくれなかったし...ぐすん。

id:jkondo氏が語らないことには何もわからないし何も評価に値しない。



(追記)
少々煽った書き方になったが、はてブが「コミュニティ」であればモデレータが何とかすべきだし、はてブが「コミュニティ」でないのであればコードで解決すれば良いと思うのだ。

モデレータ不在のネットコミュニティが荒れなかったことは(多分)ないし、「コミュニティ」でなく「インフラ」なのであれば(Googleライクに)コードで解決をすれば良い。そして(これもGoogleのように)「判断しているのはあくまでも機械でありアルゴリズムですよ」と言い切れば良いのだ(UIで解決を試みるという手もあるだろう)。

いずれにしてもそれを判断し表明するのはトップであるべきはないのかなぁ?


もうひとつ追記。
この手の問題は今に始まったことではないのだ。昔? から話題になっていて、議論の対象にもなっていたわけだよ。

なんだろうねぇ、この日本のBlog界 (というかはてな界隈というか) を覆う閉塞感? やりきれなさ? ネットイナゴ問題?

PhotoPierre: さんのコメントにインスパイアされて悪ノリしてみる。

炎上・祭り管理機能がMT4.20あたりに実装されるよう、プラグイン開発をお願いします!! 売れば売れたりして。

  • 普段の平均コメント数、コメントとコメントの平均時間などを計測
  • タイミングがX倍になったら、警告メイルを発信
  • さらにY倍なら、コメント自動休止「キャパシティを超えるコメント投稿のため、一時的にコメント受付は管理人の承認後となります」
  • NGワードの登録、共有

名前はfirerescueでお願いします。

(全部冗談です)

付け加えて、

  • はてブ2ちゃんを巡回してチェックしたりリファラチェックして炎上の兆候がないか定期的に予測する。
  • NGワードの登録、共有に加えて、観測サイトの登録・共有。
  • 巡回・登録には 超迷子: 共同体的全文検索系 Hyper Estraier のクローラを使い、ノードサーバを連携させて共有する。これぞP2P!
  • 度を越したサイトやブクマについては運営者へ削除要求, 警告を送るためのメールを自動生成。

と...妄想するのは良いのだが、結局コメントスパムやトラックバックスパム対策と同じでネガティブな対策にならざるを得ないよなぁ。

要するに、問題が発生してから対策を施しても駄目ということなんだよ。

もっとエレガントに解決しないと。

プロのウェブ屋ってのは、「問題が起こらないようにする」ことを第一に考えるのだ。

つまりは...

炎上・祭りになってから動くのではなく、ましてやスルーするのでもなく、「炎上を未然に防ぐ」究極のしくみ。

それは、「ネガティブコメントを入れる気や批判する気にならなくなるしくみ」。

って、考えてたらあるじゃねぇか。

ルー・メソッドを使えばいいのだ!

ネガティブコメントだと判断したらそいつを「ルー語」に変換してしまうのだ。
コメント投稿者はやる気がなくなって攻撃するのがアホらしくなってしまうだろう。

ということで、「ネガティブコメント判定」は面倒なので「ルー語変換」だけ作ってみた
期間限定。コメント欄に入力されたテキストはすべて強制的に「ルー語」変換されます。

注) 野田, 気が違ったんじゃねぇか? 仕事大丈夫か? と思われるとまずいので、そのうち削除するかもです, このエントリーごと(笑)。


まぁなんだ、トゥギャザーに楽しくやろうぜ。たかがブログじゃねぇか。ファイヤーとかフェスティヴァルとか、何だってんだ。俺はいつもバーンしてるぜ!


ってことで、要するにルー語変換プラグインですな。

テンプレートタグにこんな風に書いてフィルターとして動作させるもの。誰か要ります?


<$MTCommentBody Lou="1"$>

今回はこちらの辞書を使わせていただきました。

オリジナルの「ルー語変換」はこちら。

CSRFについての説明部分については, これは駄目かな。残念ながら。
僕が今までに書いた脆弱性やセキュリティ関連の解説は今のところ○さんも絶賛のユーザーもクライアントもハッピーな代物だけど、本当はこの手の話は書きたくない。頭禿げそうになるもの。

CSRF(Cross Site Request Forgery)は、本来拒否すべき外部のWebページからのHTTPリクエストを受け付けてしまうというバグによって起こります。

Ajaxかい!(←欧米かい! 的なイントネーションでっせ) この説明が駄目だ。分かりにくすぎる。外部のWebページからのHTTPかどうかは関係ないというか、それを判別出来ないのがHTTPなのだから。

GETは使用しないといった対策が有効です

だから有効じゃないってば(この場合に限ればGETかPOSTかは関係ないし)。

まぁいいけど...頼むからブクマして「勉強しなきゃ」とか言うなよ。皆の衆。

Movable Type 4 ベータ2。

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

追いつかんな...

とりあえずベータ1では

  • これまでに作成したプラグインのうちTransformerプラグイン系はそのままでは動かない。
  • モブログは少々修正が必要なもののとりあえず動いている。
  • 日本語化されていない。プラグインで定義した L10N::ja ファイルの中身も反映されない。

あんまりレポートになってませんが...

※炎上・祭り管理機能っての作ったら時節柄? ウケそうな気が。

フレームを今まで無視していたのだけど, とりあえずリンクにするようにした。

各エントリーで前, 次の移動のアクセスキーの「絵文字(?)」にまつわるバグの修正。Nakedで実装した結果の一部をMoblogへも反映。DEL要素の処理とか。

類似というか, イメージしているWebサービス(製品)は SimpleWeb なわけだけど, やっぱり負けてるなと思う部分もある反面いくつかの部分では「後発」ならではのより優れた部分も既にあると思う。もう少し頑張ってみよう。

  • 配色や見栄えを変えた場合も以降のページに設定を引き継げる
  • PDFをテキスト化できる
  • ルビを振ることができる
  • 画像や埋込みオブジェクトを(うまく)リンクとして扱える
  • 携帯電話向けに最適化できる

今週はこいつにデザインを施してみようと思う。

言語系やオープンソース系のイベントに女性は殆ど見かけませんけど, CSS系のイベントには女性は沢山いますよ。いやほんまに。

WebDesign & HTML書き

XHTML+CSS

XHTML+CSS+PHP(or JavaScript)

XHTML+CSS+PHP(or Other Lightweight Language)

という流れができれば自然に女性は増えると思うけど。

少なくとも僕の周りに「PHPをマスターしたいんですけど」っていう女性は少なくないですよ(Perl とか Rubyになると...いないなぁ)。

Webやってて, +αの表現力を身につけたい, そういうところでスキルアップしたいっていう女性は多いと思う。

さて、どうでしょう? 識者の皆様。 各所で何かと話題のPHPですが。

Movable TypeのプラグインからPerlに入るってのもあるかと思いますね(ないかな?)。
とにかく, 「Web」っていう括りでは決して女性は少なくないもの。

新しいUA(UserAgent)を作ろうとした時に困る。


僕はUserAgent開発者でもないしUserAgentを新たに書く力量もないけれど、こんなものを作ってるとこんな問題に遭遇することがあるのだ。

CSSについても、特にmediatype絡みのハックであると(media ttyとかね)、こういうケースで頭を悩ませることになる。

それは仕様です」って言い切っちゃえば楽なんだろうけど、トリッキーなCSSが普及していて新しく作ったUAが「使えねー」とか言われると開発のモチベーションも下がるだろうし。

えーっと、このブログのCSS見られると困るけど(MTのStyleCatcherで引っ張って来たCSSをちょいと直しただけだから)、まぁこういう意見もあるというか、UA開発者の立場に立ってコーディングするという視点を持つと更に視野が広がると思うな。

でもね、こういう疑問を持つこと・考えることはとても大切なことだと思う。

引き続き、MTのオープンソースライセンスについて

対WordPress?

WordPressのシェアがどうだからというのは本質ではないと思う。どっちにしてもそのあたりの憶測は誰かが書くだろうから僕は書かない。

Perlコミュニティへの貢献。

CPANにmt/lib/MT以下のモジュールが一気にUPされるのである。追記:CPAN云々の件は認識がちょっと違うのかな...という気がしていますが、いずれにしてもPerlでの開発に有効に使えるGPLライセンスのライブラリ群が出来ることには違いないでしょう。PerlでのWeb系の開発だけならMT::Utilだけでも自由に使えることに分かりやすい意味がある。

何せ、MT::Utilだけでこれだけある。

@EXPORT_OK = qw( start_end_day start_end_week start_end_month
                 start_end_period week2ymd munge_comment
                 html_text_transform encode_html decode_html
                 iso2ts ts2iso offset_time offset_time_list first_n_words
                 archive_file_for format_ts dirify remove_html
                 days_in wday_from_ts encode_js get_entry spam_protect
                 is_valid_email encode_php encode_url decode_url encode_xml
                 decode_xml is_valid_url discover_tb convert_high_ascii 
                 mark_odd_rows dsa_verify perl_sha1_digest relative_date
                 perl_sha1_digest_hex dec2bin bin2dec xliterate_utf8 
                 start_background_task launch_background_tasks substr_wref
                 extract_urls extract_domain extract_domains is_valid_date
                 epoch2ts ts2epoch escape_unicode unescape_unicode
                 sax_parser);

DBIについては後述するが、MTというのはつまりPerlベースの高機能テンプレートエンジンであり、開発プラットフォームなのだ。そして何よりMTをベースとして開発する以上、Webデザイナーとのスムーズな協業が可能になる。何しろ「テンプレート・タグ」をWebデザイナーがテンプレート・タグを理解している唯一! のテンプレートエンジンなのだから

MTのラインナップとSixApart社のビジネス展開。

オープンソース版と商業ライセンス、そしてもう一つラインアップがある。Movable Type Enterprise である。

CMS製品として考えると、Movable Type は非力な部分はあるが圧倒的に安い。3万円が5万円になっても安い。但し、個人向けライセンスと商用ライセンスを用意している時点で、且つ厳しいアクティベーションによるライセンス管理をしていない(様々な理由からできない)現状では、Movable Type の商用ライセンスというのはいかにも半端な価格設定なのだと思う。

ログインすると「Movable Typeニュース」が画面の右上に表示される、ということはSIxApart社には実際のユーザー数がログ等から分かるのだ。これは想像でしかないけれど、アクセスログから見るユーザー数と実際に登録しライセンス料金を払っているユーザー数の間には大きな開きがあるだろう。

であればMovable Typeのライセンス収入は考えずに(実際は様子見だろう。3万円から5万円の値上げ、彼ら自身もドキドキしながら反応を伺っているに違いない)、Enterpriseに注力していくのは当然だろう。CMS製品としては決して高く無い商品なのだから。そして実際にリリースやProNETミーティング等で感じるのはEnterprise版への力の入れようである。

おそらく、オープンソース版から得たものもEnterpriseに活かされていく筈であり、当然そういった期待を持っているだろう(それはすごく真っ当なことであり、全面的に賛同する。僕もそうするだろう)。

MTコミュニティのMovable Typeへの貢献。

個人的にはMT3.3をオープンソース化して欲しいと思う。それは無理だと思う。何故なら、SIxApart社の側にメリットが殆どないからだ。 (彼らにとってはセキュリティホールや脆弱性が発見された時の負荷を軽減できるな。誰かが修正してくれるだろうから。誰もいなけりゃ僕が修正するよ。)

数多くのプラグインプログラムがMTを魅力化した一因であることは確かだろう。そしてそれはコミュニティの貢献に他ならない。だからこそこれだけエネルギーをつぎ込んだMTに対する思い入れやこれまでにソースを読み、時にはハックして作成したプラグインがアーキテクトの変更によって使えなくなるのは正直辛いものがある。

だからといて今回リリースのMT4系がコミュニティと隔離されては(SixApart社にとっては)無意味なのだ。コミュニティから得るものがなくなってしまうから。

SixApart社のリリースが建前で対WordPressだけを考えているのであればMT3系をオープンソース化すれば良い。建前でなく、本当にユーザーやコミュニティと共に進歩していきたいのであればオープンソース化するのはMT4である。コミュニティもアーキテクトの変更に伴う痛み(やエネルギー)を共有すれば良いのである。

(追記)
GPLにしたことで、MTOS向けに開発されたGPLである成果は商用のライセンスやエンタープライズに取り込むことは難しいのだと思う。例えばプラグインがデュアルライセンスとかでリリースされたら別だけど。

プラットフォームとしてのMT。

PerlモジュールとしてのMTの本質的な部分はDBIをとにかく分かりやすく、DBの種類を意識せず(これは移植性にもつながる)開発出来るしくみを持っていることだろう。

MySQL, PostgreSQL, SQLite...MT4に至ってはOracleもMsSQLServerに対しても違いを意識せずに書くことができるのだから。

例えば、ログイン機能付きのWebアプリケーションやWebサービスを作るにあたって、ログイン、ユーザー管理が標準で準備されているMTを使えばスクラッチで開発することと比較して圧倒的に有利だろう。実際、Blog, CMSとして使わないのにMTをプラットフォームとして使いたいケースが多々ある。しかも、これまで気にしながらやってきたユーザー数によるライセンスコストの縛りがなくなるのだ。

※ プラットフォームとしてのMTについては、こちらも参照

Web制作者への影響。

すべてはここまでに書いたことの繰り返しになるが、手っ取り早い開発プラットフォームとWebデザイナーが理解済みのテンプレートエンジンを手に入れることができることには大きな意味がある。
また、商用CMSの価格の高さと(これまでの)オープンソースプロジェクトの隙間を埋める存在になるだろうし、制作者はそのあたりの「隙間」をビジネスにしていくことだろうと思う。

とにかく、僕は歓迎である。MT4に対しても出来る限りのフィードバックをしていきたいと思う。

既に各所で報じられている通りですが、第3四半期にMovable Typeのオープンソースバージョンがリリースされる模様です。Movable Type Open Source Project のトップページでFAQ的に書かれている部分をざっと読んでみました。

シックス・アパートの日本法人からも何らかのアナウンスや情報提供があることを期待していますが、まずは本家? のメーリングリスト(英文)に参加してみました。日本でも盛り上がると良いなと思います(というより, 盛り上げましょう、是非)。

以下は What is the Movable Type Open Source project? から Why is there a lag between the launch of the commercial and open source versions of Movable Type? までの6つのパラグラフです (翻訳には誤りが含まれているかもしれません)

原文はこちら(Welcome to MTOS: the Movable Type Open Source Project)


2007年6月8日20時06分翻訳を一部修正 (読みにくいのでDEL要素はCSSで非表示にしています)


Movable Typeオープンソースプロジェクトとは何ですか? (What is the Movable Type Open Source project?)

Movable Typeオープンソース(MTOS)は Movable Type4.0のGPLライセンスバージョンであるオープンソースプロジェクトで, 2007年第3クオーターにリリースします。 既に実在している Movable Type 開発者の大きなコミュニティへのリソースでもある www.Movable Type.org/opensource が主催します。 そして既に大きな Movable Type デベロッパーのコミュニティへリソースを提供するために www.Movable Type.org/opensource にホスティングいたします。

なぜオープンソースオプション? (Why an open source option?)

それは簡単です: 私たちの顧客と私たちのコミュニティーは Movable Type のオープンソースバージョンを求めました。 Movable Type コミュニティの多くの顧客と開発者は彼らが彼ら自身の必要性のために自由に変更することができる Movable Type のバージョンを探していたのです。さらに, 他のオープンソース製品に Movable Typeのオープンソース版をバンドルすることを目指しているコミュニティーのメンバーがいます。 私たちはこのオプションの実現について検討していましたが、「MTOSのベースをMT4のラインに位置づける」と決めていたため、今回のこの発表がMT4リリースと同じタイミングだったのです。 私たちは, しばらくこのオプションを考えていましたが, MTOSのベースをMT4のラインに位置づけると決めました(この発表がMT4リリースと同時である理由です)。

なぜ今? (Why now?)

MT4 は, Movable Typeプラットホームの未来と同様に, これまでの Movable Type のどのリリースと比較しても, 多くの人月を費やして開発された総決算とも言えるバージョンです。私たちは, そのようなMovable Type 4を紹介する時期こそがその格好の時期であると感じていました。

商業バージョンのMovable Typeは放棄するということでしょうか? Movable Typeの商業バージョンを捨てるのでしょうか? (Are you abandoning the commercial version of Movable Type?)

いいえ、絶対そんな事はありません。実際の所、今まで1度もこんなにも商業用のMTの成功を確信した事はありませんし, マーケットの見通しを実感した事もありません。Movable Typeはインストールベースのウェブログプラットホームよりもっと企業的なもの, 例えばメディア・教育機関で使われていますし, だからこそ他の開発者やパワーブロガー, 個人的なユーザー達が求め続けてきたオープンソース事業の実現が簡単になるのです。Movable Type4.0 は Movable Type の歴史の中でのどのバージョンよりも大きな開発投資を行った商業バージョンです。
そのリリースは私たちの商業バージョンの成功の確信を証明してると言えます。
絶対にそうしません。実際私たちは, Movable Type の商業上の成功に打ち込んできたわけではありませんし, マーケットの見通しについて一度も興奮したことがありません。Movable Type はいかなる他のインストールベースのウェブログプラットホームより企業, メディア, 教育機関で使われています。ですからその成功によって, デベロッパーやパワーブロガー, 個人的なユーザが求めていたオープンソース製品を提供することがこれまで以上簡単になるのです。Movable Type4.0 は Movable Type の歴史の中でのどのバージョンよりも大きな開発投資を行った商業バージョンです。

どのように Movable Type のオープンソースバージョンを得ることができますか? (How do I get the open source version of Movable Type?)

この夏の後, MTOSディストリビューションはwww.Movable Type.org でダウンロード/チェックアウトが可能になるでしょう。

Movable Type の商業バージョンとオープンソースバージョンのリリースにタイムラグがあるのは何故ですか? (Why is there a lag between the launch of the commercial and open source versions of Movable Type?)

Movable Typeのオープンソースバージョンをリリースする前に, 私たちはその開発やライセンスの範囲についてコミュニティと議論したかったのです。

さらに, 私たちはベータリリース期間中に製品の品質を向上させ, 私たちが学んだことすべてをオープンソースバージョンに取り入るために充分な時間が欲しかったからです。オープンソースプロジェクトに関してさらに知るために, ウェブサイト http://www.Movable Type.org/opensource/ へアクセスしてください。



追記: 日本での反応は? まだこれからといったところでしょうか。

僕の思うところ, 感じたことについては以下に書いてみました。


(さらに追記 - 6月19日)相変わらず静かですねぇ。[MTOS-dev]メーリングリストにしても時々テンプレートまわりの話題が飛ぶくらい。
タイミングが遅かった? 日本では積極的に告知してない? ってか、ソーシャルブクマとか見ても、MTってこんなだったっけ? っていうのが正直なところだな。

MT→MTなのにトラバが飛ばない。仕方ないのでこちら(はてブ)にリンクしておく

↑こちら経由ですが、↓こんな意見も。

コメント欄にいくつか情報がありましたので補足しました。

Movable Type4.0でCMSの内部はどう変わったか。

Movable Type4.0βでは管理画面のインターフェイスもデザインも大幅に刷新されているからTransformer系プラグインはそのままでは動かないだろうとは思っていたが「動かない」というレベルの話ではないようだ。

CMSのテンプレート自体も変わっているがそもそもCMSのテンプレートの書き方自体が大きく変わっている。

例えばBlogのIDを表示させるには、V3では「<TMPL_VAR NAME=BLOG_ID>」(HTML::Templateを使用)、V4では「<mt:var name="blog_id">」。

Movable Type v4.0 (Athena): A Developer's Perspective (Movalog: Movable Type Tips & Tricks)」より(訳はかなりいい加減)

We had to resort to crude search and replace techniques that would search for a line of code and replace it with what we wanted.

This had the lovely effect of breaking plugins at even the most minor of changes. With v4.0, a series of DOM-like methods have been introduced (including getElementById,
getElementsByTagName so on and so forth). These methods allow us to easily find fields and markup within app templates and should, hopefully, mean that Transformer plugins are less prone to break. A great example of how these methods work is on the edit template page. New with 4.0, when a template contains an MTInclude tag, a link to the template is automatically shown in the sidebar.

これまでは粗雑な検索に頼って必要なコードの行を捜し求めて、それを私たちが欲しかったものに置き換えるテクニックを利用してきた。この方法には少しの変化でプラグインが動かなくなる問題があった。

V4.0では、一連のDOMのような方法を導入した(getElementById、getElementsByTagNameなどを含んでいる) 。

これらのメソッドは、私たちが(APP)CMSテンプレートの中から簡単にフィールドやとマークアップを見つけることを助けるだろう。

これはTransformer pluginsがより「壊れにくく」なったことを意味する。

テンプレート編集画面の「インクルード」テンプレートを表示する部分

これがどのように役立つかについての素晴らしい例が「テンプレート編集画面」にある。 新しくなった4.0のテンプレート編集画面ではテンプレートがMTIncludeタグを含むとき、テンプレートへのリンクがサイドバーで自動的に表示される。

CMSのテンプレートの記法は随分変わっているからv3系のTransformerプラグインは動かないだろうが、書き方自体は変わっているのだろうかということで簡単なプラグインを書いてテストしてみた。

MT->add_callback('MT::App::CMS::AppTemplateSource.preview_entry',10 ,$plugin, ¥&_AltPreview);

動かない。CMSのコードを調べてみる。

$ find . -name "*.pm"|xargs grep 'AppTemplateSource'
./MT/Compat/v3.pm:    # $MT::CallbackAlias{'AppTemplateSource'}   = 'template_source';

lib/MT/Compat/v3.pm

    # Unnecessary to map since all the v3 legacy callbacks would fail
    # anyway.
    # $MT::CallbackAlias{'AppTemplateSource'}   = 'template_source';
    # $MT::CallbackAlias{'AppTemplateParam'}    = 'template_param';
    # $MT::CallbackAlias{'AppTemplateOutput'}   = 'template_output';

つまりは「大切でない(コールバックのエイリアス)マッピング(何故ならv3のレガシーなコールバック達はおそらくうまく動かないだろうから」ということらしい(だからコメントアウトされたままだ)。

で、このコードを見てわかる通り「template_source,template_param,template_output」というコールバックが新たに加わっている。

つまり以下の通りv3からコールバック名が変更になる。但しそのまま入れ替えてもテンプレートも記法も変わっているから動かないだろう、ということ。

AppTemplateSource => template_source
AppTemplateParam => template_param
AppTemplateOutput => template_output

ということで、以下のようにすることでTransformerプラグインが動作することは確認した。
モノにもよるが移植は結構骨のある作業になりそうだ。

MT->add_callback('MT::App::CMS:: template_source.preview_entry',10 ,$plugin, ¥&_AltPreview);

時間があればもう少し突っ込んでみたい。

軽量・低機能? のMovable Type検索プログラム

MT4.0βが公開されたので、インストールして少しずつ触っているのだが、mt-search.cgi の立ち上がりが速くなっていると感じるのは僕だけだろうか?
記事数が少ないからまだ何とも言えないけどね。

ということで(どういう繋がりやねん)、これまでいくつか書いたプラグインとかプログラムの中でMT4が出たことで不要になったものを順次公開していこうと思う。ドキュメント書くのが面倒で公開していなかったものとか商売のネタにしようと思っていたものとか理由は様々だけど、あまり気にしないでいきましょう。

ひとつ目はmt-search.cgiの代替プログラムとして書いたもののうち軽量CGI版

この間「公開されてないの?」ってコメントもいただいたし(何しろmt-search.cgiで検索すると4位とか5位に表示されるし)。

現状このブログの検索はHyper Estraierを使った「超」高速版なんだけど、サーバーにソフトウェアをインストールできない人とか、エントリー数はそんなに多くないんだけどmt-search.cgiじゃ遅い、また「単純に検索できれば良い」という人向け。

Entryをループで回して正規表現で検索しているので、決してインデックス型検索エンジンのように超高速ではないけれど、

  • 低機能? (タグの検索とかはできない, ログも残らない) だけど軽量
  • HTMLタグの中身はひっかけない
  • ページ送りが可能
  • ヒットした文字列のハイライト

といったところがメリットといえばメリット。もちろんテンプレートはカスタマイズ可能。FastCGIにも対応。

サンプル

モバイルサイトには、これをベースにしたもので検索を付けてみた。

サーバースペックにもよるけど、200エントリ程度だと結構サクっと動く感覚です。

ダウンロード

ライセンス

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

Apache/2.0.55 (Ubuntu) mod_fastcgi/2.4.2 PHP/5.1.2, DBはMySQL という環境で、まずは動かしてみた。

ファースト・インプレッションは後ほど。

DBの構造

内部的なことから書くと、DBのテーブル数が20→25に増えている。

※以下、追加されたテーブルについて。
いい加減なこと書いているかもしれんので悪しからず。

  • mt_asset(ファイルを管理するもの?)
  • mt_association(投稿者とグループ?)
  • mt_objectasset(mt_assetに登録されたデータの属性?)
  • mt_objectscore(スコア?)
  • mt_role(グループ毎の権限?)

mt_entry等の既存のテーブルの構造はざっとみたところあまり変わっていない模様。

mt-config.cgi

mt-config.cgiの中に、ORACLE, MSSQLSERVER のブロックが追加されている(SQLITE, BERKELEYDBは見つからない)

#================ AUTHENTICATION =====================

とあって、認証サービスの関連の設定なのだろう。

WYSIWYG

これはオリジナルで開発したんだろうか? それともどこかのものを買い取ったかライセンス契約したのだろうか。「VOX」向けにもともと開発したものらしい。Safariでは多分無理かと思っていたが、やはり駄目。

Firefox(Camino)はOK。

吐き出されるHTMLは...こんなもんと言えばこんなもんだが「<br>」はないだろ。 まぁCMSとして運用する場合に、HTMLがわからない人が編集する分には...といったレベルか。

WYSIWYG

※HTML中の改行はこちらで挿入

Firefox(Camino)

<a href="http://www.sixapart.jp/Movable Type/beta/">Movable Type4</a>がリリースされた。<br>
使用感よりも内部構造がどうなっているかが気になるが、<br>
とりあえずはまず使ってみよう。<br>

Safari

<P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica">Movable Type4がリリースされた。</P>
<P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica">使用感よりも内部構造がどうなっているかが気になるが、</P>
<P style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Helvetica">とりあえずはまず使ってみよう。</P>

プラグイン

プラグインの書き方に大きな違いはなさそうだ。ただ、管理画面のデザインが大幅に変わっていることから、Transformerプラグインの移植には手間がかかると思われる。管理画面のデザインだけの問題でもなさそうだ(MT4.0, CMSの変化とTransformerプラグイン。)。

まずはこんなところか。一番気になっていたモブログのインストールはそれなりにスムーズに出来たので一安心。

一部で報道されているようにオープンソース化するのであれば、何より楽しみである。

関連情報

b→strong, i→em, s→del とか出来る範囲で変換する

これは意味あるのかね? (名無しさん)


From:音声UA

意味があるかどうかは自分で考えてみれば宜しい。

ドラえもん:「シッ、のびたくん、その言葉言っちゃだめ」

のび太「どうしてさ、ドラえもん。未来ではGoogleはどうなってるのさ?」

ドラえもん「Googleは、Googleは...」

続きはご自由にどうぞ。

See also

Movable Type 4。

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

Six Apart - Six Apart: シックス・アパートが、最新ブログ・ソフトウェア「Movable Type 4」を発表

シックス・アパートは、サーバーインストール型のブログ・ソフトウェア「Movable Type(ムーバブル・タイプ)」の最新版、「Movable Type 4 日本語版」を、2007年7月18日より出荷することを発表いたします。また本日より、同製品の公開ベータテストを開始いたします。
「Movable Type 4」は従来の製品と比べ、画面インターフェースを大幅に刷新し、単なるブログ用途だけではなく、企業サイト全体を構築できるCMS(コンテンツ管理システム)としても進化しています。

詳細はプレスリリースをご覧ください。

思ったより早かったな。忙しくなるなぁ。色々検証しないといけないし。
まぁ企業としてやっているわけだから、早期にリリースしていくことは大切。

しかし、5万円という価格設定は微妙だな。

FastCGI環境でMovable Typeを動かしている場合、プラグインを追加したりしてもそのままでは反映されない。一度起動したものが常駐? するようになるからだ。

プラグインの追加等を反映させるためには、ログインしてtouchコマンドでファイルを更新してやる必要がある。

で、これが面倒臭いので、ファイルをtouchするプラグインを書いてみた。

Download:

※メイン・メニュー→プラグイン で表示される以下のプラグイン名称部分のリンクをクリックすると暫くしてから画面が更新されます。

プラグインの起動

パーミッションとかファイルのオーナーの関係でCGI(fcgi)からtouchできる設定になっていないと更新されません。なので、本番環境というよりもプラグイン開発者がローカル環境とかで使う、とかいうケースで使えるでしょうかね。

AdminScript, CommentScript , TrackbackScript, SearchScript を対象にしています。

他のファイルも対象にしたい場合は改造等ご自由に(再配布もご自由にどうぞ)。

あるサイトでFAQを探そうとして「ませんか?」というキーワードを入れて検索したのだ。

Google「ませんか?」の検索結果

話しませんか?
いいよ。話そう。
抱きしめても怒りませんか?
何だ? 今どきはこんなことばで検索するのか? 何を期待して検索するんだろう...と思ったら本のタイトルなわけですね。って、これが噂の「Fujyoshi」向けなのか? あぁびっくりした。
うちのタマ知りませんか?
ごめん、知らない。っていうか、これはアニメとかキャラクターのタイトルなわけね。
一緒に死にませんか?
ごめんだね。死ぬならお一人でどうぞ...っていうより、「関連検索」と称して「死にませんか?」って誘われた気分だよ。どうにかならんのかね。Googleさん。

こういうワードにこそフィルターが必要ではないかい?

Facebook

Twitter

このアーカイブについて

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

前のアーカイブは2007年5月です。

次のアーカイブは2007年7月です。

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

Powered by Movable Type 6.2.6