The best piece of advice I ever got regarding a personal software development process was from a grizzled old Unix developer with a neckbeard. OK, that’s not true – it was actually from a clean-shaven principal consultant and architect at a company I used to work at, but that doesn’t sound nearly as impressive.
Nevertheless, the process went something like this:
Think a bit
Code a bit
Test a bit
Go to Step 1
Having tried all manner of processes over the years, this is the one that has served me best. Let me break it down for you if you’re having trouble understanding it.
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.
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.
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.
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.
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 😉
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.
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.
Shine Technologies Senior Consultant Marc Fasel is speaking at JavaOne Shanghai this week. His topic is “Implementation of Continuous Delivery on a Enterprise Java Stack”. If you’re attending the conference, he’ll be speaking on Thursday from 12pm-1pm. Drop by and say hi afterwards!