the claim is roughly this: in italy everything is a cms, everything made with a cms looks the same, therefore italian web design is bad. i have heard it said about small businesses, about restaurants, about dentists, about lawyers. i have heard it said with a lot of enjoyment, which should already be a warning sign.

the honest version of the complaint

some of it is completely fair. if you open thirty sites for italian plumbers and twenty of them are the same template with a different photograph, you have learned something real about the market. that is not a taste problem, that is a supply problem: there is a template, there is a person who installs it for four hundred euros, and there is nobody between the two of you.

what is actually true:

• most small-business sites are template installations, not design work
• the template is chosen by whoever is cheapest to find, not by whoever understands the reader
• the result is a page that ranks, converts a little, and is forgotten
• a large amount of it is slow, and a large amount of it breaks on a phone

none of that requires wordpress to be true. it requires the buyer to not know what they are buying and the seller to not tell them.

the version that is wrong

the wrong version says the cms is to blame. the cms is a tool. wordpress is a tool that a great many people, including a lot of very good developers, use well.

the more useful claim is: the tool is chosen by the person with the least power in the transaction. the person paying for a site is not the person operating it. the operator wants something they can update without calling anyone. that is a completely rational want, and it is the want a cms is built to satisfy.

so the cms is the symptom. the cause is that the person paying and the person using the site are different people, and nobody in the middle is responsible for how it reads.

the part i actually object to

what makes me angry is not the template. it is that these sites are then sold as design.

a small business gets told it is getting a website. what arrives is a page with a hero image, three feature boxes with icons in them, a contact form that goes nowhere, and a claim that it is "modern". the price is serious money. the same shop could have had something readable, fast, and honest for a fraction of it, and did not know to ask.

that is not a taste disagreement. it is someone being paid for the appearance of the work rather than the work, and the buyer has no way to tell the difference because they have no reference for what good looks like.

i do not think the people operating these sites are stupid. most of them are doing their best with what they were given. i think the whole chain is arranged so that nobody is in a position to notice.

what i would actually change

if i could put one thing on every small business site in italy, it would not be a font or a colour. it would be the phone number, in text, visible without scrolling, at the top.

that single change would outperform most of the design work being sold. a person on a phone in a street who wants to call you does not need a hero section. they need to see whether you exist and whether you answer.

after that:

• make it load on a phone, on a bad connection, without waiting
• write the text in the voice of the person who runs the shop
• delete every icon that is not carrying information
• let the page be a page

the part where i am the problem

i build sites for a living, in the same country, in the same market. it would be very convenient for me if the answer were "the italians are bad at this".

it is not that simple. i have been handed bad briefs. i have quoted for work that should not have been quoted for. i have shipped things i was not proud of because the scope was a template plus a logo and nobody had asked for more.

the market that produces the four-hundred-euro plumber site also produces the person who thinks a site is a thing you buy once. i am inside that market. so is everyone who ships here.

if the whole local web is bad, that includes the part of it that is mine.

what i take from it

• the tool is rarely the problem. the person choosing it is
• template installs are not design and should not be sold as design. the buyer deserves to know which one they are getting
• the fastest site on a bad connection wins, and that is a technical decision made once, not a visual one
• the phone number at the top beats every hero section i have ever been paid to design
• i am part of the market i am complaining about, which is the part that makes it awkward to post

i still think most of it is bad. i just do not think "bad" is a nationality here.

so i added telemetry. anonymous, aggregate, harmless. the mod posted a small json payload to a webhook every so often.

here is what i did not add:

• a rate limit on the receiving end
• a consent switch anyone could turn off
• authentication of any kind
• any reasoning at all about the fact that a url inside a client is a url everybody can read

what actually happened

the mod's source is public, so the endpoint was public. within days the channel was not receiving telemetry anymore, it was receiving the same line thousands of times: one real user, then a script, then a script with a loop, then two scripts with a loop.

the payload was worthless but the volume was not. and the failure mode was the embarrassing one: i could no longer tell my own users apart from the abuse, because i had built something where those two things looked identical from the receiving side.

why the data being harmless was not a defence

this is the part i keep coming back to. the payload contained nothing. a script does not care. the only property that made my endpoint dangerous was that it accepted anything from anyone, as fast as the network could deliver.

saying "it is only telemetry" is not a security argument. it is a description of what the attacker does not care about.

the fix

i did not patch the mod and hope nobody looked again. i put a filter in front of the endpoint, at the edge, in cloudflare, so that the requests are rejected before they ever reach anything i own. the edge is the only place that can say no to traffic it did not let me invite in the first place.

it is one rule, and it is the smallest and best piece of security work i have ever done.

what i took from it

• an endpoint is public the moment you ship it, no matter who you meant it for
• limits belong at the edge, not in the client that asked for them
• if you cannot tell a user from an attack, you do not have telemetry, you have a firehose
• deleting something is a valid security control, and it should have been my first option instead of my last

the mod is still out there. the telemetry is not.

the entire self-description on that account is six characters: 20x dev.

this is the post i would put first, because it is the reason any of the rest of this exists.

what 42 repositories actually looks like

i measured the profile with the github api instead of guessing, and here is the whole thing:

and the languages, which is where the profile stops being about me:

nine Java repositories. almost all of them minecraft: a client, a plugin, a bounties addon, a villager-in-a-bucket, a mirrored public release. that is a real and honest part of my history — i was a kid who liked building things for a game — but it is not a design portfolio, and it is not what i do now.

so a visitor lands on this profile and concludes one of two things: either this person stopped being interesting around 2023, or this person has never had an opinion about anything. both readings are wrong, and the page gives them no way to find out. that is not a formatting problem. it is an argument that was never made.

why a list is not a portfolio

a list answers "what exists". a portfolio has to answer "why".

42 rows of name · language · stars · description is a complete answer to the first question and a zero answer to the second. completeness is not a substitute for argument — if anything it hides the argument, because 42 rows feel like evidence and none of them is a reason.

the specific failure here is that a row cannot contain a decision. every row is the same shape, so every row says the same thing, and the only thing distinguishing them is a number that measures other people's attention. order the page by stars and you get four projects and a lot of empty space. order it by pushed_at and you get a changelog.

what i actually show: 9 of 42

this site shows nine. that is 21% of the profile, and the selection is nine lines of a build script, not a query:

const FEATURED: { name: string; tags?: string[] }[] = [
  { name: "portfolio-finder" },
  { name: "dektop-cleaner" },
  { name: "terraria_mods_extractor" },
  { name: "4webvideo" },
  { name: "sorting-visualizer", tags: ["JavaScript", "React", "Visualization"] },
  { name: "wplace-theme-changer" },
  { name: "darkwplace-extension" },
  { name: "task-manager" },
  { name: "Frenxys" },
];

that array is the portfolio. not the API response, not the database — nine names in the order i want them seen, with everything else fetched and then deliberately not shown.

the order is the first design decision and it is the one i fought hardest. the api hands me the profile sorted by updated, which is the correct answer to "what did you touch last" and a useless answer to "what should i look at". the fetch keeps my order and discards the sort:

/** keeps the curated order and warns loudly if a featured repo disappears. */
function selectFeatured(repos: GhRepo[]) {
  for (const entry of FEATURED) {
    const repo = byName.get(entry.name.toLowerCase());
    if (!repo) { missing.push(entry.name); continue; }
    picked.push(repo);
  }

a project from 2025 sits next to one from 2026 because that is the argument, not because of a timestamp. recency is not an argument.

the second decision is quieter: the featured nine have 8 stars between them, and four of them have zero. if i curated by stars the page would be empty. stars are a property of other people's attention, not of the work.

each project, and the decision it is standing in for

this is the part a list cannot do. every card on the projects grid is here because it stands for something i decided about how this site behaves:

• portfolio-finder (JavaScript, 3 stars) — a tool that finds other people's portfolios. it is here because this site does the same thing at build time: fetch once, generate a file, and let nobody query github at runtime. the fallback is a hardcoded list in constants.ts, and it exists for the same reason that tool exists.
• dektop-cleaner (JavaScript/electron, 2 stars) — it is here to make the point about pushedAt: the field is carried into the data model and never used to sort. a 2025 tool earns the same card as a 2026 one.
• terraria_mods_extractor (PowerShell, 0 stars) — a single shell script, and it gets the same card as a react app. buildTags always puts the language first, so the badge reads POWERSHELL in the same slot with the same weight. the grid does not rank by prestige, because a grid that ranks by prestige is a leaderboard.
• 4webvideo (Python, 0 stars) — it is here for a decision i didn't make: there is no language filter and no search over nine items. both would cost more in code and in visual noise than they would return.
• sorting-visualizer (JavaScript/React) — the only project with hand-written tags, because FEATURED entries accept a tags override. the automated metadata is a default, not a cage: when the machine cannot describe the work, the human writes the line.
• wplace-theme-changer and darkwplace-extension (JavaScript, 1 star each) — both are the same problem i later solved for myself: repaint a thing you do not own, at runtime, without reloading. the browser extension theme, the app theme. they are adjacent to the theming system of this site for a reason, and that reason is the only reason they are on the page.
• task-manager (JavaScript) — its github description is literally just a url: https://taskmanager-enea.web.app/. that is why the Project type has a homepage field at all. the description should point at the running thing, and when it does not, the model has somewhere else to put it.
• Frenxys (Brainfuck, 1 star) — a joke repo: a readme, and the same readme written in brainfuck. it is featured because curation is editorial and a portfolio does not have to be uniformly serious. if i removed everything unserious i would also remove everything that made the account worth looking at.

the part i deleted, which is the most honest thing here

the curated list used to have hand-written entries for four older projects. i removed them, and the comment in constants.ts says why:

the previous hand-written entries (demarkify, torr, beetrap, sniffcli and friends) were removed: those repositories only live under the old owner account and 404 under Frenxys, so keeping them would ship dead links.

i checked, and it is true. all four return 404 under Frenxys and 200 under the old account. so my curated portfolio was shipping links to nothing.

that is worse than having no portfolio, because it looks curated. a dead link in a hand-picked list is a lie with a design around it: it says "i chose this" while pointing at nothing. i would rather have nine live cards than fifteen dead ones, and i deleted four to make the number true.

what building this site actually cost

because a post like this can turn into self-congratulation, the invoice. this site is a client-rendered react app with:

• 189 urls in the sitemap — 35 routes, 7 of them chrome and 28 of them posts, where each url exists only in the locales that actually have that content — and a generator that fails the build if a post in the code has no url in the sitemap, which is the only way i found to stop orphan pages
• a build-time github fetch with a fallback, so no visitor ever queries github
• a service worker, hashed assets, runtime theme repainting, a q/ctrl+c terminal version served to curl
• 28 posts, and for months only 8 of them were actually published — a with_placeholder_copy helper was rewriting the other 20 with lorem ipsum at runtime, so finished drafts that had been sitting in the code for half a year shipped as placeholder text
• a check:dist gate that had never once failed: ok() printed FAIL and then forgot to count it, so 1,710 assertions ran to no effect

i spent all of that on the frame. nine projects are visible. that ratio is the whole point, and it is the argument for the frame: the list was never the problem, so effort spent on the list buys nothing.

why this site exists

a github profile is a claim with no argument. this site is the argument.

it exists so that every claim can be followed by the code that makes it and, where i got it wrong, the post where i say so. eight of these posts are real and every single one ends with something i got wrong — a sniffer that cannot detect what its readme claims, a honeypot whose bind failure is silent, a sitemap that orphaned 37 pages, a theme that shipped with hardcoded shadows, a bug i fixed with three edits and never diagnosed, a fallback that needed a rewrite for one bot, and a privacy audit that found three third-party origins i had no idea were there.

that is the portfolio. not the 42 repositories — the ability to show the work and then refuse to hide the seams. a link list cannot do that. it can only point at a repository and hope you will not read it.

what i would tell my past self

• completeness is not an argument. 42 is not better than 9. if you cannot say why a thing is in the list, you have not curated, you have mirrored — and the 15 forks are proof that i know what mirroring looks like.
• delete before you ship dead links. a curated list with a broken entry is worse than no curated list, because the curation is the claim and the link is the evidence.
• the list was never the problem. i kept thinking the fix was to write better descriptions. the fix was to have something to say.

then i opened the network panel and counted, because a claim like that is either true or a lie and there is no third option.

it sent three requests to three different origins on a cold load, and the source contains two more that hand a stranger my IP address.

what actually leaves the browser

this is the network log of a cold load of the homepage, complete:

there is a fourth row, and it is the only one i chose to put there:

| destination | what it is | who they learn |
| --- | --- | --- |
| `www.googletagmanager.com` | Google Analytics 4 | **that you visited a page here, and when** |

that one is real, i added it on purpose, and it does not fire unless you press a button first. `src/lib/analytics.ts` keeps the answer in `localStorage`, and `gtag.js` is injected only after `granted`. refuse, and the script is never fetched and a `no` is remembered; ask again on every visit and some people read that as pressure, so it is asked once. **before you choose, this table is three rows, not four.**

that last row is the one i need to talk about. the full request was:

/v1/forecast?latitude=44.4949&longitude=11.3426&current=temperature_2m,...

my coordinates, in plaintext, in a url, to show me the temperature. and here is where they came from — or rather, where they can come from, because on this particular load they did not need to. detectUserLocation() in HomePage.tsx tries get.geojs.io/v1/ip/geo.json and, if that fails, ipwho.is. both of those are IP geolocation services, which means both of them are handed your IP address as the price of a postcode. they did not fire here because the widget already had a location; when it does not, a visitor's IP goes to two strangers in sequence so that a dropdown can be skipped.

so the honest count is three requests on a cold load and five endpoints in the source, and four of them exist to serve a single widget. i built that without a moment of thought.

what is not there is still the more interesting part, even after the analytics. no tag manager. no error reporting. no session replay. no pixel, no beacon, no document.cookie anywhere in the source. settings live in localStorage and go nowhere. the app, the styles, the images, the two UI fonts: all from my own origin, one hostname, no third party.

that last sentence is worth defending properly, because "no third party" is not true and never was — the table above is three rows long and every one of them is somebody else's server. what is true is narrower: **the app itself never talks to anyone.** one origin serves the code, the styles and the images. the third parties are called by the browser, from the page, and the two that matter can be switched off without touching a line of the app.

and the analytics row is the honest kind of addition. i could have written this post a year from now and quietly let the sentence at the top rot, and that is the move i did not make, because a privacy post that goes stale is worse than no privacy post: it teaches people the wrong lesson about the value of checking.

the part that is genuinely good, and that nobody screenshots

the favicon costs zero requests. this site repaints its tab icon at runtime, in the current theme colour, from the sigma logo path baked into the bundle:

const href = `data:image/svg+xml;utf8,${encodeURIComponent(buildSigmaFavicon(color))}`;
document.querySelectorAll<HTMLLinkElement>('link[rel~="icon"]').forEach((link) => {
  link.href = href;
});

switch the accent and the tab icon follows, because it is a data uri, so there is nothing to fetch. there is no /favicon.ico entry in the network log at all. the static .ico, the apple-touch-icon and the manifest pngs are still there, and they have to be: they are what you get before react mounts and on the clients that cannot run javascript or cannot render svg. the last <link> wins where both are supported, so the vector one goes last.

it is a small thing, and it is the clearest example of privacy-by-construction i have in the codebase: the feature is not "we do not track you", it is "this specific request does not exist".

no sourcemaps. one line in vite.config.ts:

build: {
  sourcemap: false,
}

a sourcemap is a complete map of your source, shipped to everyone who loads the page, usually by accident because it was useful once in devtools. it is the most private setting in a bundler and the easiest to forget. dist/ has no .map file in it.

hashed filenames are not privacy

every asset on this site has a content hash in its filename: a/ and c/ for the js chunks, s/ for the css. i am deliberately not pasting one here, because it changes on every build and this paragraph would be wrong by tomorrow.

people list hashed filenames under privacy posts. it is not privacy, it is caching: the hash is there so a deploy does not invalidate a year of browser cache. the hash has nothing to do with anyone's address.

i am writing it here because conflating the two is exactly what makes "privacy website" posts worthless. a bundle with a content hash in the name is not private. a 10 MB third-party script is not private either, whether its url has a hash in it or not.

for what it is worth, "size" means three different numbers for the same entry chunk: the file on disk, what a gzip server would send, and what brotli actually puts on the wire. that last one lands at roughly a quarter of the first. i am not pasting exact byte counts here, and the reason is embarrassing: this post is inside the bundle it is describing, so every number i write changes the number, and the paragraph would be wrong by the next deploy. one entry chunk, hashed, and about a quarter of its on-disk size on the wire.

the jetbrains mono problem, which is embarrassing

everything above about self-hosting fonts is true, and then there is this, on line 1 of src/index.css:

@import url("https://fonts.googleapis.com/css2?family=JetBrains+Mono:wght@400;500&display=swap");

and the variable right below it:

--font-mono: "JetBrains Mono", ui-monospace, SFMono-Regular, monospace;

two problems, and the second one is the interesting one.

the first is that every other typeface on this site is served from my own origin — GoogleSansFlex-Variable.woff2 and MaterialSymbolsRounded.woff2, both in public/fonts/, both preloaded — and one @import puts google back in the room. a visitor's browser now tells google which page they are on and roughly where from, in exchange for a monospace font that most of them will never see rendered.

the second is that the font is behind a setting. there is a "developer font" toggle in the settings dialog that switches the whole ui to JetBrains Mono. almost nobody turns it on. and the @import does not care: a css @import at the top of a stylesheet is unconditional, so it is fetched on every cold load whether you ever open that toggle or not. the privacy-relevant code path and the user-facing code path are not the same code path, and the convenience one is the one that always runs.

the fix is one line. the stack already has ui-monospace, SFMono-Regular and monospace behind it — three fonts that cost zero requests — so deleting the import degrades nothing except the glyph shapes.

the fonts i ship and nobody loads

this is not privacy, it is honesty about my own repo:

9,098,192 bytes in dist/fonts/, 1,807,368 of which no page ever asks for. they are in public/, so they are copied into every deploy, they are fetchable by anyone who guesses the url, and they will still be there in three years because nothing warns you about a file that is never requested.

and the 20,076-byte one is embarrassing in a specific way: it is the 20 KB latin subset I wrote a whole post about. i measured it, i shipped the 1,945,520-byte variable font instead because i decided the full one was the right call, and then i never deleted the subset. the file survived the decision that overruled it. the number in my post is still correct and the file is still unused.

what "privacy as a design choice" has to mean

not a disclaimer. not a cookie banner with nothing to consent to. the test is one question:

can you state, without hedging, what leaves the browser?

if you cannot, you have a privacy policy. a policy is a document you wrote once. if you can — and the list is short, and every entry is a feature you chose on purpose — then you have a design decision. mine is four requests, and after today i can name all four and decide about each one.

that is the whole discipline. not "we respect your privacy". a list, checked against the network panel, with the coordinates in it.

what i would change, in this order

1. delete the @import. the fallback stack is already there. one line, removes two third-party origins, changes nothing anyone can see unless they enabled a setting most people never touch.

2. put the weather behind a click. this is the real failure and it is mine, not theirs: to save myself and the visitor one dropdown interaction, two companies learn where the visitor is and a third is told. the geolocation should happen after a click on the weather widget, never before, and never by default. if the widget is not clicked, nobody should be located.

3. delete the two dead fonts. 1.8 MB that no page requests, in every deploy, forever.

what i would tell my past self

• a privacy claim is a list with names in it. "sends nothing" is an adjective. "sends nothing except these four things, and i can see all four in the panel" is a fact you can be caught on, which is the point.
• an @import is not a setting. i thought i had made the monospace font optional. i had made it visible or not, which is not the same thing, and the network request was there either way. the feature and the privacy are different code paths and only one of them is behind the toggle.
• the numbers in your posts rot faster than your bundles. the 20 KB subset is still sitting in this repo, unused, being the exact size i wrote about while the 1.9 MB file ships. if you ever correct a number, check whether the file it described still exists — or delete it while you are there.

i fixed it by deleting three things at once, and i have thought about that decision more than the bug itself.

the mechanism, before the fix

this is what the page body used to be:

<AnimatePresence mode="wait" initial={false}>
  <motion.div
    key={page + (blogPostId || "")}
    initial={settings.disableAnimations ? false : { opacity: 0, y: 15, scale: 0.98 }}
    animate={{ opacity: 1, y: 0, scale: 1 }}
    exit={{ opacity: 0, y: -15, scale: 0.98 }}
    transition={/* duration, ease, spring — elided */}
  >
    {page === "home" && <HomePage ... />}
    {page === "blog" && <BlogPage ... />}
    {/* ... */}
  </motion.div>
</AnimatePresence>

read the key. it changes on every navigation, so react unmounts the old motion.div and mounts a new one, and AnimatePresence exists to keep the old one alive long enough to play its exit.

and mode="wait" is the instruction not to mount the new one yet. that is the entire semantics of the mode: the incoming child stays unmounted until the outgoing child has finished leaving. the docs say it plainly, and it is a good mode. it gives you a clean cut instead of two pages fighting for the same space.

now put the failure condition next to it. the new page — the thing the user clicked, the thing the url already says — does not appear until an animation finishes. every frame that does not run is a page that does not render.

the three things i deleted, and why i cannot tell you which one did it

git diff src/App.tsx is the whole investigation. three hunks:

1. the presence wrapper. <AnimatePresence mode="wait" initial={false}> around the page body is gone. the keyed motion.div stays, with the same key, the same initial, the same animate, the same transition — only exit is gone, because there is nothing left to exit from. react still remounts on every page change, so the enter animation still plays. the page you navigated to is now rendered by react's own reconciliation, not by an animation completing.

2. React.startTransition in the navigation handler. it was wrapping the two state setters:

React.startTransition(() => {
  setPage(newPage);
  setBlogPostId(postId);
});

and it is now:

setPage(newPage);
setBlogPostId(postId);

this one is a real suspect and not a stylistic preference. a transition update is, by design, interruptible and lower priority — react is allowed to yield it and pick it back up. the update that changes the key is the update that drives the presence swap. so wrapping it in a transition makes the swap itself interruptible, and an interrupted swap is exactly a case where the exiting child was never told to exit and the incoming child was never mounted.

3. layout on the <motion.main> wrapper. removed. a layout projection on the parent measures and animates the child's box, and it runs as a separate pass from the presence swap. i wrote the reason in the code at the time, and i still believe it: a layout projection on the wrapper fights the AnimatePresence child that is actually swapping pages, and the loser can keep the previous page mounted.

and there it is. i removed all three, in one commit, without bisecting them. i could not narrow it down, so i removed the entire configuration in which the invariant could break. that is not a diagnosis. it is a shotgun, and the honest label for it is "i did not find the bug, i removed the ability to have it".

the measurement that told me the failure mode was real

the environment i test in — the preview panel i keep open while i work — runs no animation frames at all. not slow frames. zero.

here is how i established that. the obvious version hangs:

new Promise(res => {
  let n = 0;
  const t0 = performance.now();
  const tick = () => {
    n++;
    if (performance.now() - t0 < 1000) requestAnimationFrame(tick);
    else res({ rafFramesIn1s: n });
  };
  requestAnimationFrame(tick);
});

this should resolve after one second. it never resolves, because the only thing that can end it is a frame, and no frame ever comes. the evaluation times out and tells me the page stayed responsive — which it is. it is responsive and completely motionless.

so i asked again without hanging:

requestAnimationFrame(function tick() { frames++; requestAnimationFrame(tick); });
// ... 2.5 seconds later
{ "rafFramesAfterWait": 0 }

zero frames in two and a half seconds. which means that in this environment exit={{ opacity: 0, y: -15 }} can never complete, mode="wait" can never release the incoming child, and the correct page is unconditionally unreachable. the bug was not intermittent there. it was certain.

what is not a bug

this is the part i want to be careful about, because the easy conclusion is wrong.

it is not a bug in AnimatePresence. that component is still in this codebase eleven times across six files, and every one of them works:

not one of them gates a route. and that is the actual rule i should have written down before the bug instead of after it: mode="wait" is safe exactly when the gated thing is optional, and it is a correctness hazard when the gated thing is the destination. if the thing that fails to appear is what the user asked for, you have turned an easing into a precondition.

it is not a bug in the animation either. deleting the animation would have "fixed" it — set disableAnimations and the exit finishes instantly — and that would have been the wrong fix twice over: the animation was never the defect, and the site would have lost its transition to paper over a state-management problem. the transition is not what i was selling. it is decoration. it should not have been able to veto a route.

so what was the bug? an invariant, written in the wrong language. the property i needed is "the page you navigated to is the page you get". i had expressed it as "the page you navigated to appears after the previous one finishes animating". the first is a statement about correctness that react's reconciler guarantees. the second is a statement about timing that depends on a browser running frames. i had made a correctness property conditional on an animation, and then spent a day looking for a bug in the animation library.

how i know the fix works

in that same zero-frame environment, because a fix that only works where frames run is not a fix:

• home → blog: url /blog, #primary-content.children.length === 1, blog page rendered
• blog → home: url /, children.length === 1, home page rendered

one child, every time. that number is the whole test — it is the direct observable of the thing that was broken, and it is what i was checking by hand before. kids: 1, url and content in agreement, with no frames running at all.

what i would tell my past self

• name the invariant, not the library. "the url changed and the page did not" is a bug report. "AnimatePresence is broken" is a mood. the first one points at a line of code; the second one points at your favourite dependency.
• a fix that changes three unrelated things is not a diagnosis. i removed the wrapper, the transition wrapper and the layout projection together and called it fixed. if i had removed one and measured, i would know which one it was — and i would have kept the other two, and this post would be about a bug instead of about a habit.
• if the only place you can reproduce it is the place you also do your work, you have a measurement problem before you have a bug. i spent this one in a preview panel that renders no frames. that is both why it reproduced and why i could never see it in a normal browser, and it means i cannot honestly claim real visitors hit it. what i can say is that the failing condition is one a real browser hits whenever a tab is backgrounded, a frame is dropped mid-transition, or the user navigates faster than the animation — and a bug whose only trigger is a condition you cannot see in your own dev loop is a bug that ships.

so what does bing see?

a crawler that does not execute javascript looks at that document and finds a perfectly good <head> and an empty <div id="root">. 10,377 bytes of metadata and zero words of content.

the fix was to stop shipping an empty div.

the fallback

33 lines of plain html inside #root, which react throws away on mount:

one h1, a short paragraph that says who i am and what i do, a "services" list, a "contact" list, and four links into the site. 1,416 bytes of marketing copy that i maintain by hand, forever, for a reader that will never look at it.

plus 6 css rules — 13 lines, 543 bytes — so it arrives looking like a small page instead of a broken one. that part is not decoration. a fallback rendered as unstyled black-on-white text reads to a human reviewer as this site is broken, and the same 543 bytes are the difference between this site has minimal content and this site is broken.

why it is not a duplicate of the page

because createRoot clears its container. this is all the mount code does:

createRoot(document.getElementById('root')!).render(
  <StrictMode>
    <ThemeProvider>
      <App />

react does not merge into #root, it wipes the children and puts its own. so the visitor never sees the fallback for more than a few milliseconds, and the crawler never sees react. there is no hydration mismatch to worry about and no "is the app ready yet" state to design around.

the compromise, stated plainly — and then fixed

i originally did not prerender. astro, or next with static export, or vite-ssg would have given every one of the urls its own html with its own body text. i did not take it, because it turns a marketing page into a second build pipeline with its own cache and its own deploy failure mode.

then i measured what the floor actually cost, and the answer was worse than i had assumed: 374 urls, and every one of them was the same document. the canonical on all 374 said the site root, which is a way of telling a crawler that the other 373 are duplicates of the home page. one document, 374 addresses.

so i wrote a prerenderer instead. it emits one html file per (route, locale) pair into the build output, generated from the same data the app reads, so the two cannot disagree. pnpm run build now writes 189 documents — 7 page routes × 7 locales, and one document per post per locale that post has been translated into. a language contributes a url the moment that one post is written, and the hreflang cluster for a post is computed from its own id, so the document and its alternates can never disagree about which languages exist.

here is the honest accounting, per url, now:

the interesting part was not writing the generator. it was discovering that the hreflang cluster had to be per kind of route. a post exists in three languages and a page in seven, so a single hardcoded list of eleven was advertising six languages that served the english original under a foreign-language tag — which google counts as duplicate content, not as localization.

both lists are now derived from the module files on disk. dropping posts/fr.ts in makes french appear, and nothing else has to change.

the floor is gone for the posts. it is still a floor for three pages, and i would rather say so than pretend otherwise.

the layer above the fallback, and the two bugs in it

the head is not the only thing that is route-specific. /blog/* has a cloudflare pages function that rewrites the metadata for known bots:

const BOT_AGENTS = [
  "Twitterbot", "facebookexternalhit", "LinkedInBot", "Slackbot",
  "TelegramBot", "WhatsApp", "Discordbot", "discordbot",
  "ia_archiver", "Googlebot", "bingbot", "Applebot",
];

twelve user agents. for those, [id].js looks the post up in a generated og-data.js, then rewrites <title>, og:title, og:description, og:url, og:type, the twitter tags and the meta description through HTMLRewriter. bingbot is in the list, and bingbot is the one that does not run javascript. so for a blog post, bing gets the real title of the real post.

and then it gets the homepage's 101 words underneath it.

bug 1: DuckDuckDuckBot is not in that list. twelve entries, and the crawler I named in the comment directly above the fallback block — the whole reason the fallback exists — is the one that falls through to the defaults. every post on the site is titled Enea | Blog as far as duckduckgo is concerned. one string. that is the entire fix and i have not applied it.

bug 2: canonical is never rewritten. the map in MetaRewriter includes og:url but there is no handler for link[rel=canonical]. so the same document tells social platforms "this url is /blog/my-post" and tells search engines "this url is https://eneawork.it/". og:url and rel=canonical are not allowed to disagree, and mine do, on all 42 posts. the fix is one more entry in the map and one more .on("link[rel=canonical]") handler.

smaller: the function rewrites twitter:card to summary_large_image while og:image stays the 460×460 profile photo, because every post shares one image. a large card with a square avatar in it.

what i will not pretend about this

the fallback is marketing copy sitting in a code path. the moment the live site changes and i forget to change it, the crawler is being served a stale description of a different site, and nothing will fail. no test breaks, no type error, no build error. it is the kind of debt that only shows up in traffic you cannot attribute.

i have already left one small fossil in it: the line reads Fotografia: <a href="/lens">lens</a> — an italian word in an otherwise english document, in the one piece of html on this site that is supposed to be the permanent version of me. it is not a bug. it is what hand-maintained copy looks like after a year.

what i would tell my past self

• the head is where the seo lives, and csr does not touch it. every piece of metadata that matters is static, in the document, before any javascript runs. if you write the head by hand you have already done 80% of the seo work of a static site, and the remaining 20% is the thing people mean when they say "you should prerender".
• a fallback has to be the shortest thing that is still true. 1,416 bytes is a paragraph. 1,416 bytes of per-route content is 539 documents. the first one is a weekend; the second one is a platform.
• when you write a comment naming a threat, check that you actually handled it. i wrote "bing, duckduckgo and ai crawlers that do not run javascript" three lines above a fallback, and then shipped an allowlist of twelve bots with the second name missing. the comment was more thorough than the code. it usually is.

that is the entire product. there is no more to it than that.

what it actually is

three go files, 200 lines, 4,720 bytes of source:

go.mod has two direct dependencies and both of them are the tui: bubbletea 0.27.0 and lipgloss 0.12.1. the other 18 are indirect, and every single one of them arrives because of the terminal.

the part i did not expect: the whole network side has zero third-party code. capture.go imports bufio, fmt, io, net, strings, time — all standard library, all of it. the "protocol implementation" is a map from a string to a string:

var _banners = map[string]string{
	"SSH":  "SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.6\r\n",
	"FTP":  "220 (vsFTPd 3.0.5)\r\n",
	"HTTP": "",
}

that is the entire protocol knowledge in the project, and it is 1,119 bytes long.

why go, specifically

• no root, by default. the ports are 2222, 2121 and 8080, all above 1023, so the first run needs no privileges. a python honeypot would give me the same thing. this is not a reason to like go.
• one goroutine per connection, in one line. go _handle(conn, service, ch) inside the accept loop. the same shape in java is a thread pool, a bounded queue and a rejection policy. here it is a keyword, and the failure mode is a slowloris sitting on a goroutine for eight seconds.
• one static file. go build -o beetrap ./cmd/beetrap produces a single executable with no interpreter, no venv, no node_modules. a honeypot is something you leave running on a machine nobody maintains, so the fewer moving parts the better.
• the tui libraries. bubbletea gives you the update-loop architecture for a terminal, lipgloss does the styling. for a read-only log that never scrolls back, the framework costs about 120 lines and saves me from hand-rolling ansi escapes and parsing terminal width.
• net was already in the box. the honest reason: i had never written a listener before, and net.Listen + Accept made it look like four lines. i did not choose go for concurrency. the concurrency came along for free and i never had to earn it.

how i structured it, and why the structure is wrong

there is no router. there are three goroutines, hardcoded, started from the tui's Init():

func (m VxModel) Init() tea.Cmd {
	go capture.VxStartListener("SSH", 2222, m.ch)
	go capture.VxStartListener("FTP", 2121, m.ch)
	go capture.VxStartListener("HTTP", 8080, m.ch)
	return _wait(m.ch)
}

that is the routing table: three tuples, in a function that has nothing to do with networking.

the layering is inverted and i would rather name it than quietly refactor it. internal/capture is the package that actually opens sockets, and it has no idea which ports it serves or why. internal/ui — the package whose entire job is drawing coloured text in a terminal — owns the deployment topology. if i add telnet, i edit the drawing code.

the right shape is a config struct built in main, one loop over a slice of services, and a package boundary that knows nothing about ports. i would also make the service name a type instead of a bare string, because right now "SSH" is a lookup key in two maps living in two packages and nothing checks that the two maps agree.

connections reach the screen through one buffered channel of size 32, created in main:

ch := make(chan capture.VxConnection, 32)
p := tea.NewProgram(ui.VxNewModel(ch), tea.WithAltScreen())

the ui never calls the network. it waits on the channel, receives one message, appends it, re-arms the wait. that is the same message loop as the frontend of this site, for the same reason: the thing that draws must not be the thing that blocks. the accept loop only ever writes to a channel and never touches the view.

what the protocols taught me, and i did not expect any of it

the thing i got wrong in my head before writing it: i assumed a honeypot has to speak the protocol. it does not. three services, three completely different rules about who talks first:

ssh sends its identification string first. it is the rare protocol where the server speaks unprompted and the client answers with its own. so the line we read back is not a credential, it is a fingerprint: SSH-2.0-OpenSSH_9.6 tells you the client is a real openssh, which version, on which distribution. that is the whole payload of a scanner handshake, and you get it from a single line.

ftp's first line is the username. the server's 220 is the greeting, and the very next thing a client says is USER root, or USER admin, or USER anonymous. one line into the protocol and you have the credential list a bot is walking down, before it has sent anything secret.

http is the inverse, and the empty string in the map is not a bug. an http server that writes anything before reading the request is broken. the map has "HTTP": "" and the handler guards with if b := _banners[service]; b != "" — that guard is the entire reason http behaves, and it is one line that happens to be load-bearing for two protocols and correct for the third.

the general lesson: a honeypot's first read is the highest-value byte it will ever see. identification, not authentication. you learn who is out there from the handshake, and you never have to implement the part where they log in.

what it does not do

• it never sees a password. no key exchange, no none auth method, no pam, no /etc/shadow. the socket is greeted, one line is read, defer conn.Close() fires. a real ssh client waits out the 8-second deadline and gives up. that is the correct design, not a missing feature: a honeypot that accepts logins is a liability with a login form on it.
• it captures one line, 512 bytes, inside 8 seconds. io.LimitReader(conn, 512) then ReadString('\n'). a client that sends a binary blob with no newline gets whatever ReadString returns, which is garbage. fine, as long as i know it.
• one goroutine per connection, unbounded. nothing caps concurrency. a socket that connects and sends nothing holds a goroutine for the full eight seconds. a thousand of those is a thousand goroutines. survivable on a personal machine, rude on a small vps.
• nothing is written to disk. the log lives in a slice in ram, trimmed to height - 10 rows only when it is drawn. press q and it is gone. a honeypot that forgets is a screensaver with a network interface.
• the ports cannot be changed without editing go source. there are no flags, no env vars, no config file.

the two bugs i would fix before trusting it

1. a failed bind is completely silent. VxStartListener starts like this:

ln, err := net.Listen("tcp", fmt.Sprintf(":%d", port))
if err != nil {
	return
}

the error is thrown away. not printed, not counted, not rendered. if 2222 is already taken, that goroutine dies during startup and the SSH counter sits at zero forever — next to a live FTP counter, in the same header, looking exactly like a quiet day.

this is the worst failure mode a security tool can have: it is indistinguishable from success. the fix is three lines. send the error down the same channel, paint it red in the header, exit non-zero.

2. the readme tells you to do something the code cannot do. it says:

go build -o beetrap ./cmd/beetrap
sudo setcap cap_net_bind_service=ep ./beetrap

"to bind standard ports (22, 21, 80) without root". you will not bind port 22. the ports are integer literals inside ui.Init(). the capability gets granted to a binary that never asks for a privileged port. the fix is a flag, not a capability:

sshPort := flag.Int("ssh", 2222, "port to fake ssh on")

the intent in that readme section is not wrong, the code is just not connected to it. and the reason is visible in the history: four of the five commits in the repository are titled "Add files via upload". the files were written somewhere else and pasted in, and the readme arrived with them, describing a version of this program that does not exist.

smaller, but real: the accept loop does if err != nil { continue }. when a listener actually goes down, Accept returns that same error immediately and forever, and the goroutine spins at 100% cpu. it should break.

what i would tell my past self

the whole thing is one lesson wearing a network costume: you do not have to implement a protocol to learn from it. you send the right first line, you read the answer, you hang up. the entire intelligence of a honeypot lives in that first read, and everything after it — key exchange, authentication, a fake shell — is cost, liability and code i should be delighted not to have written.

and the second lesson is the boring one, which applies to every tool i have ever shipped: swallow an error and you have shipped something that lies to you by omission. the bind failure is a single return. it is the entire distance between a security tool and a screensaver.

the plan was simple: write the thing myself, read the packets, learn the protocols.

the plan worked. but not in the direction i expected.

the honest part first

the readme says the tool does "ssh brute-force detection". it does not. here is the entire feature:

if dstPort == 22 {
sshCounters[info.Source]++
if sshCounters[info.Source] > 3 {
info.IsAlert = true
info.Info = "POTENTIAL SSH BRUTE FORCE"
}
}

that is the whole thing. it counts packets to port 22, per source address, and shouts after the fourth one.

this cannot detect a brute-force attack. it cannot see a password, because ssh encrypts the entire session. the authentication exchange happens inside an encrypted tcp stream, and a passive sniffer sitting on the wire has no way in. even if i turned on tcpdump -A i would see binary ciphertext.

so what it actually detects is "something on my network talked to port 22 more than three times". that is not brute-force detection. that is a connection counter with a scary message attached.

why i still kept the feature

because it is not useless, it is just badly named. more than three connections to port 22 in a short window is a real signal — i have triggered it myself with ssh retries after a typo. and the same mechanism catches a scanner that is walking the network.

what i should have done is label it for what it is. "repeated ssh connections" is honest. "brute-force detection" promises something the code cannot deliver, and i wrote that promise.

the general lesson, which took me an embarrassingly long time to learn: a feature named after a threat implies a capability you may not have built. if your tool claims to detect attacks, the test is whether it can see the thing attackers actually send. mine cannot see any of it.

what i learned about the protocols

more than I expected, and none of it from documentation.

the layering is the part that finally clicked. a single frame is not one thing, it is a stack, and gopacket will hand you each layer separately:

if arpLayer := packet.Layer(layers.LayerTypeARP); arpLayer != nil {
// ...
} else if ipLayer := packet.Layer(layers.LayerTypeIPv4); ipLayer != nil {
// ...
} else if tcpLayer := packet.Layer(layers.LayerTypeTCP); tcpLayer != nil {
// ...
}

tcp is not "the packet". it is a layer that can exist without ip (some encapsulations), which is why the real code checks tcp and udp in their own branch after the address layers, instead of assuming a fixed order.

"who has" is what an arp broadcast is: a machine asking the whole network "who has this ip, tell me your mac". it is the first thing you see if you start sniffing on a wired network, and it floods constantly because arp has no memory.

multicast and discovery traffic is most of the noise. 224.0.0.0/24 for ipv4, ff02:: for ipv6, plus mdns on 5353, ssdp on 1900, dhcp on 67/68. my first twenty minutes of sniffing were almost entirely this. the -c flag exists purely to hide it.

a connection is bidirectional and a packet is not. the tool reads tcp.SrcPort and tcp.DstPort on every single frame, so the same conversation appears twice with the ports swapped. there is no built-in reassembly, and i do not write one. that is a real limitation and i would rather name it than pretend.

the part i got wrong twice

isLocalIP decides whether a packet is "unusual outbound". it treats loopback, link-local, multicast and the three private ranges as local.

the bug: anything inside 192.168.0.0/16 counts as local, including other machines on my own network. so a device quietly exfiltrating to the nas next to it produces zero alerts. my rule says "not leaving the house", which is not the same as "not leaving my machine".

the honest fix is to compare against the actual interface address, not against a range of possible networks. i have not fixed it. it is written down here instead, which is the only reason this paragraph exists.

the part i am happiest about

a concurrent ui that does not stutter.

the sniffer runs in its own goroutine and pushes packets into the tea program:

p := tea.NewProgram(m, tea.WithAltScreen())
go startSniffing(iface, watchlist, p)
if _, err := p.Run(); err != nil {
// ...
}

the loop never touches the ui directly, it only sends messages. that is the whole reason the interface stays responsive during a traffic spike — a rule i already knew from the frontend side of my own site, and only appreciated properly once the ui was a terminal instead of the dom.

it is also why HighPerformanceRendering is explicitly set to false: this is a read-only log that the user scrolls, so letting bubbletea skip frames is cheaper than keeping them smooth.

and the small thing that made it pleasant to use: a device alias map, so 192.168.1.185 renders as "main rig" and a watched mac shows up in orange. security tools have a reputation for being unpleasant, and half of making one pleasant is letting the user see their own house in human words.

what i would tell my past self

open the file you wrote and count the lines that actually do what the name claims.

if the answer is three lines and they count something adjacent to the threat, you have written a connection counter. rename it before someone trusts it — including you, six months later, when you wonder why the alerts feel wrong.

short answer: about 70% of it survived, and the 30% that died is the part i am most glad i dropped.

what went in

the token layer, which is the real thing. --primary-container, --on-primary-container, --surface-variant, --outline-variant — those are the m3 names, not my own names, and every component consumes them rather than hardcoding a colour. this is the part that paid off the most, and not for aesthetic reasons.

it paid off because i switched the whole site from light to dark and back, and changed the accent, six times, while writing it. nothing broke. there is no if (dark) in my components. every colour in the stylesheet resolves through a variable, and the dark palette is a second set of values for the same names.

all six palette schemes: tonal-spot, fidelity, content, neutral, expressive and fruit-salad. they are in the settings dialog and they all work, because they are what m3 calls them and not six hand-tuned themes.

the shape scale. m3 has a defined corner radius ladder and cards sit at the top of it. my cards are rounded-[2.4rem], buttons go fully rounded, nav pills are fully rounded. this is the single most recognisable m3 tell and it survives translation to a personal site without any trouble.

the ripple, at the correct opacity:

opacity: var(--ripple-hover-opacity, 0.08);

0.08 is the m3 state layer value. it feels almost too subtle, and that is correct — the point of the state layer is that you should not consciously notice it.

ripple scope. this was the part i did not know i needed. the ripple only follows the pointer inside the element you actually pressed, not the whole page. it makes fast clicks feel precise instead of sloppy.

the components that made sense as small web versions: switch, slider, text field, and two scrollbars, one for the window and one for panels. those are pure wins.

what i threw out

elevation. m3 defines six levels, 0 through 5, with a specific shadow for each. i use none of them. there is not one elevation token in my stylesheet, and the only shadows in it are hover states on cards and buttons — nothing that describes how high a surface sits.

this was not laziness, it was a decision. m3's elevation model assumes opaque surfaces stacked on each other. this site has a translucent sidebar with a backdrop blur, and content scrolling underneath it. elevation is a depth metaphor for opaque planes; when the plane is see-through, the shadow lies about what is on top of what. so borders do the separating here, not shadows.

the m3 elevation values are good and i copied the spirit — borders at --outline-variant, radius at the top of the scale — without copying the tokens.

the typography scale. m3 has five roles: display, headline, title, body, label, each with three sizes. i use roughly two of them, because a display role sized for a phone gets you about 57px, which is not a headline on a wide screen. the scale does not survive the jump from a 6-inch viewport to a 2560px one without being rescaled, and once you have rescaled it you are no longer using m3's scale, you are using yours that resembles it.

i kept the idea — a single expressive display face for the big moments, a monospace for the developer surfaces, plain sans for body — and threw away the specific ramp.

the one that never worked

motion.

m3 specifies durations and easing curves, and they are tuned for a phone: short, because a thumb is close to the screen. on a desktop pointer-driven site those same curves feel sluggish in a way that is hard to put into words. my eye is not where my thumb would be.

the bigger problem is that motion-heavy specs assume a reliable frame budget. they do not assume the frame budget might be zero.

i hit this hard. my sidebar collapse animation silently stopped working: the box stayed at full width, forever, with no error anywhere. the cause was not the animation logic but a layout projection fighting a width transition on the same element — two things both trying to own the box, and the loser never reached its final value. and the only reason i found it was measuring the computed width instead of trusting that the code "looked right".

i moved the width from a motion value into a plain css transition, and deleted the layout projection. the box now reaches its target within 60ms, measured, every time.

the lesson was not about framer motion. it was that a design system tells you what a finished state looks like and says nothing about how you get there when the frame budget collapses. for a phone app that assumption holds. for a web page running in a browser tab someone might have backgrounded, it does not.

what i would keep if i started again

the token layer, without hesitation. it is the part of m3 that is genuinely reusable outside android, and the reason is boring: it is a naming scheme that forces you to answer "what is this colour's role" instead of "what colour is it". that question is worth asking even if you never open the material docs.

the palette schemes and the shape scale, because they are free once the tokens exist.

the state layer opacity, because it is one number and it is right.

and the elevation, the type ramp and the motion curves, gone, with no regret — they are all assumptions about a context this site is not in.

the honest summary: m3 is a very good answer to "how does a native android app look and feel", and a decent starting point for a web design system, provided you are willing to treat it as a vocabulary rather than a specification. the tokens transfer. the pixel values do not.

in the same folder there was a second file, GoogleSansFlex-Latin.woff2, weighing 20,076 bytes. same typeface. same designer. 1% of the size.

that is not a rounding error. that file was 0.99% of the size of the one being downloaded, so 99% of the weight of my text font was sitting there unused.

the easy part

swapping the filename in the @font-face rule is a ten-second edit. the page still works, the text still renders, and if you never look at it again you have saved 1.9 mb of bandwidth for every visitor, forever, on every page.

this is the part where a reasonable person stops and ships it.

so i measured it first

before touching anything i wrote a tiny glyph probe and ran it in a real browser, because the size difference is obvious but the useful question is whether the small file actually covers the characters the site uses. you can do it with no libraries at all:

const load = (url) => new Promise((resolve) => {
  const f = new FontFace("Probe", `url(${url})`, { weight: "100 1000" });
  f.load().then(() => resolve("ok")).catch((e) => resolve("fail " + e.message));
  document.fonts.add(f);
});

await load("/fonts/GoogleSansFlex-Latin.woff2");
await document.fonts.ready;

const c = document.createElement("canvas").getContext("2d");
const width = (family, ch) => {
  c.font = `50px "${family}"`;
  return c.measureText(ch).width;
};
// a character the font does not have falls back, so it measures as the
// notdef box: compare against U+FFFF, which nothing maps to
const base = width("Probe", "\uFFFF");
const missing = [...text].filter((ch) => width("Probe", ch) === base);

the trick is the U+FFFF baseline. the notdef glyph has a real width, and any character the font lacks resolves to it, so an exact match against that width is your missing-glyph test.

i ran it over the whole range i care about — upper and lower case, digits, punctuation, and every accented letter this site needs to look correct in italian: àèéìòùÀÈÉÌÒÙäöüßñç, plus €£¥©®™°·….

result: zero missing glyphs. the 20 kb subset covered everything, including characters well outside the declared range.

then i checked the real thing rather than trusting the probe:

c.font = '50px "Google Sans Flex Local", monospace';
// 264.7 px — not the 300 px the fallback produces, so the real font is live

const rendered = width('"Google Sans Flex Local", monospace', "Handgloves");
const fallback = width("monospace", "Handgloves");

the two differ, so the subset was genuinely active and not silently falling back. by every measurement available to me, the swap was correct.

and then i reverted it

because the numbers were not the whole problem. two things the measurement could not see:

• the shapes are not identical. both files are cut from the same family, but the subset's outlines are not the variable font's outlines at the default axis settings. my page's headings are the largest text on the site, and they were visibly smaller and lighter than what i had designed against.
• the variable axes were gone. the file i shipped is a variable font, and the site sets wght and wdth through font-variation-settings. a subset cut for latin does not necessarily carry those axes. losing wght means every font-black in the stylesheet silently falls back to whatever the static weight happens to be.

a font-size regression on the hero heading is not something a byte counter is going to tell you about. i saw it, i did not like it, and i put the 1.9 mb file back.

what i actually kept

the number that made the difference is not the size. it is the preload:

<link rel="preload" href="/fonts/GoogleSansFlex-Variable.woff2"
      as="font" type="font/woff2" crossorigin />

the site is text-first, so that font is on the critical path. preloading it starts the download during html parsing instead of waiting for the css to arrive and be parsed, which removes a full round trip from the first paint.

crossorigin is the part people forget. fonts are always fetched in cors mode, even same-origin, so a preload without that attribute is discarded by the browser and the file gets fetched a second time anyway. you get the worst of both: the preload cost and no benefit.

the honest conclusion

1.9 mb is too much for a text font and i know how to make it 20 kb. the correct fix is not to hand-pick a latin subset — it is to build the subset myself with pyftsubset, keeping the axis ranges the stylesheet actually uses, and to check the rendered result against the original before shipping.

until that exists, the 2 mb file stays and the site is honest about it.

the useful part of this exercise was not the swap. it was noticing that the two files had been sitting in the same folder the whole time, and that i had no idea which one the browser was actually downloading. now i check transferSize on a reload, which reads 0 for every asset the browser already holds. that number is the only honest performance report i have ever used.

you open one tab for a definition of god knows what, and two hours later it is 2 am and you can explain, with total confidence, why c lets you shoot yourself in the foot.

the modern internet does not really give you education. what it gives you is random hyper-specific facts with absolutely no context attached. and somehow that sticks.

what my brain ended up with

• flags and geography: i can tell romania and chad apart at a glance. yes i know the difference. chad is slightly darker, or it is indonesia or monaco, and monaco is slightly shorter. do not ask me why any of this is useful.
• linux and command lines: a handful of bash commands that probably fix a bug exactly three people have ever had, one of whom is me. i learned nothing from it.
• security history: proxy conflicts, write-ups, threat actors. i could not tell you my own schedule tomorrow, but ask me about a 2014 cve and i will spit it out.

is it useless?

yes, and no, and mostly yes.

the honest answer is that none of this was planned. it was not for school, nobody was paying me for it. but i can talk about the most random topic for an unreasonable amount of time, and as an italian kid with too much internet that apparently counts for something.

then i stumbled across an artist and realised i had been listening to the same five things on repeat for years, not because i loved them, but because they were easy.

what changed was not the genre. it was the detail.

i started listening to how the low end sits in the mix instead of just how loud it is. i noticed when a hi-hat is pushed slightly off the grid. i started hearing arrangement, not just sound. once you hear that, you cannot unhear it, and every single thing i had made before suddenly had a problem i had never noticed.

the practical part, since i make music:

• stop mixing by genre, mix by reference
• pick one track and ask "what does this do that mine does not"
• the boring answer is usually arrangement or the low end, never the vocal
• write the idea down immediately, before the coffee wears off

i am not saying i made anything good because of this. i am saying i made anything finished because of this, which matters more.

the honest result: nothing was missing. nothing felt broken. i just read the whole thing faster.

this is not a new observation. designers have known it for years. what is new to me is having built both sides of it. the motion is genuinely nice. it is also, for a lot of people, a tax they pay on every visit to enjoy a feature they did not ask for.

so now there is a global toggle in the settings, and it defaults to respecting prefers-reduced-motion, which is what WCAG 2.3.3 asks for. the springs are still there for the people who want them.

the design lesson i am taking from this is small and annoying: as a ux designer, the motion is not the feature. the task is the feature. motion is seasoning, and a restaurant that puts seasoning on everything tastes like nothing.

i did not move this site. it has been on firebase hosting the entire time, and the reason nobody caught the mistake is that the files claiming otherwise were sitting right there in the repo: a wrangler.toml, a public/_headers, and a functions/ directory full of cloudflare pages functions. all three described a hosting setup that was never the one answering traffic.

how i found out

i went to look at my own response headers instead of trusting the repo. vary: x-fh-requested-host — fh is firebase hosting. then i diffed the html the domain was actually serving against the site i believed was live, and they were byte identical, both of them an april build that predated most of this site.

the project also holds four hosting sites. the project default and the one behind the real domain were returning the exact same 2713 bytes of html. a plain firebase deploy without an explicit target would have overwritten the wrong one, silently, with no error and no warning.

what is actually running

• static hosting for the whole app, with a rewrite mapping every client route to one html document
• cache headers written down in a file i can read, instead of a rules engine that merges them with commas
• one command to deploy, from a config that fits on a screen

what i gave up, honestly

the functions/ directory was cloudflare pages functions. firebase hosting is static, so they do not run. which means:

• /ping, /json, /help and the terminal view answer with the page html instead of text
• the guestbook endpoint returns nothing useful
• the per-post og: rewriting for bots never executes

i can port those to cloud functions when i actually need them. i have not, and i would rather write that here than let a 200 with the wrong body keep looking like it works.

the actual lesson

not that firebase is better than cloudflare. it is not, and i am not claiming it is. the lesson is that a config file in your repo is a claim about your infrastructure, and nothing verifies it. i knew where this site lived only because i read the headers instead of reading the repository.

a comment is not a deployment.

that is not automatically bad. the alternative for most people is worse. but it is worth being clear about what you are actually renting.

• you do not have the data, you have a view of it
• you do not have the server, you have an agreement about the server
• the interface is designed to make the distinction invisible

what changed my mind on this was shipping a guestbook. i wrote thirty lines of code and suddenly had to answer real questions: where does this row actually live, what happens if the project is deleted tomorrow, who can read it, and what do i tell people who ask me to delete something.

what i actually did

• moved the database to something i could reason about
• kept the data model simple enough that i could export it in one command
• made the export path a real feature, not an escape hatch nobody tested
• stopped pretending the abstraction was free

sovereignty is not paranoia. it is just knowing where your files are.

this time i went from a heavily customised setup to something boring. no compositor tricks, no three competing bars, no wallpaper script that takes four seconds to start. just ubuntu, gnome, and one tool.

and then, of course, i broke it within a week.

what broke, in order: a keybinding i forgot i had changed, a screensaver that decided gnome was a kiosk, and an autostart entry that had been quietly fighting another one for months and finally won.

what i took from it

• write down what you changed before you change it, not after
• the thing you removed was probably doing something you had forgotten about
• a clean desktop you are scared to touch is not clean, it is abandoned
• most customisation is a solution to a problem you stopped having

i am not going back to the chaotic version. but i am keeping a written list of the setup, which would have saved me the entire weekend i just lost.

google's material 3 expressive is the current reference. the research behind it claims a significant lift in how "expressive" a product feels, which is exactly the kind of thing i would have dismissed a year ago and would now defend unpleasantly.

what changed

• a real token layer for colour, shape and motion instead of hardcoded values everywhere
• every interactive element rebuilt on one component, so the focus ring and the press animation cannot drift apart
• typography with an actual scale instead of "big, bigger, biggest"
• light and dark built from the same source, not written twice

what i got wrong

i treated the expressive style as a look to apply. it is not. the motion is supposed to carry meaning, and the first version had springs everywhere and a flat hierarchy underneath. it looked expensive and communicated nothing.

second mistake: i designed desktop first. mobile is where the effort should start, and i still do not believe this instinctively.

the problems are not new, they just got better funded:

• answer containers that answer a different question than the one you typed
• ai summaries that are confident and wrong, which is the worst possible combination
• a wall of sponsored results before the actual results
• ten pages of the same article, scraped and rehosted

so i built search into this site. it is a small text index over my own posts, projects and pages. it is worse than a real search engine and better in one specific way: it only ever returns things i wrote.

i am not claiming to have solved search. i am claiming that the useful part of search is a good index and honest results, and that a surprising amount of the rest is someone trying to sell you something.

the whole thing is a few hundred lines. the hard part was not the matching, it was deciding what deserved to be in the index at all.

the pipeline went like this: dots, then a bar, then a bar with modules, then modules with rounded corners, then rounded corners with per-module transparency, then a script that generated the gradient of the modules, then a second script that generated the script.

somewhere in there i lost an entire weekend to a compositor bug that turned out to be a rounding difference between two versions of something.

what actually fixed it

i wrote down the one rule that mattered and deleted everything else:

• the bar exists to show information, not to show taste
• a module that does not change every few seconds does not need animation
• the screenshot i was chasing was made by someone who has more free time than me

this site has a theme system. it has presets, an accent colour, and a palette picker. and it does not have a single script that generates another script.

the theming on my desktop is now boring. that is not a loss. it means i stopped using my own desktop as a project.

so i wrote one button for it.

the honest scope

it is a small gui around a package manager. it shows the available updates, lets you pick, shows a log, and tells you when it wants a reboot. that is it.

what i actually learned

• the hard part is never the button. it is the failure states: no network, a held package, a mirror that is down, a lock file left behind by a crash
• never run the update from a gui without a log. if the user is going to press one button, that button owes them a way to read what happened
• "partially upgraded systems" is a real state and your ui has to have a screen for it
• the gui is not the product. the transaction is the product, the gui is the convenience

the part i am proudest of

it refuses to run as root silently. if the update needs privileges, it tells you exactly what it needs and why, instead of asking for everything up front.

it is not a big project. it is the first one i finished, and i have started about nine others.

what sold me

the camera, obviously. and the fact that android still gives you things apple has been quietly removing: a proper file manager, real customisation, an actual settings app with everything in it.

what the spec sheet got wrong

• the battery number is a laboratory result. my day is not a laboratory. the difference between the two is the whole review.
• the display resolution stops mattering the moment you read anything long on it, which is most of the day
• "processor generation" tells you nothing about thermals, and thermals are the whole game
• the charger in the box is a decision about your evenings, not about the phone

what i would change

the software support timeline, honestly. not the hardware. the hardware is fine, it is more than fine. it is the part where the manufacturer decides how long you are allowed to keep it, and that has nothing to do with how good the phone is.

if you care about that, buy the phone with the longest support you can find and stop thinking about the spec sheet. it is the only number that will still matter in three years.

and then, like everyone eventually does, i moved to ubuntu and gnome, and everything kept working.

why i moved

• i was maintaining a desktop, not using one. the week i moved, my maintenance went from a few hours a month to about ten minutes, and i reclaimed that time for actual work
• my hardware is not interesting. i did not need a bleeding edge kernel, i needed my laptop to not beep at me
• gnome is a complete desktop, not a foundation you assemble on weekends
• i got tired of the aesthetic. rolling release is a choice, and i was making it for reasons that stopped being about me

what i kept

i kept hyprland for the days i want the compositor, i kept a handful of tools that only exist because i built them, and i kept the habit of reading logs when something breaks. you do not get that habit for free.

the honest conclusion

arch was never better. it was mine. once i realised i was keeping it because it was mine rather than because it worked for me, the argument was over.

use whatever you can maintain. that is the entire opinion.

here is the loop i have watched for the past year:

• something gets posted, usually with a blue check and no history
• five accounts with generated names reply within minutes
• those replies get scraped and summarised somewhere nobody chose to put them
• someone who writes for a living reads the summary

the result is content optimised for being machine-consumed, written by things that only know what the previous layer said. it is not stupid, exactly. it is circular, and it is presented as a conversation.

why this is bad for me specifically

i make things. small things, mostly. and the only honest way to make a good small thing is to spend a long time on something almost nobody sees. that entire economy is invisible to a system that measures replies.

what i do about it

• i stopped optimising for reach. this blog has a search index and an rss feed, and that is deliberate
• i write for one person, usually me, six months ago
• i keep the raw source somewhere i can read it. if the platform goes, the writing is still mine

the internet is not dead. it is just no longer a place where being interesting is enough. you have to be findable, and findable is a different skill from interesting.

where it is genuinely good

• getting from "i do not know how to express this" to a first draft that runs
• reading codebases that are not mine
• the boring translation between two things that should be the same
• as a rubber duck that answers back

where it is genuinely bad

• it removes the part where you struggle, and the struggle is where the understanding comes from
• it produces confident wrong answers with the exact shape of right ones
• it launders other people's code through a model that will not tell you whose
• the output has no memory of your constraints. you have to re-explain every time

my actual rule

i use it the way i use a reference implementation: to get unstuck and to be corrected. anything i ship, i could explain line by line, or it does not ship.

the tell for me is when i cannot explain why the code works. at that point i did not write anything, and i should not be putting my name on it.

partly i did. but mostly it is three boring decisions i made early and never revisited.

1. boring hosting

static files where possible, a small runtime where necessary, a database that is a file. every clever thing i added to the stack got removed within a month because it added a way to fail.

2. the boring part is observable

the only thing i built for myself that i would call infrastructure is a health check i actually look at. not a dashboard i forgot about. a check, a log line, and me reading it.

3. no clever deployments

one branch, one build command, one place it runs. no canary, no blue-green, no matrix of environments. the entire deployment is short enough to read in one breath, which means when it breaks i understand why.

the honest part

the site went down anyway, twice, for reasons that had nothing to do with sophistication. a certificate, and my own bad configuration during a migration.

nothing clever would have saved either. reading the log would have.

the real reasons

• i cannot fix my own tools alone. i shipped a project with exactly one bug report, from someone i do not know, in a language i had not used before. that was the entire value and it cost me nothing
• being wrong in public is free education. every issue i never got was a mistake i got to keep
• the code is the documentation. explaining something twice costs more than writing it down once
• i use everything i publish. the portfolio site, the terminal, the markdown renderer, the tools. none of them have a "real" version

what it is not

it is not a strategy. i have no interest in a business, and the moment i start treating publication as marketing, the whole thing becomes a performance.

the part nobody mentions

maintaining is the job. the writing takes an afternoon, the answering takes a year. i am fine with that because i want the code to exist outside my head, but anyone who says "just open source it" has not yet read the issues.

that is wrong, and here is the part where design is actually the skill.

• most security problems are interface problems. people reuse passwords because the login form is hostile. people ignore warnings because the warning looks like an ad. people click the thing because the button was honest about what it would do and the other one lied
• defaults are design. the path of least resistance is the most powerful thing on the screen
• an error message is a security control. a vague error prevents a fix; a precise one teaches the user what went wrong

the specific things i changed on my own sites because of this:

• the settings that weaken security are grouped, labelled with the cost, and never one click from the safe option
• anything destructive asks for a name, not just a confirmation
• the import and export paths are symmetric, because data you cannot get back is data you have lost

i am not a security engineer. i am the person who decides what the user is offered, and that is enough to lose data.

start with the boring stuff

• learn how the network actually moves, not the tool that watches it
• read the source of something you use daily until you find something that surprises you
• learn one scripting language properly enough to automate your own boredom

then do damage, but only to yourself

i broke my own router, my own site, and my own laptop in that order. each time i wrote down exactly what i assumed, then exactly why the assumption was wrong. that list is worth more than any course.

the habit that matters is writing things down. an exploit you cannot explain is a party trick, not knowledge.

what i would tell past me

• do not start with a framework. start with the protocol
• read one advisory end to end. you learn more from one real thing than from a list of topics
• write your own tooling. a script you wrote will teach you what a tool hides
• italians are not behind. the internet does not care where you learned from, only whether you did

i still have a lot to learn. i am just no longer waiting to be told i am allowed to.