Singletons Suck (aka Flux to Redux)

As previously mentioned (see ReactJS – Real World Examples of Higher-Order Components), we are currently re-building the core realestate.com.au property experience with ReactJS. While ReactJS may be the shiniest of a long line of JavaScript frameworks (see Derek Zoolander meme), we have been careful about pulling in new “hot right now” libraries until we felt the pain and really needed them. Cue Flux.

Flux-Capacitor

Continue reading

The worst thing in our Scala code: Futures

Author’s note: this isn’t an argument against Futures, there’s nothing wrong with them as such!  This article is about good abstraction and proper separation of concerns when using them.

The aims of functional programming are much the same as any other discipline of software engineering: modularity, abstraction, low coupling, high cohesion, and so on. While the techniques and terminology are often new to developers, the goals and benefits are expressible in very familiar language because it’s all software, and we’re trying to achieve the same thing! (Read SICP for more background on software engineering fundamentals expressed with functional ideas).

Continue reading

How We (Mostly) Survived The Stormy Apocalypse!

It’s not news to anyone any more, so I’m sure everyone knows Amazon Web Services (our major cloud infrastructure provider) suffered an outage within one of their availability zones on Sunday June 5th. AWS is split up into various geographic regions, and within each region, a number of availability zones. I’m going to assume most readers know about this, but if you don’t, check out Amazon on how they describe these things. On Sunday one of these availability zones suffered a “power event”, owing to Sydney’s wild weather on the weekend, bringing it to its knees. Lots of Australian based websites had major problems.

Continue reading

ReactJS – Real World Examples of Higher-Order Components

A Little Bit of Background

Here at REA Group, we've recently been working on a new UI for the core property search experience on realestate.com.au. We've been building this UI as a universal javascript application, supporting both server-side and client-side rendering, using NodeJS and ReactJS.

During this project, we came across a few different use cases for some cross-cutting concerns, such as page load tracking, toggling new features on and off, and desktop/mobile toggling. We wanted to implement these in a generic and reusable way to avoid code duplication. For example, we had different pages (routes) in our application, and wanted to track user visits to those pages, but didn't want to duplicate this tracking code for every route.

We initially used React mixins for some of these problem, but ended up replacing it with higher-order components. In this blog post, I'll first provide a brief introduction to higher-order components (HOCs), and will then go through our journey for each use case and will explain each of the aforementioned techniques (mixins and higher-order component) in more details.


Continue reading

Securing third party applications

Our IT Security and Risk (ITSR) team is almost invisible to the outside world, yet is quite influential amongst our technical teams. The ITSR team is constantly searching for patterns to improve our security posture, and proposes—and sometimes implements—approaches to ensure that REA Group’s infrastructure stays as secure as possible.

In this article we will uncover some “behind-the-scene” approaches implemented by the ITSR team as a proof-of-concept solution to showcase the technology.

In the modern world it is almost impossible to create an infrastructure purely based on the “in-house” solutions and products where every single line of source code was audited. Therefore, companies are relying on a myriad of third party components which source code is either inaccessible (e.g. proprietary software) or was not audited.

To make the matter worse the majority of vendors do not follow IT Security best practices and their products are usually using excessive sets of privileges. For example, instead of providing an SELinux policy module tailored for their application they simply state that the first installation step is to “disable SELinux”. This approach is clearly understandable from the business point of view (e.g. the support cost is lower), but is not acceptable from the security point of view.
Continue reading