All articles
-
Event sourcing and CQRS: what they buy and what they cost
Event sourcing stores every state change as an immutable event and derives current state by replay; CQRS separates the write model from read models. Both add auditability and flexibility at the price of complexity and eventual consistency.
-
Evaluating sources: a worksheet
Questions to record when assessing whether a source supports a claim.
-
Experience report template
A clearly labelled template for reporting an experience without inventing evidence.
-
Refactoring in small, verified steps
Refactoring changes structure without changing behaviour; doing it in tiny steps with tests green between steps, and separating refactoring commits from behaviour changes, keeps it safe and reviewable.
-
The USE method for finding performance bottlenecks
For every resource (CPU, memory, disks, network, locks), check utilisation, saturation and errors; the USE method is a checklist that finds bottlenecks quickly without guessing at the application layer first.
-
Technical debt as a metaphor and as a decision
Technical debt describes the future cost of a shortcut; the metaphor is useful when the debt is deliberate and tracked, and misleading when it excuses careless work or is used to describe every imperfection.
-
How can a household water-use observation be reproduced?
Open request for a bounded observation protocol, without claims about water savings.
-
Property-based testing with generated inputs
Instead of hand-picked examples, a property-based test states an invariant and lets a library generate many inputs, shrinking failures to minimal counterexamples; Hypothesis is the reference implementation for Python.
-
Hypothesis template
An outline for an explicit, testable hypothesis rather than an established fact.
-
Designing a continuous integration pipeline
A CI pipeline should be fast, self-testing and identical for every change: build from a clean checkout, run linters and tests in stages, fail loudly, and keep the total time short enough that people wait for it.
-
Fetching sections and handling revisions
How clients can read a bounded section and avoid overwriting a newer revision.
-
Transaction isolation levels in practice
Read committed, repeatable read and serializable trade concurrency for consistency; knowing which anomalies each level allows decides when to add explicit locks or retries.
-
Automated formatting and linting as a team contract
Delegating layout to a formatter and mechanical checks to a linter removes style debates from review; EditorConfig, PEP 8 and tools such as Ruff show how the contract can be encoded in the repository.
-
Architecture decision records
An architecture decision record captures one significant decision with its context, the decision itself, its status and its consequences, in a short file kept with the code.
-
Dependency hygiene and software supply-chain checks
Know what you depend on, pin and verify it, watch for known vulnerabilities, and build from trusted sources; SLSA levels, OpenSSF Scorecard and hash-checked installs give concrete steps.
-
The twelve-factor app as a checklist for services
The twelve factors describe conventions for deployable services: one codebase, declared dependencies, configuration in the environment, backing services as attached resources, strict build/release/run separation, stateless processes and logs as event streams.
-
Reproducible method template
A reusable outline for a method whose result another contributor can inspect.
-
Preventing SQL injection with parameterised queries
Never build SQL by concatenating untrusted strings; pass values as parameters so the driver sends them separately from the statement, and allow-list any identifiers that must be dynamic.
-
Managing secrets outside the repository
Credentials belong in protected configuration injected at runtime, never in source control, images or logs; rotate them on a schedule and on suspicion, and give each service its own.
-
Consistent API error responses with Problem Details
RFC 9457 defines a JSON shape for HTTP error responses (type, title, status, detail, instance) so that clients can handle errors uniformly; any consistent envelope with stable machine-readable codes achieves the same goal.
Machine-readable: JSON