How can we use AI without getting dumber? - DHH’s recent observation about AI resonated:

“As soon as I’m tempted to let it drive, I learn nothing, retain nothing.”

When he lets AI take the wheel, his learning stops. Knowing how you learn best is crucial and I respect that. But his tweet reminded me of my first week with Rails many years ago. One command - rails generate scaffold Blog - and boom. Working blog. Complete with database migrations, controllers, views, the works. I felt like a god.

For about ten minutes.

Then came the client requests. “Can we add comments?” “What about tags?” “Why is it so slow with 10,000 posts?”

I had no idea. I’d built nothing. I’d learned nothing. The only thing that had happened was some code appeared on my screen.

I know what you’re thinking: “That’s different. Rails generators create 50 lines of boilerplate. AI writes entire features, algorithms, and architectural decisions. One removes tedium, the other removes thinking.”

Fair point. The scale has changed dramatically. But here’s what’s interesting - in the early days, those 50 lines of generated code felt just as magical and just as dangerous to understanding. I remember the debates about whether generators would make us worse developers, whether we’d lose touch with the fundamentals. Some of us worried we’d forget how to write SQL or understand HTTP.

Sound familiar?

We’re watching the same pattern repeat, just amplified. With Rails generators, with Stack Overflow, with Google, with IDE autocomplete, and now with AI. Each time, the community splits: those who see a shortcut to ship faster, and those who worry we’re shortcutting our way out of understanding anything.

Both groups are right. And both are missing the point.

Upgrading Rails applications to Tailwind 4 - With the TailwindCSS 4 beta out, I decided to upgrade my Rails applications. Here are the steps I took to do the upgrade^*:

(How I) Deploy Solid Queue with Capistrano - I manage a small number of Rails apps that haven’t yet migrated to Kamal for deployment but I wanted to migrate to solid_queue asap to reduce the service burden of running redis.

These applications are deployed with Capistrano on Ubuntu LTS servers and the solid_queue is managed by linux’s systemd. There isn’t much information out there on how to deploy solid_queue with Capistrano so hopefully this helps those of you that still use this popular way of deploying Rails applications.

The systemd service is defined in a file located in your deploy users home folder

Developing with Browser Guards in Rails 8 - As part of the Rails 8 milestones, DHH added a browser guard which he explains thus:

To take full advantage of our #nobuild defaults, we need to ensure that developers have easy control over which versions of the major evergreen browsers they intend to support, and guard their application from being accessed by unsupported versions.

In the pull request that followed we can see that by default, the browser minimums have been set to:

• Safari 17.2
• Chrome 119
• Firefox 121
• Opera 104
• and well, no IE at all.

What this means in practice is that if you visit a newly generated Rails site with a browser below these versions, you will get this 426 error page:

Memory Issue After Rails Upgrade - I upgraded a bunch of sites to Rails 7.1 recently and the ones deployed on Heroku started to show some massively increased memory usage:

Debugging Action Mailbox Issues in Production - When receiving and processing incoming emails with ActionMailbox, you may come across issues with particular emails that you need to debug. There is a tiny section in the Rails Guides about how to work with ActionMailbox in development. But how do we get an email that caused issues in production and debug it in development with the tools Rails provides?

Ruby On Rails Resources I Use Every Day - Here are a few sites/resources I have bookmarked that I refer to day to day when coding Ruby on Rails applications.

• https://api.rubyonrails.org
• https://guides.rubyonrails.org
• https://github.com/rails/rails
• https://railsdiff.org

Rails 7: Fix yarn missing on Heroku - When deploying Rails 6 sites to Heroku, the Ruby buildpack would detect if the webpacker gem was installed and install yarn for you automatically. With Rails 7, webpacker is no longer installed by default, so using jsbundling-rails and extras that require yarn to be installed will cause deployment errors on Heroku.

The fix is to install the nodejs buildpack. This needs to be done before the ruby buildpack. As follows:

heroku buildpacks:clear
heroku buildpacks:set heroku/nodejs
heroku buildpacks:add heroku/ruby

After running these commands your deployment to Heroku will work great.

Rails 'new' customizations for Rails 7 - With Rails 7 and its plethora of new javascript and css configuration options and flags, it can be quite challenging to remember just what these options are when creating a new app.

For quite some time Rails has had the ability to read in a config file you have in your home folder named .railsrc This file contains the various flags you would otherwise pass into ‘rails new’ manually. By putting your preferred options/flags into this file, every Rails app you create will be created consistently and just the way you like it.

I prefer postgres as my database and esbuild for my javascript processing and tailwind as my css framework. So my .railsrc file looks like this

--database=postgresql
--javascript esbuild
--css tailwind

Now I just start a new Rails app with

rails new brilliant_app_idea

And my new app is ready to rock configured just the way I prefer.

Execution order of after_commit and after_rollback ActiveRecord callback - Rails allows the adding of various callbacks that trigger during the lifecycle of an ActiveRecord operation. The standard callbacks are before_validation, after_validation, before_save, before_create, after_create, after_save, after_commit, and after_rollback.

These are documented quite extensively in the Rails Guides and the Rails API documentation.

The documentation is quite good at showing you the order the callbacks are executed - eg before_validation fires before validate which fires before before_save etc. Most of these validations execute in the order they are defined. For example, if you have two before_save callbacks defined, then they will execute one after the other.

Rails, testing, and peace of mind - I must admit, I probably didn’t test my code as thoroughly as I ought to have. Let me re-phrase that. I did test it. I just didn’t write complete test cases to ensure regressions weren’t introduced when new bits were added. As a result, maintenance always took longer than it should have, and bugs were introduced when changes were made. Even though I had read and studied the importance of testing very early in my software development career, it was only after continued frustration with things breaking that I got off my butt and actually started using testing practices like TDD, BDD and even writing tests for code that had already been written. I made it a goal to have the code as covered as possible.