Articles by Julio Lucero

Ruby on Rails keeps changing between releases. Five This Week in Rails opens a new window issues rolled in eight Active Record deprecations and behavior changes on Rails main over the last few weeks. Most are small renames. One is a real bug fix that stops a write from leaking outside its association. None of it has shipped in a tagged release yet, main is currently versioned 8.2.0.alpha. Rails has shipped a new minor version roughly every year (8.0 in November 2024, 8.1 in October 2025), so 8.2 landing sometime around the end of 2026 is a reasonable bet, well ahead of binds, which has a committed removal date of 8.3. uniq! is the one to not expect soon: its removal is tied to 9.0, and Rails hasn’t announced a timeline for that one yet. Nothing in your Gemfile breaks today, but you’ll want to know about it before it does. If you’ve been tracking this kind of thing, you might remember we covered deprecated associations in Rails 8.1 opens a new window back in July. This is the next batch.

I’ll get into what’s changing in each of the eight, why the Rails team made the change, and what to update in your own code once it ships. If you want the general playbook for handling deprecation warnings during an upgrade, we have a guide for that too opens a new window .

You get a site audit report and it looks manageable. A few dozen findings, most of them small: a page with barely any text on it, a link whose text is just “here”, a page whose title tag is a copy of its H1, a hero image heavy enough to hurt the largest contentful paint opens a new window . None of it is that hard. You spend an afternoon on it, close the tickets, and move on.

Then a few months pass, a dozen new pages ship, and the next audit reports the same findings again. Not because anyone ignored the first round, but because the first round fixed pages instead of fixing the process that produces pages.

That happened to us, on this site and on OmbuLabs.ai opens a new window . So the second time around we spent the effort somewhere else. Instead of just fixing the pages, we wrote checks that run on every build and say when a new page has the same problem. It is roughly the same idea as automating a tech debt audit opens a new window : most of the value is not in the report, it is in being able to produce the report again for free. No two of them wanted the same kind of check.

The goal here is search traffic, not a clean report. Thin pages, vague link text, and duplicated title tags are the things that hold a page back in search results, and a page that ships with them costs us traffic until the next audit finds it. A check on every build moves that discovery from months later to the pull request.

In this article, you will learn how we turned three kinds of audit findings into checks that run in CI.

For those who have been coding CSS since the Internet Explorer 6 era, when aligning divs on the web was an art, and there was no way to use partials or variables, the arrival of SCSS was a gift to life. At that moment, creating partials and reusing variables for your primary colors was a delightful experience.

Now in 2026, for the real fans, it’s possible you’re still using sass-rails and you’re full of these files around your project. So if you still want to keep using it like me, I recommend migrating to Dart Sass, which is, in fact, a simple migration, to avoid headaches in the future and, most importantly, to start using the latest features.

Rails 8.1 includes support for marking associations as deprecated right in your models. In this post, I’ll explain how the feature works, why it matters, and how you can use it to safely remove outdated associations from your application.

You may not be aware that, since Rails 7.1, the standard way to store secrets is by using credentials.yml instead of the old secrets.yml.

DEPRECATION WARNING:
`Rails.application.secrets` is deprecated in favor of `Rails.application.credentials`
and will be removed in Rails 7.2.

If you still see this warning, your app uses secrets.yml and the migration applies to you. If you don’t use Rails.application.secrets or config/secrets.yml at all, you can ignore the deprecation and the rest of this post.

The migration itself isn’t hard, but it can take some coordination: if your app runs in several environments, you’ll probably need to work with whoever manages your servers to move everything over. This post walks you through it, and explains why the change matters and what you gain from it.

People focus so much on <h1> and alt attributes that they forget about usability.

Introduction

When discussing accessibility (a11y), we all focus on the structure of our <h1>/<h2>, the alt image texts, the contrast, and all the necessary rules to be covered. The problem is that during the process, we forget to think about usability: Is the page saying what it is supposed to be saying? Does the image description reflect what you can see there? Or take link text as an example: Does “Read More” explain what content the user is about to access?

Most of the time, usability is overshadowed by a focus on compliance with accessibility standards. As a result, we end up with a site that passes validation but neglects to measure usability… or worse, we don’t even consider it.

A few months ago, we were working on a Rails 7 app using Webpack 5. One of the main problems we had was that making a small change in the Javascript took around 39 seconds to recompile. You can imagine how much productivity we lost just waiting, and honestly, I personally remember getting really distracted during that dead time, just sitting there.

At that point, Webpacker had been retired opens a new window , so we checked the official migration guide opens a new window and found several options: the first was jsbundling-rails opens a new window , the second was Shakapacker opens a new window , another was Importmaps opens a new window , and finally, we knew we had the option to try Vite opens a new window .

We finally went with Vite, which (as noted on GitHub) is named after the French word for “quick” (pronounced /vit/, like “veet”). Our reload time improved a lot, it dropped to just one second, which felt like magic. In this post, I’ll explain why we chose it, and also why we got such a huge speed improvement.

A typical scenario in the Rails world, after spending some time using it and playing with forms and requests, you realize that not everything is magic, there is some code that is in charge of cleaning things up so that you get in your controller the params, headers, and other request data that you need.

That’s where Rack comes in. Rack is the code that lives between the layers, from the moment the request starts until it reaches your controller. But it’s not just about input, the output works the same way. When you return something from your controller, Rack is there too.

In this post, we’ll cover a few examples where understanding how middleware works can help you solve real-life problems.

Ruby 3.4.0 was released on December 25, 2024, bringing exciting new features, performance improvements, and some breaking changes. Here’s a practical guide of what’s new and what you should know before upgrading to this version.

Highlights

• New it block parameter reference: Cleaner, more readable blocks using it instead of the original _1.
• Language and core changes: Easier keyword argument handling, string literal warnings, reserved names, and updates to core classes.
• Standard library updates: RubyGems, Bundler, JSON, Tempfile, and more get useful updates.
• Compatibility and miscellaneous changes: New error message formats, hash and float handling, block and performance warnings, and deprecated features removed.
• Prism is now the default parser: Ruby’s parser is now Prism, making it possible for better tooling and error messages.
• Socket library upgrade: Happy Eyeballs v2 means faster, more reliable network connections out of the box.
• YJIT and Modular GC: Advanced performance and memory improvements for those using Ruby’s JIT or experimenting with garbage collection.

Ruby 3.2, released in December 2022, introduced the Data class. A built-in, immutable value object for Rubyists who want simple, safe, and fast data structures without the boilerplate of custom classes or Structs. If you haven’t upgraded to Ruby 3.2 or later, you’re missing out on this powerful feature!

In this article we will present compatibility between Ruby opens a new window and Heroku opens a new window across different versions. In the process of upgrading really old applications to more modern versions of Ruby we have run into a lot of these combinations.