Menu Search
Jump to the content X X
Smashing Conf Barcelona 2016

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

10 Useful Tips For Ruby On Rails Developers

By Greg Borenstein and Michael ‘MJFreshyFresh’ Jones

Rails is an model-view-controller Web framework written in the Ruby programming language. One of its great appeals is being able to quickly crank out CRUD1-based Web applications. A big advantage of Rails over other frameworks is that it values convention over configuration2. If you follow the correct conventions, you can avoid lengthy configuration of files, and things just work! Therefore, you spend less time writing boring config files and more time focusing on business logic.

Ruby on Rails logo

Now, we love Rails. But don’t get us wrong. Like any tool, it’s not the perfect solution to every problem. A lot of the biggest complaints people have about the framework come from using it in situations where something simpler, smaller and more lightweight would do just fine. We love Sinatra3 for anything with minimal server-side involvement. Merb is another excellent minimal framework. And nothing beats apps that run completely in the browser with JavaScript: they can be deployed nearly for free, can scale almost infinitely and never have to be restarted.

In the overview below we present 10 useful tips, ideas and resources for Ruby on Rails-developers (both newbies and professionals). Please feel free to share your tips, ideas and suggestions in the comments to this post!

1. Plug-Ins Save Time Link

Rails has a well defined plug-in structure that enables you to easily install and use plug-ins in your application. David Heinemeier Hansson, the father of Rails, once stated that he uses five to six plug-ins in each Rails application.

There’s an old nugget of developer wisdom that “the best code is no code at all.” Part of what makes us so productive when developing in Rails is that all the code that we don’t have to write because someone else in the community has already written a plug-in that provides the functionality we need.

There are a few ways to install a plug-in in Rails, however the most common is using script:

# Install from a git repo
script/plugin install git://

# Install from a url
script/plugin install

You can save yourself a ton of time and hassle by becoming good at searching the Web (and especially the almighty GitHub). A couple of places to find plug-ins are Core Rails, Railsify and Rails Plug-in Directory. Need to integrate with an existing API or consume some kind of standard format data? Need tagging, pagination4, or another common Web application feature? Odds are that some great Rails or Ruby developer out there already has a project going that will get you at least most of the way there.

2. Testing is Fun and Easy with Rspec Link

For most people, the word “test” brings back scary memories of school exams. When working with Rails, however, automated testing can make your development experience much more enjoyable. While lots of people have strong, nearly religious, opinions about them, at their core, automated tests are just little helper programs you write that run bits of your main code to make sure they do the right thing. When done right, testing will improve your workflow and increase your confidence in the results.

Rails ships with a test framework baked right in, but for the last couple of years all the cool kids have been using an alternative called Rspec5. Rspec’s biggest advantage is its syntax for specifying tests:

describe "My Cool library" do
  before do
    @cool =

  it "should be full of penguins." do
    @cool.penguin_count.should == 10

  it "should melt if it gets too warm"

What’s great about Rspec’s syntax is how much English it uses. The describe block that sets the context and each assertion within it takes strings that you use to explain what your code should do. Often, this is the most important stage: you sit down to write the assertion, getting as far as you can, and then you think, “Right, what should this code actually do then?”

Because Rspec lets you leave off the block that implements the assertion (as in the second melt example), you can quickly brainstorm all of your functionality, and then go back and implement the tests later as you write the code. In the meantime, Rspec will consider those tests as “pending” and give you little reminders about them in your test runs.

Besides helping you write code in the first place, another great thing about tests is that, once you have enough of them, they let you see how all of your code is related, making it easy to know if your recent change broke anything else in your application. Rspec makes it easy to get good test coverage through the use of custom generators that create the tests right along with the rest of your code:

$ script/generate rpsec_scaffold MyModel

Once you’ve got tests to ensure that the basic functionality works successfully, you can make changes and add new code with confidence without worrying about introducing invisible bugs. As long as you run your tests regularly, you’ll know as soon as you break something. And as GI Joe taught us, knowing is half the battle!

3. Save Time, Use Rake Link

Projects often include more than just application-specific code. Sample data have to be created, Web services have to be queried, files have to be moved, code snippets rewritten, etc. Resist the urge to shell script or to cram in a migration or controller. Use Rake6. It rocks!


Rake8 is a build tool written in Ruby, very similar to make9. Rails projects have several Rake tasks already defined; to see these, run the rake -T command.

macbook$ rake -T

rake data:bootstrap     # load in some basic data [caution: will nuke and replcace cate...
rake db:create:all      # Create all the local databases defined in config/database.yml
rake db:drop         # Drops the database for the current RAILS_ENV
rake ts:run          # Stop if running, then start a Sphinx searchd daemon using Thi...
rake ts:start        # Start a Sphinx searchd daemon using Thinking Sphinx's settings
rake ts:stop         # Stop Sphinx using Thinking Sphinx's settings

Adding your own Rake tasks is quite easy. In the example below, you see that the task is name-spaced and has a description and task name, allowing you to write in Ruby.

namespace :data do
  desc "load in some basic data [caution: will nuke and replcace categories, categorizations and inventory items]"
  task :bootstrap => :environment do
    # clean out existing:
    [Category, Categorization, InventoryItem].each{|m| m.find(:all).each{|i| i.destroy}}
    InventoryItem.create! :name => "Compass"
    c = Category.create! :name => "Basic Apparel"

    ["Men’s Heavyweight Cotton T",
    "Men’s Heavyweight Polo",
    "Women’s Organic Cotton Fitted T",
    "Women’s Fitted Polo",
    "Children’s T-Shirt",
    "Jr’s Distressed Hoodie",
    "Hemp Messenger Bag"].each do |name|
      c.inventory_items.create! :name => name



4. Track Application Exceptions Link

Exceptions happen, and when they do, you want to know about them! Your client shouldn’t be the one telling you that a problem has occurred; you should already be aware of the issue and working to resolve it. Exception notification has been available in Rails for a while. There are exception notification plug-ins10 that make it easy to be notified. However, some services such as Airbrake Bug Tracker11 and Get Exceptional12 add a lot of value to your application.


Both of these services are easy to install and provide a great UI for tracking your exceptions. You can even sign up for a free account to try things out.

By centralizing the application exceptions, you are able to see how frequently these exceptions occur, what environment they occur in (a particular browser? a particular location?), what parameters were present and the full stack trace. This centralization of data helps you see patterns and resolve the issue more quickly, which results in a better application and happier users.

5. Mix and match between frameworks and servers with Rails on Rack Link

As of version 2.314, Rails runs on top of Rack15. Rack makes it possible to mix and match between Ruby Web frameworks and servers. If you’re using a framework that supports it (like Rails, Sinatra, Camping, etc), you can choose from any of the servers that do also (Mongrel, Thin16, Phusion Passenger17, etc.), and vice versa.


In addition to introducing all kinds of new options for deployment, this change means that Rails now has access to the exciting world of Rack middleware. Because Rack lives at the intersection of your app and your server, it can provide all kinds of common functionality directly. A great example of this is Rack::Cache.

Rack::Cache provides a caching layer for your application that you control simply by sending the correct headers in your responses. In other words, all you have to do is install a bit of code in the Rack config file:

require 'rack/cache'

use Rack::Cache,
  :metastore => 'file:/tmp/rack_meta_dir',
  :entitystore => 'file:/tmp/rack_body_dir',
  :verbose => true

And make sure your controller actions send the right headers (for example, by setting request.headers["Cache-Control"]) and Bam!, you’ve got caching.

6. Easy Data Dumping Link

You’ll often need to get data from production to dev or dev to your local or your local to another developer’s local. One plug-in we use over and over is Yaml_db19. This nifty little plug-in enables you to dump or load data by issuing a Rake command. The data is persisted in a yaml file located in db/data.yml. This is very portable and easy to read if you need to examine the data.

rake db:data:dump

example data found in db/data.yml

  - id
  - client_id
  - name
  - created_at
  - updated_at
  - token
  - - "1"
    - "1"
    - First push
    - 2008-11-03 18:23:53
    - 2008-11-03 18:23:53
    - 3f2523f6a665
  - - "2"
    - "2"
    - First push
    - 2008-11-03 18:26:57
    - 2008-11-03 18:26:57
    - 9ee8bc427d94

7. Keep Your Constants in One Place Link

All applications have constants, variables that are defined with data that don’t change, such as the name of the application, the tagline, values for crucial options, etc. We use the Rails initializer feature to define a config/initializers/site_config.rb for housing these constants. By using this convention, all developers on a project know exactly where to look for the constants and can quickly make changes.

Many people have questions about when to put a constant in the site_config.rb instead of the class it is used in. For a constant that are only used in a single class, we suggest putting it in that class. However, if the constant is used in more than one location, put it in the site_config.rb. For more on constants, have a look at Rubylearning20.

# File config/initializers/site_config.rb


8. Console for Working on Code Link

Sometimes you may have code that you’re curious about. Will it work this way? What’s the output? What can I change? Rails ships with a wonderful tool called console. By running script/console you will enter an interactive environment where you can access your Rails code just as though the application were running.

This environment is incredibly helpful. It is often used in production environments at times to quickly peek at data without having to log in to the database. To do this in a production environment, use script/console RAILS_ENV=production:

macbook$ ./script/console
Loading development environment (Rails 2.1.1)
>> a = Album.find(:first)
=> #

9. Ugly Views Getting You Down? Try Haml. Link

Views are how your Rails application generates the HTML pages your visitors actually see and use. By default, Rails uses the ERb templating system21 to let you embed bits of Ruby in your markup so that you can insert your data as needed. However, recent versions of Rails let you take your pick of templating languages, and nowadays the Ruby interwebs have been all abuzz about an alternative system called Haml22.


Haml is marketed as “markup Haiku.” Its CSS-inspired syntax lets you focus on the semantics of your data rather than worrying about closing all the angle brackets that come with using ERb and HTML.

For comparison, here’s a bit of markup in standard ERb:

<%= print_date %>
<%= current_user.address %>

<%= %>
<%= h %>

And here’s the equivalent in Haml:

    #date= print_date
    #address= current_user.address
    #bio= h(

Haml’s not for everyone, and many people will find this syntax quite alien. But if you value concision and are fluent in CSS, Haml may be just the ticket.

10. Know Where to Watch What’s Happening in Rails Link

Rails and Ruby both have large and active communities that constantly generate changes, improvements and new projects. Trying to keep up with all the activity can be daunting, but it’s essential if you want to benefit from the community’s best work and continue to increase your Rails and Ruby knowledge.

Thankfully, a number of sources aggregate some of the most important activity:

There’s also a whole universe of Rails training:

and news aggregators:

Another avenue is the Rails Core mailing list30 and the #rails-core IRC channel.

About the authors Link

This guest post was written by Greg Borenstein and Michael ‘MJFreshyFresh’ Jones, lead Ruby developers for StepChange Group. StepChange designs, develops and manages social media widgets and Facebook applications in partnership with leading brands and agencies. Outside of work, Greg builds drum-playing robots31 and other hardware hacks, and MJ leads a local group of Unicycle-borne pirates32. They live and work in beautiful, moist Portland, Oregon.


Footnotes Link

  1. 1,_read,_update_and_delete
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
SmashingConf Barcelona 2016

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook


Crystal Beasley is a product designer at Mozilla. She loves to write on her own blog and tweets @skinny.

  1. 1
  2. 2

    Great useful tips. Thanks SM!

  3. 3

    Thanks for the information – will definitely use this

  4. 4

    As always, great job guys!

  5. 5

    Railscast is another great place for RoR training.

  6. 6

    Very helpful, Im taking my first real dive into RoR, think this will help!

  7. 7

    I have been using Ruby and Rails for quite some time, and got a fair few sites under my belt.
    Having said that, I found this article very informative, the Rails community moves at such a pace, its sometimes hard to keep up. Thanks for bringing me up to date!

  8. 8

    Doing integration testing with Cucumber should also be mentioned. Cucumber allows you to write plain text stories that set up conditions and test expectations by interfacing with your application like a user would. The benefits are numerous: you test your full application stack (views, models, controllers, and interactions thereof), you can hand the feature descriptions directly to stakeholders and have them evaluate them, and it’s very easy to write and maintain.

    Along testing lines, replacing fixtures with generators like factory_girl or machinist is a good idea. Fixtures quickly become unwieldy, and being able to generate objects as you need them helps keep tests clean.

    For deployment and production use, the biggest time savers ever are Phusion Passenger and Capistrano. Passenger makes running a Rails application very simple (just a few declarations in your Apache config file and you’re good to go), and Capistrano makes deploying changes to your production server (or staging/test server, for that matter) a breeze.

  9. 9

    I was introduced to HAML/SASS a while back, and I have to say, it’s quite the amazing language! Totally makes thing easier with the required indentation, and automatic closing of tags. I wish I could use it outside of RoR because whenever I have to code something for WordPress now, I think, “Darn I have to use HTML again.”

    Thanks for the tips Smashing Magazine!

  10. 10

    Thanks for mentioning Ruby Inside (I’m the editor). I just wanted to highlight that Rails Inside at is more Rails specific but in the same vein :)

  11. 11

    The best tip so far is the new rails 2.3 feature regarding application templates:
    Love it.

  12. 12

    Nice!! Thanks for sharing

  13. 13

    Hey, thanks for the Rebase shoutout! :)

  14. 14

    really nice one here! i´d love to read more about ruby and/or rails. cheers!

  15. 15

    Excellent list of tips. I would drop one of them though in place of a suggestion to use Machinist + Forgery. That combination has made my testing so much more enjoyable.

  16. 16

    Having written a couple websites with Rails, I strongly disagree with #1: plugins are ultimately a time sink.

    Ruby already has a way to bundle library functionality: gems. You can install and upgrade them on their own and everything works great. Rails plugins always seem to have compatibility issues, and slight differences in *anything* (even tiny things that you’d think should never make any difference) between a dev box or test box or prod box kill them because the plugins are tied to the source code and not the Ruby install and OS.

    At my last company, our policy was: gems all you want, but plugins only if absolutely necessary. My only regret was that I should have used a higher threshold for “absolutely necessary”, because those we did end up needing caused way more than their share of pain.

  17. 17

    Awesome guys!
    It’s good to see some stuff on rails!
    keep up the good work SM!

  18. 18

    lol never tried ruby on rails..heard of it a lot but I don’t think its for amateurs like me :P

  19. 19

    Great tips! I definitely need to look into Rspec as testing is painful for me. I looked into Haml but just couldn’t get away from good old familiar html syntax.

  20. 20

    I could never wrap my brain around Rails, and I still can’t. I guess ya can’t teach an old dog new tricks.


↑ Back to top