TechRepublic Podcast

Earlier this week I was a guest on TechRepublic’s “The Upside” podcast where I talked to Chris Duckett  about the Mass Mobile Experiment – an open source collaboration platform I developed with Simon Raik-Allen from MYOB. We recently showcased the technology at Tech Ed Australia.

“One of the most interesting talks at this year’s Australian TechEd event was the Mass Mobile Experiment. The platform’s Pong implementation was used to entertain attendees before the conference’s keynote.”

We chat about the inspiration for project  – Loren Carpenter’s crowd swarming pong experiment from 1991 and we geek out about TypeScript and node.js

Here’s a link to the podcast

Enjoy !


TypeScript – first impressions are promising but where will it end up?

Earlier this week Microsoft announced TypeScript, an open source language that compiles down to plain old JavaScript. OK I can already guess what’s going through your head, you are thinking “is it like CoffeeScript?” or “is it like DART?!” Fortunately the answer to both questions is no!.

CoffeeScript doesn’t need improving and one DART language is more than enough! DART compiles down to JavaScript but it also targets the DART VM. TypeScript on the other hand is a superset of JavaScript, its not intended to replace JavaScript, rather it give you a more productive experience in writing JavaScript particularly on a large projects.

“TypeScript has a fighting chance of making it..”

I think TypeScript is in with a fighting chance of making it because of the tooling that it puts in developers hands. Microsoft builds excellent IDE’s and with TypeScript you now have all that intellisense goodness and static code analysis at your fingertips. Hardcore JavaScript developer are more than happy to work away in vim and lightweight text editors but there are plenty of mere mortal developers that will enjoy the TypeScript development experience.

Shipping the TypeScript compiler as a node package is a clever move. TypeScript can run wherever node.js can which covers most platforms of choice.

 Please keep the language spec clean and simple ! Less is  definitely more with TypeScript

The TypeScript language specification is currently nice and uncluttered but who knows where it will end up?. Anders Hejlsberg (lead architect of the C# language team ) is at the helm. When you compare C#1.0 and C#4.0 they are completely different beasts. In the case of TypeScript less is more in my opinion. It should be about giving developers just enough design time type checking and intellisense without completely stifling the dynamic nature of JavaScript.The road map for TypeScript includes support for generics – this scares me. Do you really need generic support in a dynamic language like JavaScript?

What’s nice about TypeScript

(1) Inheritance is nice and cleanly implemented

Below is a simple example of inheritance where specialCustomer extends the customer class and calls the base class constructor from its constructor.

class customer {
	id: number;
	name :string;

	constructor (name: string, id:number) { = name; = id;
	greet() {
		return "Hello, " +;

class specialCustomer extends customer{
	loyaltyCardNumber :string;

	constructor(name:string,id:number,loyaltyCardNumber :string){
		this.loyaltyCardNumber = loyaltyCardNumber;

TypeScript does the heavy lifting adding the necessary prototyping and closures for you – this is very cool and definitely saves time!

var __extends = this.__extends || function (d, b) {
    function __() { this.constructor = d; }
    __.prototype = b.prototype;
    d.prototype = new __();
var customer = (function () {
    function customer(name, id) { = name; = id;
    customer.prototype.greet = function () {
        return "Hello, " +;
    return customer;
var specialCustomer = (function (_super) {
    __extends(specialCustomer, _super);
    function specialCustomer(name, id, loyaltyCardNumber) {
        this.loyaltyCardNumber = loyaltyCardNumber;, name, id);
    return specialCustomer;

(2) Visibility Modifiers

The visibility modifier keywords like private are enforced by the TypeScript compiler but the generated JavaScript does not reflect this. A private property is implemented as a regular property but the compiler will enforce a developers intent with regard to visibility modifiers.

(3) External Type declaration files

Type declaration files (.t.ds file extension) define all the public interfaces that your JavaScript code exposes. Check out the node.js file that is published here. By creating an external type declaration file you get to interact with other existing libraries through TypeScript. Currently these files are hand crafted which sounds really tedious but I’m sure this will be automated in a future release.

(5)TypeScript  Playground

Similar to the google DART board, TypeScript has a nice web based shell where you can get your hands dirty without downloading anything. Check it out and have a play.

What not nice about TypeScript

(1) The  plug in for Visual Studio 2012 install as a C# template! Confusing eh? I sure found it hard to find !

(2) Slow feedback loop in Visual Studio.

You need to compile your project to view the generated JavaScript code. It would be nice if the there is a split panel view where you can see the generated JavaScript as you are coding , similar to the playground.

What’s Missing

  • Async/Await keywords would be a really nice feature. There are several  well known JavaScript implementations to borrow from.
  • An external type declaration file generator. A tool that can load up a JavaScript library and “decompile” it to a .t.ds file.
  • Better Visual Studio experience à la TypeScript Playground.

Overall I’m very excited about TypeScript. Microsoft is clearly getting very interested in embracing JavaScript in its many forms, their arsenal includes node.js support on azure, Win.JS, KnockOut.JS (Microsoft employee) and a JavaScript Hadoop offering. While TypeScript won’t be everyone’s cup of tea I’m sure it will appeal to a large enough portion of the development community to give it legs.

may the source be with you!


Bench marking node.js on Windows Azure


I’ve been working on a pretty cool side project that I presented at Tech Ed Australia 2012 – “The Mass Mobile Experiment!”

It’s a generic collaboration framework that enables lots of people (say at a conference) to enjoy a shared experience in real time using their mobile phone, tablet or other internet device. At my Tech Ed session I had over100 people playing a single game of pong on the big screen using their mobile phones to control the paddles in real time! The platform is built using node.js, websockets ( and it supports a plug-in architecture enabling other games / experiences  to plug in pretty easily. So far I’ve got a multi-player quiz game, pong, a political worm and an interactive presentation.

Conceptual Architecture – MME ( Mass Mobile Experiment)

  • Client ( mobile phone) sends data to server over long running websocket
  • Server (node.js) aggregates the data and sends to the playfield over websockets
  • Playfield (browser on a big screen) runs the game loop and process the aggregated data from the server.
  • Control Panel allows you to change games and throttle the client and server

Bench marking on Windows Azure

In order to load test the platform I built yet another game! This time I got 200 people in the office to “play the game”. It involved leaving a web page open for 20 minutes while I stepped up the number of websocket connections on each browser and started to send data to the server.

  • The client connects to the server over websockets and sends typical game data on a timer
  • The contol panel broadcasts messages to all clients telling them to step up the number of websocket connections to the server and to increase the send frequency. In effect a single browser is then multi-plexing several websockets to the server. I found that a single browser can easily multiplex 10 different web socket connections without slowing down the client side JavaScript Code.
  • The server collects interesting metrics such as requests per second and CPU and sends this to the playfield
  • The playfield ( load test app) listens for data over another websocket and plots the data in real time


  • Node.js server running on a medium size worker role on Window Azure, 3.5 GB RAM, Allocated Bandwidth 200 (Mbps).
  • 2000 concurrent WebSockets ( multiplexing over 200 different laptops in the office)
  • Requests per second 8500
  • Memory Usage on Azure 76%
  • Message send frequency from client – 4 messages per second

Check out this screenshot from the azure management portal – I managed to push the CPU to a 89% at 11:40 when the system ramped up to 2000 concurrent users!


  • Node.js running on an azure worker role scales really really nicely. In my case a medium sized VM scaled to 2000 concurrent web sockets processing 8000 requests per second. Not a single message got lost between the browser and the server even when the server was under stress!

Why you should distrust this post !

  • The measurements were taken using node.js v0.8.9, v 9.0, these technologies are evolving rapidly.
  • For the mass mobile experiment the node server is pretty simplistic, it aggregates data and sends it to the playfield. This may not represent what your application is doing.

All of the results along with all of the source code is open sourced here on GitHub

May the source be with you !