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



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

どうしたものか・・・。

今日は、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

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 が大量に出ると、処理が重くということでしょうか。

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

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

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



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

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

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

Kodougu の最新のスクリーンショットです。図上で要素と関係線の作成／削除／選択／移動を実現しました。図上で行う最低限の操作が実現されました。



動画はこちらにあります。（ちょっとカクカクしていますが・・・。）

ここまで、クライアント側（JavaScript）は 500 行弱、サーバ側（Rails）は 1500 行程度と、非常にコンパクトに実現できています。３月にはデモサイトを構築したいところですが、はてさて・・・？

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

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

図上で要素の作成／選択／移動／削除を作成しました。現時点でのスクリーンショットは以下のとおりです。

2007/2/7 時点の Kodougu のスクリーンショット

ここまで、クライアント側（JavaScript）は 300 行弱。全機能を実装しても 1000 行程度に収まるんじゃないかと。サーバー（Ruby on Rails）側もまだ 1000 行前後だと思いますし。JavaScript + Ruby on Rails の組み合わせは恐ろしいほど生産性が高いですね。。。

FireFox 版 Kodougu は、3 月末にはリリースしたいと考えています。がんばらねば。

2007/2 ～ 2007/4 の Kodougu の開発戦略をここに記述します。

○ モデリング機能開発
リスクは二つです。「マルチブラウザ対応」と「どれくらいの UI を実現するか」です。4 月末までにはベータ（機能拡張は基本的に終了）の状況にします。

・ マルチブラウザ対応
本プロジェクトでは、FireFox, IE を対象とします。

まず、4 月末までに FireFox 版を作成し、ブラウザ依存になる箇所（VML, SVG の実装依存の箇所とJavaScript の実装依存の箇所）を切り出し、マルチブラウザ対応の準備を完了します。

IE 対応は 5 月以降です。SVG の実装状況によっては、Safari や Opera も対象とする可能性はありますが、やはり 5 月以降です。

・ どれくらいの UI を実現するか
いわゆる Jude や EA のようなリッチな機能を完全にブラウザ上で実装することには限界があります。4 月末までにはブラウザ上で実装できる機能のうち、必要と思われるものを全て実装します。

○ モデリング言語設計機能開発
・ ノーテーション及びシンタックス
リスクは二つです。一つは、「どれくらい設定できれば十分なのか」、もう一つは「どのような UI が適切なのか」です。

現在は DB に直接 Ruby のコードを入れてこれを実現していますが、4 月末までに、メタモデリング機能の用途を明らかにして、これらのリスクの解決に着手している状態にします。

・ ストラクチャ
リスクは二つです。一つは、「メタモデリングに必要なストラクチャを十分に準備できるか」、もう一つは、「メタモデルの変更点を既存モデルにどのように反映させるか」、です。

4 月末の時点では、前者を解決し、後者の実装を開始したいと考えています。

・ セマンティクス
特にリスクはない（メタモデルの説明を文章や絵で説明できれば OK）ので、4 月末までにセマンティクスを記述する機能で欲しいものを列挙してから実装します。

○ そのほか
・ Web ページの構築
4 月末までには実施します。（できれば、3 月上旬には行いたい。）

・ 国際化
4 月末までは対象としません。5 月以降に国際化及び地域化（日本語、英語）を実施します。

○ 2007/5 ～ 2007/7
・ 積み残したリスクの解決
・ マルチブラウザ対応
・ 国際化
・ 安定化、リファクタリング
・ マニュアル等のドキュメント整備
・ 宣伝活動（？）
・ コミッタの募集
・ 要望の収集

今日は未踏のミーティングに行ってきました。今日のミーティングの議題は、下期採択プロジェクトの進捗報告、これからの開発の展望の説明、上期の成果発表会の段取りについてでした。

（私の未踏プロジェクトについてはこちらを参照してください。）

私に関係する内容としては、進捗報告とこれからの展望の説明なのですが、進捗はいいとして、これからの展望の説明にはまってしまいました。(--;
# 千葉先生に結構ツッコまれました。orz

私のプロジェクトのミソは、実装技術的な難しさとメタモデリング言語設計の難しさにあると私は考えていますが、メタモデリング言語がどのように落ち着いていくのかがいまいちうまく説明できませんでした。ノーテーションの説明はできたものの、シンタックスと構造、セマンティクスのところは玉砕。orz
わかりやすいサンプルがあるとわかりやすいというアドバイスをいただいたので、そういうものをそろえて一度考え直す必要がありそうです。今月中にやりたいところです。
# ちなみにキックオフ時と比較するとちょっとトーンダウンしている（＝広げてた大風呂敷が小さくなってきた）と言われたのは秘密です。（笑）

私の説明技術不足もさるところながら、考慮できているところとできていないところのムラがあることも問題です。来月からは時間も取れることだし、もっともっと頭を使って考えないと。

こういっちゃなんですが、最近、仕事中いかに頭を使っていないか思い知らされることが多いです。意識して頭を使っていきたいものです。

未踏プロジェクトの Kodougu を SourceForge に登録しました。まだほとんど何も出来上がってないですが・・・。

SourceForge.net - Kodougu Project
https://sourceforge.net/projects/kodougu/

SourceForge.jp ではなく、本家に登録しました。もともと、未踏の提案でも日本国内だけにしませんよという内容にしていたこともありますが、本家では Subversion が使えるという点も大きいです。日本でも、ベータ運用みたいなことは始まっているようですが。

やはり最大の難関は、英語でプロジェクトの説明文を送付することでした。SourceForge.net（.jp でも同じですが）では、登録する際にプロジェクトが SourceForge に登録するにふさわしい内容（※）であることを説明するために、数十行くらいの英作文を求められるのです。

私の英語能力は近似値 0（TOEIC の点数とか素で言えないくらいです）なので、30 分くらいで作った英文なんて読まれすらされないと思っていましたが・・・無事登録されたようです。よかった。

あとは、Kodougu の Web サイト（兼デモサイト）を作らないとな～。

※ そんなにたいしたものではなくて、公序良俗に反しないとか、オープンソースのプロジェクトかどうかとか、そもそもどういうプロジェクトかとか、そういうことをちゃんと説明できれば問題ありません。私の英語力からすると、未踏の提案を出すよりも難関だったことは秘密です。（オイ）