Oddwit

イベントの伝播にはcaptureとbubblingがある。
captureが先（親から子）、bubblingは後（子から親）。つまり親divと子spanがあったとして、それぞれのonclickイベントのcaptureとbubblingにリスナをつけておくと、クリックした際は以下の順番でリスナが呼ばれる。
1. 親のcapture
2. 子のcapture
3. 子のbubbling
4. 親のbubbling
Javascriptでは意識せずにイベントを扱うとbubblingになる。

DOMエレメントに勝手にプロパティを付け加えることができて便利。
ただし適当につけまくってるとわやくちゃになるのでうまく管理したいところ。

onBlurはブラウザ自体がフォーカスから外れた場合にも呼ばれる。
これを想定していないと変な処理が変なタイミングで行われてしまうかもしれないので要注意。

WinIEではevent.targetが使えない。
なのでこんな風に書こう。

function someAction(event){
	var target = event.target || event.srcElement;
	// ...yadda yadda yadda
}

moo.fxのEffectsはstart()じゃなく_start()で動く
API Docsには

new Fx.Style('element', 'opacity').start(1,0);

で動くって書いてあるくせに、なぜか実際にはアンダーバーがついていて_start()。

new Fx.Style('element', 'opacity')._start(1,0);

バージョンはmoo.fx for prototype.js 2.0。バージョンアップで直ったりするのかな？突然直られても迷惑やけども。

あらすじ：
Flashで、遺伝的アルゴリズム（GA)で巡回セールスマン問題を解くアプリを実装してみた。GAではパラメータのチューニングがかなり重要な要素だということが理解できた。

実行はこちら。ソースもあるよ

巡回セールスマン問題

今回扱ったのは、いくつかの都市を全て一回ずつ巡回するとき、最短となるルートを発見しようという、いわゆる「巡回セールスマン問題」。

ごり押しで解こうとなると、12の都市で12!（じゅうにバン！と読む）≒4億7千万通りのルートを試さなければならない。できるだけ少ない試行でそれなりに短いルートを得るために、今回は遺伝的アルゴリズム（Genetic Algorithm, GA）を使う。この実装では、12箇所の場合、調べる回数が数万回にまで減らせることが分かった。

遺伝的アルゴリズム

GAは、生物の進化にヒントを得たおもしろいアルゴリズムだ。定義や一般的なやり方についてはWikipediaあたりを見てもらうとして、ごく簡単に説明すると、生物の進化を模倣したアルゴリズムだ。問題に対するさまざまな解を生き物に見立て、解どうしで交配させて子どもを作ったり、環境に適さないものを淘汰したりすることで、確率的に最適解を見つける。

構成

主なクラスは5つ。

• Agent - 一人のセールスマンをあらわすエージェント。DNAを保持
• Population - セールスマンの集まり。世代を経るなどの動作をする
• World - 都市がばらまかれたマップ。エージェントのDNAを評価する
• Node - 都市。
• GA - アルゴリズムを実行する。

まずはPopulationオブジェクトとWorldオブジェクトを作成・初期化し、それをGAオブジェクトに渡して、myGA.run() で実行するという流れだ。

最近のギークたちはとにかくマッシュアップが好きなようだが、実際に使おうかなと思ったサービスはほとんど無い。

ましてやマッシュアップという言葉を知らないような人にはウケる余地など本当に微細に思えるんだがどうなんだろうか。

Ajaxを使うためだけにAjaxを使うように、マッシュアップするためだけにマッシュアップしているように見える。まぁ楽しいのは分かるし大規模なブレーンストーミングのようなものなのかも知れないが、祭りが終わったときに生き残るようなサービスがそろそろ出てもいいのではないかと思う。

「Web2.0」もそうだが、バズワードには遊ばれず本質的な良さを追求するよう注意する必要がこれからもあるだろう。

とまぁただそれだけの、大して熟していない話。

以前から数回にわたって書いてきたCIセッション問題が解決した。

問題というのは、セッションの有効期限を「ブラウザが閉じるまで」に設定できなかった件、そして個別のセッションについて期限を設定できなかった件だ。

CIのライブラリを拡張してDBのセッションテーブルの構造を含めかなり手を加えることになってしまったが、外観的にはメソッドが一つ増えただけのかなりスッキリした改造だ。

結局、クッキーをセットするときに期限を「0」にしておけば「ブラウザが閉じるまで」セッションになるということと、個別に期限を設定するにはそれぞれのセッションデータ自体に自らの期限を保存するしかないという二点が作業内容の主なポイントだった。

式の記述ミスで現行セッションがガーベジコレクションされてしまったりと前途多難だったが、今回の作業でありがたいと思ったのはテキストログの出力機能だ。主としてクッキーを扱う作業のため、これまでやってきたようなechoによるデバッグはできない。そこでメッセージをテキストファイルに書き出すCIの機能に大変お世話になった。こういうクリティカルな場面でなくとも、表示を乱さずにデバッグできるのは時によっては役に立つ。