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 は使えるな～。

Rails勉強会＠東京第15回に参加して、Rails 1.2 に関する情報を収集できたので、Kodougu を 1.2（これまでは 1.1.6）に上げてみました。

後悔した。orz

やってみたところ、DEPRECATION WARNING が大量に出てしまいました。@header（推奨は @ を外す）とか start_form_tag（推奨は form_tag）とか修正箇所は 100 箇所近くに及びました。（コード総数は 1500 行程度だったと思います。）
# 1.2 以前に既に Deprecated になっていたものも混ざっているようでしたが・・・。

まあ、修正の絶対量はたいしたことがないのですが、困ったのは、Ajax を使った機能でレスポンスが 30 秒位たたないと返ってこないという現象が発生したことです。最初は、私のコードに根本的な問題があって、Rails 1.2 ではこのパフォーマンスしか出ないのかと勘違いして、冷や汗・・・というか恐怖すら覚えました。(^^;
結局、@header を修正したら収まって、従来どおり 0.2 秒位でレスポンスがくるようになりました。DEPRECATION WARNING が大量に出ると、処理が重くということでしょうか。

まあ、結果的にはどうということもなかったのですが、あまり心構えをしないではじめたせいで心臓に悪い作業になってしまいました。(^^;

2/16 にポジションペーパーを作りましたが、昨日（2/18）はRails勉強会＠東京第15回に参加してきました。参加したセッションは以下のとおり。
・ Rails v1.2 の変更点と REST との関係
・ Agile Model Driven Development with Rails

以下に簡単な感想を記述しておきます。

■ 勉強会の形式
オープンスペース形式で全後半のセッションがありました。自己紹介はポジションペーパーを使いましたが、ネタでアイスブレーク（かなりイタイです^^;）をしたりとか、柔軟に運用していました。

■ 参加者
この勉強会には SIer、Web 系、研究系など意外と幅広い方が参加されていました。やはり、この手の勉強会は刺激になります。こういう勉強会がないと、高いスキルを持った人と出会う機会がないですからね。
# いや、別に前の会社でそういう出会いがなかったと言うわけじゃないのですが。

■ 雰囲気
ライトニングトークスとかではないので、若干まったりした雰囲気も漂いつつ、そこそこ濃い話をし合う勉強会だったと思います。「こう書くと気持ちが良い」という議論が多いのはこの手の勉強会ならでは。Rails の勉強会は、Java をやる人が多いせいか、若干 Java 世界の香りもしました。

■ 内容
Rails のようなフレームワークを使っていると、悪い意味でのアジャイル（安い、早い、マズイ）と誤解を受けることがあります。この勉強会では Rails はどちらかというと対象としている領域に対しては、しっかりとした理論的な下地を持った「良い意味で堅いフレームワーク」ということが実感できました。
# scaffold があるからって Rails 風を名乗るなよ！
# それは単なる宣伝文句なんだ。鵜呑みにしちゃだめだ！

モデリングにもそれなりの関心が払われていることは興味深い現象でした。もちろん、UML 限定とか狭義のモデリングではなく、開発に必要な情報を集めて整理してから開発を進める必要性をちゃんと認識しているということです。

あと、勉強会で人の話を聴いていくうちに、Rails はもっとうまく使ってやらないとかわいそうだと実感しました。使い方によっては、もっともっと高い生産性を発揮できるフレームワークなんですね。
# やはり scaffold だけじゃない。

■ お礼
最後に、勉強会を運営してくださった皆様（特にドリコムの方々）は、お疲れさま＆ありがとうございました。

明後日は Rails 勉強会なので、そこで配布するポジションペーパーを作成してみました。（まだこれから少し手直しをする可能性もありますが。）



これまでポジションペーパーを作成したことがないので、こんなものでいいのかよくわかりませんが、とりあえず明後日はこんな感じで行きます。ノート PC がある方が面白いみたいなので、新しいノート PC を持っていきます。

すでに気づいている人も居るかもしれませんが、記事の右下にいくつか記事と関連のありそうな単語が並んでいると思います。タグです。このブログにタグを実装してみました。そこの単語をクリックすると、タグと関係のある記事が表示されます。

記事とタグの間の関係を表すクラス図は以下のとおりです。



上の図は Kodougu で書きました。（これがやりたかった。^^）何をやっているのかというと、クラス図のメタモデル（ストラクチャとノーテーション）を設計して、設計したモデリング言語（クラス図）を使ってモデリングして上図を作成したということです。上図の場合、モデリング言語設計は 10 分くらいでできました。

もっとも、Kodougu のモデリング言語設計機能では、多重度が多の関連（属性）を要素に追加することが出来ないので、クラス図に属性をつけることはできません。
# 今がんばっています。

余談ですが、上図のような多対多の関連を実現するために、Rails ではテーブルを一つ作って、habtm という関連を作っています。（articles, tags, articles_tags という三つのテーブルが存在して、多対多関連の実現には articles_tags を使っています。habtm は has_and_belongs_to_many の略で、これを ActiveRecord で指定すると、多対多のテーブルの情報を使って自動的に関連を再現してくれます。）タグ実現の具体的な作業としては、ソースコードを自動生成したらドメインオブジェクトに habtm を一行追加して、ビューとコントローラを整えるだけです。なんというか、便利な世の中ですねぇ・・・。

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）でオブジェクトグラフを再構築してアプリで利用するということをやっています。

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

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

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

[code: ]

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

[code: