At my current project we’ve been building three different applications. All three applications are based on Spring Boot, but have very different workloads. They’ve all reached their way to the production environment and have been running steadily for quite some time now. We do regular (weekly basis) deployments of our applications to production with bug fixes, new features and technical improvements. The organisation has a traditional infrastructure workflow in the sense that deployments to the VM instances on acceptance and production happen via the (remote hosting) provider.
I think it was around 2009 when I started reading a book called Clean Code by Robert C Martin (a.k.a Uncle Bob). I found the book on a so-called ‘top 10 must-reads’ for software engineers. I really enjoyed reading that book. It had a pleasant writing style, well structured and provided some valuable insights. A few years later “The Clean Coder” was published and what appealed to me this time was that it was a book about some of the other aspects of our trade: professionalism, handling pressure, clear communication, etc. If you have not read it yet or are looking to improve some of your softer skills I would recommend reading it.
Last week I visited AWS Summit Benelux together with Sander. AWS Summit is all about cloud computing and the topics that surround cloud computing. This being my first AWS conference I can say it was a really nice experience. Sure there was room for improvement (no coffee or tea after the opening keynote being one), but other than that it was a very good experience. Getting inside was a breeze with all the different check-in points and after you entered you were directly on the exhibitor floor where a lot of Amazon partners showed their products.
Three weeks ago I presented at Luminis Devcon 2018 about the challanges of designing and documenting REST APIs. The reason I gave this presentation was that about 8 months ago I started on a new project for which my team had to develop a public facing REST API. Having a good documentation for such an API is very important, since users will read the docs and have an opinion about the usage and correctness of such an API. During my presentation I went into the lifecycle of an API and how to maintain the documentation in such a way that it’s always in sync with the actual API, since these can easily drift apart.
I’ve been trying to make this a tradition, but last year I had too much going on in my personal life, which resulted in skipping my ‘year in review’ post. 2016 was really hectic, but everything seems to be back on track now. To shed some light on what happened professionally let’s take a very quick run through 2016.