Rich Object Models & Angular.js: Memoization

stringonfinger

In my previous post on getter methods and Angular.js I showed how complex calculations can be hidden behind simple Javascript properties. One downside to this technique is that we can start to get a little blasé about when calculations are actually being executed. This can in-turn lead to performance issues.

In this post I’m going to talk about expensive calculations in rich object models – be they hidden behind getter methods or just regular methods – and how we can use memoization to reduce the impact that these calculations have on performance. Memoization isn’t something that you should use all the time, but for use-cases involving long chains of calculations it can be an effective optimization technique, especially within a framework like Angular.

If you don’t feel like reading, you can always jump to the part of my ng-conf presentation that covers memoization, or go straight to the Github project. Either way, I’m assuming that you’re familiar with the foundational concepts I introduced in the first post in this series.

Rich Object Models and Angular.js: Getter Methods

Sadly not all getters can be giant robots

In my earlier posts on Rich Object Models and Angular.js and Angular Identity Maps I’ve shown how, by introducing a rich object model to your Angular.js application, you can begin to employ more sophisticated techniques for modelling your business domain.

In this post I’m going to demonstrate how we can simplify business logic by using getter methods to hide complex calculations behind properties. Furthermore, we’ll do it in a way that slots in nicely with our existing rich-object model. If you don’t feel like reading, you can check out the section of my ng-conf presentation that covers this or go straight to the Github project.

Rich Object Models and Angular.js: Identity Maps

angularIdentityMap

In my previous post on Rich Object Models and Angular.js I introduced a simple strategy for setting up rich object-models in Angular.js. It turns out that once we’ve introduced the notion of a rich object-model, a number of more advanced object-oriented programming techniques become easy to implement. The first of these that I’m going to discuss is identity maps.

In this post I’m going to talk about what an identity map is, why you might need one, and I’ll introduce a simple identity map implementation for Angular.js. I’m going to assume you’ve already read my foundational post. If you’d like to see the portion of my talk at ng-conf devoted to identity maps, jump to the video.

Rich Object Models and Angular.js

screenshot
Another sort of rich model

Angular.js is deliberately un-opinionated about how you should structure your data models. Whilst it lays out very clear guidelines for directives, controllers and services, it also makes a selling-point of the fact that it can bind to plain-old Javascript objects with plain-old properties.

Services are singletons, so it can be unclear as to if and how you can group per-object state and behaviours.  Consequently, people tend to fall back to services that deal in very simple JSON objects – i.e. objects that contain only data, not behaviour. However, building the sorts of rich interfaces that our users demand means that we sometimes need to more fully leverage the MVC pattern. Put differently, for some problems it can be useful to have a rich object model that provides both data and behaviour.

Recently at ng-conf, I presented a simple approach I’ve used for using rich object models with Angular.js. This technique leverages existing frameworks, maintains testability, and opens up a range of possibilities for more succinct and easy-to-understand code. In this post I’ll outline the underlying approach, but you can also find some (very simple) helper code here.

Backbone Antipatterns

200px-Skull_and_crossbones

Backbone.js deserves a lot of credit for bringing MVC to mainstream client-side Javascript development. That said, many beginners ask what the ‘right way’ of doing something with Backbone is. The bad news is that there’s not necessarily a ‘right way’ – it all depends on the problem you are trying to solve. The good news is that there are definitely some ‘wrong ways’ that you should avoid on your way to finding the right solution for your particular problem.

In this post I’ll cover some of these anti-patterns, as well as some general advice for the new starter. I’ve ordered the anti-patterns roughly by significance from the major to the more trivial. Don’t be too upset if you’ve done something on this list – I’ve made most of these mistakes myself 😉

Shine wins two awards at 2013 Australian Mobile Awards

Image
Shine Principal Adam Kierce and UX Lead Sri Elkins celebrate at the awards ceremony

We’re excited and proud to announce that we’ve won in two categories at the 2013 Australian Mobile Awards!

We won an award in the ‘Productivity App’ category for Teamstuff, an app designed and developed entirely in-house by Shine.

Next up we were a winner in the ‘Sales Force’ category for the EnergyAustralia Digital Sales Experience web app, which we designed and developed for EnergyAustralia.

Congratulations to all at Shine who worked on these apps, and we look forward to building more great mobile apps in the future!

Backbone Is Not Enough

Having spent the last 18 months or so working with Backbone.js, I’ve formed the following opinion: Backbone is not enough for building large single-page applications (SPAs).

Sure, you and your team may be able to get your app across the line, but you’ll probably end up with a lot of code and may even reinvent a couple of wheels unless you’re extremely diligent about refactoring, code reviews, documentation, testing and keeping up with an ever-evolving suite of best-practices.

TEL: Shine’s Technical Excellence and Leadership Group

TEL Image

In the last two years, Shine staff have spoken 5 times at conferences in Australia and overseas. We’ve done 10 user group presentations around Melbourne, and posted 37 entries to this blog – not including news items and conference reports.

As a result of all this activity, traffic to the blog has increased by a factor of 10. We’ve had new hires tell us that our blog entries and presentations were an influencing factor in their decision to join us. We now have staff who are organisers for local technology meetups, some of which are hosted at Shine HQ. And we’ve even seen a couple of our blogs and presentations act as catalysts for new client engagements.

Why am I telling you this? Because all of this activity hasn’t just been a random occurrence. Instead, it’s been part of a deliberate and sustained strategy. In this post I’m going to talk about how we’ve done it.

Testing Backbone Views with QUnit and Sinon

Clock parts

Unit-testing Backbone Views is hard. You need to cover enough for the test to be meaningful (for example DOM updates and server calls), without getting too tangled up in gory details. In this post I’ll talk about how we use QUnit and Sinon.JS to unit-test our Backbone views.

There’s already material out there on using these frameworks together, so I’m not going to get into setting things up. However, having done it for a year now I feel I’ve learnt enough additional tips, tricks and traps to warrant sharing them with the world.

This post will cover the three things you have to think about when testing Backbone Views, then talk about three strategies for simplifying your tests. I’ll also share some more general thoughts on Backbone’s suitableness for building large apps.