Hello folks!

While working at Red Hat I had the awesome opportunity to brush up my Go skills on a daily basis again, and I stumbled across a lot of interesting technical problems.

One of these problems struck my attention so much that I started playing with it on my free time and I came up with ez. This is a pet project, but I wanted to let people know I’m on it in case its going to be useful for someone else and/or if you wanna get involved and contribute!

Configuration management is such a fun problem to solve! You can use libraries like dynaconf (Python) or viper (Go) and they’re super fancy and will probably provide everything you want (and a bit more).

Today I wanted to code, though. For a pet project, I wanted something as simple as: well, try to get this configuration from env vars, and try to look in a secret manager for those you can’t find. I wanted no dependencies for this small task, for this small project, and for those starting with configuration management, it might be a fun way to understand the power those libraries can give you.

DISCLAIMER: This has nothing to do with a certain famous book that also speaks about Clean Code. Nothing. I’m talking from the experience of writing lots of bad code throughout the years, of lots of research on how to do it better while writing Go code and these examples do not necessarily apply to any other programming language.

This is the third post of a series that started here based on a talk I gave about Go and Clean Code(slides here, in Portuguese).

This is a second post of a series that started here based on a talk I gave about Go and Clean Code(slides here, in Portuguese)

Now I’m gonna talk about package names and how to choose package names in the Go way.

First of all, packages in Go is how Go code is organized. It is similar to a Python module and pretty much the same as a Java package, a C# namespace or a JavaScript component. It is a folder containing code that, in a good software architecture, has something in common.

Hi.

I spoke about Go and Clean Code in a couple of meetups and at the last Gophercon Brasil in 2019 (slides here, in Portuguese) and I am now breaking the presentation in a series of posts, starting with this one, to explain what kind code is considered clean in Go. The motivation behind this is to share a little after years of writing Go code on what kind of practices are considered good / bad.