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 上に載せてみたいサービスはあるので。

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

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

今日は Rmake のマップエディタのリファクタリングを実施していました。マップエディタを作成する際、マップの描画を行わなくてはなりません。マップの描画機能は、エディタ向けの描画クラスとゲーム向けの描画クラスを準備していますが、処理内容に重複（※）が多く、明らかにコードクローンになっています。そこで、一つにまとめられないか考えていました。

※ 差分を説明すると、ゲームの場合は、キャラクタや文章表示用のウィンドウなどを描画しなくてはならず、エディタの場合はマス目ごとの設定値（例：エンカウント率など）などを描画しなくてはなりません。

結局、C# の Partial 型を使って一つにまとめました。本当は、描画パターンをコンポーネント化して、Ruby みたいに実行時に mixin したいところなんですけど。Seasar とか使えばできそうな気もしているけど、小さなアプリなのでそういう大仰なものを入れたくないとか考えたりして。

トラックバックを受信するコードを実現しましたが、文字コードのことを考えていませんでした。はてなダイアリーなどは UTF8 なのですが、goo ブログは euc-jp らしく、UTF8 で運用しているブログでそのまま受信すると文字化けしてしまいます。そこで、受信したトラックバックの内容を UTF8 に変換するコードを書く必要があります。

Ruby で文字コードを変換する方法はいろいろとありますが、ここでは kconv を使用します。kconv を使用すると、文字コードの自動判別をさせながら utf8 に変換するコードを書くことができます。

例としては以下のようになります。toutf8 というメソッドが文字列を utf8 に変換しています。

require 'kconv'
@trackback.title = @title.toutf8
@trackback.excerpt = @excerpt.toutf8
@trackback.url = @url.toutf8
@trackback.blog_name = @blog_name.toutf8

もっと詳しく知りたい方は、こちらのページを参照することをお勧めします。

今日、Google で「Ruby」と「Python」で検索してインデックス数を比較してみました。

■ 日本語
Ruby　：2830000
Python：2580000

■ 全言語
Ruby　：97600000
Python：92400000

おお！　ついに Ruby が Python を超えた！とか思ったのですが、「Ruby Programming」「Python Programming」で検索してみたところ・・・。

Ruby　：32700000
Python：63300000

宝石の Ruby と蛇の Python じゃノイズの量が違うってことでしょうね。まだまだ Python の方が優勢ですねぇ・・・。

S はシンプルの Sを読みました。面白いです。SOAP を取り巻く仕様の複雑さをうまく言い表しています。WS-* の調査に苦戦している後輩君もこの記事にはうなづけるんじゃないか？

S はシンプルの S より

SOAPの人 私が何て言ったかなんて忘れてください。 これからは大粒度メッセージをやりとりするんです。いいでしょ? 大粒度って言葉。メッセージは XML スキーマに従ったものです。この新しいスタイルは document/literal って言うんです。あ、古いのは RPC/encoded ね。

会社でも、これに似た話が出て、極力阻止しようとしたのですが・・・。大粒度。相互運用性とか非機能要求（パフォーマンスとかね）のことのことを考えたら・・・。