@k2works/claude-code-booster 6.2.0 → 6.3.0

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

@@ -1,273 +0,0 @@
----
-type: Article
-title: "第 2 章: 仮実装と三角測量"
-description: "前章では、FizzBuzz の仕様を TODO リストに分解し、最初のテストを仮実装で通しました。"
-tags: [article, getting-start-tdd, rust]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 2 章: 仮実装と三角測量
-
-## 2.1 はじめに
-
-前章では、FizzBuzz の仕様を TODO リストに分解し、最初のテストを仮実装で通しました。この章では、**三角測量** によってプログラムを一般化し、さらに FizzBuzz のコアロジックを実装していきます。
-
-**TODO リスト**:
-
-- [ ] 数を文字列にして返す
-  - [x] 1 を渡したら文字列 "1" を返す
-  - [ ] 2 を渡したら文字列 "2" を返す
-- [ ] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [ ] 5 の倍数のときは「Buzz」と返す
-- [ ] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [ ] 1 から 100 までの数
-- [ ] プリントする
-
-## 2.2 三角測量
-
-1 を渡したら文字列 "1" を返すようにできました。では、2 を渡したらどうなるでしょうか？
-
-### Red: 2 つ目のテストを書く
-
-```rust
-#[test]
-fn test_2を渡したら文字列2を返す() {
-    assert_eq!("2", generate(2));
-}
-```
-
-テストを実行します。
-
-```bash
-$ cargo test
-test tests::test_1を渡したら文字列1を返す ... ok
-test tests::test_2を渡したら文字列2を返す ... FAILED
-
-assertion `left == right` failed
-  left: "2"
- right: "1"
-```
-
-テストが失敗しました。文字列 "1" しか返さないプログラムなのですから当然です。
-
-### Green: 一般化する
-
-数値を文字列に変換して返すように修正します。Rust では `i32` 型に実装された `to_string()` メソッドで整数を文字列に変換できます。
-
-```rust
-pub fn generate(number: i32) -> String {
-    number.to_string()
-}
-```
-
-テストを実行します。
-
-```bash
-$ cargo test
-test tests::test_1を渡したら文字列1を返す ... ok
-test tests::test_2を渡したら文字列2を返す ... ok
-
-test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-テストが通りました！2 つ目のテストによって `generate` 関数の一般化を実現できました。このようなアプローチを **三角測量** と言います。
-
-> 三角測量
->
-> テストから最も慎重に一般化を引き出すやり方はどのようなものだろうか——2 つ以上の例があるときだけ、一般化を行うようにしよう。
->
-> — テスト駆動開発
-
-Go では `strconv.Itoa(number)` と書くところを、Rust では `number.to_string()` を使います。Rust の `to_string()` は `Display` トレイトを実装した任意の型で利用できるため、Go よりも汎用的です。
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-  - [x] 1 を渡したら文字列 "1" を返す
-  - [x] 2 を渡したら文字列 "2" を返す
-- [ ] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [ ] 5 の倍数のときは「Buzz」と返す
-- [ ] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [ ] 1 から 100 までの数
-- [ ] プリントする
-
-## 2.3 3 の倍数 — Fizz
-
-次は「3 の倍数のときは数の代わりに Fizz と返す」に取り掛かります。
-
-### Red: 3 の倍数のテスト
-
-```rust
-#[test]
-fn test_3を渡したらfizzを返す() {
-    assert_eq!("Fizz", generate(3));
-}
-```
-
-```bash
-$ cargo test
-test tests::test_3を渡したらfizzを返す ... FAILED
-
-assertion `left == right` failed
-  left: "Fizz"
- right: "3"
-```
-
-### Green: 明白な実装
-
-3 の倍数のときは "Fizz" を返すように実装します。Rust では `%` 演算子で剰余を求め、`== 0` でゼロかどうかを判定します。
-
-```rust
-pub fn generate(number: i32) -> String {
-    if number % 3 == 0 {
-        return "Fizz".to_string();
-    }
-    number.to_string()
-}
-```
-
-```bash
-$ cargo test
-test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-三角測量として 6 のテストも追加して確認します。
-
-```rust
-#[test]
-fn test_6を渡したらfizzを返す() {
-    assert_eq!("Fizz", generate(6));
-}
-```
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [ ] 5 の倍数のときは「Buzz」と返す
-- [ ] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [ ] 1 から 100 までの数
-- [ ] プリントする
-
-## 2.4 5 の倍数 — Buzz
-
-### Red: 5 の倍数のテスト
-
-```rust
-#[test]
-fn test_5を渡したらbuzzを返す() {
-    assert_eq!("Buzz", generate(5));
-}
-```
-
-```bash
-$ cargo test
-test tests::test_5を渡したらbuzzを返す ... FAILED
-
-assertion `left == right` failed
-  left: "Buzz"
- right: "5"
-```
-
-### Green: Buzz の実装
-
-```rust
-pub fn generate(number: i32) -> String {
-    if number % 3 == 0 {
-        return "Fizz".to_string();
-    }
-    if number % 5 == 0 {
-        return "Buzz".to_string();
-    }
-    number.to_string()
-}
-```
-
-```bash
-$ cargo test
-test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-三角測量として 10 のテストも追加します。
-
-```rust
-#[test]
-fn test_10を渡したらbuzzを返す() {
-    assert_eq!("Buzz", generate(10));
-}
-```
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [ ] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [ ] 1 から 100 までの数
-- [ ] プリントする
-
-## 2.5 15 の倍数 — FizzBuzz
-
-### Red: 15 の倍数のテスト
-
-```rust
-#[test]
-fn test_15を渡したらfizzbuzzを返す() {
-    assert_eq!("FizzBuzz", generate(15));
-}
-```
-
-```bash
-$ cargo test
-test tests::test_15を渡したらfizzbuzzを返す ... FAILED
-
-assertion `left == right` failed
-  left: "FizzBuzz"
- right: "Fizz"
-```
-
-15 は 3 の倍数でもあるため、"Fizz" が返されてしまいました。3 と 5 の両方の倍数の判定を先に行う必要があります。
-
-### Green: FizzBuzz の実装
-
-Rust の `match` 式を使って、条件分岐を整理します。
-
-```rust
-pub fn generate(number: i32) -> String {
-    match (number % 3, number % 5) {
-        (0, 0) => "FizzBuzz".to_string(),
-        (0, _) => "Fizz".to_string(),
-        (_, 0) => "Buzz".to_string(),
-        _ => number.to_string(),
-    }
-}
-```
-
-```bash
-$ cargo test
-test result: ok. 7 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-Rust の `match` 式はパターンマッチングを使った条件分岐です。タプル `(number % 3, number % 5)` に対してパターンを照合します。Go の式なし `switch` や Java の `if-else if` チェーンよりも、Rust の `match` は網羅性をコンパイラがチェックしてくれるため、より安全です。
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [ ] 1 から 100 までの数
-- [ ] プリントする
-
-## 2.6 まとめ
-
-この章では以下のことを学びました。
-
-- **三角測量** で 2 つ以上の例を使ってプログラムを一般化する手法
-- Rust の `to_string()` メソッドによる整数から文字列への変換
-- Rust の `%` 演算子による剰余判定
-- Rust の `match` 式によるパターンマッチング（タプルパターン）
-- Red-Green-Refactor サイクルを繰り返してコアロジックを段階的に構築する方法
-
-次章では、残りの TODO（リスト生成とプリント）を実装し、リファクタリングで「動作するきれいなコード」を目指します。

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

@@ -1,242 +0,0 @@
----
-type: Article
-title: "第 3 章: 明白な実装とリファクタリング"
-description: "前章では、三角測量と明白な実装で FizzBuzz のコアロジックを完成させました。"
-tags: [article, getting-start-tdd, rust]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 3 章: 明白な実装とリファクタリング
-
-## 3.1 はじめに
-
-前章では、三角測量と明白な実装で FizzBuzz のコアロジックを完成させました。この章では、残りの TODO（リスト生成とプリント）を実装し、学習用テストを活用しながら「動作するきれいなコード」を目指してリファクタリングします。
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [ ] 1 から 100 までの数
-- [ ] プリントする
-
-## 3.2 1 から 100 までのリスト生成
-
-### Red: リスト生成のテスト
-
-1 から 100 までの FizzBuzz の結果を `Vec<String>` として返す関数をテストします。
-
-```rust
-#[test]
-fn test_generate_list_1から100までのfizzbuzzを返す() {
-    let result = generate_list(1, 100);
-    assert_eq!(100, result.len());
-    assert_eq!("1", result[0]);
-    assert_eq!("2", result[1]);
-    assert_eq!("Fizz", result[2]);
-    assert_eq!("4", result[3]);
-    assert_eq!("Buzz", result[4]);
-    assert_eq!("FizzBuzz", result[14]);
-}
-```
-
-```bash
-$ cargo test
-error[E0425]: cannot find function `generate_list` in this scope
-```
-
-### Green: 明白な実装
-
-Rust のイテレータと `map` を使って、指定範囲の数を FizzBuzz に変換したリストを返します。
-
-```rust
-pub fn generate_list(start: i32, end: i32) -> Vec<String> {
-    (start..=end).map(generate).collect()
-}
-```
-
-```bash
-$ cargo test
-test result: ok. 8 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
-```
-
-`(start..=end)` は Rust の範囲式（inclusive range）で、`start` から `end` までのイテレータを生成します。`.map(generate)` で各要素に `generate` 関数を適用し、`.collect()` で `Vec<String>` に変換します。Go の明示的な `for` ループ + `append` に比べ、Rust では関数型スタイルでより宣言的に書けます。
-
-> 明白な実装
->
-> シンプルな操作を実現するにはどうすればいいだろうか——そのまま実装しよう。
->
-> — テスト駆動開発
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [x] 1 から 100 までの数
-- [ ] プリントする
-
-## 3.3 プリント機能
-
-### 学習用テスト
-
-プリント機能は、生成したリストの各要素を出力するものです。学習用テストとして、Rust の `Write` トレイトを使った出力のキャプチャ方法を確認します。
-
-> 学習用テスト
->
-> 外部のソフトウェアのテストを書くべきだろうか——そのソフトウェアに対して新しいことを初めて行おうとした段階で書いてみよう。
->
-> — テスト駆動開発
-
-Rust では `std::io::Write` トレイトを実装した `Vec<u8>` をバッファとして使い、出力をキャプチャできます。
-
-```rust
-#[test]
-fn test_learning_write_バッファに出力できる() {
-    use std::io::Write;
-    let mut buf = Vec::new();
-    writeln!(buf, "hello").unwrap();
-    assert_eq!("hello\n", String::from_utf8(buf).unwrap());
-}
-```
-
-### Print 関数の実装
-
-`std::io::Write` トレイトを引数に取ることで、テスト時にはバッファに、本番では標準出力に出力できます。
-
-```rust
-use std::io::Write;
-
-pub fn print_fizzbuzz(writer: &mut dyn Write) {
-    for s in generate_list(1, 100) {
-        writeln!(writer, "{}", s).unwrap();
-    }
-}
-```
-
-テストを書きます。
-
-```rust
-#[test]
-fn test_print_fizzbuzzの結果を出力する() {
-    let mut buf = Vec::new();
-    print_fizzbuzz(&mut buf);
-    let output = String::from_utf8(buf).unwrap();
-    assert!(output.contains("1\n"));
-    assert!(output.contains("Fizz\n"));
-    assert!(output.contains("Buzz\n"));
-    assert!(output.contains("FizzBuzz\n"));
-}
-```
-
-**TODO リスト**:
-
-- [x] 数を文字列にして返す
-- [x] 3 の倍数のときは数の代わりに「Fizz」と返す
-- [x] 5 の倍数のときは「Buzz」と返す
-- [x] 3 と 5 両方の倍数の場合には「FizzBuzz」と返す
-- [x] 1 から 100 までの数
-- [x] プリントする
-
-## 3.4 リファクタリング
-
-テスト駆動開発の流れを確認しておきましょう。
-
-> 1. レッド：動作しない、おそらく最初のうちはコンパイルも通らないテストを 1 つ書く。
-> 2. グリーン：そのテストを迅速に動作させる。このステップでは罪を犯してもよい。
-> 3. リファクタリング：テストを通すために発生した重複をすべて除去する。
->
-> レッド・グリーン・リファクタリング。それが TDD のマントラだ。
->
-> — テスト駆動開発
-
-### テストコードのリファクタリング
-
-Rust のテストモジュールシステムを使って、テストをカテゴリごとに構造化します。
-
-```rust
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    mod その他の場合 {
-        use super::*;
-
-        #[test]
-        fn test_1を渡したら文字列1を返す() {
-            assert_eq!("1", generate(1));
-        }
-
-        #[test]
-        fn test_2を渡したら文字列2を返す() {
-            assert_eq!("2", generate(2));
-        }
-    }
-
-    mod 三の倍数の場合 {
-        use super::*;
-
-        #[test]
-        fn test_3を渡したらfizzを返す() {
-            assert_eq!("Fizz", generate(3));
-        }
-
-        #[test]
-        fn test_6を渡したらfizzを返す() {
-            assert_eq!("Fizz", generate(6));
-        }
-    }
-
-    mod 五の倍数の場合 {
-        use super::*;
-
-        #[test]
-        fn test_5を渡したらbuzzを返す() {
-            assert_eq!("Buzz", generate(5));
-        }
-
-        #[test]
-        fn test_10を渡したらbuzzを返す() {
-            assert_eq!("Buzz", generate(10));
-        }
-    }
-
-    mod 三と五の倍数の場合 {
-        use super::*;
-
-        #[test]
-        fn test_15を渡したらfizzbuzzを返す() {
-            assert_eq!("FizzBuzz", generate(15));
-        }
-    }
-}
-```
-
-Rust のネストされた `mod` はテストの論理的グルーピングに活用でき、`cargo test` の出力に `tests::三の倍数の場合::test_3を渡したらfizzを返す` のように階層が表示されます。
-
-## 3.5 他言語との比較
-
-| 概念 | Java | Python | TypeScript | Ruby | Go | Rust |
-|------|------|--------|-----------|------|------|------|
-| テストフレームワーク | JUnit 5 | pytest | Vitest | Minitest | testing（標準） | cargo test（標準） |
-| テスト実行 | `./gradlew test` | `pytest` | `npx vitest` | `bundle exec rake test` | `go test ./...` | `cargo test` |
-| 文字列変換 | `String.valueOf(n)` | `str(n)` | `n.toString()` | `n.to_s` | `strconv.Itoa(n)` | `n.to_string()` |
-| 剰余判定 | `n % 3 == 0` | `n % 3 == 0` | `n % 3 === 0` | `(n % 3).zero?` | `n%3 == 0` | `n % 3 == 0` |
-| リスト生成 | `IntStream.rangeClosed` | `[f(n) for n in range]` | `Array.from({length})` | `(1..100).map { }` | `for` + `append` | `(1..=100).map(f).collect()` |
-| 出力テスト | `System.setOut` | `capsys` fixture | `vi.spyOn` | `StringIO` | `bytes.Buffer` | `Vec<u8>` + `Write` |
-
-## 3.6 まとめ
-
-この章では以下のことを学びました。
-
-- **明白な実装** でシンプルな操作をそのまま実装する手法
-- Rust のイテレータと `map`、`collect` によるリスト生成
-- `std::io::Write` トレイトを活用したテスタブルな出力設計
-- `Vec<u8>` を使った出力のキャプチャ（学習用テスト）
-- **リファクタリング** でテストモジュールを構造化する考え方
-- Red-Green-Refactor サイクルの完了
-
-第 1 部の 3 章を通じて、TDD の基本サイクル（仮実装 → 三角測量 → 明白な実装 → リファクタリング）を一通り体験しました。次の第 2 部では、開発環境の自動化（バージョン管理、パッケージ管理、CI/CD）に進みます。

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

@@ -1,101 +0,0 @@
----
-type: Article
-title: "第 4 章: バージョン管理と Conventional Commits"
-description: "前章までで、TDD の基本サイクルを通じて FizzBuzz プログラムを完成させました。"
-tags: [article, getting-start-tdd, rust]
-status: stable
-generated: { by: human:kakimomokuri, at: 2026-03-24T05:22:28Z }
----
-
-# 第 4 章: バージョン管理と Conventional Commits
-
-## 4.1 はじめに
-
-前章までで、TDD の基本サイクルを通じて FizzBuzz プログラムを完成させました。この章からは「動作するきれいなコード」を書き続けるために必要な **ソフトウェア開発の三種の神器** を整備していきます。
-
-> 今日のソフトウェア開発の世界において絶対になければならない 3 つの技術的な柱があります。三本柱と言ったり、三種の神器と言ったりしていますが、それらは
->
-> - バージョン管理
-> - テスティング
-> - 自動化
->
-> の 3 つです。
->
-> — 和田卓人
-
-**バージョン管理** と **テスティング** に関しては第 1 部で触れました。本章ではバージョン管理をさらに深掘りし、**コミットメッセージの規約** について解説します。
-
-## 4.2 コミットメッセージの重要性
-
-これまでの作業では、区切りごとにリポジトリにコミットしてきました。しかし、コミットメッセージの書き方に一貫性がないと、後からプロジェクトの履歴を追うのが難しくなります。
-
-チーム開発では特に、誰がいつ何のためにコードを変更したのかを明確にすることが重要です。そこで役立つのが **Conventional Commits** です。
-
-## 4.3 Conventional Commits
-
-本プロジェクトでは [Angular ルール](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type) に基づいた **Conventional Commits** の書式を採用します。
-
-### コミットメッセージのフォーマット
-
-```
-<タイプ>(<スコープ>): <タイトル>
-<空行>
-<ボディ>
-<空行>
-<フッタ>
-```
-
-### タイプの種類
-
-| タイプ | 説明 | 例 |
-|--------|------|-----|
-| `feat` | 新機能の追加 | `feat: FizzBuzz のコアロジックを実装` |
-| `fix` | バグの修正 | `fix: 15 の倍数の判定順序を修正` |
-| `refactor` | リファクタリング | `refactor: match 式でパターンマッチに変更` |
-| `test` | テストの追加・修正 | `test: 三角測量のテストケースを追加` |
-| `docs` | ドキュメントの変更 | `docs: README にセットアップ手順を追加` |
-| `chore` | ビルド・ツールの変更 | `chore: justfile にカバレッジタスクを追加` |
-| `style` | コードスタイルの変更 | `style: rustfmt で自動フォーマット` |
-
-### Rust プロジェクトでの例
-
-```bash
-# テスト追加
-$ git commit -m 'test: 数を文字列にして返す'
-
-# 機能実装
-$ git commit -m 'feat: generate 関数で match 式による FizzBuzz 判定を実装'
-
-# リファクタリング
-$ git commit -m 'refactor: テストモジュールをカテゴリごとに構造化'
-```
-
-## 4.4 Git フロー
-
-### ブランチ戦略
-
-| ブランチ | 用途 |
-|---------|------|
-| `main` | リリース可能な安定版 |
-| `develop` | 開発中の最新コード |
-| `feature/*` | 機能開発用ブランチ |
-
-### 作業の流れ
-
-1. `develop` ブランチから作業を開始
-2. TDD サイクル（Red → Green → Refactor）を実行
-3. Conventional Commits の書式でコミット
-4. テストが通ることを確認してプッシュ
-
-## 4.5 まとめ
-
-この章では以下を学びました。
-
-| 概念 | 説明 |
-|------|------|
-| Conventional Commits | コミットメッセージの標準的な書式 |
-| タイプ | feat, fix, refactor, test, docs, chore, style |
-| スコープ | 変更の影響範囲（任意） |
-| Git フロー | main / develop / feature ブランチ戦略 |
-
-次章では、Cargo によるパッケージ管理と Clippy / rustfmt による静的解析を導入します。