de:code 2018 振り返り

de:code 2018 振り返り福森拓⼤

⾃⼰紹介 .NET をどのように使ってきたのか主に使⽤している⾔語はVB.NET 業務向けのアプリケーションが多く、既存アプリの関係上、 Windows FormsやASP.NET Formを扱うことが多い周りにC#を使う⼈が少ないので、VB.NETを採⽤することが多く、必要な場⾯でのみ使⽤している。個⼈的にはC#で遊びたい
機械学習に興味がある。ハード⾯にもっと強くなりたいところ

de:code 2018 https://www.microsoft.com/ja-jp/events/decode/2018/ 今回で3回⽬の参加（2016から） 2018/5/22-23 聞いてきた内容 .NETの現在の状況機械学習確認したい内容 IoTのセキュリティ

⽬次 1. 現在の.NETの状況 2. どの技術を使⽤していけばよいのか 3. VB.NETの⽴ち位置 4. 機械学習について

1. 現在の.NETの状況各Frameworkについて .NET Standard .NET Core 3.0 Xamarin Blazor
ML.NET

各Frameworkについて .NET Framework Windows上で動作する。 .NET Core Windows、Mac、Linux上で動作する。ただし、.NET Core 3.0で実装予定のUWPは、Windows上でしか動かない。
Xamarin Windows、iOS、Android、Mac上で動作する。 .NET Standard .NET Standardは、各フレームワーク間の共通ライブラリの実装に使⽤する。

.NET Standard

.NET Frameworkの統⼀化 .NET Framework、.NET Core、Xamarinで、それぞれのAPIで実装レベルが異なるのが現状である。実際のアプリケーションでコードライブラリの共有化を⾏いたい、という要望があると思うが、それを実現するのが、.NET Standard あくまで仕様というのがポイント。すでに実装があるわけではない
イメージとしては、HTML5と同じ。 HTML5なら仕様があり、そこに各種ブラウザが実装していく。つまり、.NET Standrdという仕様があり、それに対して各 Frameworkが実装していくという考え⽅となる。

統⼀仕様の詳細共通のDLLは使⽤せず、基本的に各Frameworkで実装するというのが基本となる。しかし、Type Fowarding(型の転送)については、共通DLLを経由して⾏う。 .NETプラットフォーム間でコード、ライブラリ、開発スキルを共有できるのが利点ポータルクラスライブラリ（PCL）に代わる精選された共通APIセット
PCL:https://blog.ch3cooh.jp/entry/20140328/1396002120

.NET Core 2.1 6/1にリリース https://blogs.msdn.microsoft.com/dotnet/2018/05/30/announcing- net-core-2-1/ パフォーマンスは、SDKでもランタイムも改善している。ランタイムだけではなく、SDKも改善しているということで、開発時の効率改善も⾒込まれる。ラズパイもサポートしている。実装としては、ラズパイ上のDocker
コンテナで動くので、ラズパイ上で動作する.NET Coreベースのアプリケーションを作ることができる

Windows Compatibility Pack（Windows互換機能パック） Windows依存の機能も実装されている。Windows以外のプラットフォームでもビルドは通るし、動作する機能もある。⼀部はWindows 限定であり、APIが例外を起こす実際の実装時には If分岐で必要場所のみビルドされる。あちこちに記載する必要はあるが、#ifではなく、通常のif⽂のため、コンパイル引
数を与え忘れていたのでビルド不可という状況は起こらない。 if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))

.NET Core 3.0 2018年後半にはPreview版が出てくる。 Desktop Packs Desktop Packsが実装される。 Desktop Packsを追加することで、Windows
OSの.NET Core上で WPFのアプリケーションが動くことになる。 Microsoft ブログ https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3- and-support-for-windows-desktop-applications/

デスクトップアプリケーションで、なぜ.NET Core が必要となるのか Side by Sideで実⾏されるため、環境依存が少ない。 .NET Framework ライブラリのグローバル参照 or
ローカル参照を選択することができる。これはコンパイル時に選択することになる。最新のAPIは、.NET Coreに先に実装されるため、.NET Coreを使⽤することで、最新機能を利⽤しやすくなる

Xamarin Xamarin.FomrsがアップデートでCSSに対応 Android Emulator for Hyper-V 対応（⾼速化） Xamarin.Forms on the
Web Web Assemblyとしてコンパイルすることで、ブラウザ上で動作させることができるソース︓http://github.com/praeclarum/Ooui デモ︓http://ooui.mecha.parts/ 解説︓https://www.telerik.com/blogs/xamarin-forms-on-the-web

Blazor Browser + Razor = Blazor ブラウザ上に.NET実⾏環境ができたということ（UIフレームワークは提供していない）すべてのブラウザーで動作させることができ、Reactiveなどを知らなくても、.NETでクライアント側のWeb
UIをビルドすることができる。 Web Assemblyとして実装するため、ブラウザにプラグインなどは不要。クライアントとC#でのコードの共有、C#の強く型付けされた開発、.NETの安定性と⼀貫性を受けた開発が実現できる。

ブラウザ上での動作 Chromeの開発者ツールで確認すると、WebアプリケーションにDLL が配布されていることが確認できる。読み込み速度については、最近はJSも⼤きくなってきていることを考えると、誤差範囲になるのでは、と想定しているとのこと。クライアントのOSのNativeで動作するので速度的にも有利。実装としては、コンパイルされてブラウザー側で動いている形。将来的に期待していただければ、という⾔い⽅でした。ダウンロード︓https://blazor.net/

ML.NET Azureのモデルを使⽤するのではなく、.NETのアプリケーション⾃体で機械学習を⾏うには、今回開発されていくことが発表となった ML.NETを使⽤する。独⾃の学習モデルの作成、分析、判定。.NET のアプリケーションの中で、機械学習を使⽤できるようになる。現在は、ML.NET 0.1 (Preview)の状態だが、.NET
Core 3.0のころには、1.0に近いものが出てくると考えられている。

2. どの技術を使⽤していけばいいのかこの１年の.NET Core 新規なら、.NET Coreがいいかな、感新機能の実装 .NET Coreのほうがメインストリームに .NET
Frameworkの退役 .NET Frameworkから.NET Coreへの移⾏

この１年の.NET Core .NET Coreも⽣みの苦しみを抜けた状況となっている。どう⾒てもWindows⽤、Coreにいれるの︖な感じの互換パック Windows Compatibility Pack パフォーマンス、.NET Core
2.0、2.1にするだけで数割⾼速に C# 7.X活⽤する、細かい最適化多々ランタイムに⼿を⼊れないと実現無理な新機能の作業開始 C# のコンパイル上のトリックではなくて、.NETのコアに⼿を⼊れなければいけない機能についても、実装して来ている。

新規なら、.NET Coreがいいかな、感 .NET Core 1.0のころは、.NET Frameworkのサブセット感満載だった（機能が少ない）。しかし今は、新規なら、.NET Coreがいいかな、という状況になってきている。

新機能の実装新機能については、まずは、.NET Coreに実装している状況となっている。 .NET Frameworkへの実装は、.NET Coreから.NET Frameworkへの移植という形となるため、以下のような問題がある。 .NET
Frameworkに移植されるまでに時間がかかるパフォーマンスについては、問題が出てくる。.NET Coreのほうが早いという状況がありえる .NET FrameworkはSide by Sideではないので、環境依存となる

新機能の例 Utf8String インターネットで扱われている⽂字列はUTF-8だが、Windows上では、UTF16である状態を改善したい為の変更

.NET Coreのほうがメインストリームに今後は、.NET Coreの⽅がメインストリームとなる。 .NET Core 3.0 Desktops Packsで実装予定のGUIを使⽤したアプリケーションでも、.NET
Coreの恩恵（パフォーマンス向上、side by side インストール）などがある。１つ注意点としては、クロスプラットフォームだからといって、 Windows以外でWPFが使えるようになるわけではない。その⽬的ならば、Xamarinとなる。

.NET Frameworkの退役全機能がCoreに移った時がFrameworkの退役どき。とはいえ .NET Framework をやめたい、としてもシステムの利⽤者がいるかぎり、サポートは切れない。また、メインストリームから外れても、.NET Frameworkのサポートはちゃ
んと⾏なわれる .NET Coreで動かせる、としても無理に、移⾏する必要はない。スレッド周りの問題で、問題が起きる可能性が⾼い

.NET Frameworkから.NET Coreへの移⾏ .NET Frameworkから、.NET Coreについては、ターゲットフレームワークを変えるだけでビルドできる、という状態にしたい。 .NET Core 3.0では、Desktop
PacksでWinfows Forms、WPF、UWP が動作する予定 https://blogs.msdn.microsoft.com/dotnet/2018/05/07/net-core-3- and-support-for-windows-desktop-applications/ 実際、WPFのGUIを.NET Coreに持ってきてテストする、ということはしているが、⼤体動く。動くからといっても、スレッドの挙動の違いとかではまる可能性あり。たとえば、パフォーマンスを上げるとロックのタイミングが変わって破壊的変更につながる、ということはあり得る。

3. VB.NETの⽴ち位置⾔語戦略実装のタイミングやサポートプラットフォームに差をもたせる理由サポート内容

⾔語戦略将来の計画では、C#の設計からVBを切り離すことになる C#が似ているからといってそれを単に追加するのでなく、VB⾔語にふさわしいものを追加することになるこれは例えば、VB.NETで.NET Coreが使えなくなるというわけではない。同時に実装されるわけではないが.NET Coreでも徐々に実装されていく。PowerShellから以下のコマンドで確認可能 dotnet
new MicrosoftはVBを.NETのファーストクラス⾔語として扱い、引き続き新しい開発者を歓迎している

実装のタイミングやサポートプラットフォームに差をもたせる理由クロスプラットフォームのゲーム開発やMac OS Xを対象とする開発にはC#が適している。これは⾔語仕様によるものではなく、開発者がどれだけ引き寄せられているか、とそこからのフィードバックの差によるもの Microsoftには、広範なフィードバックを最も速く，最も多く獲得できるC#に注⼒したい意思がある。このフィードバックを通じて事例
が得られ、VB開発者にも価値があると思われた時点で，Microsoftは C#からの移植を検討する。

サポート内容品質ツールなどについて、今後も両⾔語に同等なサポートが提供される（Visual Studio 2017のライブユニットテストなど）プラットフォームに関して，今後も.NET Coreの.NET標準をサポート可能なメンテナンスが継続される。⾔語そのものに新機能やキーワードは加えられるものの，それはC# に追加されたという理由からではなく，VBの⽬的に適した場合のみ
に限られる。たとえば、前に述べたUTF-8⽂字列など

リソース The .NET Language Strategy https://blogs.msdn.microsoft.com/dotnet/2017/02/01/the-net- language-strategy/ Digging Deeper into
the Visual Basic Language Strategy https://blogs.msdn.microsoft.com/vbteam/2017/02/01/digging- deeper-into-the-visual-basic-language-strategy/ ⽇本語記事 https://www.infoq.com/jp/news/2017/03/vb-strategy https://www.infoq.com/jp/news/2017/02/strategic-net

4. 機械学習について機械学習のエンジン Azure Machine Learning Studio 必要なデータ量 GPUは正義

機械学習のエンジン Microsoftのセッションだったが、Keras(Tensor ow)を使⽤している事例が多かったオープンソースでサンプル豊富であること使⽤者数が多いため、最新の論⽂のアルゴリズムがすぐに実装される

Azure Machine Learning Workbench ローカルで実⾏することもできるし、クラウド上でも動かすこともできる。Tensor owの実⾏を⾏うこともできる。ファイル取り込みなどのコード作成も簡単に⾏えるデータを⾒ながら、データの取り込み、加⼯処理（抽出も）を⾏うことができる。途中でヒストグラム、データソースのジョインを表
⽰することもできる。参考︓https://qiita.com/yomatsum/items/3bacb6e4574c9f9b3d9c

必要なデータ量機械学習に必要な画像の数昔は100万枚。最近は1万枚程度でOK。状況によってはもうちょっと少なくても良い。（この枚数は、学習、検証、テスト合わせての枚数）枚数が少なくても済むようになった理由は、転移学習を使うことである

GPUは正義⾼性能なGPUは確かに値段が⾼いが、⼯数や⼯期などトータルで⾒るとコストはトントンではないか。やはりGPUを導⼊して早い⽅が良い

リソースレポート https://qiita.com/tfukumori GitHub(井上章⽒) セッション時サンプル https://github.com/chack411/VisualSearchApp-AD14-decode18

ご清聴ありがとうございました

de:code 2018 振り返り

de:code 2018 振り返り

tfukumori

Other Decks in Business

Featured

Transcript