Posts Tagged ‘Ruby’

–no-rdoc –no-ri

No Comments »

By default when you `gem install` something you’re going to get the RDoc (generated HTML documentation based on the source code) and ri (index for viewing the documentation offline) that comes along with it. You could:

#console
$ gem install terminitor --no-rdoc --no-ri

… if you aren’t worried about the documentation. The problem is, of course, remembering to add those command line arguments every time. Fortunately there is an easy solution – like all good Unix utilities `gem` will read `/etc/gemrc` or `~/.gemrc` for default configuration options. The RC files are in YAML format; to globally disable rdoc and ri generation during gem installation for just yourself:

#~/.gemrc
gem: --no-rdoc --no-ri

To understand exactly what you are turning off read: Ruby ri Tool. Honestly since I’ve just now bothered to read how to use `ri` I will probably leave it on for my workstations and just turn it off for my servers.
For other things you can do in your `.gemrc` file read the documentation.


Patching 1.9.2-p180 for significantly faster load times

No Comments »

I assume this patch is going to end up in 1.9.3 but in the mean time: How To Get That Edge Ruby Faster-Loading-Hotness in Ruby 1.9.2 Now

Very easy to do, even for someone fairly new to Ruby, like me. You’ll end up having to change your `.rvmrc` file to `rvm use ruby-1.9.2-p180-patched` and do the necessary steps to populate the new gemset (`gem install bundler ; bundle install`).

My guard/rspec/spork/growl went from a 1-2 second delay to pretty much instantaneous when saving a spec or associated controller/model/helper. `bundle exec rake cucumber` also doesn’t feel nearly as sluggish.


ActiveRecord new(&block) vs. new({ })

No Comments »

Assume the following ActiveRecord::Base class:

#./app/models/army_list.rb
class ArmyList < ActiveRecord::Base
  belongs_to :game_system

  validates :name, :presence => true
  validates :points, :numericality => true
  validates :game_system, :presence => true
end

I was just pulling my hair out over this spec I was writing to make sure all my validations were working properly:

#./spec/models/army_list_spec.rb
describe ArmyList do
  it "should be valid" do
    ArmyList.new(:name => "Name", :points => 1500, :game_system => Factory(:game_system)).should be_valid
  end
end

Changing it from the constructor method to the block method works however:

#army_list_spec.rb
describe ArmyList do
  it "should be valid" do
    ArmyList.new do |al|
      al.name = "Name"
      al.points = 1500
      al.game_system = Factory(:game_system)
    end
    .should be_valid
  end
end

Now that I’ve solved this problem it makes sense. The ActiveRecord::Base documentation for #new states

[...] valid attribute keys are determined by the column names of the associated table – hence you can’t have attributes that aren’t part of the table columns.

Because the column name is actually `game_system_id` it doesn’t make sense that I’d be assigning `game_system` – an attribute that doesn’t exist on the table – by using this form of the constructor.


View Specs and RSpec 2

No Comments »

I get this feeling that speccing views in Rails may be pooh-poohed but with this being my first substantive Rails project I wanted to run the full gamut. As I’m using RSpec 2 I discovered that what I thought would be a readily available tag matching assertion is just gone; this is functionality that was available in RSpec 1 but removed due to its rigidness/difficulty to maintain and the fact that Webrat has `have_selector` for performing a similar task.

But I really wanted the simplistic and easily readable `have_tag` syntax so I looked around to see what else was out there. I stumbled across rspec2-rails-view-matchers which was exactly what I was looking for.

I ended up with the following code for testing that one of my show views has the required links for navigation (among other things):

#spec/views/army_lists/show.html.haml_spec.rb
require 'spec_helper'

describe "army_lists/show.html.haml" do
  subject do
    assign(:army_list,
      stub_model(ArmyList,
        :name => "Name",
        :user => User.new do |u|
          u.display_name = "John Smith"
          u.id = 1
        end,
        :game_system => GameSystem.new do |gs|
          gs.id = 1
          gs.name = "Generic Game System"
        end
      )
    )
    render
    rendered
  end

  it { should have_tag("a", :text => "John Smith") }
  it { should have_tag("p", :text => /Name/m) }
  it { should have_tag("a", :text => /Generic Game System/m) }
end

RSpec2, rspec-rails and #route_to

No Comments »

If you want to spec out your routes you’ll need:

#console
$ mkdir ./spec/routing
$ touch ./spec/routing/users_spec.rb

Let’s say you have this in `routes.rb`:

#./config/routes.rb
⋮
get "users/:id" => 'users#show'
⋮

In your routing spec you’ll want to make sure you are testing numeric `:id` values as strings since that’s what they really are in this instance.

#./spec/routing/users_spec.rb
require 'spec_helper'

describe "routing to users" do
  it "routes /users/:id to users#show for id" do
    { :get => "/users/42" }
      .should route_to(:controller => "users", :action => "show", :id => "42")
  end
  it "should not expose all users" do
    { :get => "/users" }.should_not be_routable
  end
end

Meaning if you did the following:

#./spec/routing/users_spec.rb
⋮
{ :get => "/users/42" }.should route_to(:controller => "users", :action => "show", :id => 42)
⋮

… its going to keep failing and you may resort to testing routes you know that work the same exact way and then you will be driven further and further from sanity.