Refactored Telegram

It’s all just ones and zeros under the cover

A Simple Source IP Address Filter in Go

I’ve found that it’s occasionally useful to have something that allows through, or blocks, requests to your web application based on the source IP address. There are a number of reasons as to why you may want to do this: maybe it’s because you’d like to put something online that only you would have like access to, or it could be that you’re building something that is publicly available, but certain endpoints should only be accessible to certain machines for security or privacy reasons. For me, the motivation was to build something that was not quite ready to share with the outside world.

Either way, a simple IP Address filter might be a useful thing to keep in your toolkit. This article shows you how to build one.

Read more →

Building Sets from Maps

In the various Go projects that I work on, there have been times when I have needed to store items in a set. Many languages have a set implementation that is usable right out of the box. Unfortunately, Go is not one of them; but a set can be created quite easily using Go’s map type. Here is the technique I use to do so.

Read more →

Test Helpers and Test Packages in Go

My previous role was as a Java developer. In Java, a unit test shares the same package as the code being tested; meaning that the test has full access to the private fields and methods that the code has. This is useful for building test helpers; the methods and data structures used for setting up a test, or creating test data.

Unit tests in Go can be written in the same way, and I did this when writing tests for my personal projects1. But since starting a new role as a Go developer on a commercial project, I’ve come around to the approach of using test packages for my unit tests. Writing tests this way is arguably better (more on that below), but I was unsure how best to write the helpers I will need to keep these tests concise.

Read more →

Dealing With Errors in Go

There’s a lot to like about Go, and I’ll happily admit being a huge fan of the language. But it will be dishonest of me not to acknowledge that some aspects of programming in Go results in more code than the equivalent in another language. My guess is that the best example of this is how Go programs deal with errors.

For those unfamiliar with how errors work in Go, the short version is that they are just like any other type that you deal with — like strings and integers — and they have no special control structure to handle them in any specific way. This means that, unlike languages that have exceptions, there is nothing like try/catch blocks; you are left with the standard control statements that are available.

The result; you will fall into the practice of having a lot of code that looks like this:

func doStuff() error {
	firstResult, err := doFirstThing()
	if err != nil {
		return err
	}
	
	secondResult, err := doSecondThing(firstResult)
	if err != nil {
		return err
	}
	
	lastResult, err := doOneLastThing(secondResult)
	if err != nil {
		return err
	}
	
	return processResult(lastResult)
}

This is not bad in-and-of-itself, but it does have some shortcomings over the equivalent in languages that use exceptions. The use of an if block after every call to a “do function”1 adds a bit of noise making it harder to separate the happy path from the error handling. And although the code is technically correct — whereby the errors are being handled appropriately — you may come to wonder whether this could be done in a nicer way.

This post explores some alternatives for dealing with Go errors. It is by no means exhaustive; it’s just a few patterns I’ve found works for me. It is also by no means suggestive that you even should use one of the alternatives. Each use case is different; and one alternative might be a better solution in a particular case, but dramatically worse in another. Everything in coding, much like life itself, is a tradeoff, and I would suggest being mindful of the potential costs of adopting any one of these options alongside the benefits they may bring.

With that said, let’s look at some alternatives.

Read more →

Building and Serving Go WASM Projects

One of the advantages of maintaining a blog is that it works as a good destination to record how to do something that you find yourself needing to do occasionally, but keep forgetting how to do it. Documenting the process in public, and in a way that will hopefully help someone else that needs to do the same thing, is a laudable goal in itself, but it does raise the question on why one would do so when there are many, many, other blog posts on exactly the same topic. At least this way, there is a reference that I know exists, and is written in a way that works for me, specifically because I wrote it myself.

With this preamble out of the way, here is what you need to know in order to build a WASM project in Go, and execute it in a browser1.

Read more →

Setting Go Variables During Build

Like many others, there are occasions when and I want to store the value from the environment, like the current build number or Git commit hash, in the source code of a software package so that I can display it on startup or when invoked with a command line switch. This information is only available during the build phase of the application, so something will need to be added to the build process to inject this value once it is known. This is relatively easy to do in C by using the -D switch to the compiler to declare the value as a macro. Even in Java this can be done using Maven resource filtering.

However, I was unaware of how this was done in Go. To date, I have been using a simple form of code generation that involved passing sed over a source file with a dummy string constant. sed would be configured to replace that constant with the version number or Git hash prior to the Go application being built. This worked, but it was a little bit inelegant.

I have since learnt, via this Stack Overflow answer, that it’s possible to set the initial value of a Go variable directly from the build command. The process is not as nice as it could be, as it involves actually setting flags to the linker, but it works reasonably well and is much nicer than doing things with sed .

Read more →