Using CoffeeScript on Windows

David Havelin was the guy who broke this news: you can now use CoffeeScript directly on windows.  Here’s what you need to do:

  • git clone git://
  • cd coffee-script/bin
  • Download the latest node.exe ( into the same directory.  Note the is an “unstable” version, but you can’t get away with 0.4.x
  • ./node coffee –compile

Finally, throw away all of your over-complex coffeescript on windows solutions.  Hopefully soon there will be a batch file.

Technorati Tags: ,

Best Undocumented Feature of Backbone.js

It’s fairly well known that you can override Backbone.sync in order to provide your own backing store.*  However, what isn’t documented but is clearly visible in the source, is that this.sync not only exists but takes priority.  This is pretty vital if you ever want a presentation-model style collection, where adding and removing causes changes to other models in your application.  I’ll warn you that you need to step through the framework code fairly carefully to get this to work, but it’s really useful.

*Another useful tip: if you’re using ASP.NET MVC, add a route like this

routes.MapRoute("Delete", "{controller}/{id}", new { action : "DELETE" }, 
new { httpMethod = new HttpMethodConstraint("DELETE"))

Because ASP.NET MVC doesn’t seem to be able to cope with just slapping an [HttpDelete] attribute on an Index method.

Technorati Tags:

Second Thoughts on Jetlang Remoting

So, after my first article I decided to ask Mike Rettig what I’d missed.  I have to admit to still not having had time to play with it myself,* however his reply was sufficiently interesting I asked to be allowed to share it.  He was kind enough to permit this.  There’s no explicit quoting here, but pretty much the credit for the pain points section is owing to Mike.  Any errors are my own.

Publish/Subcribe Pain Points

In the original article I stated that client and server were identical.  This isn’t really true.  In particular, a server is an acceptor and a client is an initiator, in standard TCP style.  Although both can publish and subscribe, the presence of topics in the protocol allows for server side filtering.  To make all of this easier to understand, imagine you’re writing a simple application that prints up the last trade in a particular list of stocks.  In classic pub/sub as ZeroMQ implements, you’d connect up to a stream that published every trade as it went down.  This would mean that you were receiving many updates in which your client had no interest.  You’re flooding the network with stuff that doesn’t matter, and usually your network is your most limited resource (certainly, very few have to worry about processing power and storage anymore…).  Using the topic, the server can be made aware of the necessary filtering that needs to occur.

This brings us to the next strength of Jetlang Remoting that I missed, probably because I only read the protocol and not the code.  When you subscribe, the server receives an event telling you this has occurred.  This is actually really significant.  Let’s return to our example application.  Let’s say we’re interested in the trades of some obscure stock, call it Recondite Inc.  Now, Recondite is an extremely illiquid and only trades once an hour.  In the classic model, you will subscribe and only get told about the stock when the next trade occurs.  Pretty much everyone regards this as part and parcel of the way pub/sub works and the way around it is fairly well understood: you just get the current state via an RPC first.  However, with the Jetlang model, the server is not only aware of what interests you, the server is aware of when you began.  Therefore it can publish the initial state through the topic.

These aren’t obscure points.  Most systems I’ve worked with that involved any form a real-time data distribution encountered both of those pain points.

The last point that Mike made concerns versioning.  The topic nature of subscriptions makes it relatively easy to identify the version of the client.  In turn this enables the server to filter messages that it knows the client can’t handle.  Achieving this without server-side filtering is possible, but only by throwing ports at the problem.

Complex Subscriptions

Lastly, I made a point last time that topics could have been made byte arrays, for complex subscription, but in practice the fact that every reply contains the topic suggests you’ll want to keep the topic small.  An alternative, but more complex arrangement, would be for subscriptions to return a subscription ID first and then send data messages with the subscription ID.  Once you recognize that model, you can see that you could set up such topics using an RPC call first.  Jetlang therefore provides the flexibility to do complex subscriptions without requiring every program to implement code for it.

*I’m spending most of my time with client side UI and backbone.js at the moment, of which more another time.

Technorati Tags: ,