Anyway, enough excuses, here are few tips that I believe will be useful to some of you:

ZenTest Autotest

I love autotest, but you might have noticed that sometimes (especially on big projects), ZenTest might start using more CPU than expected. On my machine, that results in the fan going off and annoying the crap out of me.

The solution is quite simple, exclude all folders you don’t need to monitor. To do that, update ZenTest to version 3.8.X

sudo gem update ZenTest

(older version had a different syntax)

Now, edit your .autotest that should be located in ~/.autotest (if it doesn’t exist, create it).

Finally add the following code:

1
2
3
4

  Autotest.add_hook :initialize do |at|
    %w{.svn .hg .git vendor}.each {|exception| at.add_exception(exception)}
  end

I personally freeze rails in vendor and I autotest is way happier when it doesn’t have to monitor some extra files. (note that we also exclude folders such as .git or .svn)
(you can also include files etc… read more there)

RSpec

RSpec is certainly my favorite Ruby tool and I’m glad to say that most of my SD.rb friends finally got convinced!

Now, few people complained to me about spec failures outputting the full stack such as:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

 The Sessions controller should fail since it's a test' FAILED
 expected true, got false
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/expectations.rb:52:in `fail_with'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/expectations/handler.rb:21:in `handle_matcher'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/expectations/extensions/object.rb:34:in `should'
 ./spec/controllers/sessions_controller_spec.rb:25:
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/example/example_methods.rb:78:in `instance_eval'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/example/example_methods.rb:78:in `run_with_description_capturing'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/example/example_methods.rb:19:in `execute'
 /opt/local/lib/ruby/1.8/timeout.rb:48:in `timeout'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/example/example_methods.rb:16:in `execute'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/example/example_group_methods.rb:288:in `execute_examples'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/example/example_group_methods.rb:287:in `each'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/example/example_group_methods.rb:287:in `execute_examples'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/example/example_group_methods.rb:121:in `run'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/runner/example_group_runner.rb:22:in `run'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/runner/example_group_runner.rb:21:in `each'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/runner/example_group_runner.rb:21:in `run'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/runner/options.rb:89:in `run_examples'
 test_app-git/trunk/vendor/plugins/rspec/lib/spec/runner/command_line.rb:19:in `run'
 script/spec:4:

  Finished in 6.035147 seconds

  400 examples, 1 failure

We can really easily change that, open you spec.opts file located in your spec folder.

it probably looks like that:

1
2
3
4
5
6
7
8

  --colour
  --format
  progress
  --loadby
  mtime
  --reverse
  --backtrace

Get rid of “–backtrace” and your new failure should look like:

1
2
3
4
5
6
7
8
9
10
11

  1)
  'The Sessions controller The Sessions controller should fail since it's a test' FAILED
  expected false, got true
  ./spec/controllers/sessions_controller_spec.rb:25:
  script/spec:4:

  Finished in 0.269956 seconds

  15 examples, 1 failure
  

Other stuff you may find interesting (in no particular order):

• spec converter
• Rails Cell
• Git to manage and deploy a Rails app
• contacts (retrieve user’s contacts from yahoo, gmail etc..)
• Hashrocket
• one of the best Rails book of the moment
• err’s new baby
• caboose conf 08
• git hub
• SWX Ruby (or how to get Rails to talk with Flash even faster)
• Ruby Reddit

Since a lot of people seemed interested by the topic, the SDRuby guys asked me to do a intro talk on how to create Sexy Charts with super sexy Rails.

In the mean time, a lot of people were asking for a example app to look at. People knowing me know that I’m quite lazy and I don’t like repeating tasks. I therefore decided to kill 2 birds with one stone and wrote a demo app that I would use during my presentation

As I was writing the demo app, I quickly realized that my talk would be even sexier if I would show some best practices. After all, an introduction talk is meant to help newbies learning the tricks that will change them in ninjas!

Sexy charts are sexy now, but in 15 years they might not look so sexy anymore. However BDD is super hot now and will always be sexy! (even though we’ll probably adopt other even hotter approaches).

Based on the circumstances I decided that Sexy charts would become an excuse to show people how to do BDD using RSpec and how to test a XML view as described in this previous post

During my presentation I totally forgot to show people what what kind of XML we were trying to feed amCharts, so here is the file:

http://pastie.caboo.se/120055

The code used in the presentation is also available here

Presentation available here (the sound is a bit saturated, sorry about that. Note that we made the video big enough so you can follow with the code if you don’t understand my accent )

Feel free to watch the other SDRuby podcasts or even better, subscribe to our feed.

Next SDRuby meeting will be Thursday, December 6 @ 7:30pm

Location: UCSD CS Building

We’ll be talking about Unobtrusive Javascript, the Facebook API, and hosting our first Rails Roundtable.

Newbies and experts welcome!

Since I’ve started using RSpec I’ve started writing tests against my views. RSpec makes things really easy and I’ve been enjoying testing my views.

I’m not the only one having fun, check this great post from Mr Planet Argon aka Robby Russel

Recently I was working on implementing some Sexy Charts and I was using a XML builder to create an XML view of for a controller. Since I wanted to be a good Rails Ninja and obey the BDD rules, I figured I needed to test my XML view. Making sure that the nodes and the attributes were properly created. Turned out that is wasn’t too hard, there was many options but none were very well documented so I decided to write this quick tutorial.

UPDATE 31 Oct 2007: After a comment from Josh Knowles, I updated the tests to test with have_tags (built in RSpec) and hpricot.

Hpricot

hpricot is a awesome HTML parser perfect for screen scraping. But wait, there’s more to this awesome library, hpricot can also parse XML.

If you watched the excellent RSpec peepcasts you probably noticed that topfunky aka Geoffrey Grosenbach uses hpricot to test a remote API.

In our case, we’ll use hpricot to test that our generated XML follows our expectations.

XML Builder + RSpec

Let’s write a quick test to make sure our controller uses a XML builder view:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

  describe AveragesController, "handling GET /averages.xml" do

    before do
      Average.stub!(:find).and_return(@average)
    end
  
    def do_get
      @request.env["HTTP_ACCEPT"] = "application/xml"
      get :index
    end
  
    it "should render the action using the XML builder" do
      do_get
      response.should render_template('averages/index.xml.builder')
    end

  end

To make this example pass, we need to modify our rspec generated controller.

1
2
3
4
5
6
7
8

  def index
    @averages = Average.find(:all)
  
    respond_to do |format|
      format.html # index.html.erb
      format.xml  { render :action => "index.xml.builder", :layout => false }
    end
  end

(Please note that I’m using Rails 2.0 and that’s why I’m not using a .rxml view)

Here is what our XML file should end up looking like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

  <?xml version="1.0" encoding="UTF-8"?>
  <chart>
    <series>
      <value xid="0">January</value>
      <value xid="1">February</value>
      <value xid="2">March</value>
      <value xid="3">April</value>
      <value xid="4">May</value>

      <value xid="5">June</value>
      <value xid="6">July</value>
      <value xid="7">August</value>
      <value xid="8">September</value>
      <value xid="9">October</value>
      <value xid="10">November</value>

      <value xid="11">December</value>
    </series>
    <graphs>
      <graph fill_alpha="50" color="#FF0000" fill_color="#CC0000" title="high">
        <value xid="0">65.1</value>
        <value xid="1">65.7</value>
        <value xid="2">64.9</value>

        <value xid="3">66.7</value>
        <value xid="4">67.1</value>
        <value xid="5">69.3</value>
        <value xid="6">73.0</value>
        <value xid="7">74.8</value>
        <value xid="8">75.4</value>

        <value xid="9">73.4</value>
        <value xid="10">68.9</value>
        <value xid="11">65.3</value>
      </graph>
      <graph fill_alpha="50" color="#0000CC" fill_color="#0000CC" title="low">
        <value xid="0">48.9</value>
        <value xid="1">50.7</value>

        <value xid="2">52.9</value>
        <value xid="3">55.6</value>
        <value xid="4">59.2</value>
        <value xid="5">61.9</value>
        <value xid="6">65.7</value>
        <value xid="7">67.3</value>

        <value xid="8">65.7</value>
        <value xid="9">61.0</value>
        <value xid="10">54.0</value>
        <value xid="11">48.7</value>
      </graph>
    </graphs>
  </chart>
  

Let’s write some tests to make sure our view is ok:

index.xml.builder_spec.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

require File.dirname(__FILE__) + '/../../spec_helper'
require 'hpricot'

describe "/averages/index.xml.builder" do
  include AveragesHelper
  
  before do
    average_1 = mock_model(Average)
    average_1.stub!(:month).and_return("January")
    average_1.stub!(:high).and_return("74.5")
    average_1.stub!(:low).and_return("61.5")
    average_2 = mock_model(Average)
    average_2.stub!(:month).and_return("February")
    average_2.stub!(:high).and_return("82.5")
    average_2.stub!(:low).and_return("71.5")

    assigns[:averages] = [average_1, average_2]
  end

  it "should render the months in the series" do
    render "/averages/index.xml.builder"
    response.should have_tag("value", 'January')
    response.should have_tag("value", 'February')
    # Same thing but with Hpricot
    doc = Hpricot.XML(response.body.to_s)
    (doc/:value).first.inner_html.should == 'January'
    (doc/:value)[1].inner_html.should == 'February'
  end
  
  it "should set the xid attributes for the series" do
    render "/averages/index.xml.builder"
    response.should have_tag("value[xid=0]:first-child")
    response.should have_tag("value[xid=1]:last-child")
    # Same thing but with Hpricot
    doc = Hpricot.XML(response.body.to_s)
    (doc/:value).first["xid"].should == '0'
    (doc/:value).last["xid"].should == '1'
  end
  
  it "should have 2 graphs and they should have a title" do
    render "/averages/index.xml.builder"
    response.should have_tag("graph[title=high]:first-child")
    response.should have_tag("graph[title=low]:last-child")
    # Same thing but with Hpricot
    doc = Hpricot.XML(response.body.to_s)
    (doc/:graph).size.should == 2
    (doc/:graph).first["title"].should == 'high'
    (doc/:graph).last["title"].should == 'low'
  end
  
  it "should have a color set by graph" do
    render "/averages/index.xml.builder"
    response.should have_tag("graph[color]:first-child")
    response.should have_tag("graph[color]:last-child")
    response.should have_tag("graph[fill_color]:last-child")
    response.should have_tag("graph[fill_alpha]:last-child")
    # Same thing but with Hpricot
    doc = Hpricot.XML(response.body.to_s)
    (doc/:graph).first["color"].should_not be_nil
    (doc/:graph).last["color"].should_not be_nil
    (doc/:graph).last["fill_color"].should_not be_nil
    (doc/:graph).last["fill_alpha"].should_not be_nil
  end
  
  it "should have an xid for each graph value" do
    render "/averages/index.xml.builder"
    response.should have_tag("graph > value[xid=0]:first-child")
    # Same thing but with Hpricot
    doc = Hpricot.XML(response.body.to_s)
    (doc/:graph/:value).first["xid"].should == "0"
  end
  
  it "should have the high average as values of the first graph" do
    render "/averages/index.xml.builder"
    response.should have_tag("graph > value:first-child", "74.5")
    # Same thing but with Hpricot
    doc = Hpricot.XML(response.body.to_s)
    (doc/:graph/:value).first.inner_html.should == "74.5"
  end
  
end

The first thing you must do (after installing the hpricot gem) is to require hpricot in your test:

  require 'hpricot'

Now that hpricot is created we can use it to parse the response and check against our expectations.

(we create mock objects to pass to the view so we know exactly what to expect and we separate Model/Controller/Views tests)

To check against our response we have to use hpricot parser syntax. It might look at bit funny at first, but believe me it’s really easy once you get it.

But first, let’s parse the view:

1
2
3
4

# Render the mocked up data using the xml view
render "/averages/index.xml.builder"
# Load and parse the view response body:
doc = Hpricot.XML(response.body.to_s)  

Let’s look at the first test:

1
2
3
4
5
6

  it "should render the months in the series" do
    render "/averages/index.xml.builder"
    doc = Hpricot.XML(response.body.to_s)
    (doc/:value).first.inner_html.should == 'January'
    (doc/:value)[1].inner_html.should == 'February'
  end

(doc/:value) returns all the value nodes, we take the first one and extract its content. We expect that it would match the name of the month for the first average.

Let’s now look at another test:

1
2
3
4
5
6
7

  it "should have 2 graphs and they should have a title" do
    render "/averages/index.xml.builder"
    doc = Hpricot.XML(response.body.to_s)
    (doc/:graph).size.should == 2
    (doc/:graph).first["title"].should == 'high'
    (doc/:graph).last["title"].should == 'low'
  end

The thing to look at here is the fact that we are checking on the node’s attribute “title”. Really simple syntax and clean test, isn’t it?

Finally let’s look at the last example:

1
2
3
4
5

  it "should have the high average as values of the first graph" do
    render "/averages/index.xml.builder"
    doc = Hpricot.XML(response.body.to_s)
    (doc/:graph/:value).first.inner_html.should == "74.5"
  end

We are checking that the content of the first value node nested inside a graph node is equal to 74.5 which is the high average for the first month.

In practice, you probably won’t write all these tests at once, but anyway, let’s look at our XML builder which will make all these tests pass:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

xml.instruct!   ml, :version=>"1.0", :encoding=>"UTF-8"
xml.chart do
  xml.series do    
    @averages.each_with_index do |average, index|
      xml.value average.month,   id => index
    end
  end
  
  xml.graphs do
    xml.graph :title => 'high', :color => "#FF0000", :fill_alpha => "50", :fill_color => "#CC0000" do
      @averages.each_with_index do |average, index|
        xml.value average.high,   id => index
      end
    end
    
    xml.graph :title => 'low', :color => "#0000CC", :fill_alpha => "50", :fill_color => "#0000CC" do
      @averages.each_with_index do |average, index|
        xml.value average.low,   id => index
      end
    end
  end
  
end

Hpricot is a really nice tool which can make your BDD life much easier. And even if you don’t do BDD/TDD yet, it’s a great way to verify that any XML data you receive/generate is valid.

Happy testing

I have a set of RSpec examples I use all the time on all my projects requiring restful_authentication, obviously I always end up tweaking them because each application has its specific needs.

However, I was recently asked what’s the way of dealing with controllers specs when a controller has a limited access ?

Let’s look at the following controller for instance:

class AssetController < ApplicationController
 before_filter :login_required, :except => [ :index, :show ]

my assets_controller_spec.rb file will have the following code:

describe AssetController, "handling GET /assets/new" do

  before do
    @asset = mock_model(Asset)
    Asset.stub!(:new).and_return(@asset)
  end

  def do_get
    get :new
  end

  it "should be successful" do
    do_get
    response.should be_success
  end

end

and guess what… it will fail! Why? simply because we are trying to access an action requiring login. Right, so what’s the best way of dealing with this issue and get our test to pass?

The best solution I found was to use a simple helper that I put in my spec_helper.rb file

def login_as(user)
  case user
    when :admin
      @current_user = mock_model(User)
      User.should_receive(:find_by_id).any_number_of_times.and_return(@current_user)
      request.session[:user] = @current_user
    else
      request.session[:user] = nil
  end
end

You might wonder why I use when :user, well, in a lot of the application I’m working on, I have different levels of access and I want to tests different accounts so I the case conditional loop.

Anyway, let’s implement our helper in our previous RSpec example:

describe AssetController, "handling GET /assets/new" do

  before do
    login_as :admin
    @asset = mock_model(Asset)
    Asset.stub!(:new).and_return(@asset)
  end

  def do_get
    get :new
  end

  it "should be successful" do
    do_get
    response.should be_success
  end

end

and there you go, now your example passes properly

Have fun

This would work on Mac and Linux, sorry Windows users, you’ll have to slightly change the code below.

Live on the Edge

This is actually a bit tricky but it was very well covered by John Nunemaker in this post

To sum John’s post:

Create a normal rails project:

$ rails my_project
$ cd my_project

$ rake rails:freeze:edge

(or use checkout edge in the vendor folder)

$ cd ..
$ ruby my_project/vendor/rails/railties/bin/rails my_edgie_project

You now have have a real Edge project called myedgieproject. You can delete the my_project folder since we only used it to create our real edge project.

Now, we are not really done since we need to add the Edge files into our vendor folder so we don’t use our local rails gem.

I would refer to another post from John, that you can find there

$ mkdir ~/rails
$ cd ~/rails
$ svn co http://dev.rubyonrails.com/svn/rails/trunk .

We just created a rails folder called rails in our home folder and we checked out edge/trunk in it.
Now let’s go in our Rails app and setup a symlink to the trunk folder we just created.

$ cd ~/rails_projects/my_edgie_project
$ ln -s ~/rails/trunk vendor/rails

If you are using subversion, you can ignore the symlink so it doesn’t try to version it:

$ svn propset svn:ignore "rails" vendor/
$ svn commit -m "using new sweet rails setup as recommended by John Nunemaker"
$ svn up

Read more for advanced settings etc…

Install RSpec

Very straight forward, you just need to follow the documentation

$ cd ~/rails_projects/my_edgie_project
$ ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec
$ ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/CURRENT/rspec_on_rails

If you have TextMate, you might want to download the latest RSpec-X.Y.Z.tmbundle.tgz Bundle

Next thing you want to do is to install ZenTest

$ sudo gem install ZenTest

Make sure you install all the required packages.

If you are using Growl create a new file called .autotest in your home directory:

$mate ~./autotest

and add the following 2 lines to be warned when your specs/examples fail/pass

require 'autotest/redgreen'
require 'autotest/growl'

Now, lets go back to our project and create a model using the rspec scaffold (it uses scaffold_resource generator and create all the specs for you)

$ cd ~/rails_projects/my_edgie_project
$ ruby script/generate rspec_scaffold User first_name:string last_name:string :age:integer

Now, let’s start autotest (from zentest) so out code is tested in the background

$ autotest

There you go, really to modify your RSpec examples, make them fail, fix your code, examples should pass, refactor your code and start again

Today he released something very helpful for the Rails Community, not another Gem or another cool plugin to extend Rails but a web application to help you planning your conferences. We already had other tools such as conference meetup but it’s the first time that we get a product helping you to plan a conference by scheduling the sessions you want to attend.

screenshot of the entire schedule

I had a quick chat with DrNic about his latest creation and here is what he said:

“its been fun building just how I thought session selection might look + feel
web2.0 = permissive voyeurism I think!”

I share the same vision than Nic on session selection and I really enjoyed booking my Rails sessions and seeing what other people selected. (I guess that’s my voyeur side, don’t you like web2.0?)

If you wanna see what I planned on attending, checkout my schedule: my schedule

Thanks Nic for the good work and too bad you are not presenting anything at the RailsConf (move your bum to come up with a better submission next year!)

I really like what Adobe did with Flex, Unit testing, better accessibility, etc… but one thing I regret, it’s getting closer and closer to Java and AS3 syntax is a pain to use when you got used to Ruby.

Anyway, what I really wanted to do was to have Flash quickly access my Restful Rails app. The adobe guys came up with a RoR Ria SDK but well…. it only covers Flex and requires FlashPlayer 9.
I also found some great tutorials on how to use the efficient AMF messaging protocol with Rails using the WebOrb for Rails plugins

All that was really nice and I had fun, but it was an overkill for what I wanted to do. Let me show you how in less than 5 minutes how you can access you Rails Model from Flash and add some new item directly from Flash.

Create your new Rails app and use the script/generate scaffold_resource command to generate your Event Model.

script/generate scaffold_resource Event

It should create all that for you:

exists  app/models/
  exists  app/controllers/
  exists  app/helpers/
  create  app/views/events
  exists  test/functional/
  exists  test/unit/
  create  app/views/events/index.rhtml
  create  app/views/events/show.rhtml
  create  app/views/events/new.rhtml
  create  app/views/events/edit.rhtml
  create  app/views/layouts/events.rhtml
  identical  public/stylesheets/scaffold.css
  create  app/models/event.rb
  create  app/controllers/events_controller.rb
  create  test/functional/events_controller_test.rb
  create  app/helpers/events_helper.rb
  create  test/unit/event_test.rb
  create  test/fixtures/events.yml
  exists  db/migrate
  create  db/migrate/001_create_events.rb
  route  map.resources :events

let’s edit the migration file:
db/migrate/001createevents.rb

class CreateEvents < ActiveRecord::Migration
  def self.up
    create_table :events do |t|
      t.column :title, :string
      t.column :description, :string
      t.column :location, :string
        t.column :starts_at, :datetime
        t.column :ends_at, :datetime
    end
  end

  def self.down
    drop_table :events
  end
end

And let’s add some fixtures:
test/fixtures/events.yml

meeting:
  id: 1
  title: Meeting
  description: Boring meeting with the whole staff
  location: conference room
  starts_at: 2007-11-02 09:00:00
  ends_at: 2007-11-02 10:30:00
Joe_bday:
  id: 2
  title: Joe Bday Party
  description: Come and celebrate Joe's Birthday
  location: Lapin Agile Pub
  starts_at: 2007-09-07 20:00:00
  ends_at: 2007-09-07 23:30:00

Ok, now simply migrate your database,load the fixtures and start the webrick:

rake db:migrate
rake db:fixtures:load
script/server

Great, we are done with Rails.

Let’s launch Flash

Create a new Flash document and create a new .As fie in TextMate (or your favorite editor). We’ll write a quick ActionScript class to access Rails.

class Restfulflash{
    public var gateway:String;

    function Resftfulflash(gateway:String){
        this.set_gateway(gateway);
    }
    public function set_gateway(gateway:String){
        this.gateway = gateway;
        trace("gateway set to:"+gateway);
    }

    public function get(model, callback){
        var railsReply:XML = new XML();
        railsReply.ignoreWhite = true;
        railsReply.onLoad = function(success:Boolean){
            if (success) {
                    trace ('Rails responded: '+railsReply);
                    callback.text = railsReply;
            } else {
                    trace ('Error while waiting for Rails to reply');
               callback.text = 'error';
            }
        }
        var railsRequest:XML = new XML();
        railsRequest.contentType="application/xml";
        railsRequest.sendAndLoad(this.gateway+model, railsReply);
        delete railsRequest;
    }

    public function create(model, newItem){
        railsRequest.onLoad = function(success){
                trace("Item creation success: " + success);
                trace(this);
        };
        var railsRequest:XML = new XML();
        railsRequest.parseXML(newItem);
        railsRequest.contentType="application/xml";
        railsRequest.sendAndLoad(this.gateway+model+'/create/', railsRequest,'POST');
        delete railsRequest;
    }
}

Save this file in the same directory as your .fla file

In your fla file add:

// Create a XML object to hold the events from our Rails app
rails_events = new XML();

// Prepare the connection to Rails (it would be nicer to do that in 1 step, but to make things clearer i decided to do it in 2)
var rails:Restfulflash = new Restfulflash();
rails.set_gateway("http://localhost:3000/");

// Get the events from rails and load the result in the rails_event XML object.
rails.get('events', rails_events);
trace(rails_events);

// Let's create a new event
newEvent = new XML('<event><description>Spend some time with Grandma before its too late</description><ends-at type="datetime">2007-11-02T18:30:00-07:00</ends-at><id type="integer">1</id><location>Paris, France</location><starts-at type="datetime">2007-11-02T16:00:00-07:00</starts-at><title>Visit Grandma</title></event>&#8217;)
rails.create(&#8216;events&#8217;, newEvent);

// Verify  that the event was added
rails.get(&#8216;events&#8217;, rails_events);
trace(rails_events);

There you go, you have all the events provided to you by Rails nicely prepared in an easy to parse XML object. You can bind the results to a Datagrid or display the info the way you want it. Ohh and by the way, we just added a new Event to the database… easy, isn’t it? The code is a bit dirty but it’s still a good example why you need to use REST and how easy it is to get Flash to talk with Rails. (I strongly encourage that you also look at the very good WebOrb plugin for Rails)

In this post I’ll try to go through setting up a plugin for migration and start using RSpec for developing the migration plugin.

What we want is to migrate sites using the legacy application to our new Rails application. That means that new users won’t be be migrated. It therefore makes sense not to add the migrating logic to the main application but to create a plugin. (if you are not familiar with Rails plugins check this blog post from Geoffrey Grosenbach about plugins)

Let’s create our plugin

./script/generate plugin legacy_migration

Rails should have generated something like that:

legacy_migration
|-- init.rb
|-- install.rb
|-- uninstall.rb
|-- Rakefile
|-- README
|-- lib/
|   |-- legacy_migration.rb
|-- tasks/
|   |-- legacy_migration_tasks.rake
|-- test
|   |-- legacy_migration_test.rb

Since we are going to use RSpec, we can remove the test folder and create a spec folder. In our spec folder, let’s add some subfolders to organize our files. Let’s create a fixtures folder to hold, a helpers folder, a migrate folder (we’ll use that to migrate our legacy database) and finally, a models folder.

Our plugin folder should look more or less like that:

legacy_migration
|-- init.rb
|-- install.rb
|-- uninstall.rb
|-- Rakefile
|-- README
|-- lib/
|   |-- legacy_migration.rb
|-- tasks/
|   |-- legacy_migration_tasks.rake
|-- spec
|   |-- fixtures
|   |-- helpers
|   |-- migrate
|   |-- models

Great, let’s get started and let’s create our first spec. We should probably start by migrating users so I’ll create a new spec in the spec/models folder called legacy_user_spec.rb and add the following code:

require File.dirname(FILE) + '/../helpers/legacy_user_helper'
require File.dirname(FILE) + '/../helpers/spec_helper'

describe "a connection to the legacy application" do
  setup do
    @connection_status = LEGACY.connect
  end
end

it "should be connected to the legacy database" do
  @connection_status.current_database.should == ActiveRecord::Base.configurations'legacy'

end

Note that I’m using RSpec trunk/edge and I use “describe” instead of “context” and “it” instead of “specify”. For more information on how to run RSpec edge with TextMate read this previous post.

If we look at the code above, we start by requiring 2 helpers, a general helper called spec_helper and a helper just for this spec called legacy_user_helper (we will obviously need to create them otherwise our spec will failed).

Then we start our first spec by describing a connection to the legacy application and we specify that it should be connected to the legacy database.

Here is our setup code:

setup do
  @connection_status = LEGACY.connect
end

What I want is to retrieve a connection status after I connect to our legacy application. To manage the connection to the legacy application we will create a LEGACY module. We will need to connect to many legacy applications/sites and our module should help us doing that.

Then we can read that our spec checks that we are connected to the legacy database.

it "should be connected to the legacy database" do
  @connection_status.current_database.should == ActiveRecord::Base.configurations'legacy'
end

That means we want to compare the connection status to the ‘legacy’ environment defined in the database.yml file.

We now need to get this spec to pass.

Let’s get started by adding a legacy environment to our database.yml and creating our LEGACY module in our legacy_migration.rb file.

Add the following to your database.yml

legacy:
  adapter: mysql
  database: legacy
  username: root
  password:
  host: localhost

Now, let’s create the LEGACY module in our legacy_migration.rb file

module LEGACY

  # Connect to a Legacy database.
  # Usage:
  # Manual connection: LEGACY.connect(:database => 'legacy-database', :adapter => 'mysql', :username => 'root', :password => '', :host => 'localhost')
  # Auto connection to the database.yml defined legacy DB: LEGACY.connect
  # Connection to any database available in database.yml LEGACY.connect('legacy_test')
  # Connect a class to a specific database: LEGACY.connect(LegacyInstaller, ActiveRecord::Base.configurations['legacy_installer'])
  def self.connect(spec = nil, opt_env = nil)
    case spec
      # Automatically connect to the legacy environment database defined in the database.yml
    when nil
      raise 'Legacy Database not defined' unless defined? ActiveRecord::Base.configurations['legacy']
      LegacyActiveRecord.establish_connection(ActiveRecord::Base.configurations['legacy'])
      # Return the connections status
      LegacyActiveRecord.connection
      # A connection's name from the database.yml can be passed
    when Symbol, String
      if configuration = ActiveRecord::Base.configurations[spec.to_s]
        LegacyActiveRecord.establish_connection(configuration)
      else
        raise "#{spec} database is not configured"
      end
      # Connect a Model to a specific Database
    when Class
      raise 'Environment connection not provided or nil' unless defined? opt_env || opt_env['database'] == nil
      if spec.connection.current_database == opt_env['database']
        spec.connection
      else
        spec.establish_connection(opt_env)
      end
      # An array can be passed to establish the connection
    else
      spec = spec.symbolize_keys
      unless spec.key?(:adapter) then raise "database configuration does not specify adapter" end
        adapter_method = "#{spec[:adapter]}_connection"
        LegacyActiveRecord.establish_connection(spec)
      end
    end
  end

There we go, we have a really cool connect function, we can easily connect to the default legacy environment defined in the database.yml file, we can specify the connection settings, connect to another environment database and even connect one specific class/model to a specific environment. (that will useful since we have many databases). If we wanted to follow the TDD rules, I shouldn’t have written so much code… as a matter of fact, when I worked on this project I did not, but since I don’t have much time, I won’t go through the re-factoring steps.

One thing you might have noticed is that we establish a connection between LegacyActiveRecord and the legacy database. (instead of connecting ActiveRecord to the legacy database).

LegacyActiveRecord.establish_connection(ActiveRecord::Base.configurations['legacy'])

The problem is that we didn’t create the LegacyActiveRecord model yet. Let’s do that right away. Let’s add a new folder called models in our lib folder. In the models folder, let’s create a legacy_active_record.rb file and add the following code:

class LegacyActiveRecord < ActiveRecord::Base
  self.abstract_class = true
end

Cool, now let’s have fun with our new module, fire the console (./script/console) and try LEGACY.connect
Here is what we get back:

    >> LEGACY.connect
    => #nil, :database=>”legacy”, :allow_concurrency=>false, :host=>”localhost”, :username=>”root”, :adapter=>”mysql”}, @connection_options=[“localhost”, “root”, ””, “legacy”, nil, nil], [...]

let’s try to get the database we connected to:

>>LEGACY.connect.current_database
    => “legacy”

Awesome, we can now get our LegacyActiveRecord model to connect to our legacy database and return the connections status. Let’s run our specs……….. they pass.

Sweet, we setup our migration plugin, got our first spec written, added the code needed to get the spec to pass, I think we are done with PART 2

Aslak Hellesoy just mentioned in a comment that the trunk version of RSpec bundle for TextMate ( svn://rubyforge.org/var/svn/rspec/trunk ) doesn’t require the RSpec Gem installed anymore.

To install the bundle:

cd ~/Library/Application\ Support/TextMate/Bundles/
 svn co svn://rubyforge.org/var/svn/rspec/branches/0.9-dev/RSpec.tmbundle

I recently discovered RSpec, well, not really, but I finally got to start using
RSpec.

For those who don’t know
RSpec ,
RSpec is a BDD testing framework, or in better words: RSpec is a Behaviour
Definition Framework well suited for practicing Behaviour Driven Development
(BDD) in Ruby.



If you don’t know what is BDD, then just check out
http://behaviour-driven.org/, in few words, it’s TDD (Test Driven Development in better)



Anyway, I’m working on a Rails project where we use the trunk/edge version RSpec
plugin. I’m using my favorite editor:
TextMate
and I noticed that the RSpec team created a
cool
bundle for textmate.



I was quite excited until I tried running a spec and realized that the task
failed giving some errors about some missing methods… Well, the thing is we
replaced “context … do” by “describe … do” and “specify … do” by “it …
do” see
David’s
post about this specific change in trunk:



The Textmate bundle uses the ruby gem instead of the plugin and since I’m trying
to use methods only defined in trunk the bundle simply dies on me every time I
try to run my specs.



The only solution for me was to run a trunk version of the RSpec gem, here is
what to do:



Check out RSpec trunk from:
svn://rubyforge.org/var/svn/rspec/trunk

Check out RSpec trunk into its own project, or
if you’re interested in

using/learning RSpec for a particular Rails
project, consider using

svn:externals to check out RSpec trunk into your
[RailsRoot]/vendor

directory:



svn propset svn:externals “rspec
svn://rubyforge.org/var/svn/rspec/trunk”

vendor



then update to grab the latest code from RSpec
trunk:



svn update
vendor



Next, build the gem.  You have to be
standing in vendor/rspec if you’re

using svn:externals (as described above) or the
root of RSpec if you checked

it out as its own
project.



rake gem



then install
it:



gem install pkg/rspec-X.X.X.gem (where X.X.X is
the version number reported

in the output from “rake gem”)



—- from
http://rubyforge.org/pipermail/rspec-users/2006-November/000135.html



That’s it, now I can run my specs directly from Textmate the same way I was
doing with Unit Test.



( on a different post I’ll explain why I couldn’t simply run rake:spec )