Appendix A. Why Rails?
A common question in the Ruby on Rails community from newcomers is, “Why Ruby?” or “Why Rails?” In this appendix, this question will be answered with a couple of key points about why people should be using Ruby on Rails over other frameworks, covering such things as the culture and community standards.
Ruby is an exceptionally powerful language that can be used for short scripts up to full-featured web applications, such as those built with Ruby on Rails. Its clean syntax and its focus on making programmers happy are two of the many major points that have generated a large community of people who use it. There are hobbyists who use it just for the sake of it right up to hardcore people who swear by it. However, Ruby (and by extension, Rails) should not be used as “golden hammers”. Not all problems are solvable by Ruby or Rails, but the chance of running into one of these situations is extremely low. People who have used other languages before they have come to Ruby suggest that “Ruby just makes more sense.”[1]
1 Quote attributed to Sam Shaw from Railsconf 2011.
The speed at which that you can develop applications using Ruby on Rails is demonstrably faster than other languages. An application that has taken four months to build in Java could be done in three weeks in Rails, for example. This has been proven again and again. Rails even claims up front on http://rubyonrails.org that “Ruby on Rails is optimized for programmer happiness and sustainable productivity.”
The Ruby and Rails communities have a consistent focus on self-improvement. Over the last couple of years we’ve seen developments such as the improvements from Rails 2 to Rails 3, Passenger (covered in chapter 14), and Bundler. All of these have vastly improved the ease of development that comes naturally to Ruby. Other developments have focused on other areas, such as the RSpec, Capybara, and Cucumber[2] gems (featured prominently in this book), which focus on making testing exceptionally easier for Ruby developers. By consistently improving, things are becoming easier and easier for Ruby developers every year.
2 A quick nod to the aruba gem: http://github.com/aslakhellesoy/aruba, which is used extensively to test RSpec’s and Cucumber’s command-line interfaces (CLI), but can also be used to test other CLIs.
Along the same vein of self-improvement is an almost zealot-like focus on testing, which is code that tests other code. Although this may seem silly to begin with, it helps you make less silly mistakes and provides the groundwork for you to test the fixes for any bugs that come up in your system. Ruby, just like every other language, is no good at preventing buggy code. That’s a human trait that is unavoidable.
The shift away from SVN to the wonderful world of distributed version control was also a major milestone, with GitHub (a Rails application!) being created in early 2008. Services such GitHub have made it easier than ever for Ruby developers to collaborate on code across cultures. As an example of this, you only need to look at the authors of commits on the Rails project to see the wide gamut of people.
Don’t just take it from us. Here’s a direct quote from somebody who had only been using Rails for a few days:
When I am programming with Ruby I think I’m making magic.
New person
Although Ruby isn’t quite the magic of fairy tales, you’ll find young and old, experienced and not-so-experienced people all claiming that it’s just a brilliant language to work with. As Yukihiro Matsumuto (the creator of the language) says: Ruby is designed to make programmers happy. Along the same lines, the Rails claim you saw earlier, “optimized for programmer happiness and sustainable productivity,” is not smoke and mirrors either. You can be extremely happy and productive while using Rails, compared with other frameworks.
Let’s dive a little deeper into the reasons why Rails (the framework) and Ruby (the language) are so great.
A.1 Reason #1: the sense of community
The Rails community is like no other on the planet. There is a large sense of togetherness in the community with people freely sharing ideas and code through services such as GitHub and RubyGems (see Reason #2). An example of this is the vibrant community on the Freenode IRC network (irc.freenode.net) where the main #rubyonrails channel is primarily used for asking questions about Rails. Anybody can come into the channel and ask a question and receive a response promptly from one of the other people who visit the channel. There’s no central support authority: it’s a group of volunteers who are voluntarily volunteering[3] their time to help strangers with problems, without asking for money or expecting anything else in return.
3 Too much “volunteer” usage, perhaps. It was voluntary.
There’s also a large support community focused around Stack Overflow (http://stackoverflow.com) and other locations such as the Ruby on Rails Talk mailing list (http://groups.google.com/group/rubyonrails-talk) and Rails Forum (http://railsforum.com). Not to mention, there’s also the RailsBridge (http://railsbridge.org) organization, which aims to bridge the gap between newbies and experienced developers.
All of these different areas of the internet share a common goal: be nice to the people who are asking for help. One mantra in the Ruby community is, “Matz is nice always, so we are nice,” often abbreviated to MINASWAN. People in the Ruby and Rails communities are incredibly nice to everyone.
Another example of the excellent community around Ruby on Rails is the number of conferences and gatherings held worldwide. The smallest of them are the intimate hack sessions where people work together on applications and share ideas in a room. Slightly bigger and more organized than that are the events such as Railscamps (http://railscamps.org) which have about 150 people attend and run from Friday–Monday, with interesting talks given on the Saturdays and Sundays. The largest however is Railsconf, which has about 2,000 people in attendance.
There are hundreds of thousands, if not millions of people using Ruby on Rails today, building great web applications with it and building the best web framework community on the planet.
A.2 Reason #2: the speed and ease of development
The speed of how quickly you are able to develop a Ruby on Rails application is definitely one of the main reasons that people gravitate toward (and stick with) the framework.
One documented case of this is that of a team that had developed an application using a Java-based framework, which took four months. When that application became difficult to maintain, alternative languages and frameworks were sought, with Ruby and Ruby on Rails found to fit the bill adequately. The team re-implemented all the features of the original Java-based application within three weeks, with less code and more beautiful code.
Ruby on Rails follows a paradigm known as convention over configuration. This paradigm is adopted not only by Rails, but also by other modern web frameworks. Rails is designed in such a way that it takes care of the normal configuration that you may have to do with other frameworks, leaving it up to you to get down to coding real features for your application.
One example of this convention over configuration is the mapping between classes designed to interact with the database and the tables related to these classes. If the class is called Project then it can be assumed by Rails (and the people coding the application) that the related table is going to be called projects. But this can be configured using a setting in the class if that table name is not desired.
A.3 Reason #3: RubyGems
This third point is more about a general boon to the community of Ruby, but it plays a key role in developing Rails applications.
As we stated before, the culture of the Rails community is one of self-improvement. There are people who are consistently thinking of new ways to make other people’s lives better. One of these ways is the RubyGems system, which allows people to share libraries in a common format. By installing a gem, a user is able to use its code along 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 of your application and can be used as a set of instructions explaining exactly how this feature works. This is a great way to verify that the feature is precisely what was requested.
As you write these tests for the application, you provide a safety net for if things go wrong. This collection of tests is referred to as a test suite. When you develop a new feature, you have the tests that you wrote before the feature to prove that it’s working as you originally thought it should. If you want to make sure that the code is working at some point in the future, then you have the test suite to fall back on.
If something does go wrong and it’s not tested, you’ve got that base to build upon. You can write a test for an unrealized situation—a process known as regression testing—and always have that test in the future to ensure that the problem does not crop up again.