Tuesday, 1 March 2016

Testing callbacks in Node.js

When you're using any asynchronous language such as JavaScript or Node.js you will possibly be using callbacks. You will also want to make sure that you can unit test these callbacks successfully.

This blog describes a pattern for unit testing callbacks in Node.js using mochachai and sinon.

Let's say I have a function to get the details of a beer, as follows

var getBeerDetails = function(beerCode, onSuccess, onNotFound) {
    var beer = beerList[beerCode];
    beer !== undefined ? onSuccess(beer) : onNotFound();
};

The function takes three parameters, a beerCode and two callbacks. The callbacks are called when the beer is successfully found or when it's not found, as per the parameter names. The test for the "onSuccess" callback looks like this

it('should be called with beer object', function() {
    // Arrange
    var beerCode = '1001';
    var beerDetails = {
        abv: '4.1%',
        description: 'Light, hoppy, citrus flavours'
    };
    var onSuccessSpy = sinon.spy();
    var onNotFoundSpy = sinon.spy();

    // Act
    index.getBeerDetails(beerCode, onSuccessSpy, onNotFoundSpy);

    // Asssert
    expect(onSuccessSpy).to.be.calledWith(beerDetails);
    expect(onNotFoundSpy).not.to.be.called;
});

The key part of this test is using sinon to spy on the callbacks. This enables you to determine whether they have been called and with which parameters. This test asserts that the "onSuccess" callback to be called with the details of the beer found. To make this test even better we can also assert that the "onNotFound" callback is not called.

This is just some of the functionality sinon has, it's a very useful part of the unit testing toolkit.

The full source code for this blog can be found on GitHub at https://github.com/davet1985/beer-catalogue

Sunday, 13 September 2015

Managing a training programme using Scrum

TL;DR - use an agile methodology to provide structure, rapid feedback, visibility, focus and motivation to an on-the-job training programme.


Whilst preparing an internal software development training programme I decided to use Scrum to manage the process. My knowledge and experience of using Scrum comes from the world of software development, after all, I am a software developer! Scrum is often perceived as a software development methodology, but it is infact just a framework for managing a process. Given this, I thought it was well suited to providing some structure to a training programme.


Here is how I handle some of the key parts of process: -


Stories


Each training subject is captured as one or more stories. If a subject area is large it is split into many stories and grouped using the the concept of an “epic”. A story contains a description, acceptance criteria and tasks. The acceptance criteria is used to define the expected learning outcomes and the tasks are specified to give greater detail of what should be done to achieve those learning outcomes.


Backlogs


I maintain two backlogs, the overall training backlog and the sprint backlog. I write new stories when I can, add them to the training backlog and keep it prioritised. This gives me visibility over how much material is ready and gives the trainees visibility over what subject areas are coming up in the near future. During planning, stories are placed into the sprint backlog in the usual fashion.


Sprint planning


We work in one week sprints and therefore have a planning meeting, involving me and all trainees, before each sprint. During planning we try (time permitting) to go through all of the stories, in priority order, reading the description, acceptance criteria, tasks and discussing the story to gauge the complexity. Following the discussion we would size the story relative to others using the fibonacci sequence numbers.


Once all stories have been discussed and sized we start moving them into a sprint backlog. For the first couple of sprints it was hard to predict how many points to add to the sprint but this becomes easier.


Finally, I found that setting a goal for the sprint helped motivation, such as saying the main learning focus this sprint is hash maps.


Daily scrum


The daily scrum was carried out to do the usual “status update” type meeting, with each member of the team saying what they did yesterday, what they are doing today and raising any issues they may have. I found it helped to set a starting point for each day with renewed motivation for the training ahead. It also gives the trainees visibility over what I am doing on a daily basis.


Saying that, this is probably the part of the process that works least well, because the trainees work together on each story and I am involved answering question on a daily basis. I could see this becoming more useful if the number of trainees was larger and some worked at different speeds.


Sprint review


The sprint review is done in the form of a presentation from the trainees to myself and any other company employees who wish to attend. Preparing the presentation makes the trainees go over everything they learned in the sprint to ensure they are able to explain it adequately, resulting in a short revision period helping to cement the concepts.

This also allows the trainees to practice preparing and giving presentations to a group, outside of any real business situations. This helps to build their skills and confidence for when they are required to present to in a real scenario.


For me, the sprint review is an opportunity to assess how the trainees are getting on with the learning and think about any additional stories that might be required in the training backlog.


Sprint retrospective


Retrospectives are often overlooked but I believe they are one of the most important ceremonies in the scrum process. During our retrospectives we do activities such as WWW, 4L’s or the sailboat analogy. Whichever activity we do, the aim is to discover how the sprint went and raise any action points for making changes to improve the process. Talking about things that went well is just as important as talking about things that didn’t and I like to hear what the trainees enjoyed during the sprint.


Tools


There are many tools out there to aid the scrum process. For simplicity I decided to use Trello, with the Scrum for Trello chrome extension installed, to maintain the stories, backlogs and scrum board. Also for immediate visibility I use post-it notes with story headline and a basic scrum board on a whiteboard in the office to provide an indication of progress.


In conclusion using this process for managing the training programme works well. It improves focus, motivation and visibility, as well as putting a structure in place for reviewing learning outcomes and getting feedback during the training. 

Finally, in my case, it was a chance to introduce the the scrum process without doing it as a formal subject in training. This prepares the trainees for using the process used in real projects.


Have you ever used scrum for anything other than software development?


What other processes could be managed well using Scrum?

Wednesday, 14 May 2014

Never calculate your own timestamps

I came across a function in a PHP application I'm working on, the function was designed to take in a year and populate an array with weeks in that year, including the start timestamp, end timestamp and description. The detail is irrelevant but if you are interested it would look something like this: -

[
  "1388966400_1389484800" => "Mon, 6 Jan, 2014 - Sun, 12 Jan, 2014",
  "1389571200_1390089600" => "Mon, 13 Jan, 2014 - Sun, 19 Jan, 2014",
  "1390176000_1390694400" => "Mon, 20 Jan, 2014 - Sun, 26 Jan, 2014"
]

When I first saw the function it achieved this by doing something like the following: -

$oneDay = 1 * 60 * 60 * 24;
$oneWeek = $oneDay * 7;
// assuming the weekStartTimestamp is set to the first Monday
$weekStartTimestamp = $weekEndTimestamp + $oneDay;
$weekEndTimestamp = $weekEndTimestamp + $oneWeek;

On the face of it this should work no problem. As can be seen by running the following PHP, as you can see we start with midnight on the 29th, add one day and get midnight on the 30th.

$timestamp = strtotime('2014-03-29');
$one_day = 1*60*60*24;
echo date('d-m-Y H:i:s', $timestamp);
echo "\n";
$timestamp = $timestamp + $one_day;
echo date('d-m-Y H:i:s', $timestamp);

// output
29-03-2014 00:00:00
30-03-2014 00:00:00

The issue arises when one day is not equal to 1*60*60*24. This might not seen obvious but when the clocks go forwards from GMT to BST, you only need to add 23 hours to get from midnight one day to midnight the next day. And likewise when the clocks go back from BST to GMT you would need to add 25 hours. The timestamps would still be for the same day, but if you are relying on the exact date and time then this would obviously cause serious issues! As shown here: -

$timestamp = strtotime('2014-03-29');
$one_day = 1*60*60*24;
echo date('d-m-Y H:i:s', $timestamp);
echo "\n";
$timestamp = $timestamp + $one_day;
echo date('d-m-Y H:i:s', $timestamp);
echo "\n";
$timestamp = $timestamp + $one_day;
echo date('d-m-Y H:i:s', $timestamp);

// output
29-03-2014 00:00:00
30-03-2014 00:00:00
31-03-2014 01:00:00 // adding a day goes to 1am!

Fortunately, PHP provides a function to handle any such calculations you need to do with timestamps. This is the strtotime function, which to quote PHP lets you "Parse about any English textual datetime description into a Unix timestamp". The example below shows how this could be used instead of adding one day as above, and produces the expected results.

$timestamp = strtotime('2014-03-29');
echo date('d-m-Y H:i:s', $timestamp);
echo "\n";
$timestamp = strtotime('+1 day', $timestamp);
echo date('d-m-Y H:i:s', $timestamp);
echo "\n";
$timestamp = strtotime('+1 day', $timestamp);
echo date('d-m-Y H:i:s', $timestamp);

// output
29-03-2014 00:00:00
30-03-2014 00:00:00
31-03-2014 00:00:00 // this time we get midnight!

The lesson to learn from this is to never try to calculate timestamps yourself! Always use the built-in functions to handle any calculations you require!


Wednesday, 27 March 2013

Koans

The word koan originates from Zen Buddhism and google defines it as this: -
A paradoxical anecdote or riddle, used in Zen Buddhism to demonstrate the inadequacy of logical reasoning and to provoke enlightenment.

Applying this to programming has resulted in programming-style koans. Meaning riddles leading down a path to enlightenment about a specific language. Generally koans can be used to help learn the syntax and intricacies of a language by introducing different aspects in a logical order using failing tests which the "student" must pass before continuing.

I first became aware of programming koans when I set about learning Ruby and worked through the Ruby Koans.


Then, most recently, whilst trying to learn more than just the basics in Javascript, I discovered the Javascript Koans, available on github here. I would say that even if you have dabbled in some Javascript before, it's worth going through these as they certainly taught me a thing or two and may help to clarify some areas you might be a bit hazy on.


So, give these koans a try, you might learn something!