Backend engineer, interested in Ruby, Go, microservices, building
resilient architectures and solving challenges at scale. I coach
at Rails Girls in Amsterdam,
maintain a list of small gems
and often contribute to Open Source.
This is where I write about software development, programming languages
and everything else that interests me.

Data structures and algorithms are the bread and butter of computer science.
Although sometimes they appear scary to people, most of them have a simple
explanation. Also, when explained well with a problem algorithms can be
interesting and fun to learn and apply.

If you have ever tried writing a daemon for MacOS you have met with launchd. For
those that don’t have the experience, think of it as a framework for starting,
stopping and managing daemons, applications, processes, and scripts. If you have
any *nix experience the word daemon should not be too alien to you.

Recently, while writing a small Golang program for setting reminders I came
across a small confusion that I guess most newcomers to Golang will have - how
to organise a package in a way that will enable it to cleanly contain two or
more binaries.

Nowadays, having an API on top of your application is considered common.
I’ve often been disapointed when I’ve been expecting an API of a product I like
to find none. There are powerful tools out there that allow easy API
integrations, like IFTTT.com. Also, if you want to build a mobile application to
work aside your product (or maybe your product is mobile-first), then an API is
a must-have - there’s no way around it.

Have you ever found yourself publishing an API, either an internal or a public
one? Have your ever heard from the consumers of those same APIs back? Are they
happy about the functionality of your APIs and their design? You already know,
there is no perfect design, but API design has to be taken very seriously. Why?
Because evolving and changing APIS is hard and time consuming.

The web, as we all know, is driven by APIs. Since the rise of mobile applications
and the JavaScript driven single-page applications, APIs became even more
popular, as a unified way for the clients to communicate with the back-end. Most
of the companies use internal APIs for different purposes. Some use them to
expose resources, data or behaviour. Others, use them for authentication and
authorisation, some do it for controlling the hardware layer with smart
implementations under the hood. Overall, APIs are enablers that allow various
clients to utilise the same back-end logic.

Starting a greenfield application everyday is nearly impossible, especially in
your daily job. In fact, most of us are facing (somewhat) legacy codebases on a
daily basis, and regaining the context of why some feature, or line of code
exists in the codebase is very important. This is where git, the distributed
version control system, is invaluable. Let’s dive in and see how we can use our
git history and easily navigate through it.