Ishisaka のすべての投稿

I’m Tadahiro Ishisaka. I’m a C# Developer. Working on ABB Bailey Japan Ltd. Mostly interested in OOP, Design Patterns, Functional languages, Ruby, Lean and Agile development. I’m a developer of PIMS. I won Microsoft MVP in the past. (C#, 2006, 2007, 2008)

MSDN TV リソースマネージャを利用した国際化対応アプリケーションの作り方

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

Cωのdemo

Chnannel9で、MSR UK Gavin Bierman氏によるCωのデモがあがってます。Bierman氏はDatabase Queryの研究をなさっている方のようで、デモの内容もデータベースアクセス、XML関連が主になっています。
当然字幕もScriptも無く英語のままですが、がんばってみて見ましょう。
チョー要約すると、今のままだと、データベースアクセスって面倒くさいよね。Comegaだとこんなに簡単だよって内容です。(要約過ぎ)
とくにTechEd Inetaセッションで、Cωを見逃した方は、デモ中のコードを見てビビッてください。
Channel9 – Gavin Bierman – Microsoft Research in UK works on database query language

dotNetマガジンのDVD

今月のdotnetマガジンの付録だったVS2005 Beta1のDVDですが、インストールに失敗するという不具合があるのですが、今日帰宅してみると翔泳社から修正版のディスクが付いてきました。
ディスクのプレスし直し・送付のコストを考えること、この出版不況の折大変だったと想像できます。お疲れ様でしたって言うか、ありがとうございました。
いまはMSDNに入れてるおかげで、このようなベータ版を入手できることが当たり前みたいになってしまいましたが、入れなかったときのことを思い出すと、雑誌付録や、TechEdで入手できるベータ版は大変ありがたい物でした。
改めて翔泳社さんに多謝です。
つーかこんな状況であれだけコンスタントに翻訳本他を出していただけるだけでもありがたいです。

Tech Ed 2004 Yokohama 4日目 まとめ

マイクロソフトが提唱する今後のソフトウェア開発手法について

4日目分と言うことで萩原氏のセッションT1-411 次世代開発手法Software Factoryを中心に私が受講したアーキテクチャトラックのセッション内容他をまとめます。
要点は以下の通り
開発手法としてはSoftware Factoryを用いる。
各設計レベルにおいて、システムのコンテキストにあわせてパターンの組み合わせを行いシステムを作り上げる。
モデル記述にはDSL(Domain Specific Language)を用いる。UMLだけでは全てのドメインのモデル記述を行うことは不可能なので、これは用いない。
Software Factoryにおいては、プロダクトラインアーキテクチャによる開発プロセスをとる。
Software Factoryにおいては、ドメインの内容にあわせプロダクトラインを選択し、それをカスタマイズすることで個別アプリケーションの開発を行う。
プロダクトラインとはあるドメインの集まりに適応できるように開発されたソフトウェア部品、雛形のこと。ただし、従来のコンポーネント、クラスと言った物より遙かに大きな粒度を持ち、システム全体の雛形を提供する。プロダクトラインは従来のフレームワークよりもより高いレベルでアプリケーションの姿形を強制する。(トラックのプロダクトラインで高級セダンを作ることは許さない)
このプロダクトラインはアセットと呼ばれる部品(コンポーネント)により構成される。アセットは実行可能なバイナリだけでなく、それの関連するあらゆるドキュメント、リソース、メタデータを含む物である。
アセットは予めあるグループから汎化されたドメインを対象として、分析設計されたプロダクトライン中のコンポーネント(モジュール)であり、機能単位で用意される。
Software Factoryにおいては、サブプロセスとして開発プロセスとしてはマイクロプロセスを用いる。
またこうしてできた一連のモデル成果物のメタデータはアプリケーションの展開、管理、保守でも使用できるように管理されるべき。逆にメタデータとしてはそれらに必要な内容が含まれていなければならない。
また、MSFもこれに合う形になっている。
以上でもわかるように、基本的にマイクロソフトは、まず、全体行程レベルでのアジャイル開発技法の適応については懐疑的であることを臭わせます。(と言うよりも否定に近いかもしれない。)元々Software FactoryはCMMで有名なCMU(カーネギーメロン大)で開発された物のようなので、これは何となく頷けます。
また、OMGのMDAについては全くと言って良いほど評価をしていないようです。現実的でないという判断だと思います。
個人的にはUMLの否定は痛いというか、大丈夫なのかという気もしますが、マイクロソフトとしては、他に使いやすいダイアグラムがあれば(Whitehorse)そちらの方がよいだろうという考え方のようです。確かにUMLだけではSOAの開発はきついかもしれない。
ただこの辺はマクロソフトから話が出始めてきた段階なので、いろいろなコミュニティや、企業間の交渉の中で変化を見せるかもしれないし、MDAが本当に良くて、必要ならばIBM(ラショナル)のツールを買えばすむ話なのかもしれないわけだし。
したがって、今後VS2005 Team Systemやそれ以降においてMSから提供されるツールはこのような考え方に基づいて提供されることになります。ただし、開発のサイクル全てにおいて必要なツールが全て提供されるかというと、そういう訳ではなくたとえば要求管理ツールのような物はとりあえずは提供されないので、マイクロソフトから提供されない物については新たに3rdパーティの物を購入するか、作るかする必要がありそうです。また、このMSから提供されるツールはそのときのMSFにおいて適用するようなツールになるでしょうから、何らかの形でMSFの学習をしていく必要がありそうです。
MSF(Microsoft Solution Framework)
http://www.microsoft.com/japan/msdn/vstudio/productinfo/enterprise/msf/
VS2005 Team Service
http://www.microsoft.com/japan/msdn/vstudio/productinfo/enterprise/
Software Product Lines
http://www.sei.cmu.edu/productlines/index.html
DSLに関するWiki Pedia
http://en.wikipedia.org/wiki/Domain-specific_language

TechEd 2004 Yokoham 3日目

うーんかなり疲れてきました。
とりあえず今日も要点まとめ。

T1-401 エンタープライズアプリケーションにおけるパターン

パターンベース設計の利点
  • 設計課題における意思決定スピードの向上
  • ソフトウェア再利用性の向上
    • パターンの組み合わせによる知識の再利用が可能
エンタープライズパターン

アプリケーションとアプリケーションを接続するためのパターン。
分類としては以下のパターン。

  1. 統合レイヤ
  2. システム接続
  3. 統合トポロジ
統合レイヤ

アプリケーションの統合のためのレイヤを用意し、アプリケーションを統合する。統合方法としてはデータレベルで統合を行うエンティティ統合、ユーザーへのデータ提供レベルで統合するポータル統合、既存のアプリケーションとは別にプロセス管理コンポーネントを構築するプロセス統合とがある。

システム接続

論理データ層でアプリケーション統合を行うデータ統合。UIからユーザー入力をシミュレート、スクリーンからデータ取得することで、別のアプリケーションにアクセスさせて統合させるプレゼンテーション統合、各アプリケーションが持つAPIなどを利用しながら、ビジネスロジック層でアプリケーション統合を行う機能統合がある。
また、機能統合についてはWebサービスロジックで機能統合を行うサービス指向統合があり、これも統合する対象物より大きなコンテキストを考慮し、凝集する全体として、場所、構造、チャネルを構成することで、アプリは大きな統合アーキテクチャの一部として計算リソースとなる。そしてこのコンテキストが統合トポロジであり、以下のような種類がある。

  • メッセージブローカ
  • アプリケーション間の通信を処理するブローカと呼ばれるコンポーネントを用意し、ブローカを通してアプリケーション間のメッセージ送受を行う

  • メッセージバス
  • すべてのアプリケーションをつなぐ論理的なコンポーネント(バス)を用意し、アプリケーション冠のメッセージを行う。このときアプリケーションは共通のメッセージ隙間、コマンドメッセージを使用し、アプリケーションはバスへのメッセージ送信を行う。

  • パブリッシャー サブスクライバ
  • データ送信側をサブスクライバと呼び、とりあえずこれは決められたデータを用意し、一種のキューに投げ、サブスクラバと呼ぶデータ使用側は自分が必要なデータを使用する。

ということで、とりあえずここまで。

Tech Ed 2004 Yokohama 2日目

UMLなんてステステ。

T1-415 サービス指向アーキテクチャを実現するソフトウェア開発ライフサイクル

現状あるソフトウェア開発の問題を解決するためのソフトウェアファクトリ。
モデル駆動による開発。
各ドメインに適したモデリング言語(DSL: Domain Specific Language)を使用した開発。(UMLではない。)ツールとパターンを使用したモデル化モデルへの転換。
メタデータの共有
プロダクトライン構築と、プロダクト構築の二つのプロセス。部品作成と、製品の作成。サービス指向に基づいたプロダクトラインの構築。
マイクロプロセスという特定領域ごとの小さなプロセスの連鎖によるプロセス。
これらを実現するためのマイクロソフトとしての方策→DSI:Dynamic System Initiative


具体的にどうすればいいのかというところは金曜日の萩原氏のセッションということらしいです。
ということで、マイクロソフトはOMGのMDAには乗りません。MDAではサービス指向のアプリケーション設計・製作はできないと考えているようです。したがって、マイクロソフトが提供するツールではUML 2.0も使用されず、現在Whitehorseとして知られるオリジナルのダイアグラム(というかDSL)が使用されることになるようです。
つまり今後われわれ開発者は上流工程においても、マイクロソフトに乗るか、そるかの選択を迫られることになるようです。(まぁモデリングツールと開発プロセスは一体物だというのは今も変わりませんが。)ただ本来具体的な実装技術に対してニュートラルであったはずの技術・知識の汎用性が低下し特定の技術に結びつきすぎるのではないかと思ったりもします。

T5-347 Win32/MFCアプリケーションにおける.NET Frameworkの利用

ビバマネージドC++って思ったほうがよいですよ。VC++のプログラマの皆さんは。こんなの使わねーよとか思わずに。
マネージドC++の技術を使うことによってMFCアプリケーションよりそれほど苦労せずにマネージドコードを使うことができます。
そうそう、VS2005ではやっとマイクロソフトからSTLが正式サポートされるようです。