How I DOSed this newsletter.

I knew better than to fly fast and loose with a DNS update and redirect tooling, but I did it anyway. How I failed and then won.

I have a confession to make. I did something dumb early this week. I broke all the links on this substack for a few hours. I DOSed myself. I knew better, but I did it anyway. Now everything works, and I learned a few things along the way. This short story is about time constraints, hubris, and attempting to be too clever before taking a step back and doing the obvious and simple thing that works.

Substack supports custom domain names, and I initially chose: funcimp.biz. I picked it because it was short and because .biz domain names might be one of the funniest and most 2001 things to come out of 2001. I also own the more verbose functionallyimperative.com that I am using now.

Swapping out the domain name and not breaking links for a website can be tricky. To make the switch seamless, you need to update your DNS records and do some redirect magic so that you don’t break links to the old domain name. None of this is complicated unless you get tangled up in being too clever, precisely what happened to me.

When you create an account on substack, you get a subdomain; mine is https://funcimp.substack.com (it’s OK, you can click it, and it redirects). If you create a custom domain on substack, they do some DNS, SNI, and redirect magic so that all your links “just work” with your new custom domain, and if you happen to reference the old substack one, it redirects to your new fancy custom domain.

But I couldn’t leave well enough alone. I wanted everything to update to https://functionallyimperative.com, but I wanted the substack subdomain and my old domain of https://funcimp.biz to all do the magic redirect. Substack is happy to swap custom domains but doesn’t support resolving your old custom domain after the switch.

Swapping out the domain names on Substack’s side was dead simple. I was able to get the site working with the new domain in no time. My real issue was when I tried to be too clever under time constraints with my custom redirect. Once I switched over, any https://funcimp.biz link was broken until the issue was resolved. The new URL and the substack subdomain worked, but any link folks had between the two was broken.

Oh yeah, big-brain move; I decided to do all of this in one hour before I needed to head out to a tech event I’d organized (a two-hour event). At first, I tried using what I thought was a clever serverless option using an API Gateway and an AWS Lambda function. The Lambda function worked quite well. It was expressing 301 redirects that handle paths in six lines of code.

export const handler = async event => {
    return {
      statusCode: 301,
      headers: { "Location": process.env.REDIRECT_HOST+event.path}
  };
};

But I got tangled up in some DNS issues with the API gateway and couldn’t resolve the problems under time constraints. Finally, I ran out of time at my wit's end and had to leave the links broken for around three hours.

When I got home, I knew the clock was ticking. So I had a choice: beat my head against the wall on DNS issues while my links were broken or turn to a more straightforward choice. So I turned to a simpler and more pragmatic solution: Caddy

Caddy is awesome. It has many uses, but I just needed simple redirects that persisted in the URI paths. My Caddyfile is dead simple:

funcimp.biz {
	redir https://functionallyimperative.com{uri}
}

That’s it. Once deployed: problem solved, links restored. I’ve got Caddy running on a super cheap ARM-based t4g.nano that costs around $3/month while I sort out my long-term goals. I would love to fix the API Gateway stuff at some point (there are long-term HA and scalability advantages to that), but under the time constraints, I should have reached for caddy in the first place.

This week’s shareable links.

My Approach to Building Large Technical Projects

Mitchell Hashimoto (founder of HashiCorp) writes a beautiful post on his blog about how he breaks up large projects into consumable chunks. It’s a pragmatic guide that I enjoyed reading. He uses an example of his zig based terminal emulator project, which looks neat.

My favorite quote from this post:

I know a lot of people find shipping motivational. I don't think you need to ship a project for it to be successful.

How This Building Powers the Internet

Stewart Hicks channel on Architecture is fantastic, but this video is an intersection of architecture and internet infrastructure, and it just checks all the boxes. I think it's worth checking out.

The Brick Factory Problem

Numberphile covers great math topics, and this is no exception. This is a crucial math problem that affects folks like circuit board designers. Interestingly, a fully generalizable proof hasn’t been made yet.