Students should, at the end of the lesson, be able to:
- Explain what a Ruby Gem is, and how it is similar/different to a Node module.
- Look up a gem to solve a particular problem.
- Find documentation for a given gem.
- Compare similar gems' utility based on currency, issues, and test coverage.
A gem is a library of Ruby code that you can incorporate into your projects. Using an external library allows you to benefit from someone else's work, so that you don't need to waste time reinventing the wheel.
Here are a couple of gems that commonly appear in Ruby and Rails projects:
devise
paperclip
resque
rspec
capybara
pry-byebug
(a combination of two separate gems,pry
andbyebug
)
The jobs these gems do can range from debugging to testing to integrating into an API.
There are two main ways to install Ruby gems. The first is manually, through the command line:
gem install resque
This will download and install the gem that you specify.
The second way is to use bundler
(another gem, which we installed during install-fest) and a 'Gemfile', a file containing a list of gems that our project requires. To install the gems listed on a Gemfile, navigate to the location of the Gemfile and run
bundle install
When you run
bundle install
for the first time in a project, a new file called 'Gemfile.lock' gets created. This file constrains the versions of the different gems used, so that even ifbundle install
is re-run, and some gems have been updated, only the versions specified in Gemfile.lock get used.
There are a lot of similarities between Node modules and Ruby gems.
Node Module | Ruby Gem |
---|---|
npm install moduleName | gem install gemName |
npm install | bundle install |
package.json | Gemfile |
However, there are a couple of differences too. For instance, Node modules (except when using the -g
flag) get installed within a particular project, inside a folder called node_modules
. Ruby gems, in contrast, will not be installed within the project.
Fork and clone this repo; then, run each of the commands above from within the repo. Then, just for fun, run gem install bundler
and look at the output you get.
The two main places to look for Ruby gems are RubyGems.org and The Ruby Toolbox. RubyGems.org is the official listing place for all published gems, and it's the place that our gems actually come from when we install them. The Ruby Toolbox, in contrast, doesn't actually have the code on its site, but it provides some additional information about gems that's not available on RubyGems.org, including grouping gems by category.
There will often be multiple gems that can be used for the same purpose. How can we choose between them? Ultimately, we want to use code that is well-maintained, well-tested, and well-documented. If there's a link to the source code on GitHub, that can be a great place to find things like:
- When the last commit was, and how frequently commits are made.
- How many outstanding issues there are (total and as a % of all issues).
- Who the collaborators are.
- If there are tests (usually found in the
/test
or/spec
directory) and how extensive they are.
Depending on the gem, there may not necessarily be a lot of documentation available, but if the GitHub project has a wiki set up, that can be a good place to find information. Additionally, many gems have official 'rdoc' documentation; there's a searchable web interface for that documentation at RubyDoc.info.
As an exercise, pick one of the gems listed above and research it; then, research some alternative gems, and pick the gem that you think is the next best alternative. How might you justify this choice of best alternative gem to a senior engineer on your team?