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.
Geospatial information analysis normally requires pretty complex calculations and transformations between different representation types. The Google Maps APIs are a great tool because they hide all the complexity of these operations. However when the geospatial information that you need to analyse is not from Google Maps, things get more complicated.
Operations like finding polygons representing geographical places, or finding polygons that intercept other polygons, require a lot of time and intricate code to have any acceptable solution.
At Shine we are working on a solution for a big telecommunication customer that requires being able to query large geospatial databases without degrading performance.