9月27日(火)に行った第69回codeseek勉強会＆第10回日本C#ユーザー会 勉強会「BUILD 振り返り」の議事録をもとに、出た意見を整理したものです。

実機 意見交換＆撮影会

出たばかり、それも開発者プレビュー版（ベータ未満、バグだらけなの当たり前）状態のWindows 8が、なぜか5台並ぶ不思議な空間。

家で余ってるPCに開発者プレビューを入れることが多いみたいで、さすがに、スレートPCなWindows 8を見たのは初めてという方が多かったです。

ということで、タッチ操作でのWin8の使い勝手がどうかなど、みんなでWin8スレートを囲む会になったり。

画面の上下左右をフリックすることで各種メニューとかアプリ切り替えができるとか、デスクトップPCにインストールした人は意外と知らないようでした。

「シャットダウンの仕方がわからない」と評判のWin8ですが、ここに集まった人たちはさすがに、みんな「終了はConfig（[Windows]+i）→Power」だとわかってました(笑)

ちなみに、Win8を実用

僕（岩永）は自宅のメインマシンにWin8開発者プレビューを入れて使っていますが何か？

まあ、所詮は開発者プレビュー版なので、現段階では、「Windows 7の上にMetro UI乗せただけ」ですねぇ。どうせこれから修正入りまくることがわかってるので、「マウスでMetro UI使いにくい」とか思っても文句の言いようがなく。

さすがに、メインマシンに入れてずっと使ってると、なれちゃいました。いくつか不具合もあったものの、それすら、回避策を見つけてしまい、ほんと普通に使えるように。

スライド見ながら振り返り

ここから先は、適当にダウンロードしておいたBUILDの発表資料スライドを表示しながらあれこれ話す。

kkamegawaさんもブログを書いてくれているのでこちらもどうぞ： codeseek & C#ユーザー会でのBUILD振り返り

Deep dive into the kernel of the .NET Framework

動画： TOOL-813T

上書きアップデート

「.NET 4.5は.NET 4を上書きするらしいけども、大丈夫かなぁ」との心配の声。

何せ、.NET 1.1から.NET 2.0になるとき、「外部的な仕様は完全互換」としてアップデートをかけたものの、「スレッドの内部的なパフォーマンスが向上した」というのが原因で、今まで公にならなかった潜在的なバグが表に出てきて大変だったそうで。

その辺り、

l Compatibility of .NET Framework 4.5:

Ø 互換性には最大限の注意を払って、かなりのテストを行っています

l .NET 4から.NET 4.5での破壊的変更一覧

.NET 4.5の新機能

以下のような内容

l ガベコレ性能改善

l プロファイラーの最適化

l オートマチックNGen

l マルチコア バックグラウンドJIT

l モニタリング用に、再起動しなくてもJITし直してくれる機能

特に、オートNGenに期待。

.NET Frameworkのインストールにやたら時間がかかるのは、インストール時にNGenやってるからなんですよね。これを、最小限に減らす効果がまずあります。

そして、アプリの方でも起動時間短縮のためにNGenかけたいと思っても、NGen使うのが結構面倒という。

それが今回自動化（ただし、アプリも含めてなんでもオートNGenかかるのはMetroスタイル アプリだけ）。

ただし、出た意見としては、「起動が遅いのって、リソースとかの読み込み時間のファイルI/Oが重いんじゃないかという疑惑が。その場合、NGenがどこまで有効なの？」

Async everywhere: creating responsive APIs & apps

動画： PLAT-203T

プリンターの列挙

かつて、業務アプリでGUIをフリーズさせまくった最たる現況の1つに「利用可能なプリンターの列挙」があったそうな。

「GUIをフリーズさせるからやっちゃダメだよ」的な処理の例としてGetPrinter関数が書かれてるのを見て、「あるある」的反応多数。

その他、「長い処理の間にDoEventsはさむ」みたいな、後からいろいろはまりがちな昔話に花が咲いたり。

WinRT APIは非同期APIを提供します

WinRTでは、（可能性として）長くかかる処理を非同期APIとして提供する予定。

ここで、「いやー、やっと、『みんなそうだし、右に倣え』でGUIをフリーズさせていい時代終わりそうですね」との意見が出てくる。

ちょうど今日公開の記事「フリーズしないアプリケーションの作り方」で書いた（校正まで含めて原稿提出済み）内容そのままな意見が出て少し安堵したり。

C++のラムダ式

スライド中、非同期処理のサンプル コードがいくつか並んでいたわけですが、C++のサンプルが出たとき、パッと見でC++だと認識できなかった人多数。

auto picker = ref new FileOpenPicker();
picker->FileTypeFilter->Append(".jpg");
auto operation = picker->PickSingleFileAsync();
operation->Completed =
ref new AsyncOperationCompletedHandler<StorageFile^>(
[this] (IAsyncOperation<StorageFile^> ^ op)
{
if (op->GetResults()) {
MyButton->Content = op->GetResults()->FileName;
}
});
operation->Start();

autoとかラムダ式とか、C++11の新機能がまずまだあんまり見慣れないのと、C++ Component Extensions (C++/CX)っていうマイクロソフトの独自拡張（^とかでWinRTオブジェクト（昔でいうCOMみたいなもの）を管理してる辺りとか）が全く見慣れないのとで。

C++/CX

パッと見、ほとんどC++/CLI（C++の.NET Managed拡張）っぽいけど、別言語というか、別実装。

ビルド時コード生成の類でWinRT APIとのやり取りをしているみたいで、ほとんどコストのかからない（仮想関数呼び出し程度のコスト）実装になってるとか。

メモリの自動管理は参照カウント方式で、循環参照を解決するような仕組みも入ってるとか。

出た意見としては、「循環参照を自動解決って、どこまで信用していいものか…」

JavaScript promises

JavaScriptは、promisesを使って非同期処理。

割かし、最近のJavaScript方面ではデファクトスタンダードになりつつあるような普通の書き方だそうで。

でも、C#に慣れていると、function() { return …; } が長ったらしく感じる。

あと、今のJavaScriptはシングルスレッドで動いてて、自然と非同期処理にはpromisesみたいなものが発展してきたけども、これにスレッド ライブラリが入ったりするとどうなるかなぁという心配が。

C#/VB await構文

C#とVBには非同期メソッドとawait演算子があるので、WinRTとの相性非常に良いです。

非同期メソッドでの例外処理

Task.ContinueWithとかを使って非同期処理を書くと、コードの見た目上のtryブロックの範囲と、実際に例外をキャッチできる範囲が違ってくる。

一方、非同期メソッドで書くと、ほんと、例外処理まで含めて、同期処理の時と全く同じ感覚でかけたり。

Don’t worry about Concurrency

もう1個、非同期メソッドの利点は、SynchronizationContextを介して、UIスレッドに処理が戻ってくること。

（使う側は）lock不要だし、Dispcatcher不要。

[追加情報]C++/CXでも非同期メソッド？

なんか「Asynchronous patterns in the Windows Runtime」という記事で、Noteの所に、「Visual C++ Beta is expected to provide syntactic support that will greatly simplify consumption of asynchronous APIs」(VC++ベータでは、非同期APIの利用を劇的に簡素化する構文サポートが入ると期待される)とかいうセリフが。

C++/CXにも非同期メソッドのサポートが入るのかな？まあ、WinRTが非同期メソッドだらけになるんで、必然的にそうせざるを得ないかなぁ。

個人的な意見としては、非同期メソッドが「.NETだけの特殊な概念」とか思われなくなるよう、C++/CXや、その他、後追いしてくるいろんな言語にこの手の構文サポートが入ることを期待します。

バージョンアップのたびに…

「.NETって、バージョンアップするたびに非同期APIの書き方の流儀変わってる」という意見も。

さすがに、await演算子も入ることですし、今度こそ確定ですかねぇ、Task非同期パターンに。（↓こういうパターン）

Task<T> MethodAsync()

Windows Server 8 apps must run without a GUI

動画： TOOL-532T

（ほとんど、タイトルだけを見ての会話）

PowerShellの扱い

GUIなし版のServer CoreでもPowerShell動くようになるのよね？

というのも、Windows Server 2008では…

l PowerShellは.NET Frameworkに依存しています。

l （今までの）.NET FrameworkはWindowsフォームを含んでいたために、GUI部分だけ切り離すことができずにいました。

l 結果、GUIなしでPowerShellは動きません。コマンドラインなのに。

l もちろん、Windows Server 2008: Server CoreにはPowerShellは載りません。

おいおい…

ということで、GUIなしで動くPowerShell、本当に待ち望まれてたり。

で、それの意味するところは、ちゃんと.NET Frameworkの中核からWindowsフォームを分離したということのはず。

Windowsフォーム…

もう、Obsolete属性つけていいんじゃね？（暴言）

Windows Runtime internals: understanding "Hello World"

動画： PLAT-875T

COM

WinRTの内部的な挙動についていろいろ説明が。

「COMだ、これ」的声多数。

まあ、ほとんどのアプリ開発者、特に、開発言語にC++を選ばない人にとってはほとんど関係ない話。意識する必要ないと思います。

ただ、この手の内部挙動みたいな話は、発表当初にしか説明されないことが多いので、今回のBUILDはそういう意味では非常に重要かも。

パッケージ： デプロイとインストール

デプロイ、インストール、アップデート、アンインストールは、やっぱOS機能として入ってるべきよなぁと。

現在、Windowsのセキュリティ ホールの大半はJava VMとAdobe Readerのアップデート忘れによるものらしいですし。

「.msiインストーラーは、どんなに気を付けたつもりでもやっぱ一定数エラーが出て、一定数クレームが入る」という意見も。

The complete developer's guide to the SkyDrive API

動画： TOOL-532T

セッションのほとんどがデモで、スライドに何も書いてないので今回あんまり何も見れず。

サンプルのソースコードを一応持ってきていたものの、SkyDrive SDKを入れてこなかったので起動できなかったという…

サンプルの内容は、SkyDriveにデータを保存するメモ帳作り。

JavaScriptからのWinRT利用

（ちょっとどのセッションだったか失念）

ネイティブとのグルー コード

JavaScriptに限らないのだけども、対外のスクリプト言語では、CかC++とかネイティブとの連携のための橋渡し的な仕組み（グルー（glue: 糊））を持っているわけですが。

MetroスタイルHTML5+JavaScriptアプリからWinRTを呼ぶ仕組みも「まあ、やるよね」的雰囲気。

ただ、多くの場合、スクリプト言語側はきれいになるものの、ネイティブ側のグルー コードはかなり汚くなりがち。WinRTは、相互利用（ネイティブ側もまともに）なので安心。

innerHTMLかー

サンプル コードが、innerHTMLプロパティを使って、文字列でタグを生成してて、ため息が聞こえてくるなど。

コードでUI生成したら負け。

まあ、いずれ、jQueryみたいな仕組みが載るんでしょうねぇ。

アニメーション

CSS3のアニメーションとは別系統だったり。

XAMLアプリ（C++や.NET）と共通なんですが、「このページとこのページの間はこういうタイプの遷移アニメーションにしたい」っていう、種類情報をプロパティに設定するだけ。お手軽。

その他

Metroスタイル アプリとDirectX

Metroスタイル アプリからDierctXは使えます。

ウィンドウ ハンドルと切り離したAPIが1個追加されているそうで、それでMetro側からDirectXを呼べるとか。

というか、Win32 APIも一部分だけ使えます（何が使えるかはwindows.hを見れば大体わかるそうで）。

同、XNA

「WinRTアプリでXNAは使えるの？」という話題も。

現状の答えとしては、ない。

けども、Windows Phone 7との統合の話も（研究レベルで）出てるし、いずれ載らないとおかしい。

それに、「せっかくゲーム用APIとして非常にすっきりしたものを作ったのに、なくすのはもったいない。なくさないだろう。」という意見も。