Go's implicit interfaces provide great flexibility when it comes to testing our applications. By satisfying the expected contract we can create mocks easily to be used within our test cases. For me there are two main approaches I personally take to mocking. Lightweight Mocking I call this lightweight as it is less involved than the method we will come onto next. It basically involves just creating a new structure which satisfies the interface.

When it comes to designing abstractions interfaces are a fundamental tool in a developer's arsenal. Through my recent ventures into the Go languages I have begun to change my approach to how I use interfaces to a more behavioural approach, for example rather than having an interface to represent a thing such as an animal or a user, I instead aim to represent the behaviours that those things can do; walk, talk, login and so on.

I was reviewing some pull requests recently and I got into a little debate. Just before I go into what that was exactly let me prefix this with: as a developer I am a very strong believer in writing clean, readable code. From top to bottom it should read like a story and if I handed it to someone who had never coded in their life, I want them to be able to understand roughly what the code is doing.

What are Pipelines? At the very basic level Redis Pipelines allow us to send multiple commands to our server, have them executed and then read all the replies. If you are wondering why that’s different to how it normally works, think of it this way: We have a bridge, on one side of the bridge is all the commands we want to run. Our helper memorises a single command, carries it across the bridge and executes it.