Rolling your own GitOps: DNS Zone files

I like to self-host my own infrastructure. You have full control. You learn a lot. It is also not hard to get started.

Managing your infrastructure though, wow, what a pain. Take DNS. To make a simple DNS record change first I have to edit the zone file, which is manual, but feels technical in a good way, like I am in control. Unfortunately the process only gets more tedious from there. First I commit the change and push it up. Then I SSH into my server and pull down the changes. Then I rebuild the Docker image. Then I kill the running container and start a new container with the new image. Then I SSH into the other server–you always need redundancy with DNS–and repeat the same steps again.

So tedious. Compare all that with a hosted DNS service, where you log into the web interface, tweak the record, and… that’s it.

Maybe there is a way we can have the best of both worlds. GitOps would be a good fit here. Like what if all you had to do was edit the zone file and commit the change, then let every step after that be handled automatically. You know, it probably wouldn’t be that hard…

system diagram

Continue Reading

How to host your transactional email for free

engineer with server

Everyone knows that if you want to send transactional1 email you should use a dedicated service like Twilio Sendgrid, Mailgun,2 or Amazon Simple Email Service (SES). First, they’ll scale. Second, they take care of all the details you’d rather not have to think about. At the other extreme–when you’re launching the proverbial weekend project–you can plug in your Gmail account credentials and call it done.

I am not here to dissuade you from the received wisdom of the internet.

Still, in my contrarian nature3 I feel compelled to point out a middle option: you can run your own MTA (specifically an email relay). It may not be a better option for the typical app, but it offers some advantages4 all the same. This post is not about selling you on self-hosting. What it is about is showing you how much simpler it is to self-host a transactional email server than most people imagine.

Continue Reading

Banish the word “nitpick” from code reviews

coworker nitpicking work

If there were a competition for who leaves the most pull request (PR) comments during code review, yours truly would be the winner.1 Some of those comments are spotting immediate bugs or asking clarifying questions. Just as commonly however, the comments are optional naming suggestions2, discussion starters, and even–gasp–style feedback.

I have to bring all this up because–sometimes when people advocate for “no nitpick” reviews what they really want is a culture where PR review feedback is exclusively on function, with readability improvements considered out-of-bounds. That couldn’t be further from the truth for what I am about to advocate. With bona fides out of the way…

Don’t use the word “nit” in your code reviews. Don’t let your teammates use it either.

Continue Reading

Maybe you don't need React – Rediscovering the Vanilla DOM

geordiposting meme - virtual dom vs vanilla dom

Continue Reading

Stacked branches with vanilla Git

The first rule of stacked branches1 is don’t use stacked branches:

  1. Make small changes
  2. Work closely with your teammates to get the changes merged quickly
  3. Profit

Alright, so you didn’t take the advice. Maybe you are making a big change that has to be worked as one big change, but you want to slice off pieces for reviewability. Maybe your teammates are slow to review your changes. So you put your first branch up for review, then you create a second branch off the first branch to keep working, then–if you’re a glutton for punishment–you create a third branch off your second branch, and so on.

Anyone who has set up stacked branches knows what a pain it can be to manage. The initial setup is easy. The problem comes when there is a merge conflict between your stack and the main branch. Or what happens when you need to pull in a change that got merged to main.

If you haven’t been keeping up with new Git features, your workflow probably involves a lot of git checkouts,2 lots of git rebase commands, maybe commit counting like HEAD~123, or cherry-picks or who knows what other tedious work. Even after all that you probably missed something and now one of your PRs shows a bunch of duplicate commits.

It is 2023. There is a better way.

Continue Reading