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.