The Power of Go Tools (John Arundel)（Z-Library）

【One-Line Pitch】 A hands-on guide to writing idiomatic, testable Go command-line tools by leaning on the language's standard library and its vast "universal library" of packages. Best for intermediate Go developers who want to move from writing scripts to designing well-structured, importable packages and CLIs. 【Book Arc】 - **Opening (~0%–10%)**: Frames the core philosophy — Go's small language plus a huge standard and third-party ecosystem means most problems are already solved; the work is finding and composing the right packages. - **Early (~10%–32%)**: Builds the "write packages, not programs" mindset through a hello-printing example, then a line/word counter, introducing test-first design, functional options, and decoupling from `os.Args`. - **Middle (~32%–48%)**: Deepens testing practice — test scripts, `t.TempDir`, permission and pre-population security tests, and the `fs.FS` abstraction for making filesystem code testable. - **Late (~48%–70%)**: Moves into real tooling: walking directories to find files, integration tests with build tags, and testing a command runner by capturing output. - **Ending (~70%–100%)**: Culminates in building a shell and pipelines — parsing user input, designing a stateful `Session` object, and implementing globbing, redirection, piping, and quoting. 【Key Takeaways】 - **Write packages, not programs** (Early): Put substantive behaviour in importable packages and keep `main` tiny, so the same code can power multiple commands and be tested directly. - **Tests drive design, not just verification** (Early): Writing a test first forces you to think about observable behaviour rather than implementation details, making the component easier to write correctly. - **Functional options are the idiomatic configuration pattern** (Early): Options as functions applied to a struct let callers configure behaviour flexibly without bloating constructors. - **Avoid mutable global state** (Early): Structs with their own fields (e.g. a `Printer` with its own `Output`) keep code safe for concurrent use; `t.Parallel` helps catch such mistakes. - **Test what could be wrong, including security** (Middle): Permission handling and pre-population attacks are worth explicit tests — if it could be wrong, it needs testing. - **The `fs.FS` abstraction makes filesystem code testable** (Middle): Abstracting disk access avoids slow, flaky tests tied to real files. - **Test CLIs as CLIs with lightweight test scripts** (Middle): Script-based assertions let you verify real command-line behaviour without heavy plumbing or building binaries. - **Prefer standard output over logging** (Early): Writing data to stdout/stderr gives operators maximum flexibility; ask what question each log message answers before adding it. 【Reading Tips】 - Deep-read the early chapters on test-first design and functional options — these patterns recur throughout the book. - Skim the "Going further" mini-projects on a first pass, then return to them for hands-on practice. - Treat the shell and pipeline chapters as the payoff: they synthesize earlier techniques (packages, options, testing, `fs.FS`) into a substantial project. - Keep the code examples open alongside the text; the book is example-driven and rewards typing along. 【Coverage Limits】 The excerpts cover roughly the first half of the book in detail (through filesystem and integration testing) and only the chapter outlines for the shell and pipeline material; specific implementations in the later chapters are not fully represented here.