The Big Day In is an event designed for both High School (Years 9-12) and University students interested in careers in technology. Over 6,000 young people will attend events around the country to hear about the ICT industry.
“We’re looking for passionate speakers who have something valuable to say to students who are contemplating a career within ICT. ”
-John Ridge AM, Executive Director of the ACS Foundation
Sign us up!
REA’s Enterprise Technology Services team sent a delegation on a trip to the US recently to engage with other internal IT Support teams. We swapped notes and benchmarked ourselves against some of the best in the business (think Box.com, Zendesk, Okta, et al). We learned plenty about ourselves and certainly one thing which we are not is a help desk. I published the following blog internally at REA to contextualise and articulate to the business who we are, what we do and where we are going—and we why aren’t a help desk! Enjoy the read. Continue reading
Welcome to the new home of the REA Tech Blog: http://rea.tech/
This blog is about technology at REA Group, and we’re bigger than just our Australian property site. The new domain name reflects that, as well as being shorter—easier to remember, easier to type!
Please update your bookmarks and feed readers. 🙂
A Little Bit of Background
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.
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.
In part one of this blog series, we introduced a monadic macro from the Each library, and showed how it can simplify asynchronous operations. In part two, we will investigate how to gain testability without mocks and stubs, and still keep transparency from the business point of view.
Two years ago, Ken Scambler wrote a blog To Kill a Mockingtest,
which describes why we should use the command pattern to wipe out side effects and enhance testability. In this article, we will see how to implement the command pattern with the help of Scalaz and the Each library.