Last week I started to challenge myself with #100DaysOfCode. During the week
I wrote a Twitch Bot that connects to a list of twitch channels and monitors channel
followers and provides some statistics like time watched. Common enough, the follower API provides the time
when the user followed the channel and in order to store it to the database with Go, I wanted first to
convert it to a time.Time.
Slices are tricky. If you have been using Go for a while now, you may be aware that a slice is basically a triplet consisting of a:
This makes working with slices also a bit different than working with structs.
There were a couple of things that didn’t make sense to me initially in terms of optimisation of Go code. I’m going to try to list some of them that I found more interesting and you should be aware of this if you’re really working hard to optimize your Go program for performance or memory usage.
Benchmarking is an important step in writing software. This may extend beyond the scope of your Go program, but attention should also be given to the Go program itself. If you’re writing APIs or if you’re implementing a parser for a specific file format - benchmarking will tell you how performant your implementation is.
For those of you not familiar with Hugo, it’s the tool with which I’m generating this blog. Hugo is a static website engine similar to Jekyll or Hexo if you’re familiar with those. You write your content in markdown format, and it generates a set of static files, from which your blog is served. It’s written in Go and it’s very fast.
Setting up a Docker Swarm (“docker swarm mode” if you want to be more accurate), is pretty much a trivial process. You need 3 nodes, create a swarm on one of them and join the other two nodes to the swarm. Simple. What if you wanted a 100 swarm nodes? How fast can you provision new nodes to scale up your Docker Swarm?
