Original link: www.stefanjudis.com/a-firefox-only-minimap

Originally published on Remy Sharp's b:log

Just 24 hours ago, this was going to be a post on how I had failed to repair it, but in a last minute ditch, I managed to save it.

Loading up the game resulted in nothing, and opening the shell explained why. There was a lot of corrosion around the PCB, but more importantly, two of the legs on the ROM had completely dissolved:

The first task is to remove the main chips (the ROM and the RAM) and examine and then clean up the damage under the chips. The black around the vias (the holes) aren't a great sign either.

Whilst the chips are off, this is a good time to (try to) check the traces for continuity throughout the board.

Once the chips were replaced, I then have to repair the lost legs. To do this, I use a small Dremel-like hand tool that can burr into the epoxy (the black part of the chip that you would handle) until I'm able to expose the internal part of the leg before it was lost.

From there, very carefully, I'm soldering a 30 AWG (hair-thin at 0.1mm) to the inside of the chip to the pad it originally connected to.

Then using the same 30 AWG jumper wire, I proceeded to jump all the locations that I knew the trace was bad. It ended up a bit of a spaghetti board:

At this point, it was time to test.

And…it wouldn't boot. I debugged a lot more, but decided the PCB itself had suffered too much damage, and managed to order a new bare PCB for £6.50 - which came reasonably quickly.

I then proceeded to move all the components across from the old PCB to the new. The larger components are pretty straightforward, but the passives, such as the resistors and capacitors are harder, especially without a template.

I also decided to use my own new passives for the resistors, and at the time I didn't have any new capacitors, so I carried these across assuming, since I had always considered them to be pretty robust (spoiler: they aren't).

When I was finally done soldering down all the individual components and checking and re-checking the pads on the chips, I finally tried to boot it up to… another fail.

I was going to email the customer and tell them it was a dead end, when I decided I might splash out on Amazon (booo) for some 0402 SMD capacitors - at least I'd have some more for future.

As it turned out, this was the last of the issues. The caps had somehow gone bad on the original board and replacing them brought the whole cart back to life!

Another one saved. Quite a challenge, and I know if I were a real electronics shop I would have cut the losses much earlier. But I'm not a real shop, this is a distraction hobby and this one was certainly a challenge!

Originally published on Remy Sharp's b:log

I suspect this is very specific to me, but I found the majority of the story pretty triggering - specifically, I felt pissed off a lot of the time I was reading. After reading the About the Author section at the end of the book, it looks like I've had a similar timeline of a technical career to them (which perhaps is why the story got under my skin).

This is because I spent a decade in a company (over a decade ago) that treated it's employees a lot like the characters in the book and it was doing my in that the story seemed to centre around people who made their company the be-all of their lives.

Though the story (sort of) follows two main characters, you really don't meet anyone outside of the company, Gerbach, and there's a scene in the book where it seems pretty clear they all live in each other's pockets.

I didn't really have a good sense of timings until the very end (4 months). The story opens with outages the devs are firefighting, and I couldn't tell if they were still dealing with issues across the timeline or… if they'd just accepted it was all terrible and the characters swan off and pull sickies when their infrastructure is on fire 🤷.

Then there's the AI aspect that's sort of supposed to be looming, but, sort of not really… Around 2/3rds of the way into the story there's a development (not quite a plot twist) which I managed to guess how it related to the AI.

I think if you work in the technology industry, and you are (or have been) a dev, then this book might be worth a read. I'm not sure it's quite that accessible outside of the tech industry, specifically around some of the terminology (which, though I knew, I didn't realise there was a full appendix at the end, "log4j" might throw some people).

Read through a recommendation (later realising that the person who recommended it was listed in the author thanks!), I think I'd struggle to recommend it myself.

Originally published on Remy Sharp's b:log

I run "fix your gameboy game for £10" which occasionally I get orders for. This one was a challenge.

First it had a battery swap attempt (I spotted on the melted shell), but it had also suffered A LOT of flux and grim inside and initially I couldn't see any corrosion.

There were solder bridges on the ROM and eventually I spotted that the VCC vias to the ROM were corroded, so I got a jumper in place from the rear to the VCC pin on the ROM and it started booting.

But…not all was well…

My guess it was related to the RAM chip (assuming the sprites are built in RAM when they're big) and other reddit posts confirmed this.

The old multimeter is my friend, I could see the power monitor/reset chip wasn't getting power. In fact, the trace was fudged where it joins up to a 10K resistor.

I completely removed and rehomed the resistor, found even more vias that were corroded and using this excellent post to trace out from the reset chip to the RAM, I was able to add two more jumpers and only then did it come back to life:

I usually use the hair-thin wires, but I figured if someone was going to replace the battery on this in 5 or more years, hopefully the big blue and yellow wires were shouting I'M HERE ON PURPOSE!

I love getting these challenges - and definitely couldn't do what I do without the wealth of info on the web and reddit on the gameboy.

Another game saved from landfill 💪

Originally published on Remy Sharp's b:log

That reminded me that I wrote a web component that I use quite a bit (particularly with FFConf), which should really be called do-when, but it's not, it's (stupidly) called when-do (the dash, I guess, being a comma in my head).

The component says: when a time occurs or passes, do a what: show, hide or scroll-to.

You can get the code from github - which also includes an interactive demo that lets you try the settings.

What it is

A small web component to toggle on or off depending on wall clock (date) time without affecting the visual layout (with it's own element).

Use case

I've been using this web component on the FFConf event pages for a number of years to reveal the ticket button if a visitor is sitting on the page (though I appreciate that's unlikely!).

<when-do what="hide" datetime="{ticket-live}">
<p>Tickets live at {nice-ticket-live}</p>
</when-do>
<when-do what="show" datetime="{ticket-live}">
<p>Buy <a href="…">now</a>
</when-do>

I've also used the what="scroll" for our schedule page, to automatically scroll to the current speaker.

Though I do appreciate my "battle testing" has been rather limited, so if you use this and spot bugs, please let me know!

API

• what="show|hide|scroll" - the component also throws an exception if a non valid string is used
• datetime="isodate" - recommended that you include the timezone, ie. "2026-09-13T10:00Z" is 10am on 13th September on UTC
• apply="classname" optional class name to apply to the when-do element when it activates, useful if you wanted to transition your contents into view, or highlight the newly scrolled element

How it works/styling

The web component makes use of display: contents to prevent itself from modifying the visual layout.

Due to this display method, it means you can't style the element directly, in that styling has no effect.

If you want to style the contents when the element is active, such as when it has been scrolled into view, it's recommended you wrap the child elements it a parent element, such as a div.

You can also use the apply property to indicate the current when-do has activated.

AI wasn't used in any part of this web component (which is also why the demo page is so ugly).

Originally published on Remy Sharp's b:log

VPNs in particular have been tossed around as something that the UK government would like to ban (citation needed/lacking!), which is why this article is particularly interesting:

The Court of Justice of the European Union has ruled that publishers and VPN providers aren't liable for copyright infringement

Geo-blocking is the copyright holder's problem, not the VPN's. Providers are not liable for users bypassing restrictions

Hopefully this draws a simple line in the sand for the UK government, and yet, who really knows what's going through their head at any one time!

Original link: www.techradar.com/[…]/vpns-are-lawful-technical-tools-says-eu-court-in-landmark-anne-frank-copyright-ruling

Originally published on Remy Sharp's b:log

Specifically he considers the options carefully and was able to make use of local hardware (i.e. his laptop) and "ethically" trained model (from Flickr and creative commons licensed images).

Closing with a quote from Scott Jenson, that I can absolutely relate to:

While the utility is there, the current landscape of these frontier corporate models comes with massive ethical and environmental baggage. This is not a long term solution!

Original link: adactio.com/[…]/22657

Originally published on Remy Sharp's b:log

The story starts in 1938 and we follow Gertie as she plans to retire as a widow having run a bookshop and successful book clubs for many years.

That's put on hold when she agrees to take in a child from the Kindertransport - which I'd know about but hadn't read a great deal of detail.

As a parent myself, this is the first part that breaks my brain a little, and indeed this part is entirely based in history. An amazing effort and so terrible too.

The story then follows Gertie as she takes care of Hedy, a 15 year old German Jew who also longs to be reunited with her family.

The story takes us through The Blitz, the air raid shelters, rolling blackouts and rationing that took place over the years as Hitler and the Nazis spread through Europe.

I've not read any wartime books, so this was an experience. Obviously: harrowing. The story does also do a good job of making me believe the life that tries to march on.

Originally published on Remy Sharp's b:log

Under Assembly Bill 1709 by Democratic Assemblyman Josh Lowenthal, social media companies might soon be forced to remove addictive features.

infinite scroll, auto play, recommended algorithms, and push notifications are product features. They are not speech.

Original link: www.sfgate.com/[…]/meta-social-media-teenagers-22337724.php

Originally published on Remy Sharp's b:log

Chock full of quotable lines, way too many to include to do the post any justice, save perhaps Lea's last headline:

Polyfills make the Web faster, inclusive, and more robust

Highly recommend reading for a greater understanding of the role of polyfills on the web.

Original link: lea.verou.me/[…]/polyfills

Originally published on Remy Sharp's b:log

I appreciate there's some folks out there that don't want to touch LLM generated content or have it in your tool chains, I'm just going to assume that's going to be very hard as time goes on.

Though I do also appreciate there are projects working thanklessly to achieve just that.

Original link: github.com/[…]/d7971544fe17378f44f49983010dbfc1834f7bef

Originally published on Remy Sharp's b:log

I'm not talking about the "star" rule, but what I imagine would be a wildcard on elements selector.

Existing methods

If I want to select and style all the .btn-* classes using attribute selector, I'd do this:

[class^="btn-" i] {
  …
}

This selector says: find all the elements with the class attribute that starts with "btn-" - case insensitive.

It's rather brittle, because it requires that the HTML class attribute starts exactly with btn-. Though it works, it does tie the HTML closely to the CSS - which I'd argue you'd want to be very sure you need to do.

But it is possible.

Equally, and a lot more robust, is the wildcard that says "anywhere in the attribute", so:

[class*="btn"] {
  …
}

It's fine, but it's a bit sledgehammery. However, if you want to do the same thing for a web component, for instance, you can't.

If I want to target all the rem-xxx custom components using rem-* { … }, I can't.

Obviously I'm not the first to think of this, and of course the venerable Lea Verou has thought about this and filed the issue over two years ago, though there doesn't seem to be much interest in supporting it.

The reason it crossed my mind is that I was thinking about how you would initialise web components on a page, and currently it requires searching every single element in the DOM, rather than targetting to the nodes you want ahead of time.

From this MDN article they included a code snippet that (I thought) was a clever way to initialise the components:

for (const element of document.querySelectorAll("*")) {
  const tag = element.tagName.toLowerCase();
  if (tag.startsWith("mdn-")) {
    const component = tag.replace("mdn-", "");
    import(`../components/${component}/element.js`);
  }
}

But really, it should be:

for (const element of document.querySelectorAll("mdn-*")) {
  const component = element.tagName.toLowerCase().replace("mdn-", "");
  import(`../components/${component}/element.js`);
}

This feels like a relatively cheap change to add support for wildcards, and gives the querySelectorAll a nice little boost, along with the benefits Lea already outlined in the github issue she raised.

Would it be valid?

I swear I found the documentation that read that the * asterisk was reserved for the universal selector (i.e. match all things), but I can't find it any more.

However, the from my memory, the parser only allows an asterisk after a space, to indicate it's a universal selector, so foo* or foo-* would not match in the parser.

Equally, it's allowed in the attribute selector, but only when followed by =, but attribute selector already has wildcard support. But maybe this would be extended to cover "glob" like support, so I could do .foo*bar to match .foo-dont-do-it-bar. Again, the current parser doesn't allow for this, so that means it's available for use.

Originally published on Remy Sharp's b:log

Still, it's useful to be reminded that AI generated content is much, much farther reaching.

This project used a Chrome extension (with paid users, from what I could test) and collected a tonne of data and shows for products like LinkedIn, Medium and Twitter, it's anything from 30-50% of AI slop.

Lots of easy to scan charts.

I tend to only use LinkedIn to post about FFConf, then I immediately leave, and I use Reddit for either Gameboy or Home Assistant content, so I'm not really coming across this kind of content myself (or that I've noticed).

Original link: www.pangram.com/[…]/ai-in-your-feed

Originally published on Remy Sharp's b:log

I especially like these two from the post:

Text overflow truncation from centre…

And:

More pseudo-classes. :sticky for if an element is currently sticky, :overflow for if overflowing, etc

Which falls consistently into the category of "JavaScript is used to do this, it shouldn't need to".

Original link: vale.rocks/[…]/web-platform-wishlist

Originally published on Remy Sharp's b:log

parentNode.querySelectorAll('> *') you get an error: '> *' is not a valid selector.. That doesn't work...

Using :scope first fixes the "missing scope".

Original link: siderite.dev/[…]/queryselector-immediate-children-with-scope

Originally published on Remy Sharp's b:log

This book was recommended in our work Slack, and just pull quote for the book description, I found myself instantly buying it:

By normal, you mean like you? A slag with a saviour complex?

The story follows Nadia, an academic who is pulled into a job with the UN to apply her proposal to rehabilitate ISIS brides so they can leave the camps and return home.

What I really enjoyed about this book was the exposure to completely different backgrounds to my own. So for an example, Nadia is Muslim. She has turned her back on her faith. She's gone into academia, and she's now offered a job in the UN to help these ISIS brides.

Most of the characters are completely different to the people in my real life, but the writing is steeped in reality (the author's note at the end explains that she, Younis, was a humanitarian worker known for her expertise on contemporary Iraq, and that though fictionalised, there's a lot of real experience in the story).

Nadia's character is witty, flawed, pissed off, broken and I found myself actually laughing out loud at some of the lines from the book. The book's blurb includes the following line, which I absolutely felt was accurate:

A bitingly original, wildly funny and razor-sharp exploration of love, family, religion, radicalism[…]

I really enjoyed the book, and found it hard to put down - as seen in my 10 day read of what normally takes me a month.

For a first novel, from someone that on paper is very academic and doing very serious work, this is A*. Love it.

Originally published on Remy Sharp's b:log

This post gives a good high level overview of my own concerns about Bluesky being that hub, and though the post doesn't explain how they moved to Eurosky (and funnily enough then link to follow them on Bluesky) - it tries to demonstrate that it is possible to move data around.

I wonder how far we are from being able to self host and connect into the network to disseminate (I think this is the "relay" and I'm fairly sure this is far from trivial for a self-host job).

Still, one I'm keeping my eye on.

Source: waag.org

Originally published on Remy Sharp's b:log

There's lots in there, but I particularly like the section starting Web Components that writes about how they're progressively enhancing and how there's thought to the components (such as their mdn-dropdown styles).

I also really like this pattern where modules are auto-loaded and it's easy to switch JS enabled modules off for testing:

for (const element of document.querySelectorAll("*")) {
  const tag = element.tagName.toLowerCase();
  if (tag.startsWith("mdn-")) {
    const component = tag.replace("mdn-", "");
    import(`../components/${component}/element.js`);
  }
}

Source: developer.mozilla.org

Originally published on Remy Sharp's b:log

I couldn't immediately see how it worked, and since Copilot autocompletes most of my code for me - whether I want to or not, I figured it was a good bit of practice to decompress and understand.

First things first: snooze the little copilot bastard for an hour!

Side note: because I got this post through my reader, I didn't happen to clock the link right after (in the newsletter) that read "a Redditor breaks down exactly what's going on". So…um…yeah, I guess wasted energy, but probably good for my brain.

Here's the original author's code:

// 33 bytes
const signal = F=>(f,G=F)=>F=f?_=>f(G?.()):F?.();

The crux is that it creates a wrapped stack of callbacks. Effectively recursion through locally defined (and overwritten) variables (G in this case).

I started by unpacking the implicit returns so I could see more of what was going on (and renamed F to callback)

const __signal = (callback) => {
  return (f, G=callback) => {
    return callback = f ? _ => f(G?.()) : callback?.()
  }
};

From there, I "simplified" everything as far as I could so that that all the neat tricks could be seen. This certainly isn't better code (probably a version of the one above with nicer names would work).

/**
 * The function stores local variables that are
 * overwritten * with a call stack of passed in
 * functions. When the argument is falsy, then
 * the stack is unwound.
 *
 * Call stack looks like: four(three(two(one())))
 */
function signal(/*F*/ callbackStack) {
  return (/*f*/ callback) => {
    // Each new time the signal singleton is called, it
    // creates a new copy of the `callbackStack`,
    // originally as an argument which saves on the
    // `const` part.

    const localCopy = callbackStack; /*G=F*/

    // if we're passed a callback, then redefine
    // `callbackStack` with where the local copy is
    // called first, then we run the callback.
    // Calling this singleton multiple times creates
    // a stack of functions like:
    //
    // four(three(two(one())))
    //
    // there's also the initial protection with `?.()`
    // to allow for `callbackStack` to be `undefined`.
    // In the example below, I've just unrolled the code.
    if (callback) { /*F=f?*/

      /*f(G?.())*/
      callbackStack = _ => {
        if (localCopy) {
          localCopy();
        }
        return callback();
      }

    } else {
      // otherwise, when called without any arguments,
      // and the `callbackStack` is executed and
      // overwritten at the same time.

      if (callbackStack) {
        callbackStack = callbackStack(); /*F?.()*/
      }
    }

    // the original code returns the `callbackStack`
    // through the implicit return, but it's not actually
    // used for anything, it's just a side effect of
    // compressing the code.
  }
}

Obviously this isn't the point of code-golf, to take someone's hard work and walk them back to the start (and probably even further back), but it was a good bit of brain exercise for me.

For comparison, here's the Redditor's explanation.

Originally published on Remy Sharp's b:log

I've read all the previous Murderbot books, but since the last, I also watched the TV series - which I equally enjoyed, but…or put a weird spin on reading this latest book.

I'd entirely forgotten the "diary" part, and because of the TV series, I had the external perspective and wondered why this book was both being told from Murderbot's internal monologue, but also why there was so much…noise, I guess the word would be.

Once I'd finally remembered that this was the actual format of the book I settled into it, reminding myself there wouldn't be huge character developments (because the diaries tend to last for one mission/episode).

Still, the Murderbot character is in fact growing and evolving and that's fun to read.

The story pulled me along pretty well. Not quite the rip roaring page turner, but a solid entry all the same.

I'm not 100% sure you could just pick this book up without having read at least a few previous books, which is why I hadn't rated it higher (the very first novellas are absolutely excellent).

Enjoyable, even if it took me a minute to remember the specific Murderbot format.

Originally published on Remy Sharp's b:log

/* this is gross and I hate it but it works to fix 
   Safari’s layout of the table’s top headers */
@supports (font: -apple-system-body)

Gross, and horrible, but 🙏

Source: meyerweb.com

Originally published on Remy Sharp's b:log

It was like that from the very first web site - the logo was designed in early 2009 in 12 variations (which you can see from years 2009, 2010 and 2011 before they were really redesigned).

Before I (inevitably) forget, it made sense for me to write up some of the things I learnt along the way now that the 2026 web site is live.

I think Chris Mahon's did an excellent job with his translation of my mood board into Figma pages.

The spec this year was a fanzine style, which is a very tactile paper based medium, which doesn't always translate well to digital. The actual visual impetuous came from the (very fun) Running Man remake, the credits in particular:

The CSS

It's very likely a lot of this (clip-path for instance) have been around for ages. But my client work has been almost exclusively on API backend design for the last 4 years or so, which means FFConf is usually the only time I get to work in the front end to a specification.

Vertical text

I had been wrestling with transform rotates and origins, and had the text sliding all over the place.

Ana Tudor came to my rescue and took away all the pain in a simple single line: writing-mode: vertical-lr. An absolute slam dunk for getting text along the side.

Ana's other tips

• inset: 1 can be used as a shortcut instead of top/left/right/bottom: 0 when stretching across the page.
• I don't need to do transition: rotate(180deg), rotate (and others) are first class now, so rotate: 180deg works (less bytes too).

Polygons

I'd not used polygons in CSS yet (didn't have the use case), but due to the cutout nature of the speaker photos, and the proximity to the talk titles, I quickly realised (after failing with margins) this was the way to go.

• shape-outside floating the element and having the text shape around the element, in particular the cutout of the speaker photos
• clip-path letting me create the sharp angle shape on the footer
• Firefox interactive polygon devtools

I would primarily develop in Chrome Devtools directly using workspaces, but Firefox offers interactive polygon editing which was immensely useful.

Contrast issues

Due to the effect of the "paper", I didn't want to make all the text partly opaque, so instead I lay the paper (which is mostly transparent) over the entire page (with pointer-events: none).

This did mean that there was some grey flecks of colour over black text which definitely caused contrast issues.

In skimming the rendering options in Chrome's devtools I found the "Prefers Contrast" (I'm not sure if I knew about it already or not).

Using @media (prefers-contrast: more) allowed me to remove the paper effect and keep a striking black and white design.

But what if the user wanted control? I added a labelled checkbox and found that instead of using the @media query I could use @container style(--high-contrast: 1). All the modification styles are nested inside of the @container query.

Then the --high-contrast is toggled using:

:root {
  --high-contrast: 0;
}

@media (prefers-contrast: more) {
  :root {
    --high-contrast: 1;
  }
}

body:has(#high_contrast:checked) {
  --high-contrast: 1;
}

Bonus bits

I hadn't realised I could style the ::placeholder pseudo element (not sure why I thought I couldn't).

Lastly, a lovely win for me, I discovered nth-child(odd of <selector>) 🤯. I was trying to set the speaker blocks with alternating position of their photo (which I'd select with odd and even), but there was an extra element between each speaker.

In reviewing the MDN page I discover the of syntax, and it let me target exactly the way I need using: &:nth-child(odd of .speaker-card).

Originally published on Remy Sharp's b:log

<div id="meter" data-props-for="range">
  <input type="range" min="0" max="100" value="42">
</div>

With CSS like:

@container style(--live-value: 100) {
  .gauge__num { color: var(--max-tint); }
  .gauge__flag::after { content: 'max'; }
}

Lots of useful categories too.

Source: prop-for-that.netlify.app

Originally published on Remy Sharp's b:log

I wanted to pull a few quotes:

The Internet Watch Foundation reported that child sexual extortion cases in the UK rose 72% in a single year — criminals tricking young people into sending nude images, then blackmailing them. In 97% of those cases, the victims are boys.

Sacha also spots this:

Buried in the coverage is the acknowledgement that all adults will need to verify their age if they want to take or view nude images on their own devices. [...] You’ll have to prove you’re an adult to own and use a phone.

On one hand, to own a phone requires (since the availability of mobile phones) proof of being an adult, because to get a contract of any sort you had to have a bank account. This obviously changes with "burner" phones (a £10 job from ASDA) and a PAYG sim.

On the other hand, who am I proving I'm an adult to - which walks a weird line of privacy invasion.

Quoted within Sacha's article is Signal's response, and exactly what I was thinking when I saw the announcement too: isn't this at odds with the UK wanting to take some kind of lead in international AI?

Child safety looks like well-funded education, robust social services, and meaningful guardrails on the very AI technologies and platforms the current government is eagerly courting.

An excellent post well worth the review, regardless of parent status, it's going to affect us all.

Source: newsletter.sachajudd.com

Originally published on Remy Sharp's b:log

Admittedly, it's imported from my prior blog and the first time I posted on on this domain was in September, but the post in June counts! But then, my domain was registered a full year before on 13 June 2005 (which neither myself, nor the Internet Archive can remember what was on it!).

I could probably pull up the best hits based on traffic (though my Google analytics were stripped years ago, so I'm not sure how I'd work it out). But I'm not sure the highest traffic really represents the hits to me.

Instead, I'm going to reflect on the last two decades of posts and comment on how what I wrote about has changed.

In the first couple of years of my blog, I was posting regularly throughout the month. Even publishing twice a day.

The posts were a mix of movies I had seen and my excitement in sharing jQuery with non-devs (ie. designers, who back in the mid-2000s didn't have the same exposure to front end code as they do now...I think).

I'm not if it was that the mid-2000s the front end for logic wasn't considered serious enough or... something else, but I always feel like the atmosphere has changed a lot over that time. React has somehow let the trolls out from under the rocks and there's a constant tension around the front end.

Still, my posts in those first 5 years wanted to share technical solutions as simply as possible to newbies and non-devs to show there was a way that didn't require starting your JavaScript journey in 1994.

A personal place

In 2010 Julie and I lost Tia to stillbirth. After a full disconnect from the internet, I tentatively re-entered using my blog as the way to share what had happened and to share our thanks to the overwhelming love we had had from both friends and the community.

Since then I've always used my blog to reflect on another year passing without our girl on, or near, her birth date.

From 2008, I would also write a round up of my year. Something that's celebrated throughout the web blogging community each year around New year (not my blog post! All of yours! Silly thing).

This would also serve as an opportunity to share how our family has grown. Over the years a lot of us (you and I my dear reader) have gotten to chat in person, so it's also fun to hear comments on how our kids have grown. They're a hugely important part of my life, so those comments make me happy.

Ch-ch-changes

Just like a house you've no intention of ever leaving, my blog has had various renovations.

I added my reading records, making an effort to (attempt to) review the books.

I added a short lived Things I Learnt. And a newsletter section, which lasted around a year. And a Things I Fixed (as my experience in hardware grew).

The links section still lives, and probably inspired by Jeremy's links section.

I also added an attic (really, it's a loft, but it sounded more impressive as an "attic") of designs and my ethos page, which is like lifting the lid on my brain and seeing the ideas I try to live by.

In the last 5 years the momentum has proven difficult. The pandemic lockdown cut off a lot of my community connection (through events in particular), and as the years rolled on I've found less and less interest in the web.

Obviously there's AI playing into this. I've written a little about it, and have strong opinions (not all obvious) and I've enjoyed making a lot of personal, offline, projects.

But I don't feel like I've anything to add to the discourse on the web. Maybe I will again one day. I'd love to have the excitement I used to have, but these days, it's just not there.

So my blogging slowed down. It's evident in my archive, and you can see the topics drift away from anything practical and as I got older it's more idea and opinion based. Lol. Like this post!

Your contributions

From day one, I had comments on my site. Those posts that attracted more visitors tended to draw more discussion, which, I mostly approved of.

I had ported the comments from WordPress to Disqus, ejected Disqus when I found they were adding Facebook tracking and landed on commento.io.

At some point during this year (2026), Commento just dropped off the web. First it was hanging requests (which is how I spotted it) and now it's just a 404 holding page. Along with dropping off the web, all the comments you've all left over the years went with it.

A constant side effect of the web: entropy. The lesson there: own your stack if you want to last.

Stick around for some more?

Honestly, the idea of blogging for another 20 years really doesn't sound realistic to me at all! I'll be in my late 60s and frankly, I find it hard to see that far.

That said, in the 20 years behind me, I've published 674 blog posts (excluding this one), 252 links and 188 book reviews. Annoyingly I've got 75 blog posts in draft, some dating back to 2019 (I really need to tidy these up).

My blog is also entirely all my own code - for better or worse.

I'll keep publishing here. I do love my little corner of the web. A mix of musings and code and goodness knows what. Thanks for reading and hanging out online with me for all these long days 💞

Originally published on Remy Sharp's b:log

It's not, it's masonry (which, why not display: masonry 🤷

There's a also a decent (albeit stiff) video on how it works.

TL;DR: mostly you can swap display: grid for display: grid-lanes (but Jeremy goes further to actually add the CSS support check first).

Source: adactio.com

Originally published on Remy Sharp's b:log

In our household we've already had this restriction in place (at a network/DNS level) so it doesn't impact our kids experiences at all, but I do know from talking to the kids that the do wish their friends had it too. I would add that I'm in no doubt that kids will find work arounds, but the larger effect of this, I think, is important.

A few quotes that interest me from the GOV.UK news post:

The ban will therefore include platforms like Snapchat, TikTok, YouTube, Instagram, Facebook and X. We do not intend for messaging services like WhatsApp and Signal to be included in the social media ban

I'm assuming that "like" refers to the user-to-user definition, and I'd expect or hope to see pretty clear definitions (though the government doesn't particularly have a track record on clear definitions).

The government will also be looking in more detail at overnight curfews and breaks in infinite scrolling for under-18-year-olds and will set out more detail in July.

In particular the breaks in infinite scrolling - though I've been personally arguing that it could be banned altogether - the only function it serves from a UX perspective is "stickiness" aka - addition.

I'm sceptical about the implementation rules and I'm particularly worried about how the government goes about setting the definitions of what products will need to do.

Source: www.gov.uk

Originally published on Remy Sharp's b:log

I think what I find interesting here is after the jQuery mobile themes and especially Bootstrap you come to just visually adapt the most common style.

What this author has done is asked for the design systems of existing software to be adopted into the code.

What frustrates me a little bit is that I actually like the "Original" style, which is what AI is pumping out at the moment, as what I see all the time, which just says that I'm not very original…

Source: envs.net

Originally published on Remy Sharp's b:log

The UK government's ultimatum to Apple and Google is a blueprint for mass surveillance. A warning on why "nothing to hide" won't protect your digital freedom.

...

We're being steered toward a future where "safety" is just a euphemism for "unrestricted access."

If I had read this a few years ago, I'd assume it was the plot for some dystopian novel, but no, it's reality today under (what was supposed to be) the progressive government - not even the Tories.

As per the author, I don't expect any of the Big Tech to do anything about it if it means it affects their share of the gold.

I guess I'll be looking around for alternatives soon enough too (and then for the kids, and the extended family). Yay.

Source: the.unknown-universe.co.uk

Originally published on Remy Sharp's b:log

This is the extension of a previous post, Molly Guard in reverse which introduces the molly guard with:

…the little plastic safety cover you have to move out of the way before you press some button of significance.

Anecdotally, this is named after Molly, an engineer’s daughter who was invited to a datacenter and promptly pressed a big red button, as one would.

Then she did it again later the same day.

Love it.

But what's more to love about this particular post, is that Marcin found the actual Molly with her dad!

Source: unsung.aresluna.org

Originally published on Remy Sharp's b:log

The "AI overview" is its own content, not just a list of search results.

This is really interesting and I would love to see this set the tone for other countries (::cough UK::).

If enough of that wrong content defames companies or individuals, it could become a serious legal problem not just for Google but for other providers of similar services like ChatGPT, Claude, or Perplexity.

Big Tech helped themselves to our content. The content bloggers put out on the web was always intended to be consumed freely, but it we didn't agree that you (Big Tech) could use it for massive profits without the least bit of credit (let alone royalties for the content being used).

The big AI companies have harvested and thrown the web into their models without moderation causing all kinds of real-world harm, so this looks to be a positive step to forcing them to take some real responsibility.

Source: the-decoder.com

Originally published on Remy Sharp's b:log

The term deepfake traditionally refers to photos, audio, and video, but when it comes to discussions of consciousness, we need to regard text as a deepfake medium as well.

This does remind me of the story of ELIZA and Joseph Weizenbaum, which people quickly attributed intelligence to the bot. With 6 months of ELIZA's debut (in 1966), he warned loudly and publicly about the perils of anthropomorphism. He continued this campaign until his death in 2008. Yet, here we are again.

Source: www.theatlantic.com

Originally published on Remy Sharp's b:log

Source: dbushell.com

Originally published on Remy Sharp's b:log

The open rate is usually around 40% (though I know some email systems synthetically do this), but our click rates are also usually pretty good.

This week however, open rate was 3% and click rate was just 8 clicks. Something was definitely…afoot.

Spam scores

I had a report from a friend of the event that last week's newsletter landed in their spam folder. From this, I decided to integrate spamassassin to try to score the content (which it almost always comes back clean).

As belt and braces, I also paid for some credit for Mail Tester which gives me an email address that I can send to and it'll run all manner of tests, including stuff outside of the actual markup.

I had a score of 9.8/10 - so I dipped into what could be improved, and suggested "check DMARC policy state".

DMARC

The page suggested:

Not being that versed in email security set up, and like many of us, having to wear many hats, I just copied what I needed and trotted along adding this record.

What I didn't appreciate was that this change translates to:

If the email didn't come from Left Logic, just reject it.

The problem being is that the email doesn't come from Left Logic, it comes from AWS because I use SES for sending the newsletters. So even though our newsletter product said they were all sent. AWS also said they were all sent. Only a handful of people had the email.

The only reason I figured it out was because I hadn't received the email to my personal email.

The temporary fix was to add this to the _dmarc.leftlogic.com as a TXT:

"v=DMARC1; p=none; rua=mailto:dmarc@leftlogic.com"

I do need to sort out proper SPF records and DKIM and "Easy DMARC" (whatever that is), but next time around I might be a little more careful with what I copy and paste…

(though, who am I kidding!)

Originally published on Remy Sharp's b:log

The development this iteration of the game, the one in 2026, took me about a week and I haven't written a single line of code. Here's how things have changed.

TL;DR

I get it, this is a stupidly long blog post. There's no real value buried inside of it, it's pretty much entirely a story of how technology has progressed over 30 years (not really a spoiler) and my journey to evolve a game that I found in 1996.

The latest edition of this game was coded entirely by Claude Code with one strict rule: keep inside of the 32K boundary limit. There was a huge saving that Claude never suggested (1bpp font tiles instead of 2bpp) which bought me 3K - which was enough to add a full tutorial in the game along with additional small features.

I also tried to vibe code another game using the same process only to fail - the key take away for me was that my experience and knowledge was still the guiding light. With the other game, it failed because my knowledge was shallow, so the output was shallow. Sort of obvious on paper, but a useful exercise for me.

Oh, and if you scroll to the end, there's a link to the game download page.

1996

At some point during my days during Sixth Form (college to some, basically aged 16-18), a close friend had (some) machine (that neither of us can remember) and they let me play a game on it.

I remember really enjoying the game. It was technically a very simple puzzle game: a bunch of balls that you would tap the matching colour groups of balls and they would collapse down into the corner. The goal being to clear the screen.

I never caught the name of the game but my dad had a Psion and remembered that in the instruction manual (long gone are those times) it mentioned you could write your own software.

I'd been making little Visual Basic programs for friends for a few years by then, so I decided that since I had access to the internet (of sorts) through bulletin boards I would try and build my version of game so I could play it all the time!

When I finally managed to download and printed out the documentation (I remember it just kept printing and printing and printing), the very first is what hit the hardest.

SDK. This was foreshadowing. I had no idea what an SDK was. Nor any of the other mass of acronyms. And software development being gate-kept by the usual nerds meant there wasn't going to be any help with the "basic stuff".

(In truth is might have been any kind of acronym, I just remember being bewildered).

Google doesn't exist yet so I tried thumbing through the documentation and spent probably weeks just going back and forth just looking for any clue that would help me get a footing so I'd have something to start with.

In the end, I got absolutely nowhere. I park the idea and put it down to lack of knowledge, and lack of experience. This was not for someone like me. This was for people who had the inside knowledge. Plus, at that age, I had plenty of other (better) distractions.

2002

In 1999 I started my work placement for a year as part of my Computer Information Systems Design sandwich course degree (a mouthful!). In the end, I'd never return to finish my degree and stayed on for a decade.

But back to '99 and the start of the new century. The company was a web agency with the boss and two students (myself being one). Along with client work, the agency also had it's own side projects, one of which was Eurocool - a website dedicated to software for the Palm Pilot (they even made BBC news).

So I eventually bought myself one and through Eurocool I started notice that some of the games and some of the utilities came with source code and the source code was not huge and by this point I had learnt a lot more programming.

By that time I had tinkered with some C, worked with Java. I was writing JavaScript (JScript and VBScript). I was writing Perl and I could start to understand the functions of the source code and I went about making my first utility for the Palm pilot for me.

I started with a couple of smaller bits of software for the Palm Pilot, before I realised I could (and should) make a game

As it turns out that I'm not a very good graphic designer, so when it came to drawing circles for the Palm Pilot it was…very, very bad. The best I could do was draw squares and colour them in. So this is where the name Marbles Squared comes from ("it's a feature, not a bug!").

It took me until the mid 2020 so realise that the original game from the 90s was actually SameGame that I had unwittingly cloned (though only the game play mechanic, the Wiki page details the scoring system which I was never aware of).

One of the key mechanics of my version of the game was that the the random function would have a seed, and that seed would make the grids being played repeatable and shareable.

My game even turned up in American Scientific (though the original article has been long disappeared sadly). After a few years, the game had been downloaded over 1/4 million times.

More importantly though, the coding part took me (probably) 3 months to go from scratch to the first version of a workable game, mostly coding late into the night because I had a full-time job (running in start-up days of getting home at 8pm and later). I'd continue to iterate on it for a further 6 months and the last release was in 2003. If you want to try the game on a (pretty faithful) web port of the Palm Pilot, I'm hosting the Palm version on the Marbles website.

2008

By the mid-late 2000s, I had move away from London and I joined the web scene down in Brighton. Coincidentally the iPhone had launched in 2007.

Eventually I caved and got myself an iPhone and Steve Jobs original vision was for developers to use the web and the power of the browser (sidebar: that wasn't really his vision, he just didn't want 3rd party apps).

So that's what I did. I took my knowledge of Marbles Squared and the only code that was directly ported was the random function so that I could continue supporting the seed mechanic.

I also add a timer bar across the bottom of the screen (to let me play with CSS transitions), but functional it did nothing, so watching friends play the game and panicking about the timer running out was a real delight!

Developing the core of the mobile version was a matter weeks (if that) because I was breathing JavaScript daily, and that I was so familiar with how the game would play.

As with all these projects, it really wasn't the core gameplay that took the time, it was the UX around the game. The damn button in particular with the "new" border-image (vendor prefixed to kingdom come!) probably proved to be the trickiest parts.

A it probably took me a few weeks to finish the mobile version.

2020

In 2020, the ZX Spectrum Next Kickstarter project was delivered (after quite a few long years of waiting) and with the pandemic lockdown in full swing, it was time to tinker.

The Next came with an upgraded (and much more capable) NextBASIC (plus the crystal boost to 28Mhz made a big difference). So I set about making myself a game.

I wrote a clone of Oh Mummy that I used to play on the my friends' Commodore C64 but after that was done I turn my hand to recreating my Marbles game.

The challenge here was that even though the Next was faster than an original ZX Spectrum, NextBASIC still wasn't fast enough to do the grid traversing to workout available moves - or certainly not in a way that felt responsive.

So this meant turning my hand to Z80 assembly. I'd tinkered with the language but never had a real project to solve with it. This was perfect for dipping my toe into. Plus, there was 40+ years of experience on the web to learn from.

The bulk of the game would still be in NextBASIC but it would call out to a library that I wrote in assembly for hard tasks.

That project probably took me over 3 months because it was a brand new language. It was also much harder to debug. The development cycle is a lot longer compared to something like JavaScript.

But as I reach the end of that piece of work, I realised that I wanted to add a high score table.

The Spectrum Next (most times) included a Wi-Fi module, but it didn't have any native HTP protocol support so was another side quest.

I built an HTTP client in assembly for the spectrum and one of my more prouder moments that my .http is now part of the Spectrum Next distro, part of the default library of tools.

This would let players see a global leaderboard on the spectrum and share their own high scores directly from the retro hardware.

The http part was probably another three or more months, but absolutely worth it.

2026

In the intervening years AI has exploded as we're all well aware.

In the last few months I have taken to using LLMs to create small personal projects that serve a single purpose, a tool to calculate the distance between a and b, but also to add how long it would take me to walk or run and so on. Or maybe it would be a small song game that I would share with my friends.

About a month ago, I decided that I would take my experience of vibe coding and see if I could build the Game Boy game that I've been wanting the Game Boy version of Marles Squared (ironically I discovered, literally today, that Samegame was available on the Game Boy in 1997 - though it's very different from the game I wanted to enjoy).

I was able to describe in detail exactly what I wanted and I was able to iterate over and over and over to get all the details kind of fine-tuned. It certainly wasn't just a one shot build me a Game Boy game.

As with all the previous iterations, the real work was in the UI.

I did however, set myself the constraint that the game had to fit into a 32K rom (this means it works on a cart that doesn't have an MBC - memory bank controller - chip - which is what allowed games to grow up to 8MB large).

The LLM (Claude Code in my case) was also vital to really quickly turning around tooling that helped me in the development process. Tools to slice my graphics into tiles or to visualise tile data inline to code, or to convert fonts (for variable width fonts which I didn't use in the end due to byte size limits).

I was also able to take an existing rust implementation of a Game Boy emulator and layered on an MCP server so that that Claude Code could test, screenshot and probe the memory of the game to see if it was doing what I needed to do.

But the whole process was me just talking back and forth to Claude code in particular to get this game built and the vast majority of it took about a week.

After a couple of rounds of testing, I did notice that the couple of people who tried the game didn't quite know what the goal was. A "how to play" section was needed in the game, but given the constraints of 32K, lumping in a load of text copy wasn't going to work.

One of the biggest wins I had in optimising the codebase was not from Claude. I could see all the text tiles (the tiles that make up the font) were two colours. Whereas a Game Boy tile stores 4 bits of colour in a "pixel", I could see I was wasting a lot of space. GBDK even includes a native function set_bkg_1bpp_data that will make use of 1bpp tile data. From this single change (I had to update my tools to generate 1bpp) I was able to unlock over 3K. This space was then used for the tutorial and a number of other small changes (including increasing the pool of "easy game seeds").

So in the 30 years that's passed I've gone from taking weeks and weeks looking at documentation and getting nowhere to taking a week to build a fully working piece of software that suits all of my requirements.

But the reality isn't as straightforward to say you can just magic up anything you want. My advantage I have is that I've got decades worth of experience in software development. I also have an intimate understanding as to how this game is supposed to work.

As an experiment I tried to vibe code another game. Our family was playing 100 Jumps and I thought it'd be a good candidate for a Game Boy game.

The source code is online, and on the surface it seemed pretty straightforward to me to re-use the techniques that I was using to develop Marble Squared.

Except what happened is I kept iterating on something that was awful. The physics were wrong. The movement was wrong. The graphics were bad. No matter how many times I tried to iterate and even reset, it just didn't come out feeling like a decent experience.

I've come to realise that the reason for this, is because of where my experience lies, and in particular my intimate understanding of how my own game works. This knowledge allowed me to carefully plan out the development, to know where all the pitfalls were ahead of time, which I simply didn't have for 100 Jumps.

I think we're starting to see in the tech industry that the pitch that AI is here to replace our jobs isn't entirely true. In fact, a lot of us have known for decades that the real skill isn't in producing code, but actually understanding functionality and translating it to the real world.

If you made it this far, thank you for reading. If you simply skipped from the top to find the download link, I appreciate you too 😄

You can download the game over on itch, and if you fancy your chances, you can submit your high score via the Marbles website.

Originally published on Remy Sharp's b:log

It took me until around 20% of the book to get on with it properly. I was struggling to even want to pick up the book. It's well written, but the subject, end of life, was so unappealing that I found myself wanting to avoid reading the book.

At some point around 1/5 of the way in, this feeling settled and I was swept along by the narrative that the main character, Bo, gives us.

I think reading this there's going to be different aspects that hit different people hardest. I'm not a dog person, so the thread about Sixten, his dog, though sad (the dog doesn't die!) it didn't gut punch me.

I did however relate hard to the inner monologue not linking up to what's actually said. Something I suspect most people can relate to - which I suspect is the reason this book is well recommended.

The book is told almost exclusively from the thoughts of Bo, the elderly 89 year old man (which took me quite a few pages to actually work out). From his thoughts we travel back and forth in his memory which worked really well. I didn't feel lost at all, maybe because Bo's memories felt like they flowed naturally back and forth.

The story really does feel like it's being faithful to the human flaws many of us share.

It also, for me, did an excellent job of building up my relationship with Bo and gently brought me to tears right at the end in a way that made me message my kids to tell them I love them.

Originally published on Remy Sharp's b:log

Originally published on Remy Sharp's b:log

For little pop out menus it's perfect. Then I also started using it for modal boxes (yes, you might be thinking ahead of me: dialog, still, let's find out what happened).

The popover property was really easy for this, and the ::backdrop selector was perfect for adding a little backdrop blur to tell my user "this is the thing you're dealing with".

I especially love that all the UX around dismissing is handled for me. I can hit the escape key, or click outside the popover and it's dismissed.

Except, I kept noticing that when I dismissed my popover it would sometimes vanish then immediately pop back to life…

On using the wrong tool

It was through a chat with Bramus during a BTConf lunch that it was pointed out that I should be using a dialog for a modal.

I think the reason I didn't think of this earlier is down to the age old problem of naming. I have a mental model that a modal is a different thing from a dialog box. Specifically a dialog lets me set it aside whilst I carry on with what I'm doing.

For example, in many native desktop apps, a preference dialog can be opened, but I can still interact with the software.

Whereas a modal is "you need to do this and we'll lock out the app until you do". Although dismissing the modal is also valid as an action.

Anyway, that was my thinking as to why I hadn't used a dialog for modal actions.

I also didn't know I could use the ::backdrop selector with dialog - mostly because I'd heard of it in the context of the popover.

So what's the anti-pattern?

A popover doesn't trap focus (which is the whole point of a dialog). But I wasn't looking at keyboard focus, I was looking at mouse focus.

When I used the popover for a modal (looking) element, and used a blur on the backdrop selector, I didn't realise that clicking on the backdrop would let the click carry through to whatever was underneath it.

So visually the UX is saying the modal is the thing that you need to do, and clicking anywhere else will dismiss it. Technically, I could have a solid colour hiding everything under the modal and you'd have no idea what you were clicking through to.

Let's look at the two buttons below. The "click jack" one will show an alert box. If you click the "modal" button, you'll get my modal, and under the solid backdrop, I'm going to position the "click jack" button across the entire screen, so when you click away to dismiss the modal, you should get the alert.

Besides the JavaScript click handler for the click jack alert, this is all done with CSS:

/* put a solid colour over the page */
#demo-popover::backdrop {
  background-color: hotpink;
  /*
    note there's a bug that I've filed in FF that
    doesn't like solid backgrounds.
    https://bugzilla.mozilla.org/2038260
  */
}

/* expand the "bad" button under the page */
#demo-popover:popover-open + #demo-clickjack {
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
}

This isn't really a demo of click jacking (I've not fully thought though whether it's a real world issue or not), but it shows how I had managed to click to dismiss my modal and then accidentally hit a "live" target in my blurred background.

Now with a dialog

In this example, when the ::backdrop is active, it does still have a giant "click jack" button under it (you'll need to inspect the DOM to validate this), but the backdrop also traps the clicks and it doesn't go through.

That said, you can swap this same code to use popovertarget and the same problem occurs (because it's not modal, and won't trap the click).

Side note: oddly, if you happen to click on the button that opened the popover, it doesn't re-open the popover. You can see this in the MDN demo of dialog with popover.

I think ::backdrop might be the problem

For me to fall so quickly into this pattern of using a popover with the ::backdrop, and not realise I was taking the wrong approach feels like it might be something others will fall into quickly too - especially if you work in an environment where generated code isn't scrutinised.

I could even see developers trying to use pointer-events to prevent clicking through the ::backdrop whilst using popover which would really be committing to the wrong approach.

Another question is: what is the ::backdrop pseudo element for, if not obscuring the background? Therefore, if the background is obscured, then surely we're looking at a modal element (because the background is now visually out of focus)?

Which all leads me to wonder if popover should even have support for ::backdrop.

Originally published on Remy Sharp's b:log

Thanks to Big Brain Keith Cirkel for sharing this.

As (hopefully) you know, there's the $ and $$ functions in devtools. For querySelector and querySelectorAll respectively.

Well there's also $$$ to query through the shadow DOM. This means the query will cut through and into the nested DOM inside of the shadow DOM making it much easier to navigate and search for elements when debugging or styling.

It's worth also adding that, just like $ and $$, this third function also takes a second argument for context, so it means this is valid (where $0 is the currently selected DOM node in the devtools inspector):

$$$('ha-card', $0)

Begs the question: what's going to be lurking inside of $$$$ in 5 years time!

Originally published on Remy Sharp's b:log

Aliento

For some reason macos, for quite a number of versions has made it really hard to dismiss notifications (heaven forbid you repeatedly flash a raspberry pi pico). The hot target is horrible and there's many notifications that don't bundle together (the unmounted drive springs to mind).

Aliento give me a single key binding that swiped all notifications away. A daily use for me.

Aliento

Muzzle

Speaking of notifications, if you've ever given or seen a talk or video call when a distracting notification appears then this the app to solve it.

It's a toggle that muzzles your notifications. Once turned off, they'll all pile in - and you can review or use Aliento.

Muzzle

Shottr

I'm sure most of us have our goto screenshot tool. I've been using Shottr for quite a few years now. The base functionality is good, but what it adds is a quick way to draw, point, annotate and even OCR screenshots.

One extra little feature I like is that I can then drag the screenshot to where I want to share and then the file is never saved (my screenshot folder is 'uuuge already!).

Shottr

VoiceInk

As big as my phone is, I find myself dictating more and more (somewhere last year the voice recognition had a massive step change improvement).

Lately I'd been looking for a suitable voice to text on my desktop and laptop but ideally with the processing done on machine (rather than needing to wait for the roundtrip to some random server).

I use VoiceInk multiple times a day. Both for push-to-talk and for much longer sentences.

There's options to download different models, but I've found the Apple native STT to be suitable and usually the quickest (even though one machine is on Somona and the other is running Tahoe).

VoiceInk

KeyboardCleanTool

It helps you do the thing it says. Though it doesn't clean your keyboard, it does trap all key presses so you're not randomly posting emails containing keyboard mashing.

KeyboardCleanTool

Karabiner-Elements

This one has been installed on my machine(s) for years. It's one of those apps that sit in the background, do the work, and make things just a little bit more to your liking.

Primarily it's a key binding app. In my case, I wanted to swap my ctrl and alt keys, but only when using a specific keyboard. This does the job.

It also allows me to add much more complicated bindings (which historically have been tricky, but LLMs are pretty good at generating these if you need them too).

Karabiner-Elements

Better mouse

I've got a Logi MX (something) mouse. It's very fancy, and has more buttons than camo trousers have pockets.

Earlier this year, Logitech pushed a server change that somehow (I really don't understand how or why) borked the Logi mice/mouses(?!).

With that I immediately sourced an alternative that didn't bind my physical device to a cloud server 🤦

BetterMouse is that for me. Tonnes of configuration, specifically I can bind the buttons to perform custom tasks depending on the focused application.

What also stood out for me, the UI for finding the right button (that I wanted to bind) was much easier than the existing Logitech software.

BetterMouse

Sim Daltonism

I can't remember quite when I first installed this app, but it's got to be at least a decade.

It's a window that sits above all else, and let's me quickly cycle through different types of colour blindness.

I know that some of the browser dev tools included this, but I found a standalone app the simplest (since it can also see beyond the browser, such as mock ups in Photoshop or Sketch and the likes).

It's an app they I always reach for once the colour system is in place for the website I'm working on.

Sim Daltonism

Tahoe Electron Detector

Let me say this first: do not, if possible, upgrade to Tahoe. It's a total mess.

Still, if you unwittingly upgraded like I did, you might find that software becomes somewhat sluggish. For me I noticed hover effects in Firefox was firing log after I had left that target.

The issue is related (from what I understand) to some private libraries being used by Electron apps. A full reboot would resolve the issue until it raised its ugly head again.

So Tahoe Electron Detector checks your installed apps, and tells you which haven't been upgraded away from this particular bug.

Once I know what the list looked like it was easy for me to stop using those apps (Dropbox and Discord at the time, and I could use the web alternatives), and the sluggish problem went away.

Tahoe Electron Detector

Bartender

This is probably one of the most popular apps I'm listing, so I suspect many of you have already heard of it. Hopefully it helps a few of you though.

Bartender let's me pick and choose which menubar icons are visible, and which are tucked away. There's also a rule system that lets you show particular menubar icons depending on conditions (such as battery level or WiFi connection).

There are a few issues that I have with the latest edition (but are primarily due to macos rather than Bartender itself): there's a couple of system menubar icons you can't hide (like the notification centre), and I've found that some menubar apps don't open and stay open when Bartender is running (NordVPN being one of those apps).

Bartender

There's many other apps I use, but they're much more common place. There's also apps that are very cool (notist) that I just can't make into a habit.

On that note, I'd love to read your favourites that might be hidden gems.

Originally published on Remy Sharp's b:log

I really enjoyed reading this book. The story floats like a butterfly from one character to the next and it works without losing the reader.

The story, I think, follows the Flynn family and though they're painted as somewhat dysfunctional, they're all spirited in their own journey.

There's a line towards the end that reflects on the mother's character not having given up on her art career, but having chosen to be a mother. The book definitely left me with this sense: that we're okay.

There is a strong religious thread in the book (not being religious myself) but it wasn't an agenda being pushed, but rather something for some of the characters to hang on to.

Easily enjoyable. I loved the characters and would definitely recommend.

Originally published on Remy Sharp's b:log

I bought and read this book after seeing Caroline Lucas speaking with Zack Polanski during a live session of Bold Politics. It's a book that tries to reclaim "Englishness" from the weaponising that the Far Right have been using it for.

Overall, it's an interesting read, lots of history, both good and bad, lots of literature and how stories and poetry has been used over the centuries to act as a force for political change for good.

Solidarity and standing up for what's right is the theme the ran through for me.

From a technical perspective, I didn't enjoy that nearly every single page also came with a long paragraph of footnotes - which normally I skip (because it goes off to the end of the book and back, but these were inline on the same page), and completely broke the flow of what I was reading. I wish that these had simply been part of the written content rather than regular sidebars.

Then as I read, I felt like perhaps I wasn't quite the audience to fully appreciate the book. There's certainly a good chunk that is accessible, but it often felt like if I worked in politics this content would make more sense.

I did come away with 23 highlights and wanted to highlight more, partly to remember what I had read, partly as a "wow, I did not know".

I think if you enjoy your history and commentary and literature, then you'll enjoy this book. I struggle to read non-fiction in any reasonable amount of time, so I often find by the time I get to the end of a book, I forget the important things from the start!

Originally published on Remy Sharp's b:log

My Android phone, on our network, on the same SSID, speed tests at 1.1Gbps. My laptop gets around 160Mbps and my desktop pulls in around 80Mbps.

That's quite a difference, and even though I don't need the gigabit speeds - sometimes I can tell when the desktop is being slow (web site be getting big).

What was weird is that the network speeds get much faster if I add something like NordVPN to my connection…which doesn't make sense…

TL;DR - AWDL

It's a "magic" non standard enhancement (Apple Wireless Direct Link) to WiFi that Apple use that can seriously hamper your network connectivity. It's hard to kill, so the "simpler" approach is to ensure the Wifi channels you use are 44 (for 5Ghz in Europe, or 36 outside).

Slightly longer

My router, for it's 5Ghz channel, uses 160Mhz using (something called) DFS (apparently nothing to do with sofas…sorry, British joke): Dynamic Frequency Selection.

This seems to throw Apple a curve ball when it comes to their AWDL (honestly, screw Apple for having more tech that we can't control and ends up getting in the way).

AWDL is part of the system that's (from what I understood) responsible for things like AirDrop (which I don't use). Of course, turning it off doesn't really work - it's an easter process: it keeps respawning. It sort of stayed disabled on my laptop running Tahoe, but on my desktop running Somona it wouldn't stay down regardless of what I did.

Even though this problem is exclusively an Apple problem, the only way I could resurrect my network connectivity (and even though I caught it at 60Mbps, I'd seen it much, much slower) was by switching the 5Ghz to 80Mhz (all the hertz) and selecting 44 as my channel.

Night and day difference:

Ultimately my plan is to set the Wifi booster/mesh/thingy to have a Mac specific 5Ghz connection point, which is then hard wired through our house into the router, then I can have 5Ghz at 160Mhz band (so nice for all other devices, like our TV) and - hopefully - the pesky Apple devices can pull data at a decent speed too.

Originally published on Remy Sharp's b:log

The short version is: if you get the chance to attend these events or even anything similar, I'd highly recommend that you grab that ticket and let the event wash over you.

For those that didn't attend (or maybe you did and wanted to read my perspective) then here's my thoughts on the separate events and then the round up of my own experience.

State of the Browser

London based and fronted by the lovable Dave Letorey, always has a strong accessibility story - both from a practical ("how to make the web accessible") but also universal access - in that all are welcome and an open web is championed through the talks and the heart of the event.

I tried to take a few notes for myself during the day, but this quickly fell to the wayside by midday (I find if I'm taking notes I'm slowly losing track of the talk, so it was more important at the time to stay in the moment).

The day did start with Bramus Van Damme with an excellent dive into CSS anchor position, an exciting new feature of CSS that's landing throughout browsers that means we can move a lot of complex JavaScript into the bin. The CSS spec itself it's wholly simple, and there's a blind spot specifically around recreating call out arrows (usually done using rotated weird border magic).

I do question the ease of testing - though I think a talk on how to test CSS (with launching a browser and diffing the screenshot) would be extremely valuable.

Another talk by Fiona Safari on how they learnt to work with their introvertness(?) left me feeling very "seen", though Stuart did raise the valid point that this felt a little like the Barnum effect - where you're able to recognise yourself in most things (we're human after all, and patterns and self interest is programmed deep in us).

This quote really meant a lot to me, and I think about kids who don't push themselves to the front of the class - this is one to remember:

Zach Leatherman's talk looking at how a common picture compare component would and could be developed from the day the first img element was released to today. Especially drawing attention to the "dead zone" where code has landed in the browser yet the interactivity isn't at all ready.

The time to interactivity is a metric I think (I hope), we're thinking of all the time, but to see it articulated and in the context of a relatively contained context really helped - especially considering that webbies have to go back to work and argue the case.

Then Jason Williams gave a wonderful context to how Temporal came about and the sheer scale of the work.

I've spent my fair share of bemoaning the JavaScript date object (since '99, so yeah, I've been at the sharp end of Date suckage!), so learning about the mammoth effort that went into bringing a completely new date structure was a real treat.

I've been using Temporal for a good few years via a polyfill, but to learn there's so much more and it's arriving cross browser (and server-side) is valuable.

Chad Gowler's accessibility talk was absolutely superb and I do hope they have the opportunity to give the talk again at more events - so many people can learn from these experiences.

Likewise with Mike Hall's story of battling for every single byte for performance in a time when it really, really mattered (and in some senses, still does). Mike's always a pleasure to listen to (both as a speaker but also his podcast).

I'll be there for next year's State of the Browser

Web Day Out

My general feeling from (the first) Web Day Out was that there was a strong sense of practical takeaway from the talks.

I'm hoping the slides will be available (if they're not already) because there's lots of little details in many of the talks that I definitely felt like I could apply today.

All of the talks from Web Day Out were ace quality, reflecting the wonderful speaker line up.

Jemima Abu very much set the starting tone for the day. A taste of new and exciting CSS features (touching on some of the items from Bramus at State of the Browser), and speaking to the solid idea that there's technology that's moved out of the JavaScript cycle deeper into the platform, either available in CSS or event HTML itself (such as popup). Giving me even more reason to eject bytes from my code.

The original Lady of CSS, Rachel Andrew talked about what Baseline means to development and talked about the very practical nature of support.

One incredibly interesting item that I've not heard others mention: Rachel points out that given the nature of the data collected on Baseline support, it's now possible to accurately predict browser support by a given amount of time. Specifically, if a feature moves to "newly available" today, it will land in "widely available" in 30 months. This might sound like a long time, but Rachel makes the excellent point that developers working on a year-long+ project can use features that may not have wide support from the outset, but they'll be able to pick features based on expected support at the time they go live.

Rachel did also talk about how the Baseline project, in an early form, did consider whether to include polyfills as part of the support timelines, but the search for a "gold standard" of polyfill was…elusive. For my part, personally, I wouldn't want or expect to see polyfills being stamped with approval by browsers. As Rachel said herself, the requirements for polyfills (and what's considered Baseline) is entirely dependant on your own projects and products.

Next was Aleth Gueguen who shared their story of development and testing directly from the trenches - figuratively and literally. In the post-social a good number of people shared how much they appreciated the insights saying how they'd love to hear more real-life stories, as often it's the real development and challenges overcome that make an interesting story (echo'ing Mike Hall's story from State of the Browser).

Then Harry Roberts took the stage to talk outside of his usual stomping ground. That's to say, instead of performance and measurements he instead spoke to the impact of not building for the web. He shared practical examples of where (anonymised) clients had brought Harry in to work on their performance issues whilst they grappled with framework upgrades. It's a strange web-world we live in when the typical path development path is to reach for Next/Nuxt/Fux/Whux/evar because everyone is does and laden the users with bloat.

Harry had many excellent points during his talk, one that comes to mind as I write today was how optimising for 2nd page load with a coach load of JavaScript, when the bounce rate is so high is premature optimisation (pause for feigned shock) - which ultimately costs negatively.

This wasn't Harry's normal wheelhouse of talk - by his own admission - but an excellent one, and I hope he gets to repeat it for others.

Post lunch, was Manuel Matuzovič sharing his newly gained knowledge from questioning if what he knew 3 years ago still stands, and modifying and improving the tech he was using - squarely in CSS land. He used his own pet project oli.css as a place to experiment (I strongly approve - always find a safe place to play), and in particular shared his really interesting take on a CSS "reset" (not a reset per se, because browsers have managed to converge on a solid starting point, but a great starter CSS) and how he layers and reuses throughout the project.

Keeping in this space, which Jeremy made clear he had curated the talks and order into these excellent pairings, Richard Rutter talked us through what had changed in (web) font typography in the last 9 years since he published The Web Typography book.

I'll be honest, I really didn't think the web type scene was either interesting or even moving. But by gosh there was a LOT. Tonnes of interesting tweaks that we can be making here and today, lots of features that were in Baseline, others that were coming. Of all the talks, Richard's had the most "oooh - I really need to pinch this for my website" slides. I'm hoping they'll be available (and I remember to find it) because it really was a treasure trove.

In the final straight was Jake Archibald taking a zoomed in view on the customisable select element that is landing (or landed). A (typically) hilarious talk where he went all the way back to 1993 and went through all the events that needed to take place before developers (finally) laid their hands on a stylable select - whilst also showing us how to style the select today.

Highly enjoyable and difficult to ignore the contents of his slides! 😂

Finally Lola Odelola talked about their experience approaching and implementing a missing browser feature - a fallout from their talk at State of the Browser in 2024 asking the question: should there be a prefers-alt-text CSS feature?. Very much from the land of how-the-sausage-is-made and makes me twitch to want to have a crack myself (lol - if I ever had time).

What I came away with

Look, if you've been to even a handful you'll already know it's the people between the talks that makes it all worthwhile. It's always lovely when there's talks that give me a little shove towards tinkering with code, doubly so if it's a friend up on stage (new or old) giving the talk.

For the first time in a long while I attended the post-event parties (I tend to miss out on Brighton or London event parties because home calls). In doing so I had some really, really lovely conversations with different people (though landing myself chats finishing at 3am and 1am respectively 🤦).

As I sit in these events, I'm thinking about what I want from FFConf. A conundrum I face is that as I increasingly follow politics, the more I want to share what I learn about the world.

At some point during the last of the talks I realised actually what this web community is, is a microcosm of exactly the kind of progressive community that I identify with. A community that cares about representation, dignity for others, equality and sharing.

I've always known I was happier in (what I called) the hippy nation of webbies, but it makes me realise actually what we're doing in the corner of the world can be applied to how we conduct ourselves in the broader sense - and actually the politics I follow these days are very much aligned with the politics that I care about inside of the web community.

Originally published on Remy Sharp's b:log

I wasn't sure what I was getting in to reading Rivers of London (recommended multiple times on socials), especially as I kept finding the teens/young adult book cover for it (reminding me of the multiple covers the Harry Potter books had) - but I decided to jump in.

I quickly got sucked into the book and the narrative style that Aaronovitch used. For some reason I had Millie Bobby Brown as the voice which caused me a little confusion when I learn that the protagonist and narrator is called Peter Grant (I really didn't read the blurb) - but decided that she could still run the inner monologue.

The Rivers of London is a very London and British book (which I always especially enjoy because I can vividly see the places, hear the accents and usually feel the weather) that's a mix of modern copper plod story with fantastical (and certainly for me: original) characters from gods to vampires to ghosts and wizards.

There's a good balance of funny and witting against the (some times) gruesome and frankly pretty terribly bad things that make for the primary investigation for the protagonist, Grant, to work through.

Really fun stuff - I can definitely see myself returning for more in this series.

Originally published on Remy Sharp's b:log

In a project I'll often work on and move around different branches throughout the day, and as the years wear on it's rather dulled my memory - that's to say, I quickly forget what branch I was working on!

git recent

I created a git command line alias that helps my failing memory. What it does is list all the local branches, oldest to newest with the relative time and the name:

[alias]
  recent = !git for-each-ref --sort=committerdate --format='%(committerdate:relative) %(refname:short)' refs/heads/ | tail -10

It's a bit cumbersome with the !git part at the start, but it's because I want to limit it the most recent 10 results and I want it with the newest at the bottom.

$ git recent
3 weeks ago fix/ai-gen-docs
2 weeks ago feat/not-available-not-404
2 weeks ago fix/bulk-download-timeout
8 days ago fix/real-null-in-bulk
8 days ago fix/real-404
2 days ago feat/bulk-schema
2 days ago fix/transcript-endpoint-potential-null
2 days ago fix/sanitise-sql-input
21 hours ago main
20 hours ago feat/api-analytics

Memory win for me. Neato.

Originally published on Remy Sharp's b:log

Originally published on Remy Sharp's b:log

I accidentally read Dogs of War in 2018 - I never went looking for it and loved it. Equally, I can't remember when I found out about Bear Head but I knew I wanted to read it if it existed in the same universe. So finally I get around to it.

Overall well written, well drawn characters with distinctive voices in a universe that's really not that hard to conceive. I've read a few of Tchaikovsky's books now and as much as I enjoy them, for some reason it does take me quite a stretch to read the books (this one being just ~315 pages and took me a month) - not sure what's up with that.

The story is told from three protagonist's perspective: Honey, the bear from Dogs of War - once soldier, now an academic arguing for rights for others. Jimmy, the "grunt worker" placed on Mars to prepare it for the colonies that plan to settle and Carole (Springer…I want to say), the PA and "collared" assistant to the antagonist Warner S. Thompson.

Similarly with Dogs of War, Bear Head discusses self and identity (can a person be entirely digital?), freedom and slavery, and the untouchable super rich and their power.

There's some pretty horrible scenes around human slavery where people are compelled to perform, both involuntary physically but also compelled to think in certain ways (i.e. being submissive by design).

With a lot of what I'm reading lately, I can't help but associate it with today's real life events (in 2025-2026), and thinking of the corruption throughout politics we're seeing today - though I can see how this book being published in 2021 aligns fairly well with Trump's first regime from '17-21. Perhaps it's that backdrop that makes me a slow reader!

Originally published on Remy Sharp's b:log

Earlier today Jake asked me: what went wrong?

Fucking, everything.

TL;DR

I get it, this is a big wordy blog post. I got carried away and enjoyed telling the story.

The short version is: CloudFlare, probably best to upgrade everything to latest software (which I couldn't do), 520 status can actually be a mismatched TLS exchange between CloudFlare and the origin. Oh, and don't lean on LLMs too hard when the shit is really hitting the fan - try to take a big step back and make sure you take stock.

Otherwise, here's the too-long, do-read version -

On being in maintenance mode

For the last 5 ish/maybe quite a few years or more, JS Bin has run in a fairly automated maintenance mode. There's usually little flurries of wobbles that need my attention every 3/6 months. JS Bin is coming on to 18 years old, which is geriatric by web standards.

Typically it's dodgy content on the site that I need to put banning in place, sometimes it's take down requests that come through from Amazon (where JS Bin is hosted), sometimes it's a memory exception that takes me a little longer to recover from.

You can see from the last 11 years of status checks, there's been outages but nothing quite like what happened this time around (ignoring that big one on the far left…):

The larger hours when the server goes down (as I found out recently) is memory running out on the machine, and the machine will respond by pretty much collapsing. The result of which is that I can't connect to the machine via ssh to attempt restore it. It usually requires a forced reboot via the AWS console.

Then there's the odd occasion that even reboots from the AWS console, a literal "turn it on and off again", doesn't fly…

It wouldn't come back from a reboot

This latest outage just wouldn't come back from a reboot. I would trigger the reboot and then wait on the console attempting to connect over SSH so I could get some eyes on the situation but even then I couldn't get it.

JS Bin was rebooting and immediately locking up. So this tells me there's some external pressure on the machine that is not easing up.

The only option I have to hand is to shutdown the machine entirely for an hour or so, to let whatever is clawing at the door to go away for a bit.

When I eventually looked at the Cloud Watch logs, it was clear there was something absolutely smashing at the walls (and door, yes, I mix my metaphors). The amount of inbound network traffic is unprecedented for jsbin. From the chart below, it shows normal usage in the days prior, a trickle of network inbound traffic by comparison to what I was now seeing.

The dips that happen after the cliff edge of monitoring is the machine giving up and being unresponsive. From the chart, I can see that even the short outage wasn't enough to get this beast off jsbin's back.

Killing the appropriate process

When I finally managed to get into the machine, the first stop was syslog to find out what was responsible for the crash (or rather the symptom, not the cause, not yet).

I quickly found the garbage collection dump and stacktrace of node running out of memory. First thing's first: let's kill the offending process rather than having a full shit-the-bed approach.

# /etc/sysctl.conf and reload with `sudo sysctl -p`
vm.oom_kill_allocating_task=1

That would mean node (which was saturating all the memory) would be killed rather than anything the system could get it's hands on - which usually meant I couldn't ssh into the machine.

This change wouldn't stop things getting sluggish on the machine but it would mean that I could continue to diagnose even whilst the traffic was bombarding the server (albeit with a very slow terminal responding).

I could see the CPU usage was very, very high, and I could see node steadily increasing it's memory footprint (I use htop).

CPU usage of 100% is…okay because it means I'm using all the available process, but it leaves zero headroom and rather conspicuous that it wasn't dipping at any point.

Then chatgpt suggested upgrading node, which was weird because I'd never told Chatgpt what version of node I was running…

Side quest: node is really old

As with running in maintenance and things being in a status quo, I hadn't really touched node…at all.

As it happens, jsbin had been running on node 7 (not even "stable" node 8) for, I imagine, well over a decade.

To me, out of the blue, Chatgpt suggested I could upgrade node. This is a decent suggestion but at no point did I tell Chatgpt what version of node I was running.

On me querying, Chatgpt told me that I had told the AI which was a straight up lie.

After more prodding than I'd like, eventually it turned out that the version of node was in my terminal and at some point during the nginx tuning (in the next section), Chatgpt had helped itself to what was on the screen.

I've no idea if it has access to the scroll back history - I've got to assume it doesn't, but still pretty uncool.

I don't tend to use the "application" thing that Chatgpt has (I normally use the browser interface) but this definitely taught me a lesson: if there's sensitive data anywhere on the screen (ie. I had just cat an .env file) then it's entirely likely an LLM can see it too.

Anyway, I bumped from node 7 to node 22 and by some kind miracle it actually worked without any incident. It turned out that back in 2024 I had done some fairly significant work on the codebase so that I could run it on my local machine (which understandably didn't want to run node 7), so I had modernised the requisite parts.

Phew. At least the event loop is improved and going to be kinder on my CPU.

Except, it's still fucked and the adventure is far from over. Next I considered whether nginx (the proxy layer) could do with some optimisation.

Fine tuning on zip-all resources

Until now I've not shared what jsbin's main server runs on. It's a t2.micro AWS instance. Single CPU and 1GB of RAM. I'm often surprised it's managed so long on what I consider so little resources.

And yes, standing a beefier machine up (aka: throwing money at the problem) might help, but the time to reconfigure a new machine wasn't quick - I don't have an instant "build a new jsbin" script (remember, this server has been in maintenance for a long time and just happily running). It's also worth adding that although jsbin does has a "pro" offering, there's very little actual monetary resources. That's all to say: what can I do right now before creating a new machine (spoiler: I did make a new machine, and double-spoiler: it was terminated the following day as I didn't need it).

With the help of Chatgpt, Gemini and Claude (because somehow I have access to all of them, and I really don't have the full skills to know the ins and outs of nginx config) I looked at what could be tuned. I used multiple LLMs so that I could attempt to cross verify the advice (though I wasn't as diligent as I'd have liked).

The adjustments fell into these categories:

• workers spawned
• proxy timeout
• increase file descriptors
• keep alive timings
• remove http2 - to help with memory

Here's some of the actual config:

worker_connections 1024;
worker_processes auto;

keepalive_timeout 10;
keepalive_requests 100;

With the kicking I was getting from the inbound network traffic, this made little tangible difference. I'm sure it helps in the long run, but not when the machine is struggling with over 1000 requests a second and many more trying to squeeze in.

And then there was this:

Remy, have you considered CloudFlare?

I'd thought about add CloudFlare a few times in the past, but I was worried that the configuration adjustment and changes I'd need would be either complicated or would cause some other issue.

Except, nothing was working, so now was the time to get CloudFlare involved.

And so begin new problems…

Adding CloudFlare

Props where due, putting CloudFlare in front of JS Bin was relatively easy. CloudFlare detected most of the domains and where they pointed (the important ones at least) and it was a matter of swapping over the name servers from pointing to AWS's Route 53 to CloudFlare's own name servers.

Close to midnight on 29-Jan, I started to see jsbin.com load in the browser.

I thought there might be a few snags around, but quickly I got replies on github and via email that people were still (mostly) seeing errors.

In particular CloudFlare's 520 error page, which, as it turns out can be any number of issues.

Requests cutting through CloudFlare

Although I did have some success in loading, I could also see traffic still hammering through on the server.

With some help from our LLM overlords (i.e. I would have google'd it…"kagied it"?), I got the list of IP ranges that meant the traffic was from CloudFlare.

There was still a lot of traffic that didn't match those IP ranges. So the next step was to drop non-CloudFlare traffic.

This is where using the LLM cost me time via newly introduced problems (which wouldn't surface until the next day). I think I was too buried in the thick of things otherwise I might have caught it earlier (and not at the end of the process).

The first method to blocking non-CloudFlare was to use an nginx rule and variable, and to drop all traffic that wasn't tagged.

This would mean adding this line to each server {} block - this would say "If the request doesn't have the CloudFlare header, then don't let it through":

if ($http_cf_ray = "") {
    return 444;
}

Importantly there was more config directions that I followed (which I've tucked away, but you can read if you want), specifically set_real_ip_from 173.245.48.0/20; - this would trip me up later on.

/etc/nginx/cloudflare.conf

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

real_ip_header CF-Connecting-IP;
real_ip_recursive on;

http {
    include /etc/nginx/cloudflare.conf;
    ...
}

if ($http_cf_ray = "") {
    return 444;
}

This config was all well and good, but traffic was still coming in. This change would mean that nginx would have to process the traffic than ignoring (or "dropping") it entirely (#foreshadowing).

When I ran command below, it would list the connections, and I could still see non-CloudFlare requests being able to complete request (at this specific point in time, I was in a frantic cycle of "try a change - fail - worry a bit - ask LLM - repeat"):

ss -tan state established '( sport = :443 )'

The next change that I put in place was to drop the request if the IP didn't match the ones in the CloudFlare IP range (whereas before the change was looking for a CloudFlare specific header). Looking back as I write this, I'm not sure why the header method didn't work, but I was sure to add more petrol onto the fire:

geo $is_cloudflare {
    default 0;

    173.245.48.0/20    1;
    103.21.244.0/22    1;
    # etc
}

This flags if the remote address is a CloudFlare IP, set the $is_cloudflare=1. Then in my server blocks:

server {
    listen 443 ssl http2 default_server;
    if ($is_cloudflare = 0) { return 444; }
    if ($cf_valid = 0) { return 444; }

    # rest of config unchanged
}

What I didn't realise at this point, and took another 24 hours to figure out, is that the first CloudFlare nginx based change would say "if the IP is CloudFlare, then set the $remote_addr to the original request". Then this code says "if the IP is NOT CloudFlare don't let them through".

It's a mess. Now I've got reports from people on github telling me they're still seeing mostly 520 errors, and finally I realise I can replicate by using a VPN because for some reason it was still working for me.

There's two problems at this point:

1. Traffic still coming in that isn't through CloudFlare that's causing a drain on resources
2. Real users coming through CloudFlare are, mostly, not getting the site

Pretty much the worst of both worlds.

Finally, firewall rules spring to mind. Better late than never.

Dropping traffic

This was done on two fronts - just for belt-and-braces approach:

1. ufw (or as I knew it "iptables") rules one the server to DROP or ALLOW traffic based on IP range
2. AWS security policy to do the same.

Running the rules for ufw was relatively simple. A matter of allowing all the known IP ranges, then denying everything else:

$ ufw allow from 173.245.48.0/20 to any port 443
$ ufw allow from 103.21.244.0/22 to any port 443
$ # etc
$ ufw deny 443

Then repeated for port 80. I did get tripped up during testing when I wanted to allow my IP through, but that was solved with ufw status numbered and then ufw delete N.

Adding all the IP ranges on AWS was not so simple. The web UI just doesn't allow for large changes - it's very, very clunky.

Thankfully I could automate some of it from the command line and script the work. The annoying thing was that the AWS command line doesn't let me bulk modify (or at least I didn't find it) and each command takes a good few seconds to run and requires me to press enter after the response comes back saying it had worked.

This was the command:

for CIDR in \
   103.21.244.0/22 \
   103.22.200.0/22 \
   103.31.4.0/22 \
   # etc
do
   aws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 80  --cidr $CIDR --region us-east-1
   aws ec2 authorize-security-group-ingress --group-id $SG_ID --protocol tcp --port 443 --cidr $CIDR --region us-east-1
done

With those in place, finally the server was breathing again. However, those pesky CloudFlare 520s were still preventing people from visiting jsbin.com (except me…somehow…).

CloudFlare's 520

I naively thought 520 was like a 503 (the entire server is failing to respond to CloudFlare) or a 504 (gateway timeout - usually when node doesn't come back to nginx or CloudFlare), but it's not. It's more like "CloudFlare made a request and the response is incompatible".

The only real clue I had was that port 80, plain http wasn't affected. A helpful comment from @robobuljan showed that it was only the https version causing issues:

$ curl jsbin.com             # (works!)
$ curl http://jsbin.com      # (works!)
$ curl https://jsbin.com     # "error code: 520"

Although this digging took most of the day, it was the part that the LLMs really couldn't help with (and I had thankfully set them aside whilst I chewed on the meat of this problem).

As I looked for any clues. In the CloudFlare SSL/TLS page a section called "Traffic Served Over TLS" showed that there was a split in the supported TLS versions (I didn't capture a screenshot, but these numbers are from their API):

• TLSv1: 36 requests
• TLSv1.1: 56 requests
• TLSv1.2: 1,922,523 requests
• TLSv1.3: 5,216,795 requests

That's a lot on TLSv1.3, but I wondered how old (or actually new) v1.3 was given how old my rickety machine was. So I went back to my nginx config and found this line, repeated against each server block that ran SSL:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

A conspicuous lack of TLSv1.3, and I wondered what would happen if the user asked for 1.3, CloudFlare tottered off wanting 1.3 and then got back 1.2… or perhaps nothing at all.

I first tried to add TLSv1.3 to the list only for the nginx -t test to fail (the module wasn't installed and I couldn't get it without doing major upgrade work). So let's see if it can be turned off in CloudFlare.

The short answer is yes, but I struggled to find it.

The first place to confirm what's being support is the section under "Speed, Settings". But to completely turn it off, it's located in "SSL/TLS" then "Edge Certificates" and towards the end of the page.

Disabling this unlocked a lot more genuine traffic and we were cooking again. Almost, nearly. Again, for some, now the static assets weren't loading nor was the frame that actually live runs the authored code (the null.jsbin.com domain).

JS Bin was dropping some users

It took me a few more hours to solve this last step, and I'm still not entirely sure how it all hung together. But if you recall, earlier in my nginx config, I had told nginx that if the IP of the request was from CloudFlare that we should use set_real_ip_from.

This specific command was writing the original IP of the requesting user into the $remote_addr, which is what nginx was now using to drop requests with the return 444. Somehow this wasn't in the main server block (the part that returns the index page), but was somehow in the static.jsbin.com and null.jsbin.com.

This kind of confusion is the result of working late hours, and working in crisis mode. I should have known better and I'm great at dolling out advice but sometimes don't tend to heed it myself.

After I finally removed the janky checks, IP swapping and quite a bit of the cruft that I had introduced with my pal ChatGPT, this let the last of the traffic come through correctly.

JS Bin was back. Entirely.

The aftermath

Now that CloudFlare is in front of the server, life is surprisingly chill on this 1GB single CPU machine. Way more calm than a normal day of traffic. Look at that CPU usage!

I suspect if I hadn't leant on the LLMs so much during the scream-face-the-server-is-down moments, I might have caught the complexity that I was adding. Though equally I should have put CloudFlare in front of JS Bin years ago - and not at a time of crisis.

I definitely learnt a few gotchas, the TLS and 520 status codes are that for me.

The traffic has eased out from the AWS CloudWatch logs and I believe CloudFlare is now bouncing a lot of that away from me - and it seems like a lot of that is coming from Hong Kong (which I've set to have a JavaScript based check to get through CloudFlare):

Since I took that screenshot, Hong Kong has 10 million requests in the last 24 hours.

Even though I don't think I'll ever really know what caused the amount of traffic that caused everything to fall over, my gut suspects scrapers for AI and LLMs just slurping up as much of the web it can. The only evidence I have against that theory is that the traffic didn't come from a single IP.

Whereas, weirdly, I saw a single IP bot scraping this blog, accounting for over 3GB of data and over 325,000 requests in a matter of hours. Thankfully this was running on Netlify and is entirely static, and not running on node 7 🤦.

Originally published on Remy Sharp's b:log

Being an long-in-the-tooth old dog, I tend to learn and trick, and roll it out again and again typically without taking the time to find whether I still need the trick. Case and point, I learnt about the JavaScript performance trick of ~~1.4 === 1 to floor a value (and the same float | 0) but really these days it's not "faster" than doing it the legible way (i.e. Math.floor(1.4)).

Given I've had a bit of time away from the backend, here's an unorganised list of things I've found I can use, and thusly remove extra code that I no longer need.

The list

1. CSS: text-underline-offset - the distance I can set the text-underline-offset: 12px
2. CSS: gap - no more faffing with margins in flexbox.
3. CSS: nested media queries on selectors (and nesting general):

h1 {
  font-size: 1rem;
  @media (min-width: 600px) {
    font-size: 2rem;
  }
}

4. CSS: clamp(min, variable, max) - I used this extensively on FFConf 2025's css, the process of finding the right values is very much
5. CSS: content: open-quote can localised quotes and the q tag does this by default, via this neat insight from Stefan Judis
6. JS: catch without catching the variable, let's me get past the 'error' is defined but never used:

try {
  doTheDodgyStuff();
} catch {
  // nothing, it's fine
}

7. JS: pointer events have improved (though still from experience they're not 100% perfect) but are to replace the old double click & touch handlers nonsense as seen in the W3C spec
8. AVIF images are fully supported - I benefited from a train ride with Jake Archibald and in chatting I discovered AVIF are very well supported. This means easily getting 50% file size savings on JPEGs. I'm regularly running the avidenc command in directories:

ls *.jpg | xargs -P 8 -I {} avifenc -q 50 "{}" "{}".avif

So that's my little list.

Not even 10 things. I guess I've not learnt much yet, but even though I return to the server side of APIs in 2026, I'm sure I'll be kicking the tyres in the front again soon enough and adding to my measly list.

Originally published on Remy Sharp's b:log