Kodougu を comet 実装してみました。例によって FireFox 以外の動作はしません（IE や Opera でも表示は可能、一部操作もできてしまうがバグバグです）。ブラウザを二つ起動して、片方を操作するともう片方もリアルタイムに・・・。

試してみたい方は、こちらを参照してください。（英語のみ。）

近いうちに Kodougu のモデリング言語設計機能を紹介したいと考えています。がんばって実装しないとナー。

Kodougu で comet を実装する必要があるのですが、自分で実装するのもしんどいので、cometd を使ってみることにしました。

■ 注意
本記事は、cometd の trunk のヘッド（2007/5/7 時点）を参照しながら書いています。あなたが読んでいる時点で、本記事の情報が古くなっている可能性があります。

■ 環境
Windows XP SP2

■ 準備（必要なソフトウェアのインストール）
1. Python 2.4.4（インストーラあり、EasyInstall もインストールすべし）
Python Japan User's Group

※ EasyInstall のインストール方法は少し下のほうに記述してあります。

2. Twisted Python 2.4.0（インストーラあり）
http://twistedmatrix.com/trac/
※ 最新の 2.5.0 では、Twisted Web2 との互換性の問題で、正常に動作しません。

3. Twisted Web2 0.2.0 のインストール
http://twistedmatrix.com/trac/wiki/TwistedWeb2
python setup.py install

4. simplejson 1.7.1（EasyInstall でインストール）
http://cheeseshop.python.org/pypi/simplejson
easy_install simplejson

5. path 2.2
http://www.jorendorff.com/articles/python/path/
python setup.py install

6. cometd のインストール
6.1. cometd のチェックアウト
以下のアドレスからチェックアウトしてください。
http://cometd.googlecode.com/svn/trunk/
6.2. cometd-twisted フォルダ内の setup.py を書き換えてください。
data_files という項目を、「/etc/cometd」から「scripts」に書き換えてください。
6.3. setup.py の実行
python setup.py install
6.4. cometd.tac の編集
＜＜Python Install Dir＞＞\scripts\cometd.tac で設定（ポートやログファイルなど）を変更することができます。必要に応じて編集してください。

正直、Python に詳しくないと、きついと思います。私は Python にはまったく詳しくないので、この辺は結構きついです。わかりにくいところは質問してください。

補足：EasyInstall のインストール
x.1. 以下のファイルをDL
http://peak.telecommunity.com/dist/ez_setup.py

x.2. 以下のコマンドを実行
python ez_setup.py

■ cometd の起動
＜＜Python Install Dir＞＞\scripts フォルダ内で以下のコマンドを実行してください。
twistd -noy cometd.tac

補足：原因不明のエラー
私の環境では、＜＜Python Install Dir＞＞\Lib\site-packages\twisted\python\log.py の 228 行目をコメントアウトしないと、正常に動作しませんでした。原因については、現在調査中です。

# err()

■ dojo（0.4.2）からの呼び出し
Publisher/Subscriber モデルになっているので、簡単に使うことができます。以下におおよその使い方を書きますが、cometd の exmaples に dojo を使った例が豊富にあるので、参照しながら進めるようにしてください。

1. dojo.io.cometd の読み込み
dojo.require("dojo.io.cometd");

2. dojo.io.cometd の初期化
cometd.init({}, "http://127.0.0.1:8080/cometd")
※ 第一引数は、オプション設定。何が設定できるのかは不明。調査中。
※ 第二引数は、cometd サーバの URI。

3. 購読開始
cometd.subscribe("/channel/name", true, this, "acceptMethod")
※ 第一引数は、購読するチャンネル名。
※ 第二引数は、調査中。false にするとチャンネル名の先頭に "/cometd" が付加されるが何の意味があるのか・・・。
※ 第三引数は、メッセージ受信時のスコープになるオブジェクト（だと思う。。。）。
※ 第四引数は、メッセージ受信時のメソッド名。

4. メッセージの配信
cometd.publish("/channel/name", {name: "hoge"})
※ 第一引数は、配信先のチャンネル名。
※ 第二引数は、配信データ。

補足：IE、Opera で、Syntax Error が出る場合
以下のファイルの 510 行目に「}), }」というような記述がある場合、「})}」というように修正してください。私はこの修正で正常に動作するようになりました。
/dojo/src/io/cometd.js

補足：FireFox を使っている場合の問題
私の環境依存の問題である可能性がありますが、同一 PC 上で、FireFox クライアントを二つ起動以上したとき、publish したメッセージをクライアントで受け取ることができないという現象が発生しました。現在、原因調査中ですが、私は IE と FireFox など異なるブラウザであれば問題は発生していないので、テストはその組み合わせで行っています。

以上、cometd の使い方でした。

ここしばらく Apollo や Silverlight など、クライアントサイドの新技術が登場しています。Rails のブログを見ていたら、Slingshot という製品が紹介されていました。

Slingshot goes public
http://weblog.rubyonrails.com/2007/5/2/slingshot-goes-public

この製品は、Rails で開発したアプリを、オンラインでもオフラインでもシームレスに切り替えて使えるようにするもののようです。ただ、この製品が筋のいい製品かどうかはわかりません。コンセプトは納得できます。ネットがつながっていないと、Web アプリはまったく役に立たなくなるので、オフラインでも使える Web アプリができたら便利ですね。

ここしばらくのクライアント技術の傾向を思いつくままに上げてみます。
・ Web アプリとデスクトップアプリの境目をなくす（共通）
・ Web アプリとデスクトップアプリの技術的な隔たりをなくす（Apollo、Silverlight）
・ クライアント／サーバの技術的な隔たりを（割と）なくす（Silverlight）
・ アプリのインストールを意識する必要が無い
・ マルチプラットフォーム
・ 一応リッチになってきた（？）

究極的には、コードオンデマンドでインストールを意識することはなく、オンラインオフラインを意識することなく、Web / デスクトップを意識することなく、ブラウザの種類も OS の種類もデバイスの種類も意識することなく、アプリケーションというものは使えるようになるということでしょうか。

すばらしい夢の世界・・・といいたくなるところですが、IT エンジニアにとってはしんどい時代になりそうだなぁ。。。

最近、.NET の事情を追っかけていなかったので、今日は少し追っかけていました。最近、Java の世界では JRuby が盛り上がっていますが、.NET の世界でも動的言語の勢いがかなり強いようです。Jython や IronPython の開発者である Jim Hugunin のブログを読んでいたら、.NET における動的言語の取り扱いがなんとなく見えてきました。

Jim Hugunin's Thinking Dynamic
http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx

上記のブログで、私が気になった点を抜き出しておきます。

1. CLR（Common Language Runtime）について
上記のブログでは、CLR の利点を二つ挙げています。一つは、プログラミング言語を簡単に作れるようになったことです。これは、CLR が言語を作るうえで技術的に難しい点（GC だとか JIT だとかセキュリティモデルだとか）をすでに実装しているからだそうです。もう一つの利点は、異なるプログラミング言語をシームレスにつなげるようにもなったこととのことです。

2. CLR と DLR
IronPython で示したとおり、CLR は動的言語をよくサポートしています。さらに、CLR 上で動的言語を作りやすくするために、動的型システムなどを実装した DLR（Dynamic Language Runtime）というものを作るそうです。DLR の上で、Python、JavaScript、VB Script、Ruby を実装するそうです。

3. DLR と Silverlight
DLR は Silverlight にも搭載されるそうです。サーバもクライアントも Ruby で書けるなら、全てを Ruby に・・・と、夢のような世界が！

※ Silverlight とは、MS 版 Flash みたいなものです。

もちろん、DLR だけであれば、Java の世界にも似たような動きはすでにあったのでそれほど驚きはしませんが、Silverlight に乗っかってくるとは知りませんでした。（って、どれだけ世情に疎いんだ私は。orz）Kodougu を書いているときも、Ruby と JavaScript を行ったり来たりして最悪だったのですが、この世界が実現されればそういうことからも解放されそうです。

技術的なコンセプトはすばらしいので、後は政治的な理由から Linux は仲間はずれ（Silverlight は Mac の Safari にも対応するらしい）とかそういう馬鹿馬鹿しい現象がおきなければ良いのですが。。。

これまで Kodougu では、prototype.js + script.aculo.us を使ってきたのですが、dojo.gfx（SVG と VML が使えるグラフィックスライブラリ）を使ってみたかったので、dojo に切り替えてみました。

dojo.gfx のコードは以下のような感じになります。（SVG か VML を知っているとなじみやすいです。）

  
  
  
  

  


  

  



This is a dojo.gfx example. 

上記のコードのスクリーンショットは以下の通りです。


また、dojo（0.4.2）を含む JavaScript に file:// でアクセスすると、IE7 で以下のようなエラーが発生しました。FireFox ではこのようなことは無かったので、IE がらみの問題かもしれませんが dojo.require に関連するバグかもしれません。（詳細は追っていません。）IE7 でも、Apache 上に配置して http:// でアクセスしたところ、問題なく動作しました。

symbol 'dojo.gfx' is not defined after loading '__package__.js'

概ね、dojo.gfx には満足していますが、SVG で言うところの text 要素に対応していないなど、完成度はまだまだ低いようです。

trac に Kodougu を組み込むための trac macro を作成しました。All-In-One Trac v0.1.1（trac v0.9.5）で動作確認を行いました。英語の情報との格闘でしたが、作成自体は簡単でした。ただ、trac v0.10.x や v0.11.x 以降で動作するかは自信がありません。大きな流れで言うと、trac の wiki マクロは trac plugin に統合されていくようなので。

以下のように書くと、trac に Kodougu を組み込むことができます。数値は、ダイアグラムの ID です。

trac/wiki の記述例（［］は全角になっています。）

［［Kodougu(2)］］

trac に Kodougu を組み込んだスクリーンショット


「＜＜All-In-One Trac インストールフォルダ＞＞\python\share\trac\wiki-macros\Kodougu.py」のソースコード（［］は全角になっています。）

import re

def execute(hdf, args, env):
	if not args:
		args = 'err'
	args = re.split('\s*,\s*', args)
	if re.search("［^0-9］+", args［0］):
		return '［Kodougu］ Wrong Parameters! - ' + args［0］
	else:
		return ''

trac の Wiki マクロの作成も非常に簡単で、マクロ名.py の内部に execute 関数を実装するだけです。

これで、Kodougu と著名な（≒私が好きな）Web アプリケーションとの統合は完了しました。Kodougu もサーバーサイド（Ruby on Rails）はかなり出来上がってきたので、これからはクライアント（JavaScript）の開発に注力します。

今日は早起きして pukiwiki（1.4.x 向け）で以下のように書くと、Kodougu が組み込まれるプラグインを作成しました。朝食までにプラグインの作成方法を勉強するつもりが、ホンチャンコードまで書けてしまいました。これぞ朝飯前・・・ですかね。(^^;

#kodougu(2)

pukiwiki に Kodougu を組み込んだスクリーンショット


プラグイン「kodougu.inc.php」のコード（下記コードは［］が全角になっています。）

'
			. 'Kodougu is not available!';
	}
	else {
		return 'Kodougu is not available!';
	}
}
?>

pukiwiki のプラグイン開発は非常に簡単で、上記のようなコードを書いて plugin フォルダにコピーすればできてしまいます。後は trac 用の plugin を書きたいところです。

さて、Kodougu 1.0α1 公開まで後もう少し。がんばらねば。

最近、JavaScript のテストを行う方法を探していました。xUnit 系の JsUnit や MochiKit に付属してくるテストフレームワークが有名どころのようです。とりあえずテスト用のメソッド名になじみのある JsUnit を使ってみることにします。

■ 目的
alert デバッグから開放される！

■ この記事に書かれていること
・ JsUnit の基本的な情報
・ 複数のテストファイルを同時に実行する方法
・ testRunner.html で毎回テストファイル名を指定しないでテストを実行する方法

■ JsUnit の概要
まず、testRunner.html というテストランナーが存在します。html ファイルの script タグ内にテストコードを書いて、テストランナーにテストファイル（html）を指定すると、テストコードを実行するという仕組みになっています。

まずは動かしてみてください。JsUnit を DL すると、testRunner.html というファイルが含まれているので、このファイルをブラウザで開いてください。テストファイル名の入力を促されるので、tests フォルダ内の適当な html ファイル（テストファイル）をフルパス指定して、Run ボタンを押してください。見慣れたグリーンバーが表示されるはずです。

テストの書き方は、テストファイルを見ればわかります。イメージとしては以下のようなコードになります。

<script language="JavaScript" type="text/javascript" 
  src="./framework/app/jsUnitCore.js">
</script>
<script language="JavaScript" type="text/javascript">
function testAssert() {
    assert("true should be true", true);
    assert(true);
}
</script>

■ テストのディレクトリ構造
とりあえず、私は以下のような構造にしてみました。

 + e:\tests
   + framework <- ここに testRunner.html など JsUnit の全てのファイル／フォルダを入れる
   - tests.html <- テストコードの一覧を持つ
   - xxxTest.html <- テストコード

■ suite を使って複数のテストファイルを実行する
複数のテストファイルを同時に実行するには、tests.html に以下のように書いて、tests.html を testRunner.html 実行してください。

<script language="JavaScript" type="text/javascript" 
    src="./framework/app/jsUnitCore.js">
</script>
<script language="JavaScript" type="text/javascript">
function suite(){
  var newsuite = new top.jsUnitTestSuite();
  newsuite.addTestPage("../xxxTest.html");
  return newsuite;
}
</script>

テストファイル名を指定する際、tests.html からではなく、testRunner.html からの相対パスを指定していることに注意してください。

■ URL にテストファイル名を含めることで、毎回の入力を回避する
毎回 testRunner.html にテストファイル名を入力するのが面倒なので、URL のパラメータ「testpage」を指定すると、ファイル名を自動的に入力してくれます。以下のような URL を作成してお気に入りに入れておくと良いでしょう。

URL の例：file:///E:/tests/framework/testRunner.html?testpage=E:/tests/tests.html

■ 参考
Javascript/JsUnit - Bobchin's Wiki
http://bobchin.ddo.jp/wiki/index.php?Javascript%2FJsUnit

Ruby では i++ はサポートしていないようです。これまで気づいていませんでした。イテレータが準備されるようになると for 文を書かなくなるので、これまで i++ のような表記をしなかったということでしょうか。

Ruby での書き方：

i += 1

ruby-list におけるまつもと氏の見解：
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/126

この文法は驚き最小の法則からは外れる・・・気がするのですが、Delphi 出身の私にとってはむしろ自然に感じたりします。（笑）

Delphi での書き方：

Inc(i);

なぜか、Delphi では上記のように書くと高速でした。Delphi はインライン展開をサポートしていなかったと思いますが、こういう関数は特別扱いされていて、アセンブラか何かで実装されていて、その処理をインライン展開していたのかもしれません。
# 今となってはどうでも良いことですが。

404 Blog Not Found にて、蒼天航路の書評が載っていました。おおむね賛成なのですが、いくつか気になったところについて、私の意見を書いてみます。

404 Blog Not Found:書評 - 蒼天航路より

ある意味、諸葛亮というのは、個人としてそこそこの能力がある人物が、国家に大していかに有害な存在になりうるかを示した存在とも言える。彼が無理な北征を重ねなければ、蜀の寿命はずっと長かっただろう。彼に馬謖を切る資格があったとは思えない。そもそも北征を企画した時点で彼は誤っているのだから。

私は「北伐はそんなに悪い選択肢だったのか？」と考えています。確かに、蜀を長続きさせるためには北伐は下策かもしれませんが、それは「蜀という国を長続きさせることに価値があるのかどうか」という問題を解かなくてはなりません。

蒼天航路でも触れられていますが、後漢末期～三国鼎立という時代は激しく人口が減少した時代でした。蒼天航路の中で諸葛孔明は、曹操が生を受けてから中国の人口は減少の一途をたどっていることを指摘しています。良くも悪くも曹操が大きな人物であったことは間違いありません。曹操はその時代そのものであるという評価を下すと同時に、その時代の本質とは何かを指し示した的確な評価だと思います。ただ、この時代の価値を、人間の命で測るのであれば、あまり良い時代であったとは言えません。

三国鼎立以降、三国が並び立ったまま人口は回復を始めるようです。そういう意味では、魏・呉・蜀の治世にはそれぞれそれなりの価値があったと考えられます。

以下のような記述もあります。

切込隊長BLOG（ブログ）: 「好きな三国志の武将を三人選べ」と言われたらより

つまり、三国志通が選ぶ最強の武将は匈奴の大首長劉淵。こいつ。せっかく統一した晋がこの男のおかげで五胡十六国時代となって三国志が台無し。

歴史上、中国は強力な外敵を多く抱えていました。蜀の国力を温存して、外敵が引き起こした混乱に乗じて中国統一を目指すという選択肢は、蜀単独の利益を考えればありえるものだったかもしれません。しかし、それは乱世の復活であり、後漢末期の大規模な人口減少を再度引き起こす引き金になったかもしれません。外敵に対するには漢のような強力な統一国家が必要という考え方もできます。（内戦に外国の力を引き入れるのは愚策ですね。）

つまり、北伐という選択肢は、成否に関わらず三国の統一を促すものであり、蜀という国を存続させることで中国を疲弊させることよりも、良い選択肢であった・・・というよりは、為政者の責務ではなかったかという気がします。さて、諸葛孔明の前出師表にはそんなことは一言も書かれていません。何せ、主君にあてられた文章ですから、そこは TPO というものです。南中平定（※）などを見るとおり、蜀が国家としての責務を見失っていたとは考えられません。

※ 横山三国志などに出てくる南蛮征伐のような派手なものではありません。しかし、中国においては辺境の安定は国家の義務です。魏・呉・蜀ともに、辺境の安定という国家の責務をしっかり果たしていたということは忘れてはなりません。

つまり、北伐は成否に関わらず有益なものだったと。

もっとも、北伐の戦略目標は長安ですから、蜀が長安を得た時点で再びこう着状態に入り、乱世が長引く可能性もあります。治世の良否という観点では三国時代には一定の評価が下せるとしても、微妙かもしれません。

切込隊長BLOG（ブログ）: 「好きな三国志の武将を三人選べ」と言われたらより

一方、せっかくの清廉な仕組みを縁故時代に逆戻りさせた司馬懿は死ね。

まったく同意。魏という国がしっかりしていれば、その後の歴史の流れも相当違うものだったろうに。