There’s a few segments of an application’s code that will almost certainly be repeated on both the client and server: views, view state, and data models (excluding data access). To a certain extent, routing could be repeated as well; if you’re not using hashbangs, you’ll need to implement the same named routes on the client and server (although the actions you perform for those routes will be dramatically different).

The solution I’ve put together is still a work in progress, and is more a set of practices and conventions than a library. This flexibility means that while I’ve been implementing the approach using Handlebars, Backbone, and Express, you could theoretically use a completely different set of libraries. In this post, I’ll go over the basic ideas behind my approach; I’ll be putting together a sample implementation on Github that I’ll be able to write about in more detail in the future.

Unifying View Templates

Sharing template code is perhaps the easiest step towards achieving web application unity. With a full-JS stack, you’re compiling the same templates for rendering both server-side and client-side. So why not use the same templates for each?

In my experiments, I’ve been using Handlebars as my templating system. It’s based on the Mustache syntax, but has a number of powerful features, including partials and custom helpers. Handlebars is also the templating system behind Ember.js.

The key to sharing templates is the realization that what constitutes a “partial” can be relative to where the template is used — that is to say, the same template can be used as a full template on the client, and a partial template on the server. My templates are divided into three groups:

• client - client only templates
• shared - used on both the client and server
• server - server only templates

For the client, the templates in the client and shared folders are pre-compiled in a Grunt step, so for all intents and purposes there’s a single flat collection of templates. The server, however, references all of the templates in the shared folder as partials. What’s more, view helpers (in this case, special Handlebars tags) are stored in a shared/helpers directory that is referenced by both the client (in a Grunt step) and the server.

If you’re confused now, you won’t be when you see the actual implementation in my next post. What sounds complicated here is quite straightforward in practice.

Populating View Templates

If it’s easy to share templates on the client and server, getting the right data into those templates is a bit of a harder proposition. Handlebars renders data by running the template against a “context”, which is just a plain old hash. But how can we make sure that the contents of that hash are synchronized when rendering the same view on both the client and server?

The problem is exacerbated with how Backbone muddles view rendering logic. In Backbone, there’s not a fine line between the View logic (in Backbone.View) and Model logic (in Backbone.Model and Backbone.Collection). Backbone Views end up performing view state management by manipulating model instances, in order to avoid bloating Models with View specific code. But adding stateful logic into a Backbone View causes two problems:

1) it makes for larger, more complex views, as concerns are split between UX event management and controlling model state;

2) it makes it harder to share code with the server, as rendering state gets locked in a Backbone view.

We can get around these problems by reconsidering the role of a Backbone View — separating its concerns into that of Mediator and View Model. The Mediator role is one of event manager and template marshal; the view model is, most basically, a state controller.

By splitting the state controller into an object of its own concern, you can extract the logic into a module that can be shared by both the client (via Browserify) and the server (via require). The Backbone Mediator simply invokes the View Model, declaratively calling functions on it as users interact with the app — transitioning Backbone away from its traditional role of MVC framework into more of an MVVM implementation.

A View Model just returns a hash with the current state of data, which is supplied to the template. On the server, a View Model is instantiated with data accessed from the backend; the results of the View Model instance’s toJSON method are passed to the template for rendering. On the client, the same pattern is repeated, but the data is accessed via AJAX instead.

Sharing Models on Client and Server

Synchronizing model code on both the client and server is perhaps the hardest step towards achieving web application unity. The challenge primarily derives from a characteristic of Model code that we’ve inherited from the Rails world: specifically, a conflation of Model concerns between “data model object” and “data access object”. A data model object should identify a model object’s properties, its getters and setters, its relationships, and some convenient accessors; a data access object should deal with querying data sources for populating the data model objects.

Unfortunately, Backbone follows in the tradition of Rails’ ActiveRecord, flattening data accessing and data modeling into a single object. This flattening causes problems even beyond unifying a web application stack. How many Backbone applications have you seen that globally override the sync method, and use properties on model classes to determine how sync invocation works? (Not to pick on Backbone; it’s just the web application framework with which I’m most familiar.)

For now, I’ve abandoned trying to get Backbone Models and Collections to work on both the client and server. But there’s alternatives that can fill the gap nicely. The first of which I’m familiar is Dan Dean’s Tubbs library. Tubbs provides a DSL for defining data model objects, but also provides a pluggable dataStore. A single model module can be defined in a shared folder, and then required on both the client and server, with both supplying their own dataStore.

In order to make the separation between data modeling and data accessing even clearer, and the sharing of model code on the server and client easier, I created by own voltron-model library. While Voltron isn’t ready for primetime (yet), it should make the unified definition of data models significantly easier.

Whichever modeling library is chosen, the basic approach should be the same: data models are defined in a shared folder. These models are then imported by code on the server (or packaged with Browserify for the client). The server and client should decorate the models appropriately (either by adding to the model’s prototype or adding an accessor component). Thus, a model can be made to access Mongo or Postgres on the backend, or a REST service on the client.

The benefit of using Backbone on the client is that it doesn’t care if you only use limited parts of the library. Arrays of event-emitting models can provide much of the same benefit of Backbone Collections and Models, and Backbone Views and Routers see no difference.

Wrapping Up

All this discussion may be a bit confusing without a concrete implementation to reference; hopefully, I’ll be able to put together a sample application in the next few weeks. But the basic takeaway of the post is that unification of JS web applications can be made significantly easier with two factors:

• structuring your code so that it can be required by the server or packaged for the client in the same ways, whether by ingesting templates as partials or packaging code with Browserify;

• following the Node.js approach of writing small, single-purpose modules means that there’s less boilerplate to prevent you from using code in multiple environments

I want to write about the current “Holy Grail” of web application development: a unified application stack. Any dev who’s built a thick-client web app (regardless of library - Ember, Backbone, this problem is independent of tool choice) has dealt with the frustration of recreating logic in multiple parts of the application stack. It’s incredibly annoying to be writing the same code to handle model accessors, view state, and rendering logic in two different places; it’s even more irksome to be fixing bugs in one or both areas as your application matures. But let’s back up a bit. Why do we need to be writing the same logic in multiple places at all?

Generally speaking, modern web app development requires a choice from one of three architectural thrusts:

• thick server, thin client: view logic is written on the server, and rendering happens there as well. The client code deals with interactivity and AJAX requests, but is mostly just updating areas of the page with rendered view content returned by the server. This approach is most famously advocated for by 37 Signals. A thick server simplifies view code, but does so at the expense of larger AJAX payloads; why pull fully rendered code when you can just pull JSON data and render it with a client-side template?

• thick client, thin server: This architecture inverts the first approach; the server provides an API, which is basically just a wrapper around data access and caching. All of the app logic resides in the client. This approach can make for quick interactivity and rendering on the client, but presents a massive problem with “first load” delay, as the client needs to make two connections to the server: the first to load the client application code, and the second to pull the appropriate data to render. You may remember this problem from Old New Twitter.

• thick client, thick server: Unsurprisingly, this approach combines both of the previous options. Views are rendered on the server, which means the initial load is fast, but the client handles all the rendering from that point forward. The good news is that you have two fairly independent, (hopefully) highly performant application structures; the bad news is that you’re now repeating logic in view templates, view states, model helpers, even route handlers.

One exciting prospect of Node.js is that it makes Javascript an “isomorphic language”, which is to say that “any given line of code (with notable exceptions) can execute both on the client and the server” (h/t Nodejitsu). But that said, there haven’t been very compelling demonstrations that solve the code-duplication problem.

In the last few months, I’ve come up with a solution that allows for code reuse on client and server, leading to a unified codebase for handling view rendering, view states, and model interaction. It’s using components and libraries that you already know: Browserify, Backbone, Express, and Handlebars. But I’m going to hold off on describing that solution for now, and instead write about Rendr.

Rendr is the result of Airbnb’s first Node app, and it’s also the library that finally prompted me to close Vim and start writing here again. It’s the fulfillment of an idea that I first heard about from Tim Branyen: what if we used Express to render the same Backbone Views that we render on the client? That question is what prompted me on my own path towards application stack unity, so I’ve been very eager to learn more about Rendr.

Rendr took Tim Branyen’s initial idea and made it a reality. It’s important to note that Airbnb’s experiments here weren’t an excuse for architecture aeronautics; rather, they were expressly concerned with solving the “time to content” problem, which is to say, the rendering delay that Twitter famously faced. And by unifying client and server code, Rendr not only makes developers’ lives easier, it solves that time to content problem.

Rendr has a number of features and design approaches that I very much like:

• it’s described as “a library, not a framework”

• it doesn’t create a server side DOM

• it doesn’t try to collapse backend data access into the client tier, as some other frameworks have done

• it utilizes existing, familiar code (Express and Backbone)

• it keeps the rendered DOM on first load and attaches client objects to it, rather than instantiating client views and replacing the DOM with the results of those client views.

This last item is particularly important: rendering a page on the server, sending it to the client, and then recreating the DOM on the client can lead to odd rendering issues, interactivity problems, and problems with event listeners. But dynamically instantiating client objects and attaching them to an already-rendered DOM is not a trivial problem, and I commend Spike Brehm and the rest of the Airbnb team for taking the time to get this right.

You should definitely take the time to explore Rendr’s codebase. If it existed when I first set out to solve this same set of problems last year, then I probably would’ve abandoned my own quest and just used this library. But the key point of differentiation with the approach I took from Rendr’s design is modularity. Is it possible to achieve application stack unity, while using objects and code that can be implemented with any number of frameworks in any number of ways?

Stay tuned.

This post has nothing to do with that argument.

If you’re coding in Javascript, you’re going to be using callbacks, and if you’re building a library, you’re going to be supporting callbacks. It’s the reality of the ecosystem. But there are certain problems for which some syntactic sugar is helpful. Promises provide a wrapper for callbacks that allow for a chainable API around a sequence of continuations. They’re not a native part of the language, but there’s a strawman for the inclusion of Promises in a future version of JS. In the meantime, you can use the excellent Q Library from Kris Kowal. jQuery includes its own Promises implementation ($.ajax calls return Promises), but they’re slightly divergent from the Q spec. You can read this excellent guide explaining the differences between jQuery and Q promises, if you’re coming from one direction or the other.

So much for introductions. I’ve been using promises for awhile now in some of my Node code, and there’s several cases where their inclusion can clean up an API. (One area: Mongo integration, where any simple action can require several callbacks.) One benefit of Promises is that they can provide exception isolation, just like continuation-passing. The Q wiki provides the following example:

1
2
3
4
5
6
7

var info, processed;
try {
  info = JSON.parse(json);
  processed = process(info);
} catch (exception) {
  console.log("Information JSON malformed.");
}

In the above snippet, errors generated from the parser and the process function arne’t isolated. Promises, meanwhile, offer this exception isolation out of the box:

1
2
3
4
5
6
7
8

var processed = Q.call(function (json) {
  return JSON.parse(json);
})
.then(function (info) {
  return process(info);
}, function (exception) {
  console.log("Information JSON malformed.");
})

In the second example, the process function is only executed if JSON.parse doesn’t throw an error. Conversely, this same goal could be achieved with continuation-passing:

1
2
3
4
5
6
7
8
9

var processFn = function(cb) {
  asyncJSONParser(json, function(err, info) {
    if (err) {
      console.log("Information JSON malformed.");
      return cb(err);
    }
    cb(null, process(info));
  });
};

One caveat is that when you’re chaining your promises together, the behavior is slightly different than you might expect:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

var existingUser;
var promise = User.findOne({username: username})
  .then(function (user) {
    if (!user) {
      throw new Error("Username is incorrect");
    }
    existingUser = user;
    return User._hashPassword(password, user.get('salt'));
    }, function(error) {
      console.error('error in findOne');
      throw error;
  })
  .then(function (hashedPassword) {
    if (existingUser.get('hashedPassword') === hashedPassword) {
      return existingUser;
    } else {
      throw new Error("Password is incorrect");
    }
  }, function(error) {
    console.error('error in _hashPassword');
    throw error;
  });

In the above example, if there is an error in User.findOne, the error is propagated throughout the chain, which means that your console will have both error in findOne and error in _hashPassword printed. There’s no way of “breaking” from the promise chain early. But here’s the thing: you don’t have to. Unless you’re interested in transforming error objects, there’s not much point in catching promise errors in intermediary steps in the chain. So the above code would be abbreviated:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

var promise = User.findOne({username: username})
  .then(function (user) {
    if (!user) {
      throw new Error("Username is incorrect");
    }
    existingUser = user;
    return User._hashPassword(password, user.get('salt'));
  })
  .then(function (hashedPassword) {
    if (existingUser.get('hashedPassword') === hashedPassword) {
      return existingUser;
    } else {
      throw new Error("Password is incorrect");
    }
  });

//later in chain or in a diffent function
promise.then(function (eventualResult) {
    //do something with result
  }, function (error) {
    //handle error
  });
}

There’s simply no point to having then failure handlers that just throw an error, since the library throws and propagates errors for you automatically. In promise chains, then, you have the benefit of isolating exceptions (only proceeding from step to step if everything is ok) without the extra semantics of if (err) return cb(err) from continuation passing.

Before you skip below to yell at me in the comments section, I don’t mean that the idea of client-side unit testing is crazy. On the contrary: we need client-side tests more than ever! With ever-increasing complexity in our frontend code, not to mention the reliance on frameworks, building a web application without client-side tests is completely inadvisible.

But the process. Ohhhh, the process of client-side testing is bonkers.

Let’s take the example of a modern Node.js web app setup. I’ve got the app’s configuration wired with grunt.js. (If you’re not using grunt, you should be!) During development, server files are watched for changes and automatically kickoff mocha tests, which display their results in the grunt console. Great!

Client-side changes kickoff their own unit tests, which of course are also using mocha for consitency in testing vocabulary. But because of the nature of client-side testing, we can’t just call require on the unit under test. Instead, we need something like the following setup:

• requirejs for managing dependencies

• PhantomJS for running a headless browser

• grunt-mocha, which manages the PhantomJS process and reports test results to the grunt console

• an HTML fixture for loading the requirejs config, the browser environment, and test files

This setup worked. It also felt downright medieval compared to the simple server-side mocha testing configuration.

I’m not the only person who’s frustrated with this process. Chris Dickinson at Urban Airship recently released Drive.js, a unit testing framework and test driver that eases some of the above configuration. But in any of the setups I’ve seen, your client-side “unit” tests feel much more like integration tests. If you need to load your entire client-side framework, load a headless browser, or even fire up an instance of your server to test a single function of your client-side code… why not just ignore client-side unit testing and skip straight to integration tests? The lack of true isolation of the system under test could lead to some frustrating false results anyway.

There needs to be a better way. I’m not looking for a lot in my testing setup:

• I want to run my client-side tests with the same mocha vocabulary and configuration as my server tests

• I want to isolate my tests to requiring a single file and its immediate dependencies, and testing it

That’s really it. And I think I’ve found a solution.

First, I’ve needed to refactor my client-side code to follow the CommonJS requires model. I’ve also switched to browserify from requirejs, although this switch is no longer a necessity — requirejs has introduced a new configuration option, cjsTranslate, which will wrap CommonJS defined modules. Using the CommonJS approach means that my mocha tests can require my client-side files. Great.

But the much larger problem with client-side testing is those pesky browser globals: the windowobject, the DOM itself, not to mention global code like jQuery, Backbone, etc. How can we test code that relies on the presence of those globals, without resorting to running PhantomJS?

The answer comes in two parts: jsdom, and the Node.js vm module.

jsdom provides a server-side implementation of the DOM, while the vm module provides the “global” object that we can use to provide a fake browser environment to our client-side files. While I’m still fleshing out the implementation, the results so far have drastically improved my ease with client-side testing.

Here’s how it works. In a mocha test file, instead of a strict require call, I’m using a helper (passing this, the mocha test context):

1

setupClientScript.call(this, "admin/postEdit", done);

setupClientScript loads a jsdom window, injects global javascripts (like jQuery), and wires the client-side file being tested. Here it looks in a slightly simplified form:

1
2
3
4
5
6
7
8
9
10
11
12
13

var setupClientScript = function(path, done) {
  var relPath = context.clientRoot + path;
  var self = this;
  jsdom.env({
    html: '<html><head></head><body></body></html>',
    src: context.globalScripts,
    done: function(errors, window) {
    self.clientRequires = requireClientScript(relPath, window, {});
    self.clientRequires[path] = self.clientRequires[relPath];
      done();
    }
  });
};

Remember, the client-side require can’t just inject the DOM into the file under test, it also needs to make sure the file’s dependencies have access to the DOM:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

var requireClientScript = function(path, window, r) {
  var script = fs.readFileSync(require.resolve(path)).toString();
  var module = { exports: {} };
  var context = vm.createContext(global);

  context.window = window;
  context.exports = module.exports;
  context.module = module;
  context.require = function(path) {
    r[path] = requireClientScript(path, window);
    return r[path];
  };
  vm.runInNewContext(script, context);

  if (r) {
    r[path] = module.exports;
    r.window = window;
    return r;
  } else {
    return module.exports;
  }
};

And that’s it. Now, any test function can call this.clientRequires to have access to the client-side file under test. No test server being spun up. No complex configuration or requirejs rewiring. No full-on headless browsers like PhantomJS. Just a single before setup call, and you can test with mocha as you normally would.

As I wrote above, I’m still fleshing out the implementation, working out the interface and fixing deficiencies. I’ll be publishing the code when things are more mature, but in the meantime I’d love to hear some feedback.

As the event grew closer, my curiosity about what NodeConf would entail heightened. Mikeal didn’t divulge a clue as to the event’s schedule, and even perusing the twitter feeds of probable speakers and NodeConf’s site on lanyard didn’t reveal any helpful intelligence. At the opening party on Sunday, a general sense of cautious curiosity permeated the crowd. No one had ever attended a conference where the schedule would be revealed in realtime (appropriately for Node); my own conference inexperience left me more curious than most.

Mikeal had revealed two details: the major themes of each day of the conference. Day 1 was structured around the world of Node; Day 2 around the power of Node. NodeConf began with Node creator Ryan Dahl reconstructing the origins of the framework from livejournal entries and blurry photos of late night coding session in Germany. But as the day continued, I couldn’t see how the talks related to each other, or what I should be taking away from them. Each of the presentations, while excellent and often inspiring, didn’t leave me with a consistent narrative. I had expected “the world of Node” to consist mostly of talks like Isaac Schlueter’s “State of Node” presentation: perhaps a roundup of the big open source projects and frameworks that dominate the Node ecosystem, and a discussion of where they were headed. Instead, talks covered everything from realtime solutions with socket.io, to the creation of a whole new language. I had started the first day of NodeConf curious, but ended it confused.

Day Two changed all that.

As one talk on the “power of Node” led into the next, the topics and structure of the first day of NodeConf started to make sense to me. Each speaker demonstrated amazing new contributions to the Node ecosystem, from the Node-inspired Luvit framework built with Lua, to bleeding edge debugging tooling with dtrace, to ridiculous hardware demonstrations featuring human-detecting arduinos, three-dimensional saws, and radar laser robots controlled by Javascript. These talks didn’t just demonstrate powerful and frequently unexpected uses of Node: they helped me make sense of the previous day’s selection of talks.

Node is not just the Node framework: it’s a philosophy, an approach to solving problems. The first inkling of “Node as philosophy” came in substack’s post on Node’s aesthetic, discussing the “limited surface area” approach to Node’s modular problem-solving. But NodeConf demonstrated that the node philosophy goes much further than that:

1. async all of the things: Ryan’s initial work with libuv focused on the challenges of creating an async IO layer that worked across platforms, but that work has been extended with new languages like Fedor Indutny’s Candor and Tim Caswell’s Luvit framework. But it’s not just file IO - Max Ogden showed that the importance of a beautiful async API could be extended to browsers (utilizing ideas put forth by substack in day one), while Rick Waldron brilliantly demonstrated how JavaScript’s async nature could be used to solve problems which had always been approached synchronously. (Like robots. With lasers.)

2. embrace the hard problems: JavaScript may frequently be maligned for its odd “bad parts”, and JS developers have been looked down on in the past because of the history of DOM based spaghetti code, but NodeConf 2012 demonstrated a community that was unabashed in its tackling of serious computing issues. From Felix Geisendorfer’s’s writing of a binary MySQL parser that surpassed a c library in performance, to the community’s embracing of the concept of IO streams, to the use of dtrace in debugging: Node developers on the bleeding edge are not shying away from the toughest technical problems, but instead are taking them on at full speed and with high expectations.

3. a virtuous cycle of framework and community: Node’s “limited surface area” design of the core framework, along with the ease of use of NPM for publishing open source code and small useful modules, have led to an explosion of code. At NodeConf 2011, around 1800 packages had been published to NPM; now there are over 12000! Modules range from steaming cups of earl grey, to karaoke bar APIs, to websocket adapters and arduino libraries. The design of the framework drove its community adoption, but the community adoption has further developed the framework.

In the last talk of day two, Elijah Insua discussed the hardware hacking he’d done with Node. At one point, he mentioned that he came up with an idea that needed a midi driver, and he said something along the lines of: he never expected needing a midi driver, but as soon as he needed one, he came across one on NPM. The word that came to mind was serendipity: the contributions to Node, and the explorations of its philosophy, are feeding on themselves and driving completely unexpected innovation.

As I thought of the serendipitous nature of the Node ecosystem, Mikeal’s construction of NodeConf finally clicked for me. The two days of talks had been divided into groups of four presentations around a single theme; neither the themes nor the talks were made public, but each talk and theme bled into the next, with later speakers surprisingly stating how happy they were that a previous speaker had touched on a similar topic. The talks seemed to develop naturally, if unexpectedly; the overall direction was unclear to everyone except Mikeal, and gave the impression of the community simply exploring new ideas and pushing boundaries organically. The serendipity of Node’s development, then, found itself reflected in Mikeal’s construction of the conference. Does this sound ridiculously meta? Yes, but it completely worked.

As Node grows up and attracts adoption, it will be increasingly difficult to maintain the philosophically-driven, community-minded hacker ethos of the Node ecosystem, but I hope that Mikeal and the other stewards of the Node community can continue to foster talks and events that focus on the behind-the-scenes developers who are laying the building blocks for the future of this fascinating set of technologies.

• installing Homebrew
• installing iTerm2
• brew install git, macvim, tmux, tmuxinator, whatever langs and dbs you need
• pulling down your .dotfiles
• installing and syncing your Dropbox

I was developing on my new machine the day it arrived.

That experience of provisioning a machine so easily, and getting productive with it in no time at all, left me reconsidiering my original post on my toolset, which primarily boils down to zsh, tmux, and Vim. There’s plenty of material online to learn about these tools; a few of note are:

• The Text Triumvirate
• Unix as IDE
• Coming Home to Vim
• A Tmux Crash Course
• Dotfile Discovery
• Beautiful Tools

So why should you adopt tools with such a steep learning curve? Most discussions of IDEs and development environments quickly devolve into pointless arguments over the superiority of one tool over another, when in most cases the tool isn’t the most important factor; differences in productivity will more frequently boil down to experience and mastery of a toolset, rather than the toolset itself. I’ve seen masters of Vim, Eclipse, IntelliJ, and Textmate; in every case, the interface breaks down and gets out of the way of the user, who always “does” without any thought as to “how to do”.

So if mastery is more important than toolset, does your choice really matter?

Yes.

There’s two huge benefits of the Vim/tmux/shell toolset: ubiquity, and permanence.

Mastery of a tool takes many, many, many hours:

“Malcolm Gladwell’s observation that it takes 10,000 hours to become truly expert at something.” A little more than 3 years typically

— Jeff Atwood (@codinghorror) December 19, 2008

So whatever tool you choose, you want to be able to use it as much of the time as possible, in as many environments as possible.

A mastery of Eclipse, for example, doesn’t help you when you need to ssh into a unix environment (but vi/m would). Knowing Visual Studio inside and out can’t help you if you need to work on a Max or Linux box (but gvim and cygwin will still work on Windows). There’s not a lot that can compete with Vim in the ubiquity category; Emacs is the only other tool that comes to mind.

Permanence is a whole other matter. Technology changes constantly; some tools are improved, others are abandoned, still others fall out of use entirely. Are you a Flex developer who spent spent huge amounts of time mastering FlexBuilder and Eclipse? Out of luck now. Textmate? The tool that influenced countless developers to leave the Windows ecosystem eventually became pseudo-abandonware, leading to the current growth of tools liks Sublime Text 2.

Vim has been around since 1991. Its progenitor vi was written in 1976. (Again, Emacs is the only competitor here, having also been written in 1976.)

All of this is to say: don’t go and abandon your current toolset for mine! Just because what I use works for me, doesn’t mean it’s the best choice for you. If you’ve already mastered your toolset and are happy with it, stay there: you’d be wasting many productive hours on a new tool for the potential of hating it. And as wonderful as Vim/tmux/shell are for most, it’s not the right toolset for everyone or everything. If you’re doing mostly front-end web UX work, for example, Coda 2 would probably be perfect for your needs; iOS means you’re going to be stuck with Xcode, for better or worse.

But if you’re feeling constrained by your current toolset, or are making the jump from one technology to another, and haven’t given “the text triumvirate” a try, I’d very strongly recommend doing so. It’s worth the effort.

Portland has lived up to, and perhaps exceeded, our expectations. Being able to bike around a city without a constant fear of death and dismemberment has been quite a refreshing change. Living in a house has allowed us to actually grow a legitimate garden instead of stuffing a few pots in a fire escape. We couldn’t be happier with the food scene here; the amount of craft beer in Portland is downright intimidating. And it’s been extraordinarily exciting to meet so many other new Portlanders who’ve moved here for similar reasons. Needless to say, if you’re a developer who’s thinking about Portland as a place to call home, feel free to drop me a line, or introduce yourself if you’ll be coming to node conf in July.

I’ve finally had to declare blog bankruptcy here, in order to just wipe the list of well-intentioned-blog-topics clear and get started writing again. Two topics will survive the culling. First, the move to Portland presented an opportunity for a spring cleaning of my development environment. I’ll be writing about how I organized my dotfiles, and explaining why tmux is not just a cargo culting fad, but a ridiculously awesome tool for maximizing your terminal productivity.

The other surviving topic surrounds Backbone.js. Since moving to Portland, I’ve continued working with Bloomberg Sports in New York on their application for MLB team analytics. (Think a modern web app version of Moneyball spreadsheets.) Working on such a large app has presented me with some difficult lessons on how to best use Backbone, especially for interacting with a polyglot backend, which I think would prove useful to any other web devs working on larger Backbone applications.

So now, back to work so I can actually get these posts written in the next week!

The first few months of living in New York definitely delivered on the “challenging” part of our expectations; not a day went by that didn’t evoke memories of Seinfeld plot-lines. Crazy co-op boards? Difficult supers? Ridiculous encounters on the subway? More than one New York stereotype proved its roots in authenticity. But as we grew used to the city and its neighborhoods, learned how to quickly cut from one area to another, discovered which subway lines consistently failed, and realized that one should avoid 5th Ave and Times Square at all costs, the challenges started to dissipate and left only excitement. New York, in its intensity and genuine melting pot of cultures and backgrounds, presents an amazing opportunity for people to define themselves. What matters most to you, and why does it matter? In a city where practically any hobby or interest can be pursued, you’ve got to seriously prioritize your time, and that prioritization goes a long way towards identifying exactly who you are.

But for all the excitement and growth, I started to notice another development in myself: pernicious cynicism. While I had once dreamed of tackling big problems and making the world a better place, years of living in DC and New York made me view such ideas as hopelessly naive. The seeming intractability of so many daily problems, the realization that apparently important movements were actually driven by petty motivations; older, wiser me didn’t look at idealists with disdain, but rather with a wistful admiration of their blissful ignorance.

Then I spent time in Portland, OR.

It’s hard to describe the feeling of Portland. And I don’t mean the city portrayed on Portlandia - although that show is certainly accurate in its skewering. I have never been to a place where so many people devote themselves to mastering a craft, not just because of the rewards of the mastery, but because not mastering that craft is simply not an option. There’s an entrepreneurial spirit that pervades Portland, but it’s one that’s devoted to developing new ideas and contributing back to the community. Even this “return to community” is not the traditional “I’ve done well so I’m giving back” idea, but rather a networked entrepreneurship, a continuous exploration of “How can my idea involve the unique work of that awesome ?”

Mikeal Rogers, organizer of NodeConf, described Portland with admiration:

There are times and places, great cities, that are remembered much more
fondly than they were thought of at the time. Paris in the twenties when it
was home to Hemingway, Picaso and Fitzgerald. Or San Francisco in the 50s
when the beat generation migrated from New York to call it home. So
impressionable were those years that the echo fuels future, lesser,
generations for decades.

When you're in Portland, Oregon you can't help but think it might be such
a place and the time. For what it will be remembered I have no idea, but
everyone seems to be bursting with creativity and no one is content until
they have done more.

Spending time in Portland pierced the shell of cynicism that I’d developed, and rekindled my motivations to build something real and lasting, to improve my community. Portland provides the inspiration; New York has provided the confidence and skillset to do something about it.

So once again Meaghin and I find ourselves surrounded by boxes and preparing for a big move. In a month I’ll be a resident of Portland. I can’t wait to find out what the future will bring.

For even more insight into the developing world of “JavaScript everywhere”, check out this video from Joe McCann, principal architect of subPrint Interactive, on “End to End JavaScript”.

• An Object is not (Always) a Hash — Great post from Guillermo Rauch about the perils of using Javascript Objects as Hashes. Definitely some tricky gotchas here that you may not have thought about.

• Hot Node Reloading — Also from Guillermo, a solution to the annoying problem of continuously restarting your node app during development: Staying Up with Node.JS

• Shedding Light on SPDY — If you haven’t been hearing a great deal about SPDY lately, you will be soon. SPDY, if you couldn’t tell from the name, serves as a next-generation protocol to speed up web communication. Nodejitsu posts a helpful introduction to SPDY.

• Improving your Git Logs — Git log, out of the box, is so wordy that it proves fairly worthless. Check out Oli Studholme’s aliases for taming the git log beast.

• Hack Learning — One of the key lessons I’ve learned as a developer is that getting good at something requires hours, and hours, and hours, and hours of work, and many of these hours will be exhausting displays of ignorance which you’ll want to quickly forget. The good news is that you can pick up nearly any skill with enough effort and time. Jack Kinsella provides a hack for cutting back on how many hours separate “terrible newb” from “fairly competent practitioner”. His Janki Method may sound like a get rich quick scheme, but it’s really just a simple approach to improving your effiency at learning. Maybe you can cut those 10,000 hours of practice to a more managable… 6,000.

Meaghin has more pictures and a full rundown of our 2011 coffee purchases, but I wanted to highlight a few bags in particular.

Wrecking Ball Coffee Roasters is a new enterprise from Trish Rothgeb and Nick Cho; I was lucky enough to get one of the first bags they shipped this year. Their coffee presented a perfect example of what makes me love Ethiopian coffees, offering a pleasantly light body without being too acidic. I like to compare good east African coffees to pinot noir - almost all have a juiciness to them, but the best are balanced with strong bass notes. I loved Wrecking Ball’s fully biodegradable package. But beyond the coffee itself, I was happy to order from Wrecking Ball because of Nick Cho. Cho used to run the amazing Murky Coffee in Arlington, VA, which I visited very frequently when I lived in the DC area. Ironically, I didn’t drink much coffee at the time, having been exposed to some swill in college. But Murky is what enticed me to learn more: the intoxicating smell of freshly ground Counter Culture coffee, the precise movements of the baristas as they brewed espressos, the clear passion of everyone involved. Drinking the Wrecking Ball made me feel as if I were making up for the coffee I never enjoyed at Murky.

If Murky induced my coffee passion, Coava revealed the heights to which this passion could be taken. I drank Coava’s David Mancia from Honduras early in the year; later, I would visit Coava’s Portland shop in person. The David Mancia completely blew my mind. Even in my early days of home-brewing, I couldn’t screw this coffee up: chocalate, berries, an amazing finish, thick and juicy and succulent. I couldn’t wait to see how Coava’s shop measured up to the coffee they roasted, and found one of my favorite coffee shops in the country. I can’t wait to go back.

One of the highlights of 2011 was my trip to Copenhagen with Meaghin. Before the trip, I greatly anticipated experiencing Danish culture, perhaps most intrigued by their coffee culture. Almost everywhere we bought coffee in Copenhagen, we felt pleased with the product, but Coffee Collective is an entity unto itself. We visited their new location in Torvehallerne, a glorious outdoor food market, a few times, trying various coffee drinks on each visit; the Kieni from Nyeri, Kenya proved particularly delicious.

Two weeks into 2012 and as many bags brewed; I’m currently finishing up a great roast from Cafe Grumpy, from Finca La Coqueta in Columbia. I look forward to finding out what my favorites will be this year.

The more important change relates to the testing syntax. In some conversations I had online with Graeme Foster, I realized that the vows-bdd syntax left some room for improvement. Specifically, the syntax introduced a potential for redundancy when creating labels for integration tests. While named functions could be used for test statements that were repeated, there wasn’t an easy to way to handle repeated labels.

In order to make the use of test helpers even easier with vows-bdd, I have adjusted the given/when/then/and syntax to allow for array arguments in addition to the previous arguments of label,test_function. It’s easiest to demonstrate the change with an example. One area of code that frequently is repeated is login code in integration tests. Here’s how I had my tests setup with vows-bdd before:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# a test snippet

  .given "I am an admin user", ->
    @user = Model.Factory.create "user", {role: 'admin'}
    @callback()
    return

  .when "I go to login", ->
    zombie.visit Server.path_for("/login"), @callback

  .when "I click login", (browser,status) ->
    browser.fill("email", "#{@user.email}")
           .fill("password", "#{@user.password}")
           .pressButton "Login", @callback

  .then "I should be on the admin index", (err,browser,status) ->
    Test.assert.shouldBeOn browser, "/admin"

# snippet from another test

  .given "I am an admin user", >
    @password = "foo"
    @user = Model.Factory.build( "user", password: @password, passwordConf: @password, role: "admin" )
    @user.save @callback

  .when "I am logged in", >
    user = @user
    cb = @callback
    pw = @password
    zombie.visit Server.path_for("/login"), (e,browser,status) >
      browser.fill "email", user.email
      browser.fill "password", pw
      browser.pressButton "Login", cb
    return

Even with the previous syntax, this code could be improved by creating a named login function that handles the duplicated code. And you could add a property to that function that provides a label. But I felt that the vows-bdd syntax should be improved to make this code repetition even easier. So the new [label,function] syntax looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# first test

  .scenario("'/admin' is accessible to logged in admin users")

  .when(I.login_as "an admin")

  .then "I should be on the admin index", (err,browser,status) ->
    Test.assert.shouldBeOn browser, "/admin"

# other test

  .scenario("Logging Out")

  .given(I.login_as "an admin")

  .when "I click logout", (browser,status) ->
    browser.pressButton "Logout", @callback

  .then "I should be redirected to the login page", (err,browser,status) ->
    #continues

The login_as function is included in a helper file:

1
2
3
4
5
6
7
8
9
10
11

exports.login_as = (type_of_user) ->
  label = "I login as #{type_of_user}"
  fixture = () ->
    cb = @callback
    @user = user = Model.Factory.create type_of_user.match(/a[n]? (\w+)/)[1]
    zombie.visit Server.path_for("/login"), (err,browser,status) ->
      browser.fill("email", "#{user.email}")
             .fill("password", "#{user.password}")
             .pressButton "Login", cb
    return
  return [label,fixture]

Note that the function returns an array of arguments to be supplied to the vows-bdd method. Also note that the fixture method is using this — which will point to the vows context when the test is evaluated — and that the fixture returns undefined to indicate to vows that the test should be performed asynchronously.

I think this new syntax works really perfectly for integration tests; it goes a long way to supporting declarative testing style.

As always, please let me know if you run into any problems with the library or have any suggestions!

• A scaffold for your node - scaffoldit is a customizable scaffold generator for your nodejs projects. I don’t think that there’s that much boilerplate for express based apps, but this library is still pretty helpful for getting my tests and basic app configured quickly.

• Basic metaprogramming in Ruby - If you’re new to Ruby and are confused by some of the metaprogramming enabled by methods like repond_to? and method_missing, check out this helpful post from the Intridea blog.

• Build first, talk later - Spencer Fry, founder of Carbonmade, offers some fine advice to show don’t tell - a prototype is worth ten thousand words. I particularly like his observation that “The best thinking about your product will come from actually building it.”

• Productivity geekery - Brett Terpstra reviews the mother-of-all-menubar-apps, Dropzone. I haven’t bought it yet myself, but I’m pretty close to pulling the trigger.

• Writing your readme - Awhile back, nodejitsu offered some solid advice on setting up your node project’s package.json file. Now they’re back with some more great advice, but this time it’s more universal: how to write a helpful readme for your next open source project.

• After reading Umair Haque’s excellent New Capitalist Manifesto, I’ve been thinking a great deal about the values of sustainability in business and how value cycles drastically improve upon value chains. I was excited to see Fred Wilson explore the same issues on his blog:

sustainability is all about figuring out how to be in business forever. It is about business models that are win/win and lead to happy long term customer and supplier relationships. It is about avoiding the temptation to overeach. It is about avoiding the temptation to mazimize near term profits at the expense of long term health. It is about adapting the business to changing market dynamics. It is about building a team and a culture that can survive the loss of the leader and keep going. And it is about many more things like this.

Even though I’ve used git for awhile, I still need to look up the best way of performing a task every now and then. One trick that comes in handy is editing existing commits. git --amend allows for adding new files or changes to a previous commit, but you can have even more control than that – changing any pre-pushed commit in your history.

Just get the hash of the commit you want to change. With a simple git rebase <commit>^ --interactive, you can then make any changes you want. For each file, just type git add <file>. When you’re done, git commit --amend and git rebase --continue will finish up your editing.

It’s always useful to review and cleanup your commit history before pushing your changes upstream or issuing a pull request. With the ability to revisit any previous commit, you can be more comfortable in a ‘commit-all-the-time’ workflow.

1
2
3
4
5
6

exports.add = function(a,b) {
  return a+b;
}
exports.subtract = function(a,b) {
  return a-b;
}

1
2

var add = require('foo').add;
console.log(add(1,2)); // 3

If your functions are free of side effects, you’re not exactly committing a serious coding sin. But go beyond the simple example above – starting to pass around whole objects, or breaking the law of demeter – and soon your code doesn’t feel right.

I quickly ran into this problem with my vows tests. As I was about to merge a feature branch to master, I reviewed my code and was a bit horrified at what I saw in my tests:

1
2
3
4
5
6
7

{cleanupDB} = require "../helpers"
{vows,server} = require "vows"
mongoose = require "mongoose"
User = mongoose.model "User"
assert = require "assert"
Sinon = require "sinon"
{Factory} = require "../helpers"

And this was just one of my tests. Yikes. Lots of bad things going on here:

• My test has a dependency on my model implementation, and not just the model itself; if I switch the model off mongoose in the future, my test itself will need to change.
• My test has a dependency on a particulra spying/mocking framework (Sinon)
• There’s a lot of confusing imports; why is server required off of vows?
• Repeating requires - one for cleanupDB and one for Factory.

Bad bad bad.

My tests needed to be refactored to deal with this madness. I realized that there was repeated code throughout my vows tests; not only could I clean things up with some proper encapsulation, I could DRY my vows as well.

One cool feature of node is that if you include an index file in a directory, that file is loaded when you require the directory. So I created a new spec/helpers directory, and placed an index file inside.

1
2
3
4
5
6

process.env.NODE_ENV = 'test'

module.exports =
  Server:  require "#{__dirname}/server_helpers"
  Test:  require "#{__dirname}/test_helpers"
  Model:  require "#{__dirname}/model_helpers"

And each of these helper files now encapsulates logic and functionality that I use across my tests:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

http = require "http"

exports.port = port = 3003
server = (require "#{__dirname}/../../app")
server.ready = (callback) ->
  if @active
    process.nextTick callback
  else
    @active = true
    server.listen port, (err,result) ->
      process.nextTick callback
  return

process.on "exit", ->
  if @active then server.close()

wait = ->
  if !@active
    process.nextTick wait
  else
    return

server.ready wait

makeRequest = (url,params,method,callback) ->
  params ||= ""
  encoding = 'utf-8'
  server.ready ->
    request = http.request
      host: "127.0.0.1"
      port: "#{port}"
      path: url
      method: "#{method}"
      headers:
        'content-type': "application/x-www-form-urlencoded"
        'content-length': params.length

    request.on 'response', (response) ->
      response.body = ''
      response.setEncoding encoding
      response.on 'data', (chunk) ->
        response.body += chunk
      response.on 'end', ->
        callback null, response
    if params
      request.write params
    request.end()


exports.server = server

exports.get = (url,params,callback) ->
  if arguments.length == 2
    callback = arguments[1]
    params = null
  makeRequest url,params,"GET",callback

exports.post = (url,params,callback) ->
  makeRequest url,params,"POST",callback

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

Sinon = require "sinon"
assert = require "assert"
http = require "http"
Model = require "./model_helpers"

exports.spy = (object,method) ->
  Sinon.spy object, method

exports.stub = (object, method, fn) ->
  Sinon.stub object, method, fn

exports.spyRender = ->
  @response = http.ServerResponse.prototype
  Sinon.spy @response, "render"

exports.spyModel = (klass,method) ->
  Sinon.spy (Model.getType klass), method

exports.assert = assert

1
2
3
4
5
6
7
8
9
10
11

mongoose = require "mongoose"
cleaner = new (require "database-cleaner")("mongodb")

exports.cleanupDB = ->
  mongo = mongoose.connection.db
  cleaner.clean mongo

exports.Factory = (require "#{__dirname}/factories").Factory

exports.getType = (Klass) ->
  mongoose.model Klass

My test logic dependencies are clean and encapsulated, making for both clearer requires blocks and clearer tests themselves.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{Model,Test,Server} = require "../helpers"
vows = require 'vows'
User = Model.getType "User"

#code removed for brevity

  .addBatch
    "Hashes password:":
      "when a new user is created":
        topic: ->
          @user = Model.Factory.build "User"
          Test.spy User, "makeSalt"
          Test.spy User, "hashPassword"
          @user.save @callback
          return

        "it creates a salt and stores it": (err,user) ->
          Test.assert.ok User.makeSalt.calledOnce
          Test.assert.ok user.salt == User.makeSalt.returnValues[0]

        "it encrpyts the password": (err,user) ->
          Test.assert.ok User.hashPassword.calledOnce
          Test.assert.ok User.hashPassword.calledWith @user.password

      teardown: ->
        User.hashPassword.restore()
        User.makeSalt.restore()
        Model.cleanupDB()

Recent developments have certainly improvemed the enterprise work environment. The proliferation of iOS devices has not only brought Macs into the traditionally Windows-only world of the enterprise; it’s brought a new focus on standards-based webapps, which has forced a reconsideration of existing technology stacks. As enterprises have adopted dynamic languages and agile approaches – albeit slowly – they’ve begun upgrading their toolsets, as well. Github’s announcement of an enterprise plan demonstrates that it’s starting to feel a little bit more human within the confines of corporate intranets.

But even as the enterprise has evolved, the improvements made for individual developer productivity have exploded. The ease with which a single developer can build and deploy a scalable, cross-device, and revenue generating app is beyond remarkable. The maturing of tools, languages, development environments, and deployment strategies has created a fantastically productive environment. To name a few favorites:

• Macbooks - The new Macbook Airs, when fully tricked out, offer incredibly powerful development workhorses weighing less than 3 pounds and costing less than $2k

• Homebrew - A package manager for Mac OS, making that Macbook purchase perfect

• Heroku - Have an idea for a new project? Deploy it for free. Want to scale it? Flip a switch

• Chef and Puppet - Want more control than Heroku offers? Fine, manage your own boxes with a sane devops solution that you can take with you.

• Git and Github - Who could have ever imagined that managing code could be so enjoyable?

• zsh and oh-my-zsh - Tab completion, customizable plugins, persistent Git HUD

• The incredible profusion of programming languages, libraries, and frameworks - Scala, Clojure, node.js, the Play framework, NoSql solutions, nginx, to say nothing of the maturing of Ruby (especially Rails) and Python - all of these technologies make it easier than ever to work in one’s preferred style without sacrificing power or performance. The communities around each of these technologies, empowered by twitter, StackExchange, and Github, ease learning curves and offer helpful answers to any questions.

• The Apple App store, Square, Stripe, Recurly, and Samurai enable developers to make money on their ideas and apps with far less effort than in the past.

Is there any other industry in which an individual has such a dramatic advantage in tools, cost, and agility over large organizations?

It’s an exciting time for indie developers. And the future keeps looking better.

My brain is struggling to return to coding productivity after its extended vacation, so I’ve mostly been reviewing my RSS reader to aid in the transition. Assaf Arkin, to whom I owe a massive debt for his creation of Node testingtool Zombie.js, wrote a great article on Self that deserves mentioning. Self, as most JS developers know, played an important role in inspiring Brendan Eich’s creation of Javascript, but I was unaware of the details of the language.

Assaf’s whole article is worth reading, but one particular quote stood out:

language and environment come together to achieve a common goal: to create an environment that is malleable, that allows learning through sharing and exploration, that uses minimalism and consistency to foster reuse.

Minimalism, consistency, malleability.

These words work not just as signposts of good language design, but of everything from API construction to individual units of code. I’m certainly planning on using them as my mantra as I slowly get back up to speed with work.

Embracing Vows

One of the tools which I’ve really enjoyed learning is Vows.js. Vows.js is a fully async Javascript testing library that allows for blazingly fast execution. (It’s amazing how little changes in test speed can make TDD feel much less onerous.) Vows’ syntax can be a little tough to adjust to, but the speed, combined with the ability to construct “test batches”, make the barrier to entry worth the effort.

While Vows is a near pefect tool for unit testing, I began to run into trouble with full-stack integration testing. Check out the contrived example below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

vows.describe("Creating a User")
  .addBatch
    "To create a user":

      "Given the server has started":
        topic:
          server.ready, @callback

        "and the DB is populated":
          topic:
            setupFixtures @callback

          "and another setup function is required":
            topic: ->
              anotherSetup @callback

            "When visiting the form at /user/new":
              topic: ->
                ctx = this
                server.ready ->
                  zombie.visit "http://localhost:#{port}/user/new", ctx.callback
                return

              "then should allow entry of a username": (err,browser,status) ->
                assert.ok browser.querySelector ":input[name=username]"

              "should allow entry of first and last name": (err,b,s) ->
                assert.ok b.querySelector ":input[name=firstName]"
                assert.ok b.querySelector ":input[name=lastName]"

              "should allow entry of a password": (err,b,s) ->
                assert.ok b.querySelector ":input[name=password]"

              "should allow confirmation of a password": (err,b,s) ->
                assert.ok b.querySelector ":input[name=passwordConfirm]"

              "and submitting the form":
                topic: (browser,status) ->
                  browser.fill("username", "test")
                         .fill("firstName", "Justin")
                         .fill("lastName", "Reidy")
                         .fill("password", "foobar")
                         .fill("password", "foobar")
                         .pressButton "Sign Up!", @callback

                "should create a new User": (err,browser,status) ->
                  assert.ok findNewUser()

        .export module

Ouch. All that nesting makes for pretty unreadable code - even in CoffeeScript.

vows-bdd: an easier way to test

I’ve never been a huge Cucumber fan, but modeling integration tests in a “given-when -then” format makes them much easier for me to construct mentally. While the prenup library made long Vows tests easier to read by introducing a fluent interface, I thought that I’d love to marry this fluent approach with BDD’s “given-when-then”.

A couple days later and vows-bdd was born:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

Feature("Creating a User")
  .scenario("Create a User via Form")

  .given "the server is running", ->
    server.ready @callback

  .and "the DB is popuplated", ->
    setupFixtures @callback

  .and "another setup function is called", ->
    anotherSetup @callback

  .when "I visit the form at user/new", ->
    zombie.visit "http://localhost:#{port}/user/new", @callback

  .then "I should see a username field", (err,browser,status) ->
    assert.ok browser.querySelector ":input[name=username]"

  .and "I should see entries for first and last name", (err,browser,status) ->
    assert.ok browser.querySelector ":input[name=firstName]"
    assert.ok browser.querySelector ":input[name=lastName]"

  .and "I should see a password entry", (err,browser,status) ->
    assert.ok browser.querySelector, ":input[name=password]"

  .and "I should see a password confirmation", (err,browser,status) ->
    assert.ok browser.querySelector, ":input[name=passwordConfirm]"

  .when "I submit the form", (browser,status) ->
    browser.fill("username", "test")
           .fill("firstName", "Justin")
           .fill("lastName", "Reidy")
           .fill("password", "foobar")
           .fill("password", "foobar")
           .pressButton "Sign Up!", @callback

  .then "a new User should be created", (err,browser,status) ->
    assert.ok findNewUser()

  .complete()
  .finish(module)

Checkout the repo on Github for more documentation and info.

Open-Source is scary!

The vast majority of my career has taken place in enterprise world, where code is rarely, if ever, shared with anyone on the outside, and even using open-source code is considered dangerous. While I’ve contributed to OSS libraries before, I’ve never posted my own creation. It’s fairly nerve-wracking to put your work out in the wild, especially when you’re building on top of such amazing contributions from incredible developers.

In fact, I probably would’ve sat on this little library forever, constantly trying to perfect it, if not for a fantastic blog post written by Charlie Robbins(@indexzero) over at Nodejitsu. I think his post perfectly expresses the spirt and mentality of the Node community right now, and his emphasis on experimentation via small bits of functionality made me realize: this code may not be perfect, and it might not even do that much, but if I find it useful, then maybe someone else will too.

So please - checkout vows-bdd and give it a whirl. Any suggestions or comments would be very much appreciated!

A common point of confusion in Javascript is that the value of this depends entirely on a function’s context, and can even be overridden depending on how a function is invoked. Hopefully this post will save time for new Javascript devs trolling through Google’s depths:

In anonymous functions, the value of this refers to the anonymous function itself, and not the calling scope. However, the nature of closures allows the anonymous function to still refer to the calling object.

The above rule is demonstrated with the following nodejs code:

1
2
3
4

var that = this;
that.foo = 'bar';
process.nextTick(function() {
  console.log("this " + this.foo + " and that " + that.foo) });

When using a JavaScript loop to generate functions, it’s common to insert a closure wrapper in order to ensure that loop variables are closed over, and all the generated functions don’t just share the final values. CoffeeScript provides the do keyword, which immediately invokes a passed function, forwarding any arguments.

“All the generated functions don’t just share the final values.” Huh. This statement didn’t mean a lot to me. A little searching on Google led to a fairly helpful post on Stack Overflow. The question there presented the following Javascript:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

var closures = [];
function create() {
  for (var i = 0; i < 5; i++) {
    closures[i] = function() {
      alert("i = " + i);
    };
  }
}

function run() {
  for (var i = 0; i < 5; i++) {
    closures[i]();
  }
}

create();
run();

The question stated that the result of running this code was 5,5,5,5,5 instead of the expect 0,1,2,3,4. The answer which created the “correct” result provided the code below:

1
2
3
4
5
6
7
8
9

function create() {
  for (var i = 0; i < 5; i++) {
    closures[i] = (function(tmp) {
      return function() {
        alert("i = " + tmp);
      };
    })(i);
  }
}

and also explained:

JavaScript’s scopes are function-level, not block-level, and creating a closure just means that the enclosing scope gets added to the lexical environment of the enclosed function.

OK, this was even less helpful. But after going back and reading the Coffeescript docs again, the concept made sense. As always with Javascript, the context in which a function is called demands as much attention as the function itself. Reading the code in the Stack Overflow post, a developer’s brain automatically thinks of the returned function at the time of evaluation. But in reality, each of those functions created in the create function aren’t called until after the for loop has completed. Thus, by the time each function is called, it evaluates i when i has already finished the loop with a value of 5. The closure-wrapping provided in the answer is exactly what the do keyword in Coffeescript provides!

Here’s an example of the solution’s function, in Coffeescript:

1
2
3
4
5

closures = []
create ->
  for i in [0..5]
    closures[i] = do (i) ->
      -> alert i

Even with this contrived example, I find the Coffeescript easier to read, although of course it’s personal preference. If you wanted to go really crazy with Coffeescript syntax, you could write:

1

  closures = ((do (i) -> -> alert i) for i in [0..5])

Two points for cool implementation, no points for readability!