Chances are you learned about Rails from watching one of David’s screencasts or one of the many tutorials available on the web. You might even have worked your way through Agile Web Development with Rails, which has sold so many copies that it is racing to the top of the list of most successful programming books of all time.
This appendix is a potpourri of essential bits of knowledge and tools that you need to be an effective, professional Rails developer—crucial information that all those introductions and tutorials do not tell you.
Edge is the term used by the community to refer to the latest revision of Rails kept in the repository, as maintained by DHH and the Rails core team. Most Rails pros run on edge so that they can stay in tune with the latest improvements and bugfixes to the codebase. As a result, a lot of the most useful Rails plugins require you to run on edge in order to work.
In order to use EdgeRails you include a copy of Rails within your application rather than using the version installed on your machine as a library. Doing so is as easy as typing rake rails:freeze:edge
from your command line inside a Rails project directory. That rake
task will use Subversion to check out Rails into the vendor/rails
directory of your project. From that moment on, anything Rails-related that you do (console, server, etc.) in that project will use edge Rails rather than whatever version you have installed as a gem.
If you’re an experienced developer, you might be questioning the wisdom of using the latest unreleased version of Rails as it exists in the HEAD branch of the Ruby on Rails repository. Isn’t that dangerous to your productivity? What if changes to the repository actually break your application? It does happen occasionally, which is why you don’t want to track the latest version of Rails with every update to your codebase.
The answer is to pick a particular revision number of edge that is considered relatively stable. You do that by passing a variable to the freeze edge rake task, as follows:
rake rails:freeze:edge REVISION=1234
Wait a minute—how are you supposed to figure out what the latest stable revision is? And if any of those revisions really were stable, why wouldn’t they be released? I admit that I don’t have particularly good answers for you. Figuring out which revision of edge to use is more of an art than a science, and it changes with each project depending on your needs. Most of the time I start with the latest revision available at the time that I bootstrap my project and leave it there, only upgrading to a more recent version if I need to do so.
The Rails core team follows very strict policies regarding test coverage, which means that very few commits actually “break the build.” Even though edge tends to be fairly stable, official releases have tended to lag behind edge at least a few months or more. A number of continuous-integration servers are set up to automatically test each version of the Rails trunk codebase against different database adapters. They send their broken-build notifications to the rails-core mailing list, which you can subscribe to at http://lists.rubyonrails.org/mailman/listinfo/rails-core.
No, I’m not about to go off on a tangent about carbon credits and global warming. As a Rails pro, you’re going to spend a lot of time using the command line, so you might as well save yourself as much confusion and extra typing as possible. The following little tips and tricks should make your life easier and more enjoyable.
At minimum you should add aliases for starting your Rails server and console to your shell’s execution environment. Geoffrey Grosenbach suggests[1] alias ss './script/server'
and alias sc './script/console'
.
PJ Hyett and Chris Wanstrath, authors of the blog Err,[2] have provided the community with valuable, colorful essentials. First install the color gem:
sudo gem install color --source require.errtheblog.com
Now it’s a cinch to make any string appear a different color in the terminal window, because methods for ANSI colors have been added to the String
class.
While we’re at it, let’s also make our test-run results show in red and green. Again we use an Err
gem:
sudo gem install redgreen --source require.errtheblog.com
Then open test_helper.rb
in your nearest Rails project. Add require 'redgreen'
to it; right under require 'test_help'
will do. Now when you run your test suite, successful runs will print in green and failures/errors in red.
Some plugins are so valuable that (arguably) they should be a part of the core Rails distribution. However, because of the “less is more” philosophy of the core team, the Rails core distribution is actually shrinking, not growing.
The following sections are a list of what I (and the readers of my blog) consider to be essential plugins for the Rails pro to be aware of and use on a regular basis.
For the complete list of suggestions submitted for this section, read the comments on my blog post at http://www.jroller.com/obie/entry/rails_plugins_worth_their_something.
http://svn.viney.net.nz/things/rails/plugins/active_record_defaults
This plugin allows you to easily specify default values for attributes on new model objects.
script/plugin install debug_view_helper
This plugin makes it easy to add a button that will pop up a window with the following debugging information, which we are accustomed to seeing on development mode error screens:
Request parameters
Session variables
Flash variables
Assigned template variables
http://svn.rubyonrails.org/rails/plugins/exception_notification
This plugin, written by Rails core team member Jamis Buck, automatically sends you an e-mail whenever exceptions are raised on your site. It makes a remarkably adequate QA department for those lower-budget internal projects that can afford to be unstable. Will save your ass on those projects that can’t.
http://svn.techno-weenie.net/projects/plugins/exception_logger
According to Bryan Helmkamp, “I’d recommend exception_logger
over exception_notification
. The feeds and web UI are killer features.”
gem install has_finder
This plugin is an extension to ActiveRecord
that makes it easy to create custom finder and count methods on your ActiveRecord
models. Read all about it at http://www.pivotalblabs.com/articles/2007/09/02/hasfinder-its-now-easier-than-ever-to-create-complex-re-usable-sql-queries.
http://blog.evanweaver.com/files/doc/fauna/has_many_polymorphs
An ActiveRecord
plugin for self-referential and double-sided polymorphic associations. However, the simplest way to describe it is to say that has_many_polymorphs
is like a has_many :through
where the belongs_to
target is a polymorphic association. Want to know more? Read Pratik’s tutorial at http://m.onkey.org/2007/8/14/excuse-me-wtf-is-polymorphs.
https://terralien.devguard.com/svn/projects/plugins/query_trace
The Rails development log already captures SQL statements generated by ActiveRecord
. This little plugin by well-known Rubyist Nathaniel Talbott appends a short backtrace to every one of those log statements. It doesn’t seem like a big deal, until you’re trying to find the source of a nasty N+1 select problem or attempting to debug anything related to caching.
http://sample.caboo.se/plugins/court3nay/spider_test
SpiderTester is an automated integration-testing script written by Courtenay that iterates over every page in your application.
It performs a few valuable tasks for you:
Parses the HTML of every page, so if you have invalid HTML, you will be warned.
Finds every link within your site and follows it, whether static or dynamic.
Finds every Ajax.Updater
link and follows it.
Finds every form and tries to submit it, filling in values where possible.
This plugin is helpful in determining
Missing static pages (.HTML).
Poor code coverage—forgot to test a file? Don’t wait for a user to find it.
Simple fuzzing of form values.
Automated testing of form paths. Often we have forms that point to incorrect locations, and until now this has been impossible to test in an automated fashion or without being strongly coupled to your code.
Screencasts are videos distributed online that teach you a narrowly focused topic of interest by capturing actual screen output (hence the name) while the author explains concepts and writes code.
Ruby on Rails Podcast producer Geoffrey Grosenbach describes his PeepCode screencasts as “a high-intensity way to learn Ruby on Rails website development.”
In reality, he uses his extensive knowledge and soothing voice to gently guide viewers into some of the deeper areas of Rails know-how. A new hour-long video screencast is released each month. They cost 9 USD each, but are well worth the expense in my opinion.
Short on cash? Host Ryan Bates posts a new screencast almost every week for free. Episodes are shorter and more narrowly focused than the PeepCode ones, and targeted at intermediate Ruby on Rails developers.
In the last several years, Subversion (SVN) has become the predominant source-control management (SCM) system, and for good reasons. It is fast, stable, and is a huge improvement over its predecessor, CVS.
The Rails world is wedded to Subversion in various ways, particularly with its plugin system, which depends on Subversion to pull down plugin files from repositories.
What to do if you’re stuck having to use an evil SCM, such as ClearCase or StarTeam (and you can’t move to a more sensible employer)? One strategy that has been successful at times is to establish an SVN repository that you control for day-to-day development, and only check in packaged releases of your application to the main SCM.
A number of bloggers have suggested custom rake tasks that make working with Subversion more convenient. Create a lib/tasks/svn.rake
file in your Rails project and add the following task definitions to it.
Listing B.1 is a task that automatically sets up a new Rails project with the proper subversion repository settings, including ignores.
Example B.1. Configure Subversion for Rails Custom Rake Task
namespace :rails do desc "Configure Subversion for Rails" task :configure_for_svn do system "svn propset svn:ignore -R '.DS_Store' . --force" system "svn update" system "svn commit -m 'ignore all .DS_Store files'" system "svn remove log/* --force" system "svn commit -m 'removing all log files from subversion'" system "svn propset svn:ignore '*.log' log/ --force" system "svn update log/" system "svn commit -m 'Ignoring all files in /log/ ending in .log'" system "svn propset svn:ignore '*' tmp/sessions tmp/cache tmp/sockets" system "svn commit -m 'Ignoring all files in /tmp/'" system "svn propset svn:ignore '*.db' db/ --force" system "svn update db/" system "svn commit -m 'Ignoring all files in /db/ ending in .db'" system "svn move config/database.yml config/database.example -- force" system "svn commit -m 'Moving database.yml to database.example to provide a template for anyone who checks out the code'" system 'svn propset svn:ignore "locomotive.yml database.yml" config/ --force' system "svn update config/" system "svn commit -m 'Ignoring locomotive.yml and database.yml'" system "script/plugin install -x http://dev.rubyonrails.org/svn/rails/plugins/exception_notification/" end end
Listing B.2 declares an svn
namespace and five tasks related to checking status, adding and deleting working files, and checking in code.
Example B.2. Useful Subversion Rake Tasks
namespace :svn do task :st do puts %x[svn st] end task :up do puts %x[svn up] end task :add do %x[svn st].split(/ /).each do |line| trimmed_line = line.delete('?').lstrip if line[0,1] =~ /?/ %x[svn add #{trimmed_line}] puts %[added #{trimmed_line}] end end end task :delete do %x[svn st].split(/ /).each do |line| trimmed_line = line.delete('!').lstrip if line[0,1] =~ /!/ %x[svn rm #{trimmed_line}] puts %[removed #{trimmed_line}] end end end end desc "Run before checking in" task :pc => ['svn:add', 'svn:delete', 'svn:up', :default, 'svn:st']
A comprehensive survey and description of the Rails community online would take too much time to compile and get out of date quickly, but I do want to highlight workingwithrails.com (or WWR for short), an open database of all things related to the people and groups doing Rails development. It is lovingly crafted (with Rails) by Martin Sadler and his UK-based company DSC.
Over time, I’ve found that WWR is one of the most effective ways to get your name out there and identify yourself as a member of the professional Rails community, especially if you’re soliciting work as an independent contractor. If you’re hiring, or looking for good people to work with, WWR is also a fantastic resource for identifying popular members of the community and talented developers in your local area.
If you enjoyed this book and found it useful, please consider recommending its author, contributors, and principle reviewers:
If you want to take your use of Subversion on Rails projects to the next level, check out the excellent article at http://railspikes.com/2007/8/20/subversion-hooks-in-ruby.
52.14.82.217