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.
A few months ago I joined an exciting project with fellow Shiner Graham Polley, who you might know from such hits as Put on your streaming shoes. This is a follow-up article, discussing the elegant way in which we solved a hideous asynchronous limitation in PHP.
My role on the project was DevOps-based, and I was there to build some infrastructure using Amazon Web Services. As the cool kids would put it, I was there to put our client’s enterprise application INTO the cloud, or, more succinctly, to build a solution coupling services from two rival cloud service providers and provide a new league of scalability and flexibility.
The solution was pretty simple, but, like any simple solution, the little complexities come out along the way, and when you’re least expecting them.
I’m going to confess something. I’ve been harbouring a terrible secret for the last few years. It’s something that I’ve tried to keep hidden away from my peers for a very long time so as not to be labeled as “that guy“. Something I’ve kept buried deep in the depths of my darkest closet. Ok, maybe I’m being somewhat melodramatic. Pray tell, I hear you say, what is it?!
Well, it’s that I enjoy writing documentation. From the lowliest code comments through to high level architectural documentation. I enjoy it all.
UX Australia 2014 Redux was a one day Melbourne based recap of UX Australia’s 2014 Sydney conference. It was a chance for those who had missed out to see the most popular presentations. The following is a brief overview of the presentations.
Anyone who’s ever had to support server infrastructure of any kind knows the value of having a comprehensive, automated monitoring solution in place. With this in mind, we have begun to roll out the New Relic platform to monitor all our AWS based servers. New Relic comes with many great monitoring metrics straight out of the box, but still has the flexibility for software developers to create their own plugins for customized metrics on just about anything your users will care about.
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:
- Initial annoyance at having to do it
- Slow progress reworking sections of markup
- Growing satisfaction that the app was becoming accessible to a broader audience
- 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.