What are the best Ruby gems that you can use in your Rails projects?
That’s what you’ll discover in this article!
I’m going to give you 7 gems, but not the same old gems that you’ve seen a million times, I’m going to be sharing with you some gems that are very helpful, but little-known.
But before we do that…
I’ve seen developers that pull in a gem for just about everything.
If it remotely sounds like it could be helpful.
Without taking a moment to think if that gem solves the problem they have, if it’s the best option, well-maintained & documented, etc.
That’s a mistake.
Because the more things your project depends on, the more likely it’s to break when things change.
And things change ALL the time.
New Rails version, new Ruby version, new features, etc.
With that said…
Gems can save you a lot of work, help you clean your code, and avoid security issues, so use them wisely!
Let’s get into the list.
As your Rails application grows, you’ll accumulate more & more routes.
You’ll change code & some of these routes become stale.
No longer needed…
But they’ll stay there, in your
config/routes.rb, making it harder to manage.
How do you find which routes to delete?
There is a gem called
It loads your routes & compares them to the controller actions you’ve defined.
But right now it has two limitations:
I sent a pull request to add Rails 6 support, but I also came up with my own version that doesn’t have these limitations.
You can find it here.
Rails migrations can cause a lot of problems if done wrong.
Removing a column can cause problems because Rails has a cache of columns, and running a migration doesn’t reset this cache.
If you add an index & you’re running PostgreSQL the whole table gets locked until the operation is complete.
Not good for your users.
Your application won’t be able to respond to requests that need to work with a locked table.
The good news?
You don’t have to remember all of these things.
With the help of the
strong_migrations gem, you’ll know when you have one of these unsafe migrations before it makes it into production.
A Rails transaction is supposed to be an “all or nothing” operation.
It looks like this:
Book.transaction do # ... end
As you can imagine, this leads to all sort of issues.
What’s the solution?
Not very high-tech, actually, just avoid “side effects”, or doing things that affect the “outside world” of the transaction.
The isolator gem can help with this.
It audits all your transactions to make sure they’re safe.
All you have to do is install the gem, then when it detects a bad
transaction it will raise an exception.
Give it a try!
Slow tests are no fun.
But there are tools to help you find why your tests are slow so you can fix them!
One of these tools is the combination of
Here’s how to use it:
%self total self wait child calls name 43.21 2.001 2.001 0.000 0.000 1 Kernel#sleep 2.97 0.184 0.138 0.000 0.046 1640 Array#permutation 1.39 0.064 0.064 0.000 0.000 144 PG::Connection#async_exec
Here I can clearly see my call to
sleep, but this could easily be an API call, reading a big file, a slow SQL query, etc.
Another thing you can do is to use the event profiler.
EVENT_PROF='sql.active_record' EVENT_PROF_EXAMPLES=1 rake
This helps you find which tests are running the slowest queries.
Btw, Rails 6 added parallel testing, you’ve to enable this in
test/test_helpers.rb if you’re upgrading your current project.
Validations are great.
But it doesn’t matter what framework you’re using to build your web application.
You can always bypass your validations by importing data directly into the database, creating records using raw SQL, or using some method in your ORM that skips validations.
In other words…
Your validations only protect you from user error, but not developer error.
These developer errors can make your data inconsistent.
The good news?
Most – if not all – modern SQL databases implement “constraints”, a set of rules like validations, but at the database level.
So if you want to increase your data consistency you want to implement these constraints.
One gem that can help you is database_consistency.
How to use this gem?
First, you need to install it, no mystery there.
Second, you run
bundle exec database_consistency in a terminal, inside the project you want to check.
It will produce a report like this:
fail Comment title column should be required in the database fail Comment author column should be required in the database
Add the missing database constraints, in this case, not-null, with a
Want to improve your code, but not sure where to start?
Get some metrics!
There are many code metrics, like cyclomatic complexity & churn. Churn looks at the rate of change over time in your code.
Using your git change history.
A list of files that change the most.
If you spend 90% of your time changing your
User model… It’s probably a BIG file with LONG methods. A great candidate for refactoring!
One gem that helps you find these constantly-changing files is called
Run it like this:
attractor report -p app
It produces an HTML report, and a list of high-churn files that you can use to focus your refactoring efforts.
Let’s finish with another tool to help you improve your code.
If you run this gem in production (low overhead), you’ll get a coverage report of what code is being run.
You can even track unused views!
This can help you make decisions when deleting code & cleaning your project.
Don’t let unused code build up!
You have learned about 7 powerful & little-known Ruby gems that you can use in your (mostly Rails) projects to make your tests faster, improve your code & increase safety.
Remember the little warning about gem abuse, but don’t let that hold you back from trying new gems.
If you’d like to improve your Ruby skills & support the blog, consider buying a copy of my Ruby book, Ruby Deep Dive. 🙂
Thanks for reading!