私は 20.1 インチ液晶モニタ（UXGA）と 17 インチ液晶モニタ（SXGA）をもっています。17 インチモニタは最近使っておらずもったいないので、組み合わせてデュアルモニタにすることにしました。

従来使っていた Geforce2MX のビデオカードはデュアルモニタ（nView テクノロジ）に対応していなかったので、以下の新しいビデオカードを通販で購入しました。

AOpen 7600GS-DV256S AGP（Geforce7600GS）

今日ビデオカードが届いたので、差し替え作業を行いました。メインマシン（自作）に手を入れるのは久しぶりというか、購入以来手を入れた記憶が無いので、ちょっとどきどきしながら触っていました。(^^;

一つ問題になったのは、このビデオカードは D-Sub 15 ピン端子と DIV 端子が一つずつしかないことです。私はモニタは D-Sub 15 ピンだけで運用してきたので、DIV 端子のケーブルの持ち合わせがありませんでした。少しあせったのですが、最近購入した UXGA モニタに付属していたことを思い出し、家中探し回って入手することができました。

さて、マシンにカードを装着したら次は OS の設定です。ドライバをインストールし、デュアルモニタ環境を整えます。私はデュアルデスクトップ（Dualview）環境を選択しました。デュアルデスクトップとは、それぞれのモニタを独立したデスクトップ環境として使うことです。片方にはタスクバーが出てこないとか制限はありますが。

二台のモニタを一つのモニタとして動作させることもできますが、両方のモニタを同じ解像度（私の場合は SXGA）で動作させなくてはなりません。20.1 インチモニタを SXGA で使うのはもったいないので、デュアルデスクトップを選択しました。（20.1 インチモニタがメイン、17 インチモニタがサブという感じになっています。）

デュアルモニタのおかげで、片方のモニタでブラウザを開いて、リファレンスや参考サイトのソースコードを見ながら、もう一つのモニタで統合開発環境を開いて開発するとかができます。特にテストのときは重宝します。

さーて、作業効率は改善した（はずだ）からがんばって開発するか！

Ruby プログラムを .NET Framework 2.0 上で動作する DLL/EXE に変換する Ruby.NET Compiler ソフトウェアがあります。気になったのでちょっと調べてみました。

本記事は、Gardens Point Ruby.NET Compiler Beta Release（February 2007）に対応しています。

■ 知りたいこと
・ 既存の Ruby ライブラリが使えるか
・ 既存の .NET ライブラリが使えるか
・ 既存のアプリケーションに組み込めるか
・ ライセンスは使いやすいか
・ 安定度はどれくらいか
・ 開発は活発か

■ 調査結果
・ 既存の Ruby ライブラリが使えるか
実装していないようです。実装予定があるかどうかも不明です。

・ 既存の .NET ライブラリが使えるか
次のリリースで対応する（したい）ようです。

・ 既存のアプリに組み込めるか
ちゃんとコードは追っていませんが、高い頻度で動的に書き換えるのはパフォーマンス的にネックになりそう（※）ですが、それほどでなければ大丈夫そうです。

※ コンパイラであるためです。ただ、IronPython もコンパイル可能でわりと動的に書き換えてもそれほどパフォーマンスでネックにはならないので、このツールもこなれてくれば大丈夫ではないかなと楽観しています。IronPython を組み込む際は、ランタイムのロード時間のほうが問題になりました（IronPython というよりは .NET 系全般の問題）。ゲームとかリアルタイム性が必要なアプリの場合は、ランタイムを呼び出すタイミングをコントロールする必要があります。
（IronPython では、WinXP/P4 2.8GHz/1GB の PC で秒間 50 フレームで HelloWorld をパースさせたら CPU 使用率が 100% になった <- あたりまえ^^;）

コンパイラなので、既存のアプリに組み込むことは想定に入っていないのか、プログラミングインタフェースは、まだ整理されていないように見えました。IronPython のように 1 行で組み込むというわけにはいかないという印象を受けました。

・ ライセンスは使いやすいか
BSD ライセンスに近い印象を受けました。このページの Licensing という箇所を参照してください。以下の内容が書かれています。というわけで結構使いやすいのではないかと思っています。

続きを読む

もうすぐ朝・・・か。二日連続徹夜・・・。orz

Kodougu を IE でも表示できるようにしました。こちらのエントリを参照してください。
# 表示だけで、操作は一切できません。

さて、IE で表示するにあたって、壁は二つありました。
(1) VML 描画
(2) Ajax では、別のドメインにアクセスできない（セキュリティのため）

(1) ですが、これは 30 分ほどでできました。もともと、アーキテクチャ的にさまざまなレンダリングエンジンを使うことを想定しているので、VML を増やしても特に問題は発生しません。テストはちゃんと書いていないので、後で書きます。

(2) ですが、Kodougu を Web アプリに組み込むときは、JavaScript を使っています。もともと、JavaScript でブラウザを判定してから、prototype.js の Ajax.Updater で SVG/VML を取得しようとしたのですが、Ajax ではドメインを越えてデータにアクセスすることができません。ちょっとトリッキーな方法で切り抜けてみました。（後で調べたところ、割と王道のようでしたが。）

コードとしては以下のとおりです。

[code: 

]

解説します。以下の URI は、JavaScript を返しますが、この中で SVG/VML の情報を保持した kodougu_diagram_html という変数を（JavaScript で）定義しています。

http://www.kodougu.net/rendering/diagram_javascript/1

以下の一行で、HTML に SVG/VML を埋め込んでいます。

$("test_kodougu").innerHTML = kodougu_diagram_html;

つまり、JavaScript はドメインを越えて情報を取得することはできませんが、JavaScript そのものは他のドメインから持ってこれるので、動的に必要な情報を含んだ JavaScript を返す API を作ったというわけです。

あー、疲れた。(--;

Kodougu を既存の Web アプリケーション（今は私のブログ）に組み込むテストを行っています。Firefox であれば、下にモデリングツールが表示されると思います。（IE では何も表示されません。）
今できるのは、要素・関係線の作成、削除、移動だけで、要素名の変更もできません・・・。（しかも、まだバグバグです。^^;）



さて、それほどがんばらなくても Firefox 向けであれば、HTML に object タグを書くだけで既存の Web アプリに組み込めます。IE 向けは少し難しいかもしれません。IE では、VML を使うのですが、VML を使うときは HTML のヘッダにいくつかの情報を記述しなくてはならないため、既存の Web アプリに対する影響が大きいのです。

どうしたものか・・・。

mixi の日記に外部のブログを設定すると、非常に使い勝手が悪いわけですが、以下のブログにローテクですがとてもいいやり方が載っていました。

小野和俊のブログ:mixi で外部ブログを使っている人への提案より

だが、仕様は変えられなくてもストレスを回避するための方法を考えることができる。そこで提案したいのが、外部ブログを使っている人は、設定自体はミクシィ日記にしておいて、外部ブログに記事を書いたときには概要とリンクをミクシィ日記に書く、という運用面でのワークアラウンドである。記事が短い場合にはリンク自体張らずに内容を全部貼り付けてしまい、記事が長かったり、記事中にテーブルがあったりする場合には概要とリンク先 URL を貼り付ける。

確かに手間なのですが、読み手にとってはとてもいいやり方だと思います。早速これから実践してみます。

もう朝が近いな・・・。

Kodougu を mod_proxy_balancer でロードバランスしたのですが、Ajax のレスポンスが 10 秒以上待たないと返ってこないという問題に遭遇してしまいました。具体的には、ブラウザ（FireFox）上でモデル要素を動かすと、Ajax リクエストを送信するのですが、これのレスポンスが 10 秒以上たたないと返ってこないという現象です。Apache の httpd.conf をいじって KeepAlive を外したら速くなったのですが、どうも腑に落ちません。

昔、IE では KeepAlive 関係でバグがあってレスポンスが返ってこないというのはあったようですが、今回は FireFox なのでちょっとそれはなさそうな予感がしています。

以下のバグが少し関係ありそうなのですが、効果がないと書いている対処法が、私のケースでは効果があったので別問題でしょうか。時間のあるときに Apache の bugzilla をあさってみますかね。やれやれ・・・。

Bug 37770 - proxy: error reading status line from remote server (null) | Apache | Bugs
http://www.gossamer-threads.com/lists/apache/bugs/314332

■ 追記（2007/3/4 13:24）
上記の Bug 37770 に関係があるかと思い、以下の記述にしたがって httpd.conf を修正してみました（つまり、KeepAlive を On にして、以下の記述を追加した）が、効果はありませんでした。うーん・・・。

mod_proxy - Apache HTTP サーバより：

[code:

SetEnv force-proxy-request-1.0 1

SetEnv proxy-nokeepalive 1]

当面は KeepAlive Off でいくことにします。しばらくはこういった問題がシビアになるほどアクセスが集中するとも思えないので。

○ 問題の整理
Apache（mod_proxy, mod_proxy_balancer）をフロント、Mongrel（Rails）をクラスタリングしてバックエンドに配置した状態で、ブラウザ（FireFox）上でページ遷移のない Ajax を多用した操作を行うと、Ajax レスポンスが返ってくるまで KeepAliveTimeout + サーバの処理時間程度の時間がかかってしまう。（私の環境では、KeepAliveTimeout は 15 に設定しているので、15 秒以上待たされる。）
しかし、ページ遷移のある操作は問題なく動作します。

今日は家でサッカー五輪予選（日本×香港）を見てました。試合は 3-0 で勝ちましたが、ちょっと欲求不満の残る試合でした。3 トップは良い（個人的にも好き）のですが、そのせいか中盤が薄くなって、攻撃の組み立てができていないという印象を受けました。なんか日本っぽくない。（2 シャドーが交代してからは日本っぽい感じになりましたが。。。）

これで五輪出場大丈夫かなぁ・・・。

今日は、Kodougu 公開に向けて、Apache2.2 で mod_proxy_balancer を使ってロードバランスを実現させるということをしていました。つまり、フロントエンドを Apache（mod_proxy, mod_proxy_balancer）、バックエンドは Mongrel という Rails の世界では割と一般的な構成にしました。役割としては、Apache がロードバランスして、Mongrel がリクエストを処理します。Mongrel とは Ruby で書かれた Web サーバで、Rails アプリを動作させることに適しています。

なぜこのようなことをしているのかというと、理由は二つあります。ひとつはパフォーマンスとスケーラビリティに関係するものです。Mongrel は Rails アプリを動作させるには非常によい Web サーバ（Rails と相性がよくて高パフォーマンス）です。しかし、Apache と同じく 1 プロセス 1 コネクションであるため、クライアント（ブラウザ）に直接接続させてしまうと、大量のリクエストが発生したときに（Kodougu では大量のリクエストが発生する）、Web サーバがビジーになって、リクエストを受け付けるまでラグが発生する可能性があります。そこで、複数の Mongrel プロセスを起動して負荷を分散します。Mongrel はロードバランスはしてくれないので、Apache にロードバランスさせているというわけです。
もうひとつの理由は、Mongrel は Rails に特化した Web サーバなので、フロントには別のサーバをおいておきたいという思いがあります。そこで、普段使い慣れている（＋ロードバランス機能を持った）Apache をフロントに置き、Mongrel をバックに配置しました。

さて、設定は楽勝なのですが、mod_proxy_balancer で一点はまりました。mod_proxy_balancer を使うために httpd.conf には以下のような記述を追加します。（実際にはもっとたくさんのバランサメンバがいます。）

ProxyPass / balancer://mycluster/
ProxyPassReverse / balancer://mycluster/
<Proxy balancer://mycluster/>
  BalancerMember http://127.0.0.1:3000 loadfactor=20
  BalancerMember http://127.0.0.1:3001 loadfactor=20
</Proxy>

balancer://mycluster/ の最後のスラッシュ（/）を書かなかったがために、ルート以外の URL にアクセスしたときにパーミッションエラーになってしまいました。
# これで何時間もはまってました。。。

気をつけませう。。。orz

Kodougu の運用環境に Apache2.2（mod_proxy, mod_proxy_balancer）＋mongrel を使用しようと考えています。そこで、gem を使ってサーバ（Fedora6）に mongrel をインストールしようとしたところ、以下のようなエラーが出て失敗しまいました。

Building native extensions.  This could take a while...

ERROR:  While executing gem ... (Gem::Installer::ExtensionBuildError)

    ERROR: Failed to build gem native extension.



ruby extconf.rb install mongrel

can't find header files for ruby.

これは、ruby-devel をインストールし忘れていたからで、ruby-devel をインストールしたところ、無事 mongrel のインストールに成功しました。

yum install ruby-devel

ものすごい亀反応ですが、Rails Engines が Rails 1.2 でも使えるようになりました。一つ前のニュースを読むとおり、Rails のバージョンが 1.2 にあがったときに、互換性の問題で Engines は使えなくなっていました（Engines are dead...）。しかし、2/4 のリリース（Engines 1.2）ではこの問題が解決されているようです。

ってことは、Kodougu でも Login Engine は使えるな～。