Noah Clark

Your First Day with Elixir: Building Something Beautiful from Scratch

Sun, 01 Feb 2026 00:00:00 +0000

I’ve been a Ruby on Rails developer for most of my career. Over the years I’ve heard of the benefits of functional programming, but when I looked into it the syntax and approach seemed out of touch with the ergonomics that Ruby provides. Elixir helps to bridge that gap.

LazyGit and LazyDocker are growing in popularity so let’s build our own TUI, but instead of wiring it up to git or docker, we’re going to build a retro game inspired by the classic Drug Wars. The first part of this tutorial is about laying the groundwork you’ll need to continue to learn elixir with me.

Immutability Isn't Scary: Building Your First Elixir Data Structures

Sun, 08 Feb 2026 00:00:00 +0000

When I first heard that Elixir was “immutable,” I understood what this meant in theory. However, it took writing a bit of Elixir code to really understand what this meant. This section is focused on really getting at the heart of how to build with immutability at its core.

How do you write a game where the player’s money never changes? Where the inventory is frozen in time?

Today, we’re building a Player module that tracks money, inventory, and upgrades. We’ll write every test before we write the code it tests — so you’ll see the design emerge from what we want the Player to do, not from implementation details.

Map, Filter, Reduce: The Enum Module is Your New Best Friend

Sun, 15 Feb 2026 00:00:00 +0000

Coming from other languages, you might be used to writing loops. Lots of loops. for loops, while loops, forEach. They’re everywhere.

Elixir has a different philosophy. Instead of telling the computer how to iterate, you describe what you want to happen to each element. The Enum module is where this magic lives, and mastering it will fundamentally change how you think about data processing.

Today we’re building the core of our game: herb pricing, game state, and the actions that make HerbWars playable. By the end, you’ll be buying and selling herbs from IEx.

Organizing Your Elixir Code: Modules, Separation, and the Art of Not Making a Mess

Sun, 22 Feb 2026 00:00:00 +0000

Your game already works. You can buy, sell, and travel from IEx. But IEx isn’t exactly a polished user experience. Players deserve a real interface — status displays, market listings, menus, and prompts.

The key insight: we don’t touch the game logic. We build a UI layer on top of the pure functions from ch3. This separation — game logic vs. presentation — is the foundation of maintainable code.

One Module, One Responsibility

Each module should do one thing well. Our project now has:

Recursion Without the Headache: Managing Game State in Elixir

Sun, 01 Mar 2026 00:00:00 +0000

“Use recursion for your game loop.”

Many programming languages support recursion, but for the vast majority of my career, I’ve avoided it. Even when it seemed intuitive, I’d get feedback from other developers that this was exotic. Elixir changes that and turns recursion into an idiomatic approach.

The Game Loop Concept

Every game has the same basic structure:

Display current state
Get player input
Process action
Update state
Check win/lose conditions
Repeat until game ends

In languages with mutable variables, you might use a while loop that modifies a gameState object. In Elixir, we call a function that calls itself with updated state.

Time Travel Debugging: Why Immutable State is a Superpower

Sun, 08 Mar 2026 00:00:00 +0000

In ch5, we built a recursive game loop that threads state through every turn. Each call to game_loop/1 receives a complete, immutable game state and produces a new one. We treated this as an implementation detail — a way to avoid mutable variables.

But there’s something deeper going on. Because Elixir never mutates data, every game state that ever existed is still a valid, self-contained snapshot. If we hold onto those snapshots, we get something powerful: a complete, trustworthy history of everything that happened.

Game Mechanics: Random Events and Herb Effects

Sun, 15 Mar 2026 00:00:00 +0000

Our game has buying, selling, and traveling — but every playthrough feels the same. Time to add some chaos. In this chapter we’ll build two systems: random events that trigger when you travel, and herb consumption with effects that wear off over time.

Both follow the same pattern we’ve used throughout: build it with tests, keep the logic pure, wire up the UI last.

Updating the Player Struct

Before building new systems, we need new fields on the Player struct. Open lib/herb_wars/player.ex and update the struct:

From Hardcoded to Data-Driven: Loading YAML in Elixir

Sun, 22 Mar 2026 00:00:00 +0000

Our game has events, effects, and real gameplay — but every piece of content is hardcoded in Elixir modules. Want to add a new event? Edit code, recompile, hope you didn’t break something.

There’s a better way. By moving game content to external files, you separate what the game contains from how the game works. This chapter is a refactoring exercise: the game won’t gain new features, but it’ll become much easier to extend.

On naming events

Wed, 08 Apr 2026 00:00:00 +0000

The hardest part of analytics isn’t the pipeline. It’s getting six engineers to agree that user_signed_up and user.created and signup_complete are the same event. Name things once, in a spreadsheet, before you write a single line of capture code. The spreadsheet will outlast three refactors.

ETS tables at 3am

Sun, 22 Mar 2026 00:00:00 +0000

Spent an hour debugging why an ETS lookup was returning an empty list. The table existed. The key existed. Turned out I was pattern-matching on the wrong arity — the tuple had four elements, my match expected three. The BEAM doesn’t lie. It just doesn’t explain.

Capturing PostHog Events in Rails Without the Footguns

Sun, 15 Mar 2026 00:00:00 +0000

PostHog's Ruby SDK does what it promises. You call posthog.capture, pass a distinct ID and an event name, and data arrives in your dashboard. The getting-started guide takes five minutes. The next six months of living with it take considerably longer.

The gap between "PostHog works" and "PostHog works well in a Rails app that processes mortgage applications" is where most teams lose time. Not because the SDK is bad — it's fine — but because the integration patterns that feel natural in a Rails controller are almost never the ones you want in production. I have spent more hours than I'd like debugging silent event loss, duplicated captures, and properties that looked right in development but arrived mangled in production because of ActiveRecord serialization quirks.

Cover crops and dead code

Tue, 10 Mar 2026 00:00:00 +0000

Crimson clover fixes nitrogen in the soil for the next season’s planting. It doesn’t produce anything you harvest directly — it improves the conditions for what comes after. Good test suites work the same way. You don’t ship the tests, but everything you ship is better because they exist.

ETS Beyond the Cache: Three Patterns That Survived Production

Fri, 20 Feb 2026 00:00:00 +0000

Placeholder content.

The Sidekiq queue is a promise

Wed, 18 Feb 2026 00:00:00 +0000

Every job you enqueue is a promise to your future self that the work will get done. Most of the time, Sidekiq keeps that promise. But when it doesn’t — Redis restarts, memory pressure, a bad deploy — you learn very quickly which promises were load-bearing and which were decorative.

The Math Behind Sidekiq Retries

Wed, 28 Jan 2026 00:00:00 +0000

Placeholder content.

A Naming Convention for Analytics Events

Sat, 10 Jan 2026 00:00:00 +0000

Placeholder content.

GenServer Timeouts Are Not What You Think

Mon, 15 Dec 2025 00:00:00 +0000

Placeholder content.