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.

It took a while since I got this book. At the very beginning, I didn’t want to buy it. However, I got so much feedback that this book is so good that I had to check it myself. It is the second Go book in my library. I didn’t write about the first one because I wanted to compare it with another one. I wanted to recommend you only the best.

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.

In this article, I explain how you can detect if the interface you’re using is getting too big and requires splitting into smaller ones. Smaller interfaces help to improve the maintenance and readability of the code. What’s more, it helps with understanding the code. Interfaces in Go are different than those known in Java, c#, PHP etc. In those languages you define interfaces up-front. In other words, at the moment of creating a class you need to know how the class will be used.

There are books that after reading you consider them as “must-read” and you’re asking yourself why you didn’t read it before. Today is the day when I read the “Deep Work: Rules for Focused Success in a Distracted World” by Cal Newport for the second time. I don’t regret it. In COVID times, we very often work remotely. It changed a lot in our life as well as in the world.

The context package in Go is quite simple and well-known. On the other hand, there are some misunderstandings while using it. Today, I’ll try to explain all the most popular concerns and make more clear when and how use the Context. Let’s start with what the context is. Package context defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes. ref: https://golang.

I always had problems with negotiations. To be precise - it’s still a problem for me but I think that “Never split a difference” by Chris Voss will help me with this. Here are some things I took down I remember from the book the most. The first thing is the mood. When we feel safe and in control, we are more problem-solvers. A smile makes as more open and ready for negotiation instead of fight and resist.

From time to time, I receive an email from a scammer that says he has X million dollars/euro for me. At the very beginning, I removed those emails but at some point, I decided to answer them. Here’s what I found. Every scammer starts very typically. There’s a very reach person who’s dying or very sick. They found my email on the Internet and learned that I’ll be the person who will spend the money wisely.