chris clarke

Tool Support For JavaScript

Oh dear, what happened to my clever navigation and code-completion? The IDE support for JavaScript is still catching up with Java, if you have only small amounts of JavaScript you’ll be fine with TextMate or something similar. But for large class-based projects you’ll need something else.

The best thing at the moment is IntelliJ, its currently the only thing out there that can navigate across a codebase. With Aptana or Eclipse, if the method exists in another file it cannot navigate to it and you’re forced to resort to searching in files ending with *.js. Second best is Eclipse 3.3 with the JSEclipse 2.0 pre-release installed. (I’m really impressed with Eclipse 3.3 - its improved in several places - but I especially like the Quicksilver style Ctrl-3 shortcut).

How hard can unit-testing JavaScript be?

On the surface of things JavaScript seems to have a lot of the same tools that Java has for unit-testing. JSUnit is the JavaScript equivalent of JUnit and JSMock the equivalent of JMock.

The syntax of JSUnit is fine, its pretty much as you’d expect and conforms to the XUnit conventions. The key bit that’s missing is the fast feedback. When working on a class you want to be able to run the test often so you can see the immediate effects of changes you’ve made and the let the test tell you exactly whats wrong. To run a test with JSUnit, I need to open the JSUnit test runner in a browser, load my test page and then run it. Once I’ve run it, assuming its failed I get a list of tests that failed - but not the reason they failed, I need to double-click - then I get an alert telling me why the test failed. It really interrupts your flow, especially when you’re flipping between multiple classes. If you’re using an IDE with a Browser Preview tab, you can get around this problem with a little JavaScript along the lines of:

(Sorry plus signs don’t seem to show up - hopefully you can get the general idea).

I’ve got this working in Eclipse by installing the EclipseHTMLEditor plugin and including the following common bit of code in all JSUnit tests:

Now a test can be run by just clicking on its Preview tab.

Making a Mockery

JSMock is kind of good - at least someone’s written a mocking framework for JavaScript. As soon as you start to use it - you realize that it is by know means a mature piece of software.

It doesn’t give you any kind of useful messages, for example it will say ‘Unexpected Arguments’ but won’t tell you what the actual arguments were against the expected arguments. Similarly for an unexpected invocation, it won’t tell you what has been called and what was expected to be called. The other missing piece is support for literal objects - JSMock gets it wrong if you pass a literal object as an argument. This is basic stuff - thankfully the code is still quite small and I’ve found myself adding a lot of these features myself just to be able to use it.

The cool thing about JSMock is that because JavaScript is such a flexible language you don’t need to put your method calls in strings like in JMock 1 and you can keep using literal language (unlike in JMock 2):

Another cool thing is that if I have static objects as collaborators I can mock those too:

eXtreme JavaScript

Over the past few months I’ve been working a lot with JavaScript. The language is very deceptive as it has C-style syntax, and is mostly written with little regard to good programming practice. However, it turns out to be quite a good object-oriented language which can lend itself to some very elegant code.

The language itself has a fair few problems for your average extreme programmer. For starters it’s a dynamic language so a lot of errors won’t turn up until you run it, and because of its tendency to not throw Exceptions (which do exist in JavaScript), things may just quietly go wrong. Code conventions don’t seem to have been established yet and there are an awful lot of different ways to do the same thing in JavaScript, for example declaring a class can be done like this:

…or it can be done like this:

or this…

… or you could even do it like this (although you’d have to be mad):

If you are doing extreme programming it can be much harder to come up with agreed standards just because there are so many different ways of doing things. This also makes refactoring a much more subjective affair and can lead to churn if developers enter the vicious circle of refactoring other peoples code to their preferred style. Also, its very easy to do (and it seems fun for some people) clever and complicated things in JavaScript which means simplicity of the codebase often suffers.

Shared Coding Standards

This makes me think when dealing with JavaScript it is very important to have shared coding standards agreed by the whole team. For the benefit of rooting some values of simplicity in the team its probably a good idea to agree a set of things that just shouldn’t be done (i’m thinking about the needlessly complicated things here). Similarly, when CSS and DOM manipulation are involved - the team should agree standard ways of doing things.

The One Most Important Thing About Software Development

I attended miniSPA this year and at the start of the conference we were asked to come up with “the one most important thing someone should know about software development”. This question has been bugging me ever since until I realised that there is no “one most important thing someone should know about software development”. Pattern languages such as Scrum, and practices such as XP will definitely improve your chances of success but every project has its own unique problems. Unfortunately there is no one true thing that will make everything alright - you just have to address these unique problems that exist on each project - switching to Ruby or Erlang or whatever probably won’t help. Incidentally the audience at miniSPA’s conclusion was “its about people not software”.

Getting your TODOs out of comments

Thoughtworker Carlos Villela talks about Getting your TODOs out of comments.

Genius.

Continuous Deployment As A Practice

A lot of people do Continuous Integration these days (even if that just means source control and CruiseControl). But very few teams seem to do any form of Continuous Deployment. The point of Continuous Integration is to detect integration problems as quickly as possible and to reduce the risks involved in a deferred integration. A deferred integration is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems. As Martin Fowler says in his article:

“you are putting yourself into a complete blind spot right at one of tensest parts of a project”

So why is deployment any different? If your deployment process involves things that have not been done continuously every day, such as packaging files, copying them to servers, installing, configuring & starting processes, then you are doing deferred deployment. A deferred deployment is something that will delay the release and may take an unknown amount of time and involve an unknown amount of problems.

It may not be as easy to do Continuous Deployment - so keep it simple at first - grab your build artifacts from your Continuous Integration server, deploy them, automate the rest of your deployment process - then run some simple Deployment Tests:

• Is it up?
• Does it work?

Worry about adding more complicated things such as testing failover, load balancing etc. later. Just get some simple, automated deployment test coverage. I’ve seen & heard a lot of painful release processes, ones that take to 5 in the morning, ones that take 8 hours on the weekend, ones that involve a degree of ‘trial and error’ - don’t ignore your deployment problems - make them visible and try to fix them, just like you would with a slow build or a failing CruiseControl build.

Feature Crawl

Have you ever experienced feature crawl? That time on a project when features seem to take longer and longer to develop and less seems to get done than it used to. There are several reasons why this can happen, but I want to talk about problems relating to the growth of the codebase over time.

As the codebase grows over time it seems to take longer to add a feature. Adding a new feature often involves working out what the existing code does, seeing what functionality already exists that you need to use and finding the places where this functionality is available. The bottom-line is, the more existing code you need to understand and navigate through - the more time it takes.

So what can you do to help? Write Screamingly Obvious Code - code that your grandma could understand, code that’s so easy to understand what and why it’s doing something that a monkey with learning difficulties could understand it.

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

Pair Programming Patterns

I’m trying to introduce more Pair Programming at the moment - so I’ve been trying to make it a fun thing to do. One of the ways I’ve been doing this is making use of the Ping Pong Pattern which has been working quite well. However, there are situations when this pattern doesn’t fit such as when debugging, refactoring, looking for something in the code or when their are big tasks which are hard to divide up. When not using the Ping Pong Pattern, I find its easy for one pair to dominate, get bored, silently think ‘OMG WTF is he doing?!!!’, or fall asleep.

So I’m going to just make some patterns up and list some ones I found which might be fun for those new to Pair Programming and stop me falling asleep:

One Line Each - Each programmer takes it in turns to write one line of code. This can be done in silence as a kind of game, or normally to continuously discuss each programmers intentions.

Two Keyboards and Two Mice - Both programmers can interact at any time - the idea is to stop one programmer dominating / hogging (via Steve Freeman).

Chess Clocks - Sam Newman describes it much better than I could.

Pair Poker - Each programmer gets a limited number of cards at the start of the day, they can choose to play a card at anytime and gain immediate control of the keyboard.

Different Roles - Each programmer takes on a different role, possible combinations:

• Refactorer / Programmer : One programmer cannot do anything but refactor, the other can do anything.
• Tester / Implementer : One programmer cannot do anything but write tests, the other cannot do anything but make tests change from red to green.
• Navigator / Programmer : One programmer can only move between classes, the other can do anything but move between classes.
• Adder / Remover : One programmer can only add code, the other can only remove code.

Roles can be switched every hour or just when one get’s bored.

Thinking of a fun thing to do whilst debugging, looking through logs, or looking through code was a lot harder.

Backseat Driver - To keep both programmers attention, one drives and cannot do anything without being directed by the other.

Driver Buckaroo - The driving programmer has to give up the keyboard every time some event happens (e.g. build breaks, someone swears, you get an email, the project manager cracks the whip, someone checks in, someone stands up).

Promiscuous Pairing - Basically pairs rotate more often. (I’ve tried this with a rotation every 90 minutes — it was fun but tiring.)

Driving in to Trouble

Testing edge cases.

Every time I run in to something that gets in my way, slows me down or just annoys me I write it down on a card. If I run in to the same problem again - I add another notch to the card (like a tally). A colleague has a principle of Three Strikes and You’re Out - that is, if you come across the same problem three times you have to fix it. I also find it useful to take these cards along to retrospectives or stand-up meetings. Fixing these things that get in the way has really had a positive effect on productivity and made the team more interested in fixing bad things rather than taking the extra time and effort to work around them.

Red, Green, Cup of Tea

I like the Red Green Refactor pattern - write a failing test, make the test go green and then refactor the code. However, I’ve found recently that refactor doesn’t necessarily mean make the code tidier or improve the design to some people. To some people it just means change some existing code.

So I invented (by accident) the Red Green Cup of Tea pattern - write a failing test, make the test go green, and go and make a cup of tea whilst the build runs. I’ve found that whilst making a cup of tea, my pair and I can reflect on what we’ve just done and often find we weren’t 100% happy with what we just did. We then set our cups of tea back down on the desk and Refactor the code.

Annoying Patterns: Setter Injection

What do I have to do to get this object to work in the way I want?

Does setting some things rely on having set something else?

With all these public setter methods the objects state can change throughout it’s life. If I have to pass references to this object around maybe I don’t want people changing it’s state.