Java to Scala cheatsheet

We’ve started some new work in Scala!  Most of the back-end developers in the Residential team have a Java background though,  so we put together this cheatsheet to help get the team started.

Scala does almost everything Java does, plus a whole lot of useful functional stuff.  There’s a direct analog in Scala for almost everything in Java.

Keep in mind though, real idiomatic Scala needs a bit more than just Java semantics — there’s lots of really powerful and useful functional features and idioms that you can learn as you go.

Annotation declaration

Java Scala
@interface Foo {

}
trait Foo extends StaticAnnotation {

}
  • There is no special syntax for annotation definitions.
  • An annotation has to extend scala.Annotation, or one of its sub-traits.
  • Scala’s compiler will stitch it into the necessary bytecode form for use in Scala or Java.

Continue reading

Meet our CIO – Captain Agile!

Captain Agile Minecraft Avatar

Nigel’s Minecraft avatar – Captain Agile!

Nigel Dalton, our Chief Information Officer, is a great champion for the engineering and innovation culture at REA. Here’s an interview Nigel recently did for CIO Magazine published in full to give you an insight into his psyche.

What’s your name and title?
Nigel Dalton, REA Group’s Chief Information Officer. I also have a role as an executive coach for our team that runs the Commercial real estate line of business within REA Group in Melbourne.

What’s your professional background? How did you get to where you are today?
Social scientist, not an engineer – but I have a passion for machines that has proven powerful when combined with an innate passion for people. I have worked globally in both IT and business roles (marketing, sales, product and service), and often in the twilight zone between those more traditionally defined professions – in modern digital companies, they are the same thing.

Continue reading

Relaunching the REA tech blog

Hello World! It is the REA tech blog here!

Yes, we know you’ve been thinking that there’s nothing happening here anymore. We hear you say, “You’ve not written, you’ve not tweeted, there were cracks in your home page HTML and we thought you’d left without telling anyone”.

Well we’re excited to announce we have not left. We have just been deeply immersed in our tech caves, indulging ourselves in what we love doing – playing with new technologies, experimenting with methodologies and carving out new user experiences.

Until somebody said the other day, “Hey, we forgot to blog about all this”. So we’re making a renewed effort to share back to the community that we get so much from.

Continue reading

Are you responsive to your users?

Responsive web design has been pretty hot for a few years now. As online products and services jostle for our attention it’s imperative that your digital wares are available whenever and wherever your customers want.

But is responsive the golden hammer? The utopian solution for every single website?

There is no single perfect solution, it ultimately comes down to your particular requirements.

REA has an award winning iOS app. We have an incredible mobile optimised website. We have one of Australia’s most visited websites in our flagship ‘desktop’ site.

We have also embraced responsive on a few sites including our careers portal, the all new retirement living section and the share accommodation sites which now provide a multi screen experience in a single application.

There are a few key things to evaluate when deciding between a dedicated mobile experience versus a responsive, single application.

Continue reading

Loading Google Maps with RequireJS

Recently at REA, we’ve started to use RequireJS on a few projects to help modularize our Javascript. I came across a fairly subtle issue when trying to use the Google Maps JS API with RequireJS which I thought was interesting.

Here’s our situation:

  1. We want to load google maps and let our code treat it as an AMD module.
  2. We have several third-party libraries that depend on Google Maps and aren’t AMD modules; we of course want to treat them as AMD modules so we’ve shimmed them.
  3. We want to use r.js to build a single JS file for production.

Because Google Maps loads asynchronously, we can’t simply shim it. Miller Medeiros’ async plugin seems to be a common (and good) solution to this problem. His blog post describes the technique, but it doesn’t mention a couple of potential gotchas to do with shimmed modules and single-file optimized builds.

With the async plugin, Google Maps is a “real” AMD module from RequireJS’ perspective. As explained in the RequireJS docs, shimmed modules can’t depend on real modules, because RequireJS has no way ensure in the built file that the shimmed module executes after the real modules it depends on.

This implies that in the built version of the code, we’ll need to load the Google Maps API separately, before all our RequireJS modules (what the RequireJS docs refer to as “CDN loading”). But we’ll also need a way to load Google Maps via the async plugin, only in the non-built environment (otherwise we’d get two copies of Google Maps after the build).

So our complete solution consists of a gmaps.js containing:

define(['async!http://maps.google.com/maps/api/js?v=3&sensor=false&client=gme-nsp&channel=new-homes-app'], function () {
return google.maps;
});

as in the blog post, but for the built version of the code, we created a gmaps-stub.js containing:

define(function () {
    return google.maps;
});

and in our build config, loaded the stub instead:

paths: {
    gmaps: 'gmaps-stub'
}

This lets us meet all three of the above requirements.