Issue 000 — the beginning, with caveats
First issue of the Weekly Fry: what fell off the truck, the lab's mistake, and one random thing worth your attention.
- newsletter
- edition-000
Welcome to the first issue of a roundup that promises to be weekly and commits only to being useful. No sponsorship, no paid placement, no affiliate link. If something here is wrong, the correction goes in the next issue, with your name on it if you want.
What fell off the truck
The week was dominated by a discussion that is not new and will not end: who validates what. Three different products announced validation features "in the database," which in practice means a constraint, and three times the same question came up in technical discussions: if the rule is in the database, how does the user get a decent message?
The answer is always the same and never satisfying: UX validation on the client, domain rule on the server, invariant in the database — and the three need to agree. When they do not, the one who pays the bill is the end-of-month reconciliation. I wrote about it in this week's article.
From the lab
The Jank Detector was born from a silly mistake: I ran the heuristic against the site itself and it failed the very page that contains it. The reason was an empty catch in a theme component. I fixed it, and now the tool passes on itself — which is the minimum integrity a detector can have.
Lesson of the week: an audit tool needs to run against its own author. It is uncomfortable, and that is exactly why it works.
Code worth a look
Two lines that solve a problem that usually turns into three queries and two concurrency bugs:
UPDATE contas
SET saldo = saldo - $1
WHERE id = $2
AND saldo >= $1
RETURNING saldo;
Reading, comparing, and writing in three steps looks more readable and is more fragile: another request can fit between the read and the write. A single statement with a condition in the WHERE survives concurrency and even returns the resulting balance. Worth the habit.
Internet thing
SQLite's documentation has a page dedicated to explaining when not to use SQLite. A tool that knows how to say where it is the wrong choice deserves more trust than a tool that promises to solve everything: sqlite.org/whentouse.html.
Next time
An investigation into why almost every slow system has an unused index, a new experiment in the lab, and the answer to the question "how many containers were really needed" — which already has a tool and still has no answer.
Subscribe to get the next issue. If you do not subscribe, nothing happens: the issue stays in the public archive anyway.