Visual Studio 2005: Domain Specific Language (DSL) Tools

This download contains a graphical designer hosted in Visual Studio 2005 for designing and editing the concepts (or metamodel) of visual domain specific languages.

ということで、OOPSLAで発表されたDSL Toolがダウンロードできるようになりました。
インストール手順は以下のとおり。
このDSL SDKのインストール前にVSIP 2005 SDKのインストールが必要になるので、以下からダウンロードしてインストールする。
VSIP SDK 2005 Beta 1
次にダウンロードしたDSL CTPをインストールする。
次にDSL CTPのReadmeに書かれているように、VSへのパスの通ったコマンドプロンプトを開き、
devenv /resetuserdata
とコマンド打つ。
このCTPにより追加されたダイアグラムについては以下を参照。
Walkthrough of the Microsoft Tools for Domain Specific Languages
DSL TOOLの使い方もここに書かれています。
一応日本語ベータ1にもインストールできました。

スクリーンショット

はてなダイアリー – aspxの日記から

VSTSは開発メンバー一人一人に必要だとして、
VSTFはサーバシステムに近い立場だと思うので、
CALかなにかが提供されるのであろうか。

たぶんWindows ServerのCALとSQL ServerのCALは別途必要で、VSTF自体のラインセンスはVSTSに含まれるのではないでしょうか。
でもSBSみたいな形でパッケージ化されたCALもほしいですよね。
マネージャとかPMな人には必ずしもVSは必要ないですし。
しかしこう考えるとコスト的にしきいが高い。

コレオグラフィ（IBM)＝オーケストレーション（MS)
いやなに、時々わかんなくなっちゃうので。あーと現在のところ実現方法も違うようで。そのうち一連のWS-xで落ち着くのかな。

名無しさん#さんのblogで紹介されていますが、今バンクーバで行われているOOPSLAにて、マイクロソフトからソフトウェアファクトリと、VS2005 TSに関するプレスリリースが出されました。
Microsoft Grows Partner Ecosystem Around Visual Studio 2005 Team System
http://www.microsoft.com/presspass/press/2004/oct04/10-26oopslaecosystempr.asp
このプレスリリースについては前半でVS2005 TSのCTPが発表され、パートナーとしてBorland等も加わったこと、後半では、MSのソフトウェアファクトリへの取り込みと、その見通しについて発表されています。
また、ソフトウェアファクトリについては以下のサイトを参照してください。
Microsoft : Architects JOURNAL : The Case for Software Factories
http://msdn.microsoft.com/architecture/journal/default.aspx?pull=/library/en-us/dnmaj/html/aj3softfac.asp
Software Factories :
http://softwarefactories.com/index.html

続きを読む ソフトウェアファクトリ →

ExcelはWebアプリケーションのデータストアとして使っちゃイカン。というか大丈夫なの？
後イントラ環境でExcel使いたいなら、別にIEの中にOLEで呼び出せばいいでしょ。Webというか、HTMLなんてかぶせる必要ないじゃん。
なんか最近ASPからExcelにさわりたいって感じの投稿が散見されますけど、まずそこら辺のやり方って言うか、ソフトウェアシステムの構造は見直した方が良いです。
あーつづきのExcel VBAの火消し作業を続けよう。

マイクロソフトのWebにMSF:Microsoft Solution Frameworkのページが出来ました。
Microsoft Solution Frameworkはマイクロソフトが提供するソフトウエア開発プロセスモデルです。マクロソフトはこれを方法論とは呼ばずに、他の方法論より柔軟で広範であるとしてフレームワークと呼んでいます。
また、VisualStudio 2005 Team Serviceとして提供される各製品はこのMSFを前提として作られていると考えられますので、Team Serviceの導入を考えられてる方は、これから翻訳されて行くであろうホワイトペーパに目を通されておくと良いでしょう。
基本的にモデリングツールや、開発支援パッケージという者は、開発プロセスと密接に結びつく者なので、TeamServiceを有効活用していくためにはMSFの導入や理解が不可欠であると思います。

とりあえずメモ。
リップマン先生のC++/CLIへの移行ガイド。
プライマーC++/CLI書いて～。
Translation Guide: Moving Your Programs from Managed Extensions for C++ to C++/CLI
http://msdn.microsoft.com/visualc/default.aspx?pull=/library/en-us/dnvs05/html/transguide.asp

続きを読む C++/CLIへの移行 →

Cωはデータアクセスレイヤーなるものを駆逐してしまうので、要求にのみ注力してコードを書くことができます。その点で既存のオブジェクト指向言語に比べて、非常に軽くソフトウェア開発を行うことができるようになると思います。ただしその前提として、データベース内のオブジェクトは固定、使用するXMLファイルのスキーマも固定という条件がつきます。つまり、かなり確度の高いレベルまでデータモデリングを行った上でないと、ドメインロジックの構築は行えません。その点は注意が必要で、OOA→OOPという流れはとらないほうが無難です。(というか無理)
まぁそもそもCωがオブジェクト指向言語かって言うと、一味も二味も違うと思います。
それに真剣に業務に使っちゃたぶんだめです。
Ruby並とは言わないまでも、かなりLWな言語であるのは間違いないので、○スキーで256倍本でも出せば、爆発的に普及・・しないなやっぱ。

小野さんのC＃ではじめるプログラミング入門第5回にて、Parse()メソッドによるstringからintへの型変換の方法が説明されていますが、.Net Frameworkでは型変換のこれ以外の方法として、Convertクラスの変換用メソッドも用意されています。また、キャストによる型変換も用意されています。(ただしstring型から数値型、またその逆は行えません。)
[Exp. 一部小野さんのコードを借用]
string s1 = “10”;
int i1, i2;
i1 = System.Int32.Parse(s1);
System.Console.WriteLine(i1);
i2 = System.Convert.ToInt32(s1);
//これは許されない
//i2 = (int)s1;
System.Console.WriteLine(i2);
ここで疑問なのは、Paｒseメソッドを使う場合と,System．Convert．ToInt32メソッドを使う場合とではどちらがコストが低いのか、もしくは同じなのかという疑問です。
ただ、引数や、実際の動作を考えると元は同じかなともいますが。

MSDN TV　Using Managed Resources
.NET Frameworkでの国際化対応アプリケーションの作成方法を解説したビデオ。
特にリソースマネージャを使ったりソースに切り替え方法、VSでの.NET FWのリソースファイル作成方法について解説しています。
字幕、Scriptなし。