Entries from June 2005 ↓

Google and Yahoo are going to slug it out over mapping. MSN wants to join in too.

In a touch of synchronicity both G and Y released their mapping APIs today so all us geeks can play.

Smart move.

It’s easy to forget that sometimes it’s the little touches of quality and honesty that shine through after you’ve bought a product that can make all the difference. In this interview with the top US engineer for Honda, the power of a core ‘do the right thing’ value comes through:

Q: Maybe it’s just hard to get respect for something as sensible as gas mileage. Even with gas at $2 a gallon, people still don’t buy a car simply for good fuel economy, right?

A: Exactly right. What we’ve got is the stealth approach. We’re not trying to say buy this car—yeah, it’s ugly, yeah, it really doesn’t have the features that you want, yeah, maybe it’s a little too expensive, but buy it anyway because it’s the right thing to do. Because No. 1, you would go out of business. We have to make an attractive car and then one day you’ll wake up and say, “Hey, this thing gets pretty good fuel economy.” And you’ll feel good about it.

We’re in the business of collecting reviews on electrical products. I wonder what question we could ask to find out which features made the users feel surprisingly good?

(I found the honda interview via WorldChanging)

Something big is happening on the internet, right now, under our noses, and we’re involved. The cluetrain has finally arrived, though in British Rail style it’s been a bit delayed.

From time to time, I come across a blog entry that I know I’ll be talking about and thinking around and plagiarising for weeks to come. Identity over at The Robot Co-op is one such gem.

In his essay, Josh Petersen makes a cogent case for what I’ve christened the Soylent Green theory of what’s happening – you might know it as Web 2.0, but where’s the fun in that?

Some choice quotes:

“Part of what is happening on the web today, through folksonomies, blogs, social networks, link sharing and photo sharing are new ways for people to disclose their personalities in public and new ways to develop a digital identity that might augment who we are as people, offline.”

“The issues that this brings up get lost when the only policy folks have to reference is a “privacy policy”. Perhaps we need a “publicity policy” for 2.0 websites.”

“We are kind of into kind of crazy.”

(BTW. Don’t tell anyone, but Soylent Green is people)

A disappointingly short interview with Jimbo Wales, the founder of wikipedia nevertheless contains some great insights about the nature of wiki-like collaboration on corporate intranets.

I like best his judgement that it’s good when “people don’t have to get permission to do something useful.” This feels right to me – I would rather that my minions team did twenty things without asking me for permission, and got some things wrong, than deferred to me at every step.

On trusting employees, his approach seems very sensible: “You don’t expect people to vandalize the wiki any more than they would vandalize the Coke machine. If you anticipate problems with employees maliciously changing documents, you’ve got much worse problems.”

As an aside, it does make me laugh that a site called CIOInsight which positions itself at the cutting-edge of IT has no RSS feeds available and doesn’t even have valid HTML pages. I hope a redesign is in the wings.

For my sins, I’m a smoker and caffeine-addict. On a previous project, before I discovered the mock-objects religion, it took so long to run unit tests before a code check-in that I had time to nip downstairs, get a coffee, have a quick cigarette and be back upstairs before the green bar was halfway done. I knew things were bad when I realised I was on 20+ check-ins per day.

I think that the biggest advantage of using mock objects is that your tests run quicker. I find that the quicker I can run all the tests, the braver I become in fixing any broken windows that have crept into the code. But there are other significant advantages too: design decisions can be defered until you have more knowlege about the domain; classes tend to end up less tightly coupled; girls throw themselves at you in the street. Well, perhaps two of those three things are true.

An example from our codebase using the Schmock mock objects library that we developed while writing our code here.

Although we’re programming in Rails, our controller layer and model layer are separated by some service objects – one of which handles our wiki implementation. To test the wiki controller, we mock out the actual wiki using a SchMock:

class WikiControllerTest < Test::Unit::TestCase

In the setup method we create the mock_wiki and inject it into the application controller from which everything that uses it can access it.

  def setup
    @mock_wiki = SchMock.new
    ApplicationController.wiki = @mock_wiki
    @controller = WikiController.new
    @request    = ActionController::TestRequest.new
    @response   = ActionController::TestResponse.new
end

At the end of every test we verify that the mock_wiki has had all its expectations fulfilled.

  def teardown
    @mock_wiki.__verify
  end

Now the real meat of the test. We want to make sure that if we try to edit a non-existing page that we’re redirected to the ‘new’ action. We tell our mock_wiki to expect a call to page_exists? with a parameter ‘nonexistent’ and when it gets it to return false.

I find this simpler than using the built-in fixtures functionality in rails to set up the database to a known state, because the fixture appears right there in the code rather than derived from two-step removed database tables and I don’t have to remember to delete any pre-existing state from the database. It also runs much, much quicker.

  def test_should_redirect_to_new_page_form_if_asked_to_edit_nonexisting_page
     @mock_wiki.__expects(:page_exists?).with('nonexistent').returns(false)
     get :edit, { :page => 'nonexistent'}
     assert_redirected_to :action => 'new', :page => 'nonexistent'
  end
end

I think my life-expectancy has been greatly improved through the use of mock-objects and I thank the good chaps who wrote and promoted the original mock-objects – people like Steve Freeman, Nat Price, Ivan Moore and Joe Walnes – who write much more elegantly than me on the topic.

“[this] whole talk is about how if you follow your dream you’ll not only be happy, but you’ll also be financially secure, and it’s easier to believe that kind of advice when it’s given to you by someone not LIVING IN A SHACK DOWN BY THE RIVER.”

I’m not a big fan of powerpoint-style presentations. But this one is a good and funny one – and it’s not really about being a money-grabbing technocrat.

Instead, it’s a message that there can be more personal and even commercial value in servicing a niche market full of passionate users than in a mass-market full of half-baked products.

I like the definition of an entrepreneur: hating being told what to do, liking eating rice and beans and living in a box, down by the river.

RubyOnRails comes with built-in support for unit and functional testing – great for us test-driven development whackos. In a new rails application we’re developing, we used the excellent salted hash login generator to kick off the development of our site’s authentication. The login generator ships with tests – yippee! Since it’s a widely used extension for rails, it makes a useful example for some testing best practices that we’ve adopted.

[[Update: if you follow the conventions outlined here, you should be able to use the agiledox browser that I write about here]]

Here’s an example of one of the tests:

def test_auth_bob
    @request.session['return-to'] = "/bogus/location"
    post :login, :user => { "login" => "bob", "password" => "atest" }
    assert_session_has "user"
    assert_equal @bob, @response.session["user"]
    assert_redirect_url "/bogus/location"
end

This test checks that the on successful login, the appropriate user is set in the session and that the browser is sent a redirect to a location stored in the session. I like my test methods to test one thing at a time – it becomes easier to narrow down any cause of failure. So, I split the two tests:

def test_auth_bob_1
    @request.session['return-to'] = "/bogus/location"
     post :login, :user => { "login" => "bob", "password" => "atest" }
     assert_redirect_url "/bogus/location"
end

def test_auth_bob_2
   post :login, :user => { "login" => "bob", "password" => "atest" }
   assert_session_has "user"
   assert_equal @bob, @response.session["user"]
end

Now, we have two tests: one that checks that the controller redirects and the other that the session has the user set. But we have some duplication that’s crept in and we need to do a bit of work on the test names.

def log_in_with_valid_user
   post :login, :user => { "login" => "bob", "password" => "atest" }
end

def test_should_redirect_to_page_stored_in_session_on_successful_login
  @request.session[:return_to] = "/bogus/location"
  log_in_with_valid_user
  assert_redirect_url "/bogus/location"
end

def test_should_store_user_object_in_session_on_successful_login
  log_in_with_valid_user
  assert_session_has :user
  assert_equal @bob, @response.session[:user]
end

We find that the pattern ‘test_should_***_on_***’ a useful way of naming tests – it’s an idea stolen from JBehave . If this test were to fail, I’m reminded that I should (!) ask myself the question ‘should the class I’m testing do this?’ before I go on a bug-hunt. The other advantage is that I can use my test classes to generate some simple documentation for my classes. Here’s a rake target that can do just that:

desc "Generate agiledox-like documentation for tests"
task :agiledox do
  tests = FileList['test/**/*_test.rb']
  tests.each do |file|
    m = %r".*/([^/].*)_test.rb".match(file)
    puts m[1]+" should:\n"
    test_definitions = File::readlines(file).select {|line| line =~ /.*def test.*/}
    test_definitions.each do |definition|
      m = %r"test_(should_)?(.*)".match(definition)
      puts " - "+m[2].gsub(/_/," ")
    end
  puts "\n"
 end
end

An example from our codebase, typing rake agiledox generates:

security_controller should:
 - redirect to page stored in session on successful login
 - store user object in session on successful login
 - redirect to page stored in session after signup
 - store user object in session after signup
 - reject signup when passwords do not match
 - reject signup when login too short
 - report both errors if passwords dont match and username too short
 - not store user in session if password not correct on signup
 - remain on login page if password not correct on signup
 - remove user from session on log out

“I think the large, feature-rich multimillion dollar IT systems aren’t working as promised.” Too right.

This quote comes from a great interview about the new online triumvirate of wikis, weblogs and RSS and how they’re really about people and collaboration.

The new internet is not about technology any more than newspapers are about ink. I’ll think of a better metaphor tomorrow.

Rushing to get to the pub for a swift pint…

Microsoft posters have appeared all over London. Apparently, whereas I thought I was a technically-savvy chap, I am in fact a dinosaur. Great way to talk to potential customers, Microsoft. Here’s another blogger’s take which is right on target.

Thanks to Matt Galloway’s blog for pointing me to BlogPulse.

One set of choices that presents itself as CTO of a start-up is what technology we should be using? does it actually matter? and how do we judge a technology’s fitness?

I don’t think it matters as much as some people would have you believe – better concentrate on finding good programmers. However, in my last start-up, I think we started with a competitive advantage by being an early adopter of PHP. This turned into a disadvantage as we grew because it was hard to recruit good programmers for PHP and eventually we steered towards Java.

Looking for that early competitive advantage I can’t help being struck by the apparent hype surrounding Ruby on Rails.

This graph (from Blogpulse) implies that Java is still in the lead and the snowball effect of rails doesn’t appear to be gathering speed. Maybe the graph doesn’t mean anything, but its been food for my thought.