Archive for 8月 2010
Microsoft Tech·Ed Japan 2010 終了
ブログ書くまでが Tech·Ed ですｷﾘｯ
という話が多々聞こえてくるので色々と。正規セッション、閉幕後の懇親会で話した内容問わず。基本的に開発系。適当にまとまりなく。
- 開催前の話だけども： 【TechEd】 閑話休題：どれが正しいんだよ～ という話
- 半角・・・中点・・・だと・・・！？
- Unicode だと U+FF65
- ちなみに、英語圏の Tech·Ed は latin middle dot（U+00B7）みたいです。
- どうしてこうなった・・・
- Shift JIS に入ってる記号の中で latin middle dot に一番似ていた説
- Word が悪さする説（実際、Word で latin middle dot を入力すると勝手に bullet（U+2022）に置き換えられる）
- Unicode に全角・半角の区別残しちゃったのは黒歴史な気もするなぁ
- 既存システムの移行のためなのはわかるけども
- 「番地は全角数字で入力してください」みたいなシステム見るたびに泣きそう
- 半角・・・中点・・・だと・・・！？
- Bing Maps API（アプリを地図に読み込む）じゃなくて、「地図にアプリをのせる」
- http://connect.microsoft.com/bingmapapps
- 今後、Azure の制約もどんどん解消されて、書き換えなきゃいけない部分減っていきそう
- VM Role（IaaS 型に近いサービスの提供）
- Windows Azure Platform Appliance（サード バーティ製 Azure の登場で融通の利く度合が増しそう）
- 2種類のデータ ストレージ
- RDB と KVS
- オンプレミス/クラウド連携
- サービス バス（処理連携）
- フェデレーション認証（認証連携）
- 運用監視
- リモート監視になる
- ミドル以下がブラックボックス → 不具合調査、場合によっては、ログとかを元に MS に調べてもらうことに
- テスト機能拡充
- IntelliTrace
- コード化された UI テスト
- Visual Studio Lab Management 2010 によるテスト環境の仮想化
- MS Test Manager でテスト実施管理
- （Ultimate 必要だったり、Pro の場合別ラインナップで買わないと行けなかったりするけども）
- 実は、.NET って末尾再帰の最適化用に Tail 命令（Call とかの前に置くプレフィックス命令）ってのを持ってたり
- こいつが付いてるとちゃんと末尾再帰をループに展開する
- F# で再帰コード書くとちゃんとこの命令入る
- 64ビット版の .NET Framework の場合、Tail 命令入ってなくても最適化できそうなら末尾再帰のループ化する
- 試しに永久に再帰抜けないようなコード書いてもスタック オーバーフローしない（もちろん実行止まらないけど）
- ただし、Release ビルドのみ
- テキスト入力心配
- ケータイでそんなに文字入力しないと思う？
- http://d.hatena.ne.jp/ufcpp/20100216/1266337507、http://d.hatena.ne.jp/ufcpp/20100219/1266594885 ←この記事とか、ほとんど電車の中で立ったまま片手でケータイ入力してますよ
- PC でやった作業ははてな記法に整形しなおしたのと、ところどころハイパーリンク足したのと、動画差し込んだだけ
- といっても数千文字程度ですけども
- http://d.hatena.ne.jp/ufcpp/20100216/1266337507、http://d.hatena.ne.jp/ufcpp/20100219/1266594885 ←この記事とか、ほとんど電車の中で立ったまま片手でケータイ入力してますよ
- 片手入力で、qwerty 配列入力はかなり無理臭い
- ClickOnce を駆使して、あたかもウェブサイトの一部であるかのようにふるまおうとしてる WinForms アプリ見たことあるし
- クライアント技術とか、色々変えたり移植したりしたくなるんだし
- BOF-10「マイクロソフトの Web テクノロジ最前線と現実解を語ろう」でそんな感じのデモがあったようで
- 実際サーバー上は Data Services だけで、HTML5 + JavaScript で作ったアプリ
- サーバーの役目はデータの永続化だけ
- ダウンロードした PDF なり何なりに金を払いたいんじゃない
- サーバー上に「購入した」というフラグを立てたいんだ！
VB たん（魔法バージョン、上京前）
VB たんは都会に出る前後でずいぶん変わったという設定で、こいつは田舎時代版。
作画: Paese
- VB たんの田舎時代、魔法少女版は「べたな魔女」で
- 武器もべたに魔法のほうき
- ただし、マントの下はいもジャージ
- 割かし珍走な感じのほうき捌き
Lisa Feigenbaum Q & A、All-In-One Code Framework 規約集、等々
- Q&A: Microsoft’s Lisa Feigenbaum Talks About C#
- 自分の興味あるとこだけ抜き出し：
- Compiler as a Service は引き続き頑張ってるけど、まだもうちょっと先
- 用途は、サード パーティ拡張、REPL（対話的シェル）作成、DSL 埋め込み、アプリ中で C# をホスト
- C# への要望としてよくもらうもの（実装するかどうかは未定）：
- tuple、immutable な型、非 Null 許容型、Null 伝搬するメンバー呼び出し、"info of" 演算子（typeof の MethodInfo 版）、XML リテラル、ジェネリック内でユーザー定義演算子を使いたい、拡張プロパティ・拡張イベント
- [C#][VB][C++] All-In-One Code Framework Coding Standards
- MS 公式のサンプル コード集におけるコーディング規約集。
- 元がサンプル向けなので、多少違和感ある部分もなくはない
- それでも、Dipose パターンの書き方お手本とかはかなり参考になる。
- RFID kit with .Net Support!
- Maker Shedの新製品 Netduino – .NETベースのオープンソースエレクトロニクスプラットフォーム
- .NET で組み込みな感じ。
やっぱ実行時よりビルド時
動的コード生成 VS ビルド時コード生成
こないだ、動的コード生成がらみのネタで1ページ書いて公開したところ、「ビルド時で済むものは動的コード生成じゃなくてビルド時コード生成にして欲しい。」との至極まっとうなご意見をいただきまして。
最近、ViewModel の実装が面倒という問題に対して、DynamicObject を使った動的プロキシが流行ってるみたいだけど、ViewModel なんてビルド時コード生成で事足りる最たるもので、あんまり動的にやって欲しくないという。まあ、ごもっとも。
まあ、僕としても方向性としてはおおむねこの意見に割かし賛成だったり。具体的には：
- DynamicObject の実装が思いのほか簡単なので、「手抜き実装」としてはあり。
- ちゃんとやるならやっぱり静的に（ViewModel 手書きするか、ビルド時コード生成するか）した方がいいと思う。
くらいに思っています。
dynamic は、ちゃんと使えば静的なコードの5～10倍程度のペナルティで済むという話に対しても、「過度に恐れる必要もないけども、そりゃ避けれるなら避けるよね」くらいの立ち位置。動的にやるのが避けられない状況（例えばユーザーの入力に応じたコード生成が必要とか）になっても別に慌てなくてもいいよという。
テキスト テンプレート
現状、Visual Studio 使って開発するなら動的コード生成の方が楽なんですよねぇ、微妙に。ビルド時コード生成よりも。ほんと、微妙に。式ツリーとか CallSite になれてる人ってのもそう多くないでしょうけども、自分的には。正直、ビルド時コード生成は次（か、ひょっとしたらそのさらに次くらい？）のバージョン待ちかなぁなどと思っていたり。
というような話をすると「T4 を使え」とのご意見もらいまして。前は日本語情報なさ過ぎてちょっとくじけてた T4 テンプレートを、久々に調べて使ってみるなど。
でも、T4 は何か微妙に使いづらいなぁとか考えてたら、昔、元同僚が「テキスト テンプレートなんてヒア文字列と、文字列中での変数展開だけあればいい」って言ってたのを思い出したり。そうよ、PowerShell の方がたぶん使いやすい！
ということで、ちょっと書いてみました、PowerShell でテキスト テンプレート。
- データ定義： SampleClass.xml
- テンプレート： ViewModelTemplate.ps1
使い方は、
$x = [xml](Get-Content 'SampleClass.xml') .ViewModelTemplate.ps1 $x.Definition > SampleClass.cs
出力されたファイルは以下のような感じ。
- 出力された C#： SampleClass.cs
悪くはないかも。まあ、Visual Studio と統合されてるわけじゃないのが微妙ですけども。もうすっかりゆとりで、IntelliSense なしでコード書くのが苦痛だったりしますし。あと、定義ファイルが XML なのも微妙だし。XSD 書けば多少マシになりますが。
++C++; 本体に3ページほど追加
twitter 上に有明での戦況報告流れる中、黙々と引きこもって、久々に更新作業を行っていたりなど。
- [雑記] 動的コード生成のパフォーマンス
- dynamic、意外とパフォーマンス悪くないよ
- 汎用言語の進化
- DSL を取り巻く状況とこれから
- 最近ブログに書いてた DSL 回りの話をまとめる
- DSL とかドメインモデリングまわり、歴史的背景と今現在のトレンド的なもの
No More
このような話題を見かける：
失敗談とか繰り返しちゃいけないような酷い事例の共有って実はすごく重要なはずなのに、成功談と比べると非常に少ないんですよねぇ。匿名文化もありうる昨今、もっと失敗談共有して行ってもいい気がする。（黒い発言しちゃうと、あまりにもひどいことやってる会社は実名さらされても文句言えないと思いますけどねぇ。まあ、そこは置いておいて。）
その昔、こんなのありました。
もう17年前のもので、C 言語時代のものなので今となっては笑い話・・・のはずよね？・・・あれ、今でも見るような話題もなくも・・・あれ？保守案件・継続案件はともかく、あれ・・・？
一定ペースで人が引退し、新人が入ってくるわけで、ほっとくと絶対に歴史繰り返すんですよねぇ、人間って。歴史の研究とか、学校での歴史教育が「歴史 ＝ 年号と事件名暗記すること」になっちゃってるせいでブレがちですけども、歴史をひも解く価値って、同じ過ちを2度繰り返さないよう、「何をやった結果どんなことになった」という知識を残すことなわけですけども。
ViewModel とかいちいち書いてられないよね
こんな DSL 書ければいいのに（願望）。
書きたいDSL
http://ufcpp.net/study/csharp/draft/Characteristics.txt
module TypeDefinition.Models
{
// 特性データ
type Characteristics
requres Norm >= 1
{
// 特性 X
X : double
requires 0 <= X && X <= 1;
// 特性 Y
Y : double
requires 0 <= Y && Y <= 1;
// 特性 Z
Z : double
requires 0 <= Z && Z <= 1;
// 一次ノルム
Norm = X + Y + Z;
// 変更の適用操作
command Submit excuted on this.Valid;
}
}
ちょっと恣意的な型なのでわかりにくいですが、以下のようなもの：
- 元データとして X, Y, Z の3つの double を持ってる
- そこから導出される値として Norm を計算できる
- X, Y, Z はいずれも 0～1 という制約付き
- さらに、Norm が1以上という制約も付いてる
- （ViewModel 上で使う用に）Submit というコマンドを持っていて、こいつはデータがきちんと制約を満たしていないと実行できない
生成したいコード
こいつからこんなソース吐き出したいなぁ（願望）
注意： 適当なので、いまいちな部分も結構あります（Contracts の使い方わかってなかったり、Submit コマンドの扱い方に迷いがあったり）
- http://ufcpp.net/study/csharp/draft/Characteristics.cs
- immutable で、かつ、コンストラクター内でデータ検証
- なので、コンストラクターさえ通ればデータの有効性保証
- （追記）色々突っ込みを受けて微修正
- partial 付けた代わりに、プロパティの private set やめて、private readonly なバックフィールドを追加
- Contract.Assert じゃなくてこの場合 Contract.Ensures だった
- http://ufcpp.net/study/csharp/draft/CharacteristicsViewModel.cs
- ViewModel 用（この例は Silverlight）
- INotifyPropertyChanged.PropertyChanged 地獄
- Norm = X + Y + Z みたいな記述から、プロパティの依存関係を見て、PropertyChanged の呼び出しを自動的に追加
- ICommand.CanExecuteChanged 地獄
- INotifyDataErrorInfo 地獄
- （http://ufcpp.net/study/csharp/draft/DelegateCommand.cs）
あとは OR マッパー向けのエンティティクラス作ったりかな。階層的なデータとかコレクションも扱えると完璧だけども、結構めんどくさそう。
この DSL のポイント
- GUI 用の ViewModel でも、データアクセス用の Entity でも、大体共通して書くのは：
- プロパティ名、型、データ検証属性
- あと、DSL 中の注釈もそのまま DisplayName 属性とか ///<summary> コメントに反映されて欲しい
- 生成したいのは
- ViewModel 用
- ユーザーからの入力をいったんなんでも受けた上で、データ検証通らないと Submit コマンド実行できないように
- その他用
- GUI が絡む部分以外はいっそ immutalbe にしておく方が人的ミスも減るし、最適化もかけやすいはず
- one-phase 構築して（コンストラクターで一気に初期化して、以後、個別のプロパティ変更を認めない）、データ検証通らない状態を認めない
- 元データ以外に、導出される値があるはず
- ViewModel にする場合には、X の変更を Norm の変更としても PropertyChanged イベント起こさないとダメ
- 変更の通知はプロパティ間の依存だけじゃなくて、コマンドの実行可否にも影響するので、ICommand.CanExecuteChanged イベントも必要
- 複数のデータにまたがるデータ検証もある
- 例えば今回の場合、ViewModel 用なら Submit の CanExcute で検証するし、その他用ならコンストラクターで
DSL 作成支援、もっと欲しい
まあ、パーサー書いてコード生成すりゃできるんでしょうけども、数日前に書いたように、単に頑張ってパース＆ソースコード生成できてもいまいちだなぁと思っておりまして：
- 構文ハイライト欲しい
- IntelliSense 欲しい
- 式を書ける部分にはまんま C# の文法使いたい
- 自分で C# のパーサー書かなくても、自作部分から
syntax View = Identifier ‘=’ CSharp.Expression;
みたいに書けば標準で用意されてる構文定義使ってパースできるような。
- 自分で C# のパーサー書かなくても、自作部分から
- コード生成の方も、文字ベースのテンプレートじゃなくて、構文木ベースでできないものか
- それも、関数型言語に見られるような Quote 的に、普通に C# っぽい記述書けば構文木になるような（今の式木 ラムダの拡張）
そういうのができる仕組みとか整わないかなぁ・・・
DSL の行く先 (2) – 意外とそう遠くないかも
Code-Enabled
昨日の記事の「非開発者向け」って言葉は言い過ぎかなぁとか思ってたら、以下のような記事が。
「Code-Enabled な人」って表現がいいのか。Coder（コード書くこと自体がお仕事）じゃなくて、何らかの製品の設計を担うプロフェッショナルで、コード読んだりコピペしてくるくらいにはコーディングに精通してる人。それが LightSwitch の真の顧客だと。
でも、LightSwitch みたいなお手軽開発ツールはいろんな層の人の支援になるんじゃないかとも思ったり。
- Code-Enabled な人が動くアプリを直接自分で書けるように
- Coder な人も簡単に設計フェイズを行えるように
- アプリ利用者側もある程度読み書きできるように
- 委託して作ってもらったものの良し悪しをある程度分かるように
- 委託先と保守契約で喧嘩別れしたって、新たに保守の引き継ぎなりアプリのリプレースなり請け負ってくれる別業者見つかるまでの間くらいは自前でつないでいけるように
DSL 理想像
上記の話と一緒に、以下のようなもののフィードで見かける。
曰く、「ものすごく誤解を招きかねない要約として、『WFの競合技術』だと理解した！」。確かにそうだなぁと思う反面、以下のようなことも思ったり。
- シーケンシャルの処理はテキストベースで書ける方がありがたいけど、分岐とか反復のフロー入るとちょっと・・・
- でも、テキストベースで書いたものが視覚化されるとか、視覚的にデザインしたものの対応するコードが見れるとうれしいかも
- ん？そういや昔そんな話あったなぁ・・・
- 何だっけ・・・と調べてみた結果、Martin Fowler だ！言語ワークベンチ！
というので、以下のような pptx 資料作成。
昔は結構絵空事な感じはあったものの、今ならできるかもなぁ。.NET が次期バージョンでメタプログラミングな方向性模索してるのと、Visual Studio に MEF みたいな拡張機構が備わったので。XAML とか EDMX とかある程度 DSL として成功しているものもあるし、T4 テンプレートみたいなメタプログラミング的環境も出てることだし。
ドメイン モデリングの行く先
Quadrant がお亡くなりになったそうです。という記事をきっかけに、思ったこととか人と話したことなど書いてみる。
非開発者向け
今、IT 使った何かを作るとき、問題領域（ドメイン： domain）に関する知識と、プログラミングに関する知識の2つに詳しくないと何もできないんですよね。問題領域っていうと、例えば、よく話にあがるのだと：
- 大規模データ処理
- 自然言語コーパスを元に、検索や機械翻訳の精度を上げたい
- 顧客の購買行動を解析して、よりよりセールスをかけたい
- 業務知識
- 業務のフローを IT で補助・改善したいけど、そのためには業界の商習慣とかの知識が必要
とか。
2重にスキルを求めるのは負担が非常に大きいんで、出来れば問題領域の専門家が、プログラミングの知識なしで使えるようなツールが欲しいと。そういう話はもうかれこれ20年くらいは言われ続けていたり。
DSL
そういう、問題領域の専門家向けのツールとして、DSL（domain specific language： 領域特化言語）というのがあり。要するに、領域を絞ることで、学習を容易にしたプログラミング言語を作ることで、プログラミングの知識のない人にも使いやすい言語にしようというもの。
1990年代にも、テキスト ベースの DSL なんかは出ては消えを繰り返していました。いまいち定着しなかったのは、
- 使う側： 領域を絞ってもまだハードルが高い
- Visual なツールの補助が必要
- 例えば、C# が簡単な理由の1つは、Visual Studio による補助が学習ツールとしても優秀だから
- 覚えやすくするために「特化型言語」にしたのに、そのせいでツールの補助が受けられず、かえって覚えにくいという
- 作る側： 作るの大変
- 極端な話、汎用言語なら作る手間 0 なわけで
DSL Tools
その昔（確か、2005年前後だったと思う）、DSL Tools というものがあったりも。上記のような問題があるんで、Visual Studio の利用を前提とした、Visual な言語（例えば、フロー図とかをドラッグ＆ドロップとかしてつないで作っていく言語）を作るためのツールでした。ただ、DSL Tools にも問題があって：
- 個々の製品ではある程度 DSL の利用が成功したが、製品間の連携で困った
- 「特化型」という性質上、「オレオレ」になりやすい
- Visual 言語に偏向しすぎた
- 使う側： 非開発者であっても、マウスでポチポチ作業するより文字ベースで記述したい人は多い
- テキスト言語でも、構文ハイライトとか IntelliSense とかリアルタイム構文チェックとか、Visual ツールで補助できることは多い
- 作る側： Visual なものは、その分さらに作るのが大変
Oslo（現 SQL Server Modeling）
という背景があるので、Oslo は以下の3つの軸が：
- Repository
- DSL / ドメイン モデルの共通基盤
- 複数の製品の連携を最初から考えている
- M 言語
- テキスト ベースの DSL 記述
- あと、データベースとプログラミングの間の溝を埋めるという役割も
- C# に近い記述でエンティティ定義
- これも、データベースの知識とプログラミングの知識の「2重のスキル要求」の解消
- M 言語で記述した DSL は、IntelliPad っていう付属のエディターを使えば構文ハイライト＆リアルタイム構文チェックされる
- Quadrant
- データの可視化ツール
発表当初は、やっぱり「非技術者向けのツール」を目指していたんだとは思う。けど、実際のところ、一番食いついたのは、M 言語に興味を持ったガチ開発者ばかりだったような。そこが Oslo の問題だったように思えます。
結局、Oslo は SQL Server の一部分としてコンパクトに収まり、今回 Quadrant の開発は停止という運びに。
その後
Oslo を開発していたチームは Data Programability チーム（Entity Framwork や WCF Data Services を開発してるところ）に統合されたと聞きます。そしてこのたびの LightSwitch の登場。きっと、Quadrant を開発していた人も LightSwitch に関わってるのかなぁと。「Quadrant よりこっちに力を注ぎます」といったところでしょうか。
その辺りを考えると、Oslo の目指してたところは形を変えて残っていくことになりそうな。
- 複数のドメイン モデルの連携
- Repository は SQL Server Modeling として残るだろうし
- 今は、OData みたいに、データの取り出し口の部分を標準化することで製品間連携していく仕組みもあるし
- テキスト ベース DSL
- C# / .NET Framework 自体が、今、メタプログラミングな方向に向かってる
- M 言語とか IntelliPad/Quadrant みたいな独立したものよりも、C# に取り込まれたり、Visual Studio との連携を前提に進化していきそう
- 作る側も簡単じゃないといけないし、使い側にも学習・利用のツールによる補助がないといけない
- データベースとプログラミングの溝を埋める
- 非技術者向けツール
- LightSwitch がそうだし、データの可視化・解析って面では PowerPivot とかも
++C++; // 未確認飛行 C ブログ 