In this article, we’ll look at a very common mistake that Golang new comers make, especially when they come from a background of Object Oriented Programming (OOP) languages like Java or C#. What is interface pollution? Let’s look at some codes. package employee type Employee struct { Name string Credit int } type EmployeeRepository interface { Query(name string) *Employee } func NewEmployeeRepository() EmployeeRepository { return &database{} } type database struct {} // Query returns the first Employee that has a matching name. func (d *database) Query(name string) *Employee { // ... } We implement an employee package, providing a method to query the storage by employee name, which is exposed through the API of the package: the EmployeeRepository interface. This interface construct abstracts database, the concrete implementation that does the real work. This simply follows good-old OOP design principles that we’re all used to, so what is the problem here? The first thing to note is that the EmployeeRepository interface has only one implementation. In fact, if we remove EmployeeRepository interface, and expose database to the outer world like the following code, the package API does not change. ...

“How do you decide that a variable should be a pointer, or a value?” and “How do you know when to use pointer receiver and value receiver of a method?” are among the most common questions I receive from Go new comers. Even though there is no offical rule that dictates which types should use pointer, and which types should use value, it’s worth to deep dive into the topic of pointer and value semantic in Go, which is what we’ll do in this article. We’ll look at some examples, especially Go standard packages, examine what semantic the Go standard packages use, and then we’ll come up with a general guideline on how to choose the semantic for our own defined types. ...

Single Responsibility Principle (SRP) is the first one of the 5 famous principles that make up SOLID, a classic guideline to write clean and maintainable code, worshipped by a plethora of programmers worldwide. There exists various articles and workshops out there to explain the principle. Tech celebs support it, talk about it in social platforms. Many articles, however, does a poor job explaining the principle, resulting in a shallow and rigid understanding of the principle among developers. Uncle Bob, who’s believed to be the first to come up with a name for this principle, did a great job explaining it in his article ...

In our previous article, we implemented a server in Golang that gracefully reacts to termination signals. We presented the problems of the hello world version of the server, how to address it, but did not perform any verification. In this article, we’ll prepare an experiment on both the graceful server, and also the not-so-graceful one to contrast their behavior. The experiment is done in a macOS environment, but the same process will work in Windows and Linux. ...

Last week I had an interesting experience at work. An application that my team has been working on showed a weird bug with the latest build. It was very difficult to locate the source of the bug, and there were a plethora of commits between the last working build and the latest one (it’s actually terrible to let this happen, but terrible things happen all the time anyway). Finding the offending commit in this case could shrink the area that we need to look at. Lucky for us, git provides a very useful command exactly for this purpose: git bisect. In this post we’ll examine how the command works, and some of its common operations. ...

Golang provides excellent concurrency mechanism, including some built-in functionalities to run tests faster. In this blog post we’ll explore some useful techniques in running concurrent tests in Go. However, we will not cover basic knowledge of Golang syntax, concepts and how to write tests in Golang in this post. Basic tests Imagine we want to implement some helper functions for the slice data type. package slices // Unique returns true if slice does not contain any duplicates. func Unique[T comparable](slice []T) bool { exists := make(map[T]struct{}) for _, elem := range slice { if _, ok := exists[elem]; ok { return false } exists[elem] = struct{}{} } return true } // Exists returns true if elem is found in slice. func Exists[T comparable](slice []T, elem T) bool { for _, e := range slice { if e == elem { return true } } return false } We write some simple test cases to verify our helper functions as below. ...

Golang is a fantastic programming language with so many features supported out of the box. One such feature is a full-fledged HTTP server, which requires only a few lines of code to start. However, not many people are aware of the mechanism to gracefully shut down the server. In fact even Golang's official HTTP server tutorial does not mention this important feature. In this blog post we’ll explore a problem with the hello world version of the HTTP server in Golang, and how graceful shutdown addresses it. ...

DRY, which stands for Don’t Repeat Yourself, is a well-known programming principle. Many developers, however, misunderstand the principle, possessing a false grasp of what DRY is really about. In this blog post we’ll investigate a case in which DRY is misunderstood and applied in the wrong manner, and its consequences. A hypothetical code base written in Golang will be used to demonstrate the idea, but the syntax should be easy enough to understand even without Golang knowledge. ...

As a developer who writes Golang everyday, high productivity is of utmost importance. Intellij Goland IDE provides so many useful features to reach this goal: from viewing the current staged changes to running a debugging session. After working with it for a few years I believe that Goland is an essential part of my work, and I’m willing to pay for the annual license even if my company does not. More than just a text editor, Goland provides a bunch of helpful shortcuts to help us execute trivial tasks quickly. A few developers, however, are agnostic of these shortcuts, and use Goland like Notepad. ...

A commit can be signed locally before pushing to remote to ensure its authenticity. Why do we need that? Doesn’t the commit itself contain the author’s name and email? Well it turns out that it's possible to change the author's name and email of a commit. A signed commit, on the other hand, can ensure that the commit was originally made by the author who signed it using an SSH, or GPG, or S/MIME key. S/MIME key is more popular within the context of a large organization. SSH and GPG are simpler approaches that individuals can consider. The main difference between SSH and GPG signed commits is that a GPG key can expire, or be revoked, which results in the invalidation of the previously signed commits. ...