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.

• 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.

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.

• Toys: Languages that were designed by one person to scratch an itch or serve particular purpose, no more. Ruby was designed by Matz for programmer happiness. C was designed by Ritchie so he could port that Space Invaders OS to a different machine than the PDP/10.
• Petrie Dishes: Usually designed in academia as a language to experiment with language design ideas. Haskell was designed to be the canonical lazy, pure functional language. Scala is an experiment in type systems.
• Tools: Designed for serious business, dammit. These are meant to be used to build big important pieces of code. C++ evolved from C for better simulation implementations. Java was an easy to learn language for portable binaries.

Like biology and all other taxonomies, this is of course a flawed generalisation. It’s also incomplete. I know that Perl 5 is a toy, but what’s Perl 6 (apart from vapour)? Is it a tool? Or something else entirely?

Setting aside these issues, I have a personal statement. I want to learn and learn from Petrie Dishes; I want to use Toys for my day to day work and experimentation; I want to stay as far away from Tools as I can manage.

In this conversation most people point out that URL shorteners have proliferated because of the popularity of Twitter. Kottke has now proposed that Twitter run a URL shortener of their own. Which seems eminently sensible, given the current state.

I’ve got a different suggestion: Twitter should actually let me use the <a> anchor tag in my tweets. Just like I’ve been doing in HTML for as long as the web has been around. That is, the URL in your tweet should not contribute to the number of characters in your tweet, and it should also not be visible. Instead it should be attached to a word, phrase or perhaps the entire tweet. This should be optional: without markup URLs pasted into tweets should maintain the status quo.

Of course, no other forms of HTML markup should be supported: linking would be enough. The Twitter web site and desktop and custom phone clients would have no problem rendering a link. Only SMS clients would have a problem, and for these perhaps the fallback is to shorten the URL using Twitter’s own URL shortener and insert that into the tweet. SMS clients may not be that common for much longer.

Assuming Twitter allows specific parts of the tweet to be marked up, then I suggest Markdown syntax for the link. This recent tweet would have been typed out as:

I unplugged every landline phone in our office
because of [marketers](http://sethgodin.typepad.com/seths_blog/2009/04/poisoning-the-well.html) (via @misswired)

Which would have appeared as:

I unplugged every landline phone in our office because of marketers (via @misswired)

Which is what I was actually trying to say.

Of course allowing link markup like this is going to be very popular with spammers. Two counters:

1. Twitter should include rel="nofollow" on links when rendering – as they already do.
2. Don’t allow targeted markup like this, instead allow the entire Tweet to be marked up – only one link per tweet. The disadvantage with this is that sometimes I want more than one link, and the appropriate rendering is not obvious.

Both targeted markup and one-link-per-tweet have advantages and disadvantages, I’ll leave it up to Twitter to choose between them. But please, give me back my <a> anchors.