Validation is something that every API developer has to deal with, but causes a surprising amount of confusion. Should the validation be done in the controller, the model, or a service class? Is the value of an attribute being invalid part of the request validation or business logic validation? By changing the way we think about validation the answers to these questions drop out, along with a nice implementation for Akka HTTP.

When I looked through some of Deliveroo’s non-Ruby applications, I saw that a number of them were trying to copy the ActiveRecord approach and defining data access methods on the models themselves. This is not a good approach in statically typed languages. I’ll explain why, and demonstrate the approach you should be using. It’s no secret that I think Go is a dangerously bad language, but I’ll use it here to demonstrate as the majority of the applications I’ve seen with this problem are written in it.

People coming from dynamic languages like Ruby or primitive languages like Go tend to miss the point of Scala. They tend to think in terms of mutability and often aren’t familiar with data structures beyond lists and hashes, with types and side effects being seen as fairly unimportant considerations. To try and illustrate the different way you need to think when writing Scala I’m going to write a ring buffer, as I’ve seen a few people around the office implementing them as a learning exercise.

Go is becoming increasingly popular and I find it troubling. It’s taken me quite a while to work out why that is, and quite a few drafts to try and express it in a way that gets my point across in what I hope is a fair and balanced way. This is not a “Go is bad” post. That’s been done to death and I don’t want to rehash it. I also have no intention of denigrating people who like Go; doing so would be self-defeating given it’s them this post is really aimed at. This is a post about reaching your potential.

In an ideal world everything would just work fine all the time. However, the real world is rarely like that which means we need to handle failures. Different programming languages have different approaches to modelling failure, but even with Scala there are numerous differerent ways of doing so. This talk takes a look at the various types of errors and exceptions you’ll need to deal with and suggests ways to model them.