Rails%203%20In%20Action

544 APPENDIX A Why Rails?
with their own code. There are gems such as the json gem, which is used for parsing
JSON data, nokogiri for parsing XML, and of course the Rails suite of gems.
Previously, gems were hosted on a system known as RubyForge which was unstable
at times. In July 2009, Nick Quaranto, a prominent Rubyist, created the RubyGems
site we know today: http://rubygems.org. This is now the primary nexus for hosting
and downloading gems for the Ruby community, with RubyForge playing second fiddle.
The site Nick created provides an easy way for people to host gems that other people
can use, freely. Now isn’t that just awesome?
Working with gems on a project used to be tough. To find out what gems a project
used they had to be listed somewhere, and there were often times when the tools used
to install these gems would not work, either installing the wrong gems or simply refusing
to work at all. Then along came Bundler. The Bundler gem provides a standardized
way across all Ruby projects for managing gem dependencies. It’s a gem to
manage the gems that projects use. You can list the gems you want your project to use
in a special file known as the Gemfile. Bundler can interpret (when bundle install is
run) the special syntax in this file to figure out what gems (and the dependencies, and
their dependencies’ dependencies) need installing and then goes about doing it.
Bundler solves the gem dependency hell previously witnessed in the Ruby and Rails
communities in a simple fashion.
In addition to this, having different Ruby versions running on the same machine
used to be difficult and involve a lot of hacking around. Then another prominent
Rubyist, Wayne E. Seguin, created a gem called Ruby Version Manager (RVM) that
allows for simplistic management of the different
All in all, RubyGems and its ecosystem is very well thought-out and sustainable. It
provides an accessible way for people to share their code in a free manner and serves
as one of the foundations of the Ruby language. All of this work has been done by the
exceedingly great community which is made up of many different kinds of people,
perhaps one day even including people who are reading this appendix.
A.4 Reason #4: emphasis on testing
Within the Ruby and Rails community there’s a huge focus on writing great, maintainable
code. To help with this process, there’s also a big focus on test-driven development
along with a mantra of “red/green/refactor.” This mantra describes the process
of test-driven development: you write tests that are then failing (usually indicated by
the color red), write the code to make those tests pass (indicated by green), and then
clean up (refactor) the code in order to make it easier for people to know what it’s
doing. We covered this process in chapter 2.
Because Ruby is interpreted rather than compiled like other languages, you cannot
rely on compilers to pick up errors in your code. Instead, you write tests that
describe functionality before it’s implemented. Those tests will fail initially, but as you
write that functionality those tests will pass. In some situations (such as tests written
using the Cucumber gem), these tests can be read by people who requested a feature