I built sudokurace.io in about 30 hours over a long weekend. It’s an entirely free sudoku board where multiple people can play on the same board at the same time. In this newsletter post I wanted to go over the architecture behind it and how I solved my various problems!

Side note: I shared it on Hacker News as well as on some of my social accounts and it got a little attention. Page analytics are entirely public and open to view.

The back story

I’m a casual fan of playing sudoku. I’ve always had cycles of interest where I’d play a lot for a while and then put it down for months or years. It’s been nice as an airplane hobby where you can buy a little booklet or have an app and offline a bunch of puzzles to work on. I’ve always liked that you could stop working on a puzzle and pick it up whenever you wanted and generally you didn’t have to worry about getting back into context or anything like that. I had a math teacher in high school who would always put up a new puzzle on one of her whiteboards and let anyone who wanted to try to solve the puzzle. I would sometimes be in her room during my free period and eventually I started to work on the board just out of boredom and curiosity. A friend of mine would sometimes join me and it would always become a race. We never said it, we never acknowledged it, but it would become a race. We would be trying to find new numbers in before the other person and it always felt competitive.

I was recently accepted into the Tesla full self-driving beta program. This was about 2 weeks ago and I probably been in the driver seat while the car is been driving for about 300 to 350 mi now and I wanted to share some initial thoughts that I've had with the behavior of the car.

Firstly, I'm not officially affiliated with Tesla in any way but I do own some stock with Tesla. I definitely identify as being a fan of Tesla overall for what it's worth, so keep that in mind as I share my opinions.

Building containers is easy when your applications are small. I’m usually doing projects in Golang, but at work we’re a monolithic Django application and after we install all our system dependencies and application dependencies, we end up with a 4.5GB container. It takes a while to build and even longer to push the container. Because of that, I started re-reading any literature that I could find about improving your Dockerfile usage.

It comes as no surprise that the first thing everyone tells you to do is to try using multi-stage builds. It makes sense. In a language like Go, you can download all of your dependencies in one stage and then copy your binary out to the stage that’ll actually be your container image. Unfortunately, Python ecosystems don’t work quite like that. You can install everything into your virtual environments, but there isn’t quite the same concept as a single binary. There’s a project called pex which does something close, but building a pex artifact just reduces everything into a single file which can help but doesn’t actually reduce the size of anything. This is kind of an over simplification but the pex format can be thought of as simply zipping up the virtual environment. You still include everything.

I just recently created abatilo/pulumi-composite-actions which is an adapted version of the official pulumi/actions.

They’re largely the same in terms of end result but with some minor changes.

I didn’t have anything interesting to say for a first post. I more just wanted to say hello! I do have a couple of draft posts already though.

For a while, I’ve had a pretty dead “blog” on my website. I’ve opted to make my website more focused on what I’ve done and about me, and I want to use a newsletter format for longer form writing. Since I want to keep the newsletter archive available, it’s kind of like a blog anyways. It did always feel weird to have my blog post drafts just be available on my blog’s GitHub repository anyways.