Exploring Obscure-ish Ruby Gems
As anyone who has ever worked with it knows, Ruby is an incredibly powerful object-oriented programming language, one that has enough functionality to be used in production code, but flexible enough to be learned by novices. The creator of Ruby — Yukuhiro “Matz” Matsumoto — said his goal was to make Ruby “natural, not simple,” in a way that mirrors life.
One of the most impressive aspects of Ruby for budding Ruby-ists are the vast number of libraries, commonly known as gems, freely available for use. Tools like pry, rspec, and nokogiri are not only easy to adopt; they also make Ruby a more powerful language to work with, giving developers the ability to write better code and create more interesting programs.
As developers, one of the most exciting aspects of our work is our ability to manifest our ideas into reality through code. Our solutions have to be creative, and, well, our code should be creative as well. Incorporating different gems into our projects lends even more flexibility to our work, leveraging new ways of solving problems. But while gems like pry and rspec are widely known and used, there are thousands (around 150,000) of different gems available to programmers. For this article, I’ve highlighted some less commonly used Ruby gems, and I hope you’ll be inspired to dig more deeply into what libraries you can incorporate into your code. For a general overview of installing and working with Ruby gems, check out this step-by-step article.
CAVEAT: Don’t Use the Most Obscure gems
Like any program, gems are made up of lines of code. Some are built well, and some… aren’t. Although there are thousands of gems to choose from, many (like the nokogiri predecessor hpricot) have been long abandoned by their developers, and some gems are merely personal projects that never got much traction whatsoever. Before deciding on using this or that gem, make sure the project has a relatively recent stable release and has been downloaded by a large number of other developers. Any gem you use should probably have documentation and tests, as well as different contributors who have forked the project and added to it. When browsing rubygems.org for a new tool, maybe don’t go with that tool that only has 300 downloads and hasn’t been updated in the last four years. For this article, I’ve only picked projects with over 2 million downloads that have released updates in the last two months. With that, let’s dive into the wide world of Ruby gems.
reek
We’ve all heard of code smell before: it’s code that could, and let’s be honest probably should, be refactored. Code smell doesn’t necessarily refer to to bugs. It’s working code, but it might not be optimally written. Maybe your code isn’t very D.R.Y., or maybe your methods don’t have the most descriptive names. Bottom line, while you have working solutions to your problem and you’re passing your tests, your work is going to be difficult to maintain, especially for other developers who will have to decipher your logic later.
Enter reek. With reek, developers can call their immediate attention to code smells, uncovering previously unseen aspects of their work to write working code that will be more maintainable in the long run. When run, reek analyzes Ruby files and prints out a message with the line and particular code smell that was built into the program. Reek will even mark uncommented classes or modules as irresponsible. For example, if a developer were to write code like this:
# h/t github.com/troessner/reek # demo.rb
class Smelly
def x
y = 10
end
end
reek will print out:
# h/t github.com/troessner/reek$ reek --no-documentation demo.rb
Inspecting 1 file(s):
S
demo.rb -- 2 warnings:
[4]:UncommunicativeMethodName: Smelly#x has the name 'x'
[5]:UncommunicativeVariableName: Smelly#x has the variable name 'y'
And because code smells are by their nature subjective, reek is highly-configurable. This is powerful for developers, as they can customize what they want reek to focus on in a particular project or even directory to ensure they are following best practices. While linters like RuboCop can explicitly tell you where and how your code is broken, tools like reek can help dig more deeply into the architecture of your code. For a more detailed walk-through on what reek can do for you and your team, check out this post on Feature Flags.
ProgressBar
Imagine you’ve built a simple application to run in the terminal, and you’d like to get an idea of how data is bouncing around your code. Maybe it’s taking longer than expected to download files from a remote source, or perhaps you just want to see how long a particular function is taking to run.
For this kind of problem, ProgressBar is your solution. After installation, you can run ProgressBar in your application like so:
# h/t github.com/paul/progress_barrequire 'progress_bar'
bar = ProgressBar.new
100.times do
sleep 0.1
bar.increment!
end
And ProgressBar will print the following output to the terminal:
[#################################### ] [ 59.00%] [00:06]While this may seem like a trivial bit of information, a bare-bones library like ProgressBar can actually show you how data is moving through the code. As Bret Victor explains in his excellent essay “Learnable Programming,” good developers focus not on the static structure of their code, but on how the data within that code behaves, how it changes dynamically throughout its lifecycle in the program. With ProgressBar, developers get a better sense of what their code does instead of what the developer expects it to do. ProgressBar is also customizable, allowing developers to set different metrics by which they want to test their code’s behavior.
Sorbet
Built by an internal team at payments-processing giant Stripe, Sorbet is a powerful type checker for Ruby. In computer programming, a language’s type system — that is, the rules by which variables, methods, classes, and more have their types declared — is essential knowledge for anyone looking to become proficient in that language. As anyone who’s ever written something like this before:
# h/t ruby_docs.org> [1, 2, 3].first("two")
> TypeError: no implicit conversion of String into Integer
an insufficient understanding of types can lead to literally an entire class of errors.
As Stripe uses Ruby in their production codebase, their internal team saw a need for a typechecking tool similar to TypeScript for JavaScript or MyPy for Python. With Sorbet, developers can do type-checking quickly, writing code that is more bug-free and easier to debug down the line. Not only does this eliminate an entire class of errors, but it also makes code more readable and easier to alter without building new bugs into the system.
At Stripe, where hundreds of engineers complete thousands of commits per day, a tool like Sorbet can lend additional support for writing better code efficiently. Additionally, one of the benefits of using a gem developed by a large company is that it tends to be well-supported. Developers at Stripe have given a number of informative presentations on how to use Sorbet. They’ve even created a sandbox for people to try it out!
As you can see from this brief overview, there are entire universes to be discovered in Ruby gems. Although Ruby devs will undoubtedly encounter pry and rspec on a daily basis, we owe ourselves (and the people we work with) to familiarize ourselves with more than just the most commonly used tools. Part of the great joy of writing code is being able to use our creativity to create whatever we want, and to do that we ought to have a full tool belt. With Ruby gems, the possibilities for incorporation are virtually endless. There are so many gems available for use it’s hard to imagine counting all the permutations of libraries you could employ on your project. Then again, if you did want to know all of those possible permutations, there just might be a gem for that.
