今回の恐慌に対する自動車業界の反応はものすごいスピードだが、たぶんあれだけの必死な対応も未来から振り返ってみれば焼け石に水かも、と思わせるところがあるから大変だ。むろん、それが分かっているから必死なのである。しかし、巨大な経済圏が健全であることを前提に発展して肥大し尽くした業界は、経済の収斂には耐えられまい。数字に根拠はないが、勘としておそらく半分ぐらいかそれ以下の規模まで減り、企業数も相応に、ビック３も当然１社生き残るかどうかぐらいなんじゃないかと思っている。その上、電気自動車やハイブリッドカーと言った、より環境負荷の低い方向にシフトする開発は止められない。

逆に言うと、規模の収斂に耐えられるような体制作りが望まれると言うことだ。むろん現状の大量生産的な分野をいきなり潰すことは現実問題としてやってはいけない類のものなので、ゆっくり且つ速やかな（どっちだ）転換が求められるだろう。それをいかに政府が支援するかと言うことだが、光岡自動車のようなバックヤードビルダーを優遇するのはどうか、と考えている。

このバックヤードビルダーが生産する車を仮にグルーブB車（以下B車）、今までの車をグループA車(同A車）としよう。B車はつまるところ「安全装備も検査も一定基準以下の、少量生産車」であり、以下のような点で優遇を受けられる。

• 従来よりゆるい製品検査基準


• 従来より低くて許される安全基準、保安基準


• 従来より安い税金

こういった点を軽減することにより、開発および取得コストを大幅に減らそうと言うものである。少量生産であるので、当然かなりの部品共有などは避けられないだろう。一方、B車はそういう問題以下のような規制を受ける。

• 従来より厳しい車検基準（例：毎年）


• B車運転者に対する厳しい規定（酒気帯び即免許取消、罰金倍額のような強い罰則、免許に対する縛りなど）


• 生産台数規定


• 自主規制ではなく、法令による明確な規制（馬力、サイズ、etc...)


• （おそらく）高い保険料金

B車によって作られるのはおそらくは「スポーツカーなど趣味性の高い車」「独創的なデザインで高性能を目指したもの」「特注扱いの金持ち向け高級車」などの類であろう。こういった多様化が少ないコストでなされるようになれば、ある程度自動車業界のダウンサイジングは進むのではないかと思うのである。むろんコスト高になるのは避けられないだろうが、一方それを抑えるためでより強力なコンポーネント化、規格共通化も進みやすいのではないか。

個人的には、既存の自動車メーカはそのコンセプトからも、B車を作ってはいけない（代わりに子会社にでも作らせろ）と考えている。特にエンジンのような中枢部品はノウハウが相当蓄積していることもあり、既存メーカーはサプライヤーとしての地位も確保できる。まあ現実には販売網もあるので、こうやってできたバックヤードビルダーもメーカーとの親密な関係を当面続けざるをえないだろう。

今の車を見ていて思うのは、なにより画一化が進むことによって、あらゆる装備を満載するような方向に向かっていることだ。これはOSと同じ（なにもWindows Vistaだけの話ではない）だが、全部入りを提供しているために不要なものまで抱え込んでしまって、かえってパフォーマンスを落としてはいないか。また、車種ごとの開発費も、要求が高くなるためどんどん高くなり、管理の煩雑化を避けるために要求そのものを画一化せざるを得ない状況は、正直に言って自らの首を絞めているんじゃなかろうか。

まあ、L.starは自動車業界とはほとんど関係がないので、ここに書いたことが実際に可能かどうかというのを検証できるほどの資料も持ち合わせていない。しかし、このように巨大化した業界のダウンサイジングは、、組織化された大規模開発から再び少数精鋭への揺り戻しということで説明できると思っている。CPU業界がシングルスレッド最重視からマルチコアへと移っていくように、大企業社会から高度に連結された中小企業体社会に移るのは必然で、今がその良い機会じゃないかと言いたいのだ。

昔pgpoolとheartbeatを組み合わせて２ノード冗長化＋負荷分散を実装するというpgpool-HAというプロジェクトをやっていたことがある。まあ、今やっていないかというと単に必要がないのでいじっていない。まだ日本にいた頃に細かい変更を施して、その後は最新版でも動くようになっている。まあpgpool-II対応は最善ではないので細かい修正は可能ではあるが、追従する必然は無いのでとりあえず放置状態である。

で、たまに見ると質問とか出ているので、昔やった何とかで一応答えるのだが、今日は

http://pgfoundry.org/pipermail/pgpool-general/2008-December/001374.html

に、pgpool-IIをフロントエンドにウォームスタンバイ型の冗長化構成にする、というOCFなスクリプトが出ていたので反応してみた。

個人的にはリカバリにpgpoolをわざわざ使わず、Heartbeat付属のpgsql用のOCFを改造して、warmstandby対応にするほうが楽なのかな、と言う気がしてきたので、考えていた。しかし、

• start時にはstandbyからの回復コマンド実行
• stop時にはスタンバイで起動開始
• recovery時は起動し直す
• status、monitor時の挙動は全面変更。なにしろ常にPostgreSQLが動いているから。
• ん？stop状態なのに起動していない場合はどうするんだ？
• そもそもスタンバイ状態とでも言うべき状態はheartbeatでサポートしていたっけ？
• いつベースバックアップをどうやって取るの？

とまあいろいろ問題も思いついてきたのでやめた。warm-standbyは取り扱いが結構難しいなぁ。

久々にプログラミングの勘を取り戻そうとかと思いつつ、wordpress2.7にアップデートしたところ動かなくなってしまったpublish To Mixiプラグインを修正してみた。

通常下の方に表示される投稿のためのフォームが、なぜか左上に表示される。怪しいと思っていたら、単純にHTMLタグより先に出力してしまっているらしい。

何かつらつらと読んで、とりあえずplugin APIとアクションに付いての説明を理解する。なんとなくアスペクト指向っぽいな、と思いつつフックのコードを見る。なんとなくフックの挙動が違っているな・・・と思いつつ、grep使って、同様のフックを使っているAll-in-one SEOプラグイン（宝の持ち腐れ:))と見比べるとビンゴ。2.5以降は別のフックを使っているようだ。と言うわけで同様のアクションに置き換えてみるとあっさり動作。

変更前：
add_action( 'dbx_post_advanced', 'renderOption');
add_action( 'publish_post', 'publishHandler' );
変更後：
if (substr($aiosp->wp_version, 0, 3) >= '2.5') {
add_action( 'edit_form_advanced', 'renderOption');
} else {
add_action( 'dbx_post_advanced', 'renderOption');
}
add_action( 'publish_post', 'publishHandler' );
こんな感じ。プラグインエディタならそのまま編集できるのでありがたい。別途ダウンロード版を用意する予定は今の所ありません。