Monthly Archives: March 2013

Waiting for your web services? Hello JSON Mocking!

When we start a development sprint, as a UI / UX team, we will make sure that as a priority, that we identify all of the web services that we will need to consume. We then, define the parameters needed to call the service and generally, we will create a JSON object that we will expect the service to return us.

This helps us shorten the critical path by making sure that the service developers can prioritize their work efficiently, and also move development of web service stubs to the front of their work queue.  This process doesn’t always work perfectly and we are sometimes (often) in a position where the web service developers are days away from even making us a stub, so rather than postponing our own critical path work until later in our sprint, we can pretend we have a working web service using JSON mocking! Hooray!

The Tool : Mockjax

The library I use to fake a working web service is MockJax.  It is wonderfully simple.

  1. The library seamlessly wraps jQuery’s $.ajax command.
  2. You write your ajax call as you would if your service already existed
  3. In your page setup init function, you just once, setup an override based on the URL (and optionally POST type, etc), which can redirect to a function, or a static JSON text file, or another url
  4. When you call your $.ajax, the wrapper checks it’s override dictionary for a match, and if it finds one, it intercepts the call and serves your alternate mock data.

Code Reviews : The Last Line of Defence

When designing the architecture for a web site, not everything you design is about the technology or the code structure.  Perhaps one of the most important project decisions I think I implemented on “Project Shylock” was to implement mandatory code reviews before commit.

All code commits need to pass a build, run and basic sanity check.

The only times committed files won’t require a code review is for a basic copy text change (and maybe even then) or when development was performed as part of Paired Programming (and maybe even then) or for a binary file.

The benefits for code reviews are plastered all over the internet, but just to re-cap from my own personal experience.

Code Reviews produce the least buggy code

I’m sure there are some metrics out there that may prove TDD (Test Driven Development) makes for the least buggy code, but from my own anecdotal experience, nothing makes for more reliable code than having to go through it line-by-line in front of a peer and having to explain your decisions for each line of code.

Additionally, if you promote a development team where noone codes with ego (another topic!), then critical analysis of code structure and logic will flow naturally.  It can be like getting a free refactor just before you commit your changes.

 Code Reviews cross-pollenate knowledge

When I’m working on code in a team that doesn’t code review, the only time I know what everyone else is doing is during the daily scrum standup… and even then I only get a passing overview of their coding day.

When I’m on a team that is doing code review, I always know what 3 or 4 other people have been working on that week.. to the point that if they are away sick and a bug arises related to it, I generally feel comfortable to jump into the code and try my own hand at it.

Last thoughts…

I went away on vacation for 3 weeks and left my team on an honor system to keep code reviewing themselves.  I was unpleasantly surprised to come back that they had been incredibly overloaded and in their work compression mode, they dropped their code reviews.

It’s an easy thing to do to say “Oh I’m too busy to do this”, but in the end, code reviews only take a few minutes most of the time, and can save HOURS of work… sometimes you don’t have to pay that tech debt until weeks later.. but it will be paid sooner or later.. trust me.

UPDATE: Even Jeff Attwood (of Coding Horror/Stack Overflow fame) agrees!