Coding Infinity

I love Infrastructure as Code. I popularized it in the company that I work for - all of our projects now start with the infrastructure codified. I’m also trying to move all of the company’s shared (e.g. self-hosted CI tools) infrastructure definitions to code. I’ve had my share of clicking on the web panels and writing CLI scripts to manage the cloud. I still think doing this manually is much faster for quick fixes or some temporary changes but to make it sustainable, maintainable and discoverable you have to make it declarative - so codify it, as everything else!

My tool of choice for IaC is Terraform. There are other solutions available on the market (ARM, CloudFormation, Pulumi, …) but that doesn’t really matter here now. The point is - as with everything - IaC is better when applied automatically. 🙂 And here comes Terraform Atlantis, a “pull request automation” (basically CI/CD 😉 ) for Terraform.

Atlantis is a great tool, really, but it is quite simple. It does one thing and does it well but it lacks “corporatey” things that I, unfortunately, need - multitenancy. But fear not! Atlantis can be scripted so we can easily add that ourselves on top of it. So welcome kvenv, a simple tool that allows you to juggle credentials in order to shield yourself from others (and probably yourself too 🙂).

Firestore, being part of Firebase suite and having its roots in Firebase Realtime Database, is another offering from Google (they acquired Firebase in 2014) that wants to ease app development. It is a document database, but this one prides itself in being for backend as well as mobile & web development. Integration should be seamless, everything should work out of the box and all the problems with “ordinary” databases will be solved for you. :)

This won’t be another post that glorifies Firestore. I worked with it for quite some time now. I’ve seen it being used in other projects as well. In all cases it was more of a burden than a relief, at least in the beginning. I think I know why, but let’s dig into it a little bit, shall we?

It’s been more than two weeks since the DevConf 2019. Last year’s edition was a blast (even though I haven’t written about it) and I couldn’t wait to attend it this year. This time I won’t make the mistake and will use the conference as a topic for my blog post (have I said that maybe this time I will blog regularly?). :)

DevConf is a great conference - perfect organization, no main topic, no single language and the diverse speakerbase make the conference unique. Just like last year, I came back home pumped and ready to face new problems. Who needs anything else? ;)

This post is also available on my company blog on Medium.

This is a follow-up post to the one I’ve written last week. I’ve showed there how to leverage Docker and Let’s Encrypt for easier HTTPS on localhost but that solution required developing your app inside a container. I personally prefer that option but sometimes the tooling is not so well suited for work inside container (e.g. webpack + Docker for Windows). For that we need to take a little different route.

Some time ago Scott Hanselman described how to setup self-signed certificates for localhost using dotnet dev-certs. Having SSL on localhost is, for me, a must-have since we all want to have our dev env resemble production as much as possible. The approach Scott showed is great but it might be a little bit hard to use on Linux. On Linux-based systems there are multiple libraries, multiple (probably embedded) stores and hundreds of options to configure all of this. I’ll show you an another approach that will allow to develop apps locally with full SSL/TLS and nice addresses.