「pukiwiki に Kodougu を組み込む」の続きです。SourceForge.net 経由で pukiwiki プラグインの修正版が投稿されました。少し使い方が変わっているので、注意してください。

Kodougu の pukiwiki プラグインソースコード置き場

上記プラグインをインストールした後、以前はプラグインのコードを書き換えていたのですが、現在は設定ファイルを書き換えるようになっています。pukiwiki インストールフォルダ直下の pukiwiki.ini.php に以下を追加してください。（私は、9 行目の「// PukiWiki main setting file」というコメントの直後に書いています。）

username は、ご自身の ID に変更してください。（現在は変更しなくても動きますが、これはバグです。）

/////////////////////////////////////////////////
// Kodougu settings
define('PLUGIN_KODOUGU_SERVER', 
    'http://www.kodougu.net/u/username/diagram/tool/');

より良いコードが投稿されるのはオープンソースの良いところですね。ありがたいことです。安定動作するようになったら、pukiwiki の公式サイトに投稿する予定です。

最近、はてなダイアリーを使っています。ここのブログは自作スクリプトですが、いまいち使い勝手が良くないので、はてなダイアリーを使ってみて、このブログの足りないところ、だめなところを探してみようと考えていたのですが、使い心地がいいので、そのまま永住したくなりました。（笑）

あかさたの日記
http://d.hatena.ne.jp/akasata/

ただ、はてなではブログ上に JavaScript でプログラム貼り付けたりとか自由にはできないので、自作ブログはやはり必要です。当面は技術系の内容はここ、趣味の内容ははてなという感じで使い分けようかな、と思っています。

でもまぁ、やっぱ、餅は餅屋だなー。

「お知らせ:「コナミコマンド」を実装しました」によると、コナ○コマンドはできるらしいです。コードを見てもらうとわかりますが、if 文で普通に分岐しています。これはこれでお手軽な実装ですが、こういうものを見ると一般化してみたくなります。

上記サイトより抜粋：

var konmaiFlag = 0;
function konmaiCommand(konmaiKey){
	if (konmaiKey == 38 & konmaiFlag == 0){//上
		konmaiFlag = 1;
	}else if (konmaiKey == 38 & konmaiFlag == 1){//上
		konmaiFlag = 2;
	}else if (konmaiKey == 40 & konmaiFlag == 2){//下
		konmaiFlag = 3;

キーの配列を受け取ったら実行してくれるクラスがあると便利ですよね。特に以下のような書き方ができたら楽しいですね。

// 上、上、下、下、左、右、左、右、b、a
var keys = [38,38,40,40,37,39,37,39,66,65];
var processor = new KeyCommandProcessor(keys, onSuccess, onError);

作成してみました。以下にサンプルページ＋全ソースコードがあります。
キー入力サンプルページ（IE/Firefox）

でも、上記の実装だと、波○拳を繰り出すことはできません。なぜなら、複数のキーの同時押しができないからです。この手の実装はゲーム開発者にとっては当たり前のものだと思いますが、馴染みがないとなかなか難しいです。ス○２の波○拳の場合、下、下右、右、パンチです。私の記憶が正しければ。ここでは、↓、↓→、→、A を実現するようにします。とりあえず以下のような書き方をしたいものです。

// 下、下右、右、a
var keys = [40,[40,39],39,65];
var processor = new KeyCommandProcessor(keys, onSuccess, onError);

作成してみました。以下にサンプルページ＋全ソースコードがあります。ポイントは入力したキーを複数個持つことです。prototype.js とか使って配列を操作する機能を強化すれば、半分くらいのコードで書けると思います。でもまぁ、ここまで来るとあまり、手軽なものにはなりませんね。
キー入力サンプルページ（IE/Firefox）

実は現時点でも結構手抜き実装（格闘ものならもっとキー操作は厳密にする方が良いです。）ですが、ずいぶん進歩した気がしますね。上記のコードは全てパブリックドメインです。かなりバグがあると思いますが、適当に料理してやってください。

今日は Kodougu を pukiwiki に組み込む方法を紹介します。

(1) pukiwiki プラグインをダウンロードする
以下からダウンロードしてください。
http://kodougu.svn.sourceforge.net/viewvc/kodougu/trunk/tools/pertners/pukiwiki/kodougu.inc.php?view=markup

(2) プラグインを pukiwiki にインストールする
上記 php ファイルを plugin フォルダにコピーします。

(3) wiki ページに以下のように書き込む

#kodougu(/u/username/diagram/tool/<>)

引数には、あなたの図の URL を入れてください。

セキュリティなどを考慮していないので、JavaScript などを埋め込めてしまうかもしれません。（いわゆる XSS 脆弱性。）編集制限をかけている pukiwiki で使用するか、公開で使用する場合は、以下の手順でプラグインを書き換えてください。

○ iframe の src にユーザー情報を含めて、引数を数字のみにする

現在（８ ～ ９行目）：

if ($id != '') {
    return '




Metaelement のインスタンスは、UML でいうところの Class, Usecase などです。Metaattribute は値型の属性（整数や文字列）、Metareference は参照型の属性を表します。Metaattribute の例は Class 名です。Metareference は、Package が複数の Class を持つような場合を表現するために利用します。



Metanode はそのモデルの表記を表現します。多重度が複数になっているのは、一つの Metaelement が複数の表記を持っている場合があるからです。たとえば、UML のインタフェースには、ロリポップと分類子表記（矩形表記）があります。



うーん、まだまだ表現能力不足です。


  

Ruby で URL エンコーディングを行ってくれる CGI.escape メソッドでは、スペースをプラス（+）に変換します。（仕様どおりの動作だと思います。）しかし、JavaScript でデコードを行う decodeURIComponent() 関数では、+ をスペースには変換してくれないようです。したがって、Ruby でスペースを含む文字列を URL エンコードをして JavaScript でデコードすると、プラスがデコードされずに残ってしまいます。

Kodougu でこの問題にあたってバグが発生したので、とりあえず、Ruby で URL エンコードした文字列のプラスを %20 に置き換えました。%20 はスペースに変換してくれるようです。なにやらこの手の問題は微妙にエンジニアを悩ませますね。。。

Kodougu をアップロードしました。といっても、機能的にはあまり変わっていませんが、登録したユーザーは自分のモデル／図を作成できるようになっています。チュートリアルにはその手順が載っているので、参照してください。（記述の不備、動作不具合につきましてはぜひお知らせください。）

【更新内容】
(1) この記事で報告されたバグを修正
(2) 図の公開／非公開機能を追加
(3) Kodougu のチュートリアル（日本語版）を作成しました。

バグ等ありましたら、当面はこの記事のコメントによろしくお願いします。（そろそろ BTS を立ち上げたいところですが、どうしたものか・・・。スパムに強くて敷居の低い BTS があると非常にうれしいのですが。。。）

私が書いたにしては妙に反応のあった「Ruby なんて遅くて使えないよねって言ってみる」についてです。

釣りっぽいタイトルと整理されていない内容のおかげで誤読が出るとまずいので、念のため補足します。このエントリの趣旨は、Ruby は遅いけど、Web アプリにおいてはその遅さがシステムのトータルなパフォーマンスに与える影響はそれほど大きくは無いので、Ruby を使っても問題はないということです。ついでに言えば、私は「プロトタイプは Rails、本番はパフォーマンス／スケーラビリティを考慮して Java」とか「Rails を採用すると運用フェーズでコストが増大する」という意見も鵜呑みにはできないと考えています。本当に Ruby/Rails がボトルネックになっているのかと聞いてみたいところです。

ま、そんなことよりも、この記事に対応する記事を書いた方々を紹介します。いずれも、良いことが書いてあるので読んで見ると吉です。

■ 記事を書いてくださった方々
Ruby の作者であるまつもとさんに言及していただけるとは感激です。しかも的確なエントリに感謝です。

じゃあ、速度の問題はこれで解決かというとそんなことはない。 YARVになってもRailsの性能は改善されないからだ。要するにRailsが遅いのだとしてもそのボトルネックはインタプリタ性能にはないってこと。

Rails の性能の悪化はしないようですね。VM がからむと、eval のあたりで速度低下が起こっても不思議ではない気もしますが、処理系の性能向上と相殺されているのでしょうか。それとも eval は JIT コンパイルされないのかな。とにかく、Rails は eval だらけだった気がします。Kodougu はわりと eval を使っていないので、YARV の恩恵をダイレクトに受けられそうでわくわくしています。（ユーザーメリットは無いでしょうが、1ms でも高速になるとときめくのです。）どちらにしても、Rails のパフォーマンスのネックになっているところを調べないと。

航海日誌(2007-07-07) でも取り上げられているようです。Java 使いの方かな。2007 年度の未踏の方のようです。

JavaでGenerics，拡張for文，可変長引数，static import，anonymous classを上手く使うとびっくりするぐらい楽になる．このうまさを知るともう戻れない．

同意です。Java でも「上手くやれば」生産性（ここでいう生産性はコード数）において Ruby にそうそう負けるものではありません。そして、Java のパフォーマンスは心強いです。ただ、「上手くやれば」という条件付です。私は Java、C# で、（モデリングツールですが）コードの爆発的増量を経験しているので。今のところ Ruby では起こっていないようです。（私のスキルレベルでも生産性を発揮してくれる Ruby は大好きだ。）要は、私の Java/C# スキルの問題なんですが、Ruby よりは習熟しているはずなんですけどね。。。

やむにやまれず:Rubyは遅いから使えるのですというブログでも取り上げられていました。

逆でしょう。RubyやRailsは遅いから使えるんです。

あらら。読んでもらえなかったのかしら。結局使えるって書いたつもりだったのですが。私はもうちょっと整理したエントリを書かないとだめですね。orz　それはともかく、遅いってことは、いろいろやってくれてるんだから、使えるにきまっているじゃないかってことですね。面白いエントリです。

またスケールアウト時にはマシン台数が増えて、メンテナンスのランニング費用が特に脹らむことでしょう。

ランニング費用をサーバ管理費中心にしているのが若干微妙です。ソフトウェア開発は保守の方がコストがかかるので、運用フェーズになっても Ruby/Rails のメリットはむしろ上がって行きます。一人のプログラマが一年あたりに書けるコード数が一定ならメンテナンスできるコード量も一定（※）です。そして、時代は永遠のベータ。（少なくとも Rails が対象とするアプリは運用しながら開発が続けられていきます。Kodougu みたいに。）

と、異議は唱えてみたものの、基本的には面白いエントリでオススメです。（面白いから異議を唱えるんだな、これが。）

※ こういうことを書くと、動的言語は本当にメンテナンスしやすいのかどうなのか疑問を投げかける人が出てきそうです。この辺、誰か解説して欲しいなぁ。今のところ私は保守しにくさは感じていませんが、それは規模が小さなアプリだからでしょう。でも、数千、数万人月とかになるような巨大システムの基幹に Ruby/Rails を据えるような人はいないですよね？

■ そういえばこんなツッコミはなかったなぁ・・・
例：えらそうなこと言ってる割には Kodougu 重いじゃねーか。だから Ruby はだめなんだよ。今からでも Java で書き直すか？

えーと、あの、その、Kodougu が重いのは JavaScript で書いた部分がいけていないからです。はい。サーバは結構余裕です。あぁ、JavaScript を書き直したい。時間が欲しいな。

■ 追記（2007/7/21 12:04）
こちらからさらにお返事いただきました。感激。意図が伝わらないのは、釣りっぽい書き方をした私の責任です。スンマセン。丁寧なお返事ありがとうございます。

Kodougu では、要素のエディタを dojo.widget.Dialog で作っています。ところが、要素の編集を行って Dialog を閉じてから、もう一度開いたときに、編集が反映されず古い情報が表示されてしまいました。

Dojo では、デフォルトで Dialog や ContentPane などの中身はキャッシュされるようです。Dialog を show する前に、以下のように書くとキャッシュをクリアできるようです。

dialog.refreshOnShow = true;

それにしても、Web アプリというのはキャッシュとの戦いですね。レスポンスを良くするにはキャッシュが必要ですが、キャッシュのクリアし忘れによって思わぬバグに遭遇することもある・・・ということです。難しいですね。

「404 Blog Not Found:Web業界の底上げとか崇高な考えがあるなら、お前ら率先して金取ろうよ」を読みました。こういうエントリは好きです。別に IT に限った話ではないですが、エンジニアはお金を取ることに罪悪感でも感じているのか、そういうことには消極的です。理系の生涯年収が文系と比較して 5000 万少ないとか言われることとも関係があるかもしれません。

※ この話題の計算方法はちょっと微妙かもとは思います。この話題は、どこぞの国立大学の出身者の統計ということです。それなりの大学を出ていると、文系出身の人の中には商社や金融機関の人が増えてくるでしょうから、技術者の給料と比較してもね、って気がしています。

このエントリの元ネタになった「お金の臭いがする」と話題の某イベントですが、お金の臭いを撒き散らす人が入ってくるのもそれはそれで良いことなのかもしれません。（注、さっくり見た感じでは、その某イベントもそんなに金にまみれているようには見えませんが。。。）

私も肝に銘じなくてはいけません。今未踏でソフトを作っていますが、仮に有望なソフトができたとしても、お金を集める方法は Google Adsense ではあまりにもね。良いものを作ってちゃんと売る、まずはここからです。