Archive for 6月 2011
開発者にとってのWindows 8
Windows 8 上の開発環境について、ようやくきれいに整理された情報が。
といっても、公式アナウンスではなくて、リークした Windows 8 （もちろんβにも満たない開発途上版）の解析結果から得られた知見。
少々私見も込みで、要約:
.NET がもたらしたもの
まず少々歴史の振り返りを。
.NET Framework 登場以前、90年代に置いて Windows 開発がどういう状況だったかというと、「C++ と VB のパリティ（あっちを立てればこっちが立たず的な偶奇性）」という深刻な問題がありました。
Windows の機能を最大限使いたければ Win32 API を使う必要があって、それは VB では難しかった。あと、パフォーマンスの問題もあり、大規模で応答性のよいアプリを書くには C++ しか選択肢がなかった。
一方で、C++ はとにかく大変。特に、データベースアクセスと GUI 開発の効率は VB とは雲泥の差で、業務アプリなんかを書くなら VB 一択だった。
私見でいうと、VB と C++ の間のギャップっていうのも非常に問題だったと思います。「初心者は VB から」という一方で、深くプログラミングに関わるならいずれ「C++ への以降」が必要だった。そして、その間にある深い溝を超えるのは非常に大変。こういうギャップを作るというのは、「初心者から抜けるな」と言っているようなもので。
.NET や C# が、1.0 当初、「VB の生産性と C++ の性能を併せ持つ」として売り出されていたのも、こういうパリティやギャップの問題を解決したいという思いがあります。実際、（6 以前のクラシックな） VB とは違い、.NET は Win32 API へのアクセスが容易になっていて、パフォーマンスもそれなりによく作られています。もちろん、データベースアクセスや GUI 開発の効率の良さはそのままで。
Longhorn
かつて1度、.NET を中心に添えた Windows 作り（コードネーム Longhorn）というのが試みられていたわけですが…
結局ボツったというか、単なるライブラリ提供（.NET Framework 3.0）となり、OS 的には Win32 のままでリリース（Windows Vista）されました。
WPF（Windows Presentation Foundation、.NET 3.0 の一部）もこの一環だったわけです。元々 Win32 API の置き換えを狙っていただけあって、さすがに多機能。ベクター画像ベース、解像度独立、ハードウェア アクセラレーションありな新 GUI API。また、WPF も、取り扱うメディアごとに使うライブラリが異なることに起因するパリティの解消が目的の1つです。
パリティ問題再び
Longhorn がお蔵入りしたことで、再び .NET vs Native なパリティ構造が増していたり。
Windows の API はまず C++ 向けの Native API として提供されます。.NET からの利用（P/Invoke）は出来はするものの、そこそこ面倒な作業が必要です。一方で、.NET 向けのラッパー API の提供を待っていると、機能公開から1テンポ遅れることになります。
WinDiv（Windows 開発部門）とDevDiv（開発ツール部門）があまり仲良しじゃないというのが問題に拍車を掛けているそうで。WinDiv は C++ 推し、DevDiv は .NET 推しで、両者の間にかい離があるとか。
あと、これも個人的な意見ですが、昨今の Web 標準 vs プラットフォーム固有 の対立（HTML5 vs { Java on Android, Objective-C on iOS, Silverlight }）の構図、かつての VB vs C++ と同じに見えてしょうがないんですよね。パリティもギャップも大きく。
そして Windows 8
現状（リークしたコードの解析によれば）、Windows 8 の目指すところはどうも、再びこのパリティの解消にあるようです。Longhorn で果たせなかった夢の再開とも。
.NET と Native を同列に扱う仕組み。そして、そこにさらに HTML5 ベースのアプリが加わるという。
- WinRT (Windows Runtime): Win32 に変わる新 Windows API
- 20年前の C 言語スタイルではなく、モダンな C++ 向けの設計に置き換わるとか
- WinMD (WinMetaData): .NET のメタデータ（共通型システムの型情報）部分を、Native でも定義/利用できる
- DirectUI: （おそらくは WinRT の一部で）WPF/Silverlight 的なプレゼンテーション層を Native 実装
- 現状の WPF/Silverlight の基礎部分みたいな作りになっているとか
- そして、XAML ベースで書く（WinMD と合わせて考えると、Native な GUI も XAML ベースで構築することに）
- DirectUI として提供されるのはおそらく基礎中の基礎な部分のみで、WPF なんかはその上に Managed な層を重ねて再構築されるものと思われる
- コードネーム Jupiter: どうも、Silverlight 6 にあたるものではないかと。WP7 のマーケットプレース（AppHub）にあたるものを Windows 8 にも導入するはずで、それ用の、Win8 向け Silverlight かな？
Native でも共通型システムにアクセス可能（WinMD）という部分が非常に重要。Native で書かれたライブラリが即座に .NET でも利用可能。逆もまたしかりで、「WPF でないとベクター画像ベース、GPU アクセラレーションありのアプリが書けない」という状況が解消されるということに。
先日物議を醸しだした「Windows 8 では HTML5 + JavaScript でアプリ開発」というやつも、WinMD を介した Native/.NET との相互運用が肝になりそうな予感。
つまるところ、「これからは HTML5 になる」じゃなくて、「これからは Native/.NET/HTML5 の垣根が解消される」が正しかったと。
（もちろんこれは Windows 8 上での話でしかないので、引き続き、Web 標準 vs プラットフォーム固有 の対立はなんら解消されることなく続くと思いますが…）
BUILD を待て
これらはあくまでリークした非正規な情報を元に語られているもので、正式には、「BUILD（今年9月開催）まで待ってくれ」となっているわけです。
ひょっとすると、やってることが Longhorn で果たせなかった夢の再来なので慎重になっているのかもなぁという感じが。最初のビジョン（Longhorn という新 OS、新 API）から徐々に妥協的（WinFX というライブラリ、.NET Framework 3.0 の一部）になっていったのを見て、それなりに皆落胆したもので。
コンピューター プログラミング入門以前
ずいぶん長いこと「書いてます」と言い続けてたものがようやく出版される運びとなりました（6/30 発売）。
初心者をターゲットにした本ですが、どちらかというと、副読本的立ち位置です。（なので、「入門」ではなく「入門以前」だったり。）
実務じゃまず必要ないくらい低レイヤーから高レイヤーまで網羅的に概要説明という感じで、普通のプログラミング入門本＋これを読んで欲しいというもの。
Java や C# でプログラミングを覚えたという人にも低レイヤーのことは知っておいて欲しいし、環境的に低級言語しか使えない人も高レイヤーのことを知らないでいいとは思わない。ただし、そういう幅広い知識は教養として知っておくべきものなので、「最初は C から初めて Java や C# に移れ」ということではなくて、副読本として実務と並行して学ぶべきものかなと。そういう立ち位置の本になります。
Debugger Canvas、Kinect SDK、C++ AMP
なんか一気にいろいろと話題が出てるような。年度末だからかな。
- Debugger Canvas
- Dev Labs に新顔。
- 画面が広い人は勝ち組。
- Kinect SDK Beta Launch
- やっと。ギリギリ春！（春には公式に出すと言ってた）
- Introducing C++ Accelerated Massive Parallelism (C++ AMP)
- 日本語記事: MicrosotがGPGPU開発向けC++の拡張「C++ AMP」を発表
- GPGPU的なものをC++に組み込もうとしてるとか？
- アナウンスだけで、実物なにもないけども。
- ネイティブ言語の方向性って今後こういう方向にならざるを得ないと思うけど、今よりさらにC++がカオス化するのか…
- そういや、こんなものもあるそうですが: Accelerator
- MS、Visual Studio向けHTML5ツール「Web Standards Updates」を提供開始
快適4画面ライフ
twitter ではつぶやいていたわけですが、我が家のPC環境が4画面構成になりました。
4画面化した結果
大体、以下のような具合に使っています。
まあ、4枚全部使うのは、重たい作業をしている時だけですね（といっても結構ずっと）。参照したい資料が複数あるとか、作業フォルダーをたくさん開きたいとか言うときくらい。
上2枚は結構見づらいので、基本的には退避場所になります。それでも、作業用に使っているフォルダーをロストしないとかいうだけで、かなり作業効率が上がります。あと、作業途中に割り込みが入って別作業しても、復帰がかなり楽。
息抜きモードな感じのときとかは、上2枚は電源を切っていたりします。右上の1枚だけ電源切って、3画面なことも結構あります。まあ、4枚はやりすぎかもしれないけども、3枚は普通にありだと思います。
ディスプレイ アーム
ディスプレイ アームは、一応ヨドバシとかに行って色々見比べた結果、一番コンパクトで使いやすそうだったものに。
ただ、結構人気商品のようで、ヨドバシでは売切れてて、結局家に帰ってからAmazon発注。
見ての通り、結構細いです。カタログスペック的には「モニターごとに10kgまで」とのことだけども、40kgくっつけるのはちょっと怖いかも…。
ただし、別に不安定だったりはせず。貧乏ゆすりしても画面が揺れたりしない感じ。
ディスプレイ
ディスプレイは、左上のものだけ昔から使っている21型ワイドのもので、残りは新規購入。23型の同じのを3枚購入。
最初は2枚でとどめるつもりだったものの、右上のアームがさみしそうだったので、ついうっかり。ほんとにうっかり。まあ、すごく満足していますが。
ディスプレイの購入基準は、アームが細めのやつということもあり、軽さ重視。フルHDで、LEDバックライトなもので、一番お手頃な感じのを見繕った結果、以下のものに。
値段に大差ないんで、全部 HDMI ありでもよかったかもと思いつつ、買ったのは1枚だけ HDMI なし。
DisplayPort対応の奴だとマルチディスプレイ化が楽らしいけども、お手頃価格のものが見つからなかったので断念。
アームに取り付ける際に思ったのは、やっぱり軽いタイプ（3.8kg）を買って正解。10kgまで付けれるとかいっても、10kgのものを抱えつつねじ止めとかできる気がしない…（特に上部アーム。）
とはいえ、LED じゃなければ数千円安い奴（4.9kg）もあるので、どっちが良かったかは悩むところ。
グラフィック ボード
ディスプレイがあっても、グラボが対応していないことには4画面化できないわけですが。
いやー、もちろん、グラボ1枚で6画面とかやってみたいですよね！（今回はやってませんが）まあ、こっちでもよかったかもなぁ、今思えば。
PCI Express (x16) なボードを2枚させる PC なら楽そうなんですけどもね、増設。うちの PC は1ポートしかないので断念。で、PCI Express (x1) にさせるボードは安めのものがなかったので断念。
結局、USB の外付けディスプレイ アダプターを2つ購入。
外付けアダプターだと、結構 CPU レンダリングしちゃうんで、常時 CPU に負荷がかかります。うちの場合、結構 CPU パワーが余っていたのと、上画面でそんなに重たい描画することもないので全然平気（エコ的な意味では嫌な感じですが）。3D ゲームなんかをすると悲惨らしいですけども、ニコ動を見る程度なら問題なさげです。
ただ、面白半分で、4画面全体に Visual Studio とか Word を拡大しようとしたら悲惨でした。2秒に1回（0.5 FPS）の描画くらいに。良い子のみんなは 3840×2160（フルHD 縦横2倍）でVisual Studio 使おうなんて考えないでしょうから、問題ないと思いますが。
周辺整理
さて、機器を増やすと問題になるのがケーブル類なわけですが。快適引きこもり4画面ライフを充実させるためにはケーブル整理が必須です。
電源周り
まず電源。こんな具合。
使っているのは、以下のもの。
ケーブル4本くらいであれば余裕。スピーカーのケーブルもまとめたかったものの、長さが合わなくて泣く泣く断念。
4本もまとまってると、「3本の矢」的な強さがあって、多少足で蹴ってしまうくらうではびくともせず。そういう意味でも、まとめておいた方が安心かも。
ディスプレイ裏
ディスプレイ-PC本体間も大概。こちらでも整理チューブが大活躍。
あと、買ったディスプレイは軽い代わりにアダプターが外付けなので、少々隠蔽工作。
以下の結束バンドでアームに巻き付けていたり。この結束バンド、今回のディスプレイの背面に限らず部屋中で使ってて、普段から重宝しています。非常に使いやすい。
キーボード周り
アームのせいで、多少、ディスプレイが手前に来てしまうので、机のスペースが減るなぁなどと悩み、キーボード トレイを購入。
ディスプレイ前の空間は、贅沢に「今日の TODO」を付箋紙に書いて貼り付けてるという使い方をしています。
もちろん、キーボードもマウスもワイヤレス。なぜか、気が付けばキーボードもマウスも複数持ってて余ってたりするんですが…
あと、おまけで、電子小物類の充電も↓こんな感じ。
RX 6/5リリース、Babylon.Toolkit 1.0.4、等々
- Reactive Extensions 6/5/2011 release available
- 見た感じ、そんなに大きな変更はなさそう
- Babylon.Toolkit 1.0.4
- 新機能: Cartoon Effect とか、パーティクルへの対応とか
- Silverlight 5 の素の 3D 機能はあまりにも基本機能過ぎて使うの大変な中、このツールキット使うとかなり楽になりそうなわけですが
- NuGet でもダウンロードできるみたいだし、素敵過ぎる
- Introducing LINQ to HPC: Processing Big Data on Windows
- David Chappel による LINQ to HPC に関する白書
- Windows HPC Server、DSC（分散ストア カタログ）とか、LINQ to HPC とか、全体像含めて解説
- Dryad と呼ばれてた頃、Bing のデータ解析とか、Kinect の研究（モーション解析）に使われてたとか
- David Chappell 執筆 OData のホワイトペーパー公開
- そしてこっちも David Chappel
- Microsoft Research Virtualizes Idle Desktops to Save Power
- 仮想化技術で省電力化という研究
- 普段はデスクトップでマシンパワーをフルに使って作業、スリープ時に仮想マシンサーバーにイメージ送ってそっちで稼働し続ける
- ネットワークとかも切れず、処理も動き続ける
- スリープから復帰時には、まず仮想マシンにリモートデスクトップ接続、その後、同期を取ってから物理マシン動作に切り替え、というのをユーザーが気付かないようなバックで行う
- これ、いいなぁ。どんなに仮想化が進んでも、なんだかんだ言って、ローカルの物理マシンのパフォーマンスはフルに使いたいし
- Visual Studio Load Test Virtual User Pack 2010
- goal-based のテスト シナリオ
- 負荷に対する要件とか、ゴールをきっちり決めてないとグダりがちだし
- TouchStudio updated to 1.2
- ゲームと物理演算エンジン搭載したって
- Parallel programming coding guidelines
- 並列処理考える前に一通り目を通しておきたい
- Excel-DNA
- .NET で Excel 操作（DLL 提供も、ソースコード提供も可能）
- 中身まで追って見てないけども、Visual Studio 標準の Office ソリューションより楽なのかな？
C# to JavaScript
また、C# から JavaScript 生成する類の環境がホットなようで:
- JSIL
- そして、XNA のゲームを JavaScript（＋ HTML5 の Canvas）化
- 意外とスムーズに動作
- 最近、Script# の入門記事がまた出てたり: Getting started with Script#
- MIX11 でもセッションがあったし: Script#: Compiling C# to JavaScript using Visual Studio
プログラミング言語の簡単さ/むずかしさ
Scala をディスると PV が増えると聞いて。Scala、難しいよね（棒読み）。
そういう冗談さておき。プログラミング言語が簡単/難しいって何だろう。
How vs. What
C# もよく言われるんですよね、「C# は簡単だ」というのも、「C# は難しい」というのも両方。で、よくよく話を聞いてみると、だいたい以下のような感じ:
- C# は文法が多い。概念覚えるのが大変だから難しい。
- C# はやりたいことをやれるから簡単。
文法の簡単さ
「プログラミング言語マスター ＝ 文法を覚える」だというなら LISP でも使ってなさいってば。あの言語、超簡単ですよ。() の中にトークン並べるっての以外に何も文法持ってないから。
こういう意見って、要するに、How（どう書くか）ベースの簡単さなんですよね。
やりたいことをやる簡単さ
プログラミングって手段であっても目的ではないわけで。What（何をしたいか）ありきだと思うわけです。
さて、そうなると、プログラミング言語の文法が少なければ簡単かというと、if とか for とかを書くのがあなたの目的ですか、と。
というか、この意味でいうと、「簡単さ」という言葉に占めるプログラミング言語文法の割合なんて大したことはなくて、ほとんど、ライブラリとかフレームワークの方に依存するのではないかと。
文法なんて、覚えることも少なければ、ここ数十年での進歩の度合いも大したことはないです。C# みたいに、たった10年でずいぶんと進歩した言語でみても、フレームワークやライブラリの方の追加・進歩と比べると大したことはない。
理不尽な難しさ
「難しさ」にも、必要に迫られてどうしようもない必要悪的なものと、意味もなく単に難しい理不尽なものとあるわけで。
と言っても、好き好んで理不尽な難しさを導入しようなんて人は、通常、いないわけで。ネタ言語ならともかく、少なくとも実用を目指すものならば。
理不尽な難しさって、だいたいは歴史的背景に起因するか、思慮が足りなかったかのどちらかで。
歴史的背景
まあ、できた当時の事情を考えればしょうがない。どうしようもないものの…
C++ の理不尽の大半は、歴史的にどうしようもないものが多く。
C#、たった10年しかたってないこの言語ですら、もはや黒歴史と言っていいものもあり。
特に、古い文書はいつまでも残る
今はさすがにもうって感じですが、C 言語って、長らく K&R の呪いみたいなものに悩まされ続けてたり。ANSI 標準化前の初版のスタイルで C 言語を覚える人が続出してしまったという。
そんなに頻繁に更新のなかった C ですらそんなので、まして、発表から10年、正式リリースから8年にしてバージョン 4.0 の C# なんてもう。ほんの少し昔に自分で書いた説明ですら「あっ、古い。このコードまねないで。」と思いつつも、直す時間取れない/メディアの都合でそう簡単に直せないものがどれだけあるかっていう。
思慮の足りなさ
だいたい、問題は後からでてくるもので。
これに対する解決策は、十分な試用期間を設けて、十分な人数で使ってみて問題を洗い出すこと。
となると、Java とか C# みたいに最初から企業の後ろ盾のあるものはともかくとして、個人ベースの開発から始まって、徐々にコミュニティが成熟してきたような言語は何かしらカオスを抱えてしまうもので。
個人的には、Scala にもやっぱりこの手の理不尽が少々あると思っています。
簡単さ/難しさ の要因
もちろん、ライブラリの充実、言語機能の充実。そして、前述の「理不尽」が少ないかなどもありますが、その他にも。
検索性
ライブラリやらフレームワークやらの挙動まで含めれば、プログラミング言語のすべてを覚えきれる人なんてほとんどいないわけで。ソフトウェアに求められる要望も多ければ、言語やライブラリが持つ機能も膨大な今、大事なのは機能の探しやすさではないかと。
目次検索
膨大な数の機能を、名前空間（パッケージ）とかクラスで分類・整理できた方が「簡単」だと思います。
「書くのが楽だから」とか「クラスって概念を教えなくてもいいから」って理由で、標準ライブラリをグローバル関数だらけにしてしまうと、検索性で非常に困ることになるかと。IntelliSense とかのコード補完機能で、補完候補が100個くらい出て来るともう、それは補完の価値半減。
検索エンジン
検索エンジンでの検索性でいうと、記号をやたらと使う言語は不利ですね。
その点、関数型言語というか、エンジニアじゃなくて数学者に媚びた感じの言語はつらいというか。
一貫性
他の文法との
文法が一貫してないことってそうないというか、一貫してないのは前述の「理不尽」にあたるはずですけども。
他のライブラリとの
まあ、新しいライブラリを使い始める際、使ったことのある既存のライブラリとの類推を求めるもので。
この辺り、標準ライブラリが強ければそれに合わせるサードパーティが多くなるとか、言語機能が充実していれば独自にデザインパターンの亜種実装しなくていいとかあり。
C# の楽さはこういうところにあると思う。snake_case, camelCase, PascalCase が混在すること少ないし、イベントハンドラーの登録口は普通eventになってるし。
他の言語との
例えば、.NET 言語なら、今となっては、「匿名メソッドとか作ったら Action か Func になる」というのを期待しちゃうんですよね。それが標準だから。でも、これが、F# だとそうならない。FSharpFunc とかいうクラスになる。
カリー化の都合とかだとは思うんですけど、こういう細かい独自路線が、「他の .NET 言語からの流入」を結構妨げてると思うんですよねぇ。
必要十分性
機能は多ければいいかというとそうでもなく。理想をいうと、目的に応じて、目的を達成するのに必要十分な量が一番簡単なわけですが。
この辺り、目的を絞れない汎用言語は不利。かといって、いちいち目的特化型の言語（DSL）を作ると、いちいち文法を覚える手間もかかるわけで。
結局、汎用言語＋DSL の混在開発を目指してみるか、せいぜい目的ごとに名前空間をきっちり分類して検索性を上げるかくらいしか手の打ちようもなさそうな。
注意点
目先の簡単さ
世の中、「短期的に見ると簡単なんだけど、長期的には負債にしかならない」っていう罠だらけ。
そりゃ、setter/getter 書くよりも、フィールドを public にしちゃう方が楽よ。その場は。
そりゃ、デフォルト引数とかあると、オーバーロード書かなくて済むから楽よ。バージョニングの問題さえなければ。
そりゃ、イテレーターとか書くよりも、入力・加工・出力を全部1つのループの中で書く方が楽よ。後々、ループの規模がでかくならなければ。
パット見の簡単さ
概念も難しくない、書くのも簡単。でも、絶対はまるなんてものも。
例えば非同期処理、特に同時実行制御（ロックとか）なんかがその最たるもので。意外と、同期コードって単純に見えるんですよね。コード上は。
でも、同時実行制御の本当のヤバさはテストにあって。100万回に1回しかでないバグとかざらで、どうやってテストしろと。チェックインのたびに100万回テスト走らせるの？確率論的に「100万回に1回」なとき、1,000万回走らせても出ないときはでないよ？
慣れによる楽さ
自分は C で覚えたから C にある機能に近いことだけ覚えるのが楽。諸先輩がみんな C だから、新人も C 教えるのが楽。そういう楽さはあるのでなんとも。
そしてレガシー化。
「プログラミング .NET Framework 第3版」勉強会資料
6/5日の「プログラミング .NET Framework 第3版」がテーマの勉強会、僕の分の資料を置いておきます。
ちなみに今回、勉強会の内容はアーカイブ配信もされています:
地震で延期したことによって間が空いてしまい、その間にちらほら足していったらすごいページ数になってしまったという。6/5の発表では半分くらい非表示にしてカットしたり（カットしたページの一部はSilverlightを囲む会 in東京 ＃2 での発表に使っています）。
スライド中でも書いていますが、第3版で追加された第5部「スレッド処理」は、.NET Frameworkに関係なく、Windowsで非同期処理/並列処理するなら読んでおいて損はないかと。
Windows 8 のデモ動画が出てきたそうで
なんか、Windows 8（コードネーム）の話でもちきりな感じですが。
- Previewing ‘Windows 8’
- Windows 8: Build 7985 shown in demos
- [Windows 8] 2011年から PDC は BUILD に名称変更。メインは Windows 8？
- Windows 8のビデオ
- Windows 8の画面を初公開、タッチ操作前提に生まれ変わり
ちらほらと、伝言ゲーム的に噂が独り歩きして、「Win8アプリはHTML5 + JavaScritで書く」みたいな変なことまで言われてますけども… それは言い過ぎ感が。
現状、まあ、推測しかしようがないわけですが、常識的に想像するなら以下のような感じではないかと思うんですが…
HTML5 + JavaScript
Metro UIベースのタブレットということもあって、ブラウザーというアプリの枠は取っ払って HTML ページが全画面表示されるっぽい（というところまでは発表にあり）。
ということで、「Win8 特化アプリと HTML ベースのアプリの区別がパッと見つかないよ」程度の話ではないかなぁと。せいぜい…
- HTML5 でも GPU アクセラレーションをフルに使えるよ
- （過去に、そのことを指して「HTML5 をネイティブ化」とかいう表現して、各所から「はぁ？」的な反応されてましたし）
- 今の IE9 の、固定サイトとかジャンプリスト的なノリで、Live Tile（Metro UI 風のスタート画面）を操作できる
- 今の延長だとすると、<meta>タグと、JavaScript の関数いくつかで対応になりそう
かな。
2ch でも言われてましたけど、正直、HTML on Desktop 的なノリ（Active Desktop とかサイドバー ガジェットとか）だと絶対受けない。「標準的な HTML ページ＋簡単な<meta>タグ追加するだけで、Win8 アプリっぽく見えるサイトになるよ」ってところではないんですかねぇ。
Silverlight
最近、なんかもう、ちょっと Silverlight よりも HTML5 の話の方が前に来ただけで「Silverlight オワタ」とか言い出す人が… だいたい、開発者向けじゃない発表の場で Sivlerlight の名前出したってしょうがないから出さないだけなことも多いのに。
で、↓こんな話もあるくらいなので、
Win8 特化な API は今の WPF とか Silverlight がベースなのではないかなぁ。
Windows Phone 7 のノリと一緒で、「クロスプラットフォーム重視なら HTML5 で書け、特定プラットフォームに最適化してリッチにしたかったら Silverlight 使え」ってのが、まんま Win8 でも適用されるだけな気が。
前節の通り（HTML5 の普通のページがデスクトップ アプリと区別つかない状態で見える）だとすれば、なおのこと。標準⇔表現力のトレードオフがより鮮明になることは確かですが。
クラウディア窓辺
まあ、コラボっとかないとね。
http://www.pixiv.net/member_illust.php?mode=medium&illust_id=19324454
クラウディアさん（左側）に関しては 、© 2011 Microsoft Corp. All Rights Reserved.
++C++; // 未確認飛行 C ブログ 