Blog - My thoughts and ideas
This article shows how to optimize a Docker image for a Ruby on Rails application both in terms of making the image as small as possible as well as how to improve the time it takes to create the image.
We’re in the middle of migrating a lot of our infrastructure components to AWS.
One thing that took me a while to wrap my head around is how to setup a VPC (Virtual Private Cloud) at AWS in a way that all our outgoing traffic is routed via a fixed IP address.
In this article I will demonstrate how this can be done, using Terraform to setup all required resources at AWS.
As we create more and more new service and require more and more infrastructure resources to support those services, we have started to use Terraform to manage our infrastructure.
In this article, I would like to give an overview of how we structure our Terraform setup.
It’s designed to build up a common vocabulary and understanding of why we do things the way we do them and provide a little bit of background information how and why we made the decisions that lead to the current setup.
As we’re using AWS to deploy our cloud infrastructure, most of the examples will relate to AWS but in principle should be provider-agnostic and can apply to other providers as well.
A few days ago I stumbled upon a discussion on Twitter of whether or not a local development environment should be kept identical to the production environment:
The original assumption in the tweet is by itself interesting: Did we actually have that rule? Keep the development environment identical to the production environment? Did it ever work?
From my personal close to 20 year experience in software engineering I never had the situation where a development environment actually mirrored the production environment.
And I would even go as far as to say: That’s a good thing!
Let’s dive into why I think that is.
In May I had the honor of having been invited as opening keynote speaker to the DevDays 2019 in Vilnius.
Luckily I also had the chance to see a lot of other great talks that made me curious about new technologies, showed me things I hadn’t thought about before and made me appreciate a few things I always took for granted.
In this post I would like to highlight a few of my favorites:
I’ve had the opportunity to be invited as speaker to several software engineering conferences during the last couple of years.
Interestingly, when talking about this to friends and colleagues a typical reaction when they hear this is: “Oh, I’ve always wanted to do that as well but I’m simply not good enough” or similar comments.
As I had the same doubts before actually doing it I’d like to lay out a few thoughts about speaking on conferences and why you are most likely good enough, no matter what you may think.
I have been developing applications in Java for the last 15 years.
I know the language, I know the API, I know all the important frameworks and at one point I even felt arrogant enough to talk about the Java internals at conferences.
But for BetterDoc I had to use Ruby as my main programming language.
I still try to sneak in a little bit of Java here and there, but Ruby is what I’m doing most of the time.
It feels a little bit like learning how to crawl again after having been an athlete.
It’s a mixture between excitement, frustration, and pure embarrassment.
The story I want to write about in this post falls into the last category: pure embarrassment.
Like many other professions software engineering has its own language, its own vocabulary and its own conventions.
However as software engineers in order to do our job well we need to collaborate with people outside of our own profession - which means we have to find a way to communicate efficiently so that we all understand each other.
As a software engineer having the right equipment (a powerful machine and high quality peripherals) is not simply a “nice to have” but an essential requirement. These are your main tools with which you’re doing your job - and everyone should want you to do that job as best as possible.