| 著作一覧 |
おもしろかった。ASMX,Remoting,MSMQ,COM+(EnterpriseService),WSE全部ひっくるめて面倒みるとか。HTTPでP2Pとか（HTTPサーバーでもある――HTTPとは限定する必要はないのだろうけど）。
構成ファイルで拡張可能→abstract factory。
とりあえず、マイグレーションパスで一番素直な道がASMXというのは予想通りとか。
ここに来て、WXSの悪評が出ているのはもしかしてIndigoのリリースを前にして何か政治的なものがあるのかな、と考えてみたり。
今日（正確には昨日）は、Indigoと、全然まだまだっぽいけどDSLツールのVS.NET組み込みと、具体性を帯びた話が続いて、ここ数年のTechEDの中で一番おもしろかったのであった。
関心事は異なる、それをまとめるのがアナーキストの役割です。いや、破壊するのか。
与太はともかく、見ての通り、同じシステムが3つのドメインに分かれている。上流の工場がPCBを流すと魚は死滅し、水銀を流すと骨が痛い。要求をかなえるというのはなんとなくそういうような気がするのだが。割りを食うのは下流に棲む魚や海で生活する人だ。海は死にますか、形あるものすべて壊れる。そういう状況で、テクノロジストたるエンジニアは右手に技術、左手に工学を持って上から下まで駆けずり回って何をなすべきだろうか？
ということがSoftware Factoriesの根底にあるようだ。
で、重要な言葉の使い分けの点は以下だ。
Factoryの中ででスパナを持ってモダンタイムスをやるということではなく、Factoryを再利用するということ。
作ったベルトコンベア、安全基準、ルール、部品、工場をいちいちスクラッチアンドビルドしてるのが現在のソフトウェア開発に見える。それはあほだろう。10年の実験の結果、工業製品化はとりあえず無理そうだし、規格化した部品群で全部まかなうってのも無理っぽい。でも、ベルトコンベアの使い方のルール、安全基準、入れ物、点呼の習慣、こういうものは再利用しているね。ではそれをどのようにカタにはめることができるか、それは工学で引き受ける、工場の運用は技術で試せ、そんなところか。
ソフトウェア開発にフォードやテイラーの時代がやって来たようだ。
(ここは実際の工場がどれだけのルールや要素や役割や資材や概念や歴史を持つかを想像して、それぞれの組み合わせによって何を造るのに向いているのか、向いていないのか、あるインフラを導入することでどう変わるのか変わらないのか、Aを作るラインをBに当てはめて死にましたとか事故が起きましたとか、今までバケツで運んでうまくやっていましたが何か？ とかいろいろ、というようなことを実際に工場を建築することなく洗練させて行くことができるソフトウェア開発のありがたみを噛み締めるポイントのような気がする)
#理解した範囲では同意。
あとは、ソフトウェアの寿命問題。で、3年後にVB.NETが死にます、5年後にC#5.0になって全然変わりますというか、この機能を使わないとだめですとなったときに、ソースコードは大して訳にはたたない。実装の細かな仕様書は役に立つかも知れないけど立たないかも知れない。しかも作るのはソース書くより100倍くらい手間がかかる。とは言っても今までは代替手段が無かったからそういった仕様書を書いていたのだが、やめましょう。システム（テクノロジー）の寿命が尽きたら（例：2000年、2007年とか）またまた人間が読解して一生けんめい別の言語で作るのか？ そこでDSLですよ。ジェネレータを作れる専門家が数人いれば、あとはいらんじゃん。実装についての記述ではなく（ここは好みの言い方で良い気がする）を記述して残しておく。後は必要／時代／要請に応じてジェネレータを手直ししていこうよ、ということのようだ。ただし、現時点では（少なくてもVS.NET2005では）無理ぽ。とは言え、さわっておくと良いことありそうかも、というところ（なんか、ATL1.0あたりのことを思い出したけど、そんな感じかな。ただやたらと志は遥かに上のようだが）。
単純化すると、デザインパターンは汎用的な設計の再利用（コードを書くのは人間）、DSL（MSがSoftwareFactoriesで語る意味での）は特化した設計の再利用（コードは自動生成）――無理なところは無理せずに人間がコードを書く。それでも（それこそ）80%の業務プログラムは生成できるんじゃないか？
そうなると、フレームワークというものは役割を終えることになる（人間の生産性を上げるためという意味では。単なる自動生成プログラムのターゲットプラットフォームとしてのAPIセットということになるんじゃないかな）、デザインパターンは生成するソースのテンプレートに組み込まれることで、これまたインスタンス化を人間が場当たりで考える対象ではない。とは言え20%（このパーセンテージは今、これ書きながら例の2:8に合わせて書いてるだけで、そんな数値は元ネタには出てこない）についてはありありだが。
このようにして導かれる世界について、僕はどう思うだろう？ 百万遍唱えてもnew String("this is a string, hahaha");とか書いている連中はもうプログラム書くなよと言い切れるし、どう考えてもそれはハッピーな気がする。DSLを作るのは相当に骨が折れそうだが、それを元にジェネレータを作るのはもっと大変そうだ。が、これはすげぇおもしろそうだ。残り20%はどちらにしてもプロの仕事なわけで、これは無くなんないだろう。という感じで間違えて仕事に就いた人がいなくなって産業として適切な規模になるんじゃないの？ という感想。
#というか、最初は組み込みの世界がターゲットなんじゃないか、という気もする。数値化されたモデルが最初からありそうだし。
ジェズイットを見習え |
そういうのって、再利用されてないのですか!?ちょっと意外です。IT業界ではそうなのかなあ。
僕の書いてるのは厳密じゃないから間違ってるかも。<br>でも数100人規模でそのプロジェクト限定で集めた人が大半以上というような場合に、暗黙のチームでの了解しかないと辛いというか無理だってのはこないだ理解したけど。いちいちゼロベースで施設案内からファシリティの説明からしてやらないとだめなんだな、これが。
違うな。正確には、「体系だって再利用していない」ということか。開発プロセスの再利用、ライブラリの再利用、オレ様コーディングスタイルの再利用、DBアクセス方法の再利用というのが、全部まとまって、成果物管理などと一体化できているかということかな。<br>というか、死ぬほど耳が痛い。
ありがとうございます。いろいろな違いがわかってきました。どこかでまとめてみよう。
なんとなくMDAのかほりもしますね。
MDAと確かに違うと思う点は、スコープを非常に狭くしている点のようです。1featureにつき1モデルというように見える（メタモデルは1ドメインと言っているけど限りなく1大きなユースケースなんじゃないかな）。したがって、DSLをMSのようなベンダーや標準化団体が規定するのは無理としてそれは放棄していて（正確にはDSLのDSLは決めようとしているみたい）、お絵かきツール構築キットとソースコード生成エンジンのDSLについてに絞っているみたい（これが僕にとって相当、現実的なアプローチに見えるのは、実際、今すぐにでもお絵かきツール構築キットを僕自身が欲しいからなんだけど）<br>MDAというかUML2.0に対しては本の広告で明白に「反」と言い切ってますね。でか過ぎだと（ああ、その片方にはWS-*とWXSがあるわけだけど）。
上の嘘。1ユースケースが複数ドメイン（ここでのドメインはレイヤーのさらに中を分割しているなんだろう、関心領域ってことになるのかな。データベース屋さんのドメインとは違う）に分割できるはず（実際には重なり合う部分がある）なので、メタモデルの対象はやはり1つのドメインのはず。
…YACC 覚えよう…
だめだめ。お絵かきツールがすごーく重要。<br>（っていうか、その部分さえあれば、後はRuby使って幾らでも生成できるよ）
あ、そうか。Swingとかでやろうとするから難しい/面倒くさいんだからeToysを使ったらどうだ？<br>#っていうかC++Builderでも良かったような気が。FreePeekのフィルタリング設定言語がそんな感じだよね。
いやいや、きっと「MDSL のフリーな実装を！」とか「ここがダメだよ MDSL」とか言い出す人達が出て、その時に Mono や Seasar みたいなプロジェクト立ち上げ用ですよ〜。
フレームワークの役割はドメイン特化の抽象化のために存続するのではないかと。<br>行間を読みきれてないのですが、これまでフレームワークと言われていた部分が、DSLからのソース生成でできてしまうという話なんでしょうかね。
>フレームワークの役割はドメイン特化の抽象化のために存続するのではないかと<br>そうです。それはきれいな言い方ですね。（フレームワークまで生成したら本当に仕事が無くなっちゃうよ（それはイヤ））。<br>>立ち上げ用<br>おおなるほど。というか中間言語はXML、パーシングでいいんじゃないかな。
はじめまして。とおりがかりです。<br>Tech-Ed行くまでは、適当なUMLエディタもってきてばらしてDOMで触れればいいと思ってましたが、ツールボックスやプロパティシートも必須でしかもつなげる線とかは結構決め打ちで行く方がいい気がしてきています。<br>スキーマ切って後はテンプレート書けばおしまい、位のお手軽さが必要なのかなぁ、と。<br>テンプレートはerbとかで良いとしても、IDE回りを全部そろえるのはちょっと骨ですね…<br>趣味で作れるかなぁ。
はじめまして。もしかして妥協的にとおりがかり？<br>目指しているのはそのレベルのお手軽さかも知れませんが、話を聞く限りでは、モデルの制約をどう言語仕様（機能が正しいかな）にマッピングするかとかまじめに取り組む場合には考えなければならない点は多そうです。<br>趣味で作ってどういう需要があるかですね（なんか既にありそうだけどhttpd.confとかmail.cf―だっけな？―とかiptablesとかをペロペロ作れて配布できたりすると嬉しい人もいるかな。というように幾つかの構成ファイル用DSLを組にしてばら撒いてからという方法かな。趣味領域だと定型的なプログラムというのはあまり無さそうな気がするし）。自社ツールとしての半分趣味のようなもの、というのも有り得るかも。
どこでその話題を(^^;＞妥協的<br>まあ狭い業界って事ですかね。<br><br>趣味でもIEとかWordとかOutlookのように巨大なアプリを操る状況とか、WSHでやるようなシェル系の作業では、DSLがあると便利かなぁ、と思ってます。<br>趣味でWordやOutlookを使うか？と言われてしまうと何も言えませんが。<br><br>IEのCOMをモデルにするだけなら自分でWSHで書く方が早い、となってしまうので、どういうドメインで切るかはかなりセンスの問われる所だとは思ってます。<br>そういう遊びはやりたいなぁ。
なるほど。>シェル系の作業<br>レスポンスが良ければ、エクスプローラと連動させてあるディレクトリより下全部、あるいはそのディレクトリ、あるいは選択したディレクトリについて……の部分（find XXXX -exec YYYYのXXXXの部分）をちょちょっと作ってYYYYの部分で別のウィンドウがひょっと開いてツールボックスからドラッグアンドドロップでひょこひょこ作れると嬉しそうだな、とかいろいろ想像できますね。（で、テンプレートの保存もできるとか。大体、XXXにしろYYYにしろほとんど決まっていることが多いし）<br>Visual Shell Script Creatorという感じかな。