DEV Community: Anh Quân Nguyễn

What Base64 Actually Does to Your Bytes (and Why It's Not Encryption)

Anh Quân Nguyễn — Thu, 25 Jun 2026 03:03:54 +0000

Every developer pastes a data:image/png;base64,iVBORw0K... blob into their CSS at some point, decodes a JWT to see what's inside, or hits a "Basic " auth header and wonders why the password is just... sitting there. Base64 is everywhere in web development, and it's quietly misunderstood by a lot of people who use it daily. Here's what it actually is, what it costs, and the one mistake that shows up in production security reviews.

Base64 is a costume for binary, not a lock

The core idea: Base64 turns arbitrary binary data into plain ASCII text so it can travel through channels that only expect text. Email bodies, URLs, JSON values, HTML attributes, and HTTP headers were all designed for text — hand them raw bytes (a PNG, a 0x00, a UTF-16 string) and something downstream mangles or drops them. Base64 re-expresses those bytes using only safe, printable characters that nothing along the way will touch.

The alphabet is exactly 64 characters: A–Z, a–z, 0–9, plus + and /. That's 26 + 26 + 10 + 2 = 64. There's also =, used only for padding (more on that below). Sixty-four characters is the whole trick — and it's where the name comes from.

Critically: Base64 is encoding, not encryption. It provides zero secrecy. Anyone can reverse it instantly — there's no key. If you've ever "hidden" a credential by Base64-encoding it, you've hidden nothing; you've just made it slightly less obvious to a human skimming, and completely obvious to literally any tool. We'll come back to why that matters.

The 3-bytes-to-4-characters math

Here's the mechanism, and it explains everything else about Base64's behavior.

A byte is 8 bits. A Base64 character represents 6 bits (because 2⁶ = 64, exactly enough to index the alphabet). The least common multiple of 8 and 6 is 24, so Base64 works in groups of 3 bytes (24 bits) → 4 characters (4 × 6 bits):

Input:   3 bytes   = 24 bits
Regroup: 4 × 6-bit chunks
Output:  4 Base64 characters

Take the bytes for Cat (0x43 0x61 0x74), line up the 24 bits, slice them into four 6-bit numbers instead of three 8-bit ones, and look each up in the alphabet → Q2F0. That's the entire algorithm: regroup bits from 8-wide to 6-wide and map to characters.

Two consequences fall out of this immediately.

1. Base64 makes data ~33% bigger. Every 3 bytes in become 4 characters out, so output is 4/3 ≈ 1.33× the input size. That's the price of text-safety. A 3 MB image becomes ~4 MB of Base64 text. This is exactly why you don't Base64 large assets into your HTML/CSS — you inflate the payload by a third and make it un-cacheable as a separate file. You can watch this overhead directly by pasting text into a Base64 encoder/decoder and comparing input vs output length.

2. Padding (=) fills the gaps. If your data isn't a clean multiple of 3 bytes, the last group is short. Base64 pads the output to a multiple of 4 characters using =: one = means the last group had 2 bytes, two == means it had 1 byte. So a trailing == is normal and expected — it's not corruption, it's the encoder telling the decoder how many real bytes the final group held.

The URL-safe variant you'll meet in JWTs

Standard Base64 uses + and /. Both are a problem in URLs (/ is a path separator) and in filenames. So there's a second flavor, Base64URL, that swaps:

+ → -
/ → _
and usually drops the = padding entirely

This is what you see inside a JSON Web Token. A JWT is just three Base64URL strings joined by dots: header.payload.signature. Decode the first two segments and you get plain JSON — which is the second reason people get burned. A JWT payload is readable by anyone, because Base64URL isn't encryption either. The signature protects against tampering, not against reading. Never put secrets in a JWT payload. If you want to eyeball what's in one, decode the segment and run it through a JSON formatter to pretty-print the claims.

Where Base64 genuinely earns its keep

Data URIs — inlining a tiny icon or font directly in CSS/HTML (url(data:image/svg+xml;base64,...)) to save an HTTP request. Good for small assets only, because of the 33% tax.
Email attachments (MIME) — the original use case; SMTP is a text protocol, so binary attachments are Base64-encoded (historically wrapped at 76 characters per line).
HTTP Basic auth — Authorization: Basic <base64(user:pass)>. This is why Basic auth over plain HTTP is dangerous: the credentials are encoded, not encrypted, so anyone on the wire reads them. Always pair it with HTTPS.
Embedding binary in JSON/XML — JSON has no binary type, so byte blobs (small images, hashes, keys) get Base64'd into string fields.

The mistakes that show up in code review

Treating Base64 as security. Encoding ≠ encryption ≠ hashing. If the goal is secrecy, you need actual cryptography; if it's integrity, you need a hash or signature.
Base64-ing huge files. The 33% bloat plus the memory cost of holding both the binary and its text form will hurt. Stream or upload the raw bytes instead.
Mixing the two alphabets. Feeding standard Base64 (+, /) into a Base64URL decoder (or vice versa) fails or corrupts. Match the variant to the context — URLs and JWTs want Base64URL.
Panicking over =. Trailing padding is normal. Some systems strip it (and re-add it on decode); that's fine as long as both ends agree.

The takeaway

Base64 is a simple, elegant bit-regrouping scheme: 8-bit bytes re-sliced into 6-bit chunks so binary can ride through text-only pipes. It costs you a third more size and buys you universal compatibility — a great trade for small assets, MIME, and JSON, a bad one for big files. The single thing to burn into memory: it is not a security mechanism. Anything Base64-encoded is plainly readable by anyone who cares to look.

Next time you see a data: URI or a dotted JWT, you'll know exactly what those characters are — and that you could decode them yourself in a second.

Author bio: Quan Nguyen builds free, no-signup developer tools at calculators.im, including a Base64 encoder/decoder and a JSON formatter.

How UUIDs Actually Work: v4 Randomness, v7 Timestamps, and the Collision Math

Anh Quân Nguyễn — Mon, 22 Jun 2026 02:47:00 +0000

Every backend developer types uuid() a thousand times before ever asking what those 36 characters actually are. Then one day a senior engineer says "stop using v4 for your primary key, it's wrecking the index," and suddenly the thing you treated as a magic random string has versions, trade-offs, and a surprising amount of math underneath. Here is the whole picture.

A UUID is 128 bits wearing a costume

A UUID is just a 128-bit number. The familiar form — f47ac10b-58cc-4372-a567-0e02b2c3d479 — is those 128 bits written as 32 hexadecimal digits, split into groups of 8-4-4-4-12 with dashes for readability. The dashes carry no information; they're punctuation.

But not all 128 bits are free. Two small fields are reserved:

4 version bits — which UUID type this is (the 4 in ...-4372-... marks a version 4).
2 variant bits — which UUID spec it follows (almost always RFC 9562, the 2024 standard that replaced the old RFC 4122).

So a "random" UUID isn't 128 random bits. It's 122 random bits plus 6 bits of bookkeeping. That number matters later, so hold onto it.

The versions you'll actually meet

There are several versions, but three show up in real systems:

Version 1 — timestamp + MAC address. A 60-bit timestamp (100-nanosecond ticks since October 1582, of all dates) combined with a clock sequence and the machine's network MAC address. It's sortable by creation time, but it leaks where and when it was made — the MAC address is literally embedded. That privacy footgun is why v1 fell out of fashion.

Version 4 — (almost) all random. 122 random bits, no timestamp, no machine identity. It became the default because it's dead simple: no shared state, no coordination, any process can mint one offline and trust it's unique. This is what most uuid libraries hand you by default.

Version 7 — timestamp + randomness, done right. Standardized in RFC 9562 (2024). The first 48 bits are a Unix millisecond timestamp; the remaining bits (minus version/variant) are random. You get v4's "generate anywhere, no coordination" property and v1's time-ordering — without leaking a MAC address. v7 is the one the industry is quietly migrating to, for reasons that become obvious once you look at databases.

The collision question everyone asks about v4

"If v4 is random, won't two eventually be the same?" Yes — in the same sense that you might win the lottery twice on the same day. The interesting part is the actual scale.

With 122 random bits, there are 2^122 ≈ 5.3 × 10^36 possible v4 UUIDs. Naively you'd think you're safe until you've generated half of those. But collisions follow the birthday paradox: the chance two values match grows with the square of how many you generate, not linearly. The rule of thumb is that you reach a ~50% chance of any collision after roughly the square root of the space:

50% collision  ≈  1.18 × √(2^122)  ≈  2.7 × 10^18 UUIDs

That's 2.7 quintillion. To actually hit a coin-flip's worth of collision risk, you'd have to generate a billion UUIDs per second for about 85 years straight. For any normal application, v4 collisions are a non-event — you'll lose data to disk failure, bad migrations, and off-by-one bugs long before randomness betrays you.

If you want to feel the birthday-paradox effect for your own numbers — say, "what's the collision risk at 10 billion rows?" — it's the same combinatorics that powers lottery odds and hash-collision estimates; you can plug values into a permutation and combination calculator and watch how fast the probability climbs with the square of the count. It's a good intuition pump for why hash sizes and ID widths are chosen the way they are.

Why v4 quietly hurts your database

Here's the part that bites teams in production. If you make a v4 UUID your primary key on a database that clusters rows by primary key (InnoDB in MySQL, and effectively most B-tree primary indexes), every insert lands at a random position in the index.

Random insert positions mean:

Page splits everywhere. New rows don't append to the end; they wedge into the middle of already-full index pages, forcing the engine to split them.
Cache thrashing. Recently inserted rows are scattered across the whole index, so the hot pages your buffer pool wants to keep in memory keep changing.
Index bloat and fragmentation. Over millions of rows, the index grows larger and slower than a sequential key would.

An auto-increment integer never has this problem because every insert appends to the end. The tragedy of v4 is that you adopt it for the distributed, coordination-free generation — then pay for it in write amplification on a single database.

How v7 fixes it without giving up distribution

Version 7 puts a millisecond timestamp in the high bits. Because index ordering reads left to right, UUIDs generated close in time sort close together. Inserts become mostly sequential — new rows append near the end of the index, just like an auto-increment key — while the trailing random bits still guarantee uniqueness across processes with no shared counter.

So v7 gives you:

Append-friendly inserts (no random page splits)
Time-sortable IDs for free (great for "newest first" queries and pagination)
No central coordinator, no MAC leak

That's why "use v7 for primary keys, v4 only when you specifically want unpredictability" is becoming the standard advice. (ULID and KSUID are earlier, non-standard takes on the same time-prefix idea; v7 is the official version of that pattern.)

A practical cheat sheet

Public-facing or security-sensitive IDs (password-reset tokens, share links): you usually want unpredictability, so v4 — or a dedicated cryptographic token, not a UUID at all.
Database primary keys: prefer v7 for index locality; fall back to auto-increment if you don't need distributed generation.
Never parse meaning out of a UUID. Don't assume v1's timestamp, don't sort v4s expecting order, and don't treat a UUID as a secret just because it looks random.
Storage: store the 128 bits as a UUID/BINARY(16) column, not a 36-char string — you're otherwise spending 36 bytes to hold 16 bytes of data and slowing every index comparison.

The takeaway

A UUID isn't a random string; it's a 128-bit number with 6 reserved bits and a version that decides everything about how it behaves. v4 is random and collision-proof in practice but hostile to clustered indexes; v7 keeps the coordination-free magic while sorting by time so your database stops fighting you. Pick the version for the job instead of letting the library default decide.

If you just need a few to test with, you can generate UUIDs here — and next time someone on your team says "just use a UUID," you'll know which one they should mean.

Author bio: Quan Nguyen builds free, no-signup developer tools at calculators.im, including a UUID generator and a subnet calculator.

How `git diff` Actually Works: The Myers Algorithm in Plain English

Anh Quân Nguyễn — Fri, 19 Jun 2026 07:44:39 +0000

You run git diff dozens of times a day. You read the red and green lines, you stage the hunks, you move on. But there's a small algorithmic miracle happening every time: out of the astronomically many ways to describe "how file A became file B," the tool quietly finds one of the shortest ones.

That's not a formatting trick. It's a shortest-path search. Once you see it, code review, merge conflicts, and "why did git think I moved this whole block?" all start to make sense.

A diff is the shortest edit script

Forget the colored output. A diff between two sequences of lines — A (length N) and B (length M) — is an edit script: a list of insertions and deletions that turns A into B. There are always many valid scripts. The dumbest one is "delete all of A, insert all of B" — technically correct, completely useless.

What you actually want is the script with the fewest edits, because the lines you didn't touch are the ones that stayed the same. So the real goal is the mirror image:

Find the longest common subsequence (LCS) of A and B. Everything in it is "unchanged"; everything else is an insert or a delete.

The two framings are the same problem. If the LCS has length L, the minimum number of edits is exactly N + M - 2L. Maximize the matches, minimize the edits. That number — the edit distance — is what a diff is really computing.

Why the obvious approaches fail

The first instinct is line-by-line: walk both files in lockstep, mark lines that differ. That breaks the instant you insert a single line near the top — everything below shifts by one and the naive walk reports the entire rest of the file as changed. Useless for code review.

The textbook fix is the LCS dynamic-programming table: an (N+1) × (M+1) grid, fill it in, backtrack. It's correct, but it's O(N × M) time and memory. For two 10,000-line files that's 100 million cells. Git can't afford that on every status.

The insight that makes real diffs practical: edited files are usually similar. Most of the lines match. So instead of paying for the whole grid, pay only for the changes.

Myers: a diff is a shortest path through an edit graph

The algorithm Git uses by default is Eugene Myers' 1986 diff — and the whole thing rests on one reframing. Lay file A along the top of a grid and file B down the side. Now you're navigating from the top-left corner (0,0) to the bottom-right (N,M) with three moves:

→  move right   = delete a line from A
↓  move down    = insert a line from B
↘  move diagonal = the two lines match (FREE)

A diagonal move is only allowed when A[x] == B[y], and — this is the key — it's free. Right and down moves each cost 1. So:

The minimum diff is the cheapest path from corner to corner, and "cheapest" means "takes the most free diagonals."

A diff is a shortest-path problem. The long diagonal runs — Myers calls them snakes — are your unchanged blocks. The horizontal and vertical steps between them are the hunks you see in red and green.

The trick: search by number of edits, not by grid size

Myers doesn't fill the grid. He does a breadth-first search ordered by D = the number of edits so far (D = 0, 1, 2, …), and at each level tracks only the furthest-reaching path on each diagonal k = x - y. Greedily slide down every free diagonal you can before spending another edit. The first time a path reaches (N,M), the D that got it there is the edit distance, and the snakes along the way are the diff.

D = 0:  try to snake straight down the main diagonal from (0,0)
D = 1:  spend one edit (one right OR one down), then snake as far as possible
D = 2:  spend two edits, snake again
...
stop the moment a path touches (N, M)

Because it stops at the true edit distance D, the cost is O(N × D) — proportional to the file size times the number of changes, not the product of the two file sizes. When D is small (the normal case: a few edited lines in a big file), it's effectively linear. When you paste a wildly different file, D blows up and it degrades gracefully toward the DP cost. That "fast when similar" property is exactly what you want from a tool that runs on every keystroke in your editor's gutter.

Where the same idea shows up

Once a diff is "shortest path that maximizes free diagonals," you spot the pattern everywhere:

git diff, git blame, merge: all built on this edit-script core. The three-way merge that resolves your conflicts is two diffs against a common ancestor, reconciled.
Code review tools (GitHub, GitLab): the side-by-side view is the edit graph rendered as two columns; the connecting highlights are the snakes.
Text/JSON/config comparison: comparing two API responses or two YAML files is the same LCS problem on lines or tokens. (Pro tip: pretty-print or sort keys on both sides first — a noisy diff is usually just two differently-formatted versions of identical data. Running each side through a JSON formatter before comparing collapses the diff down to the changes that actually matter.)
rsync / binary deltas: same shortest-edit goal, different granularity (blocks instead of lines).
Bioinformatics: sequence alignment of DNA is LCS with weighted moves. Same grid, fancier costs.

The catch: a minimal diff isn't always a readable one

Here's the part that bites people. Myers finds a shortest edit script — but "fewest edits" and "what a human meant" aren't always the same. Move a function and the minimal diff might pair the closing } of your function with the } of the next one, producing that maddening hunk where braces and signatures are interleaved nonsense. The algorithm isn't wrong; minimizing edit count just doesn't know your code has structure. (This is why Git ships a --diff-algorithm=patience and histogram — different heuristics for choosing which minimal-ish diff reads best.)

So when a diff looks insane, it's not a bug. It's the shortest path honestly disagreeing with your sense of meaning. Switching algorithms, or eyeballing it in a clean side-by-side view that lets you flip between unified and split layouts, usually makes the human-intended change pop back out.

The takeaway

Next time you read a diff, don't think "it compared the lines." Think "it found the cheapest path through an edit graph, taking every free match it could." The green and red are the edits; the silent unchanged lines are the snakes the algorithm worked hard to keep. A diff isn't a comparison — it's a shortest-path proof that these few changes are all it took to get from A to B.

That's the whole idea behind the tool you trust with every commit. Not magic — just a very clever way of counting halts on a grid.

If you want to watch the snakes and edits line up on real input, I keep a free, privacy-first diff checker that runs entirely in the browser (no upload) with unified and side-by-side views — handy for eyeballing exactly which lines the algorithm called "changed."

The Math Behind O(log n): Binary Search, log , and Why Halving Wins

Anh Quân Nguyễn — Fri, 12 Jun 2026 10:15:58 +0000

You have read O(log n) a hundred times. Binary search is O(log n). A balanced BST lookup is O(log n). Heap insert is O(log n). We nod along — log n means "fast" — and move on.

But what is that logarithm actually counting? Once it clicks, a whole family of algorithms stops being trivia you memorized and becomes one idea you understand.

A logarithm counts halvings

Forget the textbook definition for a second. Here's the one that matters for algorithms:

log₂(n) is the number of times you can halve n before you reach 1.

That's it. Start with n, keep dividing by 2, count the steps:

64 → 32 → 16 → 8 → 4 → 2 → 1     = 6 steps   →  log₂(64) = 6
1000 → 500 → ... → ~1            ≈ 10 steps  →  log₂(1000) ≈ 9.97
1,000,000 → ...                 ≈ 20 steps  →  log₂(1,000,000) ≈ 19.93

The headline number every engineer should have burned into memory: log₂ of a million is about 20. A billion is about 30. The input grew by 1000×, the work grew by 10. That gap is the entire reason O(log n) feels like magic.

Binary search is just "halve until found"

Binary search is the canonical halving algorithm. Each comparison throws away half of what's left:

def binary_search(arr, target):
    lo, hi = 0, len(arr) - 1
    steps = 0
    while lo <= hi:
        steps += 1
        mid = (lo + hi) // 2
        if arr[mid] == target:
            return mid, steps
        elif arr[mid] < target:
            lo = mid + 1      # discard the lower half
        else:
            hi = mid - 1      # discard the upper half
    return -1, steps

Run it on a sorted array of one million integers and steps never exceeds 20 — no matter which element you search for. A linear scan would average 500,000 comparisons. Same data, same machine, a 25,000× difference in worst-case work. The only thing that changed is that binary search halves while the scan decrements.

That's the whole trick: decrementing gives you O(n); halving gives you O(log n).

Where halving shows up once you see it

The moment you read O(log n) as "halving," you start spotting the same move everywhere:

Balanced trees (AVL, red-black, B-trees): each level splits the remaining keys in two, so the tree is ~log₂(n) deep. A B-tree with a high branching factor b is log_b(n) deep — same idea, fatter halving. That's why a 4-level B-tree can index millions of rows.
Binary heaps: sift-up and sift-down walk one root-to-leaf path. Path length = tree height = O(log n).
Divide and conquer: merge sort splits the array in half each level, giving log₂(n) levels of O(n) work → O(n log n). The log factor is the number of splits.
Bits: the number of bits to represent n is ⌈log₂(n+1)⌉. "How many bits?" and "how many halvings?" are literally the same question.
Exponential search / doubling: when you double a buffer or probe 1, 2, 4, 8, …, you reach n in log₂(n) steps. Halving, run backwards.

"But my data isn't a power of two"

Real inputs aren't clean powers of 2, and the base isn't always 2 — a ternary split is log₃, a B-tree with branching factor 256 is log₂₅₆. When you need the actual value for a back-of-the-envelope estimate, you lean on the change-of-base formula:

log_b(n) = ln(n) / ln(b) = log₁₀(n) / log₁₀(b)

So the depth of a B-tree holding 10 million keys with a branching factor of 256 is log₂₅₆(10,000,000) = ln(10,000,000) / ln(256) ≈ 16.1 / 5.55 ≈ 2.9 — three levels. You can punch that into any logarithm calculator that supports an arbitrary base instead of reaching for a language's math.log(x, base) mid-discussion. The point isn't the tool; it's that base is just branching factor, and change-of-base lets you compare a binary split against a 256-way split on the same axis.

One more identity worth keeping: in Big-O, the base doesn't matter. log₂(n) and log₁₀(n) differ only by the constant factor 1/ln(2) vs 1/ln(10), and Big-O eats constants. That's why we write O(log n) with no base at all — the existence of halving is what we're claiming, not its flavor.

The takeaway

Next time you read O(log n), don't translate it to "fast." Translate it to "this algorithm halves the problem every step," and ask where the halving happens — the comparison, the tree level, the recursive split, the doubling buffer. That single reframing turns binary search, balanced trees, heaps, and divide-and-conquer into variations on one theme instead of four things to memorize.

Halving is the cheapest superpower in computer science. Logarithms are just how we count it.

Time Math Is Harder Than It Looks: 6 Duration Bugs and How to Avoid Them

Anh Quân Nguyễn — Sat, 06 Jun 2026 22:22:17 +0000

Adding two durations sounds like first-grade math. 2:45 plus 1:30 — easy, right? Then a ticket comes in: a user logged 11:45 PM → 7:15 AM and your timesheet says they worked negative 16 hours. Welcome to time arithmetic, where the obvious answer is usually wrong.

Here are six duration bugs I keep seeing in code reviews, and the mental model that makes them go away.

1. Minutes are base-60, not base-100

The number-one duration bug is treating 1:30 as the decimal 1.30. It isn't — it's 1.5 hours. If you store time as HH:MM strings and do arithmetic on the pieces without normalizing, you get garbage.

// WRONG: treats minutes like a decimal fraction
const hours = 2.45 + 1.30; // 3.75 ❌ (you meant 2h45m + 1h30m)

// RIGHT: normalize to a single base unit first
const toMinutes = (h, m) => h * 60 + m;
const total = toMinutes(2, 45) + toMinutes(1, 30); // 255 minutes
const fmt = `${Math.floor(total / 60)}:${String(total % 60).padStart(2, "0")}`; // "4:15" ✅

Rule: convert everything to one base unit (seconds or minutes), do the math, convert back at the end. When I just need to confirm a result by hand before trusting my code, I'll punch the two values into a time calculator and check the output matches — faster than adding a console.log and re-running.

2. Crossing midnight makes durations go negative

The 11:45 PM → 7:15 AM case. If end < start, the interval wrapped past midnight. Naive subtraction gives a negative number.

let diff = endMin - startMin;
if (diff < 0) diff += 24 * 60; // add a full day to unwrap

This bites overnight shifts, sleep trackers, and anything spanning a day boundary. The fix is one line, but only if you remember the case exists.

3. 12-hour vs 24-hour parsing

12:00 PM is noon. 12:00 AM is midnight. Almost every hand-rolled AM/PM parser gets the 12 case backwards because the conversion isn't +12 for PM — it's special-cased at 12.

function to24(h, period) {
  if (period === "AM") return h === 12 ? 0 : h;
  return h === 12 ? 12 : h + 12;
}

If your product serves both US (12h) and most of Europe (24h), normalize on input and store 24h internally. Display formatting is a presentation concern — keep it out of your math layer.

4. DST means a "day" isn't always 24 hours

Twice a year, a calendar day is 23 or 25 hours long. If you compute durations by subtracting wall-clock times across a DST boundary, you'll be off by an hour. This is why you never do duration math on local timestamps — convert to UTC (or epoch seconds) first, subtract, then format back to local for display.

const start = new Date("2026-03-08T01:30:00-05:00"); // before US spring-forward
const end   = new Date("2026-03-08T03:30:00-04:00"); // after
const hours = (end - start) / 3.6e6; // 1 hour, not 2 — DST ate an hour

For calendar-level differences (business days, age, date spans) the same UTC-first principle applies — our date calculator handles that side, working in whole days rather than clock time.

5. Epoch math is your friend — until you mix units

Date.now() returns milliseconds. Unix time() in most backends returns seconds. Postgres EXTRACT(EPOCH ...) returns seconds (as a float). Mix them and you're off by 1000×.

const ms = Date.now();            // 1780736400000
const sec = Math.floor(ms / 1000); // 1780736400

When I'm debugging a raw epoch value and need to see it as a human time, I keep a unix timestamp converter open rather than mentally dividing by 1000 and squinting.

6. Decimal hours for payroll rounding

Payroll systems want decimal hours (8.25), not 8:15. The conversion is minutes / 60, but rounding policy matters: some jurisdictions round to the nearest quarter-hour, some truncate. Decide the policy explicitly — don't let toFixed(2) make it for you.

const decimal = totalMinutes / 60;        // 8.25
const quarterRounded = Math.round(decimal * 4) / 4; // nearest 0.25

This is exactly the conversion a time calculator does when it shows both HH:MM and decimal output — handy when you're reconciling a timesheet against what your code produced.

The one mental model

Every one of these bugs comes from doing arithmetic in a representation that isn't additive. Wall-clock HH:MM strings aren't additive (base-60, midnight wrap, DST). Local timestamps aren't additive (DST, timezones). Seconds-since-epoch are additive. So:

Parse input into a single base unit (epoch seconds, or total minutes for clock durations).
Do all math there.
Format back to human representation only at the very end.

Get that pipeline right and time math stops surprising you.

JSON Schema in 10 Minutes — Validation, Types & Real Examples

Anh Quân Nguyễn — Tue, 26 May 2026 03:44:14 +0000

Two years ago I shipped a webhook handler without input validation. A partner started sending us a slightly malformed payload (an extra field, one missing required field) and our worker silently processed garbage into the database for three days before anyone noticed. By the time I traced it, we had 12,000 corrupt rows and a very awkward customer call.

I learned JSON Schema the next week. This post is the cheat sheet I wish someone had handed me on day one — the keywords I actually use, the gotchas that bit me again later, and the honest comparison with OpenAPI and TypeScript types.

The seven types you'll use

Every JSON value is one of seven types: string, number, integer, boolean, object, array, or null. The integer type is a JSON Schema convenience (raw JSON only has number) but the schema layer enforces "no decimal places." A minimal schema:

{
  "type": "string"
}

That validates any string and rejects everything else. You can also accept a union:

{
  "type": ["string", "null"]
}

Useful for optional fields you want to keep present in the payload rather than omitting. Before I write more than a one-line schema I usually paste a sample payload into a JSON formatter to see the actual shape pretty-printed. Type errors almost always come from misreading the structure.

Objects, required, and the additionalProperties trap

Most real validation work happens on objects. The three keywords you use every day are properties, required, and additionalProperties:

{
  "type": "object",
  "properties": {
    "email":    { "type": "string" },
    "age":      { "type": "integer" },
    "verified": { "type": "boolean" }
  },
  "required": ["email"],
  "additionalProperties": false
}

Three gotchas to internalize. First, properties describes each field but does NOT make any of them required. Without the required array, every property is optional. Second, required is a separate list of property names that must be present (presence only, you still need type to validate the value). Third, additionalProperties: false rejects any property not listed. Without this line, the schema accepts arbitrary extra fields silently. This was the bug that hit me — the partner was sending email_address instead of email, and without additionalProperties: false my schema accepted it as "no email + an unknown field."

Set additionalProperties: false by default. Remove it only when you genuinely want a free-form object. For maps with arbitrary keys but a known value type, use it as a schema instead of a boolean:

{
  "type": "object",
  "additionalProperties": { "type": "number" }
}

That validates any object where every value is a number. Perfect for price lookup tables, feature-flag percentages, or anything keyed dynamically.

String validation: minLength, pattern, format, enum

Real string validation goes beyond "is it a string." The keywords that earn their keep:

minLength / maxLength, integer bounds on UTF-16 code units (not bytes, not graphemes)
pattern, ECMA-262 regex the string must match somewhere (use ^...$ anchors for a full match)
format, named formats like email, uri, date, date-time, uuid, ipv4, ipv6
enum, a fixed list of allowed values (works for any type)
const, a single allowed value (equivalent to a one-item enum)

A practical username field:

{
  "type": "string",
  "minLength": 3,
  "maxLength": 20,
  "pattern": "^[a-zA-Z0-9_]+$"
}

One gotcha that cost me a day: format is informational by default in older drafts. You must enable format assertion in your validator. Ajv requires ajv-formats. Python jsonschema needs format_checker. Without it, "format": "email" documents intent but does not actually reject invalid emails. See the JSON Schema spec for format for the full list and the assertion behavior per draft.

Number validation: minimum, maximum, multipleOf

For numbers and integers, the validation keywords are arithmetic:

minimum / maximum, inclusive bounds
exclusiveMinimum / exclusiveMaximum, exclusive bounds (in Draft 2020-12 these take a number, in older drafts they took a boolean)
multipleOf, the value must be a multiple of this number

Validating a percentage that must be 0 to 100 in 0.01 increments:

{
  "type": "number",
  "minimum": 0,
  "maximum": 100,
  "multipleOf": 0.01
}

multipleOf has a floating-point trap I keep getting wrong. 0.1 is not exactly representable in IEEE 754, so { "multipleOf": 0.1 } will sometimes reject values you expect to pass. For money, I now store and validate as integer cents ({ "type": "integer", "minimum": 0 }). It is the same precision argument behind storing prices in the smallest currency unit everywhere else in the stack.

Array validation: items, minItems, uniqueItems

For arrays the workhorses are items (schema applied to every element), minItems / maxItems (length bounds), and uniqueItems (rejects duplicates by deep equality). A list of unique tags:

{
  "type": "array",
  "items": { "type": "string", "minLength": 1 },
  "minItems": 1,
  "maxItems": 10,
  "uniqueItems": true
}

For positional tuples where each index has a different schema, use prefixItems in Draft 2020-12 or items as an array in older drafts. A coordinate pair where index 0 is longitude and index 1 is latitude:

{
  "type": "array",
  "prefixItems": [
    { "type": "number", "minimum": -180, "maximum": 180 },
    { "type": "number", "minimum":  -90, "maximum":  90 }
  ],
  "items": false
}

The trailing "items": false rejects any extra elements beyond the two declared positions. The array equivalent of additionalProperties: false.

Schema composition: $ref, allOf, oneOf, anyOf

Once your schemas grow past a single page, you will want to break them up and combine them. JSON Schema has four composition keywords:

$ref, reuse another schema by JSON Pointer (e.g., "#/$defs/address" or an external URL)
allOf, data must validate against every subschema (intersection / mixin)
anyOf, data must validate against at least one (union, OK if multiple match)
oneOf, data must validate against exactly one (XOR, rejects if zero or multiple match)

A reusable address schema referenced from two parents:

{
  "$defs": {
    "address": {
      "type": "object",
      "properties": {
        "street":  { "type": "string" },
        "city":    { "type": "string" },
        "country": { "type": "string", "minLength": 2, "maxLength": 2 }
      },
      "required": ["street", "city", "country"]
    }
  },
  "type": "object",
  "properties": {
    "shipping": { "$ref": "#/$defs/address" },
    "billing":  { "$ref": "#/$defs/address" }
  }
}

For discriminated unions (event types, message kinds), oneOf with a const discriminator is the standard pattern:

{
  "oneOf": [
    { "type": "object", "properties": { "kind": { "const": "email" },
        "to": { "type": "string", "format": "email" } }, "required": ["kind", "to"] },
    { "type": "object", "properties": { "kind": { "const": "sms" },
        "phone": { "type": "string", "pattern": "^\\+[1-9]\\d{1,14}$" } }, "required": ["kind", "phone"] }
  ]
}

A real signup schema

Putting every keyword together, here is roughly the schema I now use for a signup endpoint:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "SignupRequest",
  "type": "object",
  "properties": {
    "email":     { "type": "string", "format": "email", "maxLength": 254 },
    "password":  { "type": "string", "minLength": 12, "maxLength": 128 },
    "username":  { "type": "string", "pattern": "^[a-zA-Z0-9_]{3,20}$" },
    "age":       { "type": "integer", "minimum": 13, "maximum": 120 },
    "country":   { "type": "string", "enum": ["US", "UK", "CA", "AU"] },
    "newsletter":{ "type": "boolean", "default": false },
    "referrals": { "type": "array", "items": { "type": "string", "format": "email" },
                   "maxItems": 5, "uniqueItems": true }
  },
  "required": ["email", "password", "username", "age", "country"],
  "additionalProperties": false
}

It enforces the email format with the 254-char maximum from RFC 5321, a 12-character minimum password from NIST SP 800-63B, a regex-validated username, an integer age within plausible bounds, a closed enum of supported countries, an optional boolean with a documented default, and an optional referral list capped at 5 unique emails. The trailing additionalProperties: false is the line that would have saved me three days and 12,000 rows two years ago.

Tooling: Ajv (Node) and jsonschema (Python)

Declare which draft you target with the $schema keyword at the root. The two production-grade validators I reach for:

Ajv for Node.js and browser, the fastest JS validator, supports Draft 2020-12. Install ajv and ajv-formats together if you use format. Compile schemas once at startup with const validate = ajv.compile(schema), then call validate(data) on every request. This is 10 to 100 times faster than recompiling per call.
jsonschema for Python, the reference Python validator. Use Draft202012Validator(schema).validate(data) or iterate .iter_errors(data) to surface all errors at once instead of failing on the first.

For quick iteration without writing code, I usually paste the schema and a sample payload into a JSON formatter to confirm both parse, then run them through a browser-based validator. When debugging an unexpected failure, a diff checker helps me compare a failing payload against a known-good payload to spot the offending field.

JSON Schema vs OpenAPI vs TypeScript

These three describe data shapes but solve different problems:

TypeScript types are compile-time only. They vanish at runtime, so a malformed API payload will silently corrupt your program if you trust the type without validating. Great for developer ergonomics, useless for runtime safety.
JSON Schema is runtime validation that works in any language. Use it at API boundaries, for config files, for database documents, and for any cross-language data contract. A single schema can drive validation in your Node frontend, Python backend, and Go worker without rewriting.
OpenAPI (formerly Swagger) wraps JSON Schema inside an API description. It adds endpoints, methods, status codes, authentication, examples, and tooling for client SDK generation. Use it when you are describing an HTTP API and want documentation, client codegen, and validation in one document.

The stack I default to now: write the JSON Schema as source of truth, generate TypeScript types from it with json-schema-to-typescript, and embed the same schema inside an OpenAPI spec for HTTP routes. One source, three outputs, no drift.

The mistakes I kept making

1. Forgetting `additionalProperties: false`

The original bug. Without it, any extra field passes validation. A client typo like { "emial": "x@y.com" } validates as "no email present plus an unknown field" instead of the clean error you want. Add it by default.

2. Confusing `required` with `type`

Listing a property under properties does NOT make it required. You must also add it to the required array. Conversely, required only checks presence. A wrong-type field still fails, but on the type check, not the required check.

3. Using `format` without enabling assertion

In Ajv you must require('ajv-formats')(ajv). In Python jsonschema pass format_checker=FormatChecker(). Without this, format: email is metadata only and accepts any string. I burned half a day on this one.

4. `oneOf` where `anyOf` is correct

oneOf rejects data that matches more than one subschema. If your subschemas overlap (a value that is both a positive integer and a multiple of 5), oneOf rejects. Use it only for genuinely disjoint cases like discriminated unions.

5. `multipleOf` with floats

IEEE 754 cannot exactly represent 0.1. { "multipleOf": 0.1 } will reject values you expect to pass. Use integer units (cents, basis points) instead.

6. Recompiling schemas on every request

Ajv's compile() is expensive. The compiled validator is fast. Compile once at module load, store the function, reuse it.

Closing thought

JSON Schema looks verbose at first. Often the schema is longer than the data. That is the point. Every constraint you encode is one bug you cannot ship. Start with your top three API endpoints, then your config files, then your cross-service messages. Within a sprint you will catch at least one bug that would have made it to production.

If you want a sandbox, try the JSON Schema Reference Tutorial and an online validator like jsonschemavalidator.net. And if you ever debug a pattern validation that is misbehaving, a regex tester is faster than guessing.

Originally published at calculators.im.

I Keep Forgetting Subnet Math — Here's the Cheat Sheet I Actually Use

Anh Quân Nguyễn — Tue, 19 May 2026 03:17:29 +0000

I have been writing backend code for years and I still cannot tell you, off the top of my head, how many usable hosts are in a /22. Every time I open an AWS VPC config or a Kubernetes cluster blueprint, I do the same Google search: "subnet calculator", click whatever ranks first, type my CIDR, write down the answer. Then I forget all of it within a week.

After the fourth or fifth time I had to look up whether /27 gives me 30 or 32 usable IPs, I sat down and built a one-page cheat sheet for myself. This post is that cheat sheet, plus the few mental shortcuts that have actually stuck. If you ship to cloud and only touch subnet math a few times a year, this is the post I wish I had bookmarked.

The three numbers that matter

For any CIDR, only three numbers matter in practice:

Block size — how many IPs total. Formula: 2^(32 − prefix). A /24 has 256 addresses.
Usable hosts — block size minus 2 (one for the network address, one for the broadcast). A /24 has 254 usable.
Magic number — 256 − mask_octet. Tells you where the next subnet starts. For /26 (mask 255.255.255.192), the magic number is 64, so subnets land at .0, .64, .128, .192.

Memorize one table and you will never need to do binary math in your head again:

Prefix	Block size	Usable hosts	Mask	Magic
/22	1,024	1,022	255.255.252.0	4 (3rd octet)
/23	512	510	255.255.254.0	2 (3rd octet)
/24	256	254	255.255.255.0	—
/25	128	126	255.255.255.128	128
/26	64	62	255.255.255.192	64
/27	32	30	255.255.255.224	32
/28	16	14	255.255.255.240	16
/29	8	6	255.255.255.248	8
/30	4	2	255.255.255.252	4

That is the entire subnet math for 99% of cloud work. Print it, tape it to your monitor, move on.

The magic number trick, with a worked example

Suppose someone gives you the IP 10.20.30.45/26 and asks for the network and broadcast addresses. No calculator, no binary conversion.

Prefix is /26, so the magic number is 64.
Look at the last octet: 45. Which multiple of 64 does it fall into? 0, 64, 128, 192. 45 is in the 0–63 block.
Network address: 10.20.30.0. Broadcast: 10.20.30.63 (one less than the next subnet, which would start at .64).
Usable range: 10.20.30.1 to 10.20.30.62.

Same trick for prefixes that fall in the third octet. 10.20.30.45/22 → magic number is 4, applied to the third octet. 30 falls in the 28–31 block (because 28 is the closest multiple of 4 at or below 30). Network: 10.20.28.0. Broadcast: 10.20.31.255. Block spans four /24s.

If your subnet boundaries do not look "round" — say 10.20.30.0/22 — that is a malformed CIDR. The network address must align to the magic number. 10.20.30.0 is not a valid /22 start; 10.20.28.0/22 is.

Cloud-specific gotchas you will hit

The textbook subnet math is the easy part. What actually trips up cloud engineers is the platform-specific quirks layered on top.

AWS VPC

AWS reserves five addresses per subnet, not two. The network address, the broadcast, and three more: the VPC router, DNS, and a future-use address. So a /28 AWS subnet has 11 usable IPs, not 14. This catches people every time they try to fit "exactly 14 EC2 instances" into a /28 and run out of IPs at instance #12.

VPC CIDR sizing also has hard limits: minimum /28, maximum /16. You can attach secondary CIDR blocks, but you cannot ever shrink a primary CIDR after creation. Always size up. A /16 gives you 65,536 addresses for free; there is no cost penalty for picking a large VPC CIDR and no benefit to picking a tight one.

Kubernetes

A typical EKS or GKE cluster needs three separate CIDRs:

Node CIDR — a subnet of the VPC, one IP per node (plus AWS's five). Size for max-nodes × 2.
Pod CIDR — usually 10.244.0.0/16 (Flannel default) or 192.168.0.0/16 (Calico). Each node gets a /24 slice (Flannel) so the cluster maxes out at 254 nodes with a /16 pod CIDR. Larger clusters need /12 or smaller per-node allocations.
Service CIDR — usually 10.96.0.0/12 (kubeadm default). Sized for total Services, not Pods. A /16 is overkill for most clusters; a /20 is plenty.

The most common k8s networking mistake is overlapping the pod CIDR with the VPC CIDR. Pick non-overlapping ranges from day one — renumbering pod CIDR in a running cluster is a recreate-the-cluster operation.

Docker

Docker's default bridge is 172.17.0.0/16. The default docker network create allocates from 172.18.0.0/16 upward in /24 chunks. If your corporate VPN also uses 172.x.x.x ranges (very common), you will get phantom routing failures where Docker containers can reach the internet but cannot reach internal services. Reconfigure Docker's default address pools in /etc/docker/daemon.json:

{
  "default-address-pools": [
    {"base": "10.99.0.0/16", "size": 24}
  ]
}

This carves Docker out of the 172.x space and into a private 10.x range your VPN almost certainly does not use.

Subnet math in code (Python and Go)

When you actually need to compute subnets programmatically — generating Terraform, validating user input, planning a migration — every modern language has a stdlib for this.

Python uses ipaddress:

import ipaddress

# Parse a network
net = ipaddress.ip_network("10.20.30.0/22")
print(net.network_address)    # 10.20.28.0 — auto-normalized!
print(net.broadcast_address)  # 10.20.31.255
print(net.num_addresses)      # 1024
print(len(list(net.hosts()))) # 1022 — excludes network + broadcast

# Check if an IP is in a subnet
ip = ipaddress.ip_address("10.20.29.50")
print(ip in net)  # True

# Subdivide a /22 into /24s
for sub in net.subnets(new_prefix=24):
    print(sub)
# 10.20.28.0/24
# 10.20.29.0/24
# 10.20.30.0/24
# 10.20.31.0/24

# Detect overlap (catches the VLSM mistake from earlier)
a = ipaddress.ip_network("10.0.0.0/25")
b = ipaddress.ip_network("10.0.0.64/26")
print(a.overlaps(b))  # True

Note: passing strict=False to ip_network lets you parse 10.20.30.0/22 (a malformed CIDR — .30 is not the network address). With strict=True (the default since Python 3.9) it raises ValueError. Use strict=True in production input validation; the explicit error is far more useful than a silently-corrected network.

Go uses net/netip (Go 1.18+):

package main

import (
    "fmt"
    "net/netip"
)

func main() {
    prefix, _ := netip.ParsePrefix("10.20.30.0/22")
    // Normalize to actual network address
    prefix = prefix.Masked()
    fmt.Println(prefix.Addr())   // 10.20.28.0
    fmt.Println(prefix.Bits())   // 22

    ip, _ := netip.ParseAddr("10.20.29.50")
    fmt.Println(prefix.Contains(ip))  // true
}

The older net.IPNet API still works but net/netip is value-typed, allocation-free, and the recommended choice for new code.

A 30-second AWS CLI sanity check

When debugging "why can't my EC2 instance reach this other EC2 instance," step one is always: are they on subnets that route to each other? Quick CLI check:

# List subnets with their CIDRs in the current VPC
aws ec2 describe-subnets \
  --query 'Subnets[*].[SubnetId,CidrBlock,AvailabilityZone]' \
  --output table

# Check route table for a subnet
aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-abc123 \
  --query 'RouteTables[*].Routes' \
  --output table

If two subnets are in the same VPC and the route tables both have local routes for the VPC CIDR, they can reach each other (assuming security groups and NACLs allow). Most "why no connectivity" tickets resolve here.

Three mistakes I have personally shipped to production

Subnet too small. A /28 for "we only need 10 instances" — then AWS takes 5, leaving 11. Add a load balancer, add scaling, you are out of IPs. Always start at /24 for any production subnet unless you have a hard reason not to.

Pod CIDR overlapping VPC CIDR. Created a GKE cluster with default pod CIDR 10.0.0.0/14 inside a VPC at 10.0.0.0/16. Cluster came up, pods on the same node could reach each other, pods on different nodes silently dropped traffic. Three hours debugging later: pick non-overlapping CIDRs.

Forgot AWS's 5 reserved IPs. Provisioned 14 EC2 instances in a fresh /28. First 11 launched fine, the rest failed with InsufficientFreeAddressesInSubnet. The fix is /27 (32 addresses, 27 usable after AWS reservations).

Closing — make subnet math boring

The whole point of the cheat sheet is that subnet math should be boring. You should not have to think about it. You should be able to glance at a CIDR, know the block size and the magic number, and move on to whatever interesting problem you were actually trying to solve.

If you need to verify a non-trivial CIDR or plan a VLSM allocation across multiple subnets, I built a free subnet calculator that handles IPv4, IPv6, and VLSM planning. There's also a longer-form guide on the math behind CIDR, VLSM, and IPv6 subnetting if you want to go deeper than this cheat sheet.

The tool is free, no signup, no tracking. If it saves you a Google search next quarter, that is the entire goal.

Cross-posted with canonical from calculators.im.

Lessons Learned Building 270+ Online Calculators: A Developer's Deep Dive

Anh Quân Nguyễn — Tue, 21 Apr 2026 10:26:03 +0000

When I started building calculators.im, I thought it would be a simple project — create a few calculator pages, deploy, done. Two years and 270+ calculators later, I've learned more about web performance, SEO, and product scaling than I ever expected. Here's everything I wish someone had told me before I started.

The Project: What Is calculators.im?

calculators.im is a collection of 270+ free online calculators covering everything from finance (mortgage, compound interest, ROI) to health (BMI, calorie needs, pregnancy due date) to math (scientific, percentage, fractions) and beyond.

The tech stack: Go for the backend, HTMX for interactivity, Tailwind CSS for styling, Redis for caching, and NGINX + Cloudflare for serving.

Lesson 1: SEO Is 80% of Your Traffic — Treat It as a Feature

I originally thought "build good calculators and they'll come." Wrong.

The reality: calculator sites are brutally competitive. There are dozens of sites competing for every keyword like "mortgage calculator" or "BMI calculator." Here's what actually works:

Target long-tail keywords over short ones. Instead of competing for "loan calculator" (dominated by Bankrate, NerdWallet), target "car loan calculator with extra payments" or "loan calculator with balloon payment." Lower competition, still significant volume.

Schema markup is non-negotiable. Adding WebApplication and FAQPage schema to each calculator dramatically increased click-through rates. Google often shows rich results in SERPs for tool pages with proper schema.

Page speed = ranking factor for tools. Users expect calculators to respond instantly. Every 100ms of latency costs you. With Go + HTMX, our Time to First Byte (TTFB) is under 50ms globally thanks to Cloudflare caching.

Lesson 2: HTMX Was the Right Bet — But Has Trade-offs

Choosing HTMX over React was controversial when I started. Here's the honest verdict after building 270 pages:

Wins:

Zero client-side hydration = better Core Web Vitals (LCP, CLS)
SEO-friendly by default — all content is server-rendered
Bundle size: ~14kb for htmx vs 130kb+ for a React app
Simpler mental model: HTML attributes over JavaScript state management

Trade-offs:

Complex interactions (real-time charts, drag-and-drop) require either Hyperscript or vanilla JS alongside HTMX
The community is smaller than React's, so fewer StackOverflow answers
Some HTMX patterns feel verbose for highly dynamic UIs

Would I choose HTMX again? Yes — especially for content-heavy tool sites where SEO matters. For a complex SaaS dashboard, I'd reconsider.

Lesson 3: Go Is Overkill for Small Projects — Perfect for Scale

Go was genuinely the right choice, but not for the reasons I expected:

Memory footprint: Our entire server runs on a $6/month VPS and handles thousands of daily visits with ~30MB RAM usage. A Node.js equivalent would use 5-10x more memory.

Compilation catches bugs early. Go's strict type system eliminated an entire category of runtime errors that plague dynamic-language projects.

Single binary deployment. go build, rsync to server, restart. No npm install, no dependency conflicts, no environment issues.

The unexpected lesson: Go forces you to be explicit about error handling. At first this feels tedious (if err != nil everywhere), but it makes your code dramatically more reliable in production.

Lesson 4: Calculator UX Is Harder Than It Looks

Building a "simple" calculator that delights users involves surprisingly subtle decisions:

Input formatting: Users expect numbers to auto-format (1000 → 1,000) as they type. Implementing this with HTMX + Go required careful input sanitization to avoid formatting conflicts.

Instant results: Never make users click a "Calculate" button. Use HTMX's hx-trigger="input" to recalculate on every keystroke. Users expect calculator-app behavior from web calculators.

Mobile-first number inputs: On mobile, use inputmode="decimal" rather than type="number". The decimal keyboard is much better than the native number input's spinner interface for financial inputs.

Error states matter: When a user enters invalid input (letters in a number field, negative age, etc.), show clear, friendly error messages in context — not a page-level alert.

Lesson 5: The Content Around the Calculator Matters More Than the Calculator

This was my biggest revelation: the page content surrounding the calculator is more important for SEO than the calculator itself.

Every calculator page on calculators.im includes:

A 500-800 word explanation of the formula and methodology
A worked example with real numbers
An FAQ section targeting "People Also Ask" queries
A table of common values for reference

This content strategy is what earns backlinks, ranks for informational queries, and keeps users on the page longer — all positive signals.

Lesson 6: Redis Caching Saved Us at Scale

When a Reddit post linked to our percentage calculator, we got ~8,000 visits in 2 hours. Without Redis caching:

Every request would hit Go and render the page fresh
At 8,000 req/hr, that's manageable but wasteful

With Redis:

Static page HTML is cached for 1 hour
Dynamic calculation results are cached by input parameters
Cache hit rate during the spike: 94%
P99 response time during the spike: 18ms

The caching strategy: cache at two layers — page-level (full HTML response via Cloudflare) and calculation-level (Redis for computed results with the same inputs).

Lesson 7: Build the Infrastructure Once, Deploy 270 Times

The most important architectural decision was treating calculators as data, not code.

Each calculator is defined by a YAML config file:

Input fields with types, labels, validation rules
Formula as a Go expression
Output formatting
SEO metadata

The Go backend reads these configs and generates both the HTML and the calculation logic dynamically. Adding a new calculator takes about 15 minutes — write the YAML, write the formula, deploy.

This approach let us go from 10 calculators to 270+ without a linear increase in development time.

What I'd Do Differently

Start with the content strategy, not the calculator. Write the explanatory content first, then build the tool around it.
Add structured data from day 1. Retrofitting schema markup to 270 pages was painful.
Build analytics from the start. Understanding which calculators get used heavily vs. which ones are ignored shapes your roadmap.

The Stack in Summary

Backend: Go — fast, cheap to run, rock-solid
Frontend interactivity: HTMX — SEO-friendly, tiny footprint
Styling: Tailwind CSS — consistent, maintainable
Caching: Redis — essential at any meaningful scale
Infrastructure: NGINX + Cloudflare — global performance, free DDoS protection

If you're building a similar tool site, I hope this saves you some of the trial and error. Check out calculators.im to see what 270 calculators looks like in practice.

What questions do you have? Drop them in the comments — happy to go deeper on any of these lessons.

DEV Community: Anh Quân Nguyễn

What Base64 Actually Does to Your Bytes (and Why It's Not Encryption)

Base64 is a costume for binary, not a lock

The 3-bytes-to-4-characters math

The URL-safe variant you'll meet in JWTs

Where Base64 genuinely earns its keep

The mistakes that show up in code review

The takeaway

How UUIDs Actually Work: v4 Randomness, v7 Timestamps, and the Collision Math

A UUID is 128 bits wearing a costume

The versions you'll actually meet

The collision question everyone asks about v4

Why v4 quietly hurts your database

How v7 fixes it without giving up distribution

A practical cheat sheet

The takeaway

How `git diff` Actually Works: The Myers Algorithm in Plain English

A diff is the shortest edit script

Why the obvious approaches fail

Myers: a diff is a shortest path through an edit graph

The trick: search by number of edits, not by grid size

Where the same idea shows up

The catch: a minimal diff isn't always a readable one

The takeaway

The Math Behind O(log n): Binary Search, log , and Why Halving Wins

A logarithm counts halvings

Binary search is just "halve until found"

Where halving shows up once you see it

"But my data isn't a power of two"

The takeaway

Time Math Is Harder Than It Looks: 6 Duration Bugs and How to Avoid Them

1. Minutes are base-60, not base-100

2. Crossing midnight makes durations go negative

3. 12-hour vs 24-hour parsing

4. DST means a "day" isn't always 24 hours

5. Epoch math is your friend — until you mix units

6. Decimal hours for payroll rounding

The one mental model

JSON Schema in 10 Minutes — Validation, Types & Real Examples

The seven types you'll use

Objects, required, and the additionalProperties trap

String validation: minLength, pattern, format, enum

Number validation: minimum, maximum, multipleOf

Array validation: items, minItems, uniqueItems

Schema composition: $ref, allOf, oneOf, anyOf

A real signup schema

Tooling: Ajv (Node) and jsonschema (Python)

JSON Schema vs OpenAPI vs TypeScript

The mistakes I kept making

1. Forgetting additionalProperties: false

2. Confusing required with type

3. Using format without enabling assertion

4. oneOf where anyOf is correct

5. multipleOf with floats

6. Recompiling schemas on every request

Closing thought

I Keep Forgetting Subnet Math — Here's the Cheat Sheet I Actually Use

The three numbers that matter

The magic number trick, with a worked example

Cloud-specific gotchas you will hit

AWS VPC

Kubernetes

Docker

Subnet math in code (Python and Go)

A 30-second AWS CLI sanity check

Three mistakes I have personally shipped to production

Closing — make subnet math boring

Lessons Learned Building 270+ Online Calculators: A Developer's Deep Dive

The Project: What Is calculators.im?

Lesson 1: SEO Is 80% of Your Traffic — Treat It as a Feature

Lesson 2: HTMX Was the Right Bet — But Has Trade-offs

Lesson 3: Go Is Overkill for Small Projects — Perfect for Scale

Lesson 4: Calculator UX Is Harder Than It Looks

Lesson 5: The Content Around the Calculator Matters More Than the Calculator

Lesson 6: Redis Caching Saved Us at Scale

Lesson 7: Build the Infrastructure Once, Deploy 270 Times

What I'd Do Differently

The Stack in Summary

1. Forgetting `additionalProperties: false`

2. Confusing `required` with `type`

3. Using `format` without enabling assertion

4. `oneOf` where `anyOf` is correct

5. `multipleOf` with floats