Azure+Blazorx個人開発

Azure + Blazor x 個人開発 松井 敏

自己紹介 ■ 🧑 松井 敏(まつい びん) @binnmti a.k.a @moririring ■ 🧑‍💻 元ゲームプログラマ & 元Windows大規模ソフトウェアプログラマ ■ 👜 HACARUS C#&CI/CD メンター(副業) ■ 🏆 Microsoft MVP for Developer Technologies 2012-2024 ■ 💻 Unity5 3Dゲーム開発講座 ユニティちゃんで作る本格アクションゲーム ■ 💻 C#読書会主催、Greek Alphabet Software Academy TA ■ ❤️ プログラム、マンガ、料理、睡眠、妻&子供 resume

キャリアブレイク ■ どんな生活をしているか ■ 勉強 (アルゴリズム、コンピューターサイエンス、コンパイラ作成、英語、栄養学、仏教) ■ 読書 (技術書、英語、仏教、料理) ■ 息子教育 (算数、自転車、マラソン) ■ 健康をテーマにライフスタイルの見直し (睡眠、食事、運動など) ■ お金の節約 (家計簿、サブスク、移動手段、税金関係、それでも必要なものには使う) ■ なるべく人と会う ■ コミュニティ活動 (主催月2回、TA月1回、ミーティング月2回) ■ 副業月2回 ■ 就職相談月1回 ■ 月3,4回ぐらいは呑んでるかも？意識して1on1を増やした ■ 個人開発

アジェンダ ■ 自作サービスの紹介 ■ Blazor ■ AIコーディング ■ DevOps (CI/CD,Github flow,IaC,Unit/GUI Test) ■ まとめ

欲しいから始まる自作サービス ■ マークダウン❤️ ■ 出来れば常にマークダウンで書きたい ■ 右側にプレビューがあって、左側で編集出来るスタイルが最高 ■ 意外にこれが多くはない。ただ絶対そうして欲しい。 ■ ただ、これだけだと作るモチベーションとしては弱い ■ 階層式のマークダウンエディタが欲しいと思った ■ ＋があれば作る意味がある。そう思って作り始めた

1Pagerという考え方 ■ Amazonの文化「ワンページャー」 ■ 会議などの概要を1Pで表現する文章 ■ だれも長い文章は読みたくない ■ 1Pにまとまった文章は最高 ■ 6PまではOKという派閥もある

1Pでは表現しきれない問題 ■ 但しどうしても詳細に知りたい情報もある ■ Googleでも1Pagerとデザインドックがある。デザインドックは詳細用。 ■ ポイントとして1Pagerとデザインドックに物理的なつながりはない。 ■ 階層はフォルダで表現することは出来るので詳細を子供にすれば良い ■ 但し、ファイルのつながりは名前などで頭の中でやるしかない ■ そう考えた時に階層式テキストはつながりが表現出来るのがかなり便利だと思った ■ 目指すべきは、全ての階層の文章が6Pに収まるぐらい短い文章として使う

具体的な階層式テキスト表現 ■ 旅行計画などを立てた時に、全体の日程をTOPに1Pにまとめる ■ 日付個毎に詳細ページに情報を書く ■ 自分のプロフィールを履歴書にTOPにまとめる ■ 会社毎の職務経歴を子階層に置く ■ 本などの内容を文章にまとめていく ■ 章ごとに見出しを作って階層で表現していく

DEMO ■ 普通のマークダウンエディタとしての機能 ■ 左側が編集で、右側がプレビューが常に出来ることが至高 ■ 入力中に - などが自動で改行される ■ 画像の追加なども可能 ■ その上で階層的にファイルを作ることが出来る ■ ログインすればTOPファイルは幾らでも作成可能 ■ ドッグフーディング中 https://pinetree.azurewebsites.net

英語への拘り ■ 出来れば言語に依らず使って欲しいし、であれば10倍のユーザーを狙いたい ■ コードリポジトリも含めて全て文章は英語こだわっている ■ 自分は空手で英語が書けるほどのスキルはないので、結構な手間もあり、ストレスもある。 ■ 早くマルチに対応しないと細かいエッセンスが抜けることもある気がしてきている

開発環境 ■ IDE:Visual Studio ■ 言語:C# ■ フレームワーク:Blazor ■ クラウド:Azure(App Service + SQL Database + Storage)

Blazor

Blazor ■ 自分のBlazorの歴 ■ 多分、相当早い段階から使ってはいる(experiment版から) ■ この時期からサービスを作っていた人は多分いないと思う。 ■ .NET 8でわりと大きく変わった。が、この時期はもう抑えてなかった。 ■ ポイントはレンダーモード。今回自分なりに調べたり、検証はしたが、業務レベルで使ってない ■ なのでより深い知識がある人からすると適当な事を言っている可能性もある。

Blazor Web アプリ レンダーモード ■ レンダーモードはテンプレートの段階で選ぶ必要がある 名前 説明 レンダリング場所 インタラクティブ 静的サーバー 静的サーバー側レンダリング (静的 SSR) サーバー ❌いいえ ★対話型サーバー Blazor Server を使用した対話型サーバー側レンダリング (対話型 SSR)。 サーバー ✅はい 対話型 WebAssembly Blazor WebAssembly を使用したクライアント側レンダリング (CSR)†。 クライアント ✅はい 対話型自動車 対話型SSRは、最初にBlazor Serverを使用し、Blazor バンドルがダウンロードされた後の後続のアクセスではCSRを使用します。 サーバー、その後クライアント ✅はい

デフォルトのイベントが発生しない問題 ■ テンプレートはデフォルトが大事だと思っているし、実際ユーザーも一番多いと思う。 ■ サーバーでページ/コンポーネントごとで作ると1プロジェクトにまとまって扱いやすい ■ ページ/コンポーネントごとのレンダーモードの非常に重要な注意点 ■ @rendermode を書かないとイベントが発生しない！ ■ これが忘れがち。というかはまりポイント。 ■ 初見殺しで本当にハマった。 ■ ググって調べたページでもこれが乗っていないことはままある。 ■ 正直自分はわりとこれでやる気をなくした。。 ■ Copilotの提案でもここが抜けていてイベントが起きないことが多々ある。 ■ 開発環境の未熟さあいまってわりとかなり気づきづらい。

グローバル ■ 「ページ/コンポーネントごと」をやめて「グローバル」にすれば良いか ■ 全部InteractiveServerならそれでも良い ■ 正直、全てInteractiveServerが一番楽な気はしている ■ しなかった理由はデフォルトではないからだけ

InteractiveServer ■ サーバーで全て制御する ■ ロードが速い ■ APIやリソースに直接アクセス可能。これが楽ー。 ■ SEO, OGP的にもこっちの方が有利 ■ 同時接続数が増えてきたら水平展開してやればOK ■ それで良いか？ハッキリ言って知らねー。 ■ ただ、問題が出るまではこれでやれば良いかもが現状の僕の考え ■ ユーザーが増えるサービスを作ってから移行するのも一つ。 ■ ただし、レンダーモードの移行は中々に大変。

レンダーモード見直し ■ で、公開したこともあって、一度レンダーモードを見直してみる ■ 以前のBlazorはクライアントありきだったしそれがベター？ ■ 大体、全部サーバーでやるなんてトレンドじゃないんじゃない？ ■ SPAこそ最新トレンドであり技術イケメンは使うべき ■ クライアントで処理した方がサーバーが増えても動くし安く上がる？ ■ そうなると、クライアントでやらない理由なくない？と思ってしまった。 ■ 端的に言うと、サーバーを使うのは格好悪いと考えたのが一番の理由

レンダーモード移行 ■ もともとInteractiveServerで作り始めていたのでここから移行する ■ InteractiveServerはプロジェクトが1つ ■ テンプレートでInteractiveWebAssemblyとInteractiveAutoは2つのプロジェクトに分かれている ■ InteractiveServerのDIに必要な設定を足していけばそのままでも行けそうな香りはした ■ 実際にやってみるとonclickがこなくなった ■ 逃げる方法もあったが、とてもイレギュラーに感じた

レンダーモード移行 ■ OnInitializedAsyncとOnAfterRenderAsyncの扱い ■ 直接DBのデータを編集出来るが、WebAPI経由の操作にする ■ 初期化に、クライアント側の合成起点の関数が呼ばれないケースがあり、DIが正常に動かない

InteractiveWebAssemblyとInteractiveAutoの使い分け ■ 全部、InteractiveAutoはアリだと思う ■ そうした場合のデメリットは、分かってない。 ■ ただ、InteractiveWebAssemblyの方が適しているケースもあると思う ■ InteractiveAutoでないと駄目な事 ■ SEOとかOGPとかに限る。と思っている

自分の設定 ■ ページ/コンポーネントごと ■ ログインが必要な個人ページはInteractiveWebAssembly。SEO関係ない。 ■ 誰でも見えるページはInteractiveAuto。SEO関係ある ■ ログイン後にセキュリティが必要なページは完全サーバー側 ■ でも初回起動相変わらず結構遅い。。結局意味がないのか。。 ■ 今は、全部InteractiveServerに戻したい気持ちもある。。

Blazorの駄目な所 ■ 開発環境が枯れてない ■ インデントや補完も良く壊れる ■ 置換も上手くいかない時がある ■ ホットリロードも良く壊れる ■ 更新しても更新されず自分でobj消さないと駄目。 ■ 記述がどんどんフロントエンドフレームワークに近づくこなれてこない ■ レンダーモードの考え方とかまんまNext ■ htmlとcsが分けられるようにはなった。。。 ■ razor空しか呼ばれていないメソッドがcsで灰色表示されていてがっかりした ■ マークダウンエディタとBlazorの愛称は悪い ■ より正確に言うとtextarea操作と相性が最悪。 ■ ただ、これはJavaScript Framework(React)であっても同じ。

AIコーディング

AIレビュー ■ AIレビューは早い段階からCodeRabbitをつけていた ■ 現段階においては、最近入ったCopilotのレビューはイマイチ ■ (ぶっちゃけCopilotのレビューの方が良かったことはほぼないかも。。) ■ レビューしてもらうためには最適なPRを作りたくなる ■ そうすると最小単位でPRする癖が付き、それがコードの健康度を上げる ■ これはZennで書いたらちょっとバズった。。

AIコーディングについて ■ AIコーディングをやろうと思って始めたわけではない ■ Github Copilotに質問してコードを書いてもらう内容が徐々に高度化していっただけ ■ 体感的にもVibe Codingしている感じではない ■ 特に進化を感じたのは、Cluade3.7を使うようになってから ■ 個人的にはめちゃくちゃ楽しいし、思った以上にコードを書いてくれる ■ 実際生産性でいっても開発速度は数倍から数十倍上がった。 ■ UIを頼んだら、内容まで完璧だった時はちょっとやるなーと思ったw

AIコーディング×テスト ■ テストを書いた方が精度が上がる体験をした ■ ちょっと難しめぐらいのロジックを頼んだ ■ UIで確認してもNG。3,4回作り直してもらったが駄目実装ばかり ■ しょうがないのでテストを書くように頼んだ ■ 一発で通るコードをはいてくれた ■ 実装も完璧だった

AIとの主従 ■ 最初の内は自分の手癖に併せていた ■ 徐々に自分のコードをAIのコードに近づけつつある ■ 特に右に短く、広めに使う ■ 早期return書かないのなんで？？ ■ 新しいVSには手癖に併せてくれる機能が乗るというのもみた ■ そろそろコードをなおしたりレビューを受けたりすることも価値が下がり始めている ■ コーディングの主体もAIになりつつある時期かなと思い、弱冠恐いかな。

Visual Studio AIいらいらポイント ■ copilot-instructions.mdはまだかなり精度が悪い ■ 設置場所として右端が一番だが、狭い。 ■ スクロールバーがマジでストレスしかない。 ■ 今自分の使い方ではEditsは全く効果を発揮していない ■ Copilotに回数制限があり、それがよく分からないUX ■ 一応バンバン新しくすれば回避出来そうだけど。。

Visual Studio vs Visual Studio Code ■ AI対応についてはVisual Studioは遅れている印象 ■ まず選べるAIが限定的（Preveiewのみ5/6にようやく乗った。） ■ エージェントモードはVS Codeのみ ■ MCPサーバーもVS Codeのみ ■ 直ぐにでも追いつくかもだがそれほど簡単ではないかも ■ 補完に関してはVisual Studio Codeに一日の長がある ■ いずれ開発はテキストエディタレベルで十分になるかもしれない

DevOps

DevOpsは必要ですか？ ■ mainブランチに直上げ上等。 ■ 右クリックメニューの発行からデプロイ上等。 ■ これで困らなければ、これでも良いと思う。 ■ 自分はCI/CDが好きなので少し意識高い系 ■ コードデプロイもGUIポチポチでymlファイル作ってくれるので、殆ど知識がいらない

本番環境固有問題 ■ 実際、ローカルでは動いても本番環境だけ動かないケースはある ■ こうなってきたら最適なDevOpsを考えるタイミングかなと思う ■ 今回は色々リサーチしたり、自分なりの最適なDevOpsを作った ■ この発表がなかったらやってなかったかもとは思う

IaC ■ 昔自分が作っていたサービスをミスで完全に吹っ飛ばしたことがある ■ バックアップなども適当だったので復元は結局出来なかった ■ そうなると第一歩としてIaCは実践しておきたい ■ 以前、TerraformでFirebase構築をしてみて大分否定的にはなった ■ というわけで、Terraformでステージングを作ってみた

Terraform ■ Firebaseで作った時よりは好印象ではある ■ FirebaseはDestroyが出来ない仕様だったし、変更修正後に再度叩くとしょっちゅう失敗していた。 ■ Azureはその辺悪くないと感じたし、実際わりとすぐ作れた。 ■ ただしCIに乗せだしてからは勝手が違ってきた ■ 最終的にはTerraformをCIすることは辞めた ■ Pulumiにしたら解決するかもしれないが、試してはいない。。

CI/CD ■ 最初のCIは本当にVSが自動出力してくれたmainにマージされたらデプロイする ■ ステージングが欲しくなってからはmainマージでステージングにデプロイさせるようにした ■ これが正しいかは知らないが、マイグレーションもココでするようにした ■ ついでにPlaywrightでGUIテストの簡易版も作った。

Git* Flow ■ Gitlab Flowにしようと思ったけれど、タグだけで十分だと思ったのでGithub Flowにした ■ タグ付けされたら本番をデプロイするようにした。その際ブルーグリーンデプロイメントにした。 ■ これはダウンタイムを無くすための工夫として教えてもらった。

My DevOps ■ Staging環境は壊れたら、一応Terraformですぐに復元可能 ■ Databaseやリソースに関してはバックアップがないのでまだ ■ 通常の開発ではPRからmainにマージすれば、ビルド、テスト、マイグレーション、デプロイまでして、その後UIテストも動く ■ 実はまだmainに直接マージも、手動デプロイも可能。たまに使う ■ 今後はさらにタイマーでUIテストを拡張していく ■ ある程度溜まってきたら、タグを切ってプッシュすれば本番環境にデプロイする。ブルーグリーンデプロイメントでダウンタイム0。

個人開発に要らないもの。。 ■ 必要か分からないけれど、役に立ちそうだから入れてみるとは、モチベーションがない時はやらない方が良い ■ モチベーションがあっても、実際は役に立たないことも多く、オーバースペックになりがち ■ .NET Aspire ■ .NET MAUI ■ Microsoft Fabric ■ Bootstrap(tailwindcss) -> css ■ IaC ■ Blazor Render Mode ■ CI/CD ■ DI

pinetree今後 ■ textareaもmonaco editorに変えたい ■ 色変え、検索、スクロールバー、ショートカット、差分表示など明らかに高精度に ■ Visual Studio Codeでエージェントモードをためしてみるかも ■ 公開機能とか ■ これこそSEO対応とかSNS対応とかもいるかも ■ サブスクでプロモードを入れたい ■ stripe対応が思っていた以上に大変そう

まとめ ■ 個人開発でAIコーディングしているのは、最高に楽しい ■ Blazorは相変わらず枯れておらず、自分の望む方向に進化はしていない ■ が、C#出かけることはなによりもジャスティスなので、そういう欠点も薄れる ■ ところが、よりにもよってマークダウンエディタはBlazorと相性の悪い題材を選んでしまった。 ■ Visual StudioとAIの掛け算はまだ弱いので、VSCodeを試してみる。 ■ 相互進化が期待だが、さてどうなるやら ■ 開発規模にあった、フレームワークやテクノロジーを選ぶのが重要。そうでないと負債にすらなる ■ 階層式マークダウンエディタに興味が出たらぜひ使って、意見をお聞かせください！！