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.

sudo gem install color --source require.errtheblog.com

sudo gem install redgreen --source require.errtheblog.com

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.

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.

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.

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

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: