August 2011

Introduction There have been many good examples of using Hudson for cross-platform builds and automatic execution of tests, but Hudson also provides a great environment for empowering non-developers to execute particular tests whenever they want. We have found this to be particularly the case when automating data migration tests. This article will discuss the what automatic data migration testing is, and how Hudson can make it easier. Whilst it refers to Hudson, the same techniques could also be used with Jenkins.
The asynchronous event-driven I/O of Node.js is currently evaluated by many enterprises as a high-performance alternative to the traditional synchronous I/O of multi-threaded enterprise application server. The asynchronous nature means that enterprise developers have to learn new programming patterns, and unlearn old ones. They have to undergo serious brain rewiring, possibly with the help of electroshocks. This article shows how to replace old synchronous programming patterns with shiny new asynchronous programming patterns.
In a prior post, I explained how Backbone.js can be used to implement cascading select boxes. However, this was pretty much just a read-only affair, and these were relatively simple HTML elements. How does Backbone fare creating, updating and deleting data via a much more complex UI component? I recently had the chance to build a shared calendar tool with Backbone and FullCalendar, a jQuery plugin for a full-sized calendar with drag-and-drop capabilities. I was quickly able to get them playing nicely with each other, and in this entry I'll cover step-by-step what it took to get there.
I got home from Portland, OR terribly jet lagged on Monday morning, but buzzing from my trip to the US and my experience as both an attendee and speaker at O'Reilly OSCON. Now that I've caught up on some sleep, it's probably about time I reflected on last week.
What happens when you don't use BackboneUp until recent years, client-side Javascript development has resembled the wild-west from a software design perspective. Libraries like jQuery have certainly helped, but with the rise of Single-Page Applications, jQuery alone doesn't provide enough of an overall framework for large-scale client-side development. Fortunately, there's been a recent proliferation of Javascript MVC frameworks, both large and small. Backbone.js is one of these. It's lightweight, works with jQuery (although it doesn't need it) and seems to have some momentum behind it at the moment. Backbone.js isn't particularly large or opinionated in the manner of say, Rails. For an expert, that might be a good thing. But for a beginner, it's not so good. The API documentation is complete, yet joining the dots can be a little intimidating at times to a newby. Simple tutorials abound that describe how to hook up a single view to a single model, but it's unclear what approach to use for more complex UIs. What should be in a model and what should be in a view? How should models and views interact with each other? I have recently had the opportunity to work on a non-trivial Backbone.js application. In this entry I'll try to present an example that is slightly bigger than your average single model and view. Furthermore, I'll present it in a manner that is iterative, rather than just dropping the whole thing on you in one hit. You'll see that Backbone.js provides a good basis for building apps in an MVC style, although you will be faced with the same design decisions you'd have to make with any other MVC framework. Note that this isn't an introduction to Backbone.js, and assumes a little background knowledge of how the framework works.
When I first started learning Objective-C and the iOS SDK 2.x a few years ago, one thing that I constantly struggled to get my head around was Interface Builder.  More specifically, why should I use it and how it could possibly benefit my iOS development - given that I could code a UI programmatically, and know exactly how it all worked? A colleague of mine even wrote a blog entry that mirrored my exact feelings towards Interface Builder back then. Well over the past 6-12 months my attitude towards Interface Builder has changed. There are two reasons for this. Firstly, it's now nicely integrated into XCode 4. Prior to that, who wanted to have 2 different apps running (XCode and Interface Builder) with popup windows spamming your desktop? That was a deal-breaker for me. Secondly, I'm now a more experienced developer. After using Interface Builder on a couple of projects, I am confident to say I am now more efficient as a developer when using Interface Builder. However, that wasn't always the case, which leads me to my key message here:
If you're new to iOS development, don't touch Interface Builder until you are capable of building UIs programatically.
Shine Technologies has recently completed a proof-of-concept migrating the hosting of two of its enterprise products into the cloud - specifically, Amazon Web Services (AWS). This post is aimed at technical managers interested in leveraging cloud technologies to provide new and powerful options to both existing and new clients of established products. We'll first give a quick overview the products, and then explain why hosting them in the cloud is beneficial for us. We'll then finish off with a couple of things we've learnt whilst getting our products going in the cloud.
Recently we released an iPhone app to the iTunes appstore which contains consumable products that can be purchased by a user.  I want to share with you some of the pain we encountered when the app went live, and what errors we came across when configuring our server from sandbox to production.