Microsoft SWIT 2014でのJeffrey Richterのインタビュー

3月27〜28日に、 Microsoft SWIT 2014カンファレンスがキエフで開催されました。 2日以内に、開発者とIT管理者は、世界中のスピーカーからの多数のスピーチを見て、聞くことができました。



もちろん、最も重要な注目は、ジェフリー・リヒターの報告に引き付けられました。 ジェフリーは多くの開発者にとって素晴らしい権威であり、.NETテクノロジーの専門家であり、Wintellectの所有者です。 私は彼とのインタビューを行いました。Habrの読者からの質問のいくつかです。 私たちはほぼ1時間、興味のある人と話しました。Catへようこそ。



（このトピックを以前どこかで見たことがあるように思える場合は、いいえ、あるインタビューがありましたが 、これは別のインタビューです）。



こんにちは、ジェフリー。 私たちはあなたの本やプレゼンテーションの大ファンです。今ここに来てあなたと話すことができて光栄です。

ありがとう



私の名前はウラジミールです。C++で書いています。これは私の同僚で、.NET開発者のアレクサンダーです。 habrahabr.ruにもブログがあります。おそらくこのコミュニティについては聞いたことがないかもしれませんが、私たちには非常に人気があります。ロシア、ウクライナ、その他の国からの約100万人のIT専門家です。 1週間前、Microsoft SWIT会議への参加を発表し、人々に質問をするよう招待しました。 あなたの許可を得て、私は読者からの最も人気のある質問と、私自身からのいくつかの質問をします。

わかった



C＃言語と.NETプラットフォームが存在せず、現在の知識と経験をすべて備えたユーザーが、それらをゼロから開発するタスクを持っていると想像してみましょう。 それらを今のとおりに作成しますか？ おそらく、それらの何かが最初に不十分に行われたのでしょうか？ おそらく重要なものを追加したいですか？

もちろん、今日の.NETとC＃には、Microsoftと私が個人的に別々に実装したいものがあります。 13年前、世界は異なっていました。 私たちは現在、モバイル開発に注力しています。13年前、Webサービスに注力していました。 したがって、実行する価値があるのは、.NETをより「クリーン」で最小限に抑え、現在ほど多くのメモリを使用しないようにすることです。



結局のところ、.NET Micro Frameworkが存在します-これはそうではありませんか？

.NETプラットフォームを調べる方法はいくつかあります。 まず第一に、これはどの企業でも採用して実装できる標準のセットであり、これらの実装は標準に準拠している限り互換性があります。 Microsoft自体は、いくつかの.NET実装をサポートしています。

1.すべてのデスクトッププログラム、ASP.NET、Silverlightなどを搭載したサーバーを実行するクラシックバージョン

2. .NET Compact Framework

3. .NET Micro Framework



もちろん、最初の最も重要な実装は通常の.NETでしたが、「電話や時計はメモリがあまりなく、強力なプロセッサも搭載されていないデバイスはどうでしょうか」と考えました。 .NETを十分に機能させる方法がなかったため、「削除された」バージョンが登場しました。 今日、これらすべてを「ゼロから」書くことができれば、プラットフォーム全体の小さなコアであるCLRタイプのシステムとガベージコレクターを強調する価値があると思います。 これが基礎になるはずですが、他のすべてのものはすでに「プラグイン」のようなものでプラットフォームに接続できます。 たとえば、Reflectionはかなり要求の厳しいリソースであり、低速のテクノロジーですが、実際に多くのプログラムがReflectionを積極的に使用しているわけではありません。 たとえば、デスクトップバージョンの.NETにReflectionを残し、マイクロバージョンとコンパクトバージョンから削除できます。 したがって、プラットフォームのすべてのバージョンで同じコアが機能し、柔軟性が向上します。 また、プラグアンドプレイモデルによると、特定のプラットフォームの開発チームは既に、残りの機能を追加できます。 特定の機能が必要ですか？ わかりました、それを取り、追加します。 しかし、.NETはこのように設計されたことはありません。 もともとは、堅牢なモノリシックプラットフォームとして作成されました。



しかし、モノリシックなアプローチを使用すると、アプリケーションを作成できます。そして、それがどこでも機能することを確認してください。 そして、あなたが提案する「モジュラー」アプローチはどうですか？

アプリケーションは、それ自体がどの「モジュール」が動作する必要があるかを述べることができます。 最終的に、今日でも、.NET、.NET Micro Framework、および.NET Compact Frameworkで実際に動作する1つのアプリケーションを作成することはできません。 私が提案することは、実際にプラットフォームの柔軟性を高めます。



Windowsでのみ.NETをリリースおよびサポートするという、Microsoftの正しい決断だと思いますか？ Windows以外のプラットフォームでのMono、Xamarin、および.NETの一般的な将来についてどう思いますか？

これはいい質問です。 間違いなく、これはマイクロソフトの政治的決定でした。 13年前、ビルゲーツ、スティーブンバルマーなど、会社の最前線にいた者たちは、MicrosoftがWindowsオペレーティングシステムの販売で多額のお金を稼いでいると判断しました。 Windows専用の.NETのリリースは、この目的のための強力な動きでした。 今日の時点で、MicrosoftはWindowsが強力な競合相手（少なくともAndroidとiOS）を持っていることを明確に認識しており、それらはこれらのプラットフォームには表れていません。 さらに、ビル・ゲイツとスティーブ・バルマーはすでに退社しており、現代のマイクロソフトはよりオープンな企業になると思います。 Xamarinを信じますか？ 間違いなく。 人々は最終的に、すべてのプラットフォームに対して一度（少なくとも、ビジネスロジック）プログラムを書くことができます。 はい、各プラットフォームではアプリケーションの視覚部分を改良する必要がありますが、これはそれほど怖いことではありません。 一般に、Xamarinは.NETプラットフォームの推進に非常に優れていると思います。



さまざまなプラットフォームについて話すと、「QtまたはJavaを使用してどこでも動作する製品を作成できるのに、Windowsでしか動作しないアプリケーションを取得して.NETコードを記述する必要があるのか​​」と尋ねる人もいます。 これらの人々に何に答えることができますか？

各オペレーティングシステムには独自の特性があります。 オペレーティングシステムの重要な機能の1つは、インターフェイス、ユーザーインタラクション、直感性、使いやすさへのアプローチです。 Windowsの最新バージョンでは、これらのことに対する独自のビジョンを提供しています。たとえば、「ライブ」アプリケーションアイコンを便利に表示するタイルインターフェイスです。 スタート画面を開くだけで十分です。カレンダーのタスク、メールの文字の存在、友人からのメッセージをタイルで確認できます。 オペレーティングシステムに固有のこれらの要素を使用すると、アプリケーションが使いやすくなります。 .NETとWindowsランタイムを使用すると、ユニバーサルライブラリを使用するよりもこのようなインターフェイスを簡単に構築できるため、Microsoftは開発者の生活をより楽しくします。 さらに、たとえば、ユーザーがWindows 8のスタート画面を開き、アプリケーションのタイルが更新されたことに気付いた場合、アプリケーションを開いて何が変更されたかを確認したい場合があります。この時点で、有料サービスまたはショーを提供できます広告。 そして今、Windowsプラットフォームの機能のサポートがアプリケーションの収益化にどのように影響したかを見ることができます。

Windowsの新機能をサポートするという点では、Windowsランタイムが本当に好きです。 これは、想像できる最も近代的で「クリーン」で最もシンプルなAPIです。 たとえば、iOSのObjective-Cで書くよりもはるかに簡単です。 iOS向けのプログラミングは今日、より多くの利益をもたらすと主張するかもしれませんが、Microsoftは今日、モバイル市場を征服するためにあらゆることを行っています。 これは大きな戦いであり、始まったばかりです。



Windows Azureプラットフォーム（つい最近、Microsoft Azureと改名された）についてどう思いますか？ このプラットフォームの将来についてどう思いますか？ Azureに関する本を書く予定はありますか？

はい、Azureについての本を書くと言っています。 むしろ、Microsoft Azureストレージについて。 実際、Azureが登場したとき、私は彼を本当に信じていませんでした。 企業が他の人々のデータセンターにデータとサービスを配置する準備ができたときはまだ来ていないと思いました。 さらに、Microsoftにはパブリッククラウド製品に関する経験があまりありませんでした-はい、outlook.com、bing、およびその他の製品はその時点ですでに存在していましたが、Microsoftには大規模なパブリッククラウドがありませんでした。 しかし、彼らはそれをやった。 Azureの登場以来、Azureの信頼性、機能性は大幅に向上し、価格は下落しています。 Azureを使用している企業から新しい成功事例を聞きます。 現在、私の会社のWebサイトでさえAzureで実行されているため、考えたくないことをたくさん考える必要がありません。 Azureで私のお気に入りの部分はAzure Storageです。 各アプリケーションで最も重要なのはその状態です。 保存するデータ、ユーザーに表示するデータ。 これらはすべてどこかに保存する必要があります-このタスクは各開発者に関係します。 また、本を書くときは、Azure Storageを使用してデータ、キュー、テーブルを効率的に処理する方法、最小限のコストで効率的に行う方法について説明します。 これは大量の情報であり、Microsoftの公式ドキュメントや推奨事項にすべてが記載されているわけではありません。重要で興味深い詳細を強調できると思います。



通常の開発者は、Microsoft Azureが内部的にどのように機能するかを理解する必要があると思いますか？ ローカルファイルとサービスを使用して、この操作またはその操作に長時間かかったり失敗した理由を常に理解できます。デバッグツールとプロファイリングツールがあります。 Microsoft Azureで作業しているときに、何かがうまくいかなかったり、時間がかかりすぎたりした場合は、その理由しか推測できません。

まあ、Microsoft Azureサービスはインターネットを介して機能します。一般に、インターネットには、保証された配信速度とデータ処理の標準がありません。 パフォーマンスの問題は、デバイス、ソフトウェア、ルーター、プロバイダー、サーバー、またはそのソフトウェアに関連している可能性があります。 Microsoft Azureの内部に注目することはそれほど重要ではないと思います。 最終的には、ローカルで実行されている.NETアプリケーションでも、たとえば同じガベージコレクターの動作など、多くの隠された暗黙の動作があります。 それでも、多くの人がこのガベージコレクタを使用して、アプリケーションの速度を許容します。 オペレーティングシステム自体も「ブラックボックス」です-単純なファイル読み取り操作でも、多数の機能が呼び出され、OSとドライバーの内部カーネルコードが機能します-これらのシステムの実装の詳細はわかりませんが、自分に合った速度で機能しますが、使用します。 Microsoft Azureの場合：速度に満足したら、試してみてください。いいえ、別の何かを探してください。 このアプローチは私には普通のようです。 人々は、ますます複雑な問題を解決するために、ますます高レベルの抽象化を構築しています。



C＃およびVB.NETコンパイラ用のAPIを提供するRoslynプロジェクトに精通していますか？ このプロジェクトは単なるおもちゃ、または既存の言語を拡張し、重要な新製品を作成するための本当に強力なツールだと思いますか？ このプロジェクトの将来を信じていますか？

はい、このプロジェクトを知っています。 その作成には非常に長い時間がかかりました; Visual Studioの構成にはまだ含まれていませんが、今後数年でますます重要になります。 プロジェクトは複数のタスクを一度に実行します。 最初に、彼はC＃コンパイラ開発者にそれをC＃に書き直させました。 コンパイラをより速く開発できるようになったため、言語の新しい機能を導入する速度が向上します。 第二に、C＃のリファクタリングツールを作成するタスクが非常に簡単になりました。 マイクロソフトは、このような製品の多数の出現、それらの間の競争、および品質の向上を期待しています。 さらに、ある言語から別の言語へのコードトランスレータを作成できるようになりました。



将来、Roslynは常に最新バージョンのコンパイラをサポートし、C＃言語のすべての関連機能をサポートすると思いますか？

はい、もちろんです。 Roslynの開発時に、C＃の現在のバージョンのすべての機能が実装され、その後、新しいバージョンがリリースされました-C＃6の機能もRoslynに追加されました。 さらに、C＃言語コンパイラの開発は、ネイティブコードからC＃自体のコードに移行しました。これにより、Roslynへの新機能の統合も容易になります。



C ++プログラマーとして、C ++ / CLIおよびC ++ / CXについてのあなたの意見に興味があります。 これらのプロジェクトには、独立した統合言語またはその運命として、新しいマイクロソフトテクノロジとネイティブコードを使用する古いプロジェクトとの間の単なる橋渡しとなる将来があると思いますか？

C ++ / CLI-あまり成功していません。 どういうわけか、私はC＃に関する本をC ++ / CLIに適合させるよう提案されました。 プロジェクトは実施されませんでした-私たちはそれを望み、それを行うことができる人を見つけませんでした。 この言語は、Microsoftの奇妙な仕事でした...知りません... C ++ / CLIを主なプログラミング言語として使用している人に会ったことはありません。 C ++ / CXに関しては、その目的はCOMでの作業を簡素化することです。 COMは90年代に作成されたテクノロジーであり、このようなすべての参照カウント、インターフェイス変換などがどれほどひどいものであるかはご存じでしょう。 .NETが登場した理由の1つは、まさにこの遺産を取り除くことでした。 コンポーネントは優れていますが、プログラマではなくCLRがメモリの割り当てと解放の問題に対処できるようにします。 Windowsランタイムでは、Microsoftはネイティブコンポーネントに戻りました。C++ / CXは、これらのコンポーネントを.NETコンポーネントで作業するスタイルで透過的に作業する方法です。 C ++言語自体は変わりません。ComponentExtensions拡張機能は、COMを使用するという恐ろしさから私たちを救うだけです。



興味深い状況があります-マイクロソフト自体がネイティブ開発にC ++を非常に積極的に使用しています（最近のバージョンのWindowsの同じWindowsランタイムは.NETではなく、ネイティブコンポーネントの形式で記述されています）が、サードパーティの開発者にC ++の使用を推奨していませんが、 .NETおよびC＃を促進します。 なんで？

マイクロソフトは規模が大きいにもかかわらず、そのリソースはまだ限られています。 すべてを網羅することはできず、すべてのテクノロジーをサポートすることはできません。 それぞれについて、特定の決定が行われます。 開発の可能性は何ですか？ 会社は最終的にどのくらいのお金を稼ぎますか？」 明らかに、現在マイクロソフトの最優先事項は.NETとマネージコードです。 もちろん、C ++ / CLIとC ++ / CXの両方がサポートされ、バグは修正されますが、これらの製品のアクティブな開発に割り当てられるリソースは少なくなります。



.NET、C＃、Windowsランタイムなど、現在のMicrosoftテクノロジーのスタックの将来についてどう思いますか？ それらがどのように発展するか教えていただけますか？

私は間違いなく.NETとC＃が大好きです。 そして、私はこれだけではありません。 Windows 8のリリース後、これらのテクノロジーが登場した瞬間がありました...放棄されたとは言いませんが、その位置をいくらか失いました。 まず、Silverlightのストーリーを思い出してください。 これにより、.NETの明るい未来に対する信頼が損なわれました。 さらに、多くのプレゼンテーションと例から、Win8プログラムは主にJavascriptで作成されることが示されました。 .NETプログラマーはだまされたと感じました。.NETが現場を去ることは可能ですか？ 幸いなことに、Microsoftはそれをより適切に考えました。 これらのソリューションを推進した多くの人々はもはや舵取りをしておらず、WindowsストアのほとんどのアプリケーションはC＃で書かれています。 さらに、最近のカンファレンスの1つで（正確に覚えていない）、Microsoftは.NET仮想マシンに縛られることなく、C + +コンパイラ。 つまり C＃のパフォーマンスに関するスピーチは、これがネイティブコードではないという事実に依存しなくなりました。 このコンパイラは今後1〜2年でリリースされます。 したがって、私にとって、C＃は近い将来最高の開発技術のままです。



関数型言語、特にF＃についてどう思いますか？ 今日、これらの言語を実際のプロジェクトで使用することが適切だと思いますか？

通常、関数型言語は私のプロファイルではありません。 私はF＃についてほとんど書きませんでしたが、最近のバージョンのC＃がF＃で多くのアイデアを得たことを知っています-ラムダ関数、拡張メソッド。 そして、これらの本当に借りた機能は、私が毎日仕事で本当に使っています。 F＃には、C＃のようなサポート、人気、記事、および書籍はありません。 そのアプリケーションの考え方は、他の（非機能的な）プログラミング言語のすべての富がすでに不足しているときにのみ現れます。 しかし、個人的に、私はそのような状況に陥る必要はめったにありません。そうしなければならないとき、この機能がそのF＃でより簡単に記述および保守できるかどうかを評価することは困難です。 プログラマは、他の職業の人々と同様に、すでに慣れ親しんでいるツールを実践しようとします。 まったく新しい何かのために、非常に正当な理由がなければなりません。



今日、あなたの報告について質問したいと思います。 Windowsストアのアプリケーションのプロセスモデルについてお話しました。 各アプリケーションはサンドボックス内にあり、他のアプリケーションの影響から隔離され、ユーザーデータへのアクセスやシステムの損傷を許可しないと述べました。

はい、そうです。



同時に、このサンドボックスは、たとえばiOSのアプリケーションサンドボックスほど完璧ではありません。 Windowsオペレーティングシステムでは、Windowsストアのアプリケーションだけでなく、通常のデスクトップアプリケーションも機能します。 また、Windowsストアからアプリケーションプロセスにアクセスできます。それらを強制終了したり、呼び出しをインターセプトしたり、ユーザーデータを盗んだり、ユーザーに表示される情報を偽造してコードを挿入したりすることもできます。 そのようなモデルは安全ではないと思いますか？

実際、Windowsストアのアプリケーションプロセスはサンドボックスに存在しますが、デスクトップアプリケーションは存在しません。 これが、MicrosoftがOSの特別なバージョンであるWindows RTをリリースした理由の1つです。WindowsRTでは、通常のアプリケーションは動作しません。 これまで、このOSで実行されているデバイスは多数あり、現在では、完全に分離された正直なサンドボックスを提供しています。これは非常に重要です-マイクロソフトは、以前のすべてのオペレーティングシステムとのサポートおよび互換性の負担を初めて放棄できます。これにより、製品の信頼性、安全性、最新性を真に高めることができます。この製品の悪い点は、名前のマーケティングエラーです。オペレーティングシステムとしてWin RTがあり、このOSのデバイスとしてWin RTがあり、Windowsランタイムもあります。これもWin RTに縮小されています。しかし、これらはすべて完全に異なるものであり、人々は少し混乱します。