Kodougu では、SQL の Select における N+1 問題を回避することが重要になってきます。

N+1 問題とは、Tree 状の情報を DB から読み出す際、全レコードの取得に一つ＋各レコード分だけ SQL を発行してしまう問題です。出来の良い O/R マッパーを使っているとよく引っかかります。

Kodougu のようなモデリングツールだと、この問題には非常によく出くわします。例えば、図上の要素を全て取得してから、要素に関係する関連の一覧を取得するなどを行うような場合です。Rails の ActiveRecord は気軽に DB にアクセスできてしまいますから。以下のコードでは、要素から出て行く関係線の一覧を取得しています。以下のようなコードを書いてしまうと、図を一枚描くたびに要素数分の SQL が発行されてしまいます。

[code: @elements = Element.find(:all) # DB アクセス発生

for element in @elements

  @outputs = element.outputs # DB アクセス発生

end]

この問題が深刻な理由は、「DB サーバはアプリケーションサーバと比較するとスケールさせにくい」からです。昨今の流行りでは、アプリケーションサーバはステートレスですから、ロードバランサーを入れるだけで簡単にクラスタリング可能です。しかし、DB サーバはレプリケーションに対応していたとしても、同期の問題などがあり単純にスケールさせることは非常に難しいのです。そこで、アプリサーバで CPU パワーを多少使ってもかまわないから、DB への負担を減らしておいた方が、スケールするアプリが書けるというわけです。

今のところ、Kodougu では個別ケースの対処ではありますが、DB にアクセスするときに、必要な情報を DB から全て取得してから、アプリケーションサーバ（Rails）やクライアント（JavaScript）でオブジェクトグラフを再構築してアプリで利用するということをやっています。

この問題をある程度自動的に回避するライブラリを作らないと身が持たないかも・・・。
# 実現方法についてはまだノーアイディアですが・・・。

今月から自宅で仕事することになったため、部屋を仕事をする環境に整えました。部屋を片付ける作業は、去年の年末から行っていて、とりあえず今日の作業で完了といえる状況になりました。

1. 無駄なものを捨てる
10 年分（多分もっと）たまりにたまった無駄なもの（本、衣類、その他）を捨てつくしました。捨てた量としてはゴミ袋 10 個分を優に超したと思います。
# 狭い家なのによくもまあこんなに・・・。

2. ノート PC を買って開発環境を整える
これは、自宅で怠けてしまう場合に、怠けないような場所へ移動して開発するためです。(^^;

3. 机を新しくする（ここを今日やっていた）
これまで、パソコンラックを使っていたのですが、書き物をするのスペースがなかった（70cm × 70cm 位）ため、120cm × 70cm の広さの机を買いました。

机の上には、ノート PC とモニターを二個（20.1 インチと 17 インチ）を置いています。開発用の PC は二台（Win2000 と WinXP）で、とりあえず仕事する環境は整ったと思います。

あー、疲れた。(--;　もう寝ようかな。
# 仕事するんじゃないのか！？

Kodougu の開発中に気になったのですが、ブラウザをリロードしても JavaScript の更新が反映されないことがあるようです。キャッシュが効いているのでしょう。

Rails では、javascript_include_tag メソッドを使うと、以下のように JavaScript のファイル名の後ろに数字（たぶん時間）を追加して展開してくれます。これだと、アクセスするたびに URL が変更されるため、ブラウザのキャッシュの影響を受けません。

[code: ]

SVG では JavaScript のインクルードは xlink を使うため、Rails のヘルパーメソッドを使うことはできません。そこで、以下のように書いてみました。

[code: 









]

こんな感じ（”［］”は小文字に変換してください。）です。ただし、Updater は使えませんでした。今は、手動で Response として受け取った XML 要素を、SVG 内の要素と置き換えています。（Element.appendChild() などを活用しています。）

余力があったら、prototype.js を SVG 上で Updater が動作するように改造するかもしれません。

この記事を読んで、Windows Vista について思い出した。（Windows Vista の存在そのものを思い出したというべきか。）

私はマイクロソフトのソフトウェア開発の手法は非常に評価しています。というか、尊敬しているかも。ユーザビリティテストやテストエンジニアに対する姿勢、ジョエルテストなど、すばらしいアイディアに満ちています。特に Visual C++ の開発チーム（ソフトウェア開発のダイナミズム参照）はすばらしい。

おそらく世界最高の開発チームを抱えているはずのマイクロソフトが、Windows Vista の開発にはかなり苦戦したようです。延期につぐ延期、縮小につぐ縮小、非常に残念です。

Windows開発責任者J・オールチン氏、Vista発売までの悪戦苦闘を振り返る（前編） - CNET Japan より

セキュリティ、検索、写真、音楽--すべてが非常に改善されていると同氏は語っている。

これらの改善はすばらしいことだと思います。おそらく、Windows Vista の開発は史上もっとも難しいプロジェクトで、ある種の記念碑的ソフトウェア開発（適応型ソフトウエア開発より）といえるかもしれません。それだけの偉業（ある種の皮肉です）を成し遂げているのに、最近の Apple や Google に感じるパワー（あるいはライフスタイルを一変させるような破壊的なもの）のようなものを感じません。これほどのエネルギーを費やす必要があったのかなぁ・・・。

とはいえ、私としては Windows Vista は普及して欲しいと思います。初期の製品ビジョンが達成されなかったことは残念ですが、この OS 上に載せてみたいサービスはあるので。

昨日は同期との飲み会でした。私の送別会ということでもあり。皆様ありがとうございました。m(_ _)m

なんというか、これまでとあまり変化を感じないのはなぜだろう・・・。(--;　会社のオフィスに居ようが居まいが普段顔をあわせない同期が多いせいなのでしょう。
# 同期会というよりは同窓会だよねって言っている同期もいたし。
# まったくそのとおりだし。

そうは言いつつも、東京オフィスに一緒に居た同期とは昼飯時食事をすることも多く、その点、今はそういうことはできないためさびしいところです。ま、そういうこともすべて織り込み済みなんだけど。

それにしても、同期は変わらないな～、とか思うのですが、飲み会に行くと割と人生どうしよう的なちょっと重めの話題が増えてきた気がします。この辺は年月を感じるな～。

JavaScript で文字列の比較を行うにはどうしたら良いのか気になったので調べました。

JavaScript

s1 == s2

プログラミング言語を変えるとき、どうしても神経質になるのが文字列の比較です。メジャーな言語によって推奨される方法が異なるのです。

Java（参照の比較は == を使う）

s1.equals(s2)

C#

s1 == s2

（C# は Java スタイルでも良いが、こちらを参照せよ。）

Ruby（参照の比較は equal? を使う。）

s1 == s2

C/C++（参照というかアドレスの比較は == を使う。）

strcmp(s1, s2) == 0

Delphi（参照というかアドレスの比較は @s1 = @s2 ・・・だっけ？？？）

s1 = s2

・・・誰か統一してくれ！