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.
Want to know more about how Shine’s been using the cloud? Read the case study here.
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.
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.
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.
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.
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.
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.