Category Golang

Introduction In the Go programming ecosystem, developers have a plethora of libraries available for solving common problems. However, some libraries may not always be the best fit for every project or developer preference. This article highlights a few Go libraries that I personally avoid using, along with the reasons behind these choices. The intention is not to discourage the use of these libraries universally but to shed light on potential challenges that may arise when using them, especially in larger or more complex projects.

Introduction In this blog post, I want to share my approach to testing functions involving randomness in Go. Recently, I was asked how I would test a specific function that calculates possible directions for an object to move. Initially, I didn’t come up with a good idea. Here, I’ll discuss how I’d solve this problem in a real-world application with a detailed explanation. The Function in Question The function calculates all possible directions that an object can move (up, down, left, right) without violating boundaries.

The else keyword is a commonly used control structure in programming. It allows us to execute a block of code if a condition is not true. However, overusing else statements can lead to less readable and maintainable code. In this article, we’ll explore why we should avoid using else clauses in our code and look at some alternatives that can make our code more concise and readable. Why Overusing else is a Bad Idea One of the main arguments against using else statements is that they can make our code more complex and harder to read.

There are many practices and tactics that tackle testing. Today, I’ll share with you how I write tests for my projects. Please notice that you may find it useful when starting a new project or an independent part of existing applications. You may find it difficult to apply in an already existing application. It’s not impossible but it may be challenging. Table of content General rules for tests Works out of the box Single responsible As simple as possible Irrelevant code should be extracted How does the architecture of the package look like?

Go is very opinionated. There are arguments that are based on personal preferences like “I don’t like the syntax” and much more specific. In this article, I’ll focus on the second type of arguments why Go isn’t the best language and confirm/denied them. My goal is to tell you the truth about the language. Table of content Arguments agains the language Lack of Function Overloading and Default Values for Arguments (https://www.

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.