This is how i did it originally:

  def contact_display_name
    returning String.new do |output|
      output << title + ' ' unless title.blank?
      if initials
        output << initials + ' ' unless initials.blank?
      else
        output << first_name + ' ' unless first_name.blank?
      end
      output << surname + ' ' unless surname.blank?
      output << suffix unless suffix.blank?
      output.strip!
    end
  end

Rather too long-winded for my liking. I managed to refactor it down to this:

  def contact_display_name
    [title, (initials? ? initials : first_name),
      surname, suffix].delete_if(&:blank?).join(' ')
  end

Of course, it is another advantage of behaviour-driven development, that i had already specced out what i wanted to happen, and i could use the specs to ensure that my two versions of the function were equivalent. See below for the specs that verify the behaviour.

  describe "contact_display_name" do
    it "should output the first_name and surname" do
      contact = Contact.new(:first_name => 'Gabriel', :surname => 'Gray')
      contact.contact_display_name.should == 'Gabriel Gray'
    end

    it "should use the title if there is one" do
      contact = Contact.new(:title => 'Mr', :first_name => 'Gabriel',
        :surname => 'Gray')
      contact.contact_display_name.should == 'Mr Gabriel Gray'
    end

    it "should use the initials rather than the first_name if it has them" do
      contact = Contact.new(:title => 'Mr', :initials => 'G',
        :first_name => 'Gabriel', :surname => 'Gray')
      contact.contact_display_name.should == 'Mr G Gray'
    end

    it "should add on the suffix if there is one" do
      contact = Contact.new(:first_name => 'Gabriel', :surname => 'Gray',
        :suffix => 'BSc Hons')
      contact.contact_display_name.should == 'Gabriel Gray BSc Hons'
    end

    it "should not mind if there is no first name or initials" do
      contact = Contact.new(:title => 'Mr', :surname => 'Gray')
      contact.contact_display_name.should == 'Mr Gray'
    end

    it "should ignore any nil values" do
      contact = Contact.new(:title => '', :first_name => nil,
        :surname => 'Gray')
      contact.contact_display_name.should == 'Gray'
    end
  end

We’ve now switched all our active projects over. I highly recommend you do the same if you haven’t already - it’s a real step closer for us to the ideal situation where customers can collaborate on the text their own stories. Aslak and the rest of the team have a lot to be proud of.

Here are some reasons why i have been won over by the test-first philosophy:

1. One thing at a time
Of course we all like to write very small concise functions, don’t we? But even in a small function, there are usually a few different paths that could be taken through it. It is so beneficial for me to think of scenarios one by one, write up the expected outcome, and then write the function a little bit at a time until it passes all the tests.

2. Confidence
Let’s be honest - who wants to go back and manually test all the things that you’ve tested a hundred times before and you’re pretty sure they’re still going to work? I used to be a tester - that was my job - and I couldn’t stand the monotony. But you can never have complete confidence in your whole system unless you have tested all of it. If you have broken something, it’s much better to know sooner rather than later. When you have a complete set of tests to run after every test you can be completely confident in your application.

3. Prove the obvious
Sometimes I’m writing a piece of functionality and I think, “Oh that’s so obvious - I don’t need to write a test for that!” But then I think to myself, if it’s so obvious then I had better make sure that it stays that way. In any case, it may not be obvious to the next person who works on this bit of code. It may not even be obvious to me in a few months time. So I write a test to prove the obvious. If somebody changes it and breaks the test, then they will be forced to think twice about the change they are making.

4. A greater understanding
Step-by-step stories are a wonderful way of understanding a system. Often when I’m coming to a piece of code I’ve not worked on before the first thing I do is work through the story. It may be enough just to read it through to see what happens when, and why. Sometimes I literally follow every step of the story, performing it manually to see for myself what it does. Once I understand what is supposed to happen, I’ll have a far better chance of following the source code. So be kind and write nice stories for the next person who comes along and wants to understand your code.

We write our behaviour-driven-development stories and specs using RSpec, and we are currently converting to Cucumber to run our test suites.

I find it slightly bizarre that even economic cycles have their own branding departments now…

Having ‘taste’ is a really important skill you can have as a developer - even if you don’t classify yourself as a ‘designer’. It’s a great thing to be able to add User Interface elements in just the right place, or code a feature up that just feels right. When a piece of software has been crafted lovingly, everyone loves to use it.

Having taste as a developer is a bit like what my wife says about being tidy around the house. Now, I’m not a naturally tidy guy, but I’m learning to be; mostly because if I wasn’t I would drive her crazy! Sometimes the problem is that I just don’t see the mess, but that’s really laziness. It’s because I’ve not yet learned to take a second look each time and judge my attempt at cleaning the kitchen with her standards. Usually at that point I see where I could do better.

It’s the same with code/feature design. Most of the time it just takes another look, and not settling for just “good enough”. It’s a choice, and making the right one will make someone else that much happier with the work we do. Food for thought.

In the past I’ve been guilty of two equal yet opposite mistakes on website projects regarding design implementation. There’s a temptation to leave the implementation of the design right until the end of the project (”It’ll only take a day or two, after all”). There’s also a strong urge to get the design done right at the beginning of the project, to really show the client what the finished article will look like.

Both of these approaches turned out to be mistakes.

When we’ve left the design until the end of the project, the client ends up directionless. Unless they’ve got a programming background, or heck of lot of vision (and most don’t), they just won’t put your lovely design concepts together with your naked ‘Times New Roman’ HTML wireframes. Sure, the site works, and works well, but it just won’t feel right. The client won’t be able to get past how it looks and will ignore all your fervent feature demos because they’ll be thinking about that ugly font.

With one project on which we did this, the client ended up changing their mind too much about what they wanted; had they seen the design progressively improving look and feel they may well have been able to catch the vision for the site quicker. With less understanding clients, you run the danger that all your hard work behind the scenes will be dismissed just because it looks awful and they wonder what you’ve been doing with all that time and money.

So why not get those concepts right onto screen straight away in their full glory? That way they’ll know exactly what they’re getting, right?

Big mistake. When we’ve done this in the past, we’ve noted that clients often equate the progress of the design with the general progress of the site. With one project, we rolled up at the end of the first iteration with a beautiful website that showed the finished design in all its glory. The client was very pleased. However, the very next iteration, after we’d spent just as much time on functionality and ‘behind the scenes stuff’, they were less pleased. Despite us telling them how much we’d accomplished, they just couldn’t quite see it. We then spent quite a while on the back foot trying to convince them stuff was happening, even though the site looked much the same as it did at the start!

So where’s the balance? I’m not sure there’s a perfect middle way; it depends on the client you’re working with and the type of project you’re working on. These days however we progress with the look and feel in stages; it tends to ensure both client and consultancy are on the same page and everyone can measure progress in their own way.

I thought it was an excellent conference. It was a little smaller and more intimate than last year, but that suited me as it wasn’t quite so crammed and I had more time to talk to people. It was definitely worthwhile taking the whole team; everybody learnt an enormous amount, and we got a lot of team chat in, which is always good. From a business standpoint, there was plenty of old-fashioned hand-shaking, and a few people who might just find the time to come along and work for us - we’re always looking for talented programmers. The message boards they have at these conferences are always good for this.

My conference highlight was the fresh take on legacy code from David Heinemeier Hansson.  Looking back on previous code you’ve written should make you cringe to some extent; how else do you know that you’re improving as a programmer? A good lesson in confidence for programmers everywhere; it was great to hear the message from someone so high-profile.

Not sure we’ll go in such numbers next year, but it’s great that we managed to get there this time. There’s a chance that RailsConf Europe 09 might be a bit closer to home, which will be nice. I’m also planning to head to Future of Web Apps in London next month (at least for the expo) - drop me a line if you’re going.

-Chris

As a company, most of the web applications we build for our clients are written in Ruby on Rails. Ruby is an interpreted, object-oriented programming language created by Japanese programmer Yukihiro Matsumoto, often known as ‘Matz’.

Rails is a framework written in Ruby which allows easy access to a database and supports our rapid development cycle. It is so-called ‘opinionated software’ in that it gently guides us to use standards that have been proven to work well, and it encourages the current best practices for web development. Rails was created by Danish programmer David Heinemeier Hansson, often known as ‘DHH’ or just ‘David’.

For me personally the most useful part of the conference was the half-day tutorial on Unobtrusive JavaScript. Many web sites these days are full of clever effects such as drag and drop, fading text, expand and collapse. These effects are made possible thanks to ingenious use of JavaScript. The trouble is, not all browsers support JavaScript. As web programmers it is our responsibility to make our sites accessible to all users. The tutorial taught me some useful new concepts, and the hands-on practice was beneficial.

Other highlights were the seminars about advanced RESTful techniques, globalisation and internationalisation, presentation caching, and enabling offline access to a website using Gears. We also heard a fantastic keynote from DHH concerning ‘legacy’ code. As time goes on we become better programmers and we may begin to dislike the code we wrote in the past. Since joining I am definitely having this experience, because i have learnt such a lot! David’s message was to celebrate legacy code - it shows how far we have come. We saw how tidying up just a small part of the code can have a big impact in feeling better about it.

It wasn’t all hard work at the conference. We sampled some of the bars and restaurants and visited the Brandenburg Gate. I got to meet some people i’ve known on the Internet for a while, and also made some new friends. It was a very worthwhile trip.