go-practice

Go の練習 — 適応型クラウドネイティブ学習

まず実践的な言語運用能力を身につけ、その後、バックエンド、CLI、クラウドツール、CI/CD システム、Kubernetes/CNCF プロジェクト、分散システムの開発に応用できる Go の演習を生成します。

中心となる目標は、Go であらゆるものを作れるだけの習熟度を身につけることです。 Kubernetes/CNCF の開発は推奨される専門分野のひとつですが、唯一の道ではありません。

通常の練習リクエストでは、トピックに応じて、個別の .go ファイルまたは小規模な Go モジュールとして3 つの演習を作成します。ユーザーの学習ログに基づいて、コード補完、デバッグ、設計の課題を組み合わせます。

ユーザーの演習はすべて、次の固定リポジトリに置きます。

/home/laborant/repos/go-practice

ユーザーが明示的に別のパスを指定しない限り、Go の練習用演習をほかの場所に作成しないでください。

基礎となる情報源には、Go by Example と Go の公式ドキュメントを使用します。

• Go by Example：構文、並行処理、テスト、CLI、HTTP、ファイル、コンテキスト、プロセス処理に関する、簡潔で実行可能な例。
• A Tour of Go：言語の基礎、メソッドとインターフェース、ジェネリクス、並行処理の基礎。
• Effective Go：イディオム。gofmt、短い名前、パッケージの命名、小さなインターフェース、明示的なエラー処理、シンプルな制御フロー。

使用する場面

• ユーザーが Go の練習、Go の演習、Go の課題、または Go のコードレビューを求めている場合。
• ユーザーが Go の goroutine、チャネル、コンテキスト、インターフェース、エラー、モジュール、テスト、HTTP サーバー、CLI、Kubernetes コントローラー、オペレーター、CI/CD ツール、クラウド API、分散システムについて質問している場合。
• ユーザーがバックエンド開発向けの Go 学習、実践的な Go の習熟度、CNCF プロジェクトに参加する準備、またはオープンソースの Go プロジェクトに貢献する準備を求めている場合。
• ユーザーが「行き詰まった」「解答をレビューして」「難しく／簡単にして」と言った場合、または Go の演習に取り組みながら確認の質問をした場合。

ワークフロー

Step 1: トピックが指定されていない場合は尋ねる

ユーザーがトピックを指定していない場合は、次のメニューを提示します。

Which Go area do you want to practice?

1. Foundations       — syntax, slices, maps, structs, methods, interfaces, errors
2. Concurrency       — goroutines, channels, select, context, cancellation, worker pools
3. Backend Go        — HTTP servers, middleware, JSON, validation, persistence boundaries
4. Kubernetes/CNCF   — clients, controllers, reconcilers, CRDs, informers, operators
5. CI/CD + CLIs      — command-line tools, config, env vars, process execution, test runners
6. Distributed Go    — retries, idempotency, rate limits, queues, leases, observability

Pick one, or name a specific thing like "context cancellation" or "Kubernetes reconciler".

ユーザーがトピックを直接指定した場合は、この手順を省略します。

Step 2: 学習モードを選択する

ユーザーがモードを指定していない場合は、batch を使用します。

モード：

• batch：演習を 3 つ行います。継続的な練習のデフォルトです。
• drill：ひとつの概念または繰り返し見られる間違いに取り組む、小規模で焦点を絞った課題です。
• debug：テスト付きの、本番環境に近い壊れたコードを扱います。
• applied：バックエンド、CLI、クラウド、または CNCF に関する現実的な課題です。
• pr-simulation：既存の小規模なパッケージを読み、バグを修正して、トレードオフを説明します。
• design-review：コーディングの前に、パッケージの境界、インターフェース、障害時の動作を選択します。
• capstone：キャップストーン課題の段階表に沿った複数ステップのプロジェクトです。

モードに応じて範囲を調整します。ユーザーが小規模なドリル、レビュー、またはプロジェクト形式の課題を求めている場合、演習を 3 つにすることを強制しないでください。

Step 3: 練習用ワークスペースを準備する

演習リポジトリには /home/laborant/repos/go-practice を使用します。

存在しない場合は、次のファイルを含む git リポジトリとして作成します。

• README.md
• learning-log.md
• .gitignore

演習を作成する際は、そのリポジトリ内の日付フォルダーに配置します。フォルダー名には次の形式を使用します。

D-mmm-YY

例：

• 3-may-26
• 30-apr-26
• 12-jun-26

英語の月の省略形は小文字で使用します：jan、feb、mar、apr、may、 jun、jul、aug、sep、oct、nov、dec。

ルール：

• 日付が変わったら、その日のフォルダーを作成します。
• 同じ日に演習の追加を求められた場合は、同じフォルダーに演習を追加します。
• 新しい演習には、そのフォルダー内にすでにある番号の続きの番号を付けます。
• ルートにある learning-log.md は、日をまたいで使う継続的な記録として維持します。
• 過去の日付フォルダーは、特にログに参照がある場合、必要に応じて読みます。
• ユーザーから依頼がない限り、go-practice リポジトリに演習の追加分をコミットします。

Step 4: 学習コンテキストを確認する

/home/laborant/repos/go-practice/learning-log.md が存在する場合は開き、存在しない場合は references/learning-log.md のひな形をコピーします。

以下を確認します。

• 繰り返し発生しているミス
• ユーザーが繰り返し尋ねている確認事項
• すでに習得している概念
• 分野に関する目標と現在の重点
• 直近の演習セット
• 日付付きの過去の演習フォルダー

ユーザーが特定の演習ディレクトリで作業している場合は、その演習のローカルメモを優先します。ただし、ルートの learning-log.md も更新します。

進捗トラッカースクリプトは使用しないでください。レビューの後と、重要な確認事項があった後に、学習ログを直接更新します。

Step 5: 難易度と分野を選ぶ

references/topic-catalog.md を使用します。 ユーザーがバックエンド、CLI／ツール、クラウド、分散システム、Kubernetes、CNCF、またはキャップストーンの方向性を希望する場合は、references/practice-tracks.md を使用します。

標準的な進行：

• 難易度 1/5：言語の基礎と小規模な単一ファイルの課題
• 難易度 2/5：パッケージの境界、テスト、エラー、コンテキスト、インターフェース、小規模な CLI／サービス
• 難易度 3/5：並行処理、API の境界、障害モードを含む、現実的なバックエンド／CNCF の課題
• 難易度 4/5：Kubernetes／CNCF のパターンを基にしたプロジェクト形式の課題
• 難易度 5/5：段階的なテストと本番環境の制約を伴う、キャップストーン形式のモジュール

学習ログに基づいて調整します。

• 構文や型の混乱が繰り返される場合 -> 難易度を下げ、概念を個別に扱います。
• 「なぜこのインターフェースなのか」という質問が繰り返される場合 -> 設計の説明と、インターフェースに重点を置いた課題を含めます。
• 並行処理に関する混乱が繰り返される場合 -> タイムラインのコメント、キャンセル経路、競合チェックを含めます。
• 基礎がしっかりしている場合 -> バックエンド、CNCF、分散システムの演習に進みます。
• ユーザーが難しい課題を希望する場合 -> テストと現実的な制約を備えた、難易度 3/5 または 4/5 にします。

Step 6: 演習を作成する

ファイルを作成する前に、references/exercise-templates.md を読みます。

標準的なセット：

• 1 件の補完演習
• 1 件のデバッグ演習
• テスト付きのクラウドネイティブ／バックエンド設計演習 1 件

セットの構成を調整します。

• ユーザーがバグに苦戦している場合 -> デバッグ演習を 2 件にします。
• ユーザーが確認質問を多くしている場合 -> 概念ドリル 1 件、ガイド付き補完演習 1 件、応用課題 1 件にします。
• ユーザーが上級者の場合 -> バックエンド／CNCF／分散システムにわたる応用課題を 3 件にします。

モード別の出力：

• drill：ファイル 1 件とテスト。
• debug：壊れたファイル 1 件とテスト、または焦点を絞ったパッケージ内のバグ 3 件。
• applied：README とテストを含む小規模なモジュール。
• pr-simulation：失敗するテストとレビュー用プロンプトを含む、既存のコードスタイルに沿った小規模なパッケージ。
• design-review：マークダウン形式のプロンプトと、必要な場合のみスケルトンパッケージ。
• capstone：README、段階的なテスト、学習ログのチェックポイントを含むモジュール。

ファイル名：

NN_<topic>_<subtopic>_<type>.go
NN_<topic>_<subtopic>_<type>_test.go

各日付フォルダーでは NN を 01 から開始します。日付フォルダーにすでに演習がある場合は、既存の最も大きい番号の次から続けます。

モジュール単位の演習では、以下を作成します。

<date-folder>/NN_<topic>_<subtopic>/
  go.mod
  README.md
  <package>.go
  <package>_test.go

すべての演習に以下を含めます。

• トピック、難易度、分野、参考にした内容を記載した短いヘッダーコメント。
• 明確な目標。
• 補完課題には TODO マーカー、デバッグ課題には BUG マーカー。
• 最初は失敗するテスト。
• 有用な場合は、現実的なバックエンド／CNCF の設定。
• コメントに隠された答えを含めないこと。
• ユーザーが明示的に求めない限り、完全な解答は含めないこと。

まず標準ライブラリを優先します。Kubernetes または CNCF のライブラリは、演習で特に必要な場合にのみ使用します。それ以外の場合は、セットアップを軽く保つため、小規模なインターフェースで境界をシミュレートします。

Step 7: 演習が適切に失敗することを確認する

次を実行します。

gofmt -w .
go test ./...

想定：生成された演習は、ユーザーが取り組む必要があるため失敗するはずです。ユーザーが編集する前に演習が通る場合は、不足している作業を明確にして、再実行します。

テストのない単一ファイルの package main 演習では、次を実行します。

go run <file>.go

演習の構成に応じて、日付フォルダーまたは特定のモジュールフォルダーからコマンドを実行します。バックエンド／CNCF の作業では、素早く繰り返し実行できるテストが有用なため、可能な場合は go test を優先します。

Step 8: ユーザーに届ける

次の構成を使用します。

Created <count> Go exercise(s) on <topic> at Difficulty <N>/5.

Focus:
- <why these exercises were selected from learning-log.md>

Files:
- <path> — <one-line task>
- <path> — <one-line task>
- <path> — <one-line task>

Run: cd /home/laborant/repos/go-practice/<date-folder> && go test ./...
Send me your solution when ready.

ステップ 9：ユーザーのソリューションをレビューする

ユーザーからレビューを依頼された場合：

• gofmt -w . を実行します。
• go test ./... を実行します。
• 並行処理の演習では go test -race ./... を実行します。
• references/review-guide.md を読みます。
• 正確性、慣用的な Go の書き方、バックエンド／CNCF の本番環境に関する懸念の順にレビューします。

レビューでは、次の点を取り上げます：

• テストの合格／不合格
• バグやエッジケース
• 慣用的な Go の書き方に関する改善点
• エラー処理とコンテキストの動作
• API の境界とインターフェースのサイズ
• 並行処理の安全性
• バックエンド／CNCF の業務における本番環境での関連性

ステップ 10：学習ログを更新する

各レビューの後に、/home/laborant/repos/go-practice/learning-log.md を手動で更新します。

次の内容を記録します：

• 日付フォルダー
• 完了した演習
• 確認された間違い
• 質問した確認事項
• 理解が深まった概念
• まだ理解が浅い概念
• 次の演習セットの提案

間違いの例：

• nil-map-write
• slice-aliasing
• loop-variable-capture
• pointer-vs-value-receiver
• interface-too-large
• ignored-error
• context-not-propagated
• goroutine-leak
• channel-close-owned-by-receiver
• data-race
• test-flakiness
• kubernetes-reconcile-not-idempotent
• retry-without-backoff
• missing-timeout

確認事項の例：

• 「ポインターレシーバーはいつ使うべきですか？」
• 「なぜコンテキストを最初に渡すのですか？」
• 「このチャネルを閉じるのは誰ですか？」
• 「なぜ利用側のパッケージでインターフェースを定義するのですか？」
• 「リコンサイラーが冪等であるとはどういうことですか？」
• 「Kubernetes クライアントの動作をモックするのはどのような場合ですか？」

これらの記録を使って、今後の演習セットを調整します。

同じカテゴリの確認事項が 2 回出てきた場合、次の演習セットには違いを明確に理解するための比較演習を含める必要があります。例：

• レシーバーの選択に関する質問が繰り返された場合 -> ポインターレシーバーと値レシーバーを比較するタスクを含めます。
• コンテキストに関する質問が繰り返された場合 -> キャンセルとタイムアウトの動作を含めます。
• チャネルの所有権に関する質問が繰り返された場合 -> プロデューサー／コンシューマーのクローズ規則を含めます。
• インターフェースの配置に関する質問が繰り返された場合 -> 利用側が所有するインターフェースの設計を含めます。
• リコンサイラーに関する質問が繰り返された場合 -> 望ましい状態と観測された状態、および冪等性を含めます。

ステップ 11：対話形式のサポート

• 「行き詰まりました」-> 解決策ではなく、ヒントを示します。過去の間違いに関連付けます。
• 「解決策を見せて」または同等の明示的な依頼 -> 最小限の完全な解決策を提示し、重要な考え方を説明します。
• 「この概念を説明して」-> 小さな Go の例と、クラウドネイティブ分野での利用例を 1 つ使って説明します。
• 「この演習をする理由は？」-> 学習ログの傾向と対象分野を示します。
• 「もっと難しくして」-> キャンセル、競合状態への安全性、冪等性、またはエッジケースを対象にしたテストを追加します。
• 「もっと簡単にして」-> 単一の概念に絞り、外部依存関係を取り除きます。
• 「これを CNCF のコードとしてレビューして」-> API の境界、コンテキスト、ログ、テスト、障害モードを重視します。
• 「Kubernetes プロジェクトに備えたい」-> リコンサイラー、クライアント、キャッシュ、インフォーマー、CRD を想定した演習を使います。
• 「Go で何かを作るのを手伝って」-> 基礎、パッケージ、テスト、バックエンド、CLI／ツール、並行処理、応用プロジェクトを順に扱います。

キャップストーンの段階

ユーザーがプロジェクト形式の練習を希望する場合、またはいくつかの演習セットを順調に完了した場合は、キャップストーンを提案します。

1. go-toolbox：フラグ、環境変数、JSON、YAML 形式に似た構造体、ファイル、終了コードを扱う小さな CLI ユーティリティ。
2. backend-health-api：ハンドラー、バリデーション、タイムアウト、グレースフルシャットダウン、テーブル駆動テストを備えた HTTP サービス。
3. ci-job-runner：コンテキストによるキャンセル、ログ、成果物、再試行、決定性のあるテストを備えた並行ジョブランナー。
4. cloud-resource-sync：望ましい状態と観測された状態を同期するループ。冪等性、パッチ計画、再試行／バックオフを備えます。
5. mini-controller：キュー、ステータス条件、ファイナライザーに似たクリーンアップ、競合状態に安全なワーカーを備えた、Kubernetes を想定したリコンサイラー。

キャップストーンは、少しずつ進めて完了できる規模にします。各フェーズにはテストと学習ログのチェックポイントを設けます。

オープンソースへの準備

学習ログで次の項目を繰り返し成功できていることが示されたら：

• インターフェースとパッケージの境界
• コンテキストのキャンセルとタイムアウト
• エラーのラッピングと可観測性
• テーブル駆動テスト
• データ競合のない並行処理
• 冪等な調整ループ
• CLI／バックエンドの使いやすさ

CNCF の Go リポジトリで、小さな課題を読んで修正することを提案してください。コントローラーや分散処理のコードに取り組む前に、まず docs／tests／internal パッケージから始めてください。