Wait wait wait, so we’re not talking about nix yet?

Well, no! The service we have is pretty simple, and I want to complicate things a bit, to show how things would work in both the Dockerfile and the nix scenario.

And because I don’t like contrived examples, we’re going to do something somewhat real-world: we’re going to geo-locate visitors, and track how many visits we get from each country.

In the previous chapter, we’ve written a Dockerfile to build the catscii service inside Docker. The result is a container image that can be pushed to production!

Now that our service is production-ready, it’s time to deploy it somewhere.

There’s a lot of ways to approach this: what we are going to do, though, is build a docker image. Or, I should say, an OCI image.

This is still a series about Nix, but again: because the best way to see the benefits of Nix is to do it without Nix first, we’ll use only Docker’s tooling to build the image.

Our catscii program does everything we want it to do, except that it’s a command-line application rather than a web server. Let’s fix that.

Enter axum

The documentation for the axum crate tells us how to make a basic web server, and we honestly don’t need much more than that.

So let’s add axum:

amos@miles:~/catscii$ cargo add axum@0.6 Updating crates.io index Adding axum =0.6 to dependencies. Features: + form + http1 + json + matched-path + original-uri + query + tokio + tower-log - __private_docs - headers - http2 - macros - multipart - w

Now that our development environment is all set up, let’s make something useful!

Creating the catscii crate

From a VS Code window connected to our VM (as we just set up), let’s make a new Rust project:

amos@miles:~$ cargo new catscii Created binary (application) `catscii` package

And open it in a new VSCode window:

amos@miles:~$ code catscii

Even though we’re running this “code” command in the VM guest, VSCode set up enough plumbing that it communicates back to the host, telling it to open another VSCode window, connected to the same SSH remote, in the right folder.

Some bugs are merely fun. Others are simply delicious!

Today’s pick is the latter.

Reproducing the issue, part 1

(It may be tempting to skip that section, but reproducing an issue is an important part of figuring it out, so.)

I’ve never used Emacs before, so let’s install it. I do most of my computing on an era-appropriate Ubuntu, today it’s Ubuntu 22.10, so I just need to:

This time around, we’re porting a solution from C++ to Rust and seeing how it feels, how it performs, and what we can learn about both languages by doing that.

See Day 17 for the rationale re: porting solutions rather than writing my own from scratch. TL;DR is: it’s better than nothing, and we can still focus about learning Rust rather than spending entire days fighting off-by-one errors.