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.
Even though one of the famous Go proverbs says _a little of copying is better than a little of dependency_, sooner or later you will find yourself importing one into your project. You just cannot solve all the problems your application may be facing, and often it's better to defer to ready, battle-tested solutions. But how should you manage your dependencies? Since we've recently (finally!) saw the premiere of an official tool, dep, let's take a look on that.
I've been meaning to play with BoltDB for a very long time, recently I finally had some time to do so. Why? I often made a mistake of setting up a large database when starting some private project only to see most of my effort going there instead of the app itself. For starters, the simplest solutions are the best, and Bolt is an example of such. Let's check out how can it be used in a small project.
In the previous post, we've taken a look at the basics of creating CLI tools in Go using cobra library. This time we'll dive a bit deeper while creating something actually useful. We'll build a small Redis client that helps us to manage the state of our cache.
When I first entered the world of Go, I had trouble thinking what are the best use-cases for the language. I knew that I could build backends for web applications or microservices, but I've always thought that it's perfect for building CLI tools. Some time ago I came across a library that makes building those in Go super easy. Let's build such a tool using Steve Francia's cobra.
Writing technical documentation for the application is often more difficult, than creating its code. We, developers, know our craft very well, but when it comes to leaving some signs of how things work, how to use them, etc., we are surprisingly ineffective. On the other hand, when we are about to use some external dependency, we'd love to see examples of how it can be inserted into our code. How do we do that in Go?
One of the things that I missed the most, apart from generics, when coming to Go while having Java background was the lack of inheritance. In JVM it was pretty simple, as you can define a parent and child classes, then have a common behavior present all the children objects. This is not the case in Go, and I had to learn how to work around this. Here, we don't have inheritance, we have the composition, and for that, we have a pretty useful technique called embedding structs.
One of the things that Go community is the proudest of is the toolchain that is shipped alongside the language. Apart from dependency vendoring (this is in progress), you can run the whole show of taking your source code, testing it, cross-compiling, all the way to building a single binary output file. One of the lesser known tools that you should get familiar with is the one that "just" lists stuff...