Slide 1
Slide 1 text
de:code 2018 振り返り
福森 拓⼤
Slide 2
Slide 2 text
⾃⼰紹介
.NET をどのように使ってきたのか
主に使⽤している⾔語はVB.NET
業務向けのアプリケーションが多く、既存アプリの関係上、
Windows FormsやASP.NET Formを扱うことが多い
周りにC#を使う⼈が少ないので、VB.NETを採⽤することが多
く、必要な場⾯でのみ使⽤している。個⼈的にはC#で遊びたい
機械学習に興味がある。ハード⾯にもっと強くなりたいところ
Slide 3
Slide 3 text
de:code 2018
https://www.microsoft.com/ja-jp/events/decode/2018/
今回で3回⽬の参加（2016から）
2018/5/22-23
聞いてきた内容
.NETの現在の状況
機械学習
確認したい内容
IoTのセキュリティ
Slide 4
Slide 4 text
⽬次
1. 現在の.NETの状況
2. どの技術を使⽤していけばよいのか
3. VB.NETの⽴ち位置
4. 機械学習について
Slide 5
Slide 5 text
1. 現在の.NETの状況
各Frameworkについて
.NET Standard
.NET Core 3.0
Xamarin
Blazor
ML.NET
Slide 6
Slide 6 text
No content
Slide 7
Slide 7 text
各Frameworkについて
.NET Framework
Windows上で動作する。
.NET Core
Windows、Mac、Linux上で動作する。ただし、.NET Core 3.0で実
装予定のUWPは、Windows上でしか動かない。
Xamarin
Windows、iOS、Android、Mac上で動作する。
.NET Standard
.NET Standardは、各フレームワーク間の共通ライブラリの実装に使
⽤する。
Slide 8
Slide 8 text
.NET Standard
Slide 9
Slide 9 text
No content
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
.NET Frameworkの統⼀化
.NET Framework、.NET Core、Xamarinで、それぞれのAPIで実装レ
ベルが異なるのが現状である。実際のアプリケーションでコードラ
イブラリの共有化を⾏いたい、という要望があると思うが、それを
実現するのが、.NET Standard
あくまで仕様というのがポイント。すでに実装があるわけではない
イメージとしては、HTML5と同じ。
HTML5なら仕様があり、そこに各種ブラウザが実装していく。
つまり、.NET Standrdという仕様があり、それに対して各
Frameworkが実装していくという考え⽅となる。
Slide 12
Slide 12 text
統⼀仕様の詳細
共通のDLLは使⽤せず、基本的に各Frameworkで実装するというの
が基本となる。
しかし、Type Fowarding(型の転送)については、共通DLLを経由して
⾏う。
.NETプラットフォーム間でコード、ライブラリ、開発スキルを共有
できるのが利点
ポータルクラスライブラリ（PCL）に代わる精選された共通APIセッ
ト
PCL:https://blog.ch3cooh.jp/entry/20140328/1396002120
Slide 13
Slide 13 text
No content
Slide 14
Slide 14 text
.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ベースのアプ
リケーションを作ることができる
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
Windows Compatibility Pack（Windows互換機能
パック）
Windows依存の機能も実装されている。Windows以外のプラットフ
ォームでもビルドは通るし、動作する機能もある。⼀部はWindows
限定であり、APIが例外を起こす
実際の実装時には If分岐で必要場所のみビルドされる。あちこちに記
載する必要はあるが、#ifではなく、通常のif⽂のため、コンパイル引
数を与え忘れていたのでビルド不可という状況は起こらない。
if (RuntimeInformation.IsOSPlatform(OSPlatform.Windows))
Slide 17
Slide 17 text
.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/
Slide 18
Slide 18 text
デスクトップアプリケーションで、なぜ.NET Core
が必要となるのか
Side by Sideで実⾏されるため、環境依存が少ない。
.NET Framework ライブラリのグローバル参照 or ローカル参照を選
択することができる。これはコンパイル時に選択することになる。
最新のAPIは、.NET Coreに先に実装されるため、.NET Coreを使⽤
することで、最新機能を利⽤しやすくなる
Slide 19
Slide 19 text
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
Slide 20
Slide 20 text
Blazor
Browser + Razor = Blazor
ブラウザ上に.NET実⾏環境ができたということ（UIフレームワーク
は提供していない）
すべてのブラウザーで動作させることができ、Reactiveなどを知ら
なくても、.NETでクライアント側のWeb UIをビルドすることができ
る。
Web Assemblyとして実装するため、ブラウザにプラグインなどは不
要。
クライアントとC#でのコードの共有、C#の強く型付けされた開
発、.NETの安定性と⼀貫性を受けた開発が実現できる。
Slide 21
Slide 21 text
ブラウザ上での動作
Chromeの開発者ツールで確認すると、WebアプリケーションにDLL
が配布されていることが確認できる。
読み込み速度については、最近はJSも⼤きくなってきていることを
考えると、誤差範囲になるのでは、と想定しているとのこと。
クライアントのOSのNativeで動作するので速度的にも有利。
実装としては、コンパイルされてブラウザー側で動いている形。
将来的に期待していただければ、という⾔い⽅でした。
ダウンロード︓https://blazor.net/
Slide 22
Slide 22 text
ML.NET
Azureのモデルを使⽤するのではなく、.NETのアプリケーション⾃体
で機械学習を⾏うには、今回開発されていくことが発表となった
ML.NETを使⽤する。
独⾃の学習モデルの作成、分析、判定。.NET のアプリケーションの
中で、機械学習を使⽤できるようになる。
現在は、ML.NET 0.1 (Preview)の状態だが、.NET Core 3.0のころに
は、1.0に近いものが出てくると考えられている。
Slide 23
Slide 23 text
2. どの技術を使⽤していけばいいのか
この１年の.NET Core
新規なら、.NET Coreがいいかな、感
新機能の実装
.NET Coreのほうがメインストリームに
.NET Frameworkの退役
.NET Frameworkから.NET Coreへの移⾏
Slide 24
Slide 24 text
この１年の.NET Core
.NET Coreも⽣みの苦しみを抜けた状況となっている。
どう⾒てもWindows⽤、Coreにいれるの︖な感じの互換パック
Windows Compatibility Pack
パフォーマンス、.NET Core 2.0、2.1にするだけで数割⾼速に
C# 7.X活⽤する、細かい最適化多々
ランタイムに⼿を⼊れないと実現無理な新機能の作業開始
C# のコンパイル上のトリックではなくて、.NETのコアに⼿を⼊れ
なければいけない機能についても、実装して来ている。
Slide 25
Slide 25 text
新規なら、.NET Coreがいいかな、感
.NET Core 1.0のころは、.NET Frameworkのサブセット感満載だった
（機能が少ない）。しかし今は、新規なら、.NET Coreがいいかな、
という状況になってきている。
Slide 26
Slide 26 text
新機能の実装
新機能については、まずは、.NET Coreに実装している状況となって
いる。
.NET Frameworkへの実装は、.NET Coreから.NET Frameworkへの移
植という形となるため、以下のような問題がある。
.NET Frameworkに移植されるまでに時間がかかる
パフォーマンスについては、問題が出てくる。.NET Coreのほうが
早いという状況がありえる
.NET FrameworkはSide by Sideではないので、環境依存となる
Slide 27
Slide 27 text
新機能の例 Utf8String
インターネットで扱われている⽂字列はUTF-8だが、Windows上で
は、UTF16である状態を改善したい為の変更
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
.NET Coreのほうがメインストリームに
今後は、.NET Coreの⽅がメインストリームとなる。
.NET Core 3.0 Desktops Packsで実装予定のGUIを使⽤したアプリケ
ーションでも、.NET Coreの恩恵（パフォーマンス向上、side by side
インストール）などがある。
１つ注意点としては、クロスプラットフォームだからといって、
Windows以外でWPFが使えるようになるわけではない。その⽬的
ならば、Xamarinとなる。
Slide 30
Slide 30 text
.NET Frameworkの退役
全機能がCoreに移った時がFrameworkの退役どき。
とはいえ
.NET Framework をやめたい、としても
システムの利⽤者がいるかぎり、サポートは切れない。また、メ
インストリームから外れても、.NET Frameworkのサポートはちゃ
んと⾏なわれる
.NET Coreで動かせる、としても
無理に、移⾏する必要はない。スレッド周りの問題で、問題が起
きる可能性が⾼い
Slide 31
Slide 31 text
.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に持ってきてテストする、ということ
はしているが、⼤体動く。
動くからといっても、スレッドの挙動の違いとかではまる可能性あ
り。たとえば、パフォーマンスを上げるとロックのタイミングが変
わって破壊的変更につながる、ということはあり得る。
Slide 32
Slide 32 text
3. VB.NETの⽴ち位置
⾔語戦略
実装のタイミングやサポートプラットフォームに差をもたせる理由
サポート内容
Slide 33
Slide 33 text
⾔語戦略
将来の計画では、C#の設計からVBを切り離すことになる
C#が似ているからといってそれを単に追加するのでなく、VB⾔語に
ふさわしいものを追加することになる
これは例えば、VB.NETで.NET Coreが使えなくなるというわけでは
ない。同時に実装されるわけではないが.NET Coreでも徐々に実装さ
れていく。PowerShellから以下のコマンドで確認可能
dotnet new
MicrosoftはVBを.NETのファーストクラス⾔語として扱い、引き続
き新しい開発者を歓迎している
Slide 34
Slide 34 text
実装のタイミングやサポートプラットフォーム
に差をもたせる理由
クロスプラットフォームのゲーム開発やMac OS Xを対象とする開発
にはC#が適している。これは⾔語仕様によるものではなく、開発者
がどれだけ引き寄せられているか、とそこからのフィードバックの
差によるもの
Microsoftには、広範なフィードバックを最も速く，最も多く獲得で
きるC#に注⼒したい意思がある。このフィードバックを通じて事例
が得られ、VB開発者にも価値があると思われた時点で，Microsoftは
C#からの移植を検討する。
Slide 35
Slide 35 text
サポート内容
品質ツールなどについて、今後も両⾔語に同等なサポートが提供さ
れる（Visual Studio 2017のライブユニットテストなど）
プラットフォームに関して，今後も.NET Coreの.NET標準をサポート
可能なメンテナンスが継続される。
⾔語そのものに新機能やキーワードは加えられるものの，それはC#
に追加されたという理由からではなく，VBの⽬的に適した場合のみ
に限られる。たとえば、前に述べたUTF-8⽂字列など
Slide 36
Slide 36 text
リソース
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
Slide 37
Slide 37 text
4. 機械学習について
機械学習のエンジン
Azure Machine Learning Studio
必要なデータ量
GPUは正義
Slide 38
Slide 38 text
機械学習のエンジン
Microsoftのセッションだったが、Keras(Tensor ow)を使⽤している
事例が多かった
オープンソースでサンプル豊富であること
使⽤者数が多いため、最新の論⽂のアルゴリズムがすぐに実装さ
れる
Slide 39
Slide 39 text
Azure Machine Learning Workbench
ローカルで実⾏することもできるし、クラウド上でも動かすことも
できる。Tensor owの実⾏を⾏うこともできる。ファイル取り込み
などのコード作成も簡単に⾏える
データを⾒ながら、データの取り込み、加⼯処理（抽出も）を⾏う
ことができる。途中でヒストグラム、データソースのジョインを表
⽰することもできる。
参考︓https://qiita.com/yomatsum/items/3bacb6e4574c9f9b3d9c
Slide 40
Slide 40 text
必要なデータ量
機械学習に必要な画像の数
昔は100万枚。最近は1万枚程度でOK。状況によってはもうちょっと
少なくても良い。（この枚数は、学習、検証、テスト合わせての枚
数）
枚数が少なくても済むようになった理由は、転移学習を使うことで
ある
Slide 41
Slide 41 text
GPUは正義
⾼性能なGPUは確かに値段が⾼いが、⼯数や⼯期などトータルで⾒
るとコストはトントンではないか。やはりGPUを導⼊して早い⽅が
良い
Slide 42
Slide 42 text
リソース
レポート
https://qiita.com/tfukumori
GitHub(井上章⽒) セッション時サンプル
https://github.com/chack411/VisualSearchApp-AD14-decode18
Slide 43
Slide 43 text
ご清聴ありがとうございました