Category Golang

Go doesn’t support enums. You probably know that. However, we can, somehow, simulate them using a few techniques or tools. Today, I’ll tell you how I use enum-like types and what are other possible options to improve it. When you start reading about enums in Go you’ll quickly find a tip to use iota. const ( // iota is reset to 0 c0 = iota // c0 == 0 c1 = iota // c1 == 1 c2 = iota // c2 == 2 ) In every const block its value is reset to 0 and increment when declaring another constant as shown above.

I like having the core logic of our application free of distractions like too many technical “details” like logging or generating metrics. Of course, sometimes it’s hard to avoid it. I found in many projects a situation where we put the logger very deeply inside of the code. At the end of the day, we had the logger almost everywhere. In tests, we had to provide the mocked implementation everywhere as well.

Sometimes, we may want to use a library but a slightly modified version. It happens very often when we develop the library but test it in the context of an application. Go has a handy mechanism in go modules that can help us with it. To make it work, we have to clone the library somewhere near the target project and run the following command in the application’s folder. go mod edit -replace github.

gRPC supports authentication. Adding it to your project is simple. All you have to do is configure it with just a few lines of code. One of the authentication types that gRPC supports is SSL/TLS. From the server-side, the code looks like this: creds, err := credentials.NewServerTLSFromFile(certFile, keyFile) if err != nil { // handle the error - no ignore it! } s := grpc.NewServer(grpc.Creds(creds)) The client has to update the code as shown below.

Programs should be written for people to read, and only incidentally for machines to execute - Abelson and Sussman It is one of the most popular questions. You can find on the Internet attempts to answer this question. I’ve had concerns if I’m designing my packages or even the whole project correctly. Today, I’m not 100% sure about that! Some time ago, I had the pleasure to meet Robert Griesemer (one of Go’s authors) in person.

Some time ago, I found a Stack Overflow question. The author had a problem with understanding why the context from the request he’s using is canceled. I remember that I had a similar situation in the past: I used the context from the HTTP request and tried to use it in background operation and return the response to the user before it was finished. This issue comes from not understanding how the context is used in the http.

You can find a lot of articles about Go that describe general aspects of it. Including the content on this blog. Today, I decided to prepare something different. I’ll tell you about one of my tasks and I’ll show you how I resolved it using Go. I thought it’d be useful to show the exec package and to tell a bit about the ssh command and learn AWS EE2 a bit better.

Writing linters is simple. I was surprised how it’s easy to write a Go linter. Today, we’ll write a linter that will calculate the cyclomatic complexity of the Go code. What is cyclomatic complexity? Cyclomatic complexity is a software metric used to indicate the complexity of a program. ref The idea is simple - every time we find any control flow statements we increase the complexity by one. I know I oversimplified it a bit but I don’t want to overwhelm you with unnecessary details.

In the last article, we wrote a few tests for a project to make sure that our refactoring won’t break anything. To understand the project better, we will separate the part of the domain and add a test to it. This will make the test more authentic. There is a problem with the end-to-end (e2e) tests: database under the hood. This attitude is not carefree. Firstly, those tests are rather slow.

When we talk about software design we very often use very generic and abstract words. But, how about the practice? How does it look in a real-world project? Today, you and I will start refactoring a small to-do app for better testability and maintainability. In this article, we will make the application testable. We’ll write black-box tests that will prevent from some bugs and make future refactoring easier and safer.