Author: Ben Teese

Every couple of months I'm in a meeting where a couple of developers start arguing about which HTTP status codes to use in their RESTful API, or where they decide to not use HTTP status codes at all and instead layer their own error-code system on top of HTTP.

In my experience, HTTP status codes are more than adequate for communicating from servers to clients. Furthermore, it's preferable to stick with this standard, because that's what most client and server-side HTTP libraries are used to dealing with.

When it comes to which status code to use, the truth is that most of the time it doesn't matter, just so long as it falls within the correct range. In this post I'm going to outline what the important ranges are, and when you should use each one.

If you control both the client and server, these guidelines should do just fine. If you're writing a more generic RESTful service where other people are writing the clients, you may have to be a bit more nuanced. Either way, this rule-of-thumb is a good starting point to work towards the simplest solution possible for your particular problem.

The ES6 spaceship has landed and promises are amongst the first new features to come down the ramp. I'm very excited about this. This is because I love promises. They've been lurking around for years in different incarnations, but now that we've settled on a standard, I think now's the time to learn them if you haven't already. So in this post I'm going to talk about what promises are, why they're awesome, and how you can start using them right now.
[caption id="attachment_6264" align="alignnone" width="500"]berlin_-_old_and_new A clash of the old-school and new-school[/caption] Over the last couple of years at Shine we’ve built a number of Single Page Apps (SPAs) for large businesses. An app we recently built had to integrate with Oracle Access Manager (OAM), an Identity Management System (IDM) from everybody's favourite enterprise software company. In this post I'm going to talk about a strategy that we used to successfully work around mismatches between the way that SPAs and OAM do things.
1_5_3_1_Chicken_Egg We love Git Flow. It's awesome to have a standard release process where everybody is using the same terminology and tooling. It's also great to have out-of-the-box answers to the same questions that get asked at the start of every project. For example:
  • "How are we going to develop features in isolation?"
  • "How are we going to separate release candidates from ongoing development?"
  • "How are we going to deal with hotfixes?"
Now it's enough to just say 'We use Git Flow', and everybody's on the same page. Well, mostly. Whilst Git Flow is terrific for managing features and separating release candidates from ongoing development, things get a little hazier when it comes time to actually release to production. This is because of a mismatch between the way that Git Flow works and another practice that is common in large development projects: immutable build artifacts.
blindfold I recently did some preliminary work adding accessibility support to an existing Angular application. At the start of this work I knew very little about website accessibility, and I suspect the evolution of my thinking during the process would be common amongst other developers who have been in the same situation. Specifically:
  1. Initial annoyance at having to do it
  2. Slow progress reworking sections of markup
  3. Growing satisfaction that the app was becoming accessible to a broader audience
  4. The realisation that the codebase itself was actually better off for the process
In this post I’ll talk about the 3 things that I’ve done so far during this journey to an accessible Angular app: accessible icons, keyboard navigation and finally, ARIA support.

think-a-bit

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:

  1. Think a bit
  2. Code a bit
  3. Test a bit
  4. 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.

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.
[caption id="attachment_5153" align="alignnone" width="384"] Sadly not all getters can be giant robots[/caption] 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.