The nudge that actually got me going came from Wes Grimes (@ncfrontiersman). He mentioned, tongue in cheek, making something called OmaBudget for Omarchy. I bit, and said “Yes, I need this for Rails!”

I’ve used xero.com as my small business accounting software for the last eight or nine years. One of the nice things about Xero is that they have a great CLI and API. So I knew that if I wanted to transfer all of my data from Xero over to my new application, it would be relatively easy. And that was the case.

I got started by giving Claude some general prompts and some screenshots from Wes’ idea, and told it that I would be building an application similar to Xero. I wanted to maintain as much of the functionality as I could, so the switch would be smooth.

This part still amazes me: it is absolutely incredible how well Claude can build a clone like this, especially when the app you are copying from gives you a CLI or an API. That access lets Claude dig deep and actually see what is happening inside the application, rather than guessing from a features page on a website. It is a completely different level of understanding.

I didn’t build it in one sitting. It came together over several weeks, a day here and a day there, with three or four concerted long sessions where I really got into the groove. After enough iterating, fine-tuning, and chasing down small bugs, I finally had a stable release.

One big decision I made early on was to use the delegated type architecture. This pattern scales well when you have many items that share a common core but differ in the details. Think bills, invoices, purchase orders, and so on. At their heart they’re all the same thing: a document that captures some kind of transaction. But each one has its own edges and specifics.

On the name: I initially called it Ledger, but that namespace felt pretty crowded. So I brainstormed some options with Claude and settled on Partita Doppia. It is Italian for double-entry bookkeeping, and I liked both the sound of it and the Italian vibe.

I’ve open-sourced the code on GitHub. Anybody who wants to can go clone the repo and use it themselves. At the moment I have pull requests closed, because I’m still working on it and moving pretty fast. But the issues board is open for anyone who wants to give feedback or finds bugs. Once I slow development down a little and get to a more stable place, I will happily open up pull requests and make this a project others can contribute to as well.

I don’t have a definite roadmap for where I’ll take things, but I’m tweaking and building features as I use the app myself, integrating things as I find what needs fixing or adding. And as of today, I have essentially switched over to Partita Doppia as my daily driver for accounting. I still maintain my Xero subscription, and probably will at least through the end of this year, but my day-to-day is now the Italian way.

Find Partita Doppia here: partitadoppia.app

For the Rails Guild, I was picturing a place that would bring Rails developers together to showcase their work in a verified way. I didn’t see one that existed. There had been some historically that filled similar roles, but it didn’t appear there was currently one in the Rails world. So I set out to create that space.

My goal was that it would be a place for Ruby on Rails developers, especially newer developers, to show what they’ve shipped. And when you visit the site, you know the work is actual work, not just resumé fluff.

As I was building the Rails Guild, the Omarchy wave happened. I knew I had to spin off an Omarchy Guild, because there was just too much momentum on that side of the tech world not to. So I released the Omarchy Guild, and kept refining the Rails Guild app.

The Rails Guild is here, and the ranks are filling up. If you’re a Rails developer shipping work, join the Guild and share what you’re shipping.

railsguild.com

It’s simple. It lists every app on your Hatchbox account, each with small buttons to deploy, to restart, or to open the app and dig into its finer settings on Hatchbox.io itself. It’s a quick place to see when each app was last deployed and what state it’s in.

When I push to GitHub and want to know if that deploy is actually done, I don’t have to open Hatchbox at all. I just click the little icon in the Omarchy top bar and the state is right there. I added some fun flair to the deploy stage animations, too.

Here’s the link to the plugin on plugins.omarchy.org.

I’ve built it so that a user simply has to authorize omarchyguild.com to access their GitHub account. From there it can see what they’ve done related to Omarchy, and any work they’ve done on pull requests, themes, or plugins gets automatically pulled into their profile. Pull requests are imported and updated automatically as new work comes in while users manually add plugins and themes.

The stack

• Rails 8, SQLite + Solid Queue/Cache/Cable, Hotwire, Propshaft + import maps, Minitest.
• Auth via email magic link with long-lived sessions.
• Deployed via Hatchbox, Cloudflare in front, MailerSend for transactional emails. Solid Queue runs as its own Hatchbox process (bin/jobs) next to the web server.

The leaderboard

The first of my favorite features is the leaderboard, which shows a ranking of people who have contributed PRs, themes, and plugins. You can break that down into all contributions combined (pull requests, themes, and plugins), or you can see separate views for just pull request rankings, theme rankings, and plugin rankings. That way you can see how the members of the guild rank based on those subcategories.

The globe

Another great feature that I really enjoy is the globe, which is a visualization of the Earth with all the Omarchs on it. Users can choose to drop a dot on the globe where they’re located. They don’t have to, but they can, and then their name and their dot will appear on the globe. This way we can see where everybody in the Guild is and what the world looks like with contributors to Omarchy all over it.

You don’t have to be a contributor

On that note, you don’t actually have to be a contributor to sign up for the site. You can simply be somebody who’s interested. You can show off your setups as well, post images of your desktop, your cool computer, your cool setups, very similar to what we have going on in the Discord. You can post all of that here on the Omarchy Guild too.

Where this fits with Discord

Discord is obviously THE place to chat and converse, and I don’t currently have any features built on omarchyguild.com that allow communication. No like buttons, no chats, no communication. It’s all just presentation. It brings all of these things together into one spot, because I didn’t feel that the Discord group had a place to showcase a person’s work in one single location.

Check it out at omarchyguild.com.

So, I did what anyone using Omarchy these days would do, and I built a plugin.

I call it Omarchy Plain English.

It’s a plugin that reads your system stats and translates what’s going on there into plain English. It doesn’t use any AI. It just has prescribed verbiage for different scenarios. It lives in your top bar and you can click it and see, in plain English, what’s happening in your system. If anything is going wonky, it’ll tell you. If everything is cool, it’ll tell you. That’s simple.

Sure, I could learn btop better, but sometimes I just want a quick answer to “why is my laptop running hot?” The laptop has all the data, and now it can easily tell me why.

Check it out here: https://github.com/joelgaff/omarchy-plain-english

P.S. - my Framework was running hot because the Bluetooth service was stuck on something and using an entire core. Claude helped me debug and fix it. What a time to be alive.

The pass is apparently bound to whichever device you activate it on. Icelandair’s portal has a “Swap Device” option, but it only works if you paid with a credit card and gave them an email at checkout. Points purchases don’t create a lookup record, so the swap silently fails with “no device associated with this email.” Poor error message, but Claude helped me figure it out.

I still wanted to use my laptop. I needed to install Omarchy Quattro, after all.

Claude said that the wifi pass follows the MAC address of the device, and the fix is to make the laptop present the iPhone’s MAC.

Framework 13 running Omarchy 3.8.5, iwd for wifi set up. Here is what Claude cooked up that worked.

On the iPhone:

• Find the Wi-Fi address (not IP address)
• Toggle Wi-Fi off entirely so the AP can age out the association.

On the laptop, save your real MAC first:

cat /sys/class/net/wlan0/address

Then clone the iPhone’s MAC and reconnect:

iwctl station wlan0 disconnect
sudo ip link set wlan0 down
sudo ip link set wlan0 address <iphone-mac>
sudo ip link set wlan0 up
ip link show wlan0 | grep link/ether
iwctl station wlan0 connect "Icelandair Internet Access"

Confirm the grep echoes the iPhone MAC and not your real one. If iwd overwrote it, check /etc/iwd/main.conf for AddressRandomization=network or once and comment it out.

Then re-point DNS at the portal gateway:

sudo resolvectl dns wlan0 172.19.0.1
sudo resolvectl domain wlan0 '~.'

That last part was needed because my resolved.conf had Cloudflare hardcoded in DNS=, which was overriding the network’s own DNS and swallowing the portal redirect. Moving Cloudflare to FallbackDNS= is the real long-term fix for captive portals.

Before landing, restore everything:

sudo ip link set wlan0 down
sudo ip link set wlan0 address <your-real-mac>
sudo ip link set wlan0 up
sudo resolvectl revert wlan0

That revert matters. Skip it and the next network I try to join will look mysteriously broken, because wlan0 is still trying to reach a gateway at 35,000 feet.

The gotchas that cost me the most time

• I typed the phone’s IP where its MAC belonged. ip complained “must be 6 bytes.” Bytes, not octets. IP is 4, MAC is 6.
• I dropped the address keyword a couple times. Without it, ip link set wlan0 F6:4F:... reads the MAC as a device name and returns “garbage.” Always ip link set dev wlan0 address <mac>.
• iwd can silently rewrite your MAC back to the hardware one on connect if AddressRandomization is set. If your first clone succeeds and then the change disappears, that is why.

This kind of stuff is just magical. I wouldn’t feel as confident messing with my Mac, but I feel a closer connection to my Linux machine, and know my way around the CLI much more comfortably (with plenty of help from Claude). I felt like a true hacker, doing something that I wasn’t technically supposed to be able to do. Big win for us nerds.

Now off to explore Quattro.

It’s the kind of thing that only matters to me now when the product is small. If the app takes off, I’ll likely turn these notifications off. But at the moment the emotional payoff of these pings is high.

Why I wanted this

Between publish and check-stats-a-week-later, there’s a long fuzzy void where I have no idea if anything is landing.

A signup is a real signal. Someone read something, tried the product, gave me their email, and made an account. That’s not a stat, that’s a person.

I want the ping the moment it happens. Not tomorrow morning in a digest email. Now.

How it works

Under the hood: a small background job on the Rails side that fires whenever a new user is created, packages up a short summary, and sends it to Telegram over their bot API. Around sixty lines of code, plus tests.

A few details worth naming:

• The job only fires in production. Dev signups, test signups, seeded data. None of them buzz my phone. Local iteration is already noisy enough.
• It only fires after the database commit. If a signup gets rolled back for any reason, no ghost ping.
• If Telegram is having a bad day, the job retries a few times, then quietly gives up and logs it. A failed notification should never block or retry a real user’s signup.

Nothing exotic. Just quiet, defensive plumbing.

The nice surprise

Setting up the Telegram bot was faster than I expected. Two minutes with @BotFather, one HTTP call to test, done. Bot tokens are just strings, chat IDs are just numbers. There’s nothing you need to configure on Telegram’s side beyond creating the bot itself.

Compared to setting up transactional email (deliverability, SPF/DKIM/DMARC, verified domains), Telegram bots are a shockingly easy notification channel for solo-builder use cases. Not for user-facing notifications. I’m not asking Cucamonga users to install Telegram. But for the “ping me, the operator” use case, it’s ideal.

Onwards.

Here is the whole thing, in the order it happened, because I think this is what modern Rails deployment can look like now, and it’s worth writing down.

The setup

The trips app has lived at trips.joelgaff.com for a while. It’s a subdomain on my personal domain. It’s fine, but the app has outgrown it. I rebranded the app to be called Cucamonga, and cucamonga.app is its new home. Time to move it over.

But I’m in London. On vacation. In bed. On my phone.

I only need three tools:

1. Cloudflare: where my DNS lives
2. Hatchbox: where the app runs
3. GitHub Mobile App: where the code lives

That’s essentially the entire deploy pipeline. Rails 8, SQLite, Hotwire, one Hetzner box behind Caddy, auto-deploy on push to master. It’s boring in the best way.

Step 1: DNS

Open Cloudflare. Add two records:

• A cucamonga.app → server IP
• CNAME www.cucamonga.app → cucamonga.app

Grey cloud, not orange. Caddy needs to see real origin traffic to provision certs, so the Cloudflare proxy stays off. Save. DNS propagates in about ten seconds because Cloudflare doesn’t mess around.

Step 2: Hatchbox

Open Hatchbox on my phone. Trips app → Domains → Add Domain → cucamonga.app. Repeat with www.cucamonga.app. Save.

Caddy on the server immediately went and provisioned a Let’s Encrypt cert for the new hostnames. This is normally the part where you’d go get a coffee. I’m lying in bed, so I scroll on X for a few minutes. On modern Rails hosting, it’s a background job you notice by accident when it finishes.

Step 3: The 403

I hit https://cucamonga.app expecting the app.

I got a 403.

DNS was correct. The cert was valid. The app was running. And it was refusing me.

Took me a minute to recall what was happening. Didn’t even need to ask Claude.

Rails 8 is paranoid about host headers by default. ActionDispatch::HostAuthorization checks every request’s Host header against your allowlist in config/environments/production.rb, and if it’s not on the list, you get a 403. This is the correct behavior. DNS rebinding attacks are real. But it also means adding a new domain requires a code change.

Step 4: The one-file patch

Open the GitHub app on my phone. Navigate to config/environments/production.rb. Tap the pencil icon. Find the config.hosts block:

config.hosts = [
  "trips.joelgaff.com",
  /.*\.joelgaff\.com/,
  "cucamonga.io",
  "www.cucamonga.io",
  /.*\.hatchboxapp\.com/
]

Add two lines:

"cucamonga.app",
"www.cucamonga.app",

Save. Commit to master.

Step 5: Hatchbox again

Push to master triggers auto-deploy. Hatchbox pulls, builds, restarts. About 90 seconds. Refresh cucamonga.app.

200.

Whole thing, phone in hand: about 15 minutes.

The point

It’s not that I did anything clever. It’s that the tools are good enough now that this is what shipping a rebrand looks like. One config file. No rebuild. No downtime. One commit. Thumb typing.

I’m not saying you should ship from vacation. I am saying this. On a mature Rails 8 + Hatchbox stack, the friction between “I want to do a thing” and “the thing is live in production” has collapsed to almost nothing. On a phone. In bed. In a foreign country.

Small ship. Now back to my tea.

Ruby is the language, Rails is a framework.

Think of Ruby as the raw materials needed to build a house.  Rails is a template or blueprint that *automatically builds* many of the common parts of the house that all houses need, without you having to do all the planning or building. 

You’re gonna need windows, so Rails makes spaces in your walls for windows. 

You’re gonna need a furnace, hot water heater, electrical wiring, and a roof over the house, so Rails takes care of all of that.  Every house needs those things. There’s no need to waste time building it all on your own.

You get to design and build all the fun stuff on top of the framework Rails has created for you.

The layout of the rooms, the shape of the house, the kinds of windows, the bathroom fixtures, type of flooring, lights and lamps, kitchen cabinets and so on. That’s your part.

In summary: Rails builds a scaffold (framework), upon which you can flesh out your house…er…project.

All the boring, monotonous steps have been taken care of for you.

More at world.hey.com/joelga

Before getting started

First, make sure you have Ruby and Ruby on Rails installed on your computer.

Second, make sure your command prompt is showing the location on your computer where you want this new Rails app to be created.

Take a look at the command line below:

joel@Joels-MacBook-Pro-16 projects %

The command line is showing that Terminal (the command line app I’m using on my MacBook) is currently in the ‘projects’ folder.  If I run the rails new command right now, a new Rails app (a folder with a bunch of files in it) will be created in the projects folder.

Create the project

Now we’re ready to create this project. In the command line run the `‌rails new` command. Swap out ‘grand-prix’ below for the title of your new project. Call it what you want, but make sure it’s either one word, or uses underscores or hyphens between words. Otherwise the first word will be used to create the project name (ie.’my new app’ would end up being called ‘my’. Use ‘my-new-app’ instead)

joel@Joels-MacBook-Pro-16 projects % rails new grand-prix

That’s it. When you run this command, a new directory (folder) titled ‘grand-prix’ will be created with the following directories and files (folders below are noted with the ‘/‘ at the end of the name):

- app/
- bin/
- config/
- config.ru
- db/
- Dockerfile
- Gemfile
- Gemfile.lock
- lib/
- log/
- public/
- Rakefile
- README.md
- storage/
- test/
- tmp/
- vendor/
- .dockerignore
- .gitattrubutes
- .gitignore
- .ruby-version

This set of files and folders has created a (very) basic rails app, and you can run it immediately.

Viewing the project

Next you’ll need to navigate into the project folder you just created.  A quick way to do this is to enter the command

cd <the name of the project you just created>

This will move your command prompt into the directory/folder (cd means change directory) of the project you just created. In my case I’d enter `cd grand-prix`.

Now, in the command line type `rails server`

joel@Joels-MacBook-Pro-16 gand-prix % rails server

The command line will output something similar to this (depending on the exact version of Rails you’re running):

joel@Joels-MacBook-Pro-16 grand-prix % rails server
=> Booting Puma
=> Rails 7.1.3.2 application starting in development 
=> Run `bin/rails server --help` for more startup options
Puma starting in single mode...
* Puma version: 6.4.2 (ruby 3.3.0-p0) ("The Eagle of Durango")
*  Min threads: 5
*  Max threads: 5
*  Environment: development
*          PID: 48667
* Listening on http://127.0.0.1:3000
* Listening on http://[::1]:3000
Use Ctrl-C to stop

To see your app running, visit that link `https://127.0.0.1:3000`.  This will open a web browser and display the following image (or similar, again, depending on the exact version of Rails you are running):

Bam.  You’ve created a Ruby on Rails app.

—
More at world.hey.com/joelga