So you’ve just written a ton of javascript using backbone.js and decided you want to save yourself the pain of unexpected regressions so decide to use QUnit to write your tests but you want to mock the calls backbone.js makes to our API. Turns out its actually fairly easy, just use sinon.js.

First for any test where you want to call the pretend API you need to setup a fake server and prime it with a response. To do this place it all inside of your setup like so:

module("Backbone.Model can recieve data", {
    setup: function () {
        this.server = sinon.fakeServer.create();
        this.server.respondWith("GET", "/v0/myApp/groups",
            [200, { "Content-Type": "application/json" },
            '{ "id": { "id": 1, "href": "/v0/myApp/1" }, "entity": { "id": 1, "title": "Example 1", "summary": "Test" } }']);

        this.groups = new GroupCollection();
    },
    teardown: function () {
        this.server.restore();
    }
});

In line 2 we create the fake server, then on line 3 we tell that fake server to intercept everything going to “/v0/myApp/groups” using HTTP-GET
On line 4 we tell the server to respond with a 200 header and that it should set the MIME type to json.
Lines 5 and 6 then contain the actual JSON you want sending back to the backbone.js model.
Line 11 just tidies up for you.

So now you’ve got a fake server to pretend to be your API you now need to run fetch on your backbone.js models and respond via your fake server, always in that order. Always.

Then hey presto you’ve got a working mock for your backbone models. In the words of Garth and Wayne. Scha-wing.

Example of a test using the fake server to provide a model

   test("Is backed by a model collection instance, which provides the data.", function () {
        expect(2);
        this.groups.fetch();
        this.server.respond();
        notEqual(this.groups, undefined);
        equal(this.groups.length, 1);
    });

So now we’ve got working tests we can push things a bit further. Wouldn’t it be nice to be able to run these on the build server after every checkin to make sure you’ve not been daft? Yes I hear you cry. Then all you need to do is whip out a bit of the old PhantomJS. I’ll leave it as an exercise to the reader but mostly it involves finding the ‘run-qunit.js’ in the PhantomJS examples and running it against your tests.

Recently in my team at work we’ve started the process of adopting a more agile process for our projects. Before this push to adopt a more agile process we were a team of GSD (Get Shit Done) and while we are still very much about getting shit done we now do it in a more traceable, organised and ultimately productive way.

The meat and potatoes of it is that we now make use of the following:

  • Daily standups
  • A Kanban board
  • Pair programming for tricky problems/new starts
  • Sprints

These 4 things have turned the way we do things on its head.

Daily standups

The standups in the morning give everyone a visibility of the issues and problems everyone else in the team is having.

Kanban board

In my opinion this is the single greatest win in the team. We use Trello almost religiously to keep track of all the stages of development. This increases visibility across the entire team. The best thing about using Trello is not only is everything online, backed up and audited, It’s that it has an awesome JSON based API so hackers like me can do cool things like automagic burndown charts, effort per dev, effortless velocity measurements and anything you could possibly think of!

We break the board into 7 columns: Product Backlog, Sprint Backlog, Dev, Inspection, Test, UAT, and Done.

Everything starts in the Product Backlog where we will estimate against just enough stories to full the Sprint Backlog, from there a developer will pick one, and only one story to complete and move it into the Dev column and assign it to themselves. When that dev has finished the acceptance criteria on the story card the story gets moved into Inspection. When time comes around the BA and tester will come to each of the devs who have stories in Inspection and check it is up to scratch, when they are happy with it they move it to Test.

Thus starts the test cycle, anytime the tester finds a defect the card is marked and the story is stuck until the defect is cleared. Once that happens the card is in UAT and the product owner has to agree everything they wanted is there. If they do then it moves to done and that story is considered complete forever more. If they don’t it again becomes stuck and effort is shifted to unstick it.

The best bit is the PM can see what all members of the team are doing, the members of the dev team can see what’s currently in the sprint backlog, what’s stuck in test, all the acceptance criteria for each of the tests and the estimates. Test can see what’s coming up from dev, what is ready for inspection, what they need to show the user in the next UAT.

Pair programming

We use pair programming sparingly, mostly limited to when a dev is stuck on a problem or we have a new dev start. It’s an easy way for a new dev to be introduced to the code base and the way things are done. It also has the added benefit of dragging them into the office banter rather than just being sat with headphones on.

Sprints

Sprints are a pretty important part of the process as they decide how much we aim to do in the length of time the sprint will take to complete, which at the moment is either 1 or 2 weeks. The biggest advantage of the sprints is that instead of giving us a MASSIVE amount of work to be slowly churned though we have a smaller chuck that just appears more doable and means no overwhelming meeting where we talk about doing hundreds of stories!

The above is just an example of how we will tend to run a project. At the moment we have a few areas for improvement the most important of those being how we put stories together, as soon as we crack that we will be in an even better position that we are now.

Lately I’ve been playing around with Less.js, as part of that I’ve tried to find a decent way to make a set of elements that can be reused easily across my team at work as well as my personal projects.

After a little bit of an initial investigation there where 2 ways that I thought we could go to create a set of less files to create a collection of standardised styles:

  1. Develop a set of mixins for the various standard parts of the style and then just call them in the elements where you want them
  2. A set of less files for common style features on a page that are imported as they are needed/wanted

After a bit of of a play around with them both I came to the conclusion that using a set of imports for each style feature was the easiest to both maintain (change the file and just recompile your master) and easiest for other people to use. It promotes a nice clean code base and the style has a structure similar to the html you are trying to skin.

With that in mind my next step was to take this concept and turn it into a reality. Luckily we have an amazing creative department at work who have produced a set of internal guidelines for internal sites, from there each of the different parts of the common style are easy enough to breakdown to .less files. After a little while I’d managed to throw together the basics of the new .less style the results look a little like the below:

Main.less – A .less file into which all the other components are imported into and acts as the base for the style
GlobalNav.less – Contains the common global navigation
Masthead.less – Contains the style for the masthead, the user must set @mastheadBackground
Nav.less – Contains the menuing for the site – user must set @navAreaBackground and @navAreaHeight
Mixins.less – My common set of mixins, mostly containing font styles and a mixin to make lists horizontal.
Grid.less – The most awesome example of how awesome less.js is, instead of using a million divs to get a grid you can how just declare .960grid([numberOfColumns]) and the less works out the correct sizes for the div your in. So awesome!

A very simple example of this looks like:

@import "mixins.less";
@import "Grid.less";
@import "elements.less";

//We need to include the PIE.HTC file
@PIELocation: url(/Scripts/PIE.htc);

// Lets use sans-serif fonts
.sans-serif();

// SiteWidth
@siteWidth:960px;

// Global Navigation
@import "GlobalNav.less";

//Masthead
@import "Masthead.less";
@mastheadHeight:110px;
@mastheadBackground: #001133;

//Nav area
@import "Nav.less";
@navAreaBackground:#222;
@navAreaHeight:40px;

//Main content of the page
.mainContainer{

    // Container for everything - grid960
    .container();

    // A bit of top padding
    padding:15px 0;

    // This is only for demo purposes
    background:#d00;

    // The left side
    .left{

        // 8 columns wide and a demo background colour
        .grid960(8);
        background:#0d0;
    }
    .right{
    // 4 columns wide and a demo background colour
        .grid960(4);
        background:#00d;
        color:#fff;
    }

    // Make sure we clear everything
    .clearFix();
}

// Footer for the entire page
@import "Footer.less";


The other cool thing we’ve done with less.js is to include CSS3 PIE as a single variable, so we declare its position relative to the site root and position: relative. This gives us IE6, 7 and 8 compatibility with nearly stylesheet we author.

The other huge advantage of taking an approach using the less framework is that now when we fix a style defect in a project we can add it back into the less.js codebase and everyone can benefit from that meaning that hopefully going forward we can not only cut down on the amount of defects that make it into production we should also be able to cut down on the amount that are already in there.

This is just a taste of the power I’ve seen in less.js and I like it!!

Don’t tell me the future you where promised hasn’t materialised as a quick example nearly everyone I know has a device that:

  • Gives you a 10m resolution of your location ANYWHERE ON THE EARTH
  • Allows you access to the biggest repository of human knowledge ever compiled
  • Allows you to send and receive messages directly from a good 30% of the ENTIRE population of the earth
  • Has more computing power than the Apollo missions

Yeah tell me the future isn’t here yet…

The other week on the UK version of The Apprentice the task set by Lord Sugar was to create, market and release an app, the most downloads in 24 hours won. Watching The Apprentice normally makes me want to crawl behind the couch and shout obscenities at the way the teams go about things, you know the usual weak leadership, bitching and just general ignorance of at least 1/2 the team. But watching this episode made me want to cry.

How both teams totally ignored social media was totally beyond me.

The most obvious way of using social media in a task like this is to crack out a Facebook page – send an invite out to everyone you know and blam that should be at the very least a 10-50 extra downloads, at the most you’ve just generated thousands of downloads. In the same vein you could use twitter in a similar fashion. Follow as many people as possible to get people to them just to look at your latest tweet with a link to the ‘cool’ new app you’ve just created. Again in the worst case you’ve got a couple of extra downloads but in the best case you’ve got thousands.

In terms of these tasks repeat business and bad word of mouth matter very little, there is little to no forward thinking just sell, sell, sell, and get as many out of the door with as much profit as possible. In that situation social media tactics like those above would drive a quick spike of traffic to your product which makes it almost the perfect method to use in these high volume low quality situations. The downside is that as soon as people realise how poor the product is you’ll start gathering negative reviews but if those initial downloads in 24 hours are your only concern then who the hell cares?

Recently I’ve gone a bit of a data mining splurge. I’ve started calculating the distance I move each day, created a huge spreadsheet of ALL my spending and, the most common area that people data mine about themselves, working out how many calories I eat. I’ve started to look a bit more in to how I could possibly drill down in to these categories.

The obvious answer for drilling into the amount of exercise I get each day is to get something like a fit bit and a GPS tracker.

The fit bit is pretty much a fancy pedometer that tries to work out what your doing based on its 3d accelerometer. Now you could marry the information from the fit bit with a tracking program on your phone that uses the GPS and this would give you an actual distance travelled, what speed you did it at and how you did it, I assume here the fit bit is actually a little intelligent and can tell the difference between lets say walking and cycling. So that would be exercise taken care of.

The next two are a little more problematic to automatically data mine, I spend most of my hard earned cash in one of 2 places. The canteen at work and the local supermarket, at both of these locations I use a semi smart card. At work my campus card also doubles up as the payment card at the canteen, coffee stand and in the ‘corner shop’. The annoying bit about about this ‘smart’ card is that even though the data pertains to me I can’t get any of the data stored and I’m sure that they keep at a minimum how much I spend and when. With that information I’d be able to see the pattern of my eating everyday at work, time stamps and prices would give a good indication of what I’m eating and when I’m eating it as well as helping drill down into my finances.

The other ‘smart’ card I use on a regular basis is one of the big supermarkets loyalty cards. It a minimum they must keep a track of my spending to be able to dole out my loyalty points and I’d dare wager that they keep a damned sight more information than than. What I’d really love to get from them is a fully itemised list of what I buy, again this would help track my current total spend there (and on what).

Then with both lists I could essentially totally workout my entire diet, week by week and give a rough total calorie count of the food that I’ve bought. And thats just the start of my data mining ideas…

I have a simple question to pose to you, how easy is it to submit a bug report for an iPhone app?

The correct answer is, of course, near damned impossible and its not just the developers fault. Currently Apple controls 100% of the app process bar the bits that are genuinely vital for a developer such as source control and issue tracking. Sure its easy to submit and sell an app on the store but that is only half the battle, the more important half is the one that follows after a user has purchased an app and it breaks. Sure there are crash reports but they only tell you when your app has crashed, if you have a more subtle bug that doesn’t cause a crash then your out of luck.

Under the current regime there is no official way for the user to directly interact with the developer and tell them that they messed up and something needs fixing. No instead the only way to report a bug for a lot of apps is to leave a bad review. Its bad enough that this has a negative effect on sales but the worst bit is that if the review is in a different App store to the developer, then they are quite honestly nearly impossible to retrieve from the iTunes Connect interface. Realising this I tried to improve on this and added a link to my issue tracker in the product description for And Next.

Hurrah I thought, I’ve now given the user an easier way to give me feedback, all the have to do is click on the link and fill in a new ticket.

But it turns out that the App store doesn’t allow hyperlinks in the product description. So instead of the nice and easy, click and it’ll take the user to the issue tracker, the user has ANOTHER step to complete, who wants to have to copy and paste a URL to do someone else a favour? Honestly as a user myself I’d think to myself “Balls to that”.

So what can be done to make it easier for users to report a bug?

The easiest way for Apple would to simply allow hyperlinks in the product description, a developer could then link their issue tracker of choice. Obviously this has a huge drawback in that it would be thoroughly abused by pretty much everyone.

The a slightly more complex way would be to have another button under “(App name here) Support” titled something like: “Report a bug” which would then be linked the developers issue tracker of choice. A simple enough thing for Apple to do and isn’t really open to that much abuse.

The third and most complex implementation for Apple would be to have the same “Report a bug” button but rather than link you to somewhere have a form for the user to fill out that is then emailed to the user (or added to an Apple issue tracker), the advantage of this is that it is Apple ‘blessed’ and would more likely get more people submitting reports.

Job hunting is boring so I’ve been wondering if it would be possible to actually make a semi-decent war-walking app within 24 hours. I know that it’ll never live on the app store because Apple won’t make the API’s needed public (which is why you’ll never see my dissertation app on the store as well) but it seems like a semi decent idea to relief the boredom if only for 1 day.

I shall try and setup some way for people to see how I’m doing at various points of the challenge (most likely screenshots at certain intervals) and I’ll be setting up a mercurial repository for you to all see the code.