When in a chat, messages are sent either using the send button or by pressing the enter key. Testing the correct behaviour on button press is straight forward. I’m using Jasmine and jsMocha for testing and jQuery for implementation.

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

beforeEach(function() {
  // code that disables the sending of messages here

  // setup UI.runner for mocking
  var mock = new Mock(UI.runner);

  // add an expectation that raise is never called
  UI.runner.expects('raise').passing('message_send', Match.an_object).never();
});

it("should not allow messages to be sent", function() {
  // add some text to the textarea
  $("#chat-form textarea").val("the text I want to send");

  // simulate the click event
  $("#send-button").click();
});

Our UI code raises events that our main application code listens to in order to send out the messages. Here I setup a mock in the before block saying the raise method should never be called with the ‘message_send’ parameter. Then in the test I insert some text into the text area and simulate a click event on the send button.

It became slightly more tricky when I came to test the enter key functionality, our implementation code looks something like this:

1
2
3
4
5

$("#chat-form textarea").unbind().keyup(function(e){
  if (e.which === 13) {
    // send message code here
  }
});

In order to programatically simulate a press of the enter key I needed to pass an event object containing a which value of 13. After a bit of hunting around I found the jQuery.Event object, that allows the creation of events which can then be fired. The test for disabling the enter key looked like this:

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

beforeEach(function() {
  // code that disables the sending of messages here

  // setup UI.runner for mocking
  var mock = new Mock(UI.runner);

  // add an expectation that raise is never called
  UI.runner.expects('raise').passing('message_send', Match.an_object).never();
});

it("should not allow messages to be sent", function() {
  // add some text to the textarea
  $("#chat-form textarea").val("the text I want to send");

  // create a new keyup event
  var e = jQuery.Event("keyup");

  // set the key that was pressed to the enter key
  e.which = 13;

  // trigger the event on the textarea element
  $("#chat-form textarea").trigger(e);
});

Using this technique it should be possible to programatically simulate any key event in a test environment.

1
2
3
4
5
6
7
8

<div id="snippets" style="display:none">
  <ul id="user-list-snippet">
    <li id="user-0">Shaun White<span class='user-0-status'>busy</span></li>
    <li id="user-1">Jeremy Jones<span class='user-1-status'>online</span></li>
    <li id="user-2">Jake Burton<span class='user-2-status'>offline</span></li>
    <li id="user-3">Tara Dakides<span class='user-3-status'>online</span></li>
  </ul>
</div>

And the JavaScript to copy the element:

1

$("#user-list-snippet").clone().removeAttr("id").attr("id", "user-list").appendTo($('#dom_test'));

Of course when working with id’s in HTML they have to be unique so the technique caused some of the other tests in the suite to fail, I needed to find another way to do this. One thing I hate is using jQuery to create more than a few dom elements as it gets complex very quickly and it’s not easy to see if the code is producing the desired HTML at a glance.

After taking a break I came up with a simple solution, the Scupper library was about to be written. I wanted to write snippets in HTML so I kept the snippet used in the first attempt. I then created a library that collected all of the snippets from the dom, storing them internally, before deleting them from the dom. This allowed the dom to be free from conflicting id’s and general pollution. The HTML snippet became:

1
2
3
4
5
6
7
8
9
10

<div id="snippets" style="display:none">
  <div id="user-list-snippet">
    <ul id="user-list">
      <li id="user-0">Shaun White<span class='user-0-status'>busy</span></li>
      <li id="user-1">Jeremy Jones<span class='user-1-status'>online</span></li>
      <li id="user-2">Jake Burton<span class='user-2-status'>offline</span></li>
      <li id="user-3">Tara Dakides<span class='user-3-status'>online</span></li>
    </ul>
  </div>
</div>

The containing div #user-list-snippet gives an element to latch onto in order to grab the contents inside. I created a method that sucks up all snippets inside a dom element and stores them:

1
2
3
4
5
6
7
8

init: function(element_id){
  var element = $('#' + element_id);
  element.children().each(function(i, elm){
    elm = $(elm);
    Scupper.items[elm.attr('id')] = elm.html();
  });
  element.empty();
}

All that was needed is an easy way to pull them out an insert them into the dom:

1
2
3
4
5
6
7
8
9
10
11

insert_into: function(source_id, destination_id){
  return $('#' + destination_id).append(Scupper.retrieve(source_id));
},

retrieve: function(id){
  if(Scupper.items[id] !== undefined){
    return Scupper.items[id];
  }else{
    throw "Requested Scupper element not found with id: " + id;
  }
}

Calling insert_into() grabs the snippet HTML and inserts it into the specified dom element ready for the test to use it.

If you want to use Scupper the source is freely available on github.

I decided to come up with my own macro that checks the specifics of a form element, enter should_render_a_form_to. This takes three arguments, a description, an options hash and a block that contains the expected url. You can use the macro as follows…

Check there is a form posting to the new_user_post_path:

1

should_render_a_form_to("create a new post", {:method => "post"}) { new_user_post_path(@user.id) }

Check there is a form putting to the user_post_path and that the form has the id of ‘post_edit_form’:

1

should_render_a_form_to("update a post", {:method => "put", :id => "post_edit_form"}) { user_post_path( :user_id => @user.id, :id => 1) }

The macro code is available on github with test coverage. If you just want to cut and paste into your own macro’s file:

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

def should_render_a_form_to(description, options = {}, &block)
  should "render a form to #{description}" do
    expected_url  = instance_eval(&block)
    form_method   = case options[:method]
      when "post", "put", "delete" : "post"
      else "get"
      end
    assert_select "form[action=?][method=?]",
                  expected_url,
                  form_method,
                  true,
                  "The template doesn't contain a <form> element with the action #{expected_url}" do |elms|

      if options[:id]
        elms.each do |elm|
          assert_select elm,
                        "##{options[:id]}",
                        true,
                        "The template doesn't contain a <form> element with the id #{options[:id]}"
        end
      end

      unless %w{get post}.include? options[:method]
        assert_select "input[name=_method][value=?]",
                      options[:method],
                      true,
                      "The template doesn't contain a <form> for #{expected_url} using the method #{options[:method]}"
      end
    end
  end
end

The macro checks both the forms action attribute as well as the hidden input rails uses to specify the method where necessary. I’ve also been playing with creating a macro to check for a form with specific fields such as should_render_a_form_with_fields. This is proving to be slightly more difficult than I originally anticipated and defining a nice interface to the method has been rather tricky.

The original Hoptoad task for use with Capistrano needed a little modification.

1
2
3
4
5
6
7
8

task :notify_hoptoad do
  rails_env = fetch(:rails_env, "production")
  local_user = ENV['USER'] || ENV['USERNAME']
  notify_command = "rake hoptoad:deploy TO=#{rails_env} REVISION=#{current_revision} REPO=#{repository} USER=#{local_user}"
  puts "Notifying Hoptoad of Deploy (#{notify_command})"
  `#{notify_command}`
  puts "Hoptoad Notification Complete."
end

fetch is a Capistrano method so needed to be removed, we can use the Vlad environment pattern for this. I also wanted to use the git information for the user instead of the system user, finally as far as I can tell the git commit SHA being deployed is not available in Vlad.

In the Vlad deployment script I added a Hoptoad task to replace the default Capistrano task provided by Hoptoad.

1
2
3
4
5
6

task :notify_hoptoad => [:git_user, :git_revision] do
  notify_command = "rake hoptoad:deploy TO=#{rails_env} REVISION=#{current_sha} REPO=#{repository} USER='#{current_user}'"
  puts "Notifying Hoptoad of Deploy (#{notify_command})"
  `#{notify_command}`
  puts "Hoptoad Notification Complete."
end

Then added it as a dependency for the deploy task

1

task :deploy => [:update, :migrate, :start_app, :notify_hoptoad]

There are a couple of helper tasks I’ve added to get the git user and the SHA of the commit being deployed

1
2
3
4
5
6
7

remote_task :git_revision do
  set :current_sha, run("cd #{File.join(scm_path, 'repo')}; git rev-parse origin/master").strip
end

task :git_user do
  set :current_user, `git config --get user.name`.strip
end

What a weekend! it all started on Friday night, a feverish last minute planning session began on how we would implement “Wuzlr”. We’d bounced around some ideas earlier in the week and had a pretty good idea of what we wanted, whittling that down into a set of features we could implement in 48 hours was no easy task, there was so many good ideas and we didn’t have time to implement them all. At 1am it all began…

The Pitch

If your office is anything like ours things get pretty serious whenever a game of table football breaks out (especially when @theozaurus is playing). We’ve wanted a way to track who’s the best in the office for quite some time, finally we have just the thing, and so do you. Wuzlr is a table football league tracking application that lets you see performance over time with all sorts of fun and interesting facts and figures displayed.

Wuzlr (or wuzler if you use the correct non web 2.0 spelling) is the Austrian word for table football and just so happened to be the first domain we came across that’s still available. We also liked the hat tip to the ‘e’ dropping crowd, no, not you party people, I’m talking about flickr and the like.

Application Features

• Create leagues and record all your games, Check out the Jiva office league
• Compare yourself to other players, Me Vs. Theo
  
• View your nemesis, best team mate, worst team mate and more, my player page
• League standings, games played per day, table bias, most dedicated players (who’s put the most time in)
  

Our Team

• Jamie Dyer @kernowsoul Developer for Jiva
• Theo Coushion @theozaurus Developer for Jiva
• Peter Coles @fatelvis Designer for Existem

Yes we know the site looks terrible in IE, who uses IE anyway?

No more will autotest stress out my mac, autotest-fsevent is a great gem that uses OS X’s FSEvent system to be notified when files have changed rather than having to constantly poll the filesystem. You need mac OS X 10.5 or later to take advantage of FSEvent.

The other nice thing autotest-fsevent does is take care of all the .autotest config options, I managed to delete my entire config file which I’ve been tweaking for as long as I can remember trying to get the perfect setup.

I can now run even the most demanding of test suites and my computer barely breaks a sweat. Thanks bitcetera, my computer ♥’s you.

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

public_context do

  context "on GET to :index" do
    setup do
      get :index
    end

    should_redirect_to("root url") { root_url }
  end
end

signed_in_user_context do

  context "on GET to :index" do
    setup do
      get :index
    end

    should_redirect_to("user url") { user_url }
  end
end

This is pretty standard practice now and something I picked up from looking at the code produced by the guys at Thought Bot. While working on the test suite it became apparent many of the methods behaved in the same way for multiple user roles. I wanted to come up with a way to run a group of tests under multiple user roles without having to duplicate any code. Shoulda macros to the rescue again! After creating another macro to deal with multiple contexts I can write my tests like this…

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

multiple_contexts 'public_context', 'signed_in_user_context' do

  context "on GET to :show" do
    setup do
      @advert = Factory(:advert)
      get :show, :id => @advert.to_param
    end

    should_render_with_layout :application
    should_render_template :show
    should_not_set_the_flash
    should_assign_to( :advert ) { @advert }
    should_respond_with :success
  end
end

And the shoulda macro code itself…

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

def multiple_contexts(*contexts, &blk)
  contexts.each { |context|
    send(context, &blk) if respond_to?(context)
  }
end

def public_context(&blk)
  context "The public" do
    setup { sign_out }
    merge_block(&blk)
  end
end

def signed_in_user_context(&blk)
  context "A signed in user" do
    setup do
      @user = Factory(:user)
      sign_in_as @user
    end
    merge_block(&blk)
  end
end

I’ve been developing with JavaScript a lot recently and found JSLint to be a rather useful tool for picking up syntax errors. Being primarily a ruby developer I have a nasty habit of omitting semicolons from the end of lines.

I found an article on running JSLint through a TextMate command but found Ryan’s script didn’t quite work with the output from the version of JSLint I’m using so I thought I’d share my modifications.

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

#!/usr/bin/env ruby
require 'cgi'

lint = `/usr/bin/java -jar ~/Library/JSLint/js.jar ~/Library/JSLint/jslint.js "$TM_FILEPATH"`

lint.gsub!(/(line \d+ character \d+:) ([^\n]+)\n([^\n]+)/m) do
  "<p><strong>#{CGI.escapeHTML($1)}</strong> #{CGI.escapeHTML($2)}</p>" <<
    ($3 ? "<pre>#{CGI.escapeHTML($3)}</pre>" : '')
end

lint.gsub!(/^(jslint:.*at )/, '')

print <<HTML
<!doctype>
<html>
<head>
  <style type="text/css">
    p { margin-bottom: 0; }
    pre {
      background: #f5f5f5;
      border: 1px solid #cfcfcf;
      font-size: 12px;
      margin-top: 2px;
      padding: 2px 4px;
    }
  </style>
</head>
<body>
  #{lint}
</body>
</html>
HTML

A couple of weeks ago I had to replace the old tires on my Fillmore as I’d worn through the green ones that came with the bike. Took a bit of getting used to the orange but it’s definitely growing on me.

This last weekend I managed a puncture the inner tube while pulling the pump off which required a trip to Strada Cycles. I ended up replacing the bars and break callipers so it turned out to be a much more expensive trip than I was expecting. Just shy of £100 got me a new inner tube and I was back on the road again.

I’ve updated the javascript_auto_include plugin to include changes from abradburne and jimp79. Thanks to these guys the plugin now supports nested controllers so you can add javascript to a paths like admin/users and admin/users/show/1 etc.

1

sh: /usr/bin/gcc: Permission denied

The way to get around this is to have a privileged user compile the C application for you, then copy it to your users home folder. The easiest way to do this is to generate and run a Merb app as the root user:

1
2
3

merb-gen app tmp-merb
merb
Ctrl+C

Then copy the RubyInline C application to the users home folder:

1

cp -R /root/.ruby_inline /home/<username>

Make sure the file ownership is set correctly:

1

chown -R <username>:<username> /home/<username>/.ruby_inline

After this you should be able to run Merb as expected. If you’re still getting errors relating to file permissions after following the instructions above you’ll need to combine the fix from Vignet and put the .ruby_inline folder in a place accessible to both the apache user and the user running the Merb app, I’ve not tested this but it should work.

Slightly late to the show I updated to RubyGems 1.3.0 today, the upgrade isn’t as straight forward as usual on OSX 10.5 and requires a little extra work.

wincent.com posted up some instructions on how to upgrade to RubyGems 1.3.0 which are useful for anyone having issues.

UPDATE: It looks like this issue is not specific to OSX, I was updating a couple of Linux servers and had to follow the same procedure.

To my relief a quick google search and a couple of minutes later I was all set-up and had exported my photo exactly how it should be. Thanks Usability Post for your amazingly simple and accurate guide to setting up colour profiles for web design.

I’ve been following Merb with interest ever since I first heard about it. One of the things I found hard to keep up with - just dipping into it now and then - was the speed of development and change. Every time I had a few minutes to play with it everything had changed. Its a bit like having the rug pulled out from under you every time you manage to get to your knees.

The 1.0 release Merb should be far more stable, and with some decent documentation I hope it will start taking off quickly, the barrier to entry will be greatly reduced. Even though I won’t be at MerbCamp I’ll certainly be following it closely.

I wonder if the 1.0 release will be promptly followed by a 1.0.1 release, as is tradition.

I came across a quote I thought I would share…

“Go to a multiplex, sit through the ads, and see how abused you feel by the start of the movie. Then to to a cinema in the UK and motive that most people turn up to view those commercials. Because they are actually fun-sensible and intriguing and full of messages that make people applaud.Yes, shout out with glee! These are entertaining, funny, well-produced, and cool. Four terms you’d never use to describe an ad at movies in the US of A today.”

I couldn’t agree more, those poor Canadians are force fed the majority the USA’s crappy ads. What’s probably worse is that often the product or service isn’t even available to them! I digress, having suffered with the Canadians for the last three years I can say I would gladly watch several hours of English commercials than a single US ad break.

In closing… Well done Britain, we produce some of the best ads in the world.

After floating around without a proper home the javascript_auto_include plugin now has a nice cosy permanent home on Github. I’ve also added an update for Rails 2.x compatibility submitted by davidsch.

Grab the plugin from the javascript auto include github repo.