Serverless Boundaries and How to Find Them

Last year I attended the awesome AWS Community Summit where I gave this talk on one of the fundamental questions of software architecture: how do we define the boundaries of things?

A lot of people I talk to are confused about how serverless applications change the way we design stuff, but my answer is that the basics are exactly the same, and even more important.

MUSTAPO: an architecture qualities checklist

Whenever I'm designing systems, there are three things to consider: the functional requirements, ie. the stuff that the system does; the constraints, ie, the time, money, and knowledge factors; and the architectural qualities - the non-functional requirements against which we test our design.

For the architecure qualities, or -ilities, I use a handy mnemonic: MUSTAPO.

Getting Started With Documentation Driven Development

Chances are that if you're building software in 2022, you're building some kind of distributed system. The success of a distributed system depends on the careful design of the interfaces between parts. For about a decade, I've been using what I call "Documentation Driven Development" (the other DDD). You can sum this up in one sentence: write the documentation first.

Mars Rover Kata, Bottom-Up

I've just uploaded my second ever Youtube video! I've been procrastinating on this for over a month, but this is a video of me tackling the Mars Rover Kata in Typescript. Most versions of this I've seen use an outside-in style, but instead I'm using a bottom-up approach. I'd love feedback, on Youtube or Twitter. If people are interested, I've got two more parts to edit and upload.

Configuring Magit Forge with the FreeDesktop Secrets API

It took me an hour or so to work this one out this morning. If you're running Magit Forge under Emacs and you want to store a personal access token on a recent Linux desktop environment, then you might want to use the Freedesktop secrets api.

Approval testing with Jest Snapshots

Approval testing is a powerful technique for working with legacy systems. When refactoring, it's important that we have tests to tell us if we've changed behaviour, but sometimes code can be smelly enough that writing unit tests is hard. Approval tests fill this gap. Instead of writing behavioural unit tests, we capture the output of the system - usually as text - and run a diff tool to check for changes in the output as we change the code.

I've previously struggled to set up approval tests with the common tools and libraries, but I realised today that Jest Snapshots solve exactly the same problem, and are easy to use.

The Cake Shop Kata

While spelunking through some code at work, I found a neat little programming problem that I've cleaned up a little and decided to publish as a TDD Kata.

In the Cake Shop Kata we're asked to write some code that can calculate the delivery date for different types of cakes, taking into account the skills and working patterns of the bakers.

Deploying Lambda with ESBuild and Terraform

Generally when deploying Lambda functions, I use the Serverless Framework. This is a wrapper around AWS Cloudformation that makes it easier for engineers to author and deploy code. It's much easier to get started when using an abstraction like this, but sometimes we need to drop down and work at a lower-level.

I recently needed to deploy a Lambda function with a large number of triggers, and the Cloudformation template generated by the serverless framework was too large to deploy. Instead I ended up configuring everything in plain Terraform. There are more moving pieces to understand, but in return for that overhead, we gain a lot of flexibility. In this post I want to show you how to configure and deploy a simple Lambda function, configuring everything ourselves in Terraform so we can see how it all fits together.

Sipping from the firehose

Kinesis Firehose writes concatenated JSON objects to S3. Most python solutions to reading the data rely on pre-processing with a lambda, or struggle to deal with large files. A better solution is to use a streaming parser. Luckily, I have just the thing.

Building a serverless web analytics solution

In this short blog series, we build our own web analytics solution from scratch using serverless technologies, just because we can.

Choosing the first test

I spend a lot of time teaching TDD to engineers. Some of my most rewarding sessions are spent with first-time TDD practitioners. When we're starting out, I'll choose a simple TDD kata, and we'll pair to solve it together.

Once I've introduced myself and the exercise, I always ask the same opening question: "What's the first test we should write?"

The answers are always interesting, because they tell me how the candidate thinks about TDD. If they have misconceptions, it's best to tackle them at the beginning. In my experience there are three common ways that people go wrong when choosing the first test.

Tackling the Delivery Service refactoring kata

I've recently started a new role as an engineering coach, and I've been working through some katas to remember how to write code.

I'm a huge fan of Emily Bache's work, and was particularly interested in the Delivery Service refactoring kata because it neatly captures some of the challenges of working with legacy codebases.

I'm going to walk through the process I followed when solving the kata, and I'll include links to each commit in the Github repository so you can see the full code as we go.