TypeScript, Flow and the importance of toolchains over tools

EDIT: The initial version of this post stated that the TypeScript compiler won’t emit code if it finds errors in the source. This is not correct. By default, the compiler will emit code even if it detects errors, unless the –noEmitOnError flag has been set. This post has been updated accordingly.

I’ve recently been working on a project that uses TypeScript. I also have been playing with Flow on a personal project. In this post I want to talk about why I think these tools are important, some of the fundamental differences between them, and why the choice of which one to use might best be determined by the broader toolchain that you are working within, rather than just the particular technical merits of one or the other.


YOW! Connected 2016: The typed-functional future of UI platforms

I just spent a couple of days at the YOW! Connected conference and had a great time, despite nursing a bit of a cold. There were a tonne of great talks at the conference covering a wide range of topics, but in this post I’m going to briefly reflect on one specific trend that interested me at the event: the way in which UI platforms are advancing to adopt modern languages, and are even influencing each other in the process. The end-result: they’re all moving towards languages that are both functional and statically typed.

Full disclosure: This year I was a member of the programme committee for the conference. So in writing this post, there’s a bit of a risk that I’m creating an echo chamber for myself. All I can really say in my defence is that I hadn’t consciously made these connections in advance – it was only afterwards that I saw a trend!


Shine’s Michael Leroy to speak at Adobe Source event


Shine developer and resident AEM expert Michael Leroy will be speaking at the Adobe Source event being held in Sydney on Oct 12 and 13.

Michael will be presenting twice. The title of his first talk will be “Building a corporate site solution using Multi Site Manager”. This will be based on the work Shine does at Medibank with AEM. Secondly, inspired by a topic he has previously blogged about, Michael will do a short talk on “Style Guides and AEM: Fitting a square peg in a round hole”.

For more information, go to


The most important thing when picking HTTP status codes

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.

ES6 Promises are here!

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.

Integrating Single-Page Apps with Oracle Access Manager

A clash of the old-school and new-school

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.

Git Flow and Immutable Build Artifacts


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.

Getting Started with Angular and Accessibility


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, Code a Bit, Test 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.