[Experiment] Swift + Foursquare API

This is my first adventure in Swift. It reads the users location and then queries the Foursquare API to find all coffee shops within a 10KM radius, which are then sorted by distance (nearest to furthest). And here’s the link to my repo.


Ember and the Designer

For the last 7 years I’ve worked with User Experience designers and I have a huge respect for their craft. I’m also loving how designers are embracing HTML5 and CSS3, and how it is giving them ownership over the experience.

It’s affording deep collaboration between the designer and developer, and asserting the need for frameworks and tools to play to our respective crafts, and to be sensitive to the designer-developer-workflow.

With this in mind I struggled for a while with Ember. I wanted a clean separation between my HTML and my code. Ideally I didn’t want to change the HTML, and I really didn’t want to pollute it with proprietary code belonging to Ember (or any other framework).

I was really disappointed as the only solution offered up was to use Ember.TextField.


<input type="text" id="firstName" placeholder="First" autofocus required>


{{view Ember.TextField valueBinding="firstName"}}

It breaks the clean separation between designer and developer. It makes my code difficult to maintain. I loose the expressiveness of HTML5. Why?

I get the binding goodness it may bring, but…

At this point I did consider walking away from Ember, but I did persevere. In the end I opted to use plain old JQuery in my code. I’m intrigued to see how this plays out as I grow my codebase, but in the meantime it keeps my HTML as pure as it can be.


<script type="text/x-handlebars" data-template-name="registration">
   <form autocomplete="on" id="registration" {{action createUser on="submit"}}>
      <input type="text" id="firstName" placeholder="First" autofocus required>
      <input type="text" id="lastName" placeholder="Last" required>
      <input type="email" id="primaryEmailAddress" placeholder="hello@mydomain.com" autocomplete="on" required><br>
      <label>Password <em>Minimum 6 characters</em></label>
      <input type="password" id="password" autocomplete="off" required pattern=".{6,}" title="Passwords must have a minimum of 6 characters."><br>
      <input type="submit" value="Create account" onmouseup="form.className='submitted';" />


App.UsersController = Ember.ObjectController.extend({
    createUser : function () {
        'use strict';
        var user = App.User.createRecord({
            firstName : $("#firstName").val(),
            lastName : $("#lastName").val(),
            primaryEmailAddress : $("#primaryEmailAddress").val(),
            password : $("#password").val()

Building organic software

I’ve been thinking a lot recently about how I can build “organic software” that permits services to transparently join the network and leave again. I want to know when a service joins the network and for it to advertise itself. I want to know when a service leaves the network so its consumers can gracefully adapt. I want a service to browse the network for the services it requires. I don’t want worry about configuration.

This is not new. If I cast my memory back to the big days of JavaOne I remember Jini (now Apache River) being the “big thing”.

Yesterday I started looking at Multicast DNS (and Zeroconf), which is used by Apple’s Bonjour. Once again the Node community has not disappointed, I quickly discovered node_mdns.

I decided to do a quick spike around MQTT, which I have also been looking at. Again, the Node community delivers with MQTT.js.

I have a service that provides an MQTT broker. When the broker is ready it advertises itself on the network.

My client browses the network for an MQTT broker, when it finds one it connects to the broker and starts publishing messages. If the broker leaves the network it stops publishing. When the broker rejoins the network, it is again discovered, and the client resumes publishing again.

Take a look at my Gist.

Although my exploration has been limited I have found it to be simple and robust. As we shift our mindset from the monolithic deployment of software to one where we build, deploy, and scale processes independently I feel this offers some really interesting and exciting possibilities. This is especially true as we look more and more at how we bridge in to the physical world to build real time experiences that consume large amounts of data and tap in to sensor networks. The end solutions are broad, it can be digital marketing, gaming, home automation (or automation anything). I came across Pachube the other day, which folds in to this and opens the door to some really interesting possibilities.


I’ve spent some time recently looking at AMQP. I’ve been using it with RabbitMQ and Node. The de facto library for Node is node-amqp, which is powerful, but I have found it to be too low-level for my every day needs of pub/sub.

I wanted a more succinct syntax for publish and subscribe so I created node-messaging.

Below are some code snippets, for complete examples and further documentation jump over to node-messaging.


messaging.createMessenger( url, function( messenger ) {
    messenger.openForPublish( exchangeName, exchangeOptions, function() {
        messenger.publish( exchangeName, routingKey, { body: "hello world" }, messageOptions );


messaging.createMessenger( url, function( messenger ) {
    messenger.openAndSubscribe( exchangeName, exchangeOptions, queueName, queueOptions, bindingKey, subscribeOptions, function( message ) {
        console.log( "Received message '%s'", message.body );

Google Maps – “hello world” with RequireJS and jQuery

I’ve been looking at the Google Maps “hello world” tutorial in conjunction with HTML5 Boilerplate, RequireJS, and jQuery.

When you download and extract the boilerplate it already gives you jQuery. Given I am using RequireJS with Node (see node-reference-app) I also wanted to use on the client-side to modularize my code. It’s no big deal in itself, but I ran in to a few issues when I dropped in the Google Maps API. A search on Google soon revealed it was due to the async nature that the Google Maps API (and other Google APIs) loads its own code.

There are a number of posted solutions. The one I liked was the async plugin for RequireJS from Miller Medeiros.

Jump over to GitHub to look at the complete solution.

The basic map code is exactly as it appears in the Google Maps tutorial, however here’s a breakdown of how it fits in to HTML5 Boilerplate and RequireJS:

  • index.html – has the div for map_canvas, there is also a script tag with a data-main attribute that tells RequireJS the script to run, main.js, when the document is ready (read more here)
  • style.css – specifies the width and height for map_canvas
  • main.js – this is where the real work begins, we grab map_canvas from the DOM with the help of jQuery and call addMapToCanvas() on the google module
  • google.js – this is the heart of the solution to the async problem, if you look at the top you will see the URL is prefixed with async!, which causes the async plugin to be called

Note: to use the example make sure to obtain your own api key and add it to the URL in google.js where it says YOUR_KEY.

Node.js reference app

I’ll keep this post short and sweet. I’ve spent the last week working on a reference app for Node.js. I’m not going to elaborate on it in this post, but rather ask you to jump across to GitHub and take a look at the project. It’s got a comprehensive README file that will hopefully explain my motivations and the app in full.

I’ll happily accept your feedback and encourage you to fork my code and adapt it to your own needs or to showcase the principles that you feel are important.