弱い技術者は実はおやじ予備軍というエントリを見て感じた事を書きます。と言っても、このエントリの書いてある本筋には大賛成です。枝葉末節についてです。

弱い技術者は実はおやじ予備軍より

実は、チャンジャーに見えるRailsユーザもおやじ予備軍の危険性があります。「JavaからRubyへ」でこのような意見があります。Javaの世界はフレームワークが乱立していて適切な組み合わせを選ぶのが大変だからRailsで統一されているRubyがいいんだと。 これには、全然賛成できません。悩みたくないからスーパーなデファクトを望むのは、危険だと思うんですよね。ライバルがいないとどうしても進歩の速度が鈍ります。Rails一党独裁よりも、いくつかのフレームワークが競い合うほうが健全なのではないかと思います。

前の Rails 勉強会では Merb というフレームワークが紹介されていました。こちらの記事が詳しいです。このフレームワーク自体はまだ実用には時間かかりそうですが、Rails ユーザも一党独裁問題に対しては、バランスを取り始めています。言い換えると、Rails ユーザはいい意味で Rails に対して批判的です。この流れは、今はかなり進んでいるエンジニア限定ですが、いずれ一般的な Rails ユーザにも波及してくことでしょう。

Rails vs Seasar にでもなっているのか、ひがさんは Rails 系には手厳しいですね。。。

弱い技術者は実はおやじ予備軍より

典型的なおやじ予備軍は、自分で考えるよりも権威のある人にこれだって言ってもらうのを好みます。身に覚えはありませんか。これって頭の固いおやじがスーツなやつらに付け込まれているのと同じです。

今はひがさんも「おやじ」をたらしこむ力が付いてきたでしょうから、「だから Rails 厨は・・・」なんて書き方をされると絶大な効果があります。願わくば、批判するなら Rails ユーザの実態をよく調べてほしいところです。

ソフトウェア技術者がどっかの段階で覚えなきゃいけないことを読んで思ったのは、広場っぽいカラーが出てていいなぁと思いました（笑）。私の結論は以前書いたとおり、自分の目指すところに合わせてポートフォリオを組んでくださいということですが、この考え方を使ってソフト（Kodougu）を組んだばかりなので、いまさらですが再考します。

ソフトウェア技術者がどっかの段階で覚えなきゃいけないことより

ソフトウェアにはメタな構造があって、さらに根源のところでは自己記述っぽい形でぐるぐる回ってるというイメージを持つ事じゃないかなーと思う。これはソフトウェアの本質そのものなので、知っておいて損は無いはず。

例に挙がっている Lisp なら、Pure Lisp の言語仕様と car/cdr に注目してもいいと思います。より、シンプルで本質的です。ちょっと視点は変わりますが、Ruby で DSL を作った Rails がなぜ流行るのかも考えてみるとよさそうですね。

マシン語だって、高級言語からアセンブリ言語、そしてその命令がスーパーパイプラインでどのように処理されているかというような階層を知れば、意外とそういう理解を得ることも可能なんじゃないかなという気がします。それに、知れば知るほど、深く掘れば掘るほどシンプルで要素分解できるというほどわかりやすい世界でないことがわかります。Pentium4 が出た時は、CPU は神のお告げで命令の実行順を決めているなんて言われたもんです。（μOP、分岐予測あたり。）言うまでもなく、shi3z 氏はこの手のことくらいは熟知していると思います。

確かにこの手の知識は必須じゃないのですが、その割にこの手の知識を知っている人には技術的に「骨のある人が多い」のも事実なんですよね。なんでだろ。

さて、メタ階層的な話に戻ります。Kodougu は UML の抽象構造であるメタメタモデル（UML Infrastructure）をいくつか改造して実装しています。メタモデルはデータで表現されています。適切な例かわかりませんが、クラスとオブジェクトの関係が、メタメタモデルとメタモデルの間に表現されています。メタモデルのデータをもとにコードを生成して、クラスとオブジェクトの関係をメタモデルとモデルの間に構築しています。そのため、Kodougu はモデリング言語を設計することができるのです。また、メタ階層的な考えで実装しているため、Kodougu のコードはサーバは 4000 行（Wiki とか余分な機能が含まれていますが）、クライアントは 2000 行で書かれています。この種のアプリの一般的なコード量は十万行から百万行程度になりますから、ずいぶんスリムです。

この手の設計思想のメリットは、初期の開発コストはそこそこ高いですが、ソフトウェアの規模が小さいため、保守コストが小さいことでしょう。デメリットは、このメタ階層が処理できない問題にあたると、どうしようもなくなるか、途方もないコストがかかる恐れがあることでしょう。そういう意味では、もっとももメタな部分の設計／実装センスが問われてしまうので、リスクを取ってでもやりたいという強いモチベーションが必要です。（ここでいうセンスは別に先天的なものを意味しているつもりはありません。音楽やスポーツに要求される”才能”とは違う気がします。）

それがアーキテクチャ設計の宿命だといえばそれまでなので、エンジニアとして生き残っていきたいのなら、この種の能力は必須かもしれません。

お、スラドでも話題になっているようです。さすがにスラド、割りとガチでテクニカルに議論している気がします。

昨日は、Rails 勉強会＠東京第 22 回に行ってきました。半年ぶりくらいの参加でした。

この勉強会は昼ごろに集まって、やりたいセッション（合計 5 ～ 6 個）を出し合って、前後半それぞれ 3 ～ 4 個のセッションを行うという形式になっています。参加者は、興味のあるセッションに参加します。私は前半は「よろず悩み相談室（？）」、後半は「Finder の実装（render_component が使えないからもっと良い仕様を考えよう）」に参加しました。正直、Ruby にも Rails にも詳しくない私にとっては何を聴いても勉強になります。

前半でおもしろかったのは、with_scope に関する不満でした。要約すれば、with_scope をネストして掛けたいということでした。「blog.user.blogs」というような記述をする時に、blog を検索するのに使った条件を、blogs にもつけたいということでした。（これはこれで関連の意図と違ってしまうので、with_scope の現在の仕様は納得感がありますが、こういう検索を楽に行う機能があったらいいというのは私も賛成です。）ストアドプロシージャで解決するという話は、もっと簡単な方がいいなぁと思いました。なんか誰かが作りそうですけど。

後半は、render_component の改善案についてでした。render :partial の不満点かもしれません。問題点は、二つ。一つは、render_component が遅いこと。もう一つは、render :partial を実行する際の find 関係の処理を記述する場所が欲しいというものでした。後者の不満点を解決するのが render_component ですが、前者の問題で使えません。render_component は Kodougu でも、一部使っています。（メタメタに言われている機能なので、積極的には使ってないですけど。）この話を聞きながら、こっそり Rails のコード（ActionPack）を読んでいました。話についていくのがやっとですが、そこそこ追えるようになってきたかも・・・。

終了後は懇親会へ。一次会はもんじゃ、二次会はさくら水産でした。いろいろな話をした気がしますが、よく覚えていません。(^^; こういう勉強会に顔を出すとみなさんよく勉強されているので刺激を受けます。私も頑張らないとナー。

Rails 勉強会用ポジションペーパです。念のため以下に貼っておきます。

PowerPoint2007 形式
PNG 形式

Kodougu は、こちらの手順で国際化しています。Rails で国際化するのによく使われる Ruby-GetText-Package ですが、PC を新しくしたら、ちょっとはまってしまいました。Windows Vista 上で rake updatepo したら、msgmerge が見つからないというエラーが出ました。前のマシンでは GTK+ をインストールしていたのでこの辺の設定をしていたのですが、今回はまだやっていないことに気がつきました。なんという間抜け。(--;

以下を参照しつつ、対応しました。
http://www.yotabanana.com/lab/20060910.html

新しい PC をセットアップすると、何かしらミスをしますね。。。orz

shi3z 氏のマシン語関係のエントリを読んでいたら、久々にアセンブリ言語で書かれたプログラムを読みたくなったので、かつて自分が書いたコード（Delphi のインラインアセンブラですが）を読み返していました。まだ書けるかどうかは怪しいですが、読むことはできるようです。10 代のころにやったことはなかなか忘れませんね。

さて、shi3z 氏の言わんとしていることはわかりますが、IT もこれだけ複雑になると、「××が必須」というのはなかなか難しくなるのではないかなと常識的な反応をしてみます。SE なら、会計知識だったり、物流の仕組みだったり世の中のことを知っているほうが重要な場合もたくさんあります。

思うに、システム作る人ってあまり生き残らない気がするのです。パッケージを利用したり、SaaS（この言葉自体は微妙ですけど）だったり。SE の仕事は何を使えば業務が遂行できるか判断するのとツールのカスタマイズが主な仕事になるのではないかとさえ思います。組み込みやゲームは違うかもしれませんけど。もっともそういう人は、SE じゃなくて IT コンサルとか名乗っていくのかもしれません。

パッケージや既存システムに問題があったらサポートに連絡です。これは MySQL だって一緒です。大体、企業でオープンソース製品が話題になるのは、オープンソース製品が重要というよりは、製品サポートビジネスが立てたい人たちが仕掛けているところもあると思います。コードの中身が公開されていて安全ですよ、しかも弊社のサポートがあるので何があっても大丈夫です、みたいな感じで。

結局サポートに頼るなら MS だっていっしょじゃん！
# パッチリリース速度なら MS だって OSS に負けてないし。

そういうこともあるのか、昨今の SE はアセンブリ言語どころか、複数の言語を操れない人さえいます。プログラミングわからない IT コンサルを何とかしてくれという人もいますが、彼らは彼らでないと困る様々なスキルを持っています。

この手の議論は、SE は理系出身でないと務まらないかどうかという話題に近いと思います。これだけ複雑化してきた世の中なら、お決まりの文句になりますが、「いろいろな人が必要なんだから、それぞれの専門を尊重しながら仕事しましょうね」ってことになりますかね。何かひとつふたつベースになるものを身につけてくださいってことで。（で、これらの人たちがコミュニケーションするにはモデリングが欲しいよねってことで、Kodougu をよろしく！）

でも、作る側に残りたいのなら、アセンブリくらいやっとかないとね。というわけで、MySQL とかの中の人になりたい人は必須でしょう。

業務用途でRubyを使う上での課題という記事を読んで、Ruby を楽しさで図ってはいけないと思いました。この話自体は、ささださんの成果報告会のパネルネタなので、私はリアルタイムに聞いていたわけですけど、そのときは感じなかった違和感を記事から感じてしまいました。

今 Ruby が楽しい理由は、Ruby の本質とは関係ないところにあるような気がしています。

パネルディスカッションで印象的だったのは、楽天の森氏も、CTCの小島氏も“Rubyの楽しさ”を強調したことだ。小島氏は言う。「Rubyを使うようになってから、プログラマが幸せそうに働いているんですよ。このインパクトは大きい。朝から黙々とキーボードを叩いている姿は、今日も会社に行くの嫌だなと思うのとは大きな違いです」。森氏も異口同音だ。「エンジニアが楽しそうで仕事が活発になった。Rubyが広がることで日本が元気になればいい」。

今、Ruby をやって楽しい理由は三つあります。

一つ目は、Ruby 自身が楽しい言語であることです。書いて動かして試すまでのサイクルが、Java などと比較すると短いです。Python でもいいじゃんって言われそうですが、Python は Ruby のようにさまざまな書き方はできません。（いや、同程度の記述能力は持っていると思うのですが、Python の思想的にそれは合いません。）Perl や PHP は私はコードを見ただけで吐き気がします。マイナーな言語の中には、Ruby と同じ要件を備えた言語もあると思いますが、メジャーな言語では Ruby こそが楽しいプログラミング言語といえるでしょう。

二つ目は、つまらない仕事は Java プログラマ（C# プログラマでもいいが）がやってくれていることです。言い方は悪いですが、つまらないシステム開発は、言語を何を選んでもつまらないのです。

三つ目は、Ruby はまだコモディティ化していないので、Ruby をやることによって注目を集めることができることです。とかく、日陰者になりやすいプログラマが、光を浴びる良いチャンスです。また、皆が知らない新しいことをやるのは楽しいものです。

さらにもう一つ言うと、今 Ruby をやっている人は Ruby 好きの人が多いでしょうから、楽しくて当然でしょう。もし、あなたが Ruby から楽しさを得ようとしているのであれば、上記の三つを良く考える必要があります。一つ目にコミットできているなら問題ありません。二つ目、三つ目の理由が隠れているとすれば、引き際が肝心です。特にこれから参入を考えるなら、引き際を誤る可能性があります。（だからといって、つまらなくなるというだけで実質的なデメリットは何もありませんけどね。）

Ruby は楽しさだけで図ってはいけません。IT エンジニアの全てがプログラミングが好きなわけではないし、ビジネスなので楽しさ以外のメリットをちゃんと考える必要があります。

という私は Ruby 好きですけど。

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

複雑な 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 アプリを作ったら自滅しますね。そういう意味では、上記の余計に感じるという表現は非常に示唆に富んだものだと思います。