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.

• 5:59pm: Fuck.
• 6:00pm: 

I started programming for the Apple //e back in 1986, when I was seven. And ever since then I’ve been programming. And while I have only recently been programming professionally on and for Apple devices, I never stopped using Apple computers. Yes, all through the dark years of the 1990s I used and programmed Macs.

If I had been born in an early time I imagine I would have been an engineer of some more mechanical kind. If I was born any later I would still have been a programmer.

But if I hadn’t been exposed to Apple and Macs I would have been a different kind of programmer. Not necessarily better or worse, but definitely different.

So as one person whose life was changed by the influence of someone I never met, thank you Steve. You will be missed.

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?

This was really cool. It’s really easy to navigate and edit when you can see how many lines to move without having to count. It also didn’t hurt pairing. I could just refer to something ‘there, on line -10.’ I had to have it. So I hacked it into the linum.el mode that comes with my editor of choice, emacs.

Now that I’m reading Avdi Grimm’s emacs reboot, including his article about line numbering, I thought I should share. At least until I can get this submitted back upstream.

In your linum.el file, add the following after all the existing defcustom forms.

(defcustom linum-offset nil
  "Whether line numbers should be an offset from point or absolute within the buffer."
  :group 'linum
  :type 'boolean)

And then replace the existing linum-update-window function with the following.

(defun linum-update-window (win)
  "Update line numbers for the portion visible in window WIN."
  (setq start-line (line-number-at-pos))
  (goto-char (window-start win))
  (let ((line (line-number-at-pos))
        (limit (window-end win t))
        (fmt (cond ((stringp linum-format) linum-format)
                   ((eq linum-format 'dynamic)
                    (let ((w (length (number-to-string
                                      (count-lines (point-min) (point-max))))))
                      (concat "%" (number-to-string w) "d")))))
        (width 0))
    (run-hooks 'linum-before-numbering-hook)
    ;; Create an overlay (or reuse an existing one) for each
    ;; line visible in this window, if necessary.
    (while (and (not (eobp)) (<= (point) limit))
      (let* ((offset-line (- line start-line))
             (line-number (if linum-offset offset-line line))
             (str (if fmt
                      (propertize (format fmt line-number) 'face 'linum)
                    (funcall linum-format line-number)))
             (visited (catch 'visited
                        (dolist (o (overlays-in (point) (point)))
                          (when (string= (overlay-get o 'linum-str) str)
                            (unless (memq o linum-overlays)
                              (push o linum-overlays))
                            (setq linum-available (delete o linum-available))
                            (throw 'visited t))))))
        (setq width (max width (length str)))
        (unless visited
          (let ((ov (if (null linum-available)
                        (make-overlay (point) (point))
                      (move-overlay (pop linum-available) (point) (point)))))
            (push ov linum-overlays)
            (overlay-put ov 'before-string
                         (propertize " " 'display `((margin left-margin) ,str)))
            (overlay-put ov 'linum-str str))))
      (forward-line)
      (setq line (1+ line)))
    (set-window-margins win width)))

And then finally, in your .emacs file somewhere, turn on this new setting.

(setq linum-offset t)

There you go, I hope you find it as useful as I have.

I’m sure you’ve all worked that out by now. It’s not actually hard, but it is labourious. And it is hard to do that programmatically for arbitrary time periods.

Compare to the following. Here’s 15kg and 400g of flour. How much flour if you add 2 tons, 67kg and 700g? Much easier right? Also much easier to do programmatically. This is the beauty of the metric system.

So let’s metricise time.

There are only two periods that are fixed in length: the year, and the day. All other divisions can be whatever we want them to be.

So working back from the year and the day, here’s my modest proposal for the metrication of time:

• Each year will be exactly 360 days long. The remaining five days will not be part of a year: instead this gap will become the mid-summer (or winter) festival. Coinciding with what is currently the week between Christmas and New Year’s Day. Any leap days or seconds will be included in this period. Every four years the festival will be six days long.
• The year will be divided into 36 ten day long weeks.
• These weeks can be further collected into all sorts of other periods: 90 days for a quarter — which would be nine weeks — and a month would be 30 days, or three weeks. All very straight forward to convert between.
• And there would still be twelve months in a year.
• Each day would have 10 hours, with 100 minutes per hour and 100 seconds per minute. Which would make the metric second equal 0.864 ‘imperial’ seconds.

And this is where we hit the last remaining, apparently insurmountable, problem of time. The second is an SI unit. And a fundamental one at that.

Changing the definition of a second, especially by that much, would make existing scientific results confusing and misleading to work with.

But this last remaining problem can also be solved easily: use a different name. When weights went metric the ounce and pound weren’t re-named, new names were introduced. SI can retain the current base unit of time as the second, while the metric unit will be known as something else. And as it is so easy to convert between metric units of time, all that needs to be done is convert a metric time into base units, and then convert those to seconds. Ta da!

There will be the small problem of mapping pre-metric dates to metric dates. But I’m sure we can work something out. Perhaps a grand re-labelling?

Ultimately, our current system of sub-dividing time is painfully inconvenient. Do you really think that we’re going to keep it forever? Or, do you think we’ll need a complete societal collapse to replace? I think we can do better than both those options.

There should be credit where credit is due.

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.

“Information wants to be free” is not a position. Information wants to be free in the same way that nature abhors a vacuum. It is simply a statement of the default state of affairs: information that can be reproduced perfectly and cheaply will be reproduced.

WikiLeaks is simply the natural result of a network and technology that has evolved to be really good at that reproduction. To me this means that questions of who owns the information, is government information different from corporate information, and should this affect individuals’ attitudes towards WikiLeaks are all slightly beside the point.

To repeat a tired cliché, the genie is well and truly out of the bottle: the technology to allow massive and anonymous leaks is now here for everyone. These kinds of leaks will only become more common. Irrespective of what happens to WikiLeaks and Julian Assange.

Unless something very draconian and totalitarian is done.

Which is why I don’t bother thinking about whether or not I personally agree with WikiLeaks (though I do), instead I worry about what the end result of attempts to shut it down will look like. That future police state is what we need to fight.