Isn’t it exactly like typing “bundle exec” ?

Yes, you’re right… it’s more or less the same thing. But I find that having to type “./bin/” is even more obvious. Believe me, you will get the hang of it quickly. Anyway, with TAB completion, it’s not like you have to type “./bin” really. It will look more like “./b” then TAB. It becomes second nature really fast.

Wow! This is the discovery of the century! I’m sold, how can I do this ? (end sarcasm)

Whenever you update your Gemfile, you do

bundle –binstubs

Did you know that as of Rails 3.1, you can have nested has_many :through clauses in your models? Here is a concrete example to understand what I mean:

  class SportSchedule < ActiveRecord::Base
    has_many :gamedays
    has_many :games, :through => :gamedays
    has_many :results, :through => :games # <= You could not do this before Rails 3.1

   ...
   def has_results?
     !self.results.empty?
   end
  end

number_with_precision(
  3.50,
  strip_insignificant_zeros: true,
  precision: 2
)
# => "3.5"

module TheModule
  attr_reader :items
  def initialize(*args)
    @items = []

    def @items.<<(item)
      super
      "You added the item #{item} with <<!"
    end

    def @items.push(item)
      super
      "You added the item #{item} with push!"
    end
    super
  end
end

class TheClass
  include TheModule
end

And now the output:

x = TheClass.new
x.items   # => []
x.items << 'blue' # => You added the item 'blue' with <<!
x.items.push 'orange' # => You added the item 'orange' with push!
x.items # => ["blue", "orange"]

I am proud of this introduction. I will take a sip of coffee and read it again, hold on. Yes this intro was good, I think I should write about magical little beings more often.

If you are like me, you never paid much attention to capistrano and the way it works. At the exception of the famous “cap deploy” command, you never really wanted to get involved in the process. For this reason you have copied and pasted the same old deployment recipe in all of your projects over the years, only changing some parameters like the application name and the emplacement of the git repository.

The fact that capistrano is doing magical things doesn’t really help in this regard. My goal in this post is to explain some of the not so obvious parts of capistrano. With minimal efforts we can have a better idea of what capistrano does and feel more in control when deploying an application.

Capistrano is magic

Like many things in the ruby world, there is a fair bit of magic involved in capistrano. For example, when you type “cap deploy”, there is a bunch of things that happen, but what things exactly? What tasks are being called? This is not obvious. First of all, “deploy” is not a task written in your own recipe file, it is a namespace located in the capistrano gem. Take a look:

namespace :deploy do
  desc <<-DESC
    Deploys your project. This calls both `update' and `restart'. Note that \
    this will generally only work for applications that have already been deployed \
    once. For a "cold" deploy, you'll want to take a look at the `deploy:cold' \
    task, which handles the cold start specifically.
  DESC
  task :default do
    update
    restart
  end
#...

As you can see, the :default task is invoked when you type “cap deploy”, which in turns will call “update” and “restart”.

This is why you never got to see a call to the :restart task in your own recipe file. I know that during all these years there was a secret part of your brain that was¸wondering about this stuff, while the not-so-secret part really didn’t care.

Capistrano and Bundler

  require 'bundler/capistrano'

This line adds some bundler magical stuff to your recipe. It will install your bundle (with the –deployment flag) when deploying, meaning that all your gems will be vendored to yourapp/shared/bundle.

Capistrano and the Asset Pipeline

load "deploy/assets"

This line adds some magical stuff for compatibility with the Rails 3.1+ asset pipeline. More precisely, it will precompile your assets. This is an almost essential part when you use the asset pipeline in production. The other solution is to precompile locally and push the assets to your repository, not a good idea in my opinion. The sad part is that precompiling assets can slow down your deployment quite severly. If you use GIT, you might like this smart solution from Ben Curtis to skip assets precompilation.

Capistrano and RVM

$:.unshift(File.expand_path('./lib', ENV['rvm_path']))
require "rvm/capistrano"
set :rvm_ruby_string, 'ruby-1.9.2-head@rails3.2'
set :rvm_type, :user

This tells capistrano to switch to a specific ruby version + gemset when connected to the server. The gemset (i.e. @rails3.2) is the tricky part because it makes you think that, when capistrano will invoke bundle install, your gems will be installed in .rvm/gems/ruby-1.9.2-head@rails3.2/gems. This is not the case. Remember that we have just told bundler to install the gems in yourapp/shared/bundle/.

So why do we bother with the gemset anyway?

One reason is that the bundler gem itself will be invoked by capistrano on your server in the gemset specified in the rvm_ruby_string variable. It can be useful to specify a gemset if you want to use a specific version of bundler.

I must say that my first experience with a significant whitespace language was a disaster. The first time I had to use Python was on a server via ssh. I was in a hurry and wanted to monkey patch some buggy script I had installed. So without thinking too much I opened the script with a text editor called nano. The problem is that a TAB in nano produces between 173 and 177 white spaces. Realizing this I decided to refrain from indenting one line or two because it was too ugly and unreadable. Then python told me that I could not do this… and at the time I remember thinking it was unacceptable that a script start to malfunction just because of a few missing whitespaces. Anyway, I spent some long minutes trying to fix a few indentation issues (in nano! I still didn’t realize it was the source of the problem) and it was very tedious. Had I try debugging the python script on my local computer with gedit for example, things would surely have turned out differently.

Then Haml came… and I stayed away

This unpleasant experience I had with Python had a rather negative side effect: It made me completely ignore Haml for a long time, which is sad because it is such a great alternative to erb.

But now I use Haml, and I really like it. Not having to “close my tags” is more satisfying than I thought it would be. I always delight when I realize I was about to write a “- end” tag to close a “- @items.each” loop or something like that. I don’t have to! Less typing, less noise, cleaner, prettier, I love this! Wouldn’t be nice if we could do away with the “end” keyword in ruby as well?

Just to give us an idea, here is how an actual class from the Haml gem would look like if it was written in Significant Whitespace ruby:

    class ParseNode < Struct.new(:type, :line, :value, :parent, :children)
      def initialize(*args)
        super
        self.children ||= []

      def inspect
        text = "(#{type} #{value.inspect}"
        children.each {|c| text << "\n" << c.inspect.gsub(/^/, "  ")}
        text + ")"

Great, it sill looks like ruby. We just removed some noise to make it even more readable.

Let’s convert a longer method, still from the Haml gem, to see how it would look like:

    def parse_new_attributes(line)
      line = line.dup
      scanner = StringScanner.new(line)
      last_line = @index
      attributes = {}

      scanner.scan(/\(\s*/)
      loop do
        name, value = parse_new_attribute(scanner)
        break if name.nil?

        if name == false
          text = (Haml::Shared.balance(line, ?(, ?)) || [line]).first
          raise Haml::SyntaxError.new("Invalid attribute list: #{text.inspect}.", last_line - 1)

        attributes[name] = value
        scanner.scan(/\s*/)

        if scanner.eos?
          line << " " << @next_line.text
          last_line += 1
          next_line
          scanner.scan(/\s*/)

      static_attributes = {}
      dynamic_attributes = "{"
      attributes.each do |name, (type, val)|
        if type == :static
          static_attributes[name] = val
        else
          dynamic_attributes << inspect_obj(name) << " => " << val << ","

      dynamic_attributes << "}"
      dynamic_attributes = nil if dynamic_attributes == "{}"

      return [static_attributes, dynamic_attributes], scanner.rest, last_line

Well, not bad at all… the only problem is that the loop is quite long and I had to double-check to know if the “static_attributes” statement was part of the loop or right after. This kind of double checking could get on my nerves fast.

I’m still undecided. I dislike end tags but they can clear things up sometimes. Anyway, I guess we probably never see this implemented in ruby. What’s your thoughts on significant whitespace languages?

Now does this mean I don’t write tests just because I think they aren’t fun? Of course not. I do write tests… I just don’t blog about them because they don’t excite me very much. I’m currently on a quest to find a way to enjoy testing more. This is a work in progress for me and so far I have managed to draw at least this conclusion: To enjoy testing a bit more, one need a killer setup and great testing tools to work with.

Continuous testing

Running “rake test” once in a while is a very simple setup. The biggest problem with this approach is that it disconnect you from your “flow”. You have to remember about running this command and if you forget (I know I do) no one will know about it.

So a part of the solution to improve my testing setup was to have my tests run continuously. The most popular library that help with this is probably autotest. It fixes once and for all the problem of forgetting to run my tests.

So we have autotest running our tests in the background. That’s great… but it could be better. the output that Test:Unit or RSpec spits is verbose, hard to read and hidden somewhere on a terminal window. I wanted the testing phase to be integrated as much as possible into my other programming tasks, so I decided to install autotest-notifications, a nice autotest plugin that knows how to talk to libnotify (linux), growl (mac) or snarl (windows) and it tells you if you have failing tests. This is the kind of OS integration I like! I am a Linux guy so I had to install libnotify-bin in my ubuntu box before I could use the plugin. Mac users will have to make sure growl and growlnotify is installed on their machines. As for windows users, they will have to install snarl. Here is a screenshot showing how it looks in Linux :

To start autotest-notifications, type an-install. To stop, type an-uninstall.

Other testing tools

Now that my tests run continously, I can concentrate on finding other testing tools that will help me write tests more easily and more rapidly.

Test::Unit / RSpec

I always used Test::Unit. I tried RSpec for the first time very recently and was quite pleased with it. I don’t see that much difference between the two except in the syntax. The only thing I can say is that when I use Test::Unit, I absolutely want to use Shoulda as well. When I use RSpec, shoulda is less essential but I still use it.

Shoulda

I’d say that shoulda is Test::Unit best friend. It gives you a nice set of useful test macros and some great semantic constructs that will improve the readability of your tests.

Capybara (I give to this one the gold medal)

Question: What’s missing if I only use Test::Unit or RSpec ?
Answer: A good integration testing framework

Capybara is a great tool for higher level testing. It’s the kind of testing a non-programmer can understand: when I click this link then I should see this and when I fill this form then it should take me there and so on.

Capybara is a magician that will actually click on your links, fill out your forms and even triggers your javascript. He’s like a end-user testing your app in a hidden browser. Seriously I think these tests are great to have and capybara does a wonderful job to help you write them.

Cucumber

To be frank, I find this one more difficult to love. If there’s one tool I plan to stop using in the near future, it’s probably cucumber. But to each its own!

For those who don’t know, Cucumber is a DSL that encourages Behaviour Driven Development. It lets you describe features before you start implementing them. The “twist” is that you describe these features in plain english, or I should rather say, in plain Gherkin. You then take each “plain Gherkin” instruction and you translate them into ruby code in another file called a “steps definition file”. For example:

Gherkin:

Given a user called Bob
When he stumbles and fall flat on his face
Then he should lose only 1 tooth

Step definition file:

Given /^a user called (.*)$^ do |user_name|
  @user = User.create(:name => user_name)
end

When /^he stumbles and fall flat on his face$/ do
  @user.stumble_and_fall!
end

Then /^he should lose only (\d+) (tooth|teeth)$/ do |count|
  @user.teeth_lost.should == count
end

My problem with Cucumber

I am the co-founder of a startup composed of 2 developers. We obviously don’t need something like the business friendly Gherkin language. For us this language is harder to understand than ruby code can be. Of course, when it’s some dead easy stuff like the example above, it looks cool, but when you start adding fixtures/factories into the mix and that you have several words in the expression that will be replaced in a regex later, then you begin to write features filled with black magic and you won’t want to touch them ever again because you know that a single tiny change will break them. For each Gherkin line I’m writing, I can’t refrain myself from thinking about the step definition that I will have to create for it. That is the main problem I have with Cucumber. As a developer I cannot write Gherkin like it was only plain english. So I often write what we could call technical gherkin easy to translate in a regex-friendly step definition… and sometimes this kind of technical language is a lot harder to appreciate than ruby. Even worse, writing this kind of developer-friendly Gherkin destroys the purpose of this language.

Factory Girl

This one gem will save you a lot of time… once you know how to use it!

What is Factory Girl? It’s simply a way to replace the somewhat cumbersome fixtures in Rails. You can see it this way: Instead of having a bunch of “static” data that will be loaded in your database everytime, with FactoryGirl you build ActiveRecord objects on the fly depending on your testing needs. Basically, you have to define one factory per model. In each factory, you define default values for every attributes you want (generally those that cannot be nil). These values will always be used unless you specify something different in your tests.

Factory.define(:league) do |l|
  l.name "The happy league"
end

Factory.define(:season) do |s|
  s.starts_on Date.parse("2010/11/30")
  s.ends_on Date.parse("2011/02/18")
  s.association :league
end

Factory.define(:gameday) do |gd|
  gd.season {Season.first || Factory(:season)}
end

Factory.define(:team) do |t|
  #sequences are a good way to generate unique values
  t.sequence(:name) do |n|
    "The big fat tigers - #{n}"
  end
  t.season {Season.first || Factory(:season)}
end

Factory.define(:game) do |g|
  g.game_time DateTime.parse("7:00 PM")
  g.association :gameday
  g.association :team_a, :factory => :team
  g.association :team_b, :factory => :team
end

If I want to test something with a Game instance and I don’t really care about the other associated models, then I can simply write Factory(:game) and FactoryGirl will take care of creating all the associations for me. I don’t have to create a gameday then associate it to my game… then create a season and associate it to my gameday… then create a league and associate it to my season. I can just type Factory(:game) and I will have a perfectly valid Game instance with all its associations.

I want to bring your attention on line #12 and #20. The way I define my association for the season factory is different. There is probably a better way to do this but I didn’t find any. Basically, instead of going the traditional route and do this:

gd.association :season

I use a block to specify a condition. I do this because of the Game factory defined at line #23. You can see that I have a relation to the Gameday factory and two relations to the Team factory. Both these factories are associated with the Season factory. If I had made a standard association call (i.e. gd.association :season and t.association :season), three different seasons would have been created at line #25, #26 and #27. This is not what I wanted… I wanted the same season to be used.

FactoryGirl is a great fixture replacement, but as you see it got its quirks and it’s not the easiest tool to use.

Conclusion

So, am I a happy tester now? not yet, I’m afraid… but I’m getting there I guess. Feel free to leave me a comment and tell me which tools you use and how you integrate testing in your programming routine.

I chose to use MongoMapper, a ruby object mapper for Mongo. MongoMapper uses ActiveModel and let you interact with a MongoDB database in a very ActiveRecord way.

Hope this sample app will help you getting started with MongoDB!

This will now change with the new gem I am working on called RRSchedule (code is also on github).

I realized that most sport leagues were using a round-robin format for their seasons and this is how I had the idea to make a gem out of it.

The gem takes into consideration the number of available “playing surfaces” and multiple game times. Say for example that you want to generate a round-robin schedule for your 19-teams volleyball league where games are played every wednesday. If there are 3 volleyball fields available and that games are played at 7:00 PM and 9:00 PM. This means that 6 games can be played every gameday (3 volleyball fields * 2 game times).

Example:
Gameday #1
========
A vs B on Volleyball field “A” will play at 7:00 PM
C vs D on Volleyball field “B” will play at 7:00 PM
E vs F on Volleyball field “C” will play at 7:00 PM
G vs H on Volleyball field “A” will play at 9:00 PM
I vs J on Volleyball field “B” will play at 9:00 PM
K vs L on Volleyball field “C” will play at 9:00 PM

Since the round-robin round can not be completed on a single day, the remaining games in the round will be put on the next gameday and a new round will start right after.

I hope this gem will be useful to some people!

Say I have a horse racing ruby application that allow people to know information about every competing horses. I have an input box that people can use to enter the name of a horse. Once they click OK, information about the specified horse is displayed to the user.

Instead of going the traditonal route, how about adding a “horse” method to the String class? It could not be easier :

HORSES = [
  {
    :name => "Jolly Jumper",
    :also_known_as => ["Smart Arse","Lucky Luke friend"],
    :speed => 3, :intelligence => 30,
    :favorite_quote => "I am a horse, I don't have quotes"
  },

  {
    :name => "Incredibly Bad",
    :also_known_as => ["Shame","The Pathetic"],
    :speed => 2, :intelligence => 4,
    :favorite_quote => "If you still put your money on me, you only have yourself to blame"
  },

  {
    :name => "Fast And Furious",
    :also_known_as => ["The Strong Rebel","The Furious One"],
    :speed => 50, :intelligence => 15,
    :favorite_quote => "I am fast"
  },

 {
    :name => "Slow and Jerky",
    :also_known_as => ["Tender","Terrible Choice"],
    :speed => 1, :intelligence => 10,
    :favorite_quote => "Pick me once, regret it for a lifetime."
  }
]

class String
  def horse
    res = HORSES.select { |h| h[:name] == self || h[:also_known_as].include?(self)}
    res.first if res.length>0
  end
end

#Then you can do stuff like this :
horse = "Tender".horse
if horse
	puts "#{horse[:name]}, also known as #{horse[:also_known_as].join(", ")}, has a speed of #{horse[:speed]} and an intelligence of #{horse[:intelligence]}. In its free time, this horse like to become all philosophic, look at the sky and say : '#{horse[:favorite_quote]}'"
else
	puts "This horse doesn't exists in our records"
end

Talk about some great syntactic ruby sugar!