Kodougu にオブジェクト図を追加しました。Firefox の悲しい仕様（バグじゃなさげ）により、一時は実装を絶望視していましたが、何とか気合と根性で実現しました。

続きを読む

Firefox の SVG 実装の text 要素では、text-decoration が無視されるそうです。この結果、テキストの下にアンダーラインなどを表示することができません。困った・・・。バグというよりは、現時点では仕様っぽいですが。Firefox は SVG 実装が本気なのかそうでないのかよくわからないので、判断に苦しみます。

Kodougu でオブジェクト図を実装する場合どうしたらいいんだ？？？　Opera とかだと、SVG 実装はかなり本気みたいで、そういうこともないのですが・・・。

現象的には軽微な気がするので、すぐに対応できそうなところを対応していないということは、何か根本的な問題を抱えているということですかね。うーん・・・。

詳細は以下を参照してください。

SVG/対応状況 - Mozilla Firefox まとめサイト
http://firefox.geckodev.org/index.php?SVG%2F%E5%AF%BE%E5%BF%9C%E7%8A%B6%E6%B3%81

Bug 317196 – text-decoration broken: no underline, line thru, etc
https://bugzilla.mozilla.org/show_bug.cgi?id=317196

私のはてなダイアリーではアナウンスしましたが、はてななどのサービスに Kodougu を組み込むために Google ガジェットとして Kodougu を公開しました。

はてなへの組み込み方は以下を参照してください。
http://www.kodougu.net/p/kodougu/wiki/show/Manual/Open

Kodougu のロゴは Dycoon 氏に作っていただいたものです。

経緯を紹介すると、中間成果報告会直前（4 月下旬）に「報告会のプレゼンで使うから、急いで作れ！　ロハで作れ！　いい物を作れ！！」というむちゃくちゃな要求に対して、以下のようなすばらしいロゴを作っていただきました。ありがとうございました。



Dycoon 氏の日記でロゴの紹介がされています。ぜひご覧ください。

Dycoonの日記 - Kodougu Logo
http://d.hatena.ne.jp/Dycoon/20070819

複雑な GUI を持つアプリケーションの設計について（Web アプリ編）を書いていたときに見ていた本は POSA 本だったのですが、以下のエントリでも同じようですね。

Flex2におけるアーキテクチャパターン @ 2007年08月 @ ratio - rational - irrational @ IDM

少なくともPACでいうAgentの開放/閉鎖は意識したほうがよさそうで、それだけでもイベントでワケワカになるのはかなり解消できます。

続報を強く期待します。Flex2 の固有事情とかもありそうです。

PAC で対処しやすい問題と対処しにくい問題があるから、その辺をどう考えるかですね。私はモデリングツールの開発経験が多いのですが、この種のアプリでは、構造ツリーとダイアグラムウィンドウという大きな枠組みがある場合が多いです。こういう大きな枠組みがあると、その単位で Agent を認識できるので、PAC の適用可能性が高く、スパゲティ対策に有効に働きます。

問題は、PAC が対応していない複雑性をどう制御するかでしょうか。たとえば、GUI アプリの状態やモードによって、中間レベル、下位レベルの Agent の枠を越えたアプリの制御を行わなくてはならなくなる場合があります。こういう場合、より上位の Agent に記述しますが、結局そのレベルの Agent の肥大化を招くことになります。これは、フォームやウィンドウのサブクラスを実装するタイプの開発スタイル（VB、Delphi 型）でよく遭遇します。

で、まだ整理されていないようですが、上記エントリに書かれているイベント翻訳（この言葉、知りませんでした。例外翻訳は聞いたことがありましたが。）や Command の適用などの話が出ていますから、その辺に対応策がありそうです。どういう解決策があるのか楽しみですね。

所詮さじ加減といわれるとそれまでですが・・・。(^^;

以下のようなエントリを見つけました。非常に良い問題意識です。そう、GUI プログラミングは泣けるほど面倒くさいのです。

subtech - Pink Blossom Diary - AS3/Flex2 を使い始めて約半年より

まずイベントドリブンなプログラミングに慣れてないのが一つで。Flex のイベントや自前イベントやをただ単に投げまくってると、とりあえずは動くけど後からメンテし辛いスパゲッティコードができあがる。このスパゲッティコードは goto 文が乱立するコードよりも酷く、goto だったら割と行き先は把握できるけど、イベントを投げまくってるだけだと、どこでどのオブジェクトがこのイベントを受け取るかが解らない。解りづらい。いちいちソースコード grep ですね、おめでたいですね。あのイベントが発生してから、そのイベントが終了したら発生するイベントが終了したらウィンドウ閉じて、その間は別のイベントはブロックして/発生しないようにして、とかもうわけわかんない。これも GUI プログラミングをしたこと無いからのような気もしなくもないけど。

もう、このエントリは素敵すぎです。GUI のいやらしさをよく表現しています。しかし、残念ながら、C# + Windows.Forms を使おうが、Java + Swing を使おうが、Delphi + VCL を使おうが、そのスパゲティから逃れることはできません。

なぜ、C# や Java でもこの問題から逃れることができないのか、考えて見ましょう。確かに、Form や Window を継承したクラスにイベントハンドラを追加していくスタイルは、一見すると、わかりやすくて簡単です。でも、何の指針もなく開発を進めていくと、イベントハンドラに、UI の状態管理、アプリの処理、UI の見た目管理などの処理が混ざることになり、結局、Form や Window を継承したクラスはスパゲティになります。

言い換えると、Web アプリは、MVC2 を採用したフレームワークにしたがって書けば、関心ごとがそこそこ分離され、わりと綺麗に書けます。でも、GUI プログラミングの場合、フレームワークに従っても、複数の関心ごとを分離してはくれません。開発者は自衛する必要があります。また、関心ごとの分離という意味では、JavaScript でも、スタンドアロンアプリでも本質的に同じ問題を抱えています。

では、どうすれば、このいやらしさから逃れられるか考えて見ましょう。

(0) 前提

複雑な GUI アプリの場合のアイディアを書きます。一応、Web（Ajax とか Comet とか絡みそうなもの）を前提にしています。

(1) UI の状態は抽象化しよう

UI の状態を抽象化します。vi みたいにモードを作ってもいいです。

GUI アプリでは、特定の作業をしているときに、特定の入力を排除するようなことがあります。保存中に全ての入力を排除するとかですね。どの状態（モード）のときに、どの View 部品が、どのイベント（キーとかマウスとか）を受け付けるか、わかりやすく定義できるような抽象化が望ましいです。View 部品は構造化しておくと、粒度に応じた管理が出来るようになります。

また、UI の状態遷移図を書いて整理して、状態遷移を実現するフレームワークを書いて抽象化してもいいでしょう。State パターンですかね。サーバと通信があるなら、それも考慮した状態管理を行いましょう。

Kodougu ではこの辺の手を抜いていて、関係線の作成中に Del キーを押したりするとちょっと変な動作をします。

(2) イベントハンドラは UI の状態管理だけを行おう

イベントハンドラにアプリの処理を書かないようにしようということです。画面描画に関わるような処理も書かないようにして、UI の状態管理に徹させることです。イベントハンドラは UI の状態に応じて、別のクラスか関数に書いたアプリの処理を呼び出しましょう。

(3) 必要ならアプリの処理と UI の変更処理は分離しよう

ここで言う UI の変更処理とは、たとえば、チャットの場合、ユーザーの発言を受信したら画面を書き換えたりするようなことです。特定の UI の状態で、ボタンを disabled にするような処理は別です。そういう処理は、状態管理で考えてください。

アプリの処理とは、チャットなら、クライアントで発言ログやログインユーザを管理したりするような処理です。

以下のケースなら、アプリの処理と UI の変更処理の分離を検討した方がいいです。当てはまらない場合は行う必要はありません。
1. アプリの処理と UI の変更処理が一対一でない場合
2. アプリの処理と UI の変更処理が同一のイベントで処理できない場合（画面への反映はサーバの応答待ちとか）
3. サーバの処理とクライアントの処理の境界があいまいな場合（Web なら、HTML の組み立てをサーバでやるか、JavaScript でやるかあいまいなとき）

(4) 必要ならアプリのモデルを定義しよう

Web アプリの場合、サーバにはしっかりとしたモデルクラス（社員クラスとかね）があるかもしれませんが、JavaScript にはそれはないかもしれません。サーバとは異なるモデルかもしれませんが、クライアントにモデルが必要になら、ちゃんと定義しましょう。Kodougu（Web 上で動作するモデリングツール） は、クライアントにもモデルを定義しています。

(5) アプリ処理、画面変更、サーバとの通信の順序を決めよう

そのままです。機能ごとに上記の順序が変わるとわかりにくいので、決めた方がいいです。

とりあえず、こんな感じかなと思います。私はまだまだ、JavaScript については経験不足です。Kodougu も JS の部分は、2000 行位しかなく、小さなものしか作ったことがありません。

■ 追記（2007/8/14 4:53）
GUIプログラミングのパターンが知りたい : akiyan.com

イベントドリブンでステートフルなGUIプログラミングには、いわゆるWebサーバーアプリーケーションでの抽象化経験は全然役に立ってる気がしません。むしろ余計に感じたりします。

無駄になるということは無いと思います。要は関心ごとの分離ですから。ただ、フレームワークを「使う」Web アプリ開発と異なり、複雑な GUI アプリはフレームワークを「作る」ことになるという違いはあります。たしかに、Rails アプリを作るように、複雑な GUI アプリを作ったら自滅しますね。そういう意味では、上記の余計に感じるという表現は非常に示唆に富んだものだと思います。

秋葉原のザ・コンピュータ館が閉館されるらしいです。知らなかった・・・。10年前は、秋葉原といえば、ザ・コンだっただけにショックです。もっとも、ここで PC を買ったことはないような気もしますが。(^^;

ラオックス、旗艦店「ザ・コンピュータ館」を閉館へ－経営再建で - アキバ経済新聞 - 広域秋葉原圏のビジネス＆カルチャーニュース
http://akiba.keizai.biz/headline/575/index.html

ここの書籍スペースは IT 系では最大クラスなので、職業柄重宝していました。でも、言われてみると、最近は専門書も Amazon で買ってますし、私は PC は元々大手ではなく、ショップブランドか自作なので、ザ・コンが閉まっても影響はありません。

まぁ、そういうことなんでしょうね。。。

ついに来ました。未踏の成果報告会です。私も「Web上で動作するモデリング環境 Kodougu の開発」というテーマで発表します。皆様、ふるってご参加ください。

日時：2008/9/7（金）10:00 - 18:00
場所：東京工業大学大岡山地区西９号館１階デジタル多目的ホール

詳しくは以下のサイトをご参照ください。

未踏ソフトウェア創造事業2006年度下期
千葉 PM 採択プロジェクト最終成果報告会
http://www.mitou-chiba.org/

■ 関連記事
未踏成果報告会にオブジェクトの広場が緊急参戦！（予告編）
http://www.ogis-ri.co.jp/otc/hiroba/Report/Mito200709/announce.html

私は、マークアップエンジニアという言葉は知りませんでしたし、ぶっちゃけ CSS で盛り上がる世界が存在しているということも理解できませんでしたが、以下のエントリの言わんとしていることは賛成です。

ただ、一つ違和感がありました。

IT戦記 - マークアップエンジニアはどこへ向かうべきか（を考えてたらカッとなって LL の資料公開）より

(X)HTML + CSS しか出来ない人はそれなりに危機感を感じたほうがいいと思った今日の昼ご飯でした。

JavaScript をごりごり書いている私が言うのもなんですけど、そんなこと言っちゃったら、Web 系エンジニア全体が微妙な気が・・・。CSS がバッドノウハウの塊で、極めるほどの本質的な奥行きがないなら、JavaScript もある意味同じ気がします。ぶっちゃけ「ブラウザ上なのにこんなことできて凄い凄い！」という世界ですからね。(--;　VC なら凄くねぇ！

# デモ、VC ノホウガムツカシイあるヨ。

つまり、私が感じている違和感は、本質と表層の捉え方なんだと思います。

http://twitter.com/amachang/statuses/191263472 より

「CSS 道」は道が短すぎるんだ。マーケティングの為に長く見せてるけど、実際覚えることは少ない。「デザイン」か「JavaScript」を職業に出来るくらいにしとかないとヤバいと思う。

私としてはデザインと JavaScript を同列においているのが少し気に食わないわけです。本質的な奥行きを持つデザインと、表層的な奥行きしかない JavaScript で比較するなんて。JavaScript のノウハウの少なくない部分は、言語が改善されれば（あるいはフレームワークやライブラリによって）消えゆく「べき」ものです。CSS ハックの大半がブラウザ（主に IE）の改善とともに消えゆくように。本質的な奥行き感で言えば、デザインと UI プログラミングくらいなら、結論として納得感があるんですけど。

# 絵のセンスがない私にとっては、絵描きさんやデザイナさんは尊敬の対象です。

UI に関係するプログラミング言語の変化はめまぐるしいです。つい最近まで主流だった VB も Delphi も Java + Swing も生き残っているとは言いがたいです。変化の激しいこの世の中で、JavaScript だって長く生き残るかどうかはわからないわけですよ。Ajax や Comet だって、本質的な部分には非常に奥行きがあるわけですが、表層に限って言えばあまり言うことはないわけです。近頃は Ajax.Request とか dojo.bind とか書けば Ajax してくれますから。

でも、UI に関係するプログラミングは実に奥が深いです。下手な書き方をするとすぐにメンテ不能やテスト不能（VB や Delphi のフォームみたいに）に陥ります。また、ユーザが直接触る部分ですから、工夫の余地は無数にあります。これらは、言語によらない本質的な難しさであり、価値です。

もちろん、今使っているプログラミング言語に精通することは大切です。でも、IT の世界は歴史が浅く道具の変化が激しいので、本質的なスキルは何か見極めていかないといけないんじゃないかなと思います。CSS の後に JavaScript では・・・あまりにも短期的な視点で食っていくためというのがアリアリ。そりゃ、食わにゃ死にますが、長期的かつ本質的なスキル開発を促しても良いんじゃないかな？、と思いました。

あ、でも、本エントリの言わんとしていることには賛成です。第二の何かは、Rails している人も、PHP やっている人も、JavaScript をやっている人にも、等しく必要なんだってことです。Java している人にもね！

以下、余談。

○ 余談１

とはいえ・・・C/C++ 言語の世界は変化が少ない・・・というか、変化はしているのだろうけど、プログラミングそのものが奥行きを持っている気がします。対象領域の違いから来るものでしょう。C/C++ だってアプリの世界なら同じ問題を抱えていると思います。

○ 余談２

スタンドアロン（Delphi + VCL でも Java + Swing でも VB でもいいけど）の世界を知っていると、HTML + CSS + JavaScript（＋LAMP）が、意外と理にかなっていて面白い世界なのが良くわかります。Web 系技術が凄くないと連呼する人はいるけど、また、私もそう思うけど、これまでのやり方よりは優れているんです。個別に見ると新しい技術はなくても、組み合わせて使うと新しいみたいな感じです。
実際、Kodougu（Ruby on Rails + JavaScript で実装されたブラウザ上で動作するモデリングツール）は、Java + Swing や C# + Windows.Forms で実装された同系統のソフトよりもはるかに短いコード（＝メンテしやすい）で実装できています。やはり、Web 2.0 のときに技術的にも何かが起こったんだなって感じます。「気づき」のあるなしとか些細なことなんですけど。

このブログの左側のメニューにはてブの人気エントリを表示してみました。はてなブックマークからサイトの注目記事を RSS で取得して、HTML に変換して表示しています。コードはざっと以下のような感じです。

require 'rss'
require 'net/http'
Net::HTTP.version_1_2

hotentries = ''
url = 'http://www.rmake-labo.com/akasata/'
rss_source = Net::HTTP.get('b.hatena.ne.jp', 
  "/entrylist?cname=&url=#{CGI.escape(url)}&sort=count&mode=rss")
rss = RSS::Parser.parse(rss_source)

rss.items.each do |item|
  hotentries += <<-EOS
    

      #{item.title}
      
        
      
    
  EOS
end

実運用する際は、はてなの RSS をキャッシュしたりしないと、はてなが重くなっちゃうので気をつけましょう。