仮想空間の日常

▲ 【Day 30】git log -S（つるはし検索）で消えた過去の関数・定数を発掘する 👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 29では、コードの犯人や導入理由を特定する 「git blame & git log -L」 によるコード考古学の基礎を学びました。 そして本日のDay 30は、長期運用や保守開発の現場でエンジニアが必ず一度は直面する大ピンチ—— 「昔確かに存在したはずのあのC#メソッドや定数、いつ誰が消した！？」 という謎を、全リポジトリのコミット差分から瞬時に一発発掘する極意—— 【git log -S（つるはし検索）で消えた過去の関数・定数を発掘する】 をお届けします！ 「仕様変更で半年前に削除したロジックが、法改正や方針転換で急遽また必要になった」「過去のテスト済み定数の値を確認したいが、現行コードのどこにも見当たらない……」 そんな時、何千件もあるコミットログを手作業で1件ずつめくって探していませんか？ Gitが誇る 「Pickaxe（つるはし）検索」 を使いこなせば、指定したテキストの「出現回数の増減（新設・削除）」を全履歴から瞬時にバイナリスキャン！ わずか0.1秒で目的のコミットを掘り当て、当時の完全なコードをピンポイントで安全にサルベージ（復元）できます！ 開発現場での無駄な再車輪開発を防ぎ、生産性を劇的に高めるプロの技を完全マスターしましょう！ ① 導入・本日の達成目標 ソフトウェア開発が数年続くと、不要と判断されたコードや古いインターフェースはリファクタリングで削除されていきます。 しかし現実のビジネスでは、「一度廃止された仕様が、別の顧客向けに再必要になった」「過去の複雑...

▲ 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章: コンテナ初回起動時の自動実行メカニズ...