«前の日記(2005-05-01(Sun)) 最新 次の日記(2005-05-03(Tue))» 編集
RSS feed
Webサイトとは「つい、うっかりの存在論」である

角谷HTML化計画

「むずかしく考えることはない」と、偉そうに葉巻を振りまわしながら、トレヴィラヌスはいった。「ガリラヤの太守がじつにみごとなサファイアを持っていることは、みんなが知っている。何者かがそれを盗むつもりで、間違ってここへ入ったんだ。ヤルモリンスキーが起きていたので、泥棒は殺さざるをえなかった。どうだね、これで?」
「そのとおりかもしれません。しかし、おもしろくはないですね」と、レンロットは答えた。
J.L.ボルヘス『死とコンパス』(『伝奇集』収録)

2005-05-02(Mon) [長年日記]

■1 Quick JUnit 0.0.4 のEclipse 3.0.xでの動作について

基本的には動作するのですが、3.0.x系では:

  • 「テスティングペアを開くときにエディタを分割する」をオンにすると動かなくなる
  • 複数のテスティングペアが存在する場合の切り替えが、マウスクリックでしか行えない

という既知の問題があります。ご注意を。

「テスティングペアを開くときにエディタを分割する」は、masarlさんが「こんな余計な機能入れるんじゃなかったなあと後悔してるんですけど.」と言っていたこともあってか、0.1.0では無くなる予定です……というかmasarlさんがソースをリポジトリにimportした時点で既に無くなってました。

複数テスティングペア間の切り替えの問題は、0.1.0でFIXされています。

Quick JUnit 0.1.0のリリース時期について

だいたいコードは動作確認できているのですが、ちょっと色いろありまして、リリース可能な状態になるのは連休明け以降になる予定です。

ちなみに、0.1.0というのはmasarlさんの遺したバージョン番号で、Eclipse3.0.x系に対応させる予定だったみたいです。なので、Eclipse3.1系には0.2.xとして対応していこうと思ってます。

■2 オレの考えた開発プロセス

(「参照先」が必要とのことなので、mixiの日記に書いた思い付きを使い回し。)

Magica and Modeling with Ruby。バズワード的には:

MMR。

な、なんだってー(AA略

MMRの工程

  • 工程0: Magicaセッション
    • IN: 現場の声
    • OUT: Magicaの分析結果
  • 工程1:ストーリーを書く。
    • IN: Magicaの分析結果
    • OUT:ストーリーカード
  • 工程2:ストーリーに対するテストを書く
    • IN: ストーリーカード
    • OUT: *-test.rb
  • 工程3:テストが通るように"モデリング"する
    • IN: *-test.rb
    • OUT: *.rb

あとは、工程 3 → 2 → 1 というフィードバックをもとに、次のサイクルを開始。

まとめると:

Magica <-> ストーリーカード <-> テスト <-> モデリング

MMRでプログラミングが不要に

上記からも明らかなように、"プログラミング"工程はそもそも存在しない。プログラミング不要。ひたすらモデリングあるのみ。ただし、モデリングの成果物はRubyによるソースコードである。

大事じゃないほうのUMLなどによるダイアグラムや自然言語による文書は必要に応じて作成するが、それらはあくまでも 「モデリング成果物」の理解を補足するための二次成果物である。

MMRでモデリング議論の空中戦を回避

工程からも明らかなように、MMRではテストを先に定義する。これにより「モデリング」技法についての議論の空中戦を排除する枠組を提供する。テストをチーム内の共通のゴールとすることで「You vs. me」の構図から「Problem vs. us」への転換を促進する。

MMRで「顧客にわかるモデリング」が無用に

顧客とのコミュニケーションはMagica(とその派生成果物。たとえば清書したVisioとか)で行う。忙しい現場の担当者に開発者の論理で箱と矢印の読み方を覚えさせるような押し付けは無用。

MMRとUML

MMRによるモデリング成果物はテキストファイルによるソースコードなので、大事なほうのUMLと親和性が極めて高い。MMRによるモデリング成果物を大事じゃないほうのUMLで可視化することについては、今後、捺印ナビリティ的に重要になっていくだろう(現状は未解決な課題)。

MMRとMDA、あるいはbuzz word haiku

MMRによる成果物である「モデル」は、PIM(Platform Independent Model)である。しかし、PSM(Platform Specific Model)への「変換」は必要ない。というのも、PSMはもちろんDI x AOPであり、これはPSMというよりもむしろPSR(Platform Specific Runtime environment)とでも呼ぶべきものだからだ。そして、PIMたるMMRの「モデル」は言うまでもなくPORO(Plain Old Ruby Object)である。

つまり、MMRの成果物はPOROなPIMでランタイムにPSM(PSE)がinjectするMDAなのだ。これは「ソフトウェアの進展とはすなわち抽象化の進展である」というソフトウェア史的唯物論のテーゼとも合致する。

いまいちど繰り返そう。諸君、ここが約束の地だ

補足(1)

以前に、似たような妄想で「programmer testを『テスト』と呼ぶと、各方面から要らぬ誤解を受けて面倒くさいからこれからはもう『スペック』って呼ぼうよ」とmixiでボヤいたら、kdさんから「本流が道を譲ってどうする」と叱られた記憶がある——のだけれど、mixi日記は過去に書いたものを手繰る術が面倒で見つけられず(脳内やりとりだったかも?)。

これはMMRについても同様。「プログラミング」に正当な評価を与えるべく活動すべきだ。でもなー、手強いんだもん。

補足(2)

上記はMagicaの提供元であるスターロジックさんとは一切関係ありません。すべて私の妄想ですので、くれぐれも誤解なきよう。

本日のツッコミ(全4件) [ツッコミを入れる]
guion (2005-05-10(Tue) 13:59)

guionなTiki:MagiCa にも書きました(リンクもしてます)が、<br>MagiCaって、<br>javaのinterfaceとか、<br>檜山正幸氏のJanusとか、<br>MAX や PureDataとか、<br>ObjectRoleModelingとか、を思い出しました。<br>やっぱり人間って、「繋がり」を見極めたい生き物なんですよね。<br><br>あとMMRを見て、 Rubyで仕様記述という繋がり(ちと強引か)から、<br>Ruby-OCLというネタ(^^;を思い出しました。

かくたに (2005-05-10(Tue) 14:07)

Ruby-OCLはその後、Moduleベースの動くモノができあがってるみたいです(w ActiveRecordの関連記述みたいな感じで制約を書きます。

guion (2005-05-10(Tue) 19:46)

な、なんだってー>Moduleベースの動くモノ<br>(こんどはAprilFoolじゃないのですよね?)<br>120%ネタかと思っていました。<br>(その割にはJUDE MLで妙なことを書きましたが…)

ゆー (2006-02-24(Fri) 19:41)

100スミスやり方おしえてください


«前の日記(2005-05-01(Sun)) 最新 次の日記(2005-05-03(Tue))» 編集
RSS feed