I posted previously about my restful_authentication fork.

I recently pushed an example application repository that shows what a generated app from my fork might look like; 100% passing specs, cucumber features, and lots of cleanup. If you find it useful, or find some issues, drop me a line.

I’ve been using bundler happily for the last month or so, and if you haven’t already checked it out, there’s numerous other sources that can explain it better than I can. Go check them out. Today I want to focus on CI and what having 60 megs of bundled code can mean for your builds.

Each of our builds are about 70 meg, 60 megs for the bundled code, a few megs in logs and a few megs in code. We generally push about 10-15 times per day. Right now we have 3 main projects going on. Even though I forked Integrity to only keep builds for a limited time, which in our case is 14 days, one app could still use as much as 10 gigs of space to store 14 days of builds. When you consider that we have three apps, with several more starting soon, these numbers were starting to look really scary.

We worked out a simple solution that seems to solve our problem, and actually speed up our builds. We set an environment variable, right now called CI, which specifies where the bundled gems lives. When we do a bundle, we do: CI=/path/to/bundled/gems gem bundle && rake integrity:all.

We modified both our Gemfile and preinitializer as follows:

Gemfile:

bundle_path ENV['CI'] ? ENV['CI'] : 'vendor/bundled_gems'

And preinitializer:

bundle_path = ENV['CI'] ? ENV['CI'] ? 'vendor/bundled_gems'

require "#{File.dirname(__FILE__)}/../#{bundle_path}/environment"

This allows developers on their local machine to just do a normal “gem bundle” to run the app, but gives us flexibility on the build machine to point at a relative path where the bundled gems will live, outside of the application. That means the bundled gems just get updated, instead of getting pulled each time.

How are you managing bundled gems and Continuous Integration? What do you do with your gigs worth of old builds?

At Work, we’re continuing the search for good Rails developers (or good general developers who want to do Rails) that live in the Boston area.

A reoccurring theme in the search is that very few developers are writing tests. Only about 4 out of 10 developers we talk to have Rails experience, and out of those maybe 1 out of 10 (if we’re lucky) write tests regularly.

Where do you find good Rails developers when hiring? Do you find the same issues with Rails developers not writing tests?

I had to do a bit of running around to get Rspec, Cucumber, and rcov working together nicely; here’s my current rake task:

require 'cucumber/rake/task'

require 'spec/rake/spectask'

namespace :rcov do

  Cucumber::Rake::Task.new(:cucumber) do |t|    

    t.rcov = true

    t.rcov_opts = %w{--rails --exclude osx\/objc,gems\/,spec\/,features\/ --aggregate coverage.data}

    t.rcov_opts << %[-o "coverage"]

  end

  Spec::Rake::SpecTask.new(:rspec) do |t|

    t.spec_opts = ['--options', "\"#{RAILS_ROOT}/spec/spec.opts\""]

    t.spec_files = FileList['spec/**/*_spec.rb']

    t.rcov = true

    t.rcov_opts = lambda do

      IO.readlines("#{RAILS_ROOT}/spec/rcov.opts").map {|l| l.chomp.split " "}.flatten

    end

  end

  desc "Run both specs and features to generate aggregated coverage"

  task :all do |t|

    rm "coverage.data" if File.exist?("coverage.data")

    Rake::Task['rcov:rspec'].invoke

    Rake::Task["rcov:cucumber"].invoke

  end

end

Running rake rcov:all should give you nice coverage data that includes both rspec and cucumber.

RESTful authentication has fallen out of favor as the authentication system of choice while building new projects, but I still find it simple enough to hack on and easy to implement in a new project. RESTful authentication coupled with Declarative Authorization gives you a nice full solution to authentication and authorization in most cases.

Although RESTful authentication is easy to set up and use, it’s use of fixtures and extensive custom cucumber steps that collide with built-in webrat steps have caused me to continuously rewrite my specs and features when setting up new projects. I finally got irritated enough by the whole situation today that I decided to fork RESTful auth, completely swap out fixtures, and rewrite all the cucumber features. No more static data: no more quentin, aaron, etc. Just User.make to generate random users and away we go.

Hopefully, you find my fork useful. Here’s a really quick “Getting Started” to show how simple you can get up and going:

• rails app_name

• git submodule add git://github.com/jeremydurham/restful-authentication.git vendor/plugins/restful_authentication

• script/generate rspec

• script/generate cucumber

• generate some code and setup a root path (map.root)

• Make sure you include flash[:error] and render :partial => ‘users/user_bar’ in your application layout, or tweak the features and specs as necessary

• script/generate authenticated user —rspec

• Add the appropriate paths to features/support/paths.rb (they are printed to STDOUT when generating RESTful auth)

• rake db:migrate

• move “include AuthenticatedSystem” to application_controller

At this point, running “rake spec” or “rake features” should both pass, and running the application should allow you to log in, log out, and sign up. Hopefully, this process took you no more than a few minutes, and you’re up and running!

If you’re looking for excellent authorization (roles, rules, etc) then make sure you take a look at declarative authorization.