20141129-dotNet2015
Your SlideShare is downloading.
×
Check these out next
More Related Content
Slideshows for you (20)
Viewers also liked (20)
Similar to 今から始める、Windows 10＆新.NETへの移行戦略 (20)
More from 信之 岩永 (16)
Recently uploaded (20)
今から始める、Windows 10＆新.NETへの移行戦略
- 1. 今から始める、Windows 10＆新 .NETへの移行戦略 岩永信之
- 2. 本日のテーマ Windows 10 & .NET 2015を見据えて 今すぐに対応できること .NET 2015までに準備すべきこと おすすめの開発指針
- 3. まずなによりも、業務系において .NETは「変えないこと」の大切さをわかってる 既存のアプリ 既存の.NET (.NET 4.5) 既存の.NETで動いてたなら だいたい※動く .NET vNext (.NET Core 5) • 事前Native化 • SIMD演算対応 • モジュール化 • ソースコード配置 既存の.NETの 延長 (.NET 4.6) .NET 2015世代の新機能 はランタイムの内部で 頑張ってるものが多い • アプリの変更少なく • アプリの適用範囲が広がる ※ ReflectionとかInteropとかで変なことしていなければほぼ
- 4. あらためて、本日のテーマ Windows 10 & .NET 2015を見据えて 今すぐに対応できること .NET 2015までに準備すべきこと おすすめの開発指針 割と、 「何かやることあったっけ？」 と言いたいレベル • Microsoftの組織変化 • .NETチームの開発体制変化 .NETを使う側も参考にすべき指針に
- 5. キーワード “One .NET” Open Every developers Cloud
- 6. 互換性 本題の前に、どう「変わってないか」の話を 「変えないこと」の大切さをわかってる
- 7. .NET Frameworkと.NET Core .NET 2015 .NET Framework ASP.NET 5 ASP.NET 4.6 WPF Windows Forms .NET Core ASP.NET 5 .NET Native Innovation • モジュール化 • オープンソース • Agileリリース • エコシステム • クロスプラットフォーム ASP.NET 5 for Mac and Linux Common Runtime Next gen JIT SIMD Compilers .NET Compiler Platform Language innovation NuGet packages .NET Core 5 Libraries .NET Framework 4.6 Libraries Compatibility • 既存デスクトップ • 既存サーバー ポイント 既存のものには下 手に手を入れない ポイント 既存環境にも最新の アプリ開発モデルをポイント 可能な限り旧環境にも オープンソースの成果を pull-req 受付 back porting とはいえ、4.6どころか…
- 8. .NETのサポートOS OS サポート期限.NETのバージョン Windows Server 2003 2010/7/13 2.0 R2 2015/7/14 4 Windows 7 / Windows Server 2008 R2 2015/1/13 2020/1/14 3.5.1 4.6 Windows 8 / Windows Server 2012 2018/1/9 2023/1/10 4.5 4.6 上段: メインストリーム 下段: 延長 現実的に多そう なのはこいつ？ 上段: 標準インストール 下段: サポートする最新バージョン 業務におかれましては、サポート期限ギリギリのOSで、標準 インストールのバージョンの.NETでないと使えないことも 多々あるかと思われます
- 9. VS 2015でも、2.0, 3.5開発できます 古いバージョンのVisual Studioとの共存も可能 今はクライアントOSでもHyper-V動くし 実機開発でも、Visual Studio 2015はWindows 7に入る 「Windows 7だからVisual Studio 2008で開発」とかやめて
- 10. .NET 2.0でもC# 6.0使えます C# 6.0 Getter-only auto-property Expression bodied function Using static Null-conditional operators String interpolation nameof Index initializers Exception filters Await in catch/finally 割と単純な構文糖衣ばっかり ライブラリ依存の機能なし .NET 2.0で動く .NET 4.5で動く 「Windows 7だからC# 3.0」とかやめて
- 11. 統制 統制取りたいから新機能使わせたくないって？ Privateな部分にうるさく言ってもしょうがない C# 6.0が影響するのはprivateなところばかり int X(int x) { return x * x; } メソッドの外から見えてる情報 はここだけ(変わってない) ここがレビューしにくいなら、何か別の問題あり メソッド1個1個が大きすぎるとか 変数名がちゃんとついてないとか int X(int x) => x * x;
- 12. まとめ 既存のものは下手に触らず、新しい試み 古い環境向けのアプリも、最新のC#, .NET, Visual Studioで
- 13. “One .NET” 「縦割り」の改善 1つのエコシステム
- 14. “One” 今年に入ってから、“One”(1つになろう)を標語にしてる “One Microsoft” 縦割り組織の改善 PC向けOSとモバイル向けOSで社内で争ってる場合じゃない 1つのOSコアに 1つの開発モデルに 1つのストアに .NETも“One .NET”
- 15. “One .NET” 以前(.NET Framework) 現状: Profileベースのフレームワーク .NET for Windows Desktop .NET for Windows Store .NET for Server BCL※ Runtime BCL WinRT Interop BCL Runtime Runtime • ターゲットごとに違うフレーム ワーク(大きな赤枠)があって • 「どのフレームワークならどの クラスが使える」みたいなルー ル(Profile)を定めてる • 1つのインストーラーで全体の インストール • 多くのクラスがmscorlib.dllの中 WPF ASP.NET ※ Base Class Library
- 16. 問題: Profileの種類 現状はまだそこまで多重保守になってない Desktop = Server Store = Desktopのものに小細工して使ってる でも、これから .NET Native, Cloud-optimized .NET Xamarinとももっと協業して、Mac, Linux, iOS, Android • (小細工でなく真に) 違うものになるかもしれない • バリエーションも増える • しかも、あとからどんどん追加で増える可能性も
- 17. 問題: 全体をまとめて アップデートが大変 mscorlib 例えば: System.Xmlに脆弱性が 見つかりました！ 全部のアプリがSystem.Xml使ってるわけじゃないけど • 直接はもう使わないのに… • 間接的にも使ってない確証得られない… mscorlibを使っていることには違いないし • バージョンアップしなきゃ！ • テスト全部やり直し！ • 多大な工数が！
- 18. “One .NET” (.NET Core) .NET Core 5 Windows Desktop Windows Store Server WinRT Interop WPF ASP.NET パッケージ管理 (Ecosystem) BCL Runtime Xamarin .iOS Xamarin .Android … • 細かい単位に分けて、NuGetベース で必要な分だけ、必要なバージョ ンを参照 • 利用者がプラットフォーム選択で あれこれ悩む必要ない • NuGetパッケージの仕 組みを拡大 • BCLとNuGetパッケージ とプロジェクトを区別 しない • 実行環境自体もパッケージ管理の 仕組みを使ってside-by-side配布 one modularity agile in control 目標: 1つのエコシステムの上で、必要とされる部分を、素早く、制御可能な形で提供
- 19. “One .NET” になることで .NETを利用する側として覚えておくといいのは ターゲット指定の改善 ライブラリ参照管理の改善 パッケージ単位のコード解析・補完
- 20. ターゲット指定(旧): Profile選択ベース Portable Class Library: ターゲットを自分で選ぶ 共通部分 共通部分 これだけ使える ターゲットを増やすと 使える部分が減る
- 21. ターゲット指定(新): 依存関係ベース パッケージ管理: 何に依存しているかでターゲットが決まる System.Runtime System.Collections.Generic System.Linq System.Net.Http System.Threading.Tasks Microsoft.Win32.Registry My App 1 My App 2 どこでもは使えなさそうな ものを参照すると… ターゲットに制限がかかる ターゲット指定は1st パーティ製ライブラリだけがやればよくなるはず
- 22. ライブラリ参照(旧): .csprojプロジェクト形式 参照管理の仕組みがバラバラ BCL参照プロジェクト参照 .csproj内NuGetパッケージ参照 <Reference/>タグ .csproj内 <ProjectReference/> タグ packages.config + .csproj 内 <Reference/>タグ
- 23. ライブラリ参照(新): .kprojプロジェクト形式 JSON (project.json)でプロジェクト設定を管理※ "dependencies": { "Newtonsoft.Json": "", "System.Console": "", "Classlibrary1": "" NuGetパッケージ参照 BCLアセンブリ参照 .sln内プロジェクト参照 } "4.0.0-beta-22231", (必要ならバージョン を明示的に指定) ※ 補完が効くし、ツールチップヒントも出る GUIでの参照設定もちゃんとできる
- 24. 区別がなくなることで 例えばこんな開発フローが 1. 作ったアプリの中から共通利用できそうなところ抜き出す 2. 別プロジェクト化 3. それをNuGetパッケージ化して配布 4. 他のプロジェクトでMyGet越しでパッケージ参照 5. 他のプロジェクトからソースコードに手を入れる必要でてきたら git cloneしてプロジェクト参照 プロジェクト→ NuGetパッケージ化 NuGetパッケージ参照→ プロジェクト参照
- 25. パッケージ単位のコード解析・補完 今までの問題: 文脈読まずにコード補完 例: コードスニペット 依存関係プロパティ • XAML系プロジェクト • プロパティが書ける文脈でしか使わないのに これから: パッケージ単位で配布可能 .NET Compiler Platformを使って作ったコード解析をNuGet配布 ライブラリにコード解析を同梱可能 例えば… JSONライブラリに、文字列リテラル中のJSON解析を付ける 常に出る
- 26. パッケージ単位のコード解析・補完 NuGet配布の例 自作のコード解析 自作のコード解析 が参照されてる コード解析が結果 (警告+ 書き替え)
- 27. まとめ 全部入りインストーラー→ 個別パッケージ配布に 制御可能な形で、素早く提供 「パッケージ化」を意識した開発を
- 28. Open Source .NET全体のオープンソース化
- 29. .NETのオープンソース化 .NET全体をオープンソース化※ .NET Home : 各プロジェクトへのリンクとドキュメント .NET Core 以前からオープンだったもの .NET Compiler Platform ASP.NET Entity Framework コミュニティプロジェクトへのリンクも Mono Project JSON.NET … ※ といってもまだ途中。随時公開中
- 30. オープンソース化の理由 クロスプラットフォームを維持可能な形で実現 コミュニティの活性化 新しい顧客の取り込み 既存顧客にとってもコミュニティが広がることはメリット 「Linuxで動かせるなら.NETをもっと活かせる」という要望は多い
- 31. もちろんビジネス構造の変化もあって Windowsの会社→ Azureの会社 Azureのデータセンターを使っていただけるなら、その上のOSは WindowsでもLinuxでも パッケージ売り→ サービス売り Offide 365, Share Point, Dynamicsなどや、Azure上の各種サービスを使って いただけるなら、クライアントはiOSでもAndroidでも Visual Studio Online VS Onlineを使っていただけるなら、クライアントはEclipseでもSublimeで も
- 32. 日本の業務系でも: 大手にとっても 社内フレームワークが足かせになってはいないか 同じような機能ならオープンなものに勝てない 「オープンだから使ったことある」って人の調達と、1から社内フレー ムワークを覚えてもらうのと、どっちがコスト低いか ググって出てこないものを使えない人 自社で作ったものもOpenな方が外注調達コスト下がってトータルで見 てお得になるかも
- 33. 日本の業務系でも: 開発者個人にとっても 自分自身の身元保証 開発者求人とか、とりあえず「コード見せろ」 中小だと法人でも同様、身元保証 聞いたこともないような会社、中身見えなくて誰が応募するのか
- 34. 業務系でも現実的なレベルになってきた Control 頻繁に更新されると動作保証ができない → バージョン管理で「変えない」こともできる Governance 誰がコードの責任を持つの？ → 統制自体はマイクロソフト、.NETチームが責任持ってやってる Discoverability 身元のはっきりしないコードは使えない → どこの製品かまで含めて検索できる こういうソースコード管理、 パッケージ管理、開発工程管理 の仕組みがだいぶ充実してきた
- 35. まとめ オープンソース化 信用の獲得 コミュニティの活性化 いろいろあったオープン化の課題は技術で解決されつつある オープン化前提で成り立つビジネスモデルに移行
- 36. Every developers Every applications .NETをすべての開発者に
- 37. 多様なアプリケーション .NETは元々適用範囲広いし Server Client On-premise Cloud Web Site Web Service HTTP Sockets GUI CUI Stand Alone Connected Desktop Mobile Mouse Keyboard Touch Windows Linux iOS Mac Android .NET Micro Framework 「AかBか？」→ 「AもBも！」 、これからさらに広がる
- 38. 過渡期 一度大きく振らないと行けないことはある A B 新しいチャレンジの際の過渡期 最終的には間に落ち着いたり、両方半々になったり A AB B A & B 成熟の証 結局、全部ほしくなる この状態に対して 「既存顧客を捨てるのか」とか 「そんなの流行らない」とか 言っちゃダメ 「ほらダメだった」とか 「やっぱり戻ってきた」とか 言っちゃダメ
- 39. Windows 8 → 10 Windows 10 デスクトップ回帰 エンタープライズ回帰 Mouse Keyboard Touch 制限なしWPF 審査付き セキュアWinRT エンタープライズ コンシューマー WinRT Windows 10 Windows 10 Windows 8 Windows 8
- 40. 今はターゲットを広げる時期 協業 Xamarin, Docker サポートOS Linux, Mac Android, iOS(Xamarin) Web Server IIS 開発環境 Visual Studio, Xamarin Studio, OmniSharp
- 41. 選べる大事さ: 開発環境 Windows環境 これからもVisual Studioは非常に強力な開発ツール Visual Studio Communityエディション 非商用、学術・研究向け、オープンソースへの貢献用途には無料提供 非Windows環境 Xamarin Studio そもそもIDEみたいな仰々しい仕組みがいやなら OmniSharp - Cross platform .NET development Sublime, Emacs, Vimなど向けのC#プラグインを提供
- 42. 補足: Xamarin Studio VS側最近機能が結構使える※ NuGet Package manager Shared Project T4 template PCL (個人の経験で言うと) Visual Studio以外を全く想定してなくて 割かし最近の機能をふんだんに使って 仕事用のそこそこの規模のソリューションが 普通にMac上でのXamarin Studioでビルド通せた ちなみに、C# 6.0は、公式サイトで仕様が出てくるたびに即座に対応 Discussionに情報が出た数日内にはMonoに関連コミットがあったり ※ むしろLegacyな機能の方が怪しい… フルパス指定が必要だったり、 パス中の と/ で困ったり
- 43. 選べる大事さ: Runtime, Webサーバー ASP.NET 5は階層化、モジュール化された構造 いろいろ差し替え、選択できる Runtime (何で.NETコードを実行するか) .NET Core 5 .NET Framework 4.6 Mono Web サーバー(何でHTTPを受け付けるか) IIS (Helios) libuv (Kestrel) 自作(Self-host) Loader (ソースコードの読み込み) C#/VB (Roslyn Loader) 自作※ 非Windows ※ 例えば、F#サポート用のLoaderのサンプルあり
- 44. 選べる大事さ: OWIN※ Webサーバーとアプリケーション間のインターフェイス仕様 Func<IDictionary<string, object>, Task> 環境変数、リクエスト、レスポンスをDictionaryを使ってやり取り どのキーにどの値を入れるかを規格化† 非同期(Task) BCL提供の型しか使わない どこででも、何ででも動く • Webサーバーが何でもいいのはもちろん HTTPである必要すらない • アプリの下にミドルウェア挟むのも楽 ※ Open Web Interface for .NET † objectのままだと使いにくいので、適切なキーで適切な型でとりだせるラッパーライブラリあり(Microsoft.OWIN)
- 45. 補足: 依存を減らす フレームワーク、サーバー、OSへの依存を減らす (ASP.NET 5みたいな)差し替え可能なモジュール提供 (OWINみたいな)標準ライブラリのみへの依存 (MVC, MVVMなどの)分離しやすいアーキテクチャ Modelの比率を増やすよう頑張るべき 依存を減らすことで 幅広いプラットフォーム対応 変化への対応 依存を減らせる技術は 積極的に取り入れるべき しなきゃいけない？
- 46. 補足: 依存を減らす フレームワーク、サーバー、OSへの依存を減らす (ASP.NET 5みたいな)差し替え可能なモジュール提供 (OWINみたいな)標準ライブラリのみへの依存 (MVC, MVVMなどの)分離しやすいアーキテクチャ • 開発者は本音では新しいものを使いたい • できないのは、入れ替えのコストが高いから • そのコストが下がるのならば… Modelの比率を増やすよう頑張るべき 依存を減らすことで 幅広いプラットフォーム対応 変化への対応してもいい！
- 47. 補足: Taskクラス Taskクラス(await/async)は依存切りに使いやすい Model中心の設計、Modelの比率向上しやすい Model ※ StatelessなWebだとこういう処理にはなりにくいものの、 WebSocket使った双方向通信とかだと同じような処理あるはず Taskクラスなし(イベント駆動) UI Click Model 処理開始 User void OnClick(sender, args) View側からのClickイベントで処理を始める UI await 処理開始 User Task AwaitClick() Model側から Clickイベント待ちをする※ Taskクラス利用
- 48. まとめ 今はターゲットを広げる時期 レイヤー化、モジュール化、選べる大切さ パーツごとに差し替え可能な構成 変えたいときに、変えたい場所だけ変える
- 49. Cloud 自社の開発にもCloudを 自前で物理的なものを持たない世界
- 50. Connect()にて Connect()での発表のうち、結構な量がVisual Studio Onlineがらみ Release Management Service Application Insights Sneak Peak Web based editing Build service Code search
- 51. クラウド化 製品にCloudサービスを使うというのはもちろん 仮想マシンもAzure VMやAWSに置いたり PaaSを使ったり: SQL Database, Service Bus, HDInsight, Media Services, etc. 自分達のインフラもCloudに Visual Studio Online MyGet GitHub お客様への納品物はだいぶクラウド化したのに、 自分のことになると「医者の不摂生」してないか
- 52. Microsoft自身も 開発サービスを提供する側だけども Azure, Office 365 API, OneDrive API Visual Studio Online すべてを自社でまかなわない GitHubでソースコード公開 BCLパッケージ配布にMyGet※ を利用 エコシステム提供 3rd パーティ製サービスもAzure StoreのAdd-onsに並べられる ※ NuGetパッケージのホスティング、CIサービス
- 53. まとめ 自分達のインフラもクラウド化 医者の不摂生になっていないか すべては一社で完結させない 自社の得意のところは自社で そうでないところは外部と連携 Gitは避けて通れないかも Git間の履歴移植は楽らしいので、一度以降してしまえば次は楽かも
- 54. 全体まとめ “One .NET” パッケージ化、制御可能な形で個別に素早く提供 Open 信用の獲得、コミュニティの形成 Every developers 広いターゲット、変えたいときに変えたいモジュールだけ変える Cloud 自社の得意なところは自社で、そうでないところは外部と連携
