- Entrepreneur. Life Hacker. Nomad.

Forwarding notifications from a Ubuntu VM to OSX Host

by Giles 0 Comments

Whilst developing on my local machine I like to use Vagrant to make sure my development environment is as close to production as possible. It also isolates my environment from my local setup, this helps to avoid package conflicts which gives me a clean slate for every new project.

notifyOne thing that is handy to have in your local environment is notifications from the terminal when a process is complete. The awesome node-notifier on NPM lets us do just that. On a recent project though I found out that the notifications weren’t being triggered due to the node process being inside the guest VM. I use Virtual Box as my virtualisation software of choice with a version of Ubuntu ticking away inside.

To get the notifications to forward from the Guest to the Host was actually simple in the end. Here is how I achieved it for anybody who comes across the same problem. And thanks to the author of this gist for a nudge in the right direction.

The Setup

  1. Install terminal-notifier using homebrew
    brew update && brew install terminal-notifier
  2. Install vagrant-notify. Make sure you have Vagrant 1.4+ and run this on the host in your Vagrant directory:
    $ vagrant plugin install vagrant-notify
  3. Create executable notify-send file
    1. touch /usr/local/bin/notify-send
    2. touch /usr/local/bin/notify-send
    3. echo "terminal-notifier -appIcon \"\$2\" -title \"\$2\" -message \"\$3\"" >  /usr/local/bin/notify-send
    4. sudo chmod +x /usr/local/bin/notify-send
  4. In your guest VM (Ubuntu), install notify-send if it’s not already available, I found a good forum post on it here. My Ubuntu didn’t come with Ruby Gems so I installed it with the following command: 
    Note: you may not have to do this if you already have rubygems installed
    sudo apt-get install rubygems

  5. Restart your VM with vagrant halt and then vagrant up
  6. You should now be able to send test notifications using the following command in the VM: notify-send Test "Hello World" – the first parameter is the title and second is the message in the notification window.
  7. To send notifications from node all you need to do now is:
    • Install the node-notifier module:
    • npm install node-notifier --save-dev
    • Require the module in your code:
    • var notifier = require('node-notifier');
    • To be safe wrap it in a conditional that only runs if your NODE_ENV environment variable is set to development. For example, here I’m using a callback in Sails to tell me when the server is ready:
if (process.env.NODE_ENV === 'development') {

  sails.on('lifted', function() {
      'title':   'Sails Lifted',
      'message': 'Ready to set sail...'


And that is pretty much it, you’re all set, now enjoy even more notifications whilst you work 😉


Rewarding Work

by Giles 0 Comments

I found out recently that one of the big projects I worked on in 2013 has won an award. The rebuild of won the 2014 Interactive Merit Award from The One Club, they are the world’s foremost non-profit organization for the recognition and promotion of excellence in advertising.

It’s feels great to have our work recognised and it was amazing to work with some really talented people, not only just the full time staff at Commonwealth Bank but all the contractors and consultants I worked with directly and through VML. I look forward to working with you all again one day and hope your doing well on your current projects.



DevTools Terminal Alfred Workflow

by Giles 0 Comments

Just a quick post to share a Alfred Workflow I made today. I recently came across the awesome DevTools Terminal Chrome Extension. If you haven’t used it yet then go check it out. It’s so nice to have a terminal window open in your browser. I like having just 2 windows open, my browser and my text editor, switching to a third window just gets distracting so it’s great to be able to have a terminal open in Chrome’s DevTools or as a separate tab. This extension is a quick shortcut for opening the terminal as a separate tab in Chrome, it’s been pretty handy for me so far and so I thought I’d share. Enjoy.


Organising JavaScript without an MVC framework

by Giles 0 Comments

Lot’s of projects I work on tend to have a lot of JavaScript but just not enough to require using a MVC framework. These sites tend to be marketing sites or blogs, usually your bog standard website that isn’t a web app. For these type of sites I organise my JS using a code snippet that I picked up a few years ago from the guys at Viget and Paul Irish.

First off if you are using a backend framework such as Rails or Laravel this will make things simpler but it’s not required. We start by adding data-attributes for our Controllers and Actions to the body tag. If you aren’t using a framework then add these attributes to your body tag as well and start thinking about what pages you can group together as controllers and what actions each of those pages would be. It may help you in organising your site a bit more as well.

<body data-controller="projects" data-action"new">

Then in our application.js file or whatever your main JS file is called we include the following:

common: {
init: function() {
// application-wide code

projects: {
init: function() {
// controller-wide code

new: function() {
// action-specific code

UTIL = {
exec: function( controller, action ) {
var ns = SITENAME,
action = ( action === undefined ) ? "init" : action;

if ( controller !== "" && ns[controller] && typeof ns[controller][action] == "function" ) {

init: function() {
var body = document.body,
controller = body.getAttribute( "data-controller" ),
action = body.getAttribute( "data-action" );

UTIL.exec( "common" );
UTIL.exec( controller );
UTIL.exec( controller, action );

$( document ).ready(

So what is this snippet doing, when the page is ready we are calling UTIL.init, this calls UTIL.exec( “common” ) by default which runs the exec method of the UTIL object. The exec method accepts 2 arguments, controller and action. The default ‘common’ argument has been passed in for the controller and nothing for the action, so ‘init’ is called by default for the action. Then after checking to see if there is an actual object with the controller and actions as properties and that they are an a method, in this case ‘common’ and ‘init’, the method runs the selected objects method – ns[controller]action; – ns is a alias for the object you defined above to hold all of the methods and properties. The common object is a great place to store all our site wide JS as this method will always be called for every page.

Next up the UTIL.init method runs UTIL.exec again, this time passing in the controller variable as an argument. This variable stores the name of our pages controller, in our case ‘projects’, from the body tag’s data attribute. Again this is passed through to the exec method and this time when it runs it calls the ‘projects’ property of our SITENAME object with the action ‘init’ as no action was passed through. The ‘init’ method is another really handy method because you can run controller wide code from here that you want to run across all of the controllers actions.

Finally UTIL.exec runs one last time passing through both the controller and action variables that it has retrieved from the body tag’s data attributes and runs the corresponding controller and action properties on the SITENAME object, in our examples case ns[projects]new; This way the only code that gets executed on page load is:


This is great as if we have lot’s of code and plugins then they won’t get executed unless we are on the correct page. I tend to use the Module Design Pattern with this approach to further organise my code. Here’s an example of a registration module:

// Registration Module

var Registration = (function() {
'use strict';

var module = {};

// Settings
var s = {
regUser: $('.reg-user')

// Init
module.init = function() {

function setupBindings() {
s.regUser.on("click", function() {

function addNewUser() {
// Do ajax call etc here...

return module;


I usually load all the modules in along with any third party libraries after the page has loaded and execute the UTIL.init method when the DOM is ready. I find this method a really nice way of managing small to medium sized JS projects that don’t require a bigger framework such as Backbone or organisation with tools such as RequireJS.