仮想空間の日常

▲ Day 18: .dockerignore の完全攻略（.git や bin/obj を除外して爆速ビルド） 🐳 皆さん、こんにちは！ Docker/コンテナ実践講座の専任講師です。 前回（Day 17）では、SDKイメージとRuntimeイメージを分離してイメージサイズを劇的に軽量化する「マルチステージビルド」をマスターしました。 しかし、現場で実際に docker build を叩いていると、こんな違和感に直面したことはありませんか？ 「ソースコードを1行直しただけなのに、ビルド開始時に何十秒も待たされる…」 「PCのファンが爆音で回り、ギガバイト単位の転送中プログレスが表示される…」 その元凶こそが、今回攻略する 『ビルドコンテキスト（Build Context）への不要ファイルの無差別転送』 です！ 本日学ぶ .dockerignore は、ビルド速度を秒速化するだけでなく、Git履歴や認証鍵の漏洩を水際で防ぐ 現場の絶対必須スキル です！ ① 導入・本日の達成目標 Docker初心者が最も陥りやすい落とし穴が、「 .dockerignore を作らずに docker build . を実行してしまうこと」です。 この設定を怠ると、Gitの膨大なコミット履歴（ .git フォルダ）や、Windowsローカルでビルドされた巨大な bin/ ・ obj/ フォルダ、さらには秘密情報を含む開発用設定ファイルまで、すべてがコンテナのビルド領域に無防備に送り込まれてしまいます。 本日の講義を終える頃には、以下の3つの目標を完全にクリアできるようになります。 ビルドコンテキスト転送の仕組み を理解し、なぜ .dockerignore がビルド爆速化に直結するのかを...

👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 14では、コミット履歴を美しく一本道に整頓する「リベース（git rebase）」と、絶対に破ってはいけない公開ブランチの黄金律について詳しく学びましたね。 さて、開発の現場で日常茶飯事のように起きるのが、 「新機能のコードを書いている最中に、本番環境で緊急バグが発覚した！」 というトラブルです。 Visual Studioを開けば、画面には赤波線（コンパイルエラー）だらけの書きかけコード。この状態のままコミットしたくはないし、かといって別のブランチ（緊急修正用ブランチ）に切り替えようとすると、Gitに「未コミットの変更があるため切り替えできません」と怒られてしまう……。 Subversion (SVN) 時代なら、泣く泣く差分パッチファイルを手動エクスポートしたり、作業フォルダを丸ごとZIP圧縮してデスクトップに避難させていたのではないでしょうか？ ご安心ください！ Gitには、そんな絶体絶命のピンチをわずか1秒で解決してくれる魔法のコマンド 「git stash（スタッシュ）」 が用意されています。 本日は、書きかけコードを安全な引き出しに一時退避し、何事もなかったかのように作業ツリーをクリーンにするプロの必須テクニックを徹底解説します！ ① 導入・本日の達成目標 「stash」とは、英語で 「（安全な場所に）隠す、一時的にしまい込む」 という意味です。 Gitのstash機能を使えば、コミット前の変更（作業ツリーやインデックス）を丸ごと一時退避領域（スタック）へと退避させ、作業ディレクトリを直前のきれいな状態（直前のコミット直後）に一瞬でリセットできます。 本日の講義でマスターする達成目標は以下の3点です！ ...

▲ Day 17: マルチステージビルド（SDKイメージ vs 軽量Runtimeイメージの分離） 🐳 皆さん、こんにちは！ Docker/コンテナ実践講座の専任講師です。 前回（Day 16）では、C# / ASP.NET Core Web API をコンテナ化するための「初めてのDockerfile構文（FROM, WORKDIR, COPY, RUN, ENTRYPOINT）」を学びました。 しかし、前回の単純なDockerfileには 「イメージサイズが800MB超に肥大化してしまう」「本番環境にコンパイラやソースコードが丸見えで残ってしまう」 という重大な課題がありました。 本日学ぶ 『マルチステージビルド（Multi-stage builds）』 は、この問題を完璧に解決し、現場のDockerイメージ作成において 100%必須とされる最重要テクニック です！ 開発環境と本番サーバーの分離を30年間実践してきたベテランエンジニアの皆様なら、その合理性に思わず膝を打つはずです。じっくりマスターしていきましょう！ ① 導入・本日の達成目標 一般的なアプリケーション開発では、「ビルドに必要な道具（巨大なSDK、コンパイラ、開発用ヘッダー、NuGetキャッシュ）」と「本番で動かすために必要なもの（最小限のランタイムと発行済みDLL群）」は全く異なります。 もしビルド環境をそのまま本番コンテナに含めてしまうと、ディスク容量を圧迫するだけでなく、余計なツール類がサイバー攻撃の足場（攻撃対象領域: Attack Surface）となってしまいます。 本日の講義を終える頃には、以下の3つの目標を完全にクリアできるようになります。 マルチステージビルドの概念と、1つのDockerfile内で 複数の FROM を使い分ける仕組み を論...

👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 前回のDay 13では、チーム開発の登竜門である「コンフリクト（競合）解消」を学び、Gitの衝突マーカーやTortoiseMergeの3画面比較、さらにはAIを活用したスマートな統合手法をマスターしましたね。 さて、ブランチを合流させる手段として前回まで「マージ（git merge）」を使ってきましたが、Gitにはもう一つ、プロの開発者が愛用する極めて強力な合流・整頓コマンドが存在します。 それが本日学ぶ 「リベース（git rebase）」 です！ Subversion (SVN) や Visual SourceSafe (VSS) に長く慣れ親しんだエンジニアの方にとって、「過去の分岐点を付け替える」「コミット履歴を一本の直線に作り直す」という概念は、最初まさに異次元の魔法のように感じられるでしょう。 「リベースを使うと何が嬉しいのか？」「マージと何が違うのか？」そして何より 「絶対にやってはいけない禁忌（リベースの黄金律）」 とは何か？ Windows/C#エンジニアの視点から、TortoiseGitの直感操作も交えて世界一わかりやすく徹底解説します！ ① 導入・本日の達成目標 「Gitのコミットグラフが複雑に枝分かれして、まるでタコ足配線やスパゲッティのように絡み合って読めない……」 開発が長期化したりメンバーが増えたりすると、無数の「マージコミット」が乱立し、どの機能がいつどこで入ったのか履歴を追うのが困難になることがあります。 この問題を解決し、 「あたかも最初から一直線に開発が進んでいたかのような、美しく整然とした履歴」 を作り出すのが「リベース」の役割です。 本日の講義でマスターする達成目標は以下の3点です！ ...

▲ Day 16: ASP.NET Core Web APIのコンテナ化（初めてのDockerfile作成） 🐳 皆さん、こんにちは！ Docker/コンテナ実践講座の専任講師です。 いよいよ本日より 「第4部: C# / .NET アプリケーションのコンテナ化（Dockerfile）」 が幕を開けます！ これまでは既存のnginxやhello-worldコンテナを起動・操作・デバッグする基礎を学んできましたが、今日からは私たちが普段開発している 「本物のC# / ASP.NET Core Web APIアプリケーション」 を自分自身の手でコンテナ化する本丸の領域へ突入します！ 「IISの手順書構築しかやったことがない」という30年選手のベテランエンジニアの皆さんも、Dockerfileの基本命令（FROM, WORKDIR, COPY, RUN, ENTRYPOINT）を一度理解してしまえば、サーバー構築の常識が180度変わる快感を味わっていただけます！ ① 導入・本日の達成目標 Dockerの本当の価値は、誰かが作ったイメージを動かすことではなく、 「自分たちの業務アプリケーションを再現性100%のイメージとしてパッケージングする」 ことにあります。 その中心となる設計図が Dockerfile です。 本日の講義を終える頃には、以下の3つの目標を完全にクリアできるようになります。 Dockerfileの基本構文である 5大命令（FROM, WORKDIR, COPY, RUN, ENTRYPOINT） の役割と実行順序を論理的に理解できる。 IISの手動仮想ディレクトリ構築とDockerfileの違い を把握し、インフラをGitでコード管理するメリットを体感できる。 実際に dotnet publish で出...

👨‍🏫 皆さん、こんにちは！ 本講座の専任講師です。 昨日のDay 12では、「Fast-Forward（早送り）」と「3-Way Merge（3方向マージ）」の仕組みを学び、Gitが共通の祖先（Base）を自動探索してスマートにコードを統合してくれる頼もしさを実感していただきました。 しかし、チーム開発やAIを活用した並行開発を進める中で、誰もが必ず直面する壁があります。それが 「コンフリクト（競合・衝突）」 です。 Subversion (SVN) や Visual SourceSafe (VSS) を長く使ってきた方にとって、競合は「誰かがファイルをロックし忘れて上書き事故を起こした！」「謎の .mine や .r123 ファイルが勝手に生成されてフォルダが散らかった！」という悪夢の記憶かもしれません。 しかし、断言します。 Gitにおけるコンフリクトは、決して「失敗」でも「バグ」でもありません！ 「同じファイルの同じ箇所を同時に変更したため、Gitが勝手にどちらかを捨てず、人間の知性に判断を委ねてくれた安全ストッパー」なのです。 本日は第13回として、コンフリクトマーカー（ <<<<<<< ）の正確な読み方、Windows開発でお馴染みの TortoiseMergeによる3画面（3ペイン）GUI結合 、そして現代最強の切り札である AI（Claude Code / ChatGPT）を用いたスマートな競合解消テクニック を余すところなく伝授します！ ① 導入・本日の達成目標 「マージしたら赤文字で CONFLICT と怒られた……どうしよう、コードが壊れた！？」 Gitを使い始めた初心者が最もパニックに陥りやすい瞬間が、このコンフリクト発生時です。 しかし、そのメカニズムと解決ツー...