Ben Silverman

Who will I be in 75 days?

Wed, 07 Jan 2026 00:00:00 GMT

If you're reading this after the 20th March, 2026, I'll be a completely different person...I think? Or maybe I'll be me, but better? Or the same person in almost every day but very slightly different in one extremely important but equally intangible factor? Who knows!

To elaborate, my girlfriend and I (and a friend of ours) will be attempting 75 Soft this year, and I'm interested and excited to see what we're like once we're out the other end. For those who don't know, 75 Soft is a "self-improvement challenge" where, for a period of 75 days (what a coincidence), you do your best to follow this set of rules:

Eat well, and avoid alcohol outside of social situations.
Exercise once for 45 minutes a day, with one day of "active recovery" each week.
Drink 3 litres of water a day.
Read 10 pages of any book, every day.

Unlike 75 Hard—the challenge this challenge is based off—you don't have to start from zero if you lose your progress (and the rules aren't quite as over the top, in my opinion), so I'm confident that we'll at least reach the end. It's an added bonus we can do it without missing any days!

The rules are, helpfully, left slightly vague, and they allow you to attach your own, more specific goals to them, which I really like. This is what we've all agreed on:

🍱 Eat well

For my girlfriend and I, this means cooking at home whenever possible and reducing the amount times we eat out or get takeaway. I wouldn't say we do this a lot at the moment, but it's an expensive habit to have in London and we often don't even feel like it was money well spent after the fact, anyway. Committing to cooking more at home will almost certainly help us eat healthier and will definitely help out our wallets. We don't really drink alcohol at home, anyway, so that part won't be hard.

🏃‍♂️ Exercise once a day

I used to be quite good at exercising regularly. I completed Couch to 5k in the first half of 2024 and managed to keep a consistent habit through most of 2025 but was unfortunately thwarted due to winter (cold) and injuries (ouch). My plan is to alternate running and gym workouts to hopefully strengthen the muscles involved and ensure I can keep up the level of activity for the entire 2.5-month period. We've also agreed that 10,000 steps in a day is a worth substitute if we aren't able to "properly" exercise for whatever reason.

🚰 Drink 3 litres of water a day

Not much here to say. I downloaded an app to help me track how much water I've had. Fortunately, tea and coffee also count!

📖 Read 10 pages a day

I already read basically every day so this isn't much of an additional to my daily routine. I will be reading Dust of Dreams by Steven Erikson, and I've actually being a little naughty and committed to 17 pages (😱) a day so that the end of the book will nicely coincide with the end of 75 Soft. It's definitely been a goal of mine to read more each day, so I'm really happy this is part of the challenge.

I'm not really sure what to expect from this challenge, to be honest. I don't believe it'll be a silver bullet, life-changing experience that will somehow catapult me into the annals of greatness, but I definitely think I'll feel proud to have completed it, and hopefully will have strengthened some healthy habits along the way.

I remember feeling insanely proud when I completed Couch to 5k. There was no need for me to start it, other than a feeling that I wanted to, and there was no goal for me other than to complete it. And sometimes that's enough. We set ourselves arbitrary goals that we can work towards, and then we feel accomplished when we reach them!

So with all this said, expect a follow-up in March!

I sense another rewrite coming on

Mon, 03 Aug 2026 00:00:00 GMT

Feeling the itch to redo my website again. I’ve been getting increasingly interested in the whole IndieWeb thing and like the idea of really making this the home for all of my Stuff. I already have a page for the movies I’ve watched (see if you can find it) but that data still originates over on Letterboxd. The biggest problem I have with the whole POSSE (Publish on your Own Site, Syndicate Elsewhere) is that Letterboxd’s UI for writing my reviews, and reading others’, is just sooo much nicer. Unless you really lean in to all the ATProto things and shift your entire online self there (and convince everyone you care about to do so, too) then you’re kind of stuck using these third party services.

There is an alternative acronym, PESOS, which is basically the same words but rearranged, and essentially amounts to taking a backup of your content and storing it on your own site. That’s what I do with my Letterboxd right now, with a terribly manual process involving exporting huge CSVs of all of my data every whenever-I-remember. There’s an RSS feed of my data I should probably hook up, actually, which might make this nicer to automate.

I still haven’t found anything super great for tracking what books I’ve read. Everyone’s on Goodreads but I don’t like the Amazon association and also their app is actually quite ugly! I’m actually trying something an app called Margins right now but it may not last, given there’s no web version, nor an easy way to get my data out of the app.

I think what is ultimately like is a way to write stuff on this website without it being a whole Thing, and for the stuff I write to be a bit more mixed in with the stuff I read, the stuff I watch, and the stuff I play. It could be fun to just have everything here and automatically synced from the other services I use.

Advent of Code 2025 - Day 1

Mon, 01 Dec 2025 00:00:00 GMT

Advent of Code is nearly over for this year and I thought I would try and do some quick write-ups of my solutions, mainly as a bit of fun and to help me improve my writing a little bit. So far it's been quite a good level of difficulty, with nothing outstandingly horrendous, but a few which have been challenging. I don't know whether the plan is to scale Days 1-12 in such a way that Day 12 is as difficult as Day 25 would've been in previous years. It'll probably be similar?

Day 1

Read the full prompt.

Part 1

Quite a straightforward task: simulate a rotating dial on a safe, and count up how many times the dial lands at position 0 after each turn.

Just increment or decrement rot depending on the input line, and mod it to keep it within the 0-99 range specified.

const input = await readInput().then((data) =>
	Array.from(data.join("\n").matchAll(ROTATON_REGEX))
);

function partOne() {
	let rot = 50;
	let answer = 0;

	for (const [, direction, amount] of input) {
		switch (direction) {
			case "L": {
				rot = mod(rot - Number(amount), 100);
				break;
			}
			case "R": {
				rot = mod(rot + Number(amount), 100);
			}
		}

		if (rot === 0) answer += 1;
	}

	return answer;
}

It's super fun that you actually need to write a custom mod function instead of just using %, like in a language like Python. This is because the % operator in JavaScript doesn't actually calculate the modulus of a number, but returns the remainder instead, so something like -3 % 4 will actually return -3 instead of the 1 that we want.

Here's a function you can use to get mods how you want them:

const mod = (n: number, m: number) =>  ((n % m) + m) % m;

Part 2

Part 2 is a little bit more involved, and asks that you calculate the number of times the dial passes 0, not just landing on it. I opted for the lazy approach and essentially just broke down my input into lots of single-step "left" and "right" turns. By doing this, you can basically then solve the problem the same as in Part 1.

function partTwo() {
	let rot = 50;
	let answer = 0;

	for (const [, direction, amount] of input) {
		switch (direction) {
			case "L": {
				for (let i = 0; i < Number(amount); i++) {
					rot = mod(rot - 1, 100);

					if (rot === 0) answer += 1;
				}

				break;
			}
			case "R": {
				for (let i = 0; i < Number(amount); i++) {
					rot = mod(rot + 1, 100);

					if (rot === 0) answer += 1;
				}
			}
		}
	}

	return answer;
}

It's not very fast—about 4x slower than my Part 1 solution—but it's very easy to implement. A better approach would probably be to look at where you land after the movement and work out whether you would've had to pass 0 to get there.

Benchmarks

clk: ~3.07 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1:                      121.41 µs/iter 121.00 µs  █                   
                    (117.79 µs … 224.92 µs) 146.00 µs  █▄                  
                    ( 32.00  b … 227.59 kb) 923.38  b ▂██▅▃▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁

Part 2:                        5.21 ms/iter   5.24 ms   ▄▂█    ▂           
                        (5.13 ms … 5.42 ms)   5.35 ms  ▆███▃   █           
                    (504.00  b … 504.00  b) 504.00  b ▅██████▆▇██▇▄█▆▅▄▅▂▂▄

Advent of Code 2025 - Day 10

Wed, 10 Dec 2025 00:00:00 GMT

A bit of linear programming on my birthday, how lovely!

Read the full prompt.

Part 1

My idea for solving Part 1 was to represent the lights as a Set of numbers, and then use the use newly available symmetricDifference method to toggle the lights on and off. Doing setA.symmetricDifference(setB) will return numbers which are in either setA or setB, but not both. So for a set of lights lights := {1, 3, 4} we can turn off lights 1 and 4, and switch on light 2 by doing lights.symmetricDifference({1, 2, 4}) (this isn't real JS notation but you get the picture).

The next thing I did was write a combinations generator to gradually yield all of the possible combinations of button presses. One thing to note is we don't need to think about any combinations containing multiple of the same button wiring schematic, because they will effectively "cancel out" and can either be represented by a single occurrence, or zero occurrences (e.g. the symmetric difference between {1, 2} and {1, 2} is an empty set, which is the same as never having toggled those lights in the first place).

So let's generate all of the combinations of our available button press schematics, from the smallest combination (i.e. 1) to the largest, and break when we find a combination that leads to all of the lights being on.

Part 2

Suddenly these buttons start incrementing counters on a different machine instead, and we have to also make sure these counters hit their required values too. It's a lot trickier and will require a different approach.

If you're smarter than me you'll probably very quickly recognise this as a Linear Programming question. I might revisit and write out an explanation in full (partly for my own benefit) but the gist is that we can represent the system of button presses as a matrix and the counter values as a vector, and then do some Maths to it to have it tell us what the minimum number of button presses required to hit the desired counter values is.

I opted to use a Linear Programming library to "solve this for me", which might be considered cheating by some people but I'm not sure I mind too much. That's what tools and libraries are made for in the first place, right?

Benchmark

clk: ~3.03 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1                        21.99 ms/iter  22.10 ms  █▂▂ ▂    ▂          
                      (21.75 ms … 22.61 ms)  22.44 ms  ███▅█  ▅ █     ▅    
                    ( 10.96 mb …  11.07 mb)  11.00 mb ▇█████▁▇█▁█▇▁▁▇▁█▁▁▁▇

Part 2                         1.55 ms/iter   1.56 ms  █                   
                        (1.35 ms … 2.41 ms)   2.17 ms ▂█▄                  
                    (  1.50 mb …   4.35 mb)   3.31 mb ███▅▃▃▂▁▁▁▁▁▂▃▃▃▄▂▃▂▁

Advent of Code 2025 - Day 11

Thu, 11 Dec 2025 00:00:00 GMT

Finally some more graph traversal!

Read the full prompt.

Part 1

Simple breadth-first search for Part 1. We want to know how many routes are possible to get from the start to the finish.

function partOne() {
	const paths = [];

	const queue: Array<Array<string>> = [["you"]];

	while (queue.length > 0) {
		const path = queue.shift()!;
		const node = path[path.length - 1];

		if (node === "out") {
			paths.push(path);
			continue;
		}

		const children = nodes.get(node);

		for (const child of children ?? []) {
			queue.push([...path, child]);
		}
	}

	return paths.length;
}

Part 2

In Part 2, we start from svr instead of you and there are so many more potential paths that could be visited. We are also only interested in the paths that pass through dac and fft, too, so a bit of added complication there.

There will be many moments where we are traversing from the same point over and over again, so let's introduce some memoization to cache the number of valid routes (i.e. passing through dac and fft) from a given point to the finish so we can reuse the value the next time we see it.

function partTwo(): number {
	const countPaths = memoize(
		(here: string, dac: boolean, fft: boolean): number => {
			let dacVisited = dac;
			let fftVisited = fft;

			switch (here) {
				case "out":
					return Number(dac && fft);
				case "dac":
					dacVisited = true;
					break;
				case "fft":
					fftVisited = true;
					break;
			}

			const result = Array.from(nodes.get(here) ?? []).reduce(
				(total, v) => total + countPaths(v, dacVisited, fftVisited),
				0
			);

			return result;
		}
	);

	return countPaths("svr", false, false);
}

Once we see that we're at out we can return Number(dac && fft) so the route only counts towards the total number of valid routes if both required points have been visited. Otherwise, the route will be a 0 and not count towards the total.

Benchmark

clk: ~3.03 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1                        21.99 ms/iter  22.10 ms  █▂▂ ▂    ▂          
                      (21.75 ms … 22.61 ms)  22.44 ms  ███▅█  ▅ █     ▅    
                    ( 10.96 mb …  11.07 mb)  11.00 mb ▇█████▁▇█▁█▇▁▁▇▁█▁▁▁▇

Part 2                         1.55 ms/iter   1.56 ms  █                   
                        (1.35 ms … 2.41 ms)   2.17 ms ▂█▄                  
                    (  1.50 mb …   4.35 mb)   3.31 mb ███▅▃▃▂▁▁▁▁▁▂▃▃▃▄▂▃▂▁

Advent of Code 2025 - Day 2

Tue, 02 Dec 2025 00:00:00 GMT

Thank god I know how to regex...otherwise this would've been painful.

Read the full prompt.

Part 1

Part 1 of Day 2 asks for us to take an interval and calculate how many numbers within that interval are made up of some sequence of digits repeated exactly twice (e.g. 11 and 22 in the range 11-22)

import { bench, run } from "mitata";
import { readInput } from "../utils";

const P1_REGEX = /^(\d+)\1$/;

const input = await readInput();

const ranges = input
	.at(0)
	.split(",")
	.map((r) => r.split("-").map(Number));

let partOne = 0;

for (const [start, end] of ranges) {
	for (let i = start; i <= end; i++) {
		if (P1_REGEX.test(i.toString())) partOne += i;
	}
}

The star of this solution is the regex, ^(\d+)\1$, which does the following:

^ - matches the beginning of the string
(\d+) - creates a "capture group" around one or more digit characters
\1 - is a "back reference" to the first capture group we created
$ - matches the end of the string

Using ^ and $ ensure we don't match any substrings containing repeating sequences of digits (e.g. 123231)!

Part 2

The problem statement then changes very slightly for Part 2, and instead asks us to find all of the numbers within a given interval which are made up of a sequence of digits that repeats at least twice (e.g. 343434, 1111).

This would be really horrible, if not for that fact that we can reuse basically all of our Part 1 solution just by changing the regex slightly.

✨ ^(\d+)\1$ becomes ^(\d+)\1+$ ✨

With this new regex we can create the capture group and then match strings with one or more of the back references, instead of exactly one.

Benchmark

clk: ~2.93 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1 & 2                   266.81 ms/iter 264.07 ms  ▂█                  
                    (262.53 ms … 292.19 ms) 274.98 ms ▅██                  
                    (  1.02 mb …  16.50 mb)   8.06 mb ███▇▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▇

I haven't tried this out yet but you could write this same test using purely mathematical operations instead of a regex and it might be faster? Something like this:

function testNumber(n: number): boolean {
	const numDigits = Math.floor(Math.log10(n) + 1);

	// Needs to have an even number of digits to split cleanly.
	if (numDigits % 2 !== 0) return false;

	const firstHalf = Math.floor(n / Math.pow(10, numDigits / 2))
	const secondHalf = n % Math.pow(10, numDigits / 2)

	return firstHalf === secondHalf
}

Advent of Code 2025 - Day 3

Wed, 03 Dec 2025 00:00:00 GMT

An appearance from the Duracell Bunny today, as we compare batteries!

Read the full prompt.

Part 1

My approach for today was to split up each line of input into an array of digits and then scan through each array, gradually selecting the next largest number available to produce the greatest final result.

We store the indices of each largest digit of the number to allow us to skip over sections of the bank and not waste time searching batteries which wouldn't be valid anyway. Given we know the number of batteries that need to be switched on at the end—parameter n in our function—we can also cut off the search early to ensure there are enough batteries left over for the next spots in the bank.

For example, given a bank of 10 batteries where we want to switch on 6 to make the highest number, we know that we can't search any further than index 4 for the first battery, because the remaining 5 batteries in the bank would all then need to be switched on.

             b1 b2 b3 b4 b5 b6 
             ↓
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

function partOne() {
	return input.reduce(
		(total, bank) => total + findLargestJoltageForNBatteries(bank, 2),
		0
	);
}

function findLargestJoltageForNBatteries(
	bank: Array<number>,
	n: number
): number {
	const array: number[] = [];

	for (let i = 0; i < n; i++) {
		const prevIndex = i === 0 ? 0 : array[i - 1] + 1;

		array.push(maxIndex(bank, prevIndex, bank.length - (n - (i + 1))));
	}

	return array.reduce((acc, val) => 10 * acc + bank[val], 0);
}

function maxIndex(array: Array<number>, start: number, end: number): number {
	let m = start;

	for (let i = start; i < end; i++) {
		if (array[i] > array[m]) m = i;
	}

	return m;
}

Part 2

We're just doing the same thing here, but looking for 12 digits instead of just 2.

function partTwo() {
	return input.reduce(
		(total, bank) => total + findLargestJoltageForNBatteries(bank, 12),
		0
	);
}

Benchmark

clk: ~3.03 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1                        43.91 µs/iter  43.54 µs  █                   
                     (42.29 µs … 267.50 µs)  55.13 µs ▂█                   
                    (  2.43 kb … 262.59 kb)  42.15 kb ███▄▃▃▂▂▁▁▁▁▁▁▁▁▁▁▁▁▁

Part 2                        84.91 µs/iter  84.08 µs  █                   
                     (80.50 µs … 950.75 µs) 120.00 µs ▂█                   
                    (  6.71 kb … 220.11 kb)  37.54 kb ███▄▂▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁

One thing I wondered about while writing this was how these benchmarks might scale in relation to the number of batteries that need to be switched on. As the number of batteries being switched on approaches the total number of batteries in the bank, the number of actual searches we can do should reduce because there are fewer numbers that are possible within the "space". For example, if we have a battery bank of 10 batteries and we want to switch on all 10, there's only one possible order in which they can be switched on (given the constraint that the order of the batteries can't change).

But that's not what I see when I benchmark my code. Our AoC input consists of a list of numbers with 100 digits, so we can benchmark all the way up to that amount and get the following graph:

------------------------------------------- -------------------------------
1                             68.69 µs/iter  68.42 µs █                    
                     (66.96 µs … 277.21 µs)  83.79 µs █ ▃                  
                    ( 23.09 kb … 333.22 kb)  52.02 kb █▅█▂▃▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁

8                            202.71 µs/iter 201.58 µs █                    
                    (199.88 µs … 407.21 µs) 243.08 µs █▃                   
                    (106.38 kb … 543.90 kb) 106.85 kb ██▅▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁

64                           460.29 µs/iter 452.46 µs █                    
                    (447.33 µs … 743.17 µs) 576.17 µs █▂                   
                    (852.63 kb …   1.51 mb)   1.24 mb ██▃▂▁▁▁▁▁▁▁▁▁▁▂▂▂▁▁▁▁

100                          608.57 µs/iter 597.13 µs █                    
                    (588.54 µs … 813.67 µs) 721.88 µs █▇                   
                    (  2.31 mb …   2.31 mb)   2.31 mb ██▂▂▂▁▁▁▁▁▁▁▁▁▃▄▂▁▁▁▁

                             ┌                                            ┐
                        $num                                           ⡠⠔⠊ 608.57 µs
                                                                   ⢀⠤⠒⠉   
                                                                ⣀⠔⠊⠁      
                                                            ⢀⡠⠒⠉          
                                                          ⡠⠊⠁             
                                                        ⡠⠊                
                                                      ⡠⠊                  
                                                    ⡠⠊                    
                                                  ⢀⠜                      
                                                ⢀⠔⠁                       
                                              ⢀⠔⠁                         
                                            ⢀⠔⠁                           
                                        ⢀⡠⠔⠊⠁                             
                                     ⣀⠤⠒⠁                                 
                                 ⢀⡠⠒⠉                                     
                              ⡠⠔⠊⠁                                         68.69 µs
                             └                                            ┘

summary
  1
   2.95x faster than 8
   6.7x faster than 64
   8.86x faster than 100

The time taken to run seems to scale linearly with the number of batteries being switched on, which is not what I expected. Something to think about...

Advent of Code 2025 - Day 4

Thu, 04 Dec 2025 00:00:00 GMT

Toilet paper meets Sokoban...sort of. We have to look through all of the rolls of toilet paper on a grid and work out which can be removed, which will be when there are fewer than 4 rolls of toilet paper in the adjacent positions around each roll.

Read the full prompt.

Part 1

I didn't really have any clever solution for this. I just iterated through each roll in the grid and counted how many adjacent spaces to it contained a roll, and incremented my answer if that value < 4.

function partOne() {
	const grid = new Grid(input);

	let answer = 0;

	for (const [pos, val] of grid.points.entries()) {
		if (val !== "@") continue;

		const [y, x] = pos.split(",").map(Number);

		let nearbyRolls = 0;

		for (const dy of [-1, 0, 1]) {
			for (const dx of [-1, 0, 1]) {
				if (dy === 0 && dx === 0) continue;

				if (grid.get(y + dy, x + dx) === "@") {
					nearbyRolls += 1;
				}
			}
		}

		if (nearbyRolls < 4) {
			answer += 1;
		}
	}

	return answer;
}

I was able to use my custom Grid helper from last year, which was nice. All it really does it parse the input into a Map of points that can then be queried. There are some benefits to this, like not running into errors when accessed nested arrays that might be out of bounds—the Grid will just return undefined instead.

It sucks having to format the keys as strings, though. In an ideal world you could use something like a tuple, but JavaScript doesn't have those and you can't use an array as a key because it's added as a reference, which means you can't construct these keys on the fly...something you might want to do if you need to, say, check all of the adjacent points to a coordinate.

Part 2

I also didn't do anything clever for Part 2. I fancied my luck just bruteforcing through to the end and it turned out to be enough, so I was happy to stop there. We can basically just wrap the Part 1 solution in a big ol' do/while loop and repeat until there are no rolls left on the grid. It's not very pretty but it's also not very fast!

Benchmark

clk: ~3.01 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1                        10.75 ms/iter  10.83 ms       █              
                      (10.10 ms … 12.59 ms)  12.09 ms  ▃   ▂█▇             
                    (  1.76 mb …  11.96 mb)  11.41 mb ▇█▂▄▂███▅▅▁▁▁▂▂▂▂▂▁▂▂

Part 2                       288.44 ms/iter 292.85 ms █   █                
                    (279.43 ms … 307.79 ms) 299.67 ms █▅▅ █▅    ▅  ▅     ▅▅
                    ( 14.39 mb …  14.39 mb)  14.39 mb ███▁██▁▁▁▁█▁▁█▁▁▁▁▁██

Advent of Code 2025 - Day 5

Fri, 05 Dec 2025 00:00:00 GMT

Ingredient management! We need to figure out which ingredients are fresh, and which aren't.

Read the full prompt.

Part 1

It's easy enough to write a bruteforce solution for Part 1 and check every ingredient to see if it lies within one of the given ranges of fresh ingredients.

const freshRanges = ranges.map<Range>(r => { const [lower, upper] = r.split("-").map(Number); return { lower, upper } });

function partOne() {
	let answer = 0;

	for (const ing of ingredients) {
		for (const r of freshRanges) {
			if (Number(ing) >= r.lower && Number(ing) <= r.upper) {
				answer += 1
				break;
			}
		}
	}

	return answer
}

Part 2

Now the challenge shifts slightly: rather than checking which of our ingredients are fresh, we have to look at all of our ranges and work out the total number of ingredients that are considered "fresh".

I also initially tried to bruteforce this and just iterate through each range, adding the ingredients to a set along the way. The idea is that, by the end of the final ingredient range, the set has collected every fresh ingredient exactly once and we can use the size of the set as our answer.

Obviously, it wasn't that simple, though. It turns out that these ranges are quite big and you very quickly exceed the set's maximum size.

Oops...

The approach I went for after this was to sort the ranges in ascending order by their starting value, and then iterate through the list of ranges and increment my final answer by range.upper - range.lower. We can use a "pointer" of sorts to keep track of the highest value seen so far, and use it in that calculation to resolve any overlaps.

function partTwo() {
	let answer = 0;
	let curr = 0;

	for (const range of sortedRanges) {
		let start = Math.max(range.lower, curr + 1);
		answer += Math.max(0, range.upper - start + 1);
		curr = Math.max(curr, range.upper);
	}

	return answer;
}

Ooh, a drawing! After counting the first range (1-4) the curr pointer will be at 4, so we start from there and calculate 8 - 4 to skip the overlap and count the remaining numbers in the second range.

Benchmark

Don't you love when Part 2 runs faster than Part 1 🙈

clk: ~3.11 GHz
cpu: Apple M1 Pro
runtime: node 20.17.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1                         8.32 ms/iter   8.35 ms  █                   
                        (8.22 ms … 8.80 ms)   8.68 ms ▃█▃                  
                    (  2.74 mb …   2.74 mb)   2.74 mb ███▅▅▄▃▅▃▃▁▁▂▃▂▃▁▁▁▂▃

Part 2                       249.24 ns/iter 249.21 ns  █                   
                    (246.82 ns … 310.57 ns) 271.93 ns ▆█                   
                    (  4.17  b … 972.03  b)   6.59  b ██▇▄▄▂▂▁▁▁▁▁▁▁▁▁▁▁▁▁▁

Advent of Code 2025 - Day 6

Sat, 06 Dec 2025 00:00:00 GMT

Oh how I envy Python's zip() function...

Read the full prompt.

Part 1

I think today's trickiness was mainly from figuring out what the question wanted you to do, and how it code something that Did It Correctly.

Unfortunately, JS doesn't have a great standard library of array functions for stuff like this, so I resorted to writing my own transpose() function and using it to swap the rows and the columns of my input.

function transpose(matrix: number[][]): number[][] {
	const rows = matrix.length;

	const cols = matrix[0].length;
	const grid: number[][] = [];

	for (let j = 0; j < cols; j++) {
		grid.push([]);
		for (let i = 0; i < rows; i++) {
			grid[j].push(matrix[i][j]);
		}
	}

	return grid;
}

We can then reduce down our list of columns, combining each one using the operator that's provided—adding or multiplying—and sum everything up to get our final answer!

const funcMap: Record<string, (a: number, b: number) => number> = {
	"+": (a: number, b: number) => a + b,
	"*": (a: number, b: number) => a * b,
};

function partOne() {
	const rows = input
		.slice(0, -1)
		.map((row) => row.trim().split(/\s+/).map(Number));

	const ops = input.at(-1)!.trim().split(/\s+/);

	return transpose(rows).reduce(
		(acc, row, i) => acc + row.reduce(funcMap[ops[i]]),
		0
	);
}

Part 2

Unfortunately I couldn't use that same transpose function for the second part of Day 6. We still need to process the groups of numbers in their columns, but now we also need to read the numbers in right-to-left, and in columns.

So something like...

...would be 356 + 24 + 1 = 381.

I opted to do a single scan from right to left of the entire input and process the columns as I went. We can create a temporary list of items by reading in all of the characters from a given column of input. Eventually we will see a character like + or *, too, and can store that as the operator needed for the calculation. And then, when we read in an entire column of empty strings, we know we've fully processed a single "group" of numbers and can add that to the final answer.

function partTwo() {
	const numCols = input[0].length;
	const numRows = input.length;

	const transposedInput: number[][] = [[]];
	const ops: string[] = [];

	for (let i = 0; i < numCols; i++) {
		const items = [];

		for (let j = 0; j < numRows; j++) {
			items.unshift(input[j][i]);
		}

		const [op, ...nums] = items;

		const num = nums.toReversed().join("").trim();

		if (num.length === 0) {
			transposedInput.push([]);
			continue;
		}

		if (op !== " ") {
			ops.push(op);
		}

		transposedInput.at(-1)!.push(Number(num));
	}

	return transposedInput.reduce(
		(acc, nums, i) => acc + nums.reduce(funcMap[ops[i]]),
		0
	);
}

Benchmark

clk: ~3.00 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1                       293.36 µs/iter 295.63 µs █                    
                    (275.21 µs … 557.38 µs) 441.21 µs █▅▅                  
                    ( 54.63 kb …   1.19 mb) 532.01 kb ████▄▂▁▂▂▁▁▁▁▁▁▁▁▁▁▁▁

Part 2                       893.25 µs/iter 888.83 µs █                    
                      (860.92 µs … 1.26 ms)   1.09 ms █                    
                    (  1.25 mb …   3.01 mb)   2.11 mb ██▆▃▂▂▂▁▁▂▂▂▂▂▂▁▁▁▁▁▁

Advent of Code 2025 - Day 7

Sun, 07 Dec 2025 00:00:00 GMT

I think this was my favourite day of Advent of Code this year. Very interesting puzzle with some super satisfying solutions once you give it a bit of thought (or a lot of thought, in my case).

Read the full prompt.

Part 1

So we've got a beam that's being fired down through a Christmas tree-shaped structure of "beam splitters" and we need to count how many times the beam gets split as it makes its way down the grid.

I simulated the beam's journey down through the grid, line by line, by checking the character at each square of the grid and modifying the characters on the next line ("below" it) depending on whether it was a beam (|) or a splitter (^). Every time we hit a splitter we can increment a counter that tracks our final answer.

function partOne(input: string[]) {
	const grid: (string | number)[][] = input.map((row) => row.split(""));
	const startX = grid[0].indexOf("S");

	grid[1][startX] = "|";

	let partOne = 0;

	for (const [j, row] of grid.slice(0, -1).entries()) {
		for (const [i, char] of row.entries()) {
			if (char !== "|") continue;

			if (grid[j + 1][i] === "^") {
				grid[j + 1][i - 1] = "|";
				grid[j + 1][i + 1] = "|";

				partOne += 1;
			} else {
				grid[j + 1][i] = "|";
			}
		}
	}

	grid[1][startX] = 1;

	return [partOne, grid] as const;
}

I don't think it was strictly necessary to simulate like this, and I probably could've stored the coordinates of the splitters and the beam positions, but this was easier (and more fun!) to visualise in my head. It also means we get a lovely visualisation by the end!

.......S.......
.......|.......
......|^|......
......|.|......
.....|^|^|.....
.....|.|.|.....
....|^|^|^|....
....|.|.|.|....
...|^|^|||^|...
...|.|.|||.|...
..|^|^|||^|^|..
..|.|.|||.|.|..
.|^|||^||.||^|.
.|.|||.||.||.|.
|^|^|^|^|^|||^|
|.|.|.|.|.|||.|

This then leads us very nicely into Part 2...

Part 2

The instructions for Part 2 were a little confusing to understand at first, but it boils down to "how many possible paths are there for a beam to take through this tree". If you think about it, every time a beam hits a splitter it essentially creates two copies of itself, either side of the splitter, which continue on downwards. Those positions either side of the splitter could also have beams arriving from directly above, or from the opposite side if there are two splitters next to each other. This is the perfect opportunity for some DP (Dynamic Programming 🤨), and also let's us use the result from Part 1, since it effectively represents all of the possible paths the beam can take.

The idea is to work downwards through the grid and add together the number of possible paths from above at each point, to track, by the end, the total number of possible paths that could've been taken by the beam. It took my quite a while to figure this out and properly understand it but I think it's so cool that you can do this and it really doesn't take too long to compute, either!

I don't know if I explained that very well so here's a diagram that maybe illustrates it better.

.....1^2^1.....
.....1.2.1.....
....1^3^3^1....  <-- there are three ways to reach the two positions in the middle here
....1.3.3.1....

I don't know if that diagram explained that very well so here's the actual code and maybe that will illustrate it better.

function partTwo(grid: (string | number)[][]) {
	for (const [j, row] of grid.entries()) {
		for (const [i, char] of row.entries()) {
			if (char !== "|") continue;

			grid[j][i] = getPointValue(grid, j - 1, i);

			if (grid[j][i - 1] === "^") {
				grid[j][i] += getPointValue(grid, j - 1, i - 1);
			}

			if (grid[j][i + 1] === "^") {
				grid[j][i] += getPointValue(grid, j - 1, i + 1);
			}
		}
	}

	return grid
		.at(-1)
		?.filter((n) => typeof n === "number")
		.reduce((acc, val) => acc + val);
}

function getPointValue(
	grid: (string | number)[][],
	y: number,
	x: number
): number {
	return typeof grid[y][x] === "string" ? 0 : grid[y][x];
}

Benchmark

clk: ~3.00 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1                       293.36 µs/iter 295.63 µs █                    
                    (275.21 µs … 557.38 µs) 441.21 µs █▅▅                  
                    ( 54.63 kb …   1.19 mb) 532.01 kb ████▄▂▁▂▂▁▁▁▁▁▁▁▁▁▁▁▁

Part 2                       893.25 µs/iter 888.83 µs █                    
                      (860.92 µs … 1.26 ms)   1.09 ms █                    
                    (  1.25 mb …   3.01 mb)   2.11 mb ██▆▃▂▂▂▁▁▂▂▂▂▂▂▁▁▁▁▁▁

Advent of Code 2025 - Day 8

Mon, 08 Dec 2025 00:00:00 GMT

Coincidentally, also the day I put my own Christmas lights up!

Read the full prompt.

Part 1 & 2

I'll cover both parts at the same time today because you basically just need to do the same thing for each, but Part 2 requires you to do it for longer.

To summarise today's problem, you're given a list of Christmas light IDs, and a map of which lights connect to which. When you connect two lights together, they form a circuit. If two lights are already in a circuit when you connect them, the two circuits merge.

Straight away my mind started thinking about sets and unioning them together. We just need to do this over and over again, deleting old circuits once they've been connected together. We can track how many times we do this, and print out our answer for Part 1, then continue until there's only one circuit left, at which point with have our Part 2 answer :)

You can view the full solution on my GitHub, because it's quite long to post here, but the main part is:

for (const c of circuits) {
	if (c.has(a)) aCircuit = c;
	if (c.has(b)) bCircuit = c;
}

circuits.delete(aCircuit!);
circuits.delete(bCircuit!);

circuits.add(aCircuit!.union(bCircuit!));

This finds the circuits that contain the two lights (a and b) which need to be merged, then combines them together into one mega-circuit and deletes the two smaller circuits.

Benchmark

clk: ~2.93 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Part 1 & 2                    14.72 µs/iter  14.42 µs   █                  
                       (12.79 µs … 1.17 ms)  20.83 µs   █▇▂                
                    (656.00  b … 152.39 kb)  23.00 kb ▁▆███▅▂▂▂▂▂▂▂▂▁▁▁▁▁▁▁

This is a bit misleading, because it's actually much slower if we include the time taken to sort all the points by their distance from each other :^)

clk: ~3.02 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                     avg (min … max) p75 / p99    (min … top 1%)
--------------------------------------------- -------------------------------
Part 1 & 2 (+sorting)          542.97 ms/iter 543.80 ms     █                
                      (536.48 ms … 567.32 ms) 545.21 ms ▅   █▅ ▅  ▅▅▅    ▅▅ ▅
                      ( 13.67 mb …  13.67 mb)  13.67 mb █▁▁▁██▁█▁▁███▁▁▁▁██▁█

But we can leave that out of the official benchmark and chalk it up to "preparation time" 😉

Advent of Code 2025 - Day 9

Tue, 09 Dec 2025 00:00:00 GMT

The hardest Part 2, I think!

Read the full prompt.

Part 1

The idea is we have a bunch of points on a grid, and need to find which pair of points would create the largest rectangle (imagine them defining opposite corners of a rectangle).

The first thing that tripped me up was realising that these coordinates weren't on a continuous plane, and we needed to take into account the "size" of the point itself when calculating the area of a rectangle. This amounted to adding 1 to each dimension when calculating the area.

Then you just need to loop through each pair of points—you can cut out some duplicate checks by properly defining your start and ends of the for-loops—and compare areas until you find the max.

for (let i = 0; i < points.length - 1; i++) {
	const [x1, y1] = points[i];

	for (let j = i + 1; j < points.length; j++) {
		const [x2, y2] = points[j];

		const rMinX = Math.min(x1, x2);
		const rMaxX = Math.max(x1, x2);
		const rMinY = Math.min(y1, y2);
		const rMaxY = Math.max(y1, y2);

		const area = (rMaxY - rMinY + 1) * (rMaxX - rMinX + 1);

		partOne = Math.max(partOne, area);
	}
}

Part 2

This got trickier in Part 2, however. These same coordinates now need to be treated as the vertices of a bounding shape, and the only valid rectangles are ones which lie completely within this shape. I needed to turn to the Advent of Code subreddit for a bit of help on this one, I'll admit. I think I understand it now?

It's worth noting that the input file is defined in such a way that the next point in the list is connected to the one before it, all the way back to the beginning. This is how the boundary shape is defined, and it's also something I missed at first because I skimmed through Part 2 and didn't properly read it. Once we know this, we can construct a pairwise list of points to get the actual edges of the bounding shape.

// Coordinates are defined "in order" around the polygon, so we can do this.
for (let i = 0; i < points.length; i++) {
	greenLines.push([points[i], points[(i + 1) % points.length]]);
}

For each rectangle we construct, then, we just need to check that it doesn't intersect with any of these lines, and we know that it lies within the shape and can be considered valid. This is where my understanding falls apart a bit, though, because apparently this wouldn't work as a general case. We're lucky that Eric Wastl (the creator) generated an input that was okay! I think the idea is that this collision-detection wouldn't work if there were any points that were directly adjacent to each other in the grid. One to look back at later, maybe.

if (area > partTwo) {
	let isColliding = false;

	for (const [[p, q], [r, s]] of greenLines) {
		const eMinX = Math.min(p, r);
		const eMaxX = Math.max(p, r);
		const eMinY = Math.min(q, s);
		const eMaxY = Math.max(q, s);

		if (
			rMinX < eMaxX &&
			rMaxX > eMinX &&
			rMinY < eMaxY &&
			rMaxY > eMinY
		) {
			isColliding = true;
			break;
		}
	}

	if (!isColliding) {
		partTwo = Math.max(partTwo, area);
	}
}

Benchmark

clk: ~3.03 GHz
cpu: Apple M1 Pro
runtime: node 22.16.0 (arm64-darwin)

benchmark                   avg (min … max) p75 / p99    (min … top 1%)
------------------------------------------- -------------------------------
Both                         182.99 ms/iter 186.98 ms     █                
                    (170.26 ms … 199.06 ms) 198.78 ms     █                
                    (  5.83 mb …   5.83 mb)   5.83 mb █▁▁▁█████▁▁▁█▁▁▁▁█▁▁█

Developing browser extensions seems hard

Thu, 14 Nov 2024 00:00:00 GMT

I'm building myself a bookmarks/read-it-later website to replace Instapaper and one requirements is saving links to it via a browser extension. (I also need to write an iOS app but that's another kettle of fish).

I didn't think it would be too bad: it's just JavaScript right? The problem lies in that there doesn't seem to be any form of intellisense for the WebExtensions API, so I have to spend half my time flicking back and forth between VSCode and the MDN docs to figure out what methods are available. Additionally, the development loop of manually loading your unpacked extension and having to monitor the browser console (Cmd-Shift-J) for logs seems quite slow?

Maybe I just haven't been at it long enough but I really hope I find a nicer way to do this.

Prefetching considered harmful

Mon, 17 Mar 2025 00:00:00 GMT

I've been trying to get prefetching working in an app I'm building at the moment, but Firefox has been consistently ignoring my wishes and only fetching on click.

I looked in my about:config and, lo and behold, prefetching behaviour had been disabled. I didn't remember doing that? I turned it back on but it still didn't work. I checked about:config again, and it was disabled again. What??

To keep it short, uBlock Origin and Decentraleyes—I'm still not sure if I need both—each had a setting in them to disable prefetching behaviour. Apparently it's harmful, privacy-wise, because it allows the browser to connect to resources that would've otherwise been blocked.

What now, then? I probably want to keep prefetching disabled because I think I value my privacy that much, which means there's no point me implementing it. I'm going to look elsewhere for performance gains.

An ExpressJS Quickstart

Thu, 13 May 2021 00:00:00 GMT

In this post we're going to cover how to create your own local web server using the express package. It's a pretty straightforward process, so let's begin!

This is a crosspost of an article I wrote over on the Yordevs website a few weeks ago.

Setting up our project

If you haven't already, set up a new Node project. From there we just need to install express with the following command:

npm install express

This will download everything that we need to get a basic web server up and running!

The code

If you're just looking for some code to copy and paste then the following snippet will be enough.

// index.js
const express = require("express");
const app = express();

app.get("/", (request, response) => {
	res.send("Hello, world!");
});

app.listen(3000);

To run the server just type:

node index.js

You can test it working by visiting localhost:3000 in your web browser, and should see something like this:

A Deeper Explanation

If you fancy going into a little more detail, in this section we'll split up the code above into a few parts and explain what they each do. As a quick reminder, here's the snippet again (but with comments too!):

// 1. Import and setup
const express = require("express");
const app = express();

// 2. Setting up endpoints
app.get("/", (request, response) => {
	response.send("Hello, world!");
});

// 3. Listening for requests
app.listen(3000);

1. Import and setup

In this section we're doing two things. First, we're importing our newly installed express package with:

const express = require("express");

Next, we create an instance of the Express server by typing:

const app = express();

Creating instances is helpful in letting us create multiple servers with different "names" that can be referenced for different things. For example you could create three different servers and have them set up to do different things, all without interfering:

const server1 = express();
const server2 = express();
const server3 = express();

// Each server can be set up to listen on a different port (explained later on) and won't interfere with each other.
server1.listen(3000);
server2.listen(4000);
server3.listen(5000);

2. Setting up endpoints

A server's endpoints are basically URLs that can be used to access different kinds of data. In the example above with have an endpoint like so:

app.get("/", (request, response) => {
	response.send("Hello, world!");
});

This creates an endpoint for our app server which responds to GET requests sent to the URL localhost:3000.

If you wanted to add another endpoint which did something when you sent a request to localhost:3000/ping, it would look something like:

app.get("/ping", (request, response) => {
	response.send("Pong!");
});

Try this part out in your code, if you want! Consider it a small challenge or something.

The final part is a callback which takes the request and response as parameters, allowing you to process the request to the server (e.g. parsing parameters included in the URL) and your response before you send it back.

3. Listening for requests

So far we've got a server which is based on the ExpressJS package we installed, and a few endpoints which are set up to do some stuff, but how do we actually get the server responding to our requests?

Much like a real life conversation, we need the server to be listening for any requests that are sent to it.

This is, thankfully, a really easy thing to do.

app.listen(3000);

Here we're literally telling the server, "listen out for any requests sent to port 3000" .

For reference, a port is like a way of dividing a network connection into lots of little numbered "doors" which can then have different types of network traffic assigned to them (e.g. all requests going to our server are on port 3000, all HTTP requests use port 80).

But yeah, that's what listening for requests is!

With all that said and done, you should have your very own web server up and running on your computer. Congratulations!

Do your tests fail?

Tue, 17 Sep 2024 00:00:00 GMT

Posting this mainly as a reminder to myself.

It's probably not enough to write a unit test, check that it passes, and continue on with your day. You should also check that it can fail too. Make it expect something that's slightly different from what you really want and see if it blows up in your face.

Otherwise, you might've just written the unit test equivalent of a yes-man and it won't really provide any value for you or your meticulously-crafted test suite.

Styling Astro with Radix Colors

Wed, 14 May 2025 00:00:00 GMT

I'm rewriting my website again—this time with Astro—and gave myself the challenge to do it all with vanilla CSS instead of Tailwind, because I was getting a little too dependent.

One of the things I instantly missed was having access to a collection of high-quality colour palettes right at my fingertips. Luckily, I'm a big fan of Radix and remembered they released their "colors" package to provide something very similar.

There are a couple of ways to use these colours with Astro so I thought I'd make a note of them.

Option 1: Importing with CSS

I think the simplest way is to write a CSS file and import the colours you want directly in there. They're all then accessible through the use of CSS variables.

@import "@radix-ui/colors/slate.css";
@import "@radix-ui/colors/cyan.css";

a {
  color: var(--cyan-9);
	&:hover {
    color: var(--cyan-10);
	}
}
/* Any other styling you want... */

You can then import this css file anywhere you want to be able to use the colours, like you would any other CSS file in Astro.

For example, in this Layout component:

---
const { title } = Astro.props;

import "../styles/colours.css";
---

<html lang="en">
	<head>
        <title>Custom Colours</title>
	</head>
	<body>
		<article>
			<h1>Custom Colours</h1>
			<slot />
		</article>
	</body>
	<style>
		h1 {
			color: var(--slate-12);
		}
	</style>
</html>

Another bonus here is you can use these same CSS variables in other components, as long as they would be wrapped by this Layout component at some point in the tree. This is a pretty good option, for example, if you use a BaseLayout component which you wrap every page in.

Option 2: `define:vars`

The second option is to import the colour palette via the Component Script and inject them into a style tag with define:vars.

---
const { title } = Astro.props;

import { slate } from "@radix-ui/colors";
---

<html lang="en">
	<head>
		<title>Custom Colours</title>
	</head>
	<body>
		<article>
			<h1>Custom Colours</h1>
			<slot />
		</article>
	</body>
	<style define:vars={slate}>
		h1 {
			color: var(--slate12);
		}
	</style>
</html>

⚠️ Note! Using the colours with define:vars gives it a slightly different syntax to before. See how it's --slate12 instead of --slate-12.

Combining the two

There might be a case where you want to globally define some colours but scope others to a specific component. This can be done by combining both of the methods above!

I've whipped up a quick example of what I mean here: Stackblitz

Rewriting my website

Sat, 18 May 2024 00:00:00 GMT

Just a quick note that, since writing this post, I rewrote my website again. I guess some things are never constant. I'm even thinking about starting it from scratch for a third (fourth?) time because I'm never happy with it and I don't know what I want.

I recently decided to completely rewrite my website. My old one sat, unchanged, for almost 3 years and I never really put much effort into adding new features to it or updating it with content, despite it being technically possible.

The process just had too much friction and I never felt like had anything big enough to say that it would be worth the effort; I didn't want to have to open a code editor just to write a little Markdown post, and I certainly didn't want to have to start creating pull requests in GitHub to get that content live.

So, I decided to rewrite it all, and look for a way to write and manage this site's content that was more inline with a traditional CMS. It would be nice to be able to access it anywhere, from any device, so I'm not restricted only to places that I happen to have cloned my site's repo to.

I also fancied a rewrite because I wanted to use Remix. I really like Remix. The loaders and actions and nested routing and "use the web" mantra give you so much control with such a great DX, and I found it really clicked for me when building other projects with it.

I only stumbled across Keystatic very recently but it seemed to be exactly what I was looking for. Following their guide on adding Keystatic to a Remix project, I was very quickly able to get a working "admin panel" with a really nice editor too. Theoretically I can login to this editor from any device, sign in with GitHub, and then publish posts without ever having to use a terminal or open VSCode. Exactly what I want!

I'm hoping this massive reduction in friction will lead to me writing more, because definitely something I want to do more, even if it feels quite ropey at first. And I trust Remix to be powerful enough, too, to let me extend this site with whatever I want in the future. If I suddenly decide I need a place to track books that isn't my Goodreads, for example, it's definitely something I could integrate.

Thanks for reading! 👋

I don't need a second brain...do I?

Tue, 06 May 2025 00:00:00 GMT

Just watched Maggie Appleton demo how she uses Tana to organise all her stuff and felt a weird mix of awe and FOMO? I don't collect anywhere near enough data in my day-to-day life to need much of a system to organise it but I kinda wish I did? I love the idea of a Second Brain, all connected together to help me work better and organise my thoughts and interests. On the other hand, maybe it's just got a nice UI that I like and I'm trying to trick myself into feeling productive by setting up some kind of new system.

Using next-themes with Stitches and Next.js

Sat, 18 Dec 2021 00:00:00 GMT

I've been building my website with the help of an amazing CSS-in-JSS solution called Stitches. If you haven't heard of it before I would definitely recommend taking a peek at their website and giving it a try because I almost instantly converted across from styled-components.

This isn't a post all about how great I think Stitches is, as much as the dev team would probably love it, though. Instead, I wanted to quickly write-up how I got dark mode working on this site using Next.js, Stitches and a little package called next-themes.

Setup the next-themes provider

Install next-themes with:

npm install next-themes

and add its provider to our Next.js App component.

// _app.tsx

import React from "react";
import type { AppProps } from "next/app";
import { ThemeProvider } from "next-themes";

function App({ Component, pageProps }: AppProps): JSX.Element {
	return (
		<ThemeProvider>
			<Component {...pageProps} />
		</ThemeProvider>
	);
}
export default App;

Create a dark theme in Stitches

Head on over to your Stitches config file (stitches.config.ts, for me) and import createTheme from stitches/react. Then create a new theme for your dark theme like so:

// stitches.config.ts

import { createStitches, createTheme } from "@stitches/react";

export const { styled, css, theme } = createStitches({
	// other styling here...
});

// Create your new dark theme below, like this.
export const darkTheme = createTheme("dark", {
	colors: {
		text: "black",
		heading: "grey",
		background: "white",
		accent: "cyan",
	},
});

Great! Now we want to set this theme up as an option in next-themes. Head back over to the _app file and set it up like so.

// _app.tsx

import React from "react";
import type { AppProps } from "next/app";
import { ThemeProvider } from "next-themes";

// Import your dark theme into the component.
import { darkTheme } from "../stitches.config";

function App({ Component, pageProps }: AppProps): JSX.Element {
	return (
		<ThemeProvider
			attribute="class"
			value={{
				dark: darkTheme.toString(), // this .toString() is important
				light: "light",
			}}
		>
			<Component {...pageProps} />
		</ThemeProvider>
	);
}
export default App;

Theme Toggle Component

Lastly we just need to make a little button or something to let you toggle between the two colour themes.

// ThemeToggle.tsx

import React, { useState, useEffect } from "react";
import { useTheme } from "next-themes";

export const ThemeToggle = () => {
	const [isMounted, setIsMounted] = useState(false);
	const { setTheme, resolvedTheme } = useTheme();

	useEffect(() => setIsMounted(true), []);

	const toggleTheme = () => {
		const targetTheme = resolvedTheme === "light" ? "dark" : "light";

		setTheme(targetTheme);
	};

	// Don't render the theme-toggling UI before the mounted.
	// See: https://www.npmjs.com/package/next-themes#avoid-hydration-mismatch
	if (!isMounted) {
		return <button>Loading...</button>;
	}

	return (
		<button onClick={toggleTheme}>
			Switch to {resolvedTheme === "light" ? "dark" : "light"}
		</button>
	);
};

Add the button wherever you want it and you should see your theme switch between dark and light mode. It'll also remember which mode you left selected and use it on subsequent page refreshes!

Creating a reusable media query function

Thu, 03 Jun 2021 00:00:00 GMT

In short

// mixins.js

const breakpoints = {
	sm: "640px",
	md: "768px",
	lg: "1280px",
};

export const media = (size = "sm") =>
	`@media screen and (min-width: ${breakpoints[size]})`;

Explanation

So it turns out you can't use CSS variables with media queries, which is a bit of a bummer.

The main reason you might want to do something like this is to create a bunch of reusable media query mixins for yourself, keeping all your breakpoints the same and letting you change them at a moment's notice. It also saves a few keystrokes and keeps you from having to remember what the exact syntax for the query should be ("is it min-width or max-width? Hmm...")

Since the function returns a template literal, it can be inserted whatever CSS-in-JS solution you're using!

The code above is basically what you'll need to write. Feel free to extend it with more breakpoints if you like, or add some checks to ensure you can't enter any incorrect values for the parameter!

Usage

// text.js

import styled from "styled-components";

import { media } from "./mixins.js";

const Text = styled.p`
	color: red;

	${media("sm")} {
		color: green;
	}

	${media("md")} {
		color: orange;
	}

	${media("md")} {
		color: blue;
	}
`;

Hello submodules!

Wed, 30 Apr 2025 00:00:00 GMT

I've put all my website content into its own private repo and am loading it as a Git submodule now, thanks to help from some helpful guides!

The plan is to start using Obsidian to create and edit content, then push it to GitHub with the Obsidian Git plugin and hopefully everything just updates. I'm not quite sure whether changes to the submodule will trigger the "parent" repo's GitHub Action to redeploy the site, which is partly why I'm writing this note; I want to check what happens and whether I need to manually redeploy something. If so, I need to find a way to have this trigger ✨ automagically ✨.

Edit: The repo seems tied to a specific version of the submodule, and didn't automatically pull the latest when I made changes. I think the easiest thing would be to setup some kind of cron job in GitHub Actions that runs the git submodule update command every 30 minutes or so (it could be longer; I don't publish very frequently) and redeploys if there are any changes. Hopefully that doesn't eat through my free tier usage limits.

How to make Vercel play nice with Remix and Keystatic

Thu, 23 May 2024 00:00:00 GMT

TL;DR

If you just want the code:

export async function loader() {
	const reader = createReader(process.cwd(), keystaticConfig);

	// This is the important line!
	console.log(
		fs.readdirSync(path.join(process.cwd(), "app", "content/posts"))
	);

	const posts = await reader.collections.posts.all();

	return json({ posts });
}

I recently posted about how I decided to rewrite my website, choosing to use Keystatic for managing the trillions and trillions of posts I've made.

The process was very simple: I set it up in local development, told it to use GitHub for storage, and added some code in my loaders to read said storage and serve the posts. It's super simple and it works super well...locally. The only tiny issue I ran into was when deploying this same code to production, on a server hosted by Vercel, where absolutely none of the posts were showing up.

Anyway I did some poking around and—through sheer, dumb luck—decided to console.log out the folder containing my posts, to check the output in Vercel's runtime logs...and suddenly everything showed up!

I'm not sure if they're doing something strange where they don't make files accessible until something "needs" them but I'm very glad I randomly found it and don't have to switch to another hosting provider or CMS system.

Vertical Tabs

Sun, 17 May 2026 00:00:00 GMT

So it turns out Firefox and Chrome both support vertical tabs now.

I first tried using vertical tabs back when Arc Browser was popular—and hadn't yet experienced the massive vulnerability that probably(?) contributed to its discontinuation back in 2025—and I really liked them. I was a bit sad to have to go back to horizontal tabs at the top of screen and tried extensions like Tree Style Tabs and Sideberry to replicate the effect, but having to rely on an extension and manually styling my userChrome.css to get Firefox to look how I wanted was a pain, so I relented and went back to horizontal tabs.

Anyway, I don't have to do that anymore. I'm back to vertical tabs on both my work and my personal computers. I think both browsers have implemented it quite well, although I'd definitely love to see native tree-style tabs for even more organisation. The best part is being able to collapse the tabs down to just their favicon, which gives me soo much more screen space.

But the point of me writing this anyway was to say that I've noticed I now keep more tabs open than I did when I was using horizontal tabs. Maybe it's because it's easier to scroll through a verical list than a horizontal one? I'm able to see the titles of more tabs than before, so perhaps that plays a factor in how much "context" I'm happy to have open at any one time.

Texting myself the weather every day

Sun, 01 Jun 2025 00:00:00 GMT

Opening the Weather app every morning is too much effort, but you know what isn't? Writing a recurring job to query an API every morning and send you the results in an SMS, delivered right to your ~~doorstep~~ phone! Come with me as we embark on my short, little journey through this very process.

Version 1: A Zapier "Zap"

Version 1 of this service was simply just a "zap" on Zapier. Very easy to connect together a trigger and an action, and start receiving a text message summary every morning at "around 7am".

Pretty good already!

I really like the summary that Zapier generates, as it has a bit more detail that you might get from a single WMO Weather Code.

However I still wanted to actually code this myself, for a couple of reasons:

In this very simple version, there's no way to customise what time the message arrives; It's locked at an "around 7am" window. My girlfriend also started using this Zap and her first question to me was whether it could arrive before 7am because she's often leaving for work earlier than that.
This is something I should be able to code and host myself, without relying on a third-party. Maybe just a matter of principle but I felt like, "if I can do this myself, I should."

Version 2: TypeScript + Twilio + GitHub Actions

This was really the sort of thing I wanted to do from the start. Complicated-ish, but with a clear progression and enough moving parts to keep me interested for an afternoon.

TypeScript + Open-Meteo SDK for fetching the weather data
Twilio for sending the SMS (I had to buy another phone number for this!)
GitHub Actions for setting up a cron job and trigger the send at ~7am every morning

OpenMeteo

The Open-Meteo service is pretty cool, as it's a free API that combines weather models from multiple different national services (e.g. MetOffice) to provide you with "the most reliable and accurate weather predictions available". The use flatbuffers instead of JSON for serialising their API payloads, which is apparently "more efficient" (not quite sure how, but maybe I'll update this once I've found it). It leads to some funky syntax when accessing the data:

const hourlyWeatherData = {
	temperature2m: hourly.variables(0)!.valuesArray(),
	precipitationProbability: hourly.variables(1).valuesArray(),
	weatherCode: hourly.variables(2)!.valuesArray(),
	uvIndex: hourly.variables(3)!.valuesArray(),
};

The SDK provides a way to fetch a single day's-worth of forecast by passing forecast_days: 1 in the request params, with it returning the max/min value for each field across the course of that day. I actually ended up foregoing this and specifying the exact date-time range instead, though, because it turns out the "daily forecast" was a full 24h time range and I was occasionally seeing results from before I woke up affecting what was being sent (e.g. a 99% chance of rain at 5am would be what's used in the SMS, even if the rest of the day was completely dry). By passing a custom time range (7am to 11pm) and manually grabbing the min/max results myself, I could constraint the weather information to the hours that actually mattered to me.

One improvement I'd like to make to this version is to find a way to generate more detailed summaries. The Zapier version was able to combine information about precipitation, cloud conditions, and temperature into a short, three-sentence summary, whereas my current implementation just uses a single WMO Weather Code, which isn't as detailed. I could probably roll my own, similar version by mapping the maximum temperature and probability of rain to a set of possible strings (e.g. >70% becomes "stormy").

Twilio

I didn't do a huge amount of shopping around, here. I know people use Twilio for sending text messages, and I needed to send text messages, so I used Twilio. Great job, Twilio Marketing team! 👍

Before fully committing, though, I did some back-of-the-envelope maths to estimate how much this sort of system might cost. Twilio charge £0.89022/month for a phone number, and £0.0463 for every SMS you send from that phone number. Based off the minimum £20 top-up charge to use their service, I reckon I could keep this live for maybe...5 months before I need to top-up? Not too bad for a fun personal project.

The Twilio SDK was actually really easy to set up and use. You basically just pass a string to be used as the message body and tell it which phone number to send from. One slightly annoying thing is there doesn't seem to be a way to send to multiple numbers at once, so you have to wrap this call in a for loop if, like me, you're sending to more than one person.

const client = Twilio(twilioSid, twilioAuthToken);

for (const phoneNumber of phoneNumbers) {
	client.messages.create({
		to: toPhoneNumber,
		from: fromPhoneNumber,
		body: messageBody,
	});
}

The Twilio SDK was actually really easy to set up and use.

I can't say the same about their website, though. It's pretty awful to navigate around and required way too much clicking around to find the billing page and understand where my money's going.

GitHub Actions

With everything pieced together and working on my machine, I turned to GitHub to provide me with a free, easy way to schedule these text messages and send them out at the same time every day.

Admittedly, I caved here and used Gemini to help me write the Workflow script, because I feel like this is an area where LLMs are quite helpful. In a couple of queries I had the script I wanted—or, at least, enough of a script to be able to tinker with and adjust by myself—and could start testing! It's a simple script that runs at 6:45am every morning, scheduled with a cron job.

name: Send SMS at 6:45am every morning
on:
    schedule:
		- cron: "45 5 * * *" # timezones issue (see below) 🙃

Interestingly, GitHub Workflows don't support timezones! This means that, if I want to sent a text every morning at 7am, when on BST (British Summer Time) I actually need to schedule it for 6am instead.

Et voilà! My work is done and my phone received a text at (roughly) 6:45 every morning!

Ben Silverman

Who will I be in 75 days?

🍱 Eat well

🏃‍♂️ Exercise once a day

🚰 Drink 3 litres of water a day

📖 Read 10 pages a day

I sense another rewrite coming on

Advent of Code 2025 - Day 1

Day 1

Part 1

Part 2

Benchmarks

Advent of Code 2025 - Day 10

Part 1

Part 2

Benchmark

Advent of Code 2025 - Day 11

Part 1

Part 2

Benchmark

Advent of Code 2025 - Day 2

Part 1

Part 2

Benchmark

Advent of Code 2025 - Day 3

Part 1

Part 2

Benchmark

Advent of Code 2025 - Day 4

Part 1

Part 2

Benchmark

Advent of Code 2025 - Day 5

Part 1

Part 2

Benchmark

Advent of Code 2025 - Day 6

Part 1

Part 2

Benchmark

Advent of Code 2025 - Day 7

Part 1

Part 2

Benchmark

Advent of Code 2025 - Day 8

Part 1 & 2

Benchmark

Advent of Code 2025 - Day 9

Part 1

Part 2

Benchmark

Developing browser extensions seems hard

Prefetching considered harmful

An ExpressJS Quickstart

Setting up our project

The code

A Deeper Explanation

1. Import and setup

2. Setting up endpoints

3. Listening for requests

Do your tests fail?

Styling Astro with Radix Colors

Option 1: Importing with CSS

Option 2: define:vars

Combining the two

Rewriting my website

I don't need a second brain...do I?

Using next-themes with Stitches and Next.js

Setup the next-themes provider

Create a dark theme in Stitches

Theme Toggle Component

Creating a reusable media query function

In short

Explanation

Usage

Hello submodules!

How to make Vercel play nice with Remix and Keystatic

TL;DR

Vertical Tabs

Texting myself the weather every day

Option 2: `define:vars`