あかさたの最近の仕事
2008-07-22 17:32 :
InfoQ に Kodougu の紹介記事を書きました
InfoQ という技術系情報サイトに Kodougu の紹介記事を書きました。主に trac/pukiwiki のようなウェブアプリケーションに Kodougu のモデリング機能を組み込んだらどうなるかという視点で書いてあります。
ソフトウェア開発におけるウェブベースのコミュニケーションにモデリングを導入する
http://www.infoq.com/jp/articles/webmodeling_kodougu
あと 2 本程度記事を書く予定ですが、次回以降は Kodougu の内部技術や、Kodougu キモでありある意味ダークサイドな機能であるモデリング言語設計機能の紹介をします。
Posted by あかさた（編集）
2008-04-09 15:48 :
Kodougu に折れ線を実装した
Kodougu に折れ線を実装しました。まだ折れ線が交差したときの処理は実装していませんが、「関係線をドラッグ＆ドロップすると折れる」「角に表示される選択矩形をダブルクリックすると角を削除する」「角に表示される選択矩形をドラッグ＆ドロップすると角の位置を移動する」機能を実装しました。
続きを読む
Posted by あかさた（編集）
2008-03-17 11:25 :
Flash 版 Kodougu の提供を開始しました
Flash 版 Kodougu の提供を開始しました。といっても IE 限定ですが。当面は FireFox は JavaScript/SVG、IE は Flash クライアントを併用することになります。
まだ試験運用中ですが、速度は従来と比較して 5 ～ 10 倍くらいになっていると思います。
続きを読む
Posted by あかさた（編集）
2008-01-30 02:11 :
Kodougu でアクティビティ図を書いてみた
今、Kodougu のサクサク感向上開発をしているのですが、なかなか出来あがらないので、現実逃避（？）にアクティビティ図を作ってみました。結構、いい加減です。
作成時間は 15 分くらいです。年度内にはパフォーマンスを劇的に向上したクライアント（IE 向け）とメタモデリング機能を一般公開したいのですが、できるやら。。。
続きを読む
Posted by あかさた（編集）
2007-12-20 17:44 :
Kodougu で GUI アプリケーションの状態管理がうまくいってなかった
Kodougu において、「編集ウィンドウを開いた状態で Del キーを押すと図上の要素が消える」というバグを修正しました。
【Bug】編集ウィンドウ上で Del キーを押下すると、図上の要素が消える
http://www.kodougu.net/p/kodougu/ticket/show/21
GUI アプリケーションの状態管理がうまくいっていなかった例です。「特定の状態時」に「どのような操作」を許可するのか、しっかり分析しないと、実行して欲しくないタイミングで拾って欲しくない操作を拾って実行してしまいます。
Command パターンか何かで処理を実装するようにして、Command の実行条件に GUI の状態を指定できるようにするようなフレームワークを作った方がいいのかも。今は何もかもを押しつけられたスパゲティな「Controller」になってしまっているので。
Posted by あかさた（編集）
2007-12-18 17:00 :
Kodougu で PNG 出力機能の実装を開始した
Kodougu で PNG 出力機能の実装を開始しています。なんかぼやけてて、バグバグで、文字化けしてますが、少しずつ前進しています。
以下のような URL を入力すると、Ruby/GtkMozEmbed を使って図のスクリーンショットを撮るというやり方をしています。
http://www.kodougu.net/p/kodougu/diagram/png/82
続きを読む
Posted by あかさた（編集）
2007-12-18 02:44 :
はてなハイクって面白い
はてなハイク（俳句）って私はロムっているだけですが、すごく面白いですね。楽しみ方としては、お題を決めて、短文（五七五である必要はない）か落書きを書き連ねていく（読む側としてはそれを見ていく）だけなのですが、ざぶとん X 枚とばかりにはてなスターをつけることもできます。サクサクと書けてサクサクと読めるのも魅力なんでしょうね。
スターのたくさん付いたエントリをピックアップする機能とか、デイリーのランキングとか、マイリストみたいなものができてくると、あとで見返せていいかも。ネタが秀逸だと、流れていってしまうともったいないとか思うので。（そういう一期一会的な楽しみ方なのかもしれないですが。）
Kodougu でもお題を切って図を描けると面白そうですね。「会員管理システムのクラス図は？」みたいなお題になりそうですけど。(^^;
Posted by あかさた（編集）
2007-12-10 17:15 :
Kodougu の dojo を 0.4.3 から 1.0.1 にアップグレードした作業をまとめてみた
Kodougu で使っていた dojo を 0.4.3 から 1.0.1 に上げました。0.4.x から 0.9 の段階でドラスティックに変わっていたので、Kodougu の JavaScript は 3000 行に満たないのですが、移行にかなり手こずってしまいました。
まだ、運用環境にはアップロードしていないのですが、大半の機能は動くようになったので、作業ログと感想を載せておきます。
作業環境：Firefox で移行作業を完了させてから、 IE での確認。
■ 疑問と感想
(1) イベント系について
イベント系が dojo._base に組み込まれたのはなぜでしょうか。個人的には従来の名前空間（dojo.event.browser）でもいいかなと感じました。それとも、よく使うものだから dojo 本体に入れ込んだのかな・・・？
(2) dojo.io.bind について
敢えて specific な構造（従来は dojo.io.bind という抽象的なメソッドだったのが、dojo 1.0 では、iframe や XMLHTTPRequest などのプロトコルごとにメソッドが準備されている）に変更されたのは・・・まぁ、なんとなく理由はわかりますが、従来の「とりあえず bind」でもよかったかなという気もします。
(3) dojo.io.FormBind が無くなった
また、dojo.io.FormBind がなくなったのが痛かったです。dojo.io.FormBind は、既存の Form の Submit ボタンが押されたイベントを拾って、Ajax 方式でリクエストをサーバに送信してくれるクラスです。
対策としては、Dojo の Form には、Form の Submit ボタンを押すと実行される OnExecute というイベントがあります。Form.execute というメソッドをオーバーライドして、ここで、xhrPost（Ajax）を送信するようにしました。このため、Rails の Form といまいち相性が良くありません（※）。もしかすると、Form 系は Rails を使わずにすべて dojo でやってしまうのも手かもしれません。Kodougu では、Rails で Form の外枠だけ作って、あとから dojo の Form 系 Widget を生成しています。
※ dojo 使っている時点で、Rails の Ajax 系ヘルパーをそのまま使うことはあきらめるしかないのですが。そのうちだれかが何とかしてくれるでしょうけどね。
(4) 感想
0.4.3 から 1.0.1 と、かなり隔たりのある更新作業だったので、正直大変でした。それでも、感覚としては、「ドラスティックな変更の割には、今のところ互換性による影響はそれほど出てない」と思います。（一番困るのは、「××が廃止されたから○○はできません」みたいなことが起こることですが、それはありませんでした。）dojo もいろいろな意味で品質が上がってきたのかもしれません。
dojo.collections -> dojox.collections のような変更が続くなら、バッドノウハウであるコンストラクタをラッピングするだけの Factory を作りたくなりました。ま、作らないと思いますけど。
続きを読む
Posted by あかさた（編集）
2007-11-10 13:56 :
dojo.gfx(dojo 0.4.3) が IE で遅い件について改善にトライした
ここしばらく、Kodougu の IE における高速化を行っていました。これまで、Kodougu の IE 対応は機能カバー率こそ 100% であるものの、速度は Firefox の 1/10 以下という非常に舐めた状態でした。機能カバー率は 50% 程度であるものの Opera 対応の方が実用性が高いかもしれません。
私が IE というものを分かっていないせいだろうと思っていたのですが、どうも調べれば調べるほど、dojo 0.4.3 の dojo.gfx が怪しいということになってきました。（dojo 1.0 が出た時点でやたら古いものを使うなって話ですが。）そこで、 dojo のどこが遅いのか調査してみることにしました。
続きを読む
Posted by あかさた（編集）
2007-11-01 14:29 :
平凡なエンジニアが未踏ソフトウェア創造事業をやったらどうなるのか書いてみた
最近、八角研究所で技術記事を書いているのですが、私が参加した 2006 年度下期未踏ソフトウェア事業（2006 年 11 月 ～ 2007 年 8 月末まで）の体験談を書いてみました。
未踏の体験談を書こうと思った動機について書きます。
私がお世話になった PM は東工大の千葉先生だったのですが、同じ PM 配下でも他の方は凄腕のエンジニアであり、能力的にも住む世界が異なるという感じでした。そういうエンジニアは目立つので、私は未踏のエンジニアというともの凄い凄腕ばかりを思い浮かべてしまうのですが、未踏ソフトウェア創造事業そのものは、適切な提案ができれば平凡なエンジニアにも門戸が開かれています。
というか、普通のエンジニアこそ挑戦すべき制度です。とはいえ、平凡なエンジニアが未踏ソフトウェア創造事業に飛び込んだらどんなことになるのか不安を覚える人もいることでしょう。そこで、平凡なエンジニアが未踏ソフトウェア創造事業をやったらどうなるのか、できるだけ詳細に書いてみることにしました。いくつかのステップは書き落としてしまいましたが、未踏ソフトウェア創造事業の雰囲気を多少なりとも伝える記事になったと考えています。
目次
未踏ソフトウェア創造事業体験記(1) － 提案編
未踏ソフトウェア創造事業体験記(2) － キックオフ編
未踏ソフトウェア創造事業体験記(3) － 開発編
未踏ソフトウェア創造事業体験記(4) － 成果報告編
未踏ソフトウェア創造事業体験記(5) － 感想編
おそらく、未踏ソフトウェア創造事業という名前は今年いっぱいで消えますが、同様の人材発掘プロジェクトは名前を変えて続けていくそうです。多くの方がこの制度にチャレンジしてチャンスをつかみ取れることを期待しています。
Posted by あかさた（編集）
2007-11-12 21:01 : dhrname
http://www.kodougu.net/p/kodougu/diagram/tool/1?profile=true
を、Firefox + Firebugで試してみましたが、
遅くなる原因は、dojoによる、vmlとsvgの要素のつくりすぎかと。
上の例では、図を動かすと、200個以上の要素をすべて消してから、また新たに要素を作り直しています。
Firebugだと、この作業に非常に時間がかかっています。
さらに、transform属性を書き換えると、一瞬で移動したので、描画性能は関係ありません。
Firefox+firebugで「ツール -> Firebug -> Inspect Element」を選択してみてください。
Firebugの情報は検索すればすぐに見つかります。
2007-11-12 22:01 : あかさた
コメントありがとうございます！
おっしゃるとおり、本質的な問題は要素の作成しすぎだと思います。ちょっと状況を整理します。
(1) そもそも VML 要素が多すぎる
(2) 操作のたびに全要素を再生成している
(3) dojo.gfx._creator.createObject() は IE と Firefox の間で 3 ～ 4 倍、createGroup に至っては 30 倍程度の速度差が出ている
(4) IE のレンダラーが遅いわけではない
(5) IE でも Firefox 程度のパフォーマンスが出てほしい
まず、(1) は、図を少数の path で記述すれば要素の生成コストを抑えることができます。回転がある（矢印の先端など）ので、どれくらい減らせるかは未知数ですが、それなりには減らせると考えています。(2) は、一つの操作が与える影響範囲を絞り込めていないため、今は手をつけていません。(3) は、IE のみ dojo の使用を取りやめることで、要素の生成コストは数分の一になりました。ただ、それでも IE と Firefox の間にはまだ速度差がかなりあります。（トータルなパフォーマンスでは 8 倍近いのですが、IE 向けコードから createGroup を排除できていないだけなので、最終的には小さな問題になるでしょう。）
(1) と (2) については、おいおい改善できる問題なので、「がんばれ、自分！」で済む問題と把握しています。ただ、dojo を使って同じ処理を実行したときに、IE と Firefox の間で速度差が 10 倍以上開くとなると、複雑な図になると結局「IE では使い物にならない」という話になってしまいそうで、手を焼いています。
dojo 1.0 で Silverlight を試してみるという方法もあるので、いただいた情報を参考にもう少し試行錯誤してみます。ありがとうございました。
2007-11-12 22:27 : dhrname
がんばってください。応援しています。