At Contiamo I am currently working a project that will eventually integrate with OpenFaaS. I am really excited about this project because we will soon bring some serverless magic to data scientists that use Contiamo. That is, once I figure out how to deploy a private Docker registry inside a Docker Swarm.
At the beginning of the month I left Teem I was Director of Engineering and it was and still is a great company. There are some amazing developers there, so if you are looking for a job in SLC, hit them up. This weekend (Aug 5) I will be moving to Berlin to start a new role at Contiamo and will be working on the Labs feature.
Ever have that feeling you are forgetting something right as you leave work? You are probably thinking about your keys or your lunch box but I am talking about your SSL certificate. They don’t last forever, we know this when we setup SSL but that doesn’t stop it from sneaking up on us. It has happened to the big guys like Instagram and Google, at Teem recently, and of course for myself with my own home server.
Recently, I have seen several articles talking about RESTful API design. Of course this is also a common topic of discussion for the engineers at Teem. I want to use (and write) APIs that are easy to understand and explain and the fastest way to complicate your API is nested routes. Just don’t do it! Do not create nested routes in your API. Let’s keep our APIs simple and create one endpoint per resource and if filters are needs, use GET parameters. This is simpler to document and simpler to maintain and ultimately, easier to use.
Perhaps the one piece of ubiquitous technology that you will find at any new
tech company is
git. There are a couple of other technologies that you will
probably find, like AWS, but
git is the only one I expect to find everywhere. It is
also, surprisingly, many developers number one frienemy. I want to share some
of my favorite tips and tweaks that I have used over the years to make it all
friend and never my enemy.
At Teem, we aim for zero down-time deploys; so, one of the most important things we must validate is that things will not break mid-deploy!
The most sensitive step of the deploy process is the changes to our database. Prior to the automation I am about to describe, validation of the database migrations required specialized knowledge about Postgres, the changes to the application model, load on the database for that model, and a bit of general experience. This obviously slows down reviews and subsequently deploys. Worse, it was simply too easy to miss problem migrations when depending on only peer reviews. To make our lives easier we created a series of validation checks to ensure that each database migration will be backwards compatible.