Thanks to cassiomarques, we can run rspec from within vim and see the results in FF.

You might be surprised though, when you run it and wait and wait, and nothing seems happening. Mostly likely it just that the running code raise an exception and no output to either FF or you vim. If you look at the terminal window where you started you vim, you will see the backtrace though. So why not display the backtrace in FF then, just like the image below?

A failure message window

Here is the part of the script modified from his original one:

begin
  ::Spec::Runner::CommandLine.run(::Spec::Runner::OptionParser.parse(argv, STDERR, STDOUT))
rescue Exception => e
  File.open("#{report_file}", "w") do |file|
    file.write("#{e.message} <br />")
    file.write e.backtrace.join("<br />")
  end
end

Another thing worth to mention is that handling vim type of links doesn’t work with his approach in either FF3 and FF2. I had to install a plugin called Mozex. My experience is that it only works for FF2. Once you install it and restart your FF2, go to Add-Ons and click on “Preference” of this plugin. goto “Universal” tab. type “vim” into the first textbox and /path/to/open_vim to the second one just like the image shown below:

Mozex plugin setup

Speaking of open_vim, since Mozex pass the whole URL (vim://Users/blah/blah.rb?line_number) back, so the regex for parsing it should be changed to:

 /vim:\/\/(.+)\?(\d+)/

In a typical Rails app, we have a lot of “index” action in almost every controllers. And in most cases, an index is a list of same type of objects. There are a lot of similar features we need to present these lists. So it makes sense to have a concept as ListPresenter and each individual presenter who presents a list should extend from it.

Of course, in Ruby, we don’t have to actually have a class called ListPresenter and do all the stuff that are not necessarily related to each other. We can have as many modules as we need. Each module does one particular task. and all presenters for list can mixin those modules.

Why it is good to do things this way? Let’s take an example: If all lists are HTML tables, and all tables have table headers with title of columns. Now we decide to use title case (such as ‘Column Name’) for these headers, we could manually type in these texts into your HTML template. The approach is straightforward, but bearing three potential problems.

1. Since developers generally do not know how to type, one could easily have typos
2. Two developers may develop two lists and one may think, wrongly, that title should be humanized (such as “Column name”). Then we end up with inconsistent UI. This inconsistency could also happen when a developer produced lists before the team decided title case. So he used humanized words back then. He had to come back fix them one by one, even with the best IDE ever – Windows notepad’s help, it still a tedious and boring task.
3. Later on, the business doesn’t like title case, they want humanized case. Well, 4 boring hours, again!

In this case, a simple method can help, all it takes is a module which provides a html_table_columns method, as the following:

module HtmlTableColumns
  def html_table_columns(*args)
    self.send :define_method, :columns do
      returning([]) do |columns_hash|
        args.each do |arg|
          case arg
            when String, Symbol
              columns_hash << arg.to_s.titlecase})
            when Hash
              columns_hash << HashWithIndifferentAccess.new(arg)
            else
              raise ArgumentError.new("The params must be Hash, String or Symbols")
          end
        end
      end
    end
  end
end

This method defines a columns for class who calls this method. A call like:

  table_columns('name', "last_connected"
  {'user_login' => "User"}, 'status')

will generate a method like this (in RSpec):

      presenter.columns.should ==
      [{'name' => 'Name'},
       {"last_connected"=>"Last Connected"},
        {'user_login' => "User"}, {'status' => "Status"}]

As long as every developer uses this method, there will be no typo, no inconsistency. And if people ever want to change from title case to humanized words, there is only one place that needs to be changed and I believe readers know where.

This is just an example how group similar features into one place is nice. In general I believe if I can find a feature that is across more than one places, it’s worth my effort to group them into one place, use whatever pattern that is applicable. So after all, I guess this post is not about List Presenter, it is about a case study of DRY.

Although still a work in progress, RSpec story runner is gaining popularity rapidly. I use it because I use Webrat for acceptance tests and Webrat integrates with the story runner seamlessly.

Then next thing I need is to create a task to integrate stories into CC.rb build process. And here it is:

desc "Run all stories"
task :all_stories do
    if out = ENV['CC_BUILD_ARTIFACTS']
        spec_out = "#{out}/Stories"
        mkdir_p spec_out unless File.directory? spec_out
        report_file_name = "#{spec_out}/index.html"
    else
        report_file_name = 'stories.html'
    end
    if ! spec_out.blank?
        sh "cp -r #{RAILS_ROOT}/vendor/plugins/rspec/story_server/prototype/javascripts/ #{spec_out}"
        sh "cp -r #{RAILS_ROOT}/vendor/plugins/rspec/story_server/prototype/stylesheets/ #{spec_out}"
    end
    sh "ruby #{RAILS_ROOT}/stories/all.rb -f html > #{report_file_name}"
end

Yes, ruby a_story.rb -f html will generate an html report instead of a plain text. That’s neat. But I also need to copy javascripts and stylesheets directories to #{spec_out} directory because the generated html report uses css and js files in these two directories.

Once you run this task as part of cruise task, you should see a Stories link under Custom Build Artifacts section. And once you click on it, you should see a page much like #{RAILS_ROOT}/vendor/plugins/rspec/story_server/prototype/stories.html.

The HTML report looks nice. But imagining when we have 100 stories all cozily live in this same single HTML file. It will take forever to load the page and it will be very difficult to find any useful information within it. My proposal is we actually generate a real index which contains just story names, and a color to indicate if they failed or not. Of course each story name is clickable which leads to another page for the detailed story report.

Default MVC layers handles one model, one form mode pretty well, but in reality, a lot of forms are not that simple. There are two classic examples:

1. Multiple models are created/updated in one form
2. One model is created/updated in one form, but in several different ways

When these scenarios happen, MVC framework becomes awkward. We have to either leak business logic into controllers, even views, or put view logic into models, or both. In this post, I want to talk about how to use Presenter Pattern to avoid putting view logic into the models.

Basically Presenter is one layer sitting between Controller and View layer, which should include all of your view logic. The first advantage we gain is that we can unit test view logic easily. Secondly, we can move all helper methods into presenters so that we can have a more elegant way to implement these methods. The third and the most important advantage we gain is that now the model is free from view logic, make its intention much more clear.

Now let’s see an example.

I have a model House, on creation form of House, there are some fields about this house. Some of them are required, some of them are optional. The form has two submit buttons, if a user click on button 1, she will become the owner of this house; if she clicks on button 2, she assigns another person to the owner of this house. When she assigns another person, she needs to pick a person before assigning, for the sake of simplicity, let’s assume she can pick a person from a drop-down list with all eligible person names.

Now if she clicks on button 1, she doesn’t need to choose any person from the drop-down list. But if she clicks on the button 2, she must select a person from that list, and if she doesn’t choose a person, she should get an error message to prompt her to do so. So we see a validation here, but this validation is totally view-specific, nothing to do with either House or Person models. In this situation, a presenter is a natural place to put this logic.

To implement this validation, one tool you absolutely need is the Validatable gem. Once a class includes a Validatable module, it has a lot of ActiveRecord-like validation logic such as validates_presence_of.

I will name my presenter after the form, in this case, NewHousePresenter, but if I know I will reuse this form in edit/update, I will simply name the presenter as HousePresenter.

Inside the presenter, I can have:

	validates_presence_of  wner_id, :if => lambda {|presenter|presenter.assign_owner?}

How to implement assign_owner? is just a matter of implementation of your view, I like to just set a hidden field with value “assign_owner” when clicking on the button 2 and “take_owner” when clicking on the button 1. Then the assign_owner? is just checking if the hidden field is string of “assign_owner”.

Isn’t it cool?

In my previous post More on form_for(@non_arb), I showed a trick to get polymorphic routes working so that the form can be

<% form(@presenter) %>


In my HousePresenter, I can just say:

	polymorphic_routes_for :house, :create_path => "house_owner_path", :update_path => "house_owner_path"

Not only is it for the sake of coolness, but also for the simplicity of the view and easiness to use the form in both create and update actions.

In my Presenter class, I also have an initialize declared as:

def initialize(params={})
  params.each_pair do |key, value|
    instance_variable_set("@#{key}", value)
  end
end

All this does is just blindly set instance variables for all params passed in. The reason for doing this is that I can easily setup a presenter for unit testing. The subclass of Presenter should implement a build class method to take params from the controller, and parse it into a hash that is sensible to the presenter and initialize. So the “constructor” remains simple for convenient construction while build can do complex logic that can be unit tested.

A build method can look like:

def self.build(house_params = {}, operation = "take_owner")

	presenter_params = {:house => House.new(house_params),  peration => operation}
	HousePresenter.new presenter_params
end

After all this, my HousesController#new and create can be as simple as:

def new
	@house_presenter = HousePresenter.build
end

def create
	@house_presenter = HousePresenter.build(params[:house], params[:operation])
	if @house_presenter.valid? && @house_presenter.house.save
		redirect_to(@house_presenter.house)
	else
		render :new
	end
end

Don’t they look like controller actions again? You can infer the edit/update code from here fairly easy.

But for the perfectionist, this line:

if @house_presenter.valid? && @house_presenter.house.save

is a little bit smelly. Bigger thing is: if the creation/update require more then just a save, then we need something else. I almost want to be able to say:

if @house_presenter.save!
...


and in save! I do whatever I need. I actually did that and Marcel Molina looked ultimately confused and I agree with him: Presenters are not meant for business transactions. hmm. well, it’s a long enough post, I would like to talk about this issue in my next post, if it eventually comes out.

Textmate seems the “official” IDE for rails projects. But we have to develop under Windows, so no Textmate.

We used eclipse with radrails (Aptana) for a while, believe me, it’s not fun. Then we start to try IntelliJ now.

Ctrl+Shift+Alt+Space in IntelliJ gives you “word completion”, just like “Esc” in Textmate. And Ctrl+Space works for local variables nicely. And it even works for instance variables, but it needs long time to think. Ctrl+Space works partially in Eclipse, but not in a RSpec file where no explicit class declarations.

Global search on Textmate is a pain, especially if you forget to delete huge development.log and test.log. So I just grep extensively when on Macs. In IntelliJ, you can specify which directory to search with, this helps a lot. Even better, when you have to search the whole project, it will ask you if you want to skip development.log/test.log, very intelligent.

The amazing thing is that renaming classes name and methods name work perfectly in IntelliJ. This feature alone will save me countless time and energy.

Subversion support in Texmate is not so nice, I would just use terminal for subversion operations. In both Eclipse and IntelliJ, the supports are just awesome.

When you have conflicting files, the diff support in Textmate is primitive. And there is no good files/directories comparison tool under MacOS. Meld diff viewer is awesome, but it may take some effort to install it on Macs.

The biggest problem with IntelliJ is that it’s not very responsive, compared to Textmate. But it’s definitely faster than Eclipse.

We use Watir as our scenario test tool, so moving away from Windows doesn’t seem quite possible. This being said, it seems IntelliJ is our best bet.

Stephen Chu talked about how to beautify statements like
customers.collect { |customer| customer.name } in one of his posts. Dr. Nic also has a post talking about the same thing. It’s very interesting to see so many people want to get away the cumbersome collect syntax and I am one of these people.

To beautify the collect syntax when we need just one field such as customer.name. There are several ways:
to use Stephen’s syntax:
customers.collect_name

Dr. Nic’s:
customers.names

And guess what, if you are using Rails, it comes with a Symbol extension method called to_proc. What the method does is to turn a symbol into a simple Proc object. so we can say:

customers.collect &:name which does the job.

In practice, I always just use this built-in to_proc because it’s free as long as you are on a Rails project. And there is no reason for me to justify I should spend time to make it even more magical.

Stephen also came up with syntax like:
customers.collect_name_and_id

The method always returns an array of arrays ([['Yi', 1], ['Du', 2]]). The syntax looks very nice, but I think it has limited value because I may not want an array of arrays, I may want an array of hashes ([{1 => 'Yi'}, {2 => 'Du']), or an array of strings, then the method has no use or we have to do more magic. Most importantly, when we want multiple fields from a model object to form some kind of data structure, we probably should ask ourselves first: what’s the business meaning for this action? If we can find one, we can just add one method, returning whatever we want, to the model class we are dealing with and use that method for collect.

For example, if I want to send an email to several people and their email address should look like:
people.collect{|person| "person.name <person.email>"}, then I probably will just add a method to the Person class, such as Person#full_email_address and return the string I need. the the syntax for collect can be simplified to people.collect &:full_email_address.

It’s cool to see how powerful method_missing can be with Stephen’s extension, and how lovely Ruby is.

Jay Fields writes an excellent module called Validatable to provide a class who include the module the ActiveRecord like behavior. For example, you can say validates_presence_of :attribute etc. This page has the RDoc of the module.When I write RSpec for a Validatable class, I ended up writing a stattement like this:

  @email.validate_only("presence_of/body")
  @email.errors.on(:body).should_not be_nil

Which is basically testing body is a required field. It works, but it looks complicated and hard to understand.The RSpec on Rails plugin provides a method error_on so that I can say something like this:

 model.should have(2).errors_on(:attribute)

This is much more readable than the previous one.I came up with a small extension on Validatable so that I can have a better syntax for testing Validatable.Here’s the spec:

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

module RspecValidatableSpec
  class Thing
    include Validatable
    attr_accessor :age
    attr_accessor :name
    validates_presence_of :age
    validates_numericality_of :age
  end
end

describe RSpecValidatable, 'a validatable object' do
  before :each do
    @thing = RspecValidatableSpec::Thing.new
  end

  it "should tell you it has at least one error on a field" do
    @thing.should have_at_least(1).error_on(:age)
  end

  it "should tell you it has one error on a required field" do
    @thing.should have(1).error_on_presence_of(:age)
  end

  it "should tell you it has one error on a numerical field" do
    @thing.should have(1).error_on_numericality_of(:age)
  end
end

describe RSpecValidatable, 'a validatable object' do
  before :each do
    @thing = RspecValidatableSpec::Thing.new
  end

  it "should tell you it has no error on a field" do
    @thing.should have(:no).errors_on(:name)
  end
end

You may need a different path to your spec_helper.rb to make it work.I got the “traditional” errors_on just like how RSpec works on ActiveRecords. What’s more, Validatable has a validates_only method which allows us validating only one type of error on one attribute. so I can have even better control than RSpec on Rails giving me over ActiveRecords. For example, I can specify what type of errors I expect to have.The only problem is that validates_only raises an error if you check an attribute on a validation that is not specified. So a nice spec like email.should have(:no).errors_on_presence_of(:attachment)is not quite possible. For those of you who are interested in this, here is the actually code:

module RSpecValidatable
  def errors_on(attribute)
    self.valid?
    [self.errors.on(attribute)].flatten.compact
  end

  def respond_to? method_name
    super(method_name) || method_name.to_s.index('error_on') == 0
  end

  def method_missing(error_on_method, attribute)
    reason = error_on_method.to_s.sub(/error_on_/, '')
    self.validate_only("#{reason.to_s}/#{attribute.to_s}")
    [self.errors.on(attribute)].flatten.compact
  end

  alias :error_on :errors_on

end

Validatable.send :include, RSpecValidatable

Dan Manges has an excellent post explaining Law of Demeter and when it makes sense to use Forwardable to comply the principle, or I should say when it doesn’t make sense to use the module.

The point is, use it when it makes sense. Take his example, customer_name is just not a sensible method for an order. Asking an order for its customer name is a wrong question because all the order should care is who is its customer. The name is irrelevant to the order.

In fact, I think by putting cusomer_name method in an order. the encapsulation is actually broken because now an order knows the inside details of a customer, thus tightly coupled these two classes.

I need a captcha in a form, whose associated model is a Validatable. After googling, I decided to go with Simple Captcha. The Simple captcha is extremely easy to use, see its documentation, you’ll know. But it works fine with a ActiveRecord::Base, not a Validatable. There has to be some hack to make it work. I could use “Controller mode” of it. But it will be nice to put it into model, make it part of validation process. and here’s my code:

First, include SimpleCaptcha into your Validatable model:

YourValidatable.module_eval do
    class << self; include SimpleCaptcha::ModelHelpers; end
end

And overwrite apply_simple_captcha

  def self.apply_simple_captcha(options = {})
    module_eval do
      require 'pstore'
      include SimpleCaptcha::ConfigTasks
      attr_accessor :captcha, :captcha_code,
      :authenticate_with_captcha
      alias_method :valid_without_captcha?, :valid?
    end
    @captcha_invalid_message =
 (options[:message].nil? || options[:message].empty?) ?
  " image did not match with text" : options[:message]
    module_eval(turing_valid_method)
    module_eval(turing_save_method)
  end

Finally, call apply_simple_captcha

That’s it.

In the controller, instead of calling valid? to decide if the object is valid, you call valid_with_captcha?

BTW: Follow this link to see how to install RMagick on Ubuntu

Sometimes it’s comforting to know your method is called within a transaction.

if Thread.current['open_transactions'].nil? ||    Thread.current['open_transactions'] == 0

will do. Any better idea?