Author: Matthew

  • Add layout checking to test_spec_on_rails

    test_spec_on_rails is a plugin that adds Rails-specific assertions to test_spec, allowing you to do nifty things like this:

    it "should render with foo template" do
      get :some_action
      template.should.be "foo"
      # equivalent to assert_equal "foo", @response.template
    end
    
    it "should display foo on page" do
      get :some_action
      page.should.select "p", "foo"
      # equivalent to assert_select "p", "foo"  
    end
    

    One thing test_spec_on_rails is missing, though, is the ability to check the layout that a template renders with. For example, it would be nice to do this:

    it "should render with foo layout" do
      get :some_action
      layout.should.be "foo"
      # equivalent to assert_equal "foo", @response.layout
    end
    

    I’ve submitted a patch to Rick Olson that adds this capability. I’m not sure if or when it will get incorporated into the plugin though, so I’m posting the patch here for anyone who might need it.

    To apply, right-click on the link and download the file into your vendor/plugins/test_spec_on_rails folder, then run this command from inside the same folder:

    patch -p0 < add_layout.diff
    

    Assuming your plugin isn't checked out as an external, you'll be able to commit the changes to your own repository. You can then start using the new hotness as described above. Enjoy!

    Update: Rick made me a committer so I was able to add this myself.

  • Fix for fixture_replacement2 when using default methods

    I’ve been using the excellent fixture_replacement plugin for several months now and greatly prefer it over traditional fixtures (yes, even foxy fixtures). fixture_replacement2 adds even more goodness to the party. However, I ran into a problem today when trying to use default_xxx methods in my example_data.rb file:

    module FixtureReplacement
      attributes_for :course do |c|
        c.name = "Geometry"
        c.transcript = default_transcript
      end
      
      attributes_for :transcript do |e|
        e.name = "Joe's Transcript"
      end
    end
    

    In “fixture_replacement language” this says that new courses should receive a default name of “Geometry” and should also receive a new transcript with a default name of “Joe’s Transcript.” The example above follows the format given in the fixture_replacement README. When I attempt to use this config file in my Rails 2.0.2 project, though, I get this error:

    NameError: undefined local variable or method `default_transcript' for FixtureReplacement:Module
    at top level in example_data.rb at line 7
    ...
    

    Why can’t it find default_transcript? I have no idea. Digging into the source code reveals that default_transcript is added to the FixtureReplacement module at runtime, but for some reason it doesn’t ever show up as being available for calling. I don’t have the time or inclination to dig further, but I did find a workaround by changing:

    c.transcript = default_transcript
    

    to…

    c.transcript = c.default_transcript
    

    This makes fixture_replacement happy and all my tests pass. I submitted a patch so hopefully this wrinkle will be ironed out soon. But this should get you by until then.

  • Vacate room when CFL bulb breaks

    Anyone else think we’re shooting ourselves in the foot on this one? If the choice is between greater power consumption and mercury poisoning, I think I’ll opt for greater consumption, thanks. The more government tries to solve these problems for us, the worse things get. Here’s a novel idea: why don’t we all just start turning off the lights when we leave the room? I know, I know… shocking concept.

  • CSV transmogrifies into FasterCSV in Ruby 1.9

    Matz let Ruby 1.9 into the wild last month. One nice change (among many) is that Ruby’s painfully slow CSV library has been replaced with James Edward Gray II’s most excellent FasterCSV library. This will most likely break existing code that uses CSV.

    From James’ blog:

    The methods provided on the CSV object are similar, but the old CSV code used positional parameters where as the new library user a Hash argument syntax (e.g., :row_sep => "rn"). That’s going to trip up any non-trivial usage.

    He also gave an example of how to write CSV code that interoperates with 1.8 and 1.9:

    require "csv"
    if CSV.const_defined? :Reader
      # use old CSV code here…
    else
      # use FasterCSV style code, but with CSV class, here…
    end
    

    Yes, it’s kind of gross, so just make sure you never have to write it. If you’re going to move to 1.9, move everything and avoid the hassle.

    I’m pretty excited about the performance improvements and other enhancements that have been made in 1.9. This is the first major release of Ruby since I began hacking on it back in the day. It’s a thrill to be part of a community that avoids the “machine gun” approach to releases.

  • visual_effect bug fix in Rails 2.0

    I noticed something interesting while enhancing Teascript today. I recently upgraded the app to Rails 2.0 which ended up breaking several of the Scriptaculous visual effects that I had been using to highlight certain parts of the page when things changed. This is how I had called visual_effect in the past:

    page.visual_effect :highlight, "activities_list", :endcolor => "'#DDDDDD'"
    

    Notice the extra set of single quotes inside the endcolor value. I had to add these single quotes due to a small bug in the Scriptaculous helper. Apparently, the helper didn’t automatically place single quotes around the endcolor value when emitting JS for the page. Well, the good news is that this has been fixed in Rails 2.0, so I was able to update my visual_effect calls to:

    page.visual_effect :highlight, "activities_list", :endcolor => "#DDDDDD"
    

    The bad news is that this change broke Teascript for several days since I initially didn’t notice what was going on. But all is well now, and I’m happy that I don’t have to add those useless single quotes any more.

  • Generating database migrations with Merb

    I’ve been futzing with the goodness that is Merb lately. It’s nifty. Really nifty. The documentation is pretty rough though. I’ll be posting some of my discoveries here. Maybe it will help someone who, like me, was a tad lost early on.

    One of the first things that confused me was migrations. Merb has script/generate just like Rails, but script/generate --help didn’t list a generator for migrations. When I attempted to generate a migration, I was promptly greeted with this pleasantness:

    $ script/generate migration CreateUsers
    Started merb_init.rb ...
    Loading Application...
    Compiling routes..
    Loaded DEVELOPMENT Environment...
    Couldn't find 'migration' generator
    

    Turns out that Merb doesn’t support databases by default. The Merb-specific ActiveRecord plugin has to be installed and switched on before migrations become available.

    (There are several ORM plugins to choose from as documented in the README, but I’ve had very little success getting the others to work so far.)

    Generate your Merb project:

    sudo gem install merb
    merb my_project
    cd my_project
    

    Install the ActiveRecord plugin thusly:

    sudo gem install merb_activerecord
    

    Now open up config/dependencies.rb and uncomment the following line:

    use_orm :activerecord
    

    The first time you run script/generate after doing this, you’ll get:

    Started merb_init.rb ...
    No database.yml file found in my_project/config.
    A sample file was created called database.sample.yml for you to copy and edit.
    

    Copy config/database.sample.yml to config/database.yml and customize as needed. (Don’t forget to create the test and development databases.)

    Now generate your first migration:

    script/generate migration CreateUsers
    

    And you’re off to the races.

  • Who’s On First?

    Here’s a video to celebrate the new year. This is an imitation of the classic Abbott and Costello routine. My brother and I have been doing it for over a decade now. Here’s a version from 4 years ago at the NCHE conference in North Carolina. Enjoy!

  • MultiRails grows one release older

    MultiRails is a plugin that makes it easy to test Rails applications against multiple versions of Rails. Built by the cool guys at this place (mainly Rob Sanheim), MultiRails version 0.0.3 has just been released. Check it out.

  • UI for acts_as_tree

    The current project I’m on requires us to give administrators the ability to modify a tree of models built using acts_as_tree (now a plugin as of Rails 2.0). The acts_as_tree plugin is simple and elegant, but I’ve struggled to find a pre-built UI framework for acts_as_tree that is equally compelling. Can anyone recommend a good, simple (AJAX optional) plugin for generating a UI for acts_as_tree? Please post a comment.