Backbone Boilerplate Vs. Rails Asset Pipeline

We recently shifted from Backbone Boilerplate to the Rails Asset Pipeline for generating the various assets (Javascript, CSS, HTML, images, etc) that comprise, a single-page app. In this post I’ll talk about our motivations for making the shift, what we had to change to get there, and how the end result turned out.

Amazon Web Services Publish a Case Study on Shine in the Cloud

Into things Cloud-related? Amazon Web Services have just posted a case study on how Shine (yes, that’s us) is migrating mission-critical installations of our products from customer’s on-site infrastructure to the cloud.

It also covers how Shine has used RDS and Provisioned IOPS to achieve significant performance improvements (a topic we’ve also previously discussed in detail).

Shine principal Adam Kierce gets a few choice quotes in there, and the case study offers a terrific insight into the cost benefits that the cloud can bring to our customers.

We’re raving fans of AWS, as demonstrated by our recent attendance at the re:Invent conference in Las Vegas and sponsorship of the AWS Customer Appreciation Day in Sydney.

Want to know more about how Shine’s been using the cloud? Read the case study here.

JSConf Down Under: A Conference Report

I attended JSConf Down Under yesterday. The conference format was quite straightforward: one day, one stream, nine speakers. In this post I’ll talk about the three things at the conference that had the biggest impression on me: Brendan Eich’s presentation on The State of JavaScript; Isaac Schlueter on the new Node.js streams; and the JavaScript community as a whole.

Efficient Stateful Views With Backbone, Part 2: Collections & Animations

In Part 1 of this blog series, we saw how UI state could be maintained efficiently in a Backbone app by introducing view-management infrastructure and retaining references to views. In Part 2, I’m going to talk about how this strategy can be extended to views of collections. I’ll also discuss some alternate approaches to the problem of efficient stateful views, and why I chose the approach of retaining references to views. Finally, for bonus points I’ll discuss how to manage portions of your UI that transition their state via animations.

Efficient Stateful Views with Backbone.js, Part 1

One of the good things about single-page apps is that it’s possible for them to remember UI state within a page. If an area of the page is hidden from the user, and then redisplayed later, you’re able to display that area in the same state that it was left.

This is in contrast to traditional request/response apps, which are mostly stateless, and where maintaining the state of finely-detailed UIs across requests quickly becomes impractical.

However, done carelessly, retaining view state in a single-page app can result in drastic memory leaks over time as the user navigates through the UI.

I’m going to describe a strategy that we’ve used to efficiently maintain stateful Backbone.js views in a large-scale app. In this post – the first of two parts – I’m going to give an overview of the problem, introduce some memory-management infrastructure, and then propose a solution for simple views. In Part 2, I discuss how to handle collections and animated elements. Note that these posts assume experience with Backbone.

On Pair Programming

Working on a project that used pair programming was something that I’d wanted to try for a long time but had never had the opportunity to do. Consequently, when a chance came up to work on a project where the entire team was pair-programming full-time, I was ready to get on board and give it a go. In this post I’ll talk about my experience, some of the benefits I saw, and some broader conclusions that I reached.

How to Stop Cucumber Becoming Technology Roadkill

I’ve worked on a number of projects with Cucumber now, and I think it is a terrific tool. However, I’ve been seeing it used in ways that it was not originally intended for, the consequence being acceptance-test suites that grow increasingly slow, brittle and difficult to maintain.

These problems occur when developers start using Cucumber to drive overly-detailed tests. The problem of excessive UI testing with Cucumber has been blogged about in the past by Aslak Hellesøy – the creator of Cucumber – but I thought I’d cover some of my own experiences and opinions in this post.

Building a shared calendar with Backbone.js and FullCalendar: A step-by-step tutorial

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.

Cascading Select Boxes with Backbone.js: A Step-by-Step Tutorial

What happens when you don’t use Backbone

Up 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.