Sharing the joy of building with Ruby on Rails.
Rails 8 leans hard into SQLite as a first-class production database. One of the nicest payoffs is that you can build a fast, typo-tolerant, relevance-ranked search engine without adding Elasticsearch, Meilisearch, or even the pg_search gem. SQLite ships with FTS5, and Rails 8.1 finally exposes a clean migration DSL for it.
I've been upgrading an old Rails application. And with old, I mean old. It started life on Rails 4.2, and I've been methodically dragging it into the present, one minor version at a time. The jump from 4.2 to 5.0 went remarkably smoothly. Green test suite, clean deploy, no surprises. So when it was time for Rails 5.1, I felt confident. Tests passing, staging looked good, so I deployed to production.
One of the quieter additions in Rails 7.1 is also one of the most elegant: generates_token_for and its companion find_by_token_for. Together, they give you stateless, purpose-bound, self-invalidating tokens without a single extra database column or table.
If you're using Claude Code for software development, you've probably hit this wall: you want to work on multiple features simultaneously, but you can only run one Claude session per project at a time. What if you could run three, four, or even five Claude Code sessions in parallel? Each working on a different feature, each with its own running application you can test in your browser.
I run multiple Claude Code sessions in tmux throughout the day. One pane has Claude refactoring a component, another is debugging an API issue, and I'm actively working in a third. The problem? I kept missing when Claude finished or needed permission to continue working, switching back only to find it had been waiting for minutes. After some digging, I figured out how to get notifications working properly with tmux. Here's what I learned.
Last weekend, I woke up to an inbox full of error notifications from one of my Rails applications. Something was clearly wrong. I jumped out of bed, got on my laptop, and logged into Rollbar, the error tracker.
Rails comes with excellent built-in authentication and authorization tools, but one common security pitfall is developer error. For example forgetting to add a before_action :require_admin. This can lead to sensitive data being exposed unintentionally.
This week, I deliberately cleared my schedule of all client work so I could focus entirely on Rails Startup. It is the application I'm building (and already using) as a foundation for a few of my own side projects. Aside from the occasional dad duty, I managed to spend quite some hours deep in the code.