@k2works/claude-code-booster 6.1.0 → 6.3.0

package/lib/assets/docs/article/getting-start-tdd/clojure/06-task-runner-and-ci-cd.md

@@ -1,250 +0,0 @@
----
-type: Article
-title: "第 6 章: タスクランナーと CI/CD"
-description: "前章では静的コード解析ツールとコード複雑度チェッカーを導入しました。"
-tags: [article, getting-start-tdd, clojure]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 6 章: タスクランナーと CI/CD
-
-## 6.1 はじめに
-
-前章では静的コード解析ツールとコード複雑度チェッカーを導入しました。テストの実行、静的解析、複雑度チェック、フォーマットチェックと、様々なコマンドを使えるようになりましたが、毎回それぞれのコマンドを覚えて実行するのは面倒です。
-
-この章では **タスクランナー** を使ってこれらのタスクをまとめて実行できるようにし、さらに **Nix** による再現可能な開発環境と **GitHub Actions** による **CI/CD** パイプラインを構築します。
-
-## 6.2 Nix による開発環境
-
-### Nix とは
-
-> Nix は再現可能なビルドと宣言的な環境管理を提供するパッケージマネージャです。`flake.nix` で開発環境を定義すると、チームメンバー全員が同じツールチェインを使えます。
-
-本プロジェクトでは `nix develop .#clojure` コマンドで Clojure 開発に必要なすべてのツールが揃った環境に入れます。
-
-```bash
-$ nix develop .#clojure
-Clojure development environment activated
-  - Clojure: Clojure 1.11.x
-  - Leiningen: Leiningen 2.x.x
-  - Babashka: x.x.x
-  - Clojure LSP: x.x.x
-```
-
-### Nix 環境の構成
-
-`ops/nix/environments/clojure/shell.nix` で環境を定義しています。
-
-```nix
-{ packages ? import <nixpkgs> {} }:
-let
-  baseShell = import ../../shells/shell.nix { inherit packages; };
-in
-packages.mkShell {
-  inherit (baseShell) pure;
-  buildInputs = baseShell.buildInputs ++ (with packages; [
-    clojure
-    leiningen
-    babashka
-    clojure-lsp
-  ]);
-  shellHook = ''
-    ${baseShell.shellHook}
-    echo "Clojure development environment activated"
-  '';
-}
-```
-
-| パッケージ | 用途 |
-|-----------|------|
-| `clojure` | Clojure ランタイム（JVM 上） |
-| `leiningen` | プロジェクト管理・ビルドツール |
-| `babashka` | スクリプティング用 Clojure |
-| `clojure-lsp` | Language Server Protocol 実装 |
-
-### Nix を使う利点
-
-- **再現性** — `flake.lock` でバージョンを固定し、誰がいつビルドしても同じ結果
-- **分離** — システムの Clojure や Java に依存せず、プロジェクト専用の環境を構築
-- **CI 統合** — ローカルと CI で同じ `nix develop` コマンドを使い、環境差異をゼロに
-
-## 6.3 Makefile によるタスク管理
-
-### Makefile とは
-
-> Makefile は Unix 系の定番ビルド/タスク管理ツールである make の設定ファイルです。ターゲット（タスク名）と依存関係、実行コマンドを定義し、`make <ターゲット>` で実行できます。
-
-### Makefile の定義
-
-```makefile
-.PHONY: test lint kibit fmt fmt-check complexity bikeshed coverage check build run clean
-
-test:
-	lein test
-
-lint:
-	lein eastwood
-
-kibit:
-	lein kibit
-
-fmt:
-	lein cljfmt fix || true
-
-fmt-check:
-	lein cljfmt check || true
-
-complexity:
-	lein complexity
-
-bikeshed:
-	lein bikeshed
-
-coverage:
-	lein cloverage
-
-check: lint kibit complexity test
-
-build:
-	lein uberjar
-
-run:
-	lein run
-
-clean:
-	lein clean
-```
-
-### 主要なタスク
-
-| タスク | コマンド | 説明 |
-|--------|---------|------|
-| `make test` | `lein test` | テスト実行 |
-| `make lint` | `lein eastwood` | Eastwood による静的解析 |
-| `make kibit` | `lein kibit` | Kibit によるイディオム検査 |
-| `make complexity` | `lein complexity` | 循環複雑度チェック |
-| `make bikeshed` | `lein bikeshed` | コード品質チェック |
-| `make fmt` | `lein cljfmt fix` | コードフォーマット |
-| `make coverage` | `lein cloverage` | テストカバレッジ計測 |
-| `make check` | lint → kibit → complexity → test | 全チェック実行 |
-
-### 実行例
-
-```bash
-# Nix 環境に入る
-$ nix develop .#clojure
-
-# 全チェック実行
-$ make check
-lein eastwood
-== Warnings: 0. Exceptions thrown: 0
-lein kibit
-lein complexity
-=== Clojure 循環複雑度チェック (閾値: 7) ===
-関数数: 10, 違反: 0
-複雑度チェック: 成功
-lein test
-Ran 10 tests containing 38 assertions.
-0 failures, 0 errors.
-```
-
-## 6.4 GitHub Actions による CI/CD
-
-### CI/CD とは
-
-> CI/CD（Continuous Integration / Continuous Delivery）は、コードの変更を自動的にビルド、テスト、デプロイするプラクティスです。
-
-### ワークフローの定義
-
-`.github/workflows/clojure-ci.yml` にワークフローを定義します。ローカル開発と同じ **Nix** 環境を CI でも使用し、環境差異をゼロにします。
-
-```yaml
-name: Clojure CI
-
-on:
-  push:
-    branches: [main, develop]
-    paths:
-      - "apps/clojure/**"
-      - ".github/workflows/clojure-ci.yml"
-  pull_request:
-    branches: [main]
-    paths:
-      - "apps/clojure/**"
-
-permissions:
-  contents: read
-
-jobs:
-  test:
-    runs-on: ubuntu-latest
-
-    steps:
-      - name: Checkout the repository
-        uses: actions/checkout@v4
-
-      - name: Install Nix
-        uses: cachix/install-nix-action@v30
-        with:
-          nix_path: nixpkgs=channel:nixos-unstable
-
-      - name: Cache Nix store
-        uses: actions/cache@v4
-        with:
-          path: /tmp/nix-cache
-          key: ${{ runner.os }}-nix-clojure-${{ hashFiles('flake.lock', 'ops/nix/environments/clojure/shell.nix') }}
-          restore-keys: |
-            ${{ runner.os }}-nix-clojure-
-
-      - name: Run linter (Eastwood)
-        run: nix develop .#clojure --command bash -c "cd apps/clojure && lein eastwood"
-
-      - name: Run complexity check
-        run: nix develop .#clojure --command bash -c "cd apps/clojure && lein complexity"
-
-      - name: Run tests
-        run: nix develop .#clojure --command bash -c "cd apps/clojure && lein test"
-```
-
-### CI パイプラインの流れ
-
-```
-Push / PR → Checkout → Nix インストール → Nix キャッシュ復元
-→ Eastwood 静的解析 → 循環複雑度チェック → テスト実行 → 結果通知
-```
-
-### Nix 統合のポイント
-
-1. **`cachix/install-nix-action@v30`** — GitHub Actions ランナーに Nix をインストール
-2. **`nix develop .#clojure --command bash -c "..."`** — Nix 環境内でコマンドを実行
-3. **Nix ストアキャッシュ** — `flake.lock` と `shell.nix` のハッシュでキャッシュキーを生成し、ビルド時間を短縮
-4. **環境の一致** — ローカルの `nix develop .#clojure` と CI の環境が完全に同一
-
-## 6.5 他言語との比較
-
-| 言語 | タスクランナー | CI 環境 | テスト | 静的解析 | 複雑度チェック |
-|------|-------------|---------|--------|---------|-------------|
-| Clojure | Makefile | Nix | lein test | Eastwood + Kibit | 循環複雑度チェッカー |
-| Rust | Makefile | Nix | cargo test | Clippy | Clippy cognitive_complexity |
-| Go | Makefile | Nix | go test | golangci-lint | golangci-lint gocyclo |
-| Java | Gradle | setup-java | JUnit | Checkstyle + PMD | PMD CyclomaticComplexity |
-| Python | tox | Nix | pytest | Ruff | Ruff McCabe |
-| Node | npm scripts | Nix | Vitest | ESLint | ESLint complexity |
-| Ruby | Rake | Nix | Minitest | RuboCop | RuboCop Metrics |
-| PHP | Composer scripts | Nix | PHPUnit | PHP_CodeSniffer + PHPStan | PHPMD |
-| C#/F# | Cake | Nix | xUnit | SonarAnalyzer | SonarAnalyzer |
-
-## 6.6 まとめ
-
-この章では以下を実現しました。
-
-| 項目 | 内容 |
-|------|------|
-| Nix | `nix develop .#clojure` で再現可能な開発環境を構築 |
-| Makefile | test / lint / kibit / complexity / check タスクを定義 |
-| `make check` | Eastwood → Kibit → 複雑度チェック → テストを一括実行 |
-| GitHub Actions | push / PR 時に Nix 環境で自動 CI を実行 |
-| Nix 統合 | CI でも `nix develop .#clojure` を使用しローカルと環境を統一 |
-
-第 2 部を通じて、ソフトウェア開発の三種の神器（バージョン管理、テスティング、自動化）を Clojure の開発環境に整備しました。次の第 3 部では、プロトコルとマルチメソッドによるポリモーフィズムに進みます。

package/lib/assets/docs/article/getting-start-tdd/clojure/07-protocols-and-records.md

@@ -1,140 +0,0 @@
----
-type: Article
-title: "第 7 章: プロトコルとレコードによるポリモーフィズム"
-description: "この章からは FizzBuzz プログラムに追加仕様を実装しながら、Clojure におけるポリモーフィズムを学びます。"
-tags: [article, getting-start-tdd, clojure]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 7 章: プロトコルとレコードによるポリモーフィズム
-
-## 7.1 はじめに
-
-この章からは FizzBuzz プログラムに追加仕様を実装しながら、Clojure におけるポリモーフィズムを学びます。Clojure は関数型言語ですが、`defprotocol` と `defrecord` による型ベースのポリモーフィズムを提供しています。
-
-### 追加仕様
-
-```
-1 から 100 までの数をプリントするプログラムを書け。
-ただし 3 の倍数のときは数の代わりに「Fizz」と、5 の倍数のときは「Buzz」とプリントし、
-3 と 5 両方の倍数の場合には「FizzBuzz」とプリントすること。
-タイプごとに出力を切り替えることができる。
-タイプ 1 は通常、タイプ 2 は数字のみ、タイプ 3 は FizzBuzz の場合のみをプリントする。
-```
-
-## 7.2 TODO リスト
-
-- [ ] タイプ 1 の場合（通常の FizzBuzz）
-- [ ] タイプ 2 の場合（数字のみ）
-- [ ] タイプ 3 の場合（FizzBuzz の場合のみ）
-- [ ] それ以外のタイプの場合（例外を発生）
-
-## 7.3 値オブジェクト — FizzBuzzValue
-
-### defrecord による不変データ構造
-
-Clojure の `defrecord` は不変のデータ構造を定義します。Java のクラスと異なり、フィールドは変更できません。
-
-```clojure
-;; src/fizzbuzz/domain/model.clj
-(ns fizzbuzz.domain.model)
-
-(defrecord FizzBuzzValue [number value])
-
-(defn create-fizz-buzz-value [n]
-  (->FizzBuzzValue n (str n)))
-```
-
-`->FizzBuzzValue` は自動生成されるコンストラクタ関数です。
-
-### 述語関数
-
-```clojure
-(defn fizz? [n]
-  (zero? (mod n 3)))
-
-(defn buzz? [n]
-  (zero? (mod n 5)))
-
-(defn fizz-buzz? [n]
-  (and (fizz? n) (buzz? n)))
-```
-
-Clojure の慣例として、述語関数（真偽値を返す関数）は名前の末尾に `?` を付けます。
-
-## 7.4 プロトコル — FizzBuzzType
-
-### defprotocol によるインターフェース定義
-
-`defprotocol` は Java のインターフェースに相当します。実装すべき関数のシグネチャを定義します。
-
-```clojure
-;; src/fizzbuzz/domain/type.clj
-(ns fizzbuzz.domain.type
-  (:require [fizzbuzz.domain.model :as model]))
-
-(defprotocol FizzBuzzType
-  "FizzBuzz タイプごとの文字列生成プロトコル"
-  (generate-string [this value]
-    "FizzBuzzValue から文字列を生成する"))
-```
-
-### レコードによるプロトコル実装
-
-各タイプをレコードとして定義し、プロトコルを実装します。
-
-```clojure
-;; タイプ 1: 通常の FizzBuzz
-(defrecord FizzBuzzType01 []
-  FizzBuzzType
-  (generate-string [_this value]
-    (let [n (:number value)]
-      (cond
-        (model/fizz-buzz? n) "FizzBuzz"
-        (model/fizz? n) "Fizz"
-        (model/buzz? n) "Buzz"
-        :else (str n)))))
-
-;; タイプ 2: 数字のみ
-(defrecord FizzBuzzType02 []
-  FizzBuzzType
-  (generate-string [_this value]
-    (str (:number value))))
-
-;; タイプ 3: FizzBuzz の場合のみ
-(defrecord FizzBuzzType03 []
-  FizzBuzzType
-  (generate-string [_this value]
-    (let [n (:number value)]
-      (cond
-        (model/fizz-buzz? n) "FizzBuzz"
-        (model/fizz? n) "Fizz"
-        (model/buzz? n) "Buzz"
-        :else ""))))
-```
-
-## 7.5 テストの実装
-
-```clojure
-;; test/fizzbuzz/domain/type_test.clj
-(deftest fizz-buzz-type01-test
-  (testing "タイプ 1: 通常の FizzBuzz"
-    (let [t (type/->FizzBuzzType01)]
-      (is (= "1" (type/generate-string t (model/create-fizz-buzz-value 1))))
-      (is (= "Fizz" (type/generate-string t (model/create-fizz-buzz-value 3))))
-      (is (= "Buzz" (type/generate-string t (model/create-fizz-buzz-value 5))))
-      (is (= "FizzBuzz" (type/generate-string t (model/create-fizz-buzz-value 15)))))))
-```
-
-テスト実行 → GREEN。
-
-## 7.6 まとめ
-
-この章では以下のことを学びました。
-
-- **defrecord** による不変データ構造（値オブジェクト）の定義
-- **defprotocol** によるインターフェースの定義
-- レコードによるプロトコルの実装（ポリモーフィズム）
-- 述語関数の命名規則（`?` サフィックス）
-- `let` によるローカルバインディング

package/lib/assets/docs/article/getting-start-tdd/clojure/08-multimethods-and-design-patterns.md

@@ -1,139 +0,0 @@
----
-type: Article
-title: "第 8 章: マルチメソッドとデザインパターン"
-description: "前章ではプロトコルとレコードによるポリモーフィズムを学びました。"
-tags: [article, getting-start-tdd, clojure]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 8 章: マルチメソッドとデザインパターン
-
-## 8.1 はじめに
-
-前章ではプロトコルとレコードによるポリモーフィズムを学びました。この章では **マルチメソッド** による値ベースのディスパッチと、**デザインパターン** の Clojure 的な実現を学びます。
-
-## 8.2 マルチメソッド
-
-### defmulti / defmethod
-
-マルチメソッドは **値に基づいたディスパッチ** を行います。プロトコルが型に基づくのに対し、マルチメソッドは任意の値でディスパッチできます。
-
-```clojure
-;; ディスパッチ関数の定義
-(defmulti generate-by-type
-  "タイプ番号に基づいて FizzBuzz 文字列を生成する"
-  (fn [type-num _value] type-num))
-
-;; タイプごとの実装
-(defmethod generate-by-type 1 [_ value]
-  (let [n (:number value)]
-    (cond
-      (model/fizz-buzz? n) "FizzBuzz"
-      (model/fizz? n) "Fizz"
-      (model/buzz? n) "Buzz"
-      :else (str n))))
-
-(defmethod generate-by-type 2 [_ value]
-  (str (:number value)))
-
-(defmethod generate-by-type 3 [_ value]
-  (let [n (:number value)]
-    (cond
-      (model/fizz-buzz? n) "FizzBuzz"
-      (model/fizz? n) "Fizz"
-      (model/buzz? n) "Buzz"
-      :else "")))
-
-;; デフォルト（未定義タイプ）
-(defmethod generate-by-type :default [type-num _]
-  (throw (ex-info "FizzBuzz タイプが未定義です" {:type type-num})))
-```
-
-### プロトコル vs マルチメソッド
-
-| 特徴 | プロトコル | マルチメソッド |
-|------|-----------|--------------|
-| ディスパッチ基準 | 第 1 引数の型 | 任意の値 |
-| パフォーマンス | 高速（JVM レベル） | やや遅い |
-| 拡張性 | 型の追加で拡張 | メソッドの追加で拡張 |
-| 用途 | インターフェース設計 | 柔軟なディスパッチ |
-
-## 8.3 ファクトリ関数パターン
-
-Clojure ではクラスのコンストラクタの代わりにファクトリ関数を使います。
-
-```clojure
-(defn create-type [type-num]
-  (case type-num
-    1 (->FizzBuzzType01)
-    2 (->FizzBuzzType02)
-    3 (->FizzBuzzType03)
-    (->FizzBuzzTypeNotDefined)))
-```
-
-`case` は `switch` 文に相当し、定数値でのディスパッチに最適化されています。
-
-## 8.4 Command パターン
-
-### プロトコルによる Command パターン
-
-```clojure
-;; src/fizzbuzz/application/command.clj
-(defprotocol FizzBuzzCommand
-  "FizzBuzz コマンドプロトコル"
-  (execute [this]))
-
-;; 単一値コマンド
-(defrecord FizzBuzzValueCommand [number type-num]
-  FizzBuzzCommand
-  (execute [_this]
-    (let [fizz-buzz-type (type/create-type type-num)
-          value (model/create-fizz-buzz-value number)]
-      (type/generate-string fizz-buzz-type value))))
-
-;; リストコマンド
-(defrecord FizzBuzzListCommand [numbers type-num]
-  FizzBuzzCommand
-  (execute [_this]
-    (let [fizz-buzz-type (type/create-type type-num)]
-      (->> numbers
-           (mapv model/create-fizz-buzz-value)
-           (mapv #(type/generate-string fizz-buzz-type %))
-           model/create-fizz-buzz-list))))
-```
-
-### テスト
-
-```clojure
-(deftest fizz-buzz-value-command-test
-  (testing "FizzBuzzValueCommand: 単一値コマンド"
-    (is (= "1" (cmd/execute (cmd/->FizzBuzzValueCommand 1 1))))
-    (is (= "Fizz" (cmd/execute (cmd/->FizzBuzzValueCommand 3 1))))
-    (is (= "Buzz" (cmd/execute (cmd/->FizzBuzzValueCommand 5 1))))
-    (is (= "FizzBuzz" (cmd/execute (cmd/->FizzBuzzValueCommand 15 1))))))
-```
-
-## 8.5 Strategy パターン
-
-Clojure では高階関数が Strategy パターンの自然な表現です。
-
-```clojure
-(defn process-with-strategy [strategy-fn numbers]
-  (mapv strategy-fn numbers))
-
-;; 使用例
-(process-with-strategy fizzbuzz (range 1 101))
-```
-
-関数をファーストクラスの値として渡すことで、Strategy パターンが関数の引数渡しだけで実現できます。
-
-## 8.6 まとめ
-
-この章では以下のことを学びました。
-
-- **defmulti/defmethod** によるマルチメソッド（値ベースのディスパッチ）
-- プロトコルとマルチメソッドの使い分け
-- **ファクトリ関数** パターンと `case` 式
-- **Command パターン** のプロトコルによる実現
-- **Strategy パターン** の高階関数による実現

package/lib/assets/docs/article/getting-start-tdd/clojure/09-namespaces-and-module-design.md

@@ -1,136 +0,0 @@
----
-type: Article
-title: "第 9 章: 名前空間とモジュール設計"
-description: "この章ではモノリシックなコードを名前空間に分割し、ドメインモデルに基づいたモジュール設計を行います。"
-tags: [article, getting-start-tdd, clojure]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 9 章: 名前空間とモジュール設計
-
-## 9.1 はじめに
-
-この章ではモノリシックなコードを名前空間に分割し、ドメインモデルに基づいたモジュール設計を行います。
-
-## 9.2 名前空間による分割
-
-### Before（モノリシック）
-
-```
-fizzbuzz/
-└── core.clj          (すべてのロジックが集中)
-```
-
-### After（モジュール分割）
-
-```
-fizzbuzz/
-├── core.clj                    (公開 API・エントリーポイント)
-├── domain/
-│   ├── model.clj               (値オブジェクト・コレクション)
-│   └── type.clj                (FizzBuzz タイプ — プロトコル実装)
-└── application/
-    └── command.clj             (コマンド関数)
-```
-
-## 9.3 名前空間の設計原則
-
-### 単一責任の原則
-
-各名前空間は 1 つの責務のみを持ちます。
-
-| 名前空間 | 責務 |
-|----------|------|
-| `fizzbuzz.core` | 公開 API とメインエントリーポイント |
-| `fizzbuzz.domain.model` | FizzBuzzValue と FizzBuzzList の定義 |
-| `fizzbuzz.domain.type` | タイプごとの文字列生成ロジック |
-| `fizzbuzz.application.command` | コマンドパターンの実装 |
-
-### 依存方向
-
-依存関係は常に上位レイヤーから下位レイヤーへ向かいます。
-
-```
-application/command → domain/type → domain/model
-                   ↗
-     core ────────
-```
-
-## 9.4 名前空間の require
-
-```clojure
-;; エイリアスを使った require
-(ns fizzbuzz.domain.type
-  (:require [fizzbuzz.domain.model :as model]))
-
-;; model/fizz? のようにエイリアス経由でアクセス
-(model/fizz? 3)  ;=> true
-```
-
-### require のベストプラクティス
-
-1. **`:as` エイリアス** を使う（名前の衝突を防ぐ）
-2. **`:refer :all`** は避ける（テストファイルでは許容）
-3. **循環依存** を作らない
-
-## 9.5 アクセス制御
-
-Clojure では `defn-` でプライベート関数を定義します。
-
-```clojure
-;; パブリック関数
-(defn fizzbuzz [n] ...)
-
-;; プライベート関数（同一名前空間内でのみアクセス可能）
-(defn- divisible-by? [n d]
-  (zero? (mod n d)))
-```
-
-## 9.6 レコードとプロトコルの配置
-
-### 推奨パターン
-
-- **プロトコルの定義**: 独立した名前空間に配置
-- **レコードの実装**: プロトコルを require して実装
-- **ファクトリ関数**: プロトコルと同じ名前空間に配置
-
-```clojure
-;; domain/type.clj にプロトコル定義とレコード実装を配置
-(defprotocol FizzBuzzType
-  (generate-string [this value]))
-
-(defrecord FizzBuzzType01 []
-  FizzBuzzType
-  (generate-string [_this value] ...))
-
-;; ファクトリ関数も同じ名前空間に
-(defn create-type [type-num] ...)
-```
-
-## 9.7 テスト名前空間の構成
-
-テストは対応するプロダクトコードと同じ構造で配置します。
-
-```
-test/
-└── fizzbuzz/
-    ├── core_test.clj
-    ├── domain/
-    │   └── type_test.clj
-    └── application/
-        └── command_test.clj
-```
-
-## 9.8 まとめ
-
-この章では以下のことを学びました。
-
-- **ns** マクロによる名前空間の定義と管理
-- **:require** と **:as** エイリアスによる依存関係の宣言
-- **単一責任の原則** に基づくモジュール設計
-- **defn-** によるアクセス制御
-- ドメインモデルに基づいた名前空間の分割パターン
-- テスト名前空間の構成
-
-第 3 部が完了しました。プロトコルとマルチメソッドによるポリモーフィズムと、名前空間によるモジュール設計を学びました。第 4 部では関数型プログラミングの本質を探ります。