A few years ago I personally attended a talk delivered by Tony Hoare. Amongst other things I very much enjoyed his remarks on performance. I hope I will never forget and never fail to act on his famous quote "premature optimization is the root of all evil". I have seen the horrible results of hand optimizing Go code by default and I want to avoid that my codebase looks anything like that. Today I like to get started with some performance checks of the Go codebase I have been working on. Of cause I start with some profiling...

(read more …)

With better technologies, infrastructure and tools the database gets more and more attention. This is especially relevant with todays NoSQL movement in mind. Within this context scalability is a central subject of discussion and consequently performance is getting more important, too.

(read more …)

When I start a new project I begin by working on the interfaces like command line, services, plugins, etc. (the APIs). Once my API draft is good enough, I started writing tests. And I had to find out recently that Testing in Golang takes a little bit more attention than usual. Workarounds for bad design like mocking and monkey-patching are not readily available in Go like they are in dynamic languages. Many testing remedies are already available in Golang that promise to ease the pain but the general advice is not to use them. Instead one should make ones code testable and use the standard testing tools that are shipped with Golang itself. As always tools are a matter of taste and personal preferences - I wanted to do it in the recommended way.

(read more …)