Enterprise Library 1.1 のリソース

どの程度の需要があるのかわかりませんが、enterpriselibrary.jpから日本語リソースが消えたという連絡がありましたので、掲示しておきます。現在は 5.0がリリースされたところですし、今さら1.1の日本語リソースを公開したところで使えるかどうかも確認していませんので、ご使用は自己責任でお願いいたします。 EntLib jp full 200507.zip

0

GAX のVS08SP1用のアップデータが公開されました

Guidance Automation eXtensionのVisual Studio 2008 SP1に対応したアップデートがリリースされています。このリリースのインストールは、以下のような順序で行います。 Visual Studio 2008 SP1 Visual Studio 2008 SDK 1.1 GAX 2008 February Guidance Automaintion Toolkit 2008 February Guidance Automation eXtension Update このアップデートのインストールそのものは、GATをインストールする前でも良いかもしれませんが、私は上記の順番で日本語版のVisual Studio 2008にインストールして動作を確認しました。 それから詳細を確認できていないのですが、私の環境ではDSL ToolsのDomain Specific Languageプロジェクトでテキスト・テンプレートの生成が失敗する現象が発生しました。インストールは、VS SDK 1.0をアンインストールしてから前述の順番で行ったのですが。仕方ないので、レジストリエディタでテキスト・テンプレートの検索パスを調べたら環境変数を使う形式になっていたので、フルパスに書き換えて動作するようになりました。

1

DSL Tools for Visual Studio 2008

今更という気がしないでもないですが、リリースされています。インストールしたフォルダの中の「VisualStudioIntegration\Tools\DSLTools」にVisual Studio 2005のマイグレーションガイドがあります。これによると以下のような作業を行うことでマイグレーションができます。 Visual Studio 2008で新規ソリューションを作成する(ソリューション名、言語名、拡張子、会社名、名前空間などを合わせる)。 ドメインモデル定義ファイル(DSL)を置き換える。 カスタマイズしたコードやリソースをコピーする。 エラーが無くなるまで調整する。 これ以外にVisual Studio 2008 SDKで新しく追加された機能として、Visual Studio Command Table(vsct)ファイルというものがあります。これが何かといえば、メニューなどを定義するための新しい機能です。元々は、Command Table Compiler(ctc)を使っていたのですが(現在も使えます)、これだけではなくXMLで定義できるVSCTを追加したというものです。DSL Toolsもctcからvsctへ変更になっており、メニューなどを追加している場合はvsctで定義する必要があります。基本的には、ctcで定義していた要素が、XMLのタグに置き換わったと理解していただければ良いと思います。スキーマが提供されているため、Visual StudioのIDEでインテリセンスが働きますので、迷うことはないと思います。が、マイグレーションされる場合にご注意ください。vsctに関するドキュメントは、DSL ToolsではなくVisual Studio Development Environment SDKの中になります(Visual Studio SDKの機能ですから)。

0

[Arch]実現可能性をどうみるか

何か硬いタイトルですが、何気に以下のような図を見てください。 図の良し悪しは置いといて、ようはサーバーという役割とクライアントという役割が物理的なコンピュータとして分離しているよということを表しています。このような構造になった時に、ソフトウェアを開発する立場として何を考えるでしょうか。 何を実現しようとしているのか。 どういう機能の役割分担なのか。 ネットーワークはどうなっているか(プロトコル、回線、etc)。 言語は何か? 要求を考える時に重視するべきことは、「何を狙いとしているのか」という点でしょう。そしてソフトウェアで実現すべき機能は何かということになるでしょう。 サーバーとクライアントが物理的なコンピュータとして分離されていますから、通信手段や言語も気になるかも知れません。でも物理的なネットワークの回線で繋がるということから、コンピュータ同士が通信を行う取り決めを行えばどのようなコンピュータとも通信そのものは可能なはずです。つまり、以下のようなことを決めれば通信は可能だと考えることができます。 通信プロトコルを合わせる。 メッセージの種類と役割、データの項目を合わせる。 これ以外にも考えるべきことはあるでしょうが、通信プロトコル(たとえばHTTPを使うか、TCP/IPなのか)と交換するメッセージを決めれば、通信可能であることを予測することができます。サーバーとクライアントのソフトウェアやOSを気にする必要はありません。何故なら、純粋に接続可能かどうかを見極めることが大切だからです。 次に考えることはコストと実現可能期間かもしれません。コストを考える上で、同じOSで同じプログラミング言語で作成されていることは重要かもしれません。何故なら、標準で通信手段が提供されていたりするからです。異なるOSや異なるプログラミング言語の間で通信を行う必要があるかも知れません。通信手段を簡単に実現するライブラリがそれぞれに存在すれば、コストを削減することができます。もちろん独自に通信手段を確保することもあり得ます。ようはコストや信頼性、パフォーマンスと言った指標とのトレードオフで今回の実現手段を選択すればよいのです。この選択した実現手段を関係者に対して、適切に説明できて、実現手段を提示できれば良いだけです。 ここで重要なのはプログラミング言語でもOSでもありません。通信が可能かどうかであり、それが必要十分な手段(コストや納期など)で実現できるかどうかです。 ついでに言えば、このような物理的な構成になった時の弱点も考えられることが大切です。具体的に言えば、通信方式が同期式なのか非同期なのかです。そして大量のデータを送受信する必要があるかどうかなども通信方式を決定するときの、重要な事項になります。一般的にHTTPサーバーへ大量のデータを送信するとタイムアウト時間のチューニングが必須になります。タイムアウト時間を延ばせば、サーバーで管理するセッションオブジェクトなどの破棄タイミングをどうするかなどの懸案事項も生まれてきます。この問題を根本的に解消するには、大量データの送受信では非同期処理を採用するとか、別の手段を用いるなどが必要になるわけです。 これらの懸案事項というのは、実現可能性を考えるときに必要な機能を洗い出せていれば事前に検討材料にすることが可能になります。これらの実現可能性を漏れなく考えて実現方式を検討していくのがアーキテクチャ設計ではないかと私は考えます。 ここまで考えて行く上でプログラミング言語は、それほど重要なことでは無いという事実も重要な点です。もちろん逆でプログラミング言語から構造を考えていくという手段もあるでしょう。この手段の欠点は、プログラミング言語が提供する以上の構造を作れない点です。つまり限界は、プログラミング言語が持つということです。 PS.誰でもよーく考えれば思い浮かぶ事だと思っています。でも忙しすぎて、慣れた手段で実現していくことで、新しい方法や手段を考えなくなることが怖いと私は思っています。自戒の意味で。

1