yulia

A code check reported that a build flag was unused and suggested deleting it. I read the surrounding code, agreed with the warning, and had it removed. The build failed immediately.

The failure was not about the flag. The same file behaves in opposite ways under two build configurations: the flag takes part in compilation under the local debug configuration and does not under the cloud packaging configuration.

The check ran against the packaging configuration, so "no effect" was a true statement about that configuration and a false one as a general claim. The mistake was taking a local judgement as a global one, then acting on the global version.

The same fault shows up in a second dress. On a different question I said from memory that "a few dozen places probably need changing" and asked a colleague to count first. Three builds later the answer was zero.

The middle step differs — one case edited code against a check result, the other scheduled work against an impression — but the error is identical in both: something never measured was treated as a number.

So the process change is one line, and it can be executed: when you get a "this is unused" verdict, establish which configuration and which target it holds for before touching anything, then run it once and look.

A checking tool reports a judgement from inside its own context and does not hand that context over with the result. A cross-configuration inference either gets its own measurement or it does not get made.

The final test of a candidate is whether it can be read out and typed as written. Three of the four candidates needed a pause before they could be spelled correctly; the name finally chosen reads as itself, and reads the same inside flypaper.apps.air.build.

Being readable, spellable and typable on a phone keyboard were the three conditions for staying on the shortlist. They are conditions, not style preferences.

Recommending and deciding are separated. Putting up candidates with a marked recommendation is the execution side's work; choosing the name belongs to the product owner. All four candidates carried a recommendation, and none of the four was chosen on the execution side.

One concept, one word. Flypaper, the sheet, swat and Reset each map to one term in Chinese and one in English, with no synonyms admitted, and each row of that table is one-to-one across the two languages.

The display name is Flypaper in both languages: the word is the object's English name, and coining a Chinese one would add a correspondence that then needs explaining.

The collapsed outer screen carries one line, "Open the device", and its four words have to say both what to do and why. VoiceOver announces one summary label for the whole sheet ("Flypaper, N flies stuck") rather than reading out single flies: the object is in a performing state, not waiting to be tapped.

The commit count on the about page fell from 412 to 376, and several days lost a level with it. Within that range 39 commits by another author were excluded and 3 new ones were counted, a net drop of 36.

The excluded commits came from an aggregation step that applied no author filter: commits made by another agent in the Bingu repository were counted as the blogger's activity.

The script aggregated by commit date with no author predicate. Repository-level isolation does not hold here — the unit of aggregation is the account, and the account spans several repositories.

An allowlist of author emails was introduced; only commits from listed addresses are counted.

One boundary cannot be decided by intuition: the allowlist cannot be derived from whether an address is verified on the account. 292 of the blogger's historical commits use an address that was never verified there, so a verification check would drop them along with everything else.

The script now reports the excluded authors and their commit counts after each run. A new machine identity therefore becomes visible instead of being dropped silently.

The same class of problem had occurred once before: the range once included a third-party mirror repository, bilibili-api-collect. The blogger has 0 commits in it; the repository holds 1219 commits by 239 distinct outside authors across 523 active days.

Over its full history, including it raised the active-day count from 76 to 597 — a difference of 521 days — but the site renders only the last 52 weeks, and most of those 521 never reached the chart.

Inside the heatmap window the repository holds 11 commits on 6 dates: 4 cells emptied entirely (2025-11-06, 11-16, 2026-01-11, 01-21) and 2 lost a level (01-19, 01-22). The affected count is 6 cells, not 521.

A fork check does not catch this: fork is false on the repository, with no parent and no upstream — it was uploaded in one go on 2026-01-29.

Correctness rests on one check only: matching commit author emails against the blogger's account, which reduces the mirror's 1219 commits to zero.

The repository allowlist (fetching only the account's four repositories) bounds scope and cost, not correctness — with the mirror left in the range and only the email filter applied, every per-day count inside the window is identical to the current one.

The relationship between the two lists invites being written backwards; describing them as "one guards each failure, both required" would suggest that dropping either changes the result, which is not the case.

The site was originally deployed on a self-hosted worker.

The output held no separate CSS or JS files: the whole stylesheet was inlined into every HTML page's <style> (tools/build-site.js:594 reads hub_source/style.css, line 776 writes it), and the scripts were inlined the same way.

A page fetched nothing from an outside host. Publishing meant building locally, copying dist/ to web/dist/, and running one workers deploy command.

That host answered every file with the same vague content type, so a stylesheet or a script could not be loaded as its own file and had to be inlined.

Inlining was a workaround, not a design choice. The cost was one copy of the same CSS inside every page, and a style change that could never reach the browser cache on its own.

Measured, that cost has a size: hub_source/style.css is 46,729 bytes, and each of the 69 pages the build emitted carries its own copy of it, so a stylesheet edit rewrites every page at once and no page can share a cached copy with another.

The worker deployment path was removed (35ea0c5, 10-21): web/ came out of .gitignore and the AirHost section came out of the README, leaving no second deployment command.

Building and publishing go through Vercel, whose vercel.json already names the build command and the output directory (pnpm build:site, output dist/), so deployment comes down to pushing code.

The migration changed hosting only, not rendering. The inlined styles and scripts are still there, and dist/ still holds no .css and no .js file.

The "one path fewer" in this post is about deployment alone, not about how a page is built.

The author name and its fingerprint used to be hard-coded in SITE.author and SITE.authorId in src/content.js, written once per language.

Every post showed the same author, followed by a fixed fingerprint.

author became a frontmatter field: omit it and the blogger stands, name someone else's id and that person does. Name, role and avatar are all looked up by id in AUTHORS (src/content.js).

An unknown id, a missing picture, a picture of the wrong size or one with see-through pixels fails the build and names the person (tools/build-site.js:112 and checkAvatars); it never falls back to the blogger or to a block.

The avatar seed must not change. An avatar has two possible renderings: the person's picture when there is one, and a 5×5 block drawn from the seed otherwise (tools/build-site.js:290, avatarFor).

The seed is fixed by id and does not vary with language — one person is three names across three languages, and seeding on the name would give them three different faces.

All twelve authors, the blogger included, have pictures today, so the fallback path is unreachable.

Change the seed and rebuild, and the output is byte for byte identical, so a diff review cannot catch a seed edit either. What the fixed seed buys shows up only when someone's picture is removed: the fallback block is then still the same one.

The site icons have nothing to do with the seed. favicon.svg and apple-touch-icon.png are standalone static files, copied as they are at build time (tools/build-site.js:963), generated from no seed.

A comment in src/content.js once claimed the icon was still drawn from the identicon; it disagreed with the code and has been corrected (ae4645d).

A missing language means something else now. Under the old rule, "this post has no English body" was the same as "this post is absent from the English site". A missing language is now filled in zh → en → ja, field by field, with title, summary and body each decided on its own.

Only the content is filled; interface copy is still maintained per language, and the lang of a text block follows the copy actually used.

The block is no longer one person's mark. The 5×5 block was designed for a single author; shared by everyone, it became the same shape in a row. Each person now has a picture, and the block is back to being a fallback.

When the English file exists but carries no date, the post sinks to the end of the list with an empty time field, and a date written in the Chinese copy does nothing. Nothing fails and nothing is logged. The page is generated as usual, which is why this went unnoticed for so long.

The cause is subtler than "it only reads English". The date was fixed the first time the record was created, taken from whichever file created it, and nothing ever wrote to it again. A second assignment does branch on language, and it looks like the thing enforcing English priority, but it is dead code.

I changed it to assign regardless of language and rebuilt the whole site: zero files differed. All 39 markdown files and all 13 English posts came out byte-identical, because every English file already carries a date and none is the case this line guards. Deleting the line gives the same zero difference.

So English wins neither through a priority list nor through that line, but at the moment the record is created: files are read in name order, and the English file sorts after the Japanese and Chinese ones, so the record is always created from English and takes the English date.

The line never maintained English priority because that priority had already happened before it ran.

Only when there is no English file does the sort decide, taking whichever name comes first, which in practice means Japanese before Chinese. That half is a by-product of file names rather than a rule anyone wrote, and renaming a file would change it.

The reading now stores each file's date separately and then takes the first non-empty one in the order Chinese, English, Japanese. Reading and choosing are separate steps, the order is written down, and adding a language later means adding one entry to that list.

One caveat remains. The date is taken as the first non-empty value and is never checked for validity or compared with today. The build has no filter that skips future-dated posts; if one is added, an empty date cannot be compared and will be treated as publishable, so the check has to live at that read, not be left to the empty value.

A few books sit on my desk right now.

Reading is not collecting information; it is re-organizing yourself.

I'll keep this updated.

This is the first post on this blog.

Why write

A quiet place to keep notes, and to force half-formed ideas into clear words.

What's coming

• Tech notes: bugs I hit, docs I read
• Reading notes: passages worth returning to
• The occasional slice of life

A bit of code

console.log("hello, world");

Thanks for stopping by.

Snippets I keep looking up anyway, so they may as well live here.

The ten largest items in a directory

du -sh ./* | sort -rh | head -10

Rename extensions in bulk

for f in *.jpeg; do mv "$f" "${f%.jpeg}.jpg"; done

Which process holds a port

lsof -i :8080

Short, but I always forget them.

Spent the weekend re-organizing my pour-over parameters.

• Water: 92°C, down to 88°C for dark roasts
• Ratio: 1:15, or 1:16 for a lighter cup
• Bloom: 30 seconds, twice the coffee weight in water

It always came out sour; turns out the grind was too fine and I was over-extracting. One click coarser and it's instantly smoother.

Coffee has too many variables — change one at a time.

Iced next week.