Go comes with the ability to embed structs into other structs. It allows you to “reuse” fields and functions from one struct (the base) with another struct that embeds it. This can often be misunderstood as inheritance that you get from object orientated programming languages. While it can be useful and prevents having to duplicate code, it can also cause bugs that can be hidden in plain sight, which is what I encountered recently.

Ignore files are great. They allow you to ignore (of course) files/directories in different scenarios. For example a .gitignore file can be used to prevent files from being committed to Git such as local secrets, built binaries or any temp files. Or a .dockerignore file can be used to only copy files into a Docker container that are actually needed for a build (there’s no point copying test code / resources if they aren’t needed).

One of the many strengths of Go is its concurrency. But using concurrency comes with caution. Sometimes it’s not necessary and a lot of Go developers jump to using it too soon because they think it’ll solve a problem. I’m very guilty of having done that many times. However sometimes concurrency comes “for free” in the sense of http servers. Let me explain that a little better. When you create an http server and run it, you can make 1000s of requests to that server and it will handle them concurrently, and you didn’t even have to do a thing, other than write ~10 lines of code.

In the world of gRPC most cases will be a request response type of communication. The client sends the request to the server. The server does something, perhaps get some data from a database, and then returns it in a response to the client. This is known as a Unary RPC. However there are 3 other types that can be used which involve streaming. Server side - The server sends multiple messages back to the client, who waits for each response Client side - The client sends multiple messages to the server, which waits for each request before sending the response Bidirectional - Both server and client send messages to each other at the same time.

In Go there is a package called context, which defines a type that contains deadlines, cancellation signals or some other data and is usually passed from function to function. One of the most common use of the context is the ability to work out if a call should be cancelled. For example, when a gRPC request is being handled by a server, the client may have provided a 20 second timeout.

Recently I’ve been extracting data from a MongoDB collection, but I’ve had a requirement to keep the ordering of some of the data. For example, some of the data I’ve pulled out is stored as a primitive.Binary, and in this binary data is stack trace information. Part of the stack trace is a segment of code, which contains elements line number and code value. So something like this: { "code": { "27": "func main() {", "28": " err := someBadFunc()", "29": " if err !

I started investigating how to use channels to run concurrent things and then finish tasks in a go routine depending on the outcome of another routine. How I used channels The first thing to create would be the function that sleeps and then writes to the channel when done. I create a channel variable of type bool. Call my startSession function and pass in the channel and then wait for that channel to have some data that I can receive to continue.

I’m currently writing an application that takes some data from the user and writes that data to a file for later use. The function that does the saving is very small and is called from within another function. My problem, is that I wanted to write a unit test to test that my parent function did everything it should in terms of preparing the data, but I don’t want it to call the save function and actually save data to disk.

I bank with Monzo (for so many reasons that I won’t post here). One of the cool things they offer is IFTTT integration, and one of their applets is the 1p Savings Challenge. It goes like this: 1st January it puts 1p into a savings pot. 2nd January it puts 2p into a savings pot. 3rd January it puts 3p into a savings pot. It keeps going until the 31st of December where it’ll put £3.

When I’m working with multiple branches in Agile projects, I found I was typing git checkout, git commit, git push far too much. And then there the remembering the branch name that I was wanting to checkout (some of them were so long as well……). I decided that I didn’t want to use alias, but instead put my knowledge of Go that I had learnt and put it to use. So I wrote a command line app that allows quick shortcuts to be used to do the commands I did the most.