# .NETの3日間 ~3コミュニティ合同イベント~ テーブルトーク テーブルトークのトピックをまとめていきます ## テーマ1:ビジネスアプリケーション(その他のMS技術)~19:45 * 登壇(敬称略) * Yuta Matsumura([@tsubakimoto_s](https://twitter.com/tsubakimoto_s)) * Tomohiro Suzuki([@hiro128_777](https://twitter.com/hiro128_777)) * mishizaki([@mishi_cs](https://twitter.com/mishi_cs)) * 進行 * Takas(@DevTakas) * ビジネスアプリケーションのここ一年の変遷? * 社内の運用をまわすためのWorkFlowの構築など * 他社製品を使うことがあったが申請やPower Automateを使うことが多くなった * Share Pointなどを利用してガバナンスをしっかりするための活動をすることになった * 守るための工程はかなり面倒…ということなので導入の支援を行ったりしている * データや資産を管理していきつつ自動化をするようになっている * Power Automateを利用している * クラウドシフトでPower Platformなどを利用することが多くなった * オンプレで組んでいたものを持っていくのに相性が良かった * 申請やモノの管理など比較的軽いもの。元々Share Pointなどでやっていた軽いもの * M365を利用しているから色々使えるようになったのでそこから積極的に使うためのサポートをすることが多くなった * E3/E5を導入するといった企業が増えてきたがどう使っていいかわからない。という支援など。 * 他社ローコードツールとの比較とか * ガバナンス周りのポリシー設定などコンサル的な支援も多い * 市民開発者(というか導入支援する際に関わる人達)について * 熱の違う人の間でみんなに使ってもらうにはどうする?といった課題があったりるする。 * 神Excel作るのが得意な方々をPower Platformに持っていく支援ができればいいと思っている * 自分たちの仕事をやりやすくするために使っていく * みんなが自分自身で作る。トライアンドエラーをできる環境が重要そう。 * AIとの関わり方? * Co-pilot:Power Platformのはぜんぜん違う→0から作ってくれるぞ! * 断片は作ってくれはしないのは開発者的に気になるので試してみたいところ。 * Power Appsも部品できるからそこもサポートできれば嬉しいが… * 著作権はどうなる? * 日本における法整備・ガイドラインがまだない?そこをどう解決するか?が気になっている。 * 生成されたものは著作権はないということは社会通念上認められるかもしれないが、元ネタがある部分がどうなる?と思っている。 * GitHub Copilotはその点色々整備されている * Publicリポの情報食わせないオプションとかある * M365 Copilotはどうなるんだろう?という部分は気になっている。 * トライエラーをしてよりよいものを作りやすくなるんだろうと思う * コードを書くイメージとは違う観点でバックオフィス業務の人もどんどんトライアンドエラーができるようになるだろう? * おすすめのBuildセッション * [Accelerate development with Visual Studio and Microsoft Power Platform](https://build.microsoft.com/en-US/sessions/a2154a8a-57fe-4717-af9a-bea7ec2b5e94) * 市民開発者の人にも開発者の人にもおすすめ * プロ開発者と市民開発者の関わり方がわかるようになってくる * 社内で作られているWebアプリを組み込む。。。なんてこともできる。 * レガシーなWeb APIをAPIMでくるんで、カスタムコネクタで接続して利用。みたいな使い方。 * API Management Authorizationが気になっている * 認証の部分を担ってくれる機能。これがあれば個別のマイクロサービスの認証が不要になるかもしれない。 * [Azure API Management での API 認可について | Microsoft Learn](https://learn.microsoft.com/ja-jp/azure/api-management/authorizations-overview) ## テーマ2:サーバーサイド技術(AzureとかWebとか)~20:20 * 登壇(敬称略) * Yuta Matsumura([@tsubakimoto_s](https://twitter.com/tsubakimoto_s)) * くさば([@tomo_kusaba](https://twitter.com/tomo_kusaba)) * たなか([@tanaka_733](https://twitter.com/tanaka_733)) * 進行 * Takas(@DevTakas) * 面白かったBuild Session * [Join the .NET Team at Microsoft Build 2023!](https://devblogs.microsoft.com/dotnet/microsoft-build-2023-and-dotnet/) * ここにあるものが大体おすすめ * [Deep dive into .NET performance and native AOT](https://build.microsoft.com/en-US/sessions/28588f70-fb54-447a-b778-7ef02c8ffdf8?source=sessions) * クライアントサイドだけじゃなくサーバーサイドでも効果があるよ。というお話。 * ネイティブコードまで事前にコンパイルし自己完結型で動作するアプリケーションとなる * 起動時間が早い * メモリ使用量も削減される * ランタイムレスで成果物が生成されるので軽い * 元々自己完結型のアプリは生成できたがランタイム入でめちゃくちゃFatだった。 * ASP.NET 8でPreview段階で入る予定 * モバイル環境でNative AOTが良いぞ話はよくあったがサーバーの世界でもそれは生きそうだ * クラウドネイティブの文脈 * マイクロサービスで頻繁にデプロイしたいという環境の場合起動時間が早ければ早いほど当然良い * 回復力の観点でも重要な要素になりそう * Native AOTだけではなくCloud Nativeの文脈でLinuxで動くのが当然の世界に寄せてきている * 非Rootユーザーでもちゃんと動くようになったりと.NETは着実に選択されるためのニーズを満たしてくれている * [Advanced developer tips and tricks in Visual Studio](https://build.microsoft.com/en-US/sessions/5ee143d2-5336-4e2f-b345-7daf606e7629?source=sessions) * 知らないVisualStudioの機能が出てくるのでざっと見るのはおすすめ * APIエンドポイントエクスプローラー * 1日めのセッション。Swaggerなど立ち上げなくても網羅的にAPI見れるしテスト叩けるので良き * Copilotについても紹介あり * 普通のCopilotもCopilotXも * 新しい機能ではないがあまり使われていない機能の説明なんかもある * VSのWindowレイアウトを保存してそのレイアウトに瞬時に切り替える機能がある…といったTipsが紹介された * [What's new in .NET 8 for Web, frontends, backends, and futures?](https://build.microsoft.com/en-US/sessions/da223f08-abb2-4f38-87de-0856ffa22317?source=sessions) * Blazor Web AssemblyとBlazor Serverが同居できるようになったらしい * WASMベースだけど一部通信にWebSocketを使うようなことが可能に * 元々別物だったものが同居できるようになったので力を入れていることが再認識できた * こまかい部分をServerの機能、WASMの機能を使う。という構築の仕方ができるようになった * なにか新しいものが…というほどたいそれたレベルのものではないがそれぞれのいいところを取捨選択し同一のアプリに載せれるようになる * UXの観点でよりユーザーのニーズに即した実装がBlazorのアプリ一本で可能になるのではないか * 今までServerだし…WASMだし…ということで諦めていた部分に手が差し伸べられた * おすすめのBuildで紹介された?いままで使ってたツール? * [Building AI solutions with Semantic Kernel](https://build.microsoft.com/en-US/sessions/31e11443-70d3-4020-8c8c-0a654bccd233?source=sessions) * .NET開発者としてAIと関わる際に一番関わるライブラリなのではないか。 * Copilot Stackの考え方をベースにプラグインを作るなどする際に確実に利用することになりそう * [GitHub Advanced Security for Azure DevOps public preview starts now!](https://devblogs.microsoft.com/devops/github-advanced-security-for-azure-devops-public-preview-starts-now/) * エンタープライズ企業はAzure DevOpsを多く使っているかもしれないが、その中でもコードセキュリティを保った状態で開発ができるようになる。 * 脆弱性のあるライブラリの利用やシークレット漏れなどをCIなどの中で検知・対応できるようになる * DevHomeのDevDrive * [Dev Drive for Performance Improvements in Visual Studio and Dev Boxes!](https://devblogs.microsoft.com/visualstudio/devdrive/) * WindowsをどういうOSにしていくか。という思惑がすこし見えるかも。 * 開発者がWindowsOSを選ぶ一助になるのかもしれない * 現在WindowsのInsider Previewでしか利用できない * 試しに使ってみたがPublishBuildしたときに10%くらいの向上 * 軽量なアプリでそれだけ向上したので、大きなアプリになるともっと増えるのでは ## テーマ3:クライアントサイド技術 ~20:45 * 登壇(敬称略) * とっちゃん([@Tocchann](https://twitter.com/Tocchann)) * Takao Tetsuro * 須藤圭太([@suusanex](https://twitter.com/suusanex)) * 進行 * Takas(@DevTakas) * Buildはクライアントサイドのセッションはあまりなかった説 * 実際あまりなかったが強いてあげるなら… * MAUIが数点 * DevHome系 * [New developer experiences in Windows](https://build.microsoft.com/en-US/sessions/5017d756-1ed1-468c-bd43-1ac98079f71e?source=sessions)? * AOT(前トーク) * .NET8系(前トーク) * おもしろそうなクライアントサイド技術 * Windows一辺倒だった世界で他プラットフォームに展開したい…となったとき * 元々はXamarinがその役割をになっていたがどうしても弱い部分(Windows)があった * いまはMAUIという答えになっているがMAUIもちょっと… * 実はBlazorがいいのでは?という世界ができていたりする * Webアプリからクライアントの世界を触るようなことができるようになっているので * クライアントの世界でUIはどうする問題につきあたることを考えると軽量につくれかつ取り回しがしやすいBlazorが選択肢にあがることが多いのではないかという気はしている * Generic Host * Generic Hostを使って共通して基本的な部分は共通して作れるという世界がクライアントサイドでも構築可能になっている * ASP.NETだけではない * Generic Hostさえ抑えておけば、基本部分はそのままにUIをすげ替えるような世界が構築できるかもしれない * UIはいろんな選択肢があるが大事なところは共通化できるようになってきている。というのが面白い部分。 * Webの世界とクライアントサイドの世界のロジック共通化がより高度なレベルで可能になるかもしれない * 新しい機能を追加する。変更する。動的に組み合わせる。といったことが可能なのでその観点からも重要な要素となる * 利用する環境に即したインターフェースを変更する可能性はあるかもしれないが最小限で収まると思う * 今後WASIとの連携においても重要な役割を果たすと予想される * Windows Formsでバインディングができる話(2日目セッション) * これがすすむとWindows Formsでジェネリックホストができる世界が人がりそうだが… * ただ相性が悪い(やるためにはちょっと必要なことが重い) * Formsやってる人がMVVMとかGeneric Hostを勉強する動機がでてきた…という見方も * MAUIやBlazorなどマルチプラットフォーム推しだが実際はどうだろう? * Server側はあるていど処理が共通しているが、一つのアプリをマルチプラットフォーム展開というのはあまりない * 用途がそもそも違うから共通項があまりない…ということもあるが * ToCなビジネス要件の場合クライアントサイドに処理を寄せたほうが責任分界点やコストの面で折り合いが付きやすいことも多くそういった面もあり * そもそも一つのアプリをWindowsでもLinuxでもモバイルでも…という要件はあまりない * C#の開発者が別のプラットフォームに手を出すときにじゃあMAUIを…Blazorを…みたいなことが増えてきた * 今の技術の延長でそのまま別のプラットフォームへ…ということが増えてきた * 最小限の学習で別プラットフォームの構築が可能な世界 * 保守や運用面でも自分たちの領分で理解・構築することができる * クラウドサービスでモバイルアプリケーションを提供している会社はかなり多い * ある種単機能特化型のアプリが提供されている場合、それと同様なアプリの構築は必要ないとする場合が多い * SIのような会社の場合は複数あるアプリを組み合わせてビジネス構築するような構成が多い * 基本的にはサービスのみ提供という形態は少なくアプリも同時に提供していることが多いためそれをそのまま使うことが多い * どちらかというと最近求められているのは上記のような異なるサービスをどのように組み合わせて運用するかという運用設計の観点からのアプローチが重要視されることが多い * 汎用アプリはない。単機能特化型のアプリを複数使う。 * 円滑なアプリ間の連携のためのWebAPI * 連携部分のロジックをClient、Sererで共通化し運用しやすくるためのGenericHostが有用。と考えるのも良さそう * IoT * クライアントサイドといえば一昔前はもてはやされていたが今は。。。? * 停滞気味だから特に今回のBuildはなにもなかった