Travel blog: Vietnam day 1

Day One in Vietnam.

We arrived in Ho Chi Minh City at around midnight, and it was a lot like walking onto the set of some sixties war movie. The border security look like they are in slightly overdone third world bad guy costumes, complete with the communist style army caps. We spent half an hour or so walking up and down looking for our airport transfer, who had clearly opted for bed instead of a very late night pickup.

Once we gave up on our transfer we tried in vain to find a sober taxi driver. I picked one who seemed sober, or at least could pass for vertically capable. He then grabbed one of our cases and took off into the parking lot. We chased him down and caught him at a people mover, and then we negotiated a fare. A second person then came to renegotiate and round up, and insisted “tip tip tip”. We then did a circle round the parking lot, and they swopped drivers. again. The new one seemed half sober so we got our hopes up. He proceeded to grab my wallet and audit it for me, just to make sure I didn’t have anything in there he would like to relive me of. After this display of kindness we felt we had found the man to take us to our hotel… but after another circle round the parking lot they swopped back to the first guy.

We finally left the parking lot, after the first taxi driver had told us “not happy” a few times. My wallet was the equivalent of twenty dollars lighter, and we drove four minutes down the road to our hotel.

Vietnam is a funny place, and it’s 2am – we haven’t even started yet.

Culture Eats Your Strategy for Breakfast

In May I presented at the Web World Forum, a part of World Forum Disrupt Sydney 2017.  I spoke about how we were trying to shift our culture in digital tech and product delivery at Domain to be even more focused on business outcomes.   


Link to the video of the full talk is here and the slides from my talk at the conference are ‪here

Hack 4 Homelessness

A fortnight ago, Domain supported and participated in a hackathon organised by Vibewire – #hack4homelessness.  Vibewire are a coworking space based close to Domain’s head office.  Vibewire focus on equipping young people with various business skills – and from what we’ve sen this seems to include a social conscience.  Vibewire focus on the youth, and homelessness disproportionately affects the youth so there’s a natural synergy there.  At Domain we want to see everyone in a home they are happy to live in, and so we found real synergy with #hack4homelessness too.

When we got together to discuss how we might be able to help, one of the first ideas that came up was the sharing of our Public API with all hack teams.  We launched our API recently and we’ve already signed up hundreds of users so we knew it would work well enough for the hackathon users.  We also framed a challenge for the hackers to tackle – how do we try help supply of housing meet demand.  We saw some very clever ideas emerge including requests for features our API’s don’t yet support.

One of the most inspiring things about the hackathon was seeing so many young people giving so much of their time and energy to work on problems that they do not stand to gain from solving.  The energy in the hackathon was palpable and the participants worked with amazing zest.  The pitch sessions at the end were fantastic as the participants spoke us through their lean canvases, occasionally showing that they’d learned a few new tricks out of the process themselves.

Most touchingly, the organisers had speakers talking about homelessness at the kickoff – but these were not merely presentations of statistics and charts.  Participants got to engage with people who work directly with the homeless, and even with people who have first-hand experience of homelessness.  This made the experience so much more palpable and real.

Domain were proud to support this amazing initiative – alongside several other supporters.  We look forward to supporting #hack4homelessness again in the future, and a shout-out to the Domain team members who gave up their weekends to support!

How we’re using Bots at Domain

Bots are all the rage in tech right now. They are the antithesis to virtual reality (VR) in that VR is all about the bling, while bots have no bling at all. Bots are all about pure functionality wrapped in a chat API. No graphic design, no UI. Just doing things.

One of our senior tech guys recently quipped that this is exactly why managers love bots – because at the most basic level, they’re that easy.

In a superficial survey I’ve identified eight active bot projects at Domain. Five out of eight of them are written using Python. The remainder are Node.js and Ruby. We’ve had a go-live rate of 75 per cent, which is remarkably rapid ROI. In the words of one bot builder; “seeing other people add my bot to new [Slack] channels made me happy.” The ones that haven’t gone live yet are likely to still go live in some expanded form.

The fundamental architecture of bots revolves around connecting web services and webhooks with each other. The bot component is a text / chat API in the middle of the web services. These architectures lend themselves very well to cloud hosted environments. We have all eight hosted in AWS in some form or another, with the majority being on EC2. Only one of them is using docker and running in a containerized environment, while another is running on Heroku.

  • There is a Cambrian Explosion of bot frameworks happening, and we’re seeing at least experimental use of the following frameworks:
  • – trainable bot framework
  • – a ruby based bot framework, originally inspired by Github’s open-source bot framework called Hubot
  • Facebook Bot Platform – used for the Domain chatbot that you can interact with on Facebook
  • – text based bot framework with intent parsing
  • Microsoft’s bot framework – a useful framework that includes the ability to create Skype bots. This was recently in the IT press.

When looking at the intent behind the bots we’ve built, we see two universal themes: Firstly, the ability to complete chatops style actions from Slack. Secondly, to perform basic functions without interrupting a user’s context. An example of this would be querying Home Price guide via Facebook Messenger, without ever leaving Facebook.

Some of the Chatops functions we have built include:

  • A bot that helps with certain Android related tasks
  • The ability to query our AWS account to get info on ASG’s directly from Slack.
  • Integrating third party SMS alerting into our Slack incident channel
  • We’ve also integrated the Google Vision API with Domain listings, and it’s possible to interact with it through Slack.
  • Where should bots be used?

One of the primary drivers of our bot projects has been the early adopter mindset. Most people working on bots are looking for ways to create genuinely useful bots to release to customers. Our Android Lead highlighted a couple of questions that showed where a bot could be useful:

  1. Which system or website do you hate having to go into and use and/or check?
  2. What type of simple but repetitive tasks do you have to do that you think should require less steps and/or time?

Tedious, repetitive tasks are in all likelihood going to be the first to be automated away by bots. This would include a large swathe of the tasks we currently use contact centres to resolve, which would free our CX teams up to focus on how to add more value to our customers

Two of the key considerations for building bots that will be more useful are the ability to retain context in a conversation, and the ability to learn and adapt to natural language. The way a programmer describes something is very often different to the way an end-user would.

According to the people building them, the biggest benefits of bots revolve around saving time by automating everyday tasks. In the Chatops context, one developer remarked; “bots bring information and processes from disparate systems to a central place where our team is already communicating, without the need to jump into external systems.”

Another of our developers remarked “Slackbots are great as developer tools. Primarily because developers love the command line, and this essentially allows us to “share” our scripts with everyone in Slack.”

“Consumer bots have a ways to go before they become mainstream. China is the furthest ahead with WeChat being one of the strongest platforms. The usability of the bots tied strongly with the e-commerce hooks make it a strong ecosystem to buy/sell/discover.”

As I see it, the power of bots is in tying natural language processing, machine learning, all our microservices and state/context retention together. I believe our next step will be to build a smart NLP bot that interacts across multiple platform – Slack, Skype, Whatsapp, Facebook… Wherever it can sniff out new people to chat with.

Disrupting the disrupted disruptor

I presented a talk at the recent Ignite Sydney event that was run recently. This event had a specific focus on Digital and tech. It’s worth checking out all the speakers. In coming up with a topic, I was having some fun with the industry’s abuse of the concept / word “disruption”. I spoke about changing an old, established, mature business to try deal with the shakes and shudders of being disrupted. The real point was about trying to create a change-oriented culture. My talk is on YouTube here

Arduino Hacking: RSS onto an LED Dot Matrix Display Panel

We’ve been playing with Arduinos for the last few weeks.  Yesterday I bought a Freetronics Dot Matrix Display (DMD) from Jaycar for $30 or so, and I’ve cobbled together a couple of scripts to drive some RSS content to it.  It works 🙂

I have a SainSmart Mega 2560, but there’s no reason this shouldn’t work with any Uno compatible. Note – this DMD doesn’t work with the Mega unless you overwrite a couple of files (Thanks @TheRevva for sharing)

Before starting, two ruby gems are needed – SerialPort and FeedJira -thanks @johndagistino [protected] for the steer.  It’s also worth spending time going through the code samples Freetronics have made available on github – linked at the bottom their product page

Note – I still have a problem with serial comms in that it doesn’t work unless I have the Serial Monitor open.

gem install serialport

gem install feedzilla


This is the ruby test script that I’ve used to grab two rss feeds, and pass the headlines in one at a time into to Arduino over the serial port.

require "serialport"
require "feedjira"

def showfeed(feedurl)
	#params for serial port
	port_str = "/dev/tty.usbmodem621"  #NB port may be different for you, copy this from port selected in Arduino IDE 
	baud_rate = 9600
	data_bits = 8
	stop_bits = 1
	parity = SerialPort::NONE
	sp =, baud_rate, data_bits, stop_bits, parity)
	feed = Feedjira::Feed.fetch_and_parse(feedurl)
	sp.write feed.title
	puts feed.title
	sp.write "   "

	feed.entries.each do |entry|
		sp.write entry.title
		puts entry.title
		sp.write "   "

And lastly, the Arduino sketch to drive the rss feed onto the display:

// dmd-rss.ino

#include "SPI.h"      
#include "DMD.h" 
#include "TimerOne.h"
#include "Arial_black_16.h"<arial_black_16.h> 
// you can remove the fonts if unused
#include "SystemFont5x7.h"

#define DISPLAYS_ACROSS 1   
#define DISPLAYS_DOWN 1       
/* change these values if you have more than one DMD connected */

void ScanDMD()

void drawText(String dispString, int scrollspeed) 
  dmd.clearScreen( true );
  dmd.selectFont( SystemFont5x7 );
  char newString[256];
  int sLength = dispString.length();
  dispString.toCharArray( newString, sLength+1 );
  dmd.drawMarquee(newString,sLength,( 32*DISPLAYS_ACROSS )-1 , 0 );
  long start=millis();
  long timer=start;
  long timer2=start;
  boolean ret=false;
    if ( ( timer+1000-scrollspeed ) < millis() ) {
      ret=dmd.stepMarquee( -1 , 0 );

void setup()
   Timer1.initialize( 5000 );           
/*period in microseconds to call ScanDMD. Anything longer than 5000 (5ms) and you can see flicker.*/

   Timer1.attachInterrupt( ScanDMD );  
/*attach the Timer1 interrupt to ScanDMD which goes to dmd.scanDisplayBySPI()*/

   dmd.clearScreen( true );            
/* true is normal (all pixels off), false is negative (all pixels on) */

void loop() {
  String content = "";
  char character;

  while(Serial.available()) {
      character =;

  if (content != "") {
  	dmd.clearScreen( true);
  else {



Continuous Deployment

I had a chat with Brett Winterford recently, a journalist writing for IT News, about continuous integration and continuous deployment (article here).  The essence of our discussion was focused on the question “Can legacy enterprise teams move into CI/CD”.  The answer to the question has to be yes, for a couple of reasons.

First and foremost, our competitors can no longer be regarded as the same competitors we had when news was delivered daily in print and technology projects could run for three years (and did!) without seeming unusual – merely “big”.  Our competitors now are globally placed, and can set up a competitive news source about as quickly as you can make an omelette. That’s the benchmark.  If we can’t tweak a feature on one of our sites and test it live inside of 24 hours, we might just be dinosaurs waiting for a meteor.  Most of the newer digital media businesses can do this, and many of our legacy competitors are on this journey as well.  This is why it’s a baseline expectation, not a target.

Secondly, as we move into a world of KPI’s focused on site performance including competitive benchmarking we need to be able to call a slowdown worse than a particular measure a severity one issue, and ask the relevant team to stop their project work and turn their attention to the slowdown until the issue is resolved.  This can’t really work unless we can release the performance fixes and test them continuously – preferably using RUM (Real-user monitoring) and this couples these two objectives.

Third, in a recent restructure my team was expanded and now includes responsibilities from design through to support.  Part of the motivation for this is a desire for faster output.  I’ve had several people dispute this is feasible – on the basis that we are running at capacity already.  I believe we can achieve good results in a couple of ways though.

As we are all in one team now, we can lean out our management processes and push closer to pure agile / Scrum and ship a lot more smaller releases.  This will create a perception of velocity in its own right, but will also gain faster feedback – allowing teams to refine or pivot more quickly, and get to the right outcomes quicker.  Product managers will also be able to do their UAT incrementally instead of waiting for releases, which will lean out the UAT processes.

Lastly, testing as a function will change fundamentally in a CI/CD environment and our testers will be increasingly automation specialists who will work with the project teams to make sure they have tests in place.  This will mean more testing is automated, and done quicker than human hands can do it.

Disruptive Innovation 101

My boss handed me a pamphlet he’d received in the mail at work and said “Here,you’ll be interested in this”.  It was advertising a talk by Clay Christensen on his learnings around disrupive innovation – or as he calls it market-creating innovation.  This struck me as so important for our leadership team to attend I got permission to book a bunch of us seats to attend.  And it was worth every second.

I presented a crunched-down brown bag lunch session on this at work recently, you can find it on the Engineering @ Fairfax blog – where we’ve started publishing a lot of our internal sessions.   Unfortunately the Q&A was very sensitive and so we have had to edit the last part out of the video

Here’s the video:

Here’s the presentation:

Repaving the front garden

Since we moved in, the front garden has been messy uneven brickwork.  Someone who lived here a very long time ago spent a lot of effort arranging the brick pavers in a circle pattern, but there were two problems.  Firstly, the circle pattern means there are a lot of big spaces between the rectangular bricks – and these spaces get more and more full of weeds over time.   Second, the little trees they planted turned into big trees, and the roots had lifted all the bricks unevenly, and so the gate no longer opened without contact with the bricks and the walking area was one big trip hazard.

Starting point – very uneven brickwork, poorly maintained beds, massive weed problem:

It’s easy to see how the bricks were lifted up by the roots of the big plane tree here, and how the tree has outgrown the original corner  placement, and is butting up against the brickwork.  It’s also very close to making the garage wall crack, and will probably have to be taken out in five years or so.

2013-09-07 12.17.26 2013-09-07 12.17.21


Continue reading “Repaving the front garden”