Rob Ashton

Something like this

This is a time-lapse of me creating a game over 48 hours (a weekend), overall there is about 30 hours of screen-time packed into 3 minutes of video - it's cool to see how the game and code progress over those 30 hours.

What is interesting is how I always have the social elements open in a browser window on my left hand side, I'd never noticed it before - I don't think it slowed me down any - the pauses where I wasn't coding I was up making coffee or thinking about a problem

Still, it would be interesting to see how I'd get on without it if I was doing another of these - the next rendition of the competition is next March and I think I'll be doubling my efforts to create something cool - I might even go as far as to do a 3D effort in WebGL

I've gone off on a tangent recently and been playing around with games development as if I was 15 again

I think I'm going to make a game that I actually want people to play next, but first up - three things I've released recently

Hoverbattles

My flagship 'game', something I've learned a lot from these past couple of months - written with a NodeJS back-end, with WebGL front-end, the code is awful in places and I think I have a few memory leaks (or third party libs do!) but I'm pretty much done with this now.

Note: The server this is on is not brill, so there will be lag

This can be found at http://hoverbattles.com - fill your boots.

Source can be found at https://github.com/robashton/HoverBattles

Plane Thinking

I coded this over a few days as warm-up for LD22, the 48 hour games development challenge, this is plain old Canvas (although I was playing with using WebGL to do progressive enhancement it turns out that copying buffers between the two gets expensive quickly and I didn't take it much further

This should work in most browsers, I really should make the effort to get it working with touch controls as it would work well on iPad

This can be played at http://planethinking.heroku.com/

Source can be found at https://github.com/robashton/plane-thinking

You don't have to be alone

This is my entry to the 48 hour game development competition Ludum Dare - I don't really think of this as competing with anybody else, trying to build a game from scratch over 48 hours is mega hard and I'm really proud that I was able to pull it off with plot, sound, music and alternative ending galore

The code for this is ... suboptimal, if you play it on anything other than a really high end desktop computer in any other browser than Chrome then do so at your peril. I'll be learning from that in my next game and making an effort to keep those render calls down

The game can be found at: http://ld22-ashton.heroku.com/

The source can be found at: https://github.com/robashton/ld48_22

The point of all this

Games development is complicated, the code in Hoverbattles is probably the most complex domain I've ever worked on, and finding ways to keep the accidental complexity low whilst keeping the technical complexity low at the same time was a big challenge

I've learned a lot by stepping away from ordinary business app development, and I'll be taking that back to the workplace with me, as well as carrying on in this space - never before has there been a better time for aspiring games development to noodle on in their spare time.

This site? Yeah I've messed this up a bit - I need to rip all these posts out and deploy them as static content and set up some re-directs, a project for a rainy weekend when I don't want to play with games :-)

Merry Xmas

Rob

A brief middle-of-project retrospective

I've not been coding in my spare time much the past few months, being seriously busy for a client - but the past couple of weeks has seen me pick up a project of mine that I started a few months ago (HoverBattles) and start pushing to some level of completion.

This has been an interesting project for me, not least of all because it's written entirely in Javascript (WebGL + JS, NodeJS and CouchDB) but because this time I made a real effort to drop any up-front 'zomg my code must be perfect' aspirations from the get go.

What does this mean? Well I pretty much decided that technical debt should not be something to be overly avoided, overly organised code-bases stifle creativity and I really just wanted to deliver something.

I also knew that as I learned more about effective JavaScript that my opinions on the 'best way to achieve things' would be changing about 20x more rapidly than it does when working in an environment I'm heavily used to, and trying to constantly maintain code at some mythical standard would prevent me from actually delivering

A couple of months later how does that leave me? Is the code-base a huge unmaintainable mess? I would say no - it is not.

There are messy bits in there but they're largely on the periphery. An avoidance of up-front framework/empire building has allowed me to be morally flexible with regards to where I put new code to Get Cool Stuff Done, and a healthy concern when going over pre-existing code to add something new has led to some easy wins when re-factoring around the pain points that naturally emerge.

I don't think that I've taken a cavalier approach to the project - at a macro level it's quite well structured, and for the most part there is a clean separation between the different sub-components that drive the system. In a code review there are bits I'd have to apologise for but even in projects with the greatest amount of technical debt avoidance this has been true.

There are some problems with the messaging/multi-player side of things, complex work-flows have emerged as a consequence of the individual components receiving some input, doing something and raising some output in orders that I did not pre-plan.

This has been made more complicated by the fact that some of these components only exist on the server, and yet the events they raise are still sent to the client because the client needs to react even if it is not the one doing the critical thinking.

This is an example of what I have come to classify as a real problem - that is, it is a problem that is naturally occurring and isn't one I have constructed to satisfy the whims of my inner Powerpoint Architect.

When I think of all the things that we work on in our line of business applications, the efforts we go to de-couple everything so it can be easily tested and maintained, the efforts we go to make sure we have the extensibility points and have our "what ifs" covered, I'm seeing a lot of that in a new light as this project goes on.

I don't think a lot of our 'units' in our LOB world are really units at all, they're fractions of 'units', and it's only as part of a more complex interaction that things get interesting and worth spending time fussing over.

Even those seeking to do more vertical testing of a unit within their system (across several internal components) aren't really testing anything meaningful, they're not really spending their time on anything really meaningful either - I wonder if we do a lot of this stuff just to make our jobs more interesting because LOB apps are at a micro-level... quite boring

Anyway I digress, a response could be that some of that rigidity and forward thinking is needed because we have more than one soul working on these projects and if everybody took the cavalier 'get it done' attitude we'd end up with a big mess right?

I'm not convinced - I think that if you have a team that can actually communicate and react to problems as they arise that a good momentum would still be possible, a lot of the technical solutions delivered in these LOB apps seem to exist as a way of avoiding the need for communication and I'm beginning to think of that as less okay than I did

I'm also beginning to think that a concentration on these things causes bigger balls to be dropped. There is little point in arguing over patterns if you're going to forget to apply sanitisation to user-provided input for example - or suitable defensive mechanisms against things that might go wrong (as dirty as that might make some of your code).

Going back to the whole CQRS thing as that was the topic of the last post, this ties in well - those things exist as solutions to complexity that already exists - not as ways of creating complexity that wasn't there before. Technical solutions should be avoided unless they're actually delivering the necessary value.

Random blathering I know, I'll actually start talking about the tech in the game soon I think, it's getting interesting and I think there are some things to say about it

Is something I hear all too often at conferences and on Twitter, and more often or not it is said because of either a basic misunderstanding of what CQRS is or is not - or perhaps because they've dipped their toes into the hyperactive DDDCQRS mailing list and been scared away by all the white coat discussion that goes on in there a lot of the time.

The other day, the sentiment was yet again voiced by somebody of whose opinion I respect on Twitter and I ended up in about five minutes writing a gist explaining why I didn't think this was the case (Writing 4000 word essays is an hour's work if I'm feeling ranty), I've tidied it up a bit and decided to throw it below as it works well in a blog entry.

A basic summary

At the highest level CQRS just means maintaining a happy division between the reads and writes across your system - that is, having the reads in your system executed in a thin clean manner appropriate to the views you want to retrieve (one model), and your writes going through all the crazy logic you need such as validation, updating queues, third party systems, processing business rules (another model)

Consider the traditional and very-tongue-in-cheek N-Tier architecture I have created here in powerpoint, seen in a million "architecture" presentations in ASP.NET webforms shops across the world:

 

Now modify it a little bit so that our reads haven't got to go through all that cruft, haven't got to somehow amene themselves to a bunch of "DAL objects" that are created with the very best intention of standardising our access to some form of database (and normally optimised for the write actions anyway).

We can instantly make our lives a lot easier by creating a pile of code optimised for creating views for our presentation layer, perhaps doing a bit of raw SQL or calling a sproc to generate the view for us. We can helpfully formalise this arrangement and for the most part set down a rule that the direction of travel down those two paths is one way (towards the DB for writes and away from the DB for reads).  Funnily enough - most systems that do that BOL/BLL/DAL/OCKS stuff end up with something that looks like this anyway because it's too hard to do everything through a single model.

This is now a form of CQRS - at the highest level we've effectively split our system into two models and done something that's very similar to what we'd call CQS if we were doing it at the method level.  This in itself should surely be enough to convince you  that CQRS itself is not complicated and it might be a useful thing to look further into.

Of course, as you go further down the rabbit hole...

Some examples

CQRS can be achieved by using a document database like Raven or Couch - using your documents as a write store, using your indexes as a query store.

 

It can be achieved with your favourite ORM (Even better if you can actually use that O and that M and get some good old OO going) - if you want to use your objects for encapsulating business logic and go directly to the the queries to project the data you need for views (HQL, SQL directly, SPROCS, whatever) - from the same database even, providing this remains efficient enough for your needs. (Funnily enough, "our" collective weak attempts at creating domain models with NHibernate are what led to us re-discovering the need for two models in the first place in my opinion).

 

Of course you may well end up with two databases anyway, as trying to query a database comprised of tables that represent state in your "objects" can be pretty inefficient, with the read store updated from the write store using hooks in your write system to generate pre-calculated views or data that's more applicable to generating views - this is not a bad model and can work too, it's still CQRS.

 

CQRS gets the "complicated" label because people often associate it directly with event sourcing, which requires that little bit more of up-front development in order to get the level of elegance you won't find in the above scenarios. However, even event sourcing is really simple once you look at it - and is a natural progression from some of the other ways of "doing" CQRS - which can be a bit muddy (not that there is anything wrong with systems that are a bit muddy). Note that I'm not mentioning DDD here At All - which is where a lot of heavy learning lies, and nearly none of us do anyway.

Consider hooking those events in your system to manually flatten/re-arrange data into other stores as outlined above? Does that work for that one other store? How about a reporting store? How about full text search? What about integration with third party systems and the data they want to see from you? How about the boardroom reports your CEO now wants on his desk each morning before he starts his day?

Youch. Deciding your single source of truth is the already written state gives you an amount of inflexibility, which you may or may not be happy with up to a point.

Updating other views of this truth after small changes can be inefficient and awkward. Recovering after introducing any write bugs to the system can be expensive also. Hell - even changing your model can also be expensive as database migrations are hardly the easiest things if you're trying to work with multiple stores and layers all over the place. When your powerpoint presentations start looking like this you have complexity issues- and these complexity issues aren't caused by CQRS, they're caused by having complex powerpont presentations.

Moving to events and jumping through a few hoops to make this possible can open up a world of simplicity, and if it's not for you there are other options open to you. CQRS is not complicated - trying to shoehorn the responsibilities of read and write through a single model is complicated. Most of us realise that going through a standard "BLL, DAL, BOL, TLA, CRA, P) layer for both reads/writes is dumb, and CQRS is a good way of formalising this decision.

Another tdlr;

You can see that clearly there is a natural progression from the very basics to having the need to go for a full blown event sourcing system with publishers/subscribers/servers/eventual consistency once the complexity of trying to manage a more "simple" solution starts to overwhelm.

Unless you have that complexity and that need then of course trying to thrust an ivory tower designed architecture onto a system that doesn't need it is going to seem complicated. Hint: If your technical solution is more complicated than your original problem you're probably doing it wrong.

I've been contacted quite a bit this past month with requests for workshops and short term consultancy on RavenDB - I'm thrilled to bits that the database seems to be taking off in this way and I'm all about helping this happen.

The short answer is yes, I am happy to come and do private workshops tailored around your company's needs with RavenDB, I am also happy to offer remote or on-site consultancy where appropriate/desired.

If you've too been wondering about this but not known where to look, just e-mail me at robashton@codeofrob.com, I don't bite.

That's about it really, I'll use this space to say that I'm now nearly settled in Belgium on a long term project for a client and I'm ready to commence blogging again, I've a few things I want to cover with RavenDB in particular but I'll most likely be doing that over at codebetter.com

Yawn

At NDC2011 I was chatting to some folk who work on various OSS projects about cool things we could potentially work on in the future, and the topic of a Silverlight -> Web converter came up

TLDR: Click here to see the demos, click here to see the code, click here to view the Google Group.

I had thought about this before, but it is only recently that an IL converter appeared up that I deemed fit for this purpose (JSIL), and it is after this conversation I decided to put words into action

To this end, I have spent the past few weeks diving into the various concepts in Silverlight and spiking out implementations for converting them to make sure that the vast majority of what I wanted was actually possible

And that leads us to this, SLJS.org, home to where I've gotten so far, with a couple of demos showing off what it can do. More to be added as we go along.

• Here is a basic example of an application in action: Hello World (Silverlight, HTML)
• And here is something demonstrating some more SL concepts: Calculator (Silverlight, HTML)

Truth be told I'm largely doing this for fun and education at the minute, although I know a few people who actually want to use it - not to convert legacy projects, but to write new code in their familiar Silverlight world and have it work in a browser without requiring a plug-in.

I'm happy to support that, but it should be a community effort, rather than me blindly just working on features for the sake of it (although I have a little more of that left in me before I start taking on feature requests!)

So far the following has been implemented

• Bootstrapping a converted Silverlight application in JavaScript
• Responding to changes of the root UI element
• Rendering a control hierarchy from the root UI element
• Rudimentary Dependency Object and Dependency Property support
• Listening for changes on Dependency Properties to update styling
• Listening for changes on Dependency Properties to update content
• A templating system for customizing the output from each control

On my immediate road-map (so in the coming week), I'll be working on:

• Rudimentary data-binding support (A spot of MVVM coming up)
• Converting styles to CSS
• Going through System.Windows.Controls and creating the outline for them in JS
• Forcing some layout concepts into HTML from Silverlight
• A preliminary investigation into attached dependency properties

I would totally appreciate some help/feedback/pointers for the direction of the project/cheering from the sidelines etc

The last one is important actually, if y'all tell me you find this interesting then I'll carry on working on it, if nobody gives a crap then when I get bored I'll stop :-)

But yeah, just joining the Google Group and helping me build a road-map would be a good start

In response to a question from a friend on Twitter (Private account so no linky), but with the text:

"Been reading up a little bit on node.js @robashton @domgreen. What makes it stand out from alternatives or is it just a JS 'me too' play?"

My initial response was, hey - you know what? I can't think of any (popular) alternatives that provide the unique combination that node.js does, and then started writing a torrent of tweets describing why I personally am so excited about node.

Then I decided that rather than spam Twitter, I should write a blog post to link to when asked the same question in the future.

Every bugger has already done one of these, but I want to answer the question in my own personal way

1) You get to write Javascript on the server and the client

Think about this for a second - it's really not just a gimmick (although some people seem to think it is). Even in a simple web application you're going to have validation logic that you're going to want to execute on the client AND on the server, and usually this can't be shared without going through some sort of rules engine or crazy framework to spit out some rough client-side equivalents.

No need with node, you can write your model (complete with business rules, etc), and write a nice task-based user interface around that model, running it all locally in the browser, and then dispatching and validating the commands on the server - because hey, everything is just JSON at the end of the day, and everything you're writing works against that.

Take this a step further, and consider that we have some pretty awesome document databases on the scene at the moment whose primary communication and storage mechanism is - guess what? JSON (well BSON) - at no point during any of this do you need to sit there dealing with mapping frameworks or hand-written mapping code, because you're just flinging JSON around.

With efforts on CommonJS and Stitch ongoing, there is really no excuse for not writing all your JavaScript in a state where it can be executed on both the client and the server.

2) Event-based asynchronous stuff is just How Things Work in JavaScript

Yeah okay, I have no idea what I'm talking about here, but what I do understand and what most people who have been writing JavaScript for the past decade understand is that your JavaScript tends to execute on a single thread and long-running processes get dealt with by the host, using callbacks to notify you (back on that single thread) as and when those things are done.

Now, in the browser these long-running requests are limited to... well HTTP calls to the server to get/post data, but on the server we do nearly everything like this; requests to other machines, requests to the file system etc.

We don't need any crazy language keywords (looking at you C#), we don't need any crazy Task of X/Y and Z objects (Looking at you C#), we just need:

This gives us some brilliant performance benefits, dealing with potentially gazillions of connected clients an easy possibility Sorry for a "the register" link this early in the morning, it's a bit indecent of me.

This also makes dealing with concurrency (at least within a single process) really easy too, all your variables are safe to be accessed at any time as you haven't got any potential race conditions, you can mutate state all you want and not worry that somebody else is going to come along and take away your cheese.

Hell, even the plans for future-node seem to be keeping this philosophy intact, with multiple node processes being given a way to communicate safely (or at least as far as I understand the slides that I've read from conferences I wasn't at).

3) Awesome package management!

Just like Ruby, and just like Linux-land in general, if you want to do something there is probably a library/package waiting for you to pull down and consume, and you can do this via the wonderful magic of NPM

npm install socket.io

It's that easy to get the libraries you need, and there are libraries available for most of the things you can think of, the primary ones I am using myself are:

• Paperboy - for simply serving static files from a directory (index.html, style.css, etc
• gzip - for um, gzipping content that I send down to the client
• socket.io - for magically doing websockets, or at the very least emulating websockets
• jsdom + jquery - manipulating the DOM server-side? Oh say it ain't so?
• Stitch for allowing me to write code in CommonJS format and still use it in the browser.

This isn't anything particularly unique to node, but in this day and age it's a bit hard to be taken seriously without a good package manager in your ecosystem and it's good to see something of quality here.

4) Community community community

The community around node.js is brilliantly active, passionate and y'know - generally quite bright - and willing to try new things out (Kinda goes with the territory really)

This, just like Ruby, is a really big draw for those of us from ecosystems which... lack anything of this scale

This enthusiasm does make it a bit difficult to separate actual innovation occurring from the old "Look at JavaScript doing what everything else has been able to do forever", but I'll take raw enthusiasm over rigid nay-say mentality any day - enthusiasm is contagious and gives me the ability to Get Things Done

5) It's easy, really easy, like super easy, We can all do it!

JavaScript aside (And if you don't like JavaScript you can always use CoffeeScript), the process of writing code that does exciting stuff is ludicrously simple.

Having direct access to the HTTP pipeline, and not hiding it behind crazy levels of abstracted framework cruft is a big, big win - and once you start writing code like this you start to wonder where this kind of thing has been all your life.

"I want to do this: " has not once resulted in me banging my head against the constraints and limitations that somebody else has put in my way (supposedly to help me).

My personal website currently runs on pixie dust and grated unicorn horns - I'm pulling in content from my old subtext blog and spitting it out on the front page (with plans to pull in content from CodeBetter and Altdevblogaday too), whilst acting as a reverse proxy for the old site (in very few lines of code).

That's utterly crazy, and I drafted it up in just a few hours of hackity hack hack hacking, with those goals in mind.

Anyway...

The beauty of node comes in the combination of these attributes, not just one thing (because none of those things bar point #1 are by themselves particularly new or ground breaking

If you've previously dismissed node as something pointless because you think it brings nothing new to the table compared to your X, Y or Z then I urge you to have another look at it, as The Creators prepare to bring it natively to Windows it's only going to get more popular and you'll want to be involved.

The dynamic keyword in C#4 has been put to some good use already - and has attracted a few detractors (probably because dynamic is to C# as generic is to Java), but the fact that the dynamic keyword compiles down to simple reflection over System.Object does present some interesting possibilities over its more pure counterparts.

I had this thought at the weekend whilst doing something completely unrelated, and a brief Google suggested nobody else has bothered doing it with Mark Rendle's Simple.Data yet, so here I am with a proof of concept scribbled down after a couple of hours work this evening.

Given the following code:

I want to end up with a database table that looks like:

Looking at it, this is actually quite a simple problem, and we have two possible solutions to follow if a as a user, we are to do this without writing any further code on top of this.

• Create/modify the database as the code is executed
• Analyse the compiled IL and figure it out from there

Both have their merits and cons (and some cons are definitely shared hah), but from an accessibility point of view being able to do either of these would be pretty "cool"

I'm going for option 2, because I haven't done any IL in a while and want to remind folks that I'm not just a JS monkey, but still care about those .NET leanings too ;-)

Looking at the above code, as a user we can work out that the various columns and tables exist, and their types, so this should mean we can do the same programnatically against the compiled IL.

Let's look at the compiled IL for the first method as dumped out with Mono.Cecil in my immediate Window:

Okay, that's quite daunting, but breaking it down we can easily understand what is going on (I haven't read any docs, I just read the IL and figured it out, so I could be wrong :)

• First up, we look at a compiled generated static field and if it's present we skip forward by about 30 instructions
• If it's not present, we load up the name of our method call (FindByUsername) and do some reflection to get information about that method call
• We then do the same with the property access (Users)
• Arriving at the point we would have skipped ahead to if those values had been present, we realise they are cached information about the calls to the "Object", only loaded once (sensible as Reflection is expensive yeah?
• At this point, we can safely load up the arguments into the stack and make a call via the Callvirt to the cached reflection information on the DB object

This is nice and simple, the only information we haven't got for sure is that those dynamic calls are actually being made to a SimpleData object because it's just a System.Object once compiled. I figure it might be possible to trace through the code to find at what point that object was actually created via the Open call, but that's way beyond the scope of this blog post.

As for analysing this, we have Mono.Cecil so may as well write a feature test to try our initial play out.

I'm not going to be clever about this, as it's just a play-about, so let's dive in and see what information we can find in the assembly - to do this we enumerate the types and pass them into some type of scanner.

We then have a look at all the methods on that type (duh)

The important information is found in the method call, and the important stuff we want to look for in a method is (for now):

• Are there any dynamic method calls made?
• Are there any references to cached fields (Callsites)

With this in mind, I can think about how to identify these things

Looking at whether we have any method calls (returning references to those instructions - we just look for any call virts to an Invoke method (This is hardly fail-safe, but it'll easily do for that test)

Looking at any cached references to reflected data, again we just look for a loading of a field, the subsequent "goto", and check the type of the field (Callsite)

I can use these methods to get me information about what is going on here, and just check we're in a method that actually does something similar to what we're interested in.

The references to those fields will yield in interesting information about the table/column we are dealing with in Simple.Data, that is - the names of those objects.

I find this by going to that instruction and looking for the inevitable call to Ldstr, loading the name of the method call/property access onto the stack before making the reflection call.

So far so good, now I just need the type of the argument passed into the call, and I achieve that by looking at the arguments being loaded into the actual method call

Can you say hacky? I just look at the previous instruction and if it's a ldstr I know the argument is a string :)

All that is left is the putting together of this information into the model we're building.

This gives me an in memory model of the database, with the name of the table and the column we've found - creating a DB creation script from this is a trivial task left to the imagination by the reader (My Sql is awful man!)

This is where I stopped as I don't have much time to go further tonight, if anybody wants to fork the repository and carry on where I left off, it can be found here: https://github.com/robashton/Simple.Data.Generation

Clearly the rest of the work takes the following path if it was to be continued:

• Check for all the other types of 'const' to be passed into Simple.Data method calls
• Check for arguments/local variables being passed into the Simple.Data method calls
• Allow for multiple arguments to Simple.Data method calls
• Deal with other types of Simple.Data method call other than FindBy
• Deal with dynamic operations being passed to other dynamic operations (Simple.Data does this)

Is this actually a good idea? Possibly? Possibly not? I haven't read about the implementation of dynamic behind the scenes by the compiler (literally, not at all) - and don't know how much is left up the compiler when choosing how to do it (Looking at those cached fields...), and this particular script makes quite a lot of assumptions about this.

As an example of what implementing the dynamic key word on top of a statically typed language and runtime brings to us though, it's quite powerful - and it would be interesting to see it pushed further.

Thoughts?

If for one reason or another you haven't got a Linux box available and you're using Cygwin to run Node and such, then you probably want a good editor/debugger to go along with this and provide a tolerable experience comparable with that on a more native platform.

Cloud9 is pretty darned cool, and although the hosted version lacks stability with the git integration and various other things, the downloadable and hostable version is pretty much The Thing to use when dealing with large numbers of files in a fully fledged javascript client/server app.

At the moment however, if you want to use the latest node with the latest cloud9, there are a few issues, and getting this scenario working under Windows takes a tiny bit of manual effort.

• Install Cygwin.
• Install Git (using Cygwin setup)
• Install Curl (using Cygwin setup)
• Then run Cygwin.

That leaves us in a place to install the latest version of Node:

git clone git://github.com/joyent/node.git
cd node
./configure
make && make install

If during the configuration step you're told that you're missing a component, run the Cygwin setup and install that component. Some of the names are a bit different, but googling suffices for everything here - you basically want openssl-dev and a c++ compiler - it didn't ask me for much more than that.

Next up, you want NPM, this is nice and easy

curl http://npmjs.org/install.sh | sh

When this has finished chugging, you should be sat in Cygwin wondering what to do next, and the answer is - install Cloud9!

npm install cloud9

Now, in an ideal world this would work (and in the future, if you're reading this in the future, hi!) it probably will work at this point - but at the moment you're going to have to re-build one of the components for cloud9 and copy that over to the correct location.

Pop into the Cygwin setup tool and install libxml2-devel

Then from Cygwin perform the following:

git clone https://github.com/ajaxorg/o3.git
cd o3
./tools/node_modules_build
cp build/default/o3.node /usr/local/lib/node/cloud9/support/jsdav/support/node-o3-xml/lib/o3-xml/

Now if you go to a folder with a pile of javascript files, you can run cloud9 by typing.

cloud9

The fruits of this labour should look something like this:

Now you can run/debug/manage all your writings inside your browser - ace stuff.

 

Credits go to a chap called Neil Kerkin who I stole this from and ported it into Cygwin so I could do JS if caught short offline on my windows laptop. (I've done likewise on my main Ubuntu machine).