They have been available for some time already, but I forgot to share the link! The videos from Gophercon UK 2018, including my _Documenting Go Code with Beautiful Tests_ have been published on Youtube! Enjoy!
The latest release of Go, 1.11, was one of the largest in a long time when it comes to functionality. One of the headlines of this version were modules, which were very hyped and hated at the same time, since the community is divided into "modules team" and "dep team". While I feel that dep solves the problems I face on the daily basis, I decided to give the other approach a chance. Let me show you how you can build a small, sample application using "go mod".
When I was first introduced to Docker, I was excited to see how much easier this can make developing eg. Java applications. Setting up the whole environment was brought down to a set of simple commands allowing me to spin it up without any fuss. But after spending some time with Go, which compiles to static binary files, I was wondering if I really need Docker containers to run them efficiently? This led me to a little experiment with "launchd".
If I wanted to sum up my experience at GopherCon UK 2018, I would probably say something like _awesome_, _unforgettable_ and _amazing_. But those three words would not fully explain everything I saw and felt during that time. It was super-exciting for me, being a first-time speaker at a Go conference. It was also incredibly stressful because even though I'm pretty confident about my English skills, it's something totally different to use it with other people for whom the language is not their native one. Standing on a stage in front of a few hundred people, and butcher the native langue of many (most? half? I have no idea) of them, that was scary. I heard that my jokes got some laughs, so maybe it wasn't that bad. Or they laughed at me, but at this point, it's too late to feel bad about myself. Anyway, I would like to share my thoughts on four of the most important elements of my London experience.
Hi there! This is just a quick and short post to keep you guys updated on what is happening with this blog and myself. I'm getting ready for GopherCon UK, and it takes much more time than I thought.
So far we've managed to play with NATS pub/sub and extended it with streaming service to create a more reliable messaging queue. The problem is, that by using the default configuration, we have little to no control over where the messages, subscriptions, and information about queue's clients reside. Fortunately, NATS Streaming allows you to use SQL database as a storage, which we will explore in this very post.
In the previous blog post, we've taken a look at how NATS works in general, we created a pub-sub connection between two services allowing some kind of communication. The problem was, that it only worked when both publisher and subscriber were working at the same time. What if we want to allow particular pieces to go down, get redeployed and updated, but still maintain all the messages so that they are processed once the receiver wakes up? This is where we need NATS Streaming.
When building a microservice architecture, you have basically two ways you can build communication between its elements. First, the obvious one is to make services call each other directly via eg. using HTTP endpoints, while the other is to have a message bus/queue where one app publishes a message, while others read it. This post explains the basics of one of the message bus solutions, NATS.
From my experience, there are two main use cases for Docker: creating an output container with the applications that can be deployed somewhere, and creating a container with development dependencies (eg. language, database versions) that allow you to build/compile it without having everything installed on your machine. You can do both at the same time, but it used to result in huge images that go to production. Thankfully, there is a better way now - multi-stage builds.
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.