Writing Rust is pretty neat. But you know what’s even neater? Continuously testing Rust, releasing Rust, and eventually, shipping Rust to production. And for that, we want more than plug-in for a code editor.

We want… a workflow.

Why I specifically care about this

In Veronica Mars and password hashes, from my new Tech As Seen On TV series, we’ve explored “cracking passwords” using brute-force methods, and then using rainbow tables, which was much, much faster.

But how do rainbow tables actually work? Let’s start at the beginning.

What’s a password hash?

A very simple design for an authentication system is to store passwords in clear text, say, in a file named password.txt:

Time for another Advent of Code 2020 problem!

That one sounds like it’s going to be fun. Our input is pretty much assembly, like this:

nop +0 acc +1 jmp +4 acc +3 jmp -3 acc -99 acc +1 jmp -4 acc +6

So, the first thing we’re going to do is write down some types.

There’s more than one way to approach this problem, but let’s go with this:

#[derive(Debug, Clone, Copy)] enum InstructionKind { Nop, Acc, Jmp, } #[derive(Debug, Clone, Copy)] struct Instruction { kind: InstructionKind, operand: isize, } type Program = Vec<Instruction>;

On September 8 2025, around 13:00 UTC, someone compromised Josh Junon’s npm account (qix) and started publishing backdoored versions of his package.

Someone noticed and let Josh know:

Josh confirmed he’d gotten pwned by a fake 2FA (two-factor authentication) reset e-mail:

The phishing e-mail came from npmsj.help (registered 3 days prior) and claimed users had to reset their 2FA:

Let’s tackle the day 16 puzzle!

Parsing

The input looks like this:

Valve AA has flow rate=0; tunnels lead to valves DD, II, BB Valve BB has flow rate=13; tunnels lead to valves CC, AA Valve CC has flow rate=2; tunnels lead to valves DD, BB Valve DD has flow rate=20; tunnels lead to valves CC, AA, EE Valve EE has flow rate=3; tunnels lead to valves FF, DD Valve FF has flow rate=0; tunnels lead to valves EE, GG Valve GG has flow rate=0; tunnels lead to valves FF, HH Valve HH has flow rate=22; tunnel leads to valve GG Valve II has flow rate=0; tunnels lead to valves AA, JJ Valve JJ has flow rate=21; tunnel leads to valve II

I wanted to take some time to write about a piece of software I’ve been working on lately, just so you know how I’ve been spending the last few weeks.

Rationale

A few years ago, I designed a programming language: ooc. Even though I’ve done my fair share of Java, C, Ruby, JavaScript, and even some Perl, Scala, Python, PHP, etc., I still find myself going back to ooc because it gives me access to C libs, relatively high-level constructs, and it forces me to write code that’s not too smart.

Welp, I did it again - I released an album: it’s named *andfall, a play on the word “landfall”, and I wrote it in one week-end, for @McFunkyPants’ entry in the Ludum Dare 33 game jam.

It’s my first solo album, the previous ones were collaborations with @bigsylvain and @geckojsc. It feels a bit weird to release an album alone - there’s nobody to blame for the flaws, and nobody to praise for the good parts!

Learning Rust is… an experience. An emotional journey. I’ve rarely been more frustrated than in my first few months of trying to learn Rust.

What makes it worse is that it doesn’t matter how much prior experience you have, in Java, C#, C or C++ or otherwise - it’ll still be unnerving.

In fact, more experience probably makes it worse! The habits have settled in deeper, and there’s a certain expectation that, by now, you should be able to get that done in a shorter amount of time.

The day 7 challenge talks about trees! File trees that is.

The temptation to solve it before starting to write this article so I don’t look silly is high, but I’m explicitly not doing so, so that we can bang our collective heads against any walls at the same time, and see how we can get out of it! Trees are serious business!

Part 1

The sample input looks like this:

In Part 11, we spent some time clarifying mechanisms we had previously glossed over: how variables and functions from other ELF objects were accessed at runtime.

We saw that doing so “proper” required the cooperation of the compiler, the assembler, the linker, and the dynamic loader. We also learned that the mechanism for functions was actually quite complicated! And sorta clever!