It was a very busy day for Canonical releases. Juju core 1.11.3(devel) was released which brought with it a number of bug fixes along with the long awaited Local Provider support. The stunning, cutting edge, crowd funded Ubuntu Edge Ubuntu smartphone campaign was released and, at the time of this writing is sitting at $2.4Million of it’s record setting $32Million goal after less than 24 hours.

Most exciting to me however is release of the Juju GUI v0.8 and the new jujucharms.com. v0.8 has a large number of bug fixes to intagrate properly with the new jujucharms.com but most importantly enhances the new Juju Deployer format.

Visiting jujucharms.com now drops you right into the Juju GUI with the charm browser open allowing you to explore and discover new charms as well as deploy them into a mock Juju environment. This allows you to build your entire environment and then export it into the new Juju Deployer format for easy import into your own local environment!

We don’t plan to slow down now, there are a number of great improvements coming down the pipeline very soon. If you have been following our development trunk I would like to let you know that the uistage link will be being retired in favour of http://comingsoon.jujucharms.com/ which will, just like with uistage, host our dev trunk, updated throughout the day as new code makes it in.

It’s a great time to be involved with open source! Let me know what you think of all of the great things coming out of Canonical. Comment below or mention me on twitter @fromanegg, Thanks for reading!.

Earlier this week we released the latest version of the Juju GUI, 0.6.0. This version brings with it a bunch of bug fixes and stability improvements, an updated UI, and a new charm browser which allows you to find new charms without leaving your environment. You can find the source here.

Other changes include:

This just in… Juju for OSX is now available! From the team which brought you Juju brings you the ability to manage your OpenStack, AWS, and HP Cloud environments from OSX.

Setup:

At the time of writing there are 137 services ready to deploy. Plus you can deploy your app right from github using our node.js and Rack charms.

A number of people, myself included, have a hard time getting started with test driven development (TDD). The issue lies in that it’s difficult to wrap your head around something that is rather non specific in its implementation and it is usually described as “writing your tests before you write your code”.

When developers hear “Write your tests before you write your code”, then they look at their previous test suite they wonder… “How can I possibly write this without having written the code first?

new Test.Case({
    testSomething : function () {
       var class = new MyClass();
	class.assert(...);
    },

    testSomethingElse : function () {
        //...
    }
});

Herein Lies the difficulty with doing test driven development, everyone says you write the tests first but in reality you write the structure of the class first. To illustrate this lets create a simple instantiable class using TDD. This class will need to receive data and then append a representation of that data to the DOM.

Your first step is to outline each step the class needs to make in point form. This helps you visualize the whole completed class from start to finish before you type a single line of code. This will help you figure out any shortcomings in complex classes ahead of time so you don’t waste time writing code which will be thrown away.

Our classes requirements: is instantiable. will accept a config object and create related instance properties. will generate a string template using the configuration properties. will generate a DOM element from the string template. will append that element to the body.

Next is to take these steps and create tests which prove that they work. To do that we need to use a test suite which makes test driven development easy. For this tutorial I am going to use Mocha (http://visionmedia.github.io/mocha/) I won’t go into detail on this test framework as it’s out of the scope of this tutorial but it is pretty easy to pick up by following along.

describe(DOM Info Generator, function(){
  it(is instantiable);
  it(will accept a config object and create related instance properties);
  it(will generate a string template using the configuration properties);
  it(will generate a DOM element from the string template);
  it(will append that element to the body);
});

So now you can start to see what I mean when I said that we write the structure of the class first. In practice we aren’t writing the tests first at all, we are writing declarations of what our class will be doing.

The third step is to start writing some code to satisfy these tests in order. Our first two tests say that our class needs to be instantiable and that it needs to accept a configuration object and create related instance properties.

function DomInfo(config) {
  this.name = config.name;
  this.job = config.job
}

Now that we have the code completed to what we believe matches our first two tests we can write the tests. On a real project you would need to import your class into your test suite but for this tutorial we will just have our test suite after our class declaration.

var assert = require(assert);
describe(DOM Info Generator, function() {
  var name = 'Spock',
        job = 'Science Officer',
        domInfo;

  // Code to execute before every test.
  beforeEach(function() {
    domInfo = new DomInfo({
      name: name,
      job: job
    });
  });

  // Code to execute after every test.
  afterEach(function() {
    domInfo = null;
  });

  // Tests
  it(is instantiable, function() {
    assert.equal(domInfo instanceof DomInfo, true);
  });
  it(will accept a config object and create related instance properties,
    function() {
      assert.equal(domInfo.name, name);
      assert.equal(domInfo.job, job);
    });

  ...
});

Stretching a little bit out of context of this tutorial I am setting up hooks (beforeEach, afterEach) to create a new instance of our class for every test, and then clean up that instance after every test.

For our first test we take our new instance and test to make sure that it is an instance of our constructor. The second test we access the two instance properties of our class and check them against our known values.

Moving on to our next two tests we need to take our configuration values generate a template and generate a DOM element from that template.

function DomInfo(config) {
  this.name = config.name;
  this.job = config.job
  this.generateAndAppendTemplate();
}
DomInfo.prototype = {
  generateAndAppendTemplate: function() {
    this.generateTemplate();
    this.createDOMElement();
    this.appendElement();
  },
  generateTemplate: function() {
    this.template = Hi  + this.name + ! Great job being a  + this.job;
  },
  createDOMElement: function() {
    var greeting = document.createElement('div');
    greeting.className = 'greeting';
    greeting.textContent = this.template;
    this.element = greeting;
  },
  appendElement: function() {
    document.body.appendChild(this.element);
  }
}

And now to the tests to make sure that our code satisfies our goals. I left out the previous code and tests for brevity.

...
  it(will generate a string template using the config properties,
    function() {
      assert.equal(typeof domInfo.template === string);
      assert.notEqual(domInfo.template.indexOf(name), -1);
      assert.notEqual(domInfo.template.indexOf(job), -1);
    });
  it(will generate a DOM element from the string template, function() {
    assert.equal(typeof domInfo.element === object);
  });
  it(will append that element to the body, function() {
    assert.notEqual(document.querySelector(.greeting), null);
  });

By now you are probably getting the hang of this.

To recap, the easiest way to understand test driven development, or TDD, is to outline our class into declarations of intent. Then, test by test, write the code to satisfy those declarations and the tests to ensure that they stay satisfied. Running the tests constantly to be sure that we are always moving forward. If you find that after satisfying one of your new tests, or after a refactor, you have broken some tests you must then stop and make those tests pass again. You cannot advance unless all previous tests pass.

I hope that this approach will help those of you who haven’t been able to wrap your head around test driven development be productive. Properly developing large applications using test driven development helps to all but remove code rewrites from improperly spec’d code and hidden regressions because you outline the classes intent and knock off those points one by one.

Thanks for reading, and as always, let me know what you think by commenting below or mentioning me on twitter @fromanegg.

I’m sure most people cringe when they hear that they have been assigned a task which has to do with dates in JavaScript. Because JavaScript is lacking a fully featured date library these tasks are rarely trivial and become even more difficult when you need to support users around the world.

Converting a timestamp to UTC time.

To display a timestamp in UTC around the world instead of in the users local timezone you use getTimezoneOffset, multiply it by 60,000 and then subtract that from your timestamp.

var rd = new Date.getTimezoneOffset()*60000,
    time = new Date((1349797266.032 * 1000) - rd);

console.log('UTC timestamp is ' + time);

Calculating the users timezone

To calculate the users timezone we need to determine the offset between the current time and the UTC time. To do that we use the getUTCHours method and the compare the two dates.

var dateATmp = new Date(2013, 0, 1, 0, 0, 0, 0),
    dateA = new Date(2013, 0, 1, dateATmp.getUTCHours(), 0, 0, 0);

console.log('Your timezone is GMT ' + (dateATmp - dateA) / 3600000);

Determining if the user observes daylight savings time

Calculating if the user observes daylight savings time (DST) is a little long winded but is certainly possible. We need to calculate the timezone difference between January and July. To do that we create the two dates, one in their current timezone and the other in UTC. We then divide the difference by 3600000 to get the hour offset and if they are the same DST is not observed.

var dateATmp = new Date(2013, 0, 1, 0, 0, 0, 0),
    dateA = new Date(2013, 0, 1, dateATmp.getUTCHours(), 0, 0, 0),
    dateBTmp = new Date(2013, 6, 1, 0, 0, 0, 0),
    dateB = new Date(2013, 6, 1, dateBTmp.getUTCHours(), 0, 0, 0),
    diffStdTime = (dateATmp - dateA) / 3600000,
    diffDaylightTime = (dateBTmp - dateB) / 3600000,
    dst = (diffStdTime == diffDaylightTime) ? 'not': '';

console.log('DST is %s observed here.', dst);

I hope that some or all of these solutions help make your life with dates in JavaScript a little easier. If you have any problems, or if you know of a better way to accomplish these tasks please let me know below or by mentioning me on twitter @fromanegg Thanks for reading!