It’s hard to write maintainable code without others’ opinions. Code reviews are an easy solution: they’re async, perfect for the busy manager; enforceable and trackable in your code platform; easy to refer back to later.

Unfortunately, it’s easy to give a terrible code review: how many times have you got stuck in the bikeshed iterating on things that were already better than what was there before? On the flipside, how many times have you got a plain “LGTM” when you knew you could do better next time if only you had feedback?

How can we make our code reviews focus on catching bugs before they happen, while still providing pointers for growth, without just being linter 2.0?

If you don’t mind sounding like an assassin droid with a complex past, then I have a solution for you… or at least a set of idiosyncrasies developed over the last few years which have worked well for me and my team(s).

tl;dr: In this scheme, any non-urgent comment in a code review gets a prefix. If there’s no prefix, some response (code or a reply) is needed. If all comments have a prefix, approve the pull request. By leaving nitpick comments but not blocking on them, we accept a slower first review, but kick off a virtuous cycle that should lead to overall better code and faster reviews in the future.

[Read More]

From March 2025 until March 2028, I am a certified IPv6 Security Expert according to RIPE, the Regional Internet Registry for Europe, the Middle East and Central Asia. You could become one too!

This certification comes from a virtual multiple-choice exam on the contents of the free RIPE NCC Academy IPv6 Security course. The course page claims that it takes around 24 hours to complete; in real time this was a couple of modules each day over the course of a week.

tl;dr: The course covers security considerations raised by IPv6: largely similar to IPv4, with added challenges from the two sets of differing protocols coexisting. This includes details of IPv6 protocols where needed to explain vulnerabilities. I imagine it is primarily useful for network engineers and SOC team members, particularly if you’re configuring networks yourself or implementing tooling which interacts with these protocols. For broader Web security, sections focusing on information exposed at higher levels – e.g. IPv6 addressing architecture (section 2.4) and DHCPv6 (section 3.5) – are most relevant. The labs and animations are particularly good; use RFCs to augment the text.

[Read More]

After a silly joke at work, I spent an evening implementing a Python script to generate "all the way down"-type animated gif images which endlessly zoom down onto some source image. I wanted this for a Slack emoji, but it'd be equally useful for Discord emoji and similar.

More specifically, design considerations were:

1. Avoid the pitfalls of other online generators which don't round properly. Depending whether the downscaled image had an odd or even number of pixels, the image would drift left and right through the animation.
2. Far too many .gif generators rely on server-side logic. I want to be able to play around with how my images are configured without incurring a bunch of network round trips, and without passing the images over to some third party service.
3. I wanted proper support for transparency. This was basically just to generate a "turtles all the way down" gif using the turtle emoji from Noto Color.
4. A desire to release it free to the world, for anyone to use (and modify).

The Python script met these needs at the time. However, I've had cases where I've wanted to generate these gifs but haven't been at a machine with the Pillow library installed. Thus a couple more evenings later... [Read More]