Reference
The Catalogues
Named catalogues, worked one entry at a time. Gamma and company's design patterns, Hohpe and Woolf's integration patterns, the data structures underneath them, and the problems that need several at once. Each post takes one entry: what the mechanism actually is, where the cost goes, the shape of problem it fits, when to reach for something else, and the Go to write it.
These are written to be returned to rather than read through. Sister surfaces: Under the Hood explains how one thing works, and The Exam Room is certification scenarios. The Workshop's facilitator playbooks are reference too, and have no landing page of their own yet.
Data Structures
1 of 22 published
Patterns
0 of 28 published
What a Design Pattern Is, and Is Not
The Gang of Four wrote down what C++ and Smalltalk programmers kept building in 1994. It is a description of practice at a moment, not a prescription, and several of its entries are workarounds for a language feature that did not exist yet: a first-class function dissolves Strategy and Command, implicit interfaces dissolve much of Adapter, a range loop is Iterator. Several others describe structural decisions no syntax removes. Which is which, and why the vocabulary is still worth having.
First of 28Integration
0 of 30 published
Choosing an Integration Style
Four ways to join two systems, and each one decides what breaks later. File transfer asks nothing of either system and sets a latency floor. A shared database removes the lag and makes the schema a contract nobody can change. Remote calls couple availability, so the caller fails when the callee does. Messaging decouples time and hands you duplicates, reordering and a much harder debugging story.
First of 30Applied Patterns
0 of 10 published
The Same File Twice
A supplier's scheduler fired twice on the night the clocks went back, the same stock file landed twice, and 340 lines were credited with 9,840 kg that arrived once. Nobody found it for twenty-three days, by which time the automatic reorder had gone out short three Mondays running and a caterer and a restaurant had been let down. The hard half of the fix is not spotting the repeat; it is telling a repeat from a correction.
First of 10Algorithms
0 of 28 published
What Makes an Algorithm Fast
Big-O counts one operation and discards everything else, which is why two O(1) reads from the same array measured 0.66 and 193 nanoseconds: the same order, 294 times apart. This opens the Algorithms group by setting out what the notation claims and what it leaves to the machine, with the constant factor, the cache hierarchy, branch prediction and allocation measured rather than guessed. Amortised analysis gets the dynamic array as its worked case: a million pushes copy 1,048,575 elements under doubling and 499,999,500,000 under growth by one, and moving the shrink threshold from a quarter of the capacity to half turns a 29 nanosecond push-and-pop into 9.4 microseconds. Every figure here came out of Go's testing.B on one machine.
First of 28Concurrency
0 of 26 published
The Race Detector
A four-goroutine racy counter printed the right answer on ten runs out of ten, and the race detector failed it on the first run and exited 66. The mechanism is a vector clock per goroutine plus a bounded record of recent accesses per word, and it proves a race when two overlapping accesses have no ordering edge between them, which makes it byte-precise: adjacent bytes of one word went unreported while a one-byte overlap between two copies did not. Instrumentation measured 3.00 times the resident memory and a median 9.3 times the run time on a memory-bound loop against 2.5 times on a channel-bound one. What it never reports is the bug nobody asked it about: an atomic load followed by an atomic store returned 167,626 of 400,000 increments with no race to find.
First of 26Distributed Systems
0 of 30 published
The Write-Ahead Log
A write-ahead log is a file that changes are appended to before they are made, and the order of operations is what makes it work: frame the change, append it, fsync, then apply. The framing costs 67 nanoseconds an entry on the machine below and the fsync costs 216 microseconds, three thousand times more, which is why every real implementation groups entries behind one fsync: batching 128 of them cut the per-entry cost by a factor of 77. It also hands you a file whose tail is torn by every crash, so recovery has to treat the last entry as suspect, and 576 single-bit flips over a 72-byte log were all rejected by a four-byte checksum. What it does not do is bound its own size.
First of 30Refactorings
0 of 16 published
What Refactoring Actually Is
Refactoring is a change to a program's structure that leaves its observable behaviour identical, and a test suite is what makes the second half checkable rather than a hope. This post works one pricing function through six steps, from a single 34-line function to four small ones, with all 14,250 inputs in its domain agreeing at every state along the way. Then it slips one extra edit into step four, and 3,120 of those inputs disagree, which is the two-hat rule arriving as a number. It also measures what the rearrangement cost at run time: 5.3 nanoseconds a call before, 16.7 after, with a factor of two of that coming from one step.
First of 16Resilience
0 of 16 published
What Resilience Actually Costs
Every one of the sixteen stability patterns gives something up: capacity, latency, or whether the answer is current. In a tick-level simulation of one caller tier in front of one dependency, 54,097 requests through an unguarded system lost 4,476 that needed nothing from the dependency at all; bounding the dependency to twenty concurrent calls took that number to zero and refused 12,053 outright. The same bound, with nothing wrong anywhere, refused 396 requests the unguarded system answered. Steady state, fail fast, and the difference between a system that degrades and one that stops are the vocabulary the rest of this run uses. Every later post answers the question stated once here: what does this one give up.
First of 16