仮想空間の日常

▲ Day 32: Dockerネットワークの仕組み（Bridge, Host, None） 🐳 「コンテナ同士はどうやって通信している？ 外部にDBを晒さずにWeb APIとだけ安全に繋ぐには？」 前回（Day 31）までで第6部『データの永続化とボリューム』が完結し、新メンバーが参加した初日にコマンド一発でDBと初期シードデータが完全復元される「ゼロセットアップ環境」の構築手法を学びました。 そして今日から、いよいよ本講座の最重要タームの1つである 新章『第7部: コンテナ間ネットワークとポート管理』 が開幕します！ 物理サーバーやオンプレミスインフラを30年経験してきたエンジニアの皆様は、こう疑問に思われるかもしれません： 「物理サーバーならL2スイッチにLANケーブルを挿し、VLANを設定すれば通信を分離できた。Hyper-Vなら仮想スイッチを作って仮想NICを割り当てていた。では、Dockerコンテナ同士は一体どうやって通信しているのか？ なぜIPアドレスではなくコンテナ名でpingが通るのか？ 外部インターネットからデータベースを完全に隠蔽するにはどう設計すべきか？」 本講義では、Dockerが裏側で構築する仮想ネットワークブリッジの正体から、3大ネットワークドライバー（Bridge / Host / None）の使い分け、初心者が必ずハマる「デフォルトブリッジの罠」、そしてC# Web APIとSQL Serverを組み合わせたセキュアな多層防御ネットワーク設計まで、完全網羅で解説します！ INDEX 本日の講義メニュー 第1章: 物理スイッチ・VLANから「ソフトウェア定義ネットワーク...

▲ 【Day 29】git blame & git log -L でC#コードの「犯人・導入理由」を完全特定 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 28では、必要な行だけをインデックスに選別してアトミックなコミットを作る 「git add -p」 の部分ステージング術を学びました。 そして本日のDay 29は、保守・運用・レガシーコード調査の現場でエンジニアの調査スピードを10倍に引き上げる極意—— 【git blame & git log -L でC#コードの「犯人・導入理由」を完全特定】 をお届けします！ 「他人が書いたC#のビジネスロジックを読んでいるとき、『なぜこんな不自然なif文があるんだ？』『このハードコードされた閾値は何のために存在するんだ？』と頭を抱えたことはありませんか？」 「そして『誰だこんな汚いコードを書いたやつは！消してしまえ！』と短絡的に削除してしまい、実は過去の重大な障害を防ぐための命綱ガードだったことで、障害を再発させて青ざめた経験はありませんか？」 プロのエンジニアに必要なのは、怒りではなく 「コード考古学（Code Archaeology）」 の視点です。 Gitのコマンドや最新のGUI拡張機能を駆使すれば、怪しい1行や特定のC#メソッドが 「いつ・誰が・どのコミットで・どのような仕様・チケット（Issue/PR）の理由で書かれたのか」 を数秒でタイムスリップして解明できます！ SVN時代の重いblameとは次元の違う、Gitならではの超高速コード調査テクニックをマスターしましょう！ ① 導入・本日の達成目標 ソフトウェア開発において、コードを新しく書く時間よりも「他人の書いた既存コードを読む時間・調べる時間」の方が圧倒的に長いと言われています。 ...

▲ Day 31: データベース初期データ（シードデータ）の自動投入テクニック 🐳 「新メンバーがチームに入った日、DB環境構築で丸一日潰していませんか？」 前回のDay 30では、「コード・構成（Git）」と「実データ（Volume）」の3層分離原則を徹底解説し、巨大なDBファイルをGitにコミットしてリポジトリを破壊する事故の防止策を学びました。 しかし、ここで現場のエンジニアから最も多く寄せられる切実な疑問があります： 『mdfファイルをGitに含めないのは理解できた。では、新人が開発を始めるための初期データ（マスターデータやテスト用データ）はどうやって渡せばいいのか？』 かつてのオンプレミス現場では、先輩エンジニアがUSBメモリや共有フォルダで数GBのダンプファイルを手渡し、手作業でSSMSからリストアさせていました。 しかし現代のコンテナ開発では、 『リポジトリをクローンして docker compose up を1回実行するだけで、必要な初期データがすべて自動投入されたDBが立ち上がる』という「ゼロセットアップDB環境」 が標準です。 本講義では、Docker標準の entrypoint-initdb の自動実行メカニズムから、C# EF Core による Database.Migrate() とテストデータ注入テクニックまで、現場で即座に役立つ自動化ノウハウを完全網羅します！ INDEX 本日の講義カリキュラム 第1章: USB手動配布の悲劇と「ゼロセットアップDB」の必然性 第2章: コンテナ初回起動時の自動実行メカニズ...

▲ 【Day 28】git add -p で必要な行だけを綺麗にコミットする部分ステージング技 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 27では、巨大なC#ソリューションでの再ビルド待ちを完全ゼロにする神機能 「git worktree」 の内部構造と2画面並行デバッグの極意を学びました。 そして本日のDay 28は、プロの現場で毎日のように使われる超実践テクニック—— 【git add -p で必要な行だけを綺麗にコミットする部分ステージング技】 を徹底解説します！ 「C#のバグ調査や新機能開発の際、変数の値を確認するためにコードの途中に Console.WriteLine を差し込んだり、一時的なハードコード（テスト用の固定値やフラグ）を書き込むことはよくありますよね」 「しかし、いざコミットしようとしたとき、そのデバッグ行を手動で1行ずつ削除したりコメントアウトして、再度ビルド確認してからコミットしていませんか？ あるいは、削除し忘れたデバッグログがそのまま本番リポジトリにコミットされ、Pull Requestのレビューで『不要なデバッグ出力が残っていますよ』と指摘されて恥ずかしい思いをしたことはありませんか？」 かつてのSubversion (SVN) では「ファイル単位」でしかコミット対象を選択できなかったため、そうした苦労は避けられませんでした。 しかしGitには、 1つのファイル内にある変更箇所を行単位（Hunk：ハンク）で自由自在に選別し、必要な行だけをインデックス（ステージング）に載せる『git add -p (patch)』 という強力無比な機能が備わっています！ ローカルのデバッグ用ログを残したまま、本番用修正コードだけを100%美しくコミットするプロの極意を、コマンドラインとTortoiseGit GUIの両面から完全マスターしましょう！ ...