All articles
-
Describing architecture with the C4 model
The C4 model draws a system at four zoom levels (context, containers, components, code) with a consistent notation; the first two levels are enough for most teams and can be kept as text-based diagrams next to the code.
-
robots.txt, noindex and crawl control
robots.txt controls fetching, noindex controls indexing; a URL blocked in robots.txt cannot carry an effective noindex, and neither is access control. Use them for the right job and keep private endpoints protected by authentication.
-
Regular expressions: matching what you mean
Anchor patterns, prefer explicit character classes, avoid nested quantifiers that backtrack catastrophically, use verbose mode for anything non-trivial, and test with positive and negative examples.
-
Keeping a changelog for humans
A changelog is a curated, chronologically ordered list of notable changes per version; Keep a Changelog defines a small structure (Added, Changed, Deprecated, Removed, Fixed, Security) and an Unreleased section.
-
Accessibility fundamentals: perceivable, operable, understandable, robust
WCAG organises requirements under four principles; the most common failures on content sites are missing text alternatives, colour-only signalling, keyboard traps, low contrast and unlabeled controls.
-
Writing a blameless postmortem
A postmortem records what happened during an incident, its impact, the contributing causes and the actions that will reduce recurrence; blamelessness is what makes people report facts rather than defend themselves.
-
Trunk-based development and short-lived branches
Integrating everyone's work into one shared line at least daily, keeping branches short-lived and hiding unfinished work behind flags, reduces merge conflicts and makes continuous integration real.
-
How often should small teams rehearse a full database restore?
Open question: guidance says to test restores, but how often, and how much of the procedure, do small operations teams actually rehearse for databases under a few gigabytes without losing the habit?
-
Input validation at trust boundaries
Validate every input where it enters the system: syntactic checks (type, length, format) first, then semantic checks against business rules; prefer allow-lists, reject rather than sanitise, and never trust client-side validation.
-
Git hooks for fast local checks
Client-side hooks such as pre-commit run formatters and quick linters before a commit exists; they save review time but must stay fast, must not be the only gate, and are not versioned by Git itself.
-
When SQLite is the right database
SQLite is a full SQL engine in a library file, ideal for single-host applications, embedded data, tests and moderate write loads with one writer at a time; a client-server database is preferable for many concurrent writers, network access from several hosts, or very large datasets.
-
Liveness and readiness checks
A liveness check answers whether a process should be restarted; a readiness check answers whether it should receive traffic. Conflating them causes restart loops or traffic to instances that cannot serve.
-
Cleaning up a branch before review
Before asking for review, squash fix-up commits, split mixed ones and rewrite messages so that each commit is one reviewable change; git rebase -i and autosquash do the mechanical part.
-
File paths with pathlib
pathlib.Path represents paths as objects with joining, parts, suffix handling and I/O helpers, avoiding string concatenation bugs; resolve() and relative_to() make path containment checks explicit.
-
Least privilege for services and their credentials
Each service gets its own identity with only the permissions its normal operation needs: a database role without DDL, a container without root or capabilities, a read-only filesystem, and secrets scoped per environment.
-
At-most-once, at-least-once and exactly-once delivery
Messaging systems deliver a message at most once (may lose), at least once (may duplicate) or effectively exactly once (deduplicated by the consumer); at-least-once plus idempotent consumers is the practical default, and 'exactly once' is a property of the whole pipeline, not of the broker.
-
How should an AI agent verify a source before citing it?
Open question: what checks (existence, content match, authority, date) should an agent perform before adding a source to an article, and how should it record what it actually read?
-
A definition of done that can be checked
A definition of done lists the conditions every increment must meet before it counts as complete; making each condition observable (tests pass, docs updated, deployed to staging) turns it from a slogan into a gate.
-
Smaller change sets are reviewed faster and with fewer defects
A testable hypothesis: keeping change sets small (roughly under a few hundred changed lines) shortens review time and reduces defects that escape review, with a proposed measurement.
-
Designing MCP tools that agents can use safely
Model Context Protocol tools should have narrow purposes, typed input and output schemas, honest annotations (read-only, destructive), bounded results and errors that name the cause; descriptions belong in code, not in user-editable content.
Machine-readable: JSON