Before joining this project I spent two weeks on another project helping them make a technology decision. This other project had a requirement for a sophisticated web UI. The choices were Flash or JavaScript. After helping with some spikes the team decided to use JavaScript. As this would be the first time anyone on the team would be using JavaScript, I made some recommendations. One of these was not to use CoffeeScript.

I was wrong.

It was a new project with a team of people who weren’t very familiar with JavaScript and certainly had not written a large JavaScript application. I felt that CoffeeScript would be another new thing for what until very recently had been a Java team. It would be better to first learn JavaScript; understand that and then learn how CoffeeScript can make the language better.

After that short consulting gig, I started on this project on the following Monday. This was another sophisticated JavaScript UI application. But it was already about two months into development. This project had already decided not to use CoffeeScript, for similar reasons as I’d gone through on the previous Friday. It was like jumping forward in time two months. More than anything else, with the amount of JavaScript code we had, the syntax was just agony. It simply made the code harder to read. This may sound like a small detail, but I believe very strongly that code needs to be readable by humans above everything else. JavaScript’s syntax is simply woefully inappropriate for the style of programming the language is otherwise very tuned for.

As I mentioned above, we used underscore.js pretty heavily. This encourages a lot of anonymous functions passed as parameters, something that reads very nicely in Ruby. In JavaScript, a simple loop to lowercase every string in an array reads pretty painfully.

var keyNames = _.map(recipientNames, function(name) {
  return name.toLowerCase();
});

By the way, the glyph }); is henceforth known as the coffee-break.

The absolute bare minimum for a lambda is function() { return; }. That’s 19 characters! 19! Here’s the same code in CoffeeScript:

keyNames = _.map recipientNames, (name) -> name.toLowerCase()

That is one plausible line. Yes please, can I have some more? This may seem like a small detail on its own. It’s just syntax, you say. You may disagree with my opinion that syntax is critical. Allow me to offer another example from this project. A couple of us are Ruby programmers, and fans of the very declarative style of test that is possible in RSpec, using let.

describe "an account" do
  let(:subject) { Account.new(:balance => balance) }
  describe "positive balance" do
    let(:balance) { 100 }
    it "should allow withdrawals" …
  end
end

The JavaScript unit testing library of choice, Jasmine doesn’t (yet) include any equivalent of this. So I whipped something up pretty quickly to allow the equivalent:

describe("an account", function() {
  define({subject: function(ctxt) { return createAccount({balance: ctxt.balance()}); }}, function(ctxt) {
    describe("positive balance", function() {
      define(ctxt, {balance: function() { return 100; }}, function(ctxt) {
        it("should allow withdrawals", function() { …; });
      });
    });
  });
});

There are two problems here. Firstly, JavaScript doesn’t have instance_eval or method_missing so you can’t decorate a lexical scope before passing it downwards, hence explicitly passing down the ctxt parameter. Actually, while the lack of method_missing is a real pain, I think instance_eval is no great loss and I would happily write much, much code in a language that doesn’t allow libraries to mess with name bindings quite so liberally.

Secondly, the sheer noise of the JavaScript syntax is incredibly painful. Here is the equivalent, translated directly into CoffeeScript.

describe "an account", ->
  define
    subject: (ctxt) -> createAccount balance: ctxt.balance()
  , (ctxt) ->
    describe "positive balance", ->
      define ctxt,
        balance: -> 100
      , (ctxt) ->
        it "should allow withdrawals", -> … 

The most interesting thing from this conversion, to me, is that it shows that the double-nesting of defines and describes is actually pretty unclear. In my copious spare time I’m working on a better implementation of that define() function, in the hope of getting it added to Jasmine. If I’d been staring at that second version throughout the project I would have started down that path earlier.

But the better syntax is not everything; the other features in CoffeeScript, like list comprehensions and default arguments are Good Things and would have been very nice to have.

The application is a mobile web app for a customer who already has a number of native apps for iPhone and Android. All these apps use an existing set of services to access the core data. Our app used JQuery Mobile and Underscore.js as the only libraries. For testing, we used Jasmine and cucumber.

Originally, I wanted to post this as a single post, but it go long. Very long. Looking back on our project, there were four things I’d like to try doing differently.

• We didn’t use CoffeeScript for what felt like very good reasons at the time. In hindsight, this was a mistake.

• Writing functional tests for a pure JavaScript application is a different problem requiring different solutions than a typical web application.

• Your JavaScript application is going to end up as a very sophisticated GUI application, with more complex state and flow management than most typical web applications. Consider your use of models and controllers very seriously.

• Web applications have long had to deal with the Back and Refresh browser buttons. A single page JavaScript application adds some new wrinkles. But I think that HTML 5 also includes some neat solutions.

As I get my posts written, I’ll update the above with links.

The first week and a half was Chicago. A couple of days of thrilling things like opening a bank account and applying for my social security number. Banks are different over here. There are only two account packages that were offered, and both only have a monthly fee of $8 which is waived at the drop of a hat. And banks are open on Saturdays! The horror.

The week on the beach was a good break. In the end, with public holidays, transition leave and beach time, it was three weeks between stopping work in Australia and starting on a project over here.

Of course, the coffee is still almost universally rubbish. To counter that, we spent quite awhile in Chicago hunting for the perfect burger. After being repeatedly scared off by threats of three hour waits we finally had a really good one the afternoon I was flying out.

And the first project was in Plano, Texas. That’s a suburb of Dallas. And a complete wasteland. It’s a dead-flat plain, smeared with office parks and strip malls. I didn’t know what a strip mall was until I got down there. I see why they inspire such horror. Around Plano is basically nothing, but fortunately we stayed in a hotel in another suburb about 15 minutes to the South: Addison. Addison at least has a strip of franchise restaurants, and kind-of-bars. The highlight of that was the evening we ate dinner in a Greek restaurant, while watching a car on fire across the road. Metre high flames and plumes of black smoke. Very exciting.

By ‘we’ I mean the ThoughtWorks team. Just two other travellers. They started to think I liked Starbucks. I tried to put a stop to that, but I couldn’t help but be excited at almost drinkable coffee. Sigh.

Dallas has three redeeming features: first, Texas BBQ — hell yeah! It’s completely unlike anything I’ve had and really amazing. Half a pound of meat, served on paper, eaten with your fingers, no sauce, sitting in a dirty shack. Well worth it. Lockhart’s Smokehouse in Oak Cliff, if you’re ever down that way.

Second is the 6th Floor Museum. In the Old Texas Book Depository. That’s right, a museum dedicated to the assassination of JFK. It’s actually a good museum. Small enough to really see; respectful without being sycophantic; and complete: it finishes with the conspiracy theories. In one corner they have recreated Oswald’s perch, as it was when they first found it. Down in the plaza outside it’s a different story. There’s an ‘X’ on the road at The Spot. And the grassy knoll is covered in lunatics delivering speeches and handing out pamphlets. Again, if you’re there, then go.

And finally, my accent was quite novel. Apart from the teasing and joking from the team, I walked into a pub and wanted to order a beer. I made the mistake of trying to order by name, instead of just pointing. There’s a San Francisco beer I quite like called ‘Anchor Steam.’ Some of you would have already seen where this is going. I had to repeat myself several times. The waitress went to stare at the beer fridge. Conferred with a couple of other staff. And then returned with another waitress. She’d brought over a Brit to translate for me. Sigh. The trick is to really hoe into those ‘Rs’.

Working with the client was kind of fun. I spent a day pairing with a very junior client dev. She was from Louisiana. She has only been in a taxi twice. At stand-up, the next day she said that pairing was fun but a bit difficult to follow. A helpful ThoughtWorker then said “That’s just Giles.” Very quickly she said “Oh, but I love his accent!” In a Southern drawl. So I’m playing up the Australian thing. They’re all my mates, and there are no worries to be seen anywhere.

I’ve finished up in Dallas, and spent the weekend back in Chicago. And now I’m on another plane. This time I’m off to San Francisco. Joining a big team out there, I’ll probably be here until September, I think. The client is at 2nd and Mission, and we’re staying in hotels around Union Square. This should be quite a lot of fun.

Typically, cucumber step definitions look like this:

When /^I select the recipient named "([^"]*)"$/ do |recipientname|
 within_jqm_page do
   page.find('a', :text => recipientname).click
 end
end

Step definitions implemented like this end up becoming a pain to re-use. Essentially you are calling a function, except to do so you have to construct a string, and then execute that. We’ve all seen how that ends.

Given /^all the entered recipient details are valid$/ do
  When %{I fill in "name" with "Valid Name"}
  And %{I fill in "phone" with "4152234567"}
  And %{I fill in "email1" with "valid.email@example.com"}
end

The direct outcome is very hard to maintain step definitions — like the above — and thus very poor quality cucumber tests. Patterns like page objects and personas take work to extract when following this approach. This approach that is analogous to writing VB6 applications in the early 2000s where all logic was just a double-click on a form button away. And as with VB6, that cucumber directly encourages this approach is part of the problem.

I hear a lot of complaints about cucumber these days. These complaints tend to target the English language test scripts: while business readable acceptance tests may be nice, these are useless if the business is never actually reading the tests.

The unspoken heart of this complaint seems to be the English language tests are responsible for the poor maintainability of the average cucumber test suite. I agree. But that shouldn’t be the case.

After trying to build well-factored cucumber suites on a few occasions, I pretty much hate the pattern of just attaching anonymous blocks to regular expressions. Instead, I want step definitions that directly invoke methods. Something like:

Given /^I am on the (\w+) page$/ => :go_to_known_page,
  :on => { current_user }

class User
  def self.current_user
    …
  end

  def go_to_known_page(page_name)
    visit Page.page_named(page_name)
  end
end

World(User)

The significant part is in the first two lines. Instead of passing a block to the Given, a symbol for a method to invoke would be passed. This method would be invoked with the arguments matched by the regular expression, after any Transforms have been applied. The :on is optional. This is a block evaluated against the World. If :on is provided, the method would be sent to the result of this block instead.

Yes, this would force you to define classes and attach methods to those. Yes, this would require you to think about the interrelationships of your objects. Yes, this is quite a lot more limited than an arbitrary block of code. Yes, that is exactly the point.

After a quick glance through the cucumber source this does not look difficult to add. Should I go to the effort of adding it?

In the world of adults the solution to these problems is known as dependency management. There are now two tools to help Ruby: rvm and Bundler. These are both opinionated pieces of software that try to do a lot to help. Often far too much. After digging quite deeply into Bundler with Nick Drew on a recent project, here are some things that we learnt that I’ve tried to distill into a set of guides on good ways to use Bundler and rvm. This is just what I’ve discovered, if there are any tips or better ways to use these tools, or other tools that help, please share.

This is going to assume that you already know something about both.

• Firstly, use rvm and Bundler. If you have used them in the past and were unhappy, try again. The early versions had some truly horrible bugs. Development has moved quickly and things are a lot better now. If you’re using Rails 3 then you have little choice about Bundler. But for any projects you should use these.
• Use rvm to install your Ruby, don’t use the system Ruby. Create at least one gemset and use that.

• Create a .rvmrc for your project and check it into source control. Naming the gemset after your project, it should probably look something like:

  rvm_install_on_use_flag=1
  rvm --create use ruby-1.8.7-p330@project
  

• Use rvm on your build box. But not in production.

• Create a personal gem set and toss the gems you use on simple little scripts into that.
• Install Bundler into the global gemset for the Ruby you are using.
• Include development and test groups in your Gemfile. Be strict about the difference between a gem required to run the build system (development), used in tests (test — obviously) and a gem required to run the application.
• Don’t check the .bundle/config file into source control. Bundler often chooses to remember settings in this file. This will cause much irritation. This is an example of being more helpful than is helpful.
• Don’t use the --deployment switch to bundle install unless you really mean that. As well as producing a local bundle of gems, installing in deployment mode will freeze the Gemfile. This is remembered and will cause much frustration when you’re trying to add new gems. If this does happen you will get an opaque error complaining that you have not checked your Gemfile.lock into source control. To get around this, just delete your .bundle/config. You’re doing that to remove the remembered setting about freezing your gems.

• Your build script (the one you run before committing) should call bundle package. In fact, it should look quite a lot like:

  bundle package && bundle install && rake spec features
  

• Check the gem files in vendor/cache into source control.

• Definitely use bundle install --deployment --local --without="development test" either as part of your Capistrano tasks or as part of packaging for a release. Every one of those switches except the first should not be required. But they are. So there you go.
• Bundler attempts to take over your world. This is intensely irritating. Expect to be annoyed.

• If you ever need to start a Ruby program from your Ruby program but in a different Bundler world, you will need to do some cleaning of your environment. In particular you will need to clean the environment variables BUNDLE_GEMFILE, BUNDLE_PATH, BUNDLE_BIN_PATH and most surprisingly RUBYOPT. You may find the following function helpful.

  def without_bundler_env
    original_env = ENV.to_hash
    ENV.delete("BUNDLE_GEMFILE")
    ENV.delete("BUNDLE_PATH")
    ENV.delete("BUNDLE_BIN_PATH")
    ENV.delete("RUBYOPT")
    yield
  ensure
    ENV.replace(original_env.to_hash)
  end
  

• If you need to examine the Gemfile from another Ruby project in your Bundler controlled world, you will think that you can use Bundler::Definition.build("<i>path to Gemfile</i>", "<i>path to Gemfile.lock</i>", nil). That would be a good start. You will also need to set ENV["BUNDLE_GEMFILE"] to point to that file and call resolve_with_cache!, however. Try the following:

  ENV['BUNDLE_GEMFILE'] = 'Gemfile'
  bundle_def = Bundler::Definition.build('Gemfile',
                                         'Gemfile.lock',
                                         nil)
  bundle_def.resolve_with_cache!
  

Ultimately, the goal of Bundler and rvm are noble. Dependency management is a hard problem. And there are no alternatives if you are choosing to use Ruby. Are there things that could perhaps be done better? Absolutely. But there is probably nothing so bad that some patterns couldn’t fix. So please, let’s all work out how to get the most out of these tools.

So without further ado, the big announcement is that I’m working on a new language called Seph. […] Why? I already have Ioke and JRuby to care for, so it’s a very valid question to ask why I would want to take on another language project […]. The answer is a bit complicated. I always knew […] that Ioke was an experiment in all senses of the word. This means my hope was that some of the quirky features of Ioke would influence other languages. But the other side of it is that if Ioke seems good enough as an idea, there might be value in expanding and refining the concept to make something that can be used in the real world. And that is what Seph is really about.
— Preannouncing Seph

This will be an informal, and highly technical, talk on a really interesting new language. Come along for a chance to ask your questions. Also, to enjoy some free beer and pizza. There’s a pretty good chance that Martin Fowler may be in the room, though I’m not promising anything…

Where?

ThoughtWorks Sydney Office, Level 8, 51 Pitt St, Sydney

When?

Wednesday, 8th Sept; 6pm for a 6.30pm start

Who?

You! Assuming you’re a developer interested in learning about languages.

How?

RSVP to Giles Alexander as I need some idea of numbers.

And that’s all you need to know, see you on Wednesday.

• When you are working on projects you will sit down with someone with a problem. You’ll get to know that person and their problem intimately and personally. Hopefully you’ll then solve their problem and leave them in happier and better place. All thanks to the expertise you have imparted.

• When you are working on products you will not have this personal connection with your customers. Instead you will attempt to imagine how all the possible customers in the world could potentially want to use your product. You’ll try to place yourself in an enormous range of situations and attempt to make each of those a bit better. Hopefully, if your product is completed and a success in the market then you will have made the world a better place for a huge range of people. None of whom you’ll ever know.

So… satisfaction from helping just a few people you know well, or satisfaction from helping a huge range of people you’ll never know? Of course, if you do choose to work on projects then you’re guaranteed to help people, whereas products succeed far less often.