T6-501多言語パラダイムによる実装手法に関するフォローアップ

TechEdの「T6-501 多言語パラダイムによる実装手法」に関して、フォローアップとしてお話した内容を記載します。説明した内容は、論点が3つあります。 プログラミング言語と計算モデル 複数の言語を組合わせた具体例 分析・設計のおける考慮点(マルチパラダイムを抽出するために) 最初の「プログラミング言語と計算モデル」では、コンピューターで動作させるモデルとしてチューリングマシンやラムダ計算モデル、並列に特化したDAGやCSPなどのモデルが存在しており、近年のプログラミング言語はマルチパラダイム化しているが、中心となる計算モデルというものが間違いなく存在するということです。従って、汎用言語(GPL)が他の計算モデルへ対応するためにマルチパラダイム化したとしても、現時点では最適化などを考えると最適解には決して成り得ないという話をしました。この理由として、複数の言語が活発に使われているし、新しい言語も開発されていることを取り上げました。現実的に複数の言語を組合わせる時の問題点として、「人材が居ない」とか「新しいことを覚えたくない」とかを良く耳にします。ですが、この論点においては生産性などとのトレードオフで判断すべきだという説明をしました。その理由として、不可能ではないけど頑張れば出来るから頑張って1000行のコードを書いたとして、別の言語を使うと500行で済むことが良くあるからという話をしました。これは、別の言語を知っているかどうかであり、異なるパラダイムでは異なる問題解決アプローチがあるからです。だから、様々な言語を知ることは自分にとって有益になります。 次に具体例として、動的言語と関数型言語を取り上げました。動的言語では、オブジェクトの結合度を弱めるためにObjectコンテナーが、スクリプトでオブジェクトを生成する3種類の戦略をお見せしました。これ以外にも、検証ルールや構成パターンなどをデモでお見せしました。これらの理由は、オブジェクト同士の結合度を弱めることで、変更が起きる可能性をスクリプトなどへ隠ぺいすることで、保守容易性や変更容易性を向上することができます。 続いて、非同期パターンを組合わせた場合にプログラムが複雑化していくという説明をしました。この問題を解決するために、F#の非同期ワークフローが有益であり、同時実行などを考えた場合はアクターモデル(メッセージ エージェント)を使うと簡単になるというデモをお見せしました。さらに、デモの中ではWPFで作成したUIへイベントを通知するモデルを用意することで、非同期+リアクティブ プログラミングという組み合わせの重要性を説明しました。.NET Frameworkの非同期処理で、Begin系メソッドで呼ばれるコールバックメソッドは、Beginメソッドを呼び出したスレッドとは異なるスレッドで呼ばれます。このためコールバックメソッド内で、イベントを発生させるとコールバックメソッドが動作しているスレッドになってしまいます。このままだと、UIスレッドとは異なるためWPFではDispactherを使わなければならなくなり、この形式は良くありません。何故なら、イベントの利用者がDispactherを意識する必要があるからです。この問題を解決するには、同期コンテキストを使ってイベントを呼び出し側スレッドに同期させるのが良いリアクティブ プログラミングとなります。 最後に説明した分析・設計における考え方では、以下のような考え方をベースに説明をしました。 メンタルモデル(James.O.Coplien) Domain Driven Design (Erick Evans) DCI(Data Context Interaction) この中でご説明したこととして、現在のOOA&Dではプログラミング言語が持つ制約としてのクラスを抽出することに重きを置いており、ユーザーの目的を支援する本来のオブジェクトになっていないということです。このギャップを埋めるために、Agileの様々な手法が使われています。その例として、XPにおけるユーザーの参加と早期のフィードバックを踏まえた動くソフトウェアを素早くリリースするというプラクティスを取り上げました。この考え方からCoplienのDCIアーキテクチャに繋がっており、彼の考え方によればクラスのしての設計時点の振る舞い(Methodfull Role)と、オブジェクトが動作する場(コンテキスト)において異なる振る舞い(Methodless Role)が出てくるということです。従ってDCIでは、ユーザーのゴールを「ドメインオブジェクトに対する操作」ではなく「目的を達成するためのタスクフロー」に置いています。 一方、DDDの世界においてはEric Evansなどのその後の研究や実践した結果から、書籍としてのDDDに定義されていないことなどを学習していき、DDDを再定義しようとする動きに繋がっています。これらの動きが、DDD eXChange 2010の資料などから読み取ることができます。DDDの再定義から提唱されているのが、以下のような考え方です。 Event Sourcing Process Integration Event Sourcingでは、CQRS(Command Query Responsibility Segregation-コマンドとクエリーの分離)という考え方でオブジェクトの振る舞いを分離していきます(この考え方が、T1-502の萩原さんのセッションでも説明がありました)。また、DDDのビルディングブロックとして、Entities、Value Objects、Services、Domain Events(非同期イベント)、Aggregates、Modulesなどが定義されると再定義しています。これは、EvansなどのDDDの考え方をクラウドを含めたシステムに対応できるように考え方を洗練させていったことにより出てきたものと考えられます。このビルディングブロックやCQRSを組み合わせると、ドメインモデルにはコマンド系のメソッドしか残らなくなります。こうなると、今までのドメインモデルとは異なったものに変化していきます。EvansのDDDの世界で重要なポイントと私が考えているのが、Bound ContextとContext Mapになります。モデル(オブジェクトと言い換えても良い)が意味を成す領域がBound Conetxtであり、これに関連するContextとの対応関係がContext Mapとなります。よって、このことはContextによってモデルの振る舞いが決定されることを意味します。このようなEvansなどの考えに気が付いた時に私が思い出したのが、Martin Fowlerの「Development of Further Patterns of Enterprise Application Architechure」になります。つまり何が言いたいかといえば、ドメインモデルを現在のシステム形態(Key-Valluesストレージなどのクラウド技術を含んだもの)へ対応させるにはどうしたら良いかという動きが、今まさに始まっているということです。 Evansのこのような考え方は実装により近いのではないかということを私は考えており、Coplienはもっと上流(別の言い方ではユーザーより)から考えているように私は感じています。これはどのような視点でシステムを見ているかによるものです。そして、もっと重要だと私が考えるのは、システムにおける共通性と可変性を識別し(ドメイン工学のFODAなど)、可変性をどのように実現していくかということです。それが、DCIアーキテクチャや再定義されつつあるDDDの前提になっていると私には思えます。 分析・設計論として、簡単な結論があるわけではありません。考えるべき事柄が多岐に渡っており、それらの要素に気が付くというのが本セッションの大きなテーマでもありました。このような雰囲気が参加者に伝えようと意図したのが、今回の私の発表になります。 PS.これらの考え方は、今回のセッション資料を作成するに当たって萩原さんと何度もディスカッションをして得られた気づきによるものです。これらのディスカッションは、TechEdの期間中も何度も行っており、その中でお話する内容が決まっていきました。これらの理由から、公開している資料には本エントリーで記載さしたようなキーワードが含まれいないのです。

0

TechEdの準備に追われています

いよいよ来週は、TechEd Japan 2010の開催です。私が担当するのは「T6-501 多言語パラダイムによる実装手法-動的言語、関数型言語を含めたプログラミング言語の有効活用へ-」というセッションになります。参加者向けにPPTが公開されていますので、おおまかなアウトラインを確認することができると思います。実は、まだ設計論に関しては色々と検討をしている最中です。この資料の作成に関しては、何度も萩原さんとディスカッションしたり、色々な資料(論文や書籍だったり)を読み漁ったりしています。中でも参考にしているのは、以下の3つになります。 Domain Driven Design : Eick Evans Lean Software Archtechture:James.O.Copplien 萩原さんの過去の講演資料(クラスにまたがる散乱ともつれ合い) 複数のプログラミング パラダイムを組合わせる上で重要だと考えるのは、如何以下に設計上でパラダイムを発見するかということです。この目的のために大切なことが、ドメイン、ユースケース(振る舞い)、コンテキストではないかというのが私の考えです。実世界のオブジェクトの振る舞いは、コンテキスト(その時の目標と言い換えても良いです)に左右されると考えているからです。この当たりの考え方は、当たり前と云えば当たり前なんですが、どうも実現が難しいように感じています。これを実現する1つの手法が、Agile Dvelopmentの本質だとも考えています。 話は変わって、TechEdでは「BOF-06 Let’s Dynamic」というBOFがありまして、イスラエル在住のMVPであるShay Friedmanが参加してくれます。彼は、IronRuby Unleashedという書籍の著者でもあります。IronRuby関係で知り合って、今回のBOFへの参加に当たって彼と何度も連絡を取り合っています。TechEdに参加される方で、Rubyにご興味のある方は是非ともご参加ください。 それから、F# 2.0 CTPですが2010 Augustが公開されました。このビルドには、以下の内容が含まれていました。 .NET Framework 2.0対応のバイナリ ソースコード .NET Framework 4対応のバイナリ Windows Phone 7向けのバイナリ 中でも.NET Framework 4向けのF#対話型シェル(fsi.exe)は、日本語の入力もできるようになっています。多分、対話型シェルの標準入力用のパーサーがユニコード対応になったと思います。これでVisual Studio 2010 Professional以上を持っていなくても日本語を使ってF#を試せるようになります。 追記:書き忘れましたが、TechEdのセッションの難易度は高く設定させていただいています。このため、オブジェクト指向分析&設計はもちろんのこと、デザインパターン、アジャイル開発などの知識は必須となります。用語を知っているという前提となりますので、ご容赦ください。 追記:F# 2.0 CTPの.NET Framework 4向けの対話型シェルですが完全な日本語入力に対応しているというものではなく、ユニコード対応のお蔭で日本語の入力もできるという程度のものです(いげ太さんのご指摘により、追記しました)。

2

TechEd 2009 での Silverlight3 を使ったピアノサンプルについて

TechEd 2009のMVPラウンジでお見せしたSilverlight 3のマルチタッチ対応のピアノのデモですが、その後の調査で作成したデモのバグのためにSilverlight3ランタイムがハングアップしたようになっていたことが判明しました。この件は、多くの方が陥りそうな気がするので自戒の意味も込めて、状況を以下に記載します。 Silverlight3でマルチタッチを使用するには、System.Windows.Input.Touchクラスを使用します。 具体的には、「Touch.FrameReported += Touch_FrameReported」のようにイベントハンドラを登録します。イベントハンドラは、「void Touch_FrameReported(object sebder, TouchFrameEventArgs e)」というシグネチャを持ちます。 イベントハンドラ内では、タッチポイントコレクションを取得します。 「TouchPointCollection touchPoints e.GetTouchPoints(FrameworkElement)」メソッドでタッチポイントコレクションを取得します。タッチポイントコレクションには、複数のタッチされたポイントで構成されています。 タッチポイントコレクションからタッチポイントを取り出して処理します。 「foreach (TouchPoint tp in touchPoints)」のようにタッチポイントを列挙します。タッチポイントには、ActionプロパティとTouchDeviceプロパティなどがあります。 Actionプロパティによってタッチ動作を識別します。 TouchAction.Down、Move、Upという列挙値とActionプロパティを比較することでタッチ動作を記述します。タッチの動作の基本は、ダウン->移動->アップ(移動が無い場合もあります)になります。 TouchDeviceプロパティによって、タッチされた場所を識別します。 TouchDevice.Idにタッチした場所の識別子が格納されています。つまり、ダウン->移動->アップが一回のタッチ動作であれば同じ識別子になります。複数(マルチ)のタッチであれば、TouchDevice.Idが異なるので一致するId毎にActionプロパティと組み合わせてタッチ動作を記述します。言い換えると、タッチ動作がダウン->移動->アップですからダウン時にTouchDevice.Idと座標を記録して、移動やアップ時に記録されたIdを取り出してタッチ動作にするのです。 私のサンプルで問題があった個所は、MouseLeftButtonDownイベントとタッチイベントの両方をハンドリングしていたことでした。これで何が問題になったかというと、軽いタッチの場合はOSというかブラウザがタッチダウンをMouseLeftButtonDownイベントに変換してしまうので、タッチダウンイベントを処理できないというものでした。  if tp.Action == TouchAction.Down) { Path hitKey = null; // タッチされた場所の最上位のFrameworkElementを取得 FrameworkElement hitElement = tp.TouchDevice.DirectOver as FrameworkElement; // これが対処したコード while (hitElement != null) { if (hitElement is Path) {…

0

Windows Touch について

Windows 7もRTMしまして、マルチタッチに対応しているPCが幾つかあります。具体的には、以下のようなPCです。 HP Touch Smart IQ800 や IQ500 HP Touch Smart tx2 ノートブック DELL Latitude XT2 や XT Microsoftで行うデモで良く見かけるのが、IQ800です。個人で所有するとなると、ノートブックになると思います。このように記述している私もHP Touch Smart tx2を購入しました。現在は、Windows 7 RTMをインストールして、マルチタッチ対応のプログラムを開発するのに使っています。マルチタッチ対応のプログラムの実行環境としては、以下のような方法があります。 Silverlight 3 .NET Framework 3.5 WPF4(.NET Framework 4.0ベータ1) Win32 APIを使ったネイティブアプリケーション Silverlight 3で開発するには、System.Windows.Input.Touchクラスを使用します。.NET Framework 3.5(WPFかWindows Forms)の場合は、Windows 7 Multitouch .NET Interop Sample Libraryを使用するのが簡単です。このライブラリの場合は、Win32 APIをラップしたヘルパークラスが提供されています。WPF4では、FrameworkElementにTouchイベントハンドラを記述できるようになっています。が、IDEで自動的には記述できませんのでXAMLに記述する必要があります。 Windows Touchを理解するには、ManipulationとInertiaを理解するのが良いでしょう。WM_GESTUREやWM_TOUCHメッセージは低レベルなものなので、自分で動作を作りこむ必要があります。これに対して、ManipulationやInertiaでは、複数のタッチによる振る舞いを処理するための仕組みが用意されているからです。デモなどで見かける、写真の移動や回転、ズームなどがManipulationで実現されているのです。 Silverlight3のWindows Touch対応は、WM_TOUCHメッセージのみの対応となります。従って、タッチによる振る舞いは、コードで作りこむ必要があります。 HP Touch Smart tx2を使っていて気がついた点は、マルチタッチのドライバーの動作が不安定だということです。色々と調べていくと、ACアダプタを抜いてバッテリモードで試すと安定していることに気がつきました。私が使用しているマルチタッチのドライバーでは、静電式パネルのタッチポイントの認識時に電源周りの磁界が影響するようです。この点を気をつけるようになってから、安定してマルチタッチを試すことができるようになりました。

0

Deep Dive to .NET Framework CLR を作成中です

TechEd 2009 横浜で「Deep Dive to .NET Framework CLR」というセッションを担当します。この資料を作成しています。このセッションは、私の著書である「The Root of .NET Framework」という書籍をモチーフにして、資料を構成しています。どのような内容が良いか、悩みながら作成を行っています。その途中経過を以下に引用します。 PEヘッダーから CLIヘッダーのアドレスを見つけて   CLI ヘッダーを読み解くのが、上記のスライドです。ここまで来るとメタデータが、どのように格納されているかを知りたくなることでしょう。それらも作成しているのですが、どこまで作るかが難しいところです。 これ以外にも、GCやCLRのホストインターフェース、RCWなどとアイディアがあるのですが、如何とも時間の制約がありますので作成したスライドを全部、説明しきれないかもしれません。現時点で30スライド程度が出来上がっていて、ここから SOSデバッガ拡張や.NET Framework 4.0の話を入れようと思っていますので。まだまだ、悩みは尽きません。公開されているセッションレベルは400番台なので、最低でも16進数ダンプの見方を知っている方が対象になると思います。

0

DLR Console を使って時計をドラッグするサンプル

前回のエントリで Silverlight Dynamic Language SDK 0.3.0がリリースされたと記載しました。このSDKで提供されているサンプルにDLR Consoleがあります。もっともDLR Consoleは、SDK 0.2.0(Silverlight 2.0 ベータ2と一緒に提供されたものです)で動作するようになっています。SDK 0.3.0に含まれているDLRを調べると、IronPythonのChangeset38029以降のもののようです。このためIronRubyプロジェクトで今日時点で公開されているSVN138よりも新しいDLRになります。このDLRでは、ホスティングAPIなどの細かな変更やネームスペースの変更が行われています。 SDK 0.3.0のDLR Consoleでは、時計をドラッグするというRuby用のスクリプトが含まれています。時計をドラッグするサンプルは、Jimmyさんのブログに解説がありビデオのリンクやDLR Consoleを試すリンクなどがあります(英語キーボードなのでご注意ください)。このサンプルを動かしているのが、以下の画像になります。 ここで入力しているコードを以下に記載します(Jimmyさんのブログには、一か所不足しているコードがありますので)。require ‘lib/clock’ $clock = Clock.show require ‘lib/drag’ Drag.new($clock.canvas).enable これで私は上記のサンプルを動作させることができました。ちなみに今日時点でIronPythonの最新のChangesetは38690がUpされています。 追伸:実はTechEdでこのデモをお見せしようとしたのですが、時間が足りなくて忘れてしまいました。Peer Talkで一部の方に受けていたのが、このサンプルです。

1

DLR B4 対応の MyCalc サンプルです

TechEd 2008 Yokohamaでお話したようにDLRのホスティングのサンプルを公開します。今回は、1)MyCalc、2)Toolサンプルの2種類が含まれています。どちらもIronPython 2.0ベータ4のDLR対応ですので、DLRはIronPythonプロジェクトからダウンロードしてください。TechEdに参加して頂いた方には、事後になりますがカンファレンスDVDにも収録しますので、そちらを見ていただいても結構です。もっともDVDが届くのまで時間がかかりますので、早く知りたいという場合は、ここからダウンロードしてください。 それから当日にお話したと思いますが、IronPythonプロジェクトとIronRubyプロジェクトに含まれるDLRの状況を記載しておきます。 IronPython 2.0ベータ4に対応したIronRubyのソースを私は見つけていません。 IronPython Changeset37512とIronRuby SVN138のDLRは同期しています。 IronPython Chnageset38029のDLRは、37512から変更されていますのでご注意ください。 TechEdでお見せしたオブジェクト共有のデモの環境は、Silverlight2ベータ2とIronPython Chnageset37512、IronRuby SVN138です。それぞれのソースコードは、TechEd期間中にサブミットされた最新を使用しています。 Hosting.zip

1

明日からTechEdが始まりますが、まだデモの準備中です

いよいよ明日からTechEd Yokohamaが始まります。実は、まだデモの準備をしている最中なのですが… 先週中にIronRubyとIronPythonプロジェクトで動きがありました。具体的には、IronRuby SVNが135になって週末には137になっていました。IronPythonでもChangeset 37512が週末にUpされました。これらのリビジョンに含まれるDLRですが、かなり同期している模様です。前回のエントリに記載したChangeset36656とSVN132に含まれるDLRとは異なりますので、ご注意ください。 動かないというものではありませんが、OLEオートメーション系のリファクタリングが行われていました(これだけではありませんが)。IronRubyのソースコードを調べていくと、インタロップ・アセンブリを利用するためにSystem.Scripting.Comネームスペースを使用していました。またIronRuby SVN135からは、RubyというネームスペースがIronRubyというネームスペースに変更になっています。

3

IronRubyとIronPythonのDLRが同期した模様

FXさんからのフィードバッグから色々と調べていました。 IronRuby SVN 132とIronPython Changeset35778で試したところDLRが同期している模様です。両方のソースコードからビルドして組み合わせて見ると問題なく動作することを確認できました。Changeset35778の詳細をまだ調べきれていませんが、ベータ4に対してネームスペースなどのリファクタリングが行われています。一番顕著なのが、System.Scripting.Runtimeネームスペースが、Microsoft.Scripting.Runtimeになっていることです。つまり、Microsoft.Scripting.CoreプロジェクトからMicrosoft.Scriptingプロジェクトへ変更になっているのです。 IronPythonからはclrモジュールのUse関数を利用することでRubyのスクリプトを実行することができます。またIronRubyのソースコードの大きな変更は、署名無しのソースツリーになったことです。 これを使って来週に迫ったTechEd Yokohamaのデモをこれから考えるところです。 追記:FXさんよりフィードバックを頂いて、Changeset36656がリリースされているそうです。このChangesetを使って試してみるつもりです。

4

IronPython 2.0 Beta4 に含まれるDLR

IronPython 2.0 Beta4のリリースに伴ってDLRにも変更が行われています。細かく調べていくと、Microsoft.Scripting.Core.dllに含まれるネームスペースが大きく変更されています。具体的には、以下のようなものです。 Microsoft.Scripting -> System.Scripting Microsoft.Scripting.Runtime -> System.Scripting.Runtimeなど Microsoft.Scripting.Ast -> System.Linq.Expression 現時点では、全てがSystemネームスペースに移行しているわけではありません。一部、Microsoft.Scriptingネームスペースも残っています。また、Microsoft.Scripting.dllの方は、ネームスペースの変更はありません。 現在、TechEdの資料やサンプルを作成しているのですが、上記のネームスペース変更以外にLanguageContextクラスなども変更になっており、色々と調べています。この関係で、IronRubyのSVN 127のソースコードも調べていくと、DLRはSystemネームスペースになっているものが含まれています。でも、Beta4とは違うバージョンのためIronPython 2.0 Beta4からIronRubyを利用することはできませんでした。

3