@k2works/claude-code-booster 3.0.0 → 3.1.0

package/lib/assets/docs/article/getting-start-tdd/csharp/chapter12.md

@@ -0,0 +1,211 @@
+# 第 12 章: エラーハンドリングと型安全性
+
+## 12.1 はじめに
+
+前章では LINQ チェーンによるパイプライン処理を学びました。この最終章では、C# の **Nullable 参照型** と **パターンマッチング** を使ったエラーハンドリングと型安全性を学びます。
+
+## 12.2 Nullable 参照型
+
+C# 8.0 以降では、Nullable 参照型を有効にすることで null 安全性をコンパイル時にチェックできます。
+
+```xml
+<PropertyGroup>
+  <Nullable>enable</Nullable>
+</PropertyGroup>
+```
+
+### null 許容型と非 null 型
+
+```csharp
+string name = "hello";    // 非 null 型（null を代入するとコンパイラ警告）
+string? nullable = null;  // null 許容型（null を許容）
+```
+
+### FizzBuzzList での活用
+
+`FindFirst` メソッドは一致する要素が見つからない場合に `null` を返します。
+
+```csharp
+public FizzBuzzValue? FindFirst(Func<FizzBuzzValue, bool> predicate)
+{
+    return _values.FirstOrDefault(predicate);
+}
+```
+
+戻り値の型 `FizzBuzzValue?` は「null の可能性がある」ことを明示します。Rust の `Option<T>` に相当する C# の表現方法です。
+
+### テストの作成
+
+```csharp
+[Fact]
+public void 最初の一致する値を取得できる()
+{
+    var list = new FizzBuzzList(new List<FizzBuzzValue>
+    {
+        new FizzBuzzValue(1, "1"),
+        new FizzBuzzValue(3, "Fizz"),
+        new FizzBuzzValue(6, "Fizz")
+    });
+    var found = list.FindFirst(v => v.Value == "Fizz");
+    Assert.NotNull(found);
+    Assert.Equal(3, found.Number);
+}
+
+[Fact]
+public void 一致する値がない場合はnullを返す()
+{
+    var list = new FizzBuzzList(new List<FizzBuzzValue>
+    {
+        new FizzBuzzValue(1, "1"),
+        new FizzBuzzValue(2, "2")
+    });
+    var found = list.FindFirst(v => v.Value == "Fizz");
+    Assert.Null(found);
+}
+```
+
+## 12.3 パターンマッチング
+
+C# のパターンマッチングは `switch` 式で豊富なパターンを記述できます。
+
+### switch 式
+
+`FizzBuzzTypeFactory` は `switch` 式を使って型安全なファクトリを実現しています。
+
+```csharp
+public static IFizzBuzzType Create(int type)
+{
+    return type switch
+    {
+        1 => new FizzBuzzType01(),
+        2 => new FizzBuzzType02(),
+        3 => new FizzBuzzType03(),
+        _ => throw new ArgumentException($"Invalid FizzBuzz type: {type}")
+    };
+}
+```
+
+C# の `switch` 式は Rust の `match` 式に近く、値を返す式として使えます。`_` はデフォルトケース（Rust のワイルドカードに相当）です。
+
+### 型パターン
+
+`is` キーワードと型パターンで、オブジェクトの型をチェックしながらキャストできます。
+
+```csharp
+public bool Equals(object? obj)
+{
+    if (obj is FizzBuzzValue other)
+    {
+        return Number == other.Number && Value == other.Value;
+    }
+    return false;
+}
+```
+
+`obj is FizzBuzzValue other` は「`obj` が `FizzBuzzValue` 型であれば `other` に代入する」というパターンマッチングです。Rust の `if let Some(value) = option` に近い表現です。
+
+### null チェックパターン
+
+```csharp
+public bool Equals(FizzBuzzValue? other)
+{
+    if (other is null) return false;        // null パターン
+    if (ReferenceEquals(this, other)) return true;
+    return Number == other.Number && Value == other.Value;
+}
+```
+
+### FizzBuzzTypeName enum と switch 式
+
+```csharp
+public enum FizzBuzzTypeName
+{
+    Standard = 1,
+    NumberOnly = 2,
+    FizzBuzzOnly = 3
+}
+
+public static IFizzBuzzType Create(FizzBuzzTypeName name)
+{
+    return Create((int)name);
+}
+```
+
+enum を使うことで、タイプ番号をハードコーディングせずに型安全に指定できます。
+
+### テストの作成
+
+```csharp
+public class FizzBuzzTypeFactoryTest
+{
+    [Fact]
+    public void タイプ1を生成できる()
+    {
+        var type = FizzBuzzTypeFactory.Create(1);
+        Assert.IsType<FizzBuzzType01>(type);
+    }
+
+    [Fact]
+    public void 不正なタイプは例外を投げる()
+    {
+        Assert.Throws<ArgumentException>(
+            () => FizzBuzzTypeFactory.Create(0));
+    }
+
+    [Fact]
+    public void Enumで生成できる()
+    {
+        var type = FizzBuzzTypeFactory.Create(FizzBuzzTypeName.Standard);
+        Assert.IsType<FizzBuzzType01>(type);
+    }
+}
+```
+
+## 12.4 例外ハンドリング
+
+C# では `try-catch` と例外型の階層で例外を処理します。Rust の `Result<T, E>` とは異なるアプローチです。
+
+```csharp
+try
+{
+    var type = FizzBuzzTypeFactory.Create(0);
+}
+catch (ArgumentException ex)
+{
+    Console.WriteLine($"エラー: {ex.Message}");
+}
+```
+
+### Rust との比較
+
+| 概念 | C# | Rust |
+|------|------|------|
+| エラーの表現 | 例外（`Exception`） | `Result<T, E>` |
+| エラーの伝播 | `throw` / `try-catch` | `?` 演算子 |
+| null の表現 | `T?`（Nullable 参照型） | `Option<T>` |
+| null チェック | `is null` パターン | `match` / `if let` |
+
+C# は例外ベースのエラーハンドリングですが、Nullable 参照型とパターンマッチングにより、null に起因するバグをコンパイル時に検出できるようになっています。
+
+## 12.5 他言語との比較
+
+| 概念 | C# | Rust | Java | TypeScript |
+|------|------|------|------|------|
+| エラーハンドリング | `try-catch` | `Result<T, E>` | `try-catch` | `try-catch` |
+| null 安全 | `T?` (Nullable) | `Option<T>` | `Optional<T>` | `T \| null` |
+| 列挙型 | `enum`（整数ベース） | `enum`（代数的データ型） | `enum`（クラスベース） | `enum`（数値/文字列） |
+| パターンマッチ | `switch` 式 + 型パターン | `match`（網羅性チェック） | `switch` + `instanceof` | — |
+| エラー伝播 | `throw` | `?` 演算子 | `throws` | `throw` |
+
+## 12.6 まとめ
+
+この章では以下を学びました。
+
+| 概念 | C# の実現方法 |
+|------|-------------|
+| null 安全 | Nullable 参照型 (`T?`) + `<Nullable>enable</Nullable>` |
+| パターンマッチ | `switch` 式 + 型パターン + null パターン |
+| 型安全なファクトリ | `enum` + `switch` 式 |
+| 例外ハンドリング | `ArgumentException` + `try-catch` |
+
+全 12 章を通じて、C# の TDD 基本サイクル、開発環境の自動化、オブジェクト指向的な設計、関数型プログラミングの活用を一通り学びました。C# の強力な型システム、interface / abstract class、LINQ、Nullable 参照型、パターンマッチングは、安全で堅牢なソフトウェアを構築するための強力な基盤です。

package/lib/assets/docs/article/getting-start-tdd/csharp/index.md

@@ -0,0 +1,83 @@
+# テスト駆動開発から始める C# 入門
+
+## 概要
+
+FizzBuzz 問題を題材に、テスト駆動開発（TDD）の基本サイクルから、開発環境の整備、オブジェクト指向設計、関数型プログラミングの活用まで、C# の特徴を活かしながら段階的に学びます。
+
+## 対象読者
+
+- C# の基本文法を理解しているプログラミング学習者
+- TDD を体験してみたい開発者
+- オブジェクト指向設計や LINQ による関数型プログラミングに興味がある方
+
+## 前提条件
+
+- .NET 8.0 SDK 以降がインストールされていること
+- dotnet CLI が利用可能であること（Nix 環境推奨: `nix develop .#dotnet`）
+
+## C# の特徴
+
+| 特徴 | 説明 |
+|------|------|
+| 静的型付け + 型推論 | 強力な型システムと `var` による型推論 |
+| オブジェクト指向 | class, interface, abstract class による本格的な OOP |
+| 関数型要素 | LINQ, ラムダ式, デリゲートによる関数型プログラミング |
+| Nullable 参照型 | null 安全性をコンパイル時に検査 |
+| パターンマッチング | switch 式、型パターン、プロパティパターン |
+| クロスプラットフォーム | .NET による Windows / macOS / Linux 対応 |
+
+## 開発ツール
+
+| ツール | 用途 |
+|--------|------|
+| [xUnit.net](https://xunit.net/) | テスティングフレームワーク |
+| [NuGet](https://www.nuget.org/) | パッケージマネージャ |
+| [dotnet format](https://learn.microsoft.com/dotnet/core/tools/dotnet-format) | コードフォーマッター |
+| [Microsoft.CodeAnalysis.Analyzers](https://github.com/dotnet/roslyn-analyzers) | 静的コード解析 |
+| [Cake](https://cakebuild.net/) | ビルドスクリプト |
+
+## 目次
+
+### 第 1 部: TDD の基本サイクル
+
+1. [第 1 章: TODO リストと最初のテスト](chapter01.md)
+2. [第 2 章: 仮実装と三角測量](chapter02.md)
+3. [第 3 章: 明白な実装とリファクタリング](chapter03.md)
+
+### 第 2 部: 開発環境と自動化
+
+4. [第 4 章: バージョン管理と Conventional Commits](chapter04.md)
+5. [第 5 章: パッケージ管理と静的解析](chapter05.md)
+6. [第 6 章: タスクランナーと CI/CD](chapter06.md)
+
+### 第 3 部: オブジェクト指向設計
+
+7. [第 7 章: カプセル化とポリモーフィズム](chapter07.md)
+8. [第 8 章: デザインパターンの適用](chapter08.md)
+9. [第 9 章: SOLID 原則とモジュール設計](chapter09.md)
+
+### 第 4 部: 関数型プログラミングへの展開
+
+10. [第 10 章: 高階関数と関数合成](chapter10.md)
+11. [第 11 章: 不変データとパイプライン処理](chapter11.md)
+12. [第 12 章: エラーハンドリングと型安全性](chapter12.md)
+
+## 実装コード
+
+本記事のすべてのコード例は `apps/dotnet/` に実装されています。
+
+```bash
+# 開発環境に入る
+nix develop .#dotnet
+
+# テスト実行
+cd apps/dotnet
+dotnet test
+```
+
+## 参考文献
+
+- Kent Beck 著『テスト駆動開発』
+- Martin Fowler 著『リファクタリング: 既存のコードを安全に改善する』
+- Robert C. Martin 著『Clean Code: アジャイルソフトウェア達人の技』
+- Microsoft『C# プログラミングガイド』

package/lib/assets/docs/article/getting-start-tdd/elixir/01-todo-list-and-first-test.md

@@ -0,0 +1,87 @@
+# 第 1 章: TODO リストと最初のテスト
+
+## 1.1 はじめに
+
+この章では、FizzBuzz 問題を小さな TODO リストに分解し、ExUnit で最初のテストを書きます。TDD の最初の一歩は、いきなり実装することではなく、失敗するテストから始めることです。
+
+## 1.2 FizzBuzz の仕様と TODO リスト
+
+対象の仕様は次のとおりです。
+
+```text
+1 から 100 までの数を出力する。
+3 の倍数は Fizz、5 の倍数は Buzz、3 と 5 の両方の倍数は FizzBuzz を出力する。
+```
+
+まずは仕様を TODO リストに分解します。
+
+- [ ] 数を文字列として返す
+- [ ] 3 の倍数で Fizz を返す
+- [ ] 5 の倍数で Buzz を返す
+- [ ] 15 の倍数で FizzBuzz を返す
+- [ ] 1 から 100 までの結果をリストで作る
+
+最初のタスクとして「1 を渡すと文字列 1 を返す」だけを扱います。
+
+## 1.3 ExUnit の基本
+
+Elixir では `mix new` で作成したプロジェクトに ExUnit が標準で含まれます。最小のテストは `test` マクロと `assert` マクロで書けます。
+
+```elixir
+# test/fizz_buzz_test.exs
+
+defmodule FizzBuzzTest do
+  use ExUnit.Case
+
+  test "1 を渡すと文字列 1 を返す" do
+    assert FizzBuzz.generate(1) == "1"
+  end
+end
+```
+
+- `test` はテストケースを定義します。
+- `assert` は期待値を検証します。
+
+## 1.4 mix test の使い方
+
+テスト実行は `mix test` を使います。
+
+```bash
+$ mix test
+```
+
+この時点では `FizzBuzz` モジュールが未実装なので、テストは失敗します。これが Red です。
+
+## 1.5 Red から Green へ
+
+### Red: 最初の失敗するテスト
+
+先ほどのテストを実行すると、例えば次のように失敗します。
+
+```text
+** (UndefinedFunctionError) function FizzBuzz.generate/1 is undefined
+```
+
+### Green: 仮実装で通す
+
+まずは最小限の仮実装でテストを通します。
+
+```elixir
+# lib/fizz_buzz.ex
+
+defmodule FizzBuzz do
+  def generate(1), do: "1"
+end
+```
+
+再度 `mix test` を実行します。
+
+```bash
+$ mix test
+```
+
+1 件のテストが成功すれば Green です。まだ汎用的ではありませんが、TDD ではこの小さな成功を積み重ねます。
+
+## 1.6 まとめ
+
+この章では、TODO リスト駆動で最小タスクを切り出し、ExUnit の `test` / `assert` と `mix test` の基本を確認しました。さらに、最初の失敗するテストを書いてから仮実装で成功させる Red → Green を体験しました。

package/lib/assets/docs/article/getting-start-tdd/elixir/02-fake-it-and-triangulation.md

@@ -0,0 +1,95 @@
+# 第 2 章: 仮実装と三角測量
+
+## 2.1 はじめに
+
+前章では「1 を渡すと文字列 1 を返す」を仮実装で通しました。この章では、仮実装から三角測量へ進み、実装を一般化します。
+
+## 2.2 仮実装の限界
+
+前章の実装は次のようなハードコードでした。
+
+```elixir
+defmodule FizzBuzz do
+  def generate(1), do: "1"
+end
+```
+
+この実装は `1` 以外に対応できません。ここで新しいテストを追加して、一般化の必要性を明確にします。
+
+## 2.3 三角測量: 2 を追加する
+
+ExUnit の `describe` ブロックで関心ごとをまとめます。
+
+```elixir
+# test/fizz_buzz_test.exs
+
+defmodule FizzBuzzTest do
+  use ExUnit.Case
+
+  describe "generate/1" do
+    test "1 を渡すと文字列 1 を返す" do
+      assert FizzBuzz.generate(1) == "1"
+    end
+
+    test "2 を渡すと文字列 2 を返す" do
+      assert FizzBuzz.generate(2) == "2"
+    end
+  end
+end
+```
+
+`mix test` を実行すると失敗します。Green にするため、仮実装から一段進めます。
+
+```elixir
+# lib/fizz_buzz.ex
+
+defmodule FizzBuzz do
+  def generate(n), do: Integer.to_string(n)
+end
+```
+
+この変更で、`1` と `2` の両方が通ります。複数の具体例から実装を引き出すのが三角測量です。
+
+## 2.4 3 の倍数で Fizz
+
+次に、FizzBuzz の本題を追加します。
+
+```elixir
+# test/fizz_buzz_test.exs
+
+defmodule FizzBuzzTest do
+  use ExUnit.Case
+
+  describe "generate/1" do
+    test "1 を渡すと文字列 1 を返す" do
+      assert FizzBuzz.generate(1) == "1"
+    end
+
+    test "2 を渡すと文字列 2 を返す" do
+      assert FizzBuzz.generate(2) == "2"
+    end
+
+    test "3 の倍数を渡すと Fizz を返す" do
+      assert FizzBuzz.generate(3) == "Fizz"
+      assert FizzBuzz.generate(6) == "Fizz"
+    end
+  end
+end
+```
+
+これを通す最小実装は次のように書けます。
+
+```elixir
+# lib/fizz_buzz.ex
+
+defmodule FizzBuzz do
+  def generate(n) when rem(n, 3) == 0, do: "Fizz"
+  def generate(n), do: Integer.to_string(n)
+end
+```
+
+`mix test` が成功すれば Green です。
+
+## 2.5 まとめ
+
+この章では、ハードコードの仮実装から、複数ケースによる三角測量で一般化する流れを学びました。また、`describe` でテストを整理し、「2 を渡すと文字列 2」「3 の倍数で Fizz」を ExUnit で表現しました。

package/lib/assets/docs/article/getting-start-tdd/elixir/03-obvious-implementation-and-refactoring.md

@@ -0,0 +1,109 @@
+# 第 3 章: 明白な実装とリファクタリング
+
+## 3.1 はじめに
+
+この章では FizzBuzz の仕様を `cond` で明白に実装し、1 から 100 までのリスト生成まで完成させます。最後に、読みやすさを高めるリファクタリングの観点を確認します。
+
+## 3.2 cond による明白な実装
+
+まずは必要なテストを追加します。
+
+```elixir
+# test/fizz_buzz_test.exs
+
+defmodule FizzBuzzTest do
+  use ExUnit.Case
+
+  describe "generate/1" do
+    test "5 の倍数を渡すと Buzz を返す" do
+      assert FizzBuzz.generate(5) == "Buzz"
+    end
+
+    test "15 の倍数を渡すと FizzBuzz を返す" do
+      assert FizzBuzz.generate(15) == "FizzBuzz"
+    end
+  end
+end
+```
+
+このテストを通す明白な実装は次のとおりです。
+
+```elixir
+# lib/fizz_buzz.ex
+
+defmodule FizzBuzz do
+  def generate(n) do
+    cond do
+      rem(n, 15) == 0 -> "FizzBuzz"
+      rem(n, 3) == 0 -> "Fizz"
+      rem(n, 5) == 0 -> "Buzz"
+      true -> Integer.to_string(n)
+    end
+  end
+end
+```
+
+15 を先に判定することがポイントです。
+
+## 3.3 1 から 100 までのリスト生成
+
+続いて、結果一覧を作る関数のテストを書きます。
+
+```elixir
+# test/fizz_buzz_test.exs
+
+defmodule FizzBuzzTest do
+  use ExUnit.Case
+
+  describe "generate_list/0" do
+    test "1 から 100 までの FizzBuzz リストを返す" do
+      result = FizzBuzz.generate_list()
+
+      assert length(result) == 100
+      assert Enum.at(result, 0) == "1"
+      assert Enum.at(result, 2) == "Fizz"
+      assert Enum.at(result, 4) == "Buzz"
+      assert Enum.at(result, 14) == "FizzBuzz"
+    end
+  end
+end
+```
+
+実装はパイプライン演算子 `|>` を使うと読みやすくなります。
+
+```elixir
+# lib/fizz_buzz.ex
+
+defmodule FizzBuzz do
+  def generate(n) do
+    cond do
+      rem(n, 15) == 0 -> "FizzBuzz"
+      rem(n, 3) == 0 -> "Fizz"
+      rem(n, 5) == 0 -> "Buzz"
+      true -> Integer.to_string(n)
+    end
+  end
+
+  def generate_list do
+    1..100
+    |> Enum.map(&generate/1)
+  end
+end
+```
+
+`|>` は「左の結果を右の関数に渡す」演算子です。データの流れを上から下に読めるため、処理の意図が明確になります。
+
+## 3.4 リファクタリングのポイント
+
+テストがすべて通る状態を保ちながら、次を確認します。
+
+- 判定順が明確か（`15` → `3` → `5`）
+- 重複した変換処理がないか
+- 関数名が役割を正しく表しているか
+- テストの責務が分離されているか（`describe` ごとに関心を分ける）
+
+必要なら、テストデータを増やして安全に整理します。TDD では「動くこと」と「読みやすいこと」を両立させます。
+
+## 3.5 まとめ
+
+この章では、`cond` を使った明白な実装で `Buzz` と `FizzBuzz` を追加し、`1..100` のリスト生成を完成させました。さらに `|>` の基本と、テストを守りながら進めるリファクタリングの観点を確認しました。

package/lib/assets/docs/article/getting-start-tdd/elixir/04-version-control-and-conventional-commits.md

@@ -0,0 +1,96 @@
+# 第 4 章: バージョン管理と Conventional Commits
+
+## 4.1 はじめに
+
+この章では、Elixir プロジェクトを安全に育てるための Git の基本操作と、Conventional Commits の実践方法を学びます。TDD では小さな変更を頻繁にコミットするため、履歴の読みやすさが品質に直結します。
+
+## 4.2 Git の基本操作
+
+まずは作業の最小ループを押さえます。
+
+```bash
+# 変更確認
+git status
+
+# 差分確認
+git diff
+
+# ステージング
+git add lib/fizz_buzz.ex test/fizz_buzz_test.exs
+
+# コミット
+git commit -m "test: add test for fizzbuzz list generation"
+
+# 履歴確認
+git log --oneline --decorate -n 10
+```
+
+TDD では次の粒度でコミットすると履歴が明確です。
+
+- Red: 失敗するテスト追加
+- Green: テストを通す最小実装
+- Refactor: 振る舞いを変えない整理
+
+## 4.3 Conventional Commits のルール
+
+Conventional Commits は、コミットメッセージを `type: summary` 形式で統一する規約です。
+
+代表的な `type` は次のとおりです。
+
+- `feat`: ユーザーに見える機能追加
+- `fix`: バグ修正
+- `docs`: ドキュメント変更
+- `refactor`: 振る舞いを変えない内部改善
+- `test`: テスト追加・修正
+- `chore`: ビルドや設定などの雑務変更
+
+例:
+
+```text
+feat: add generate_list/0 for 1..100 fizzbuzz output
+fix: handle 15 multiples before 3 and 5 checks
+docs: add chapter 4 for git workflow
+test: add cases for fizz and buzz boundaries
+refactor: simplify generate/1 with cond ordering
+chore: update ci cache key for nix flake
+```
+
+## 4.4 Elixir プロジェクトでのコミット例
+
+`apps/elixir` の FizzBuzz 実装を例に、実際のコミット単位を示します。
+
+```bash
+# Red
+git add test/fizz_buzz_test.exs
+git commit -m "test: add failing test for generate_list/0"
+
+# Green
+git add lib/fizz_buzz.ex
+git commit -m "feat: implement generate_list/0 with enum map"
+
+# Refactor
+git add lib/fizz_buzz.ex test/fizz_buzz_test.exs
+git commit -m "refactor: improve readability of fizzbuzz conditions"
+```
+
+ポイントは、1 コミット 1 意図です。`feat` と `refactor` を同一コミットに混ぜないことで、レビューしやすくなります。
+
+## 4.5 .gitignore の設定
+
+Elixir ではビルド成果物と依存パッケージを Git 管理対象から除外します。`apps/elixir/.gitignore` には少なくとも次を含めます。
+
+```gitignore
+/_build/
+/deps/
+.elixir_ls/
+```
+
+- `/_build/`: `mix compile` の生成物
+- `/deps/`: `mix deps.get` で取得される依存コード
+- `.elixir_ls/`: Elixir Language Server の作業ディレクトリ
+
+これらを除外すると、環境依存ファイルの混入を防げます。
+
+## 4.6 まとめ
+
+この章では、Git の基本操作、Conventional Commits の主要ルール、Elixir プロジェクトでの具体的なコミット例、`.gitignore` の重要設定を確認しました。以降の章では、この履歴運用を前提に品質チェックと自動化を強化します。