Forblune

Procedures

Procedures

The hardest thing to judge before hiring someone is whether they actually check their work.So here are the procedures I use, as they are.

Each one lists what it fails to catch. A procedure without stated limits is a boast, not a method.

Draw the boundary with 400 and 405

When it is used

When someone reports a broken contact form. Looking at the page cannot tell you whether the form is broken or the server never deployed.

The procedure

curl -s -o /dev/null -w "%{http_code}" \
  -X POST https://example.com/api/lead

What it settles

Post an empty body: a 400 means the server code is alive and validating; a 405 means the deploy failed and only static files are being served. One line separates two failures that look identical on screen.

What it does not catch

  • False 200s from CDN cache — recheck against the deployment URL, not the custom domain.
  • Silent failures in storage or notification. A 200 does not prove the record was written.

Decide the source of truth by hash

When it is used

When several copies of a site exist — backups, build output, an old repo — and nobody knows which one is actually live.

The procedure

curl -s "https://example.com/?$(date +%s)" | shasum -a 256
for d in ./dist ./backup ./old; do
  shasum -a 256 "$d/index.html"
done

What it settles

Compare the hash of the live response against every candidate. Once, none of eight candidates matched — which is how I learned the assumption that a local copy was canonical was simply wrong. Add a changing query value or the cache answers instead of the origin.

What it does not catch

  • A crawled copy has no server code or build config. Matching HTML does not mean matching behaviour.
  • If the response embeds a timestamp or random value, the hash changes every request.
  • Which copy should be canonical is a human decision. This only tells you same or different.

Count broken Korean words

When it is used

Before shipping any Korean page. When a word splits mid-word, readers judge that nobody proofread it before they judge anything else.

The procedure

const seg = new Intl.Segmenter('ko', { granularity: 'word' });
// 어절마다 getClientRects() 가 두 줄에 걸치면 쪼개진 것
// 화면 밖 허니팟은 제외: r.right < 0 || r.width <= 1

What it settles

Counted by script, not by eye, and it must be zero at 390, 768, 1280, and 1440px. The cause is nearly always the same: no word-break: keep-all in the CSS. With it, zero; without it, breakage — I have not seen an exception.

What it does not catch

  • Off-screen elements such as bot traps register as false positives; filter them by width and position.
  • Text held in data attributes passes a static scan. It has to be measured on the rendered page.
  • A single orphaned word on a heading's last line is a different problem, needing text-wrap: balance.

What all three taught me

When a measurement reports a failure, suspect the tool before the target. Building these, I misjudged real things: I failed a healthy layout by omitting item padding from a spacing measurement, measured a horizontal row as if it were vertical, and nearly filed a healthy server as slow because I timed it seconds after a reboot.

So the handoff includes how each number was measured, not only the number. A number you cannot re-derive is not evidence.

See pricing and scope