New Tools

With a new job comes 35-45 minutes on a train either direction, and some time to reflect on the day and write for the blog. So here’s my beginner’s attempt to lay out the tools we use at the new job.

It’s always good for a craftsman to get to know his/her tools better, but with so many new tools that’s just going to take a while. Consider this a start!

I’ll also contrast it the tools from the old job, based on all of 5 days of experience.

Mercurial

Old: Subversion

Mercurial is a distributed version control system. It’s similar to, but has slightly different internals from, Git… but the word is that Mercurial is used here because the lead developer preferred it. Maybe he prefers James Bond to McGuyver. Whatever works.

It is far and away better than Subversion, for reasons best explained in this Joel Spolsky post: the short version is that even though one of the advantages of SVN was that fugly merges would go away, in practice they haven’t. With Mercurial, they just might.

Vagrant on VirtualBox

Old: None

Virtualbox is a virtual machine the emulates an x86 environment on any given piece of hardware. Vagrant manages most everything else that’s built on top of the machine; operating system, databases, web servers, environment and dependencies.

When managing many web applications (or, really, any software applications at all) it’s inevitable that the dependencies and requirements from one application to the next will change. Deploying a virutal machine for each application, with the requirements for that application built into the machine, allows developers to iterate through changes rapidly on their local box without worrying about local-box issues that inevitably cause shared working areas to break.

Atlassian JIRA

Old: Intervals Timetask

It’s not enough to know how much time was spent on a given task. It’s more important to know the current status of the task, especially when coordinating with a team of up to a dozen people.

A scrum board helps do this. Important tasks are at the top. Less-important tasks are on the bottom. The journey of each task is monitored on a scrum board, as it flows from backlog to design, to development, to QA, then back to development to push. Tasks are never lost, because they’re right there, on the board.

It integrates well with commit hooks that tie every commit to a particular task. Since I’m a serial committer, it subtly influences me to commit less than I would, but that’s not a bad thing; a commit should be defined by a proper unit of work.

Ruby Version Manager, Node Version Manager

Old: N/A

In the same way that Vagrant keeps the service layer clean, versions managers keep the application layer clean. Some of our applications were built with Ruby 1.9.3, some were built with 2.0.0. Until there’s development time to migrate each application to the most updated version, project-level declarations of application versions keep developers happy.

Grunt

Old: Framework-level hooks, sort of

Not much experience with this so far, but we use it to compile our CSS from SASS and minify JS before deploying to production. This is better done automatically than manually.

Jasmine

Old: None

Jasmine is a JS-based framework for unit tests. A large chunk of our business logic is written in JavaScript, and in the future we’ll only be writing more in it, so bringing code coverage for those scripts up to at least 80% would be ideal.

I thought that trying to test complex JavaScript would be an absolute PITA when I first scanned the code, but Jasmine has the concept of spies, so you can do this…

  it("tracks that the spy was called", function() {
    expect(foo.getBar).toHaveBeenCalled();
  });

And what if you’re testing class A and want to make sure the functionality of class B doesn’t get in the way? Well, JavaScript is a prototypal language, {so you can override B really easily}(3):

spyOn(obj, 'method').andReturn('Pow!')

:-D