最近、Kodougu でユースケース図の実装を開始しました。いざ作り始めてみると以下の点をどうするかで悩み始めています。

・ Include/Extend をどうするか（特に拡張点の扱いは悩ましい）
・ システム境界はどうするか（UML 2.0 的には分類子であり、名前空間）
・ なんかユースケースの初期サイズが大きい(^^;

現在、Kodougu では UML は「Tiny UML 2.0」という名称で実装しています。名前のとおり、Tiny な実装を目指していて、ごてごてとした機能を嫌います。私の好みとしては、システム境界は単なる四角にして、Include は実装、Extend はいらないって感じですかねぇ・・・。

続きを読む

Rails 開発者こそモデリングすべきだよなぁって唐突に思いました。Rails は DB スキーマさえ作成すれば、そのあとはレールに乗って高速に開発ができるのですが、当たり前の話 Rails は DB スキーマの設計方法は教えてくれません。ましてや、どんなソフトウェアを作ればいいのか教えてくれるわけでもありません。

Rails は「何を作るか決めてからがすごいフレームワーク」なのです。分析工程は開発者自身が自分のやり方で実施しないといけないのです。

何を作るのかを導き出すのはモデリングが得意です。とはいえ、一般的な UML 本に載っているような開発プロセスはどうにも Rails アプリを記述するには重すぎる気がします。（少なくとも私はそう考えています。）往々にして、図解言語というものは、概要をとらえるには適していますが、詳細に書くと途端に見難くなります。実装レベルのシーケンス図などは、見るだけでも吐き気がします。

そこで、Rails 向けにシンプルな分析工程を考えてみます。

続きを読む

Seasar って日本で既に成功しているものだとばかり思っていました。

Seasarはなぜ日本から巣立たない? - 2007-10-12 - ひがやすを blog

だから、私は先に日本で成功するまでは、海外には進出しない。日本人に選ばれたものが、海外でもまた成功すれば、日本人も「舶来信仰」の呪縛が解けることでしょう。

たぶん、Seasar 自身はすでに日本で成功しているし、海外に出してもそれなりに成功する気がします。私は Spring も Seasar も深く触ったことはないですが、使っていて Seasar の方が気持ちがいいんですよね。

問題は周辺プロダクトのドキュメントなどを英語化する際に、ペースがまちまちになってしまいそうなことでしょうか。東工大の千葉先生は、最初から英語でドキュメント化しておけば日本人のだれかが勝手に日本語化してくれるから、自分で日本語も英語も準備するよりも楽的な話を未踏のミーティングでしていた気がします。それはそれで敷居が高いですけどね。。。
# そういえば、Kodougu の英語ドキュメントのバージョンが古いままだ。。。orz

そういう意味では、日本語で今のスピードを維持しながら・・・というのも一つの作戦なのかもしれません。

欲を言うと、日本人向けに海外から技術を輸入するビジネスをしている人たちが、逆に日本のものを英語に翻訳して輸出すればいいのですが。

未踏の成果報告会で見せたネタですが、Kodougu を Eclipse 上で動かしてみました。

続きを読む

現在、八角研究所にて、未踏ソフトウェア創造事業体験記の連載記事を書いています。要は、Kodougu の開発記録を書いているわけですが、肝心の Kodougu の技術的な点についてはやや濃すぎて書けないでいるので、まずはこちらのブログで書いてみることにしました。

最初は Kodougu のメタプログラミング的な面について紹介します。

続きを読む

オブジェクトの広場に 2006 年度下期未踏ソフトウェア創造事業の千葉 PM の成果報告会の模様を紹介するレポートが掲載されたようです。今のところ、本イベントを紹介した記事では一番丁寧なレポートになっているようです。

この報告会では、広場の皆様に大変お世話になり、しかも素晴らしいレポートを挙げていただいて、ただただ感謝です。ありがとうございました。

お勧めはやはり、広場の講演（「現場を助けるモデリング」）なのですが、資料だけでも十分雰囲気はつかめますが、どうせならもう一回やってストリーミングで流してほしいですね。(^^)

９月から、サイドワークとして八角研究所にて、テクニカルライターの仕事をさせてもらっています。私の記事の一覧はこちらです。前職時代にオブジェクトの広場でも記事を書いたり、本の執筆にかかわったりしたことはあったので、執筆は初めてではありませんが、仕事としてやるのは初めてです。

八角研究所の技術サイトは、まさにこれから立ち上げていこうという状態です。何もかもがこれからという状態なので、私にとっても得難い経験になりそうです。

また、2007/9/30 付けで、私の初記事が掲載されています。未踏ソフトウェア創造事業の体験記（連載全５回のうちの初回）です。未踏のあぁ～んなことやこぉ～んなことをせき☆ららに語っています。ぜひお読みください。

よろしくお願いします。m(_~_)m

Kodougu で、相関図ジェネレータで描けるような相関図を描けるようにしてみました。以下、スクリーンショットです。


続きを読む

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

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

実は、チャンジャーに見える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 行で書かれています。この種のアプリの一般的なコード量は十万行から百万行程度になりますから、ずいぶんスリムです。

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

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

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