Jot Thought

Well, we’re officially in hiring mode. Business is so strong that we need help asap. After doing lots of research and advice gathering on general employment (and there’s a lot,) we got down to business by writing up a couple of job descriptions and heading out into the world seeking great talent. Our methods to date have consisted of:

1. Posting on our web site
2. Posting on free sites like rubynow.com and rubyrockstars.com
3. Posting on paid sites like jobs.37signals.com and linkedin.com (we also used their free posting to our own networks)
4. Posting on the Stanford and Berkeley job boards
5. Announcing open positions at local ruby meetups
6. Posting on various message boards to which we belong
7. Sending out requests for recommendations to friends and family

The results have been interesting so we thought we’d share.

37signal’s job board, at $300 a post, generated the most traffic to our site, but not the highest number of applicants. In fact, we got as many inquiries through the free ruby boards as through 37signals. We’ve had the most luck from the meetups (fewer candidates, but much higher quality) and using LinkedIn (great candidates through our own network and more submissions through their paid listings than any other source - which is a good deal since they only charge $145 a post)

We also encountered a couple of unexpected results:

1. A ton of recruiters and staffing firms submitted to our jobs form. Suffice to say, we’re not willing to pay fees of up to 30% of first year’s salary.
2. We had a number of folks contact us looking for help obtaining an H1-b visa or sponsoring them for one they already have.

All in all, we’ve actually met a number of really promising candidates, and have one who’s accepted our position of web developer. You’ll hear more about him when he starts in a few weeks:-)

On a recent Ruby on Rails project, we ran into a situation where we needed to use the ActionController::Base url_for method in our tests. My first attempt was to simply write the test as follows:

def test_next__should_show_step3
  @request.env["HTTP_REFERER"] = @controller.url_for(
    :controller => 'wizard',
    :action => 'step',
    :step_number => "1",
    :id => 1)
 
  post :next, :id => 1
  assert_not_nil
  assigns(:virtual_tour)
  assert_response :redirect
  assert_redirected_to :action => 'step', :step_number => "3", :id => assigns(:virtual_tour).id
end

When I ran the test it resulted in the following error:

test_next__should_show_step3(VirtualTourWizardControllerTest):
NoMethodError: You have a nil object when you didn't expect it! The error occured while evaluating nil.rewrite
/usr/local/lib/ruby/gems/1.8/gems/actionpack-1.12.5/lib/action_controller/base.rb:488:in `url_for'
./test/functional/virtual_tour_wizard_controller_test.rb:91:in `set_referer_step'
./test/functional/virtual_tour_wizard_controller_test.rb:64:in `test_next__should_update_virtual_tour'

When we looked at the rails code, we saw that an instance variable @url was not initialized yet in our tests. This was causing the nil error seen above. We found a post that wrote about a work around by initializing this variable by calling get :index or some other action that doesn’t cause a side effect. This seems like a bit of a hack so we dug a little further.

After a little digging in the rails source code, we found the class that does the actual URL rewriting. The class is called ActionController::UrlRewriter which url_for delegates to to do the actual URL rewriting. So we created a little helper method in test_helper.rb to wrap ActionController::UrlRewriter in a nice helper method called url_for. The following is the method we created in test_helper.rb

def url_for(options)
  url = ActionController::UrlRewriter.new(@request, nil)
  url.rewrite(options)
end

We can know rewrite our test to look like this.

def test_next__should_show_step3
  @request.env["HTTP_REFERER"] = url_for(
    :controller => 'wizard',
    :action => 'step',
    :step_number => "1",
    :id => 1)
 
  post :next, :id => 1
  assert_not_nil
  assigns(:virtual_tour)
  assert_response :redirect
  assert_redirected_to :action => 'step', :step_number => "3", :id => assigns(:virtual_tour).id
end

We ended up doing a little more refactoring after this since we set the referer like this in many of our other tests.

One of the easiest ways to get feedback on your web application is to use screensharing technology to watch folks attempt to use your site. Many of the top web conferencing applications can be used for this purpose, and they usually offer free trial accounts. You set up a time for your session and get a meeting ID and a conference number. The user will need to go to the site, enter the meeting id number, download a small applet (usually java) and then have “presenter” status moved to them. From that point on, you can see your subjects using your site while talking to them. It’s particularly useful for larger teams, as multiple people can join in the “meeting” from anyplace with an internet connection. Basically, there’s no reason the entire development team can’t sit and watch from their machines.

Until recently, my favorite was GotoMeeting from Citrix. It was much simpler to use than WebEx or even worse, Gatherplace.net. However, we just uncovered a serious limitation while doing some usability with one of our clients. Gotomeeting doesn’t allow Macs to act as hosts - meaning a user with a Mac can’t share his or her desktop with the team. This renders the tool useless for this kind of research.

Fortunately, we gave Adobe’s Acrobat Connect a try and not only did it work flawlessly, but it was even easier to use than Citrix and it uses a Flash plugin rather than a java applet. They offer a 14-day trial, which should be plenty of time to run a study and determine if it works for your purposes.

In case anyone from the above companies happen to see this, I think the entire market is missing an opportunity to repackage these online meeting solutions for research purposes. It’s a classic case where a technology designed to solve one problem ends up being very useful in solving another problem. Call it a great “unintended” use! Either way, it would be great to see one or all of these providers offer a simpler solution with a more cost-effective pricing model for this type of service.