Red Squirrel Reflections

I'm excited to announce that Ryan Platte will be joining Obtiva in a few weeks. Ryan is the fearless leader of Chirb and will add significant depth to our dynamic language expertise.

I'm excited to announce that Ryan Platte will be joining Obtiva in a few weeks. Ryan is the fearless leader of Chirb and will add significant depth to our dynamic language expertise.

Inspired by Jamis' post on assert_select I've just committed an update to my Watir on Rails plugin that adds support for both assert_select and assert_tag. Give it a try!

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

class GettingStartedTest < Test::Unit::TestCase
  include WatirOnRails
  
  def test_getting_started
    browser = open_browser("/")
    assert_select "div#getting-started h1", "Getting started"
    assert_tag :tag => "h1", :content => "Getting started",
               :parent => { :tag => "div", :attributes => { :id => "getting-started"} }
  end
end

Rather than asserting against the body of the response from the controller, I'm grabbing the HTML from the most recently opened browser.

Working for a small software company excites me for many reasons. One of the most rewarding aspects of the 10 months that I've been working for Obtiva has been working with Tyler and watching him mature as a Rubyist. Tyler was already hacking Ruby when I met him, but since guiding him toward Rails and Ajax, Tyler has delivered some excellent work on a soon-to-be-announced Obtivian web offering. One of my favorite aspects of working with a small group of people vs. going independent is that our weaknesses and strengths are complimentary: our whole is greater than the sum of our parts. Although I did a lot of speaking and training in 2005 and 2006, one of my biggest weaknesses is (still) monologue. After road-tripping to GLSEC 2006 with Tyler last year and attending his talk, it was immediately apparent that Tyler is a gifted speaker. I'm pleased to announce that Tyler will be talking about Ruby and Rails at this month's Chicago Uniforum meeting and will be teaching our Ruby on Rails TDD Bootcamp in early March.

Even cooler still, Obtiva has just hired our first apprentice (and female), Victoria Wang. This is another important step toward establishing our software studio in Wheaton. Apprentices bring enthusiasm and an appetite for learning that inspires. On top of this, Victoria brings some other important qualities with her: excellent visual design abilities (that's her RailsConf-inspired drawing) and a non-male perspective. Welcome Victoria!

Since moving home to Norway, Aslak has been doing some cool work with RSpec and Watir. Most recently, he's added automated screen capture on failing Watir tests to his bag of tricks ... and he's not just using plain 'ol Watir, he's using SafariWatir too. :-)

Since moving home to Norway, Aslak has been doing some cool work with RSpec and Watir. Most recently, he's added automated screen capture on failing Watir tests to his bag of tricks ... and he's not just using plain 'ol Watir, he's using SafariWatir too. :-)

Like many small consulting companies, Obtiva was built upon a longstanding relationship with a large, local client. A client like this provides a strong foundation on which to build a business. As I said in my 2006 Retrospective, my primary goal for 2007 is to spend an increasing amount of time in our Wheaton office leading our Rails projects. To achieve this goal, we will need to bring in a steady stream of new projects. I'm happy to say that January has proven to be a good start. We kicked off two new Rails projects: negotiations software for a large bail bonds company and (yet another) social networking application for a major television network.

While these projects are wildly different, they have one thing in common. Both clients are located in California. Why is that significant? Go read Mike Karlesky's insightful post on Inshoring. While neither Obtiva nor Atomic Object can compete with the prices of our offshore brethren, it is possible for us to undercut our coastal colleagues.

Moving toward distinct, shorter-term projects creates a need for a steady stream of new business, which is exacerbated by our expertise in Ruby on Rails and agile practices. We have found that by coupling a killer technology like Rails with the disciplines of frequent releases and test-driven development, we are able to deliver our projects ahead of schedule. This puts more pressure on us to bring in more projects, but it also increases our chances for repeat business, not to mention the morale boost our team feels. It's a positive feedback loop that I hope we'll still find ourselves in when summer arrives.

Hamish released the first rb-appscript gem, paving the way for the new and improved SafariWatir. Now with non-sluggish performance! Seriously, my regression test script runs ridiculously fast on my MacBook Pro compared to previous versions of SafariWatir.

This performance boost comes as no surprise. Up until now I was doing the simplest most naive (and slowest) thing that could possible work by using backticks to invoke AppleScript from the command line...

`osascript <<SCRIPT
tell application "Safari"
  do JavaScript "#{script}" in document 1
end tell
SCRIPT`.chomp

This got me started, but it turns out that using an Apple Event bridge like rb-appscript is more natural, and so much faster...

app = AS.app("Safari")
document = app.documents[1]
app.do_JavaScript(script, :in => document)

In unrelated news, my fellow Obtivian Tyler Jennings has submitted his first Rails patch.

Watch the screencast of SafariWatir running its test suite.

As much as I love the freedom that monkeypatching provides, it's not until I taught the concept to a room of Ruby newbies that I appreciated how dangerous it could be in a team environment, particularly on a team with more than one Ruby newbie. Obie is teaching our Rails course at Cisco this week where it sounds like he had a similar experience.

I've completely neglected my apprenticeship patterns over the last year. Ruby and Rails is partly to blame for this. But the other reason is that I have an opportunity to apply Pete McBreen's ideas for the first time and, to me, that takes priority over almost anything else in my professional life, because opportunities like this don't come around very often.

Stories like the one that Victoria just related over on DevChix get me very excited about the future, and reinforce the direction the apprenticeship patterns are headed.

Tim Kuntz has written a nice series of blog posts on introductory ActiveRecord: intro, impl-1, impl-2, conventions.

Kevin Barnes is becoming one of my favorite bloggers. Today he posted a little gem about dogmatic YAGNI.

My point is that sometimes you are going to need it and you know you are going to need it. The secret is to use some balance and not just shut off your brain.

This took me back to what agilists were saying in 2001...

No process is foolproof enough, or complete enough, for users of that process to turn off their brains.

I believe this quote was from a paper from some of the guys from RoleModel but I can't find the PDF.

Kevin Barnes is becoming one of my favorite bloggers. Today he posted a little gem about dogmatic YAGNI.

My point is that sometimes you are going to need it and you know you are going to need it. The secret is to use some balance and not just shut off your brain.

This took me back to what agilists were saying in 2001...

No process is foolproof enough, or complete enough, for users of that process to turn off their brains.

I believe this quote was from a paper from some of the guys from RoleModel but I can't find the PDF.

Jamis posted yet another nugget of wisdom. This one was about Ruby's method visibility, which can be tricky for people coming to Ruby from Java or C#. Jamis left one aspect of the protected access level as an exercise for the rest of us, so I figured I'd write up an example that helps illustrate when you would use protected vs. private.

class Sibling
  def ask(sib)
    sib.tell
  end
  
  def spy_on(sib)
    sib.secret # will always complain
  end

  protected

  def tell
    secret
  end
  
  private
  
  def secret
    "Charlie tooted"
  end
end

rose  = Sibling.new
ricky = Sibling.new

begin
  puts ricky.tell
rescue
  puts "Ricky will only tell another sibling"
end

begin
  puts rose.spy_on(ricky)
rescue
  puts "Ricky complains when Rose tries to find the secret"
end

puts rose.ask(ricky) # Ricky will tell if Rose asks nicely

One of the main differences for Java developers is that objects of the same class can't see each other's private methods.