What we do here at REA is super serious business, but I came to REA for a different reason entirely. Because of technology. It has the capacity to be creative, fun and simultaneously, it can deliver value.
It is no secret we have a lack of talent coming into IT here in Australia. I believe that the reason behind this is how software development is perceived in the community. Hacking in popular media is presented as a Matrix-like activity, where we “wire in” and the computer and our bodies become one. We have a pride in complexity, and through the grad programme, I’m starting to understand why. Unfortunately it doesn’t make it easy to enter into our industry.
Instead of just sitting back and complaining about the lack of software developers, REA has decided to step up and do something about it.
I joined REA’s Consumer & Brand Delivery Engineering team 8 months ago, it’s been a blast and I love working on the tech we use. We extensively use Docker, AWS, and Ruby to produce internal tools such as `shipper` that other teams use to ship their containerized applications.
We host our own Docker Registry, and we maintain a set of base images, such as `ubuntu-ruby2.2` which is an image based on the official Ubuntu, with Ruby 2.2 and a few other dependencies baked in. We want the teams at REA to use those images, because we control how they are built and we include libraries and dependencies widely used in the company. Continue reading
In June 2015, REA Group Senior Developer Daniel Heath came across an internal ad outlining a secondment opportunity: ‘Need food, shelter and a software developer – please help.’ The role was looking for a passionate software developer to help work on a national initiative with a real social impact. He decided to throw his hat in the ring and was the successful applicant for the role. Continue reading
We’re big fans of continuous deployment here at REA. Merging a pull request and seeing the changes flow all the way to production in a matter of minutes is really awesome. Unfortunately, even with a large number of automated tests, this also makes it possible for an uncaught bug to flow all the way through as well.
We recently experienced this when some new cache-busting code was mistakenly committed and caused our landing page to use a non-existent CSS file. Fortunately we noticed quickly and so the user impact was minimal, but it highlighted that the tests in our deployment pipeline were not as effective as we would like them to be. Continue reading
Recently, we refactored one of our micro-services in order to apply the Each library. Each is a macro library developed by Thoughtworks that converts native imperative syntax to scalaz‘s monadic expressions. This means that we can write, among other things, asynchronous code with Futures in a plain imperative style.
The micro-service is a Scala application that serves as a RESTful server. It receives requests from browsers. For each of the requests, the micro-service fetches data from other internal RESTful servers, composites these data into one response, and sends the response to browsers.
A few months ago, my colleague Chris Myers and I used some basic category theory concepts to guide us to a design that elegantly solved a problem in a Java codebase.
It isn’t the only way we could have arrived at the design; anyone could have done it, really! However, you might find it interesting to see what practical application of these ideas can look like. Importantly, category theory gives us a framework to shed light on what makes many good design concepts useful, and why. Continue reading