Some time ago I ran into an example source code of the standard library with some interesting approach to writing unit tests. At first, it felt strange, but I decided to apply it to my everyday routine and realized how awesome it is. I always put readability of my source code as a top priority, that's why I adopted custom check functions in my tests.
Recently I've been working with an internal Go tool that uses environment variables for accessing user credentials that are being used to authenticate. While I find that very handy, I was wondering how difficult would it be to add the functionality of providing the password manually, but in a safe (non-displaying) way. As it turned out, it cannot be any easier!
One of the first things I've learned when starting working with Go was that it has so-called _proverbs_. They are a list of rules, which sound like some smart quotes, which should guide you during your journey. For a long time, I didn't quite understand why I should _accept interfaces but return structs_. I wanted to return interfaces as well since this would define what my return type does, not what it is exactly. It struck me almost a one full year or working with Go exclusively, how wrong I was. This post explains my line of thought, I hope it might save some of you sometime before you have your _Aha!_ moment.
We've already seen the basics of Vault and wrote some code to access it in the last posts, this time we'll focus on two aspects that allow us to have more control over who can do what with our vault. Let's dive into it.
I the previous post we talked about the basics of Vault, its architectural concepts, nomenclature and basic operations that can be performed. Now it's time to turn that theory into practice and write some code in Go that will allow us to access our secrets.
We all have something to hide, I think everyone has to admit that. Being a developer you need to store lots of passwords, tokens, addresses and other pieces of information that you should not reveal to anyone. You could keep them all in a text file, but a part of you knows that you really should not. What are the alternatives? Let's look at one of them, Vault, which is an awesome project by Hashicorp.
Building web applications take much time, but what if you want to create a small website, like a business card? If you are fine with a simple, static content and you are a developer, there is just a perfect place to have it set up in seconds. This post describes how you can create your own site using Github.
One of the things developers like about Go is that it has strong typing, which means that the compiler takes care of making sure that if you expect a string or a number, you will get one. Unfortunately, this approach has limitations, for example, it would be difficult to parse JSON structures since they come from the "outside world". This blog post shows how you can use one specific package from the standard library so that you can handle situations like those.
I've never been any kind of expert on software security, but I've always known that HTTPS beats HTTP at all times. I know that the communication in the latter is not encrypted and your data can be stolen. I always thought that it takes a great deal of effort to secure the connection, but lately, I discovered how little you actually need, thanks to Let's Encrypt and Caddy.
When building a library or an application in Go, we should care about having all our dependencies defined or included in the repository. If we depend on some third party code to work in a certain way, we should have some specific configuration saying that those are the versions that allow our core do its part correctly. With dep, Go's official vendoring tool it is a bit tricky since all the dependencies are moved to one place and then used across all the code. This raises a problem if we have one library in two different versions imported in two places at the same time. Fortunately, we can do something about that.