Bosonica

112 POSTS

Exclusive articles:

Profile Before You Blame: The Slow Step Was a Regex, Not the PDF

A catalog job crawled for the better part of an hour, and the obvious suspect — heavy PDF parsing — took the blame. Profiling put ~40 of every ~41 seconds somewhere no one had looked: a one-line regex hunting for an email that wasn't there.

Windows Dev-Environment Gotchas That Eat a Day

A running field guide to the traps that bite a Windows dev box day after day - the ones that are small on their own and expensive in aggregate. Each is written as a thirty-second diagnosis.

Count-Based Backup Rotation Is a Trap on a Shared Disk

"Keep the last fourteen" is a sentence about time. A disk only understands bytes. Here is the morning that difference cost us, and the small change that fixed it for good.

The Form Link and the Response Sheet Are Two Different Files

Handing out the form link is safe — nobody who fills it can see anyone else's answers. The spreadsheet behind it is a different file with its own sharing, and that is the one quietly filling with names, numbers, and dates of birth.

Fingerprint at Import: Catching a Source Record That Changed After You Copied It

You imported the record correctly. Then someone fixed a typo in the source — and your re-run skipped right past it, because dedup saw a record that already existed and moved on.

Breaking

Many-to-One: Why a Mapping Backlog Outgrows Its Target Taxonomy

You're mapping a messy source vocabulary onto a clean target taxonomy. The target has about 5,600 slots, so the job must be roughly 5,600 decisions — right? The backlog is already past 8,900, and still climbing.

The Fix That Didn’t Take: When a Content-Hash Gate Skips Your Code Change

You shipped a fix to how one field is computed, re-ran the pipeline across everything, and it reported a clean run. Then the consistency check still flags those records as wrong. The fix is in the code, the rebuild "ran" — and the records never changed. Your own optimisation skipped them.

Your Dedup Scan Is Over-Counting — Because It Forgot What You Already Fixed

The report said 80 duplicate groups still to resolve. You'd been resolving them for days. You run it again after a big batch and it *still* says 80-ish. The backlog isn't stubborn — the scan is counting work you already finished.

When Your Skills Folder Is a Deploy Target, Not a Drawer

You hardened a skill in the repo, shipped the PR, and the agent kept loading the old one. Or you fixed the live skill by hand, and the versioned copy quietly stayed behind. Same root cause: the copy you run and the copy you version are two different files.