Thursday, August 20, 2015

Adventures with Unity3d Web Player and

I am currently building a multi-player game with Unity3d, ES6 and  I had a LOT of challenges getting this all to work, in particular I had problems with the Unity web player’s security sandbox approach and included libraries.  I’m dumping my pain and learnings into this article both for my own reference and hopefully to help some folks out there who wish to pursue a similar approach and have similar challenges

The Server

- Node
- (1.3.6)
- ES6 + Babel + Gulp


The Client

- Unity3D (5.1.2f1 Personal)
- (

I chose this project by Fabio Panettieri because it is well written, uses websocket-sharp and supports the newer 1.0 protocol which a lot of the other libraries don’t.



This is a bit of an odd combination I guess but I’m really into ES6 right now and building the game backend in ES6 felt natural and fluid.  The Unity front end is a necessary evil because, well it needs to look like a game or nobody is going to play it. I guess I could do the same thing with Angular2 and canvas but Unity3d is the for-purpose-and-free tool for games, it’s fast and c# is not too horrible. 

Ultimately this game will probably go to Steam using a desktop client but I am targeting the Unity web player because in the Alpha stages, I just wanted folks to hit a web page and play.  Here is where my problems began.

Web Player Problem 1 - Getting it to Build

Flipping from standalone mode to web player mode (file -> Build Settings -> Web player) immediately breaks the build of game due to compilation issues in the the websocket-sharp library.  After digging around, I ended up following the dubious example set here ( and manually hacking the websocket-sharp code so that it would compile.  I wasn’t happy with this approach but I seemed to be mostly hacking out stuff that wasn’t needed so I just kept hacking until it compiled.

Note that obviously this approach assumes you have pulled in the whole folder into your assets folder including all the SocketIOComponent stuff and the websocket-sharp source also.  Some folks suggested to build the library separately outside of Unity and then just import the DLL’s.  I could not get this to work, the compiled dll’s were not compatible with  In hindsight this may have been a versioning problem, not sure.

Web Player Problem 2 - Sandbox Security

After getting the game to build correctly, the game appears to work from the unity editor but after packaging and running the game from a test page, it fails with the following error:- 

Unable to connect, as no valid crossdomain policy was found

This was difficult to track down and fix but this page ( was a great reference and helped a lot (RTFM).  The first key to figuring this out is to change the editor setting to emulate the web player behaviour in the editor, this makes it much easier to reproduce and debug.  Do this by choosing  Edit —>  Project Settings —>  Editor  and fill in the  WWW Security Emulation box.  I used this url (http://localhost:10090/mygame.html) because I was serving my from 10090 but I think only the host/port is important. 
A couple of notes on the debugging:-

  • Using the emulation mode puts the errors in the Editor.log (~/Library/Logs/Unity/Editor.log on OS X) see this link for details (
  • I didn’t find the Debug setting (ENABLE_CROSSDOMAIN_LOGGING 1) to be very helpful but try it if you want
  • I could NOT get Security.PrefetchSocketPolicy()  to work.  Supposedly this allows you to set up the socket security handshake on a port other than the default of 843.  I ended up using the default port but this was ok because on my host (digital ocean) I have have no problem with admin access (I think you need admin access to serve on ports lower than 1024).
  • Definitely use the telnet method (under the Debugging section of the above article) to check that your security handshake is working.  If the telnet doesn’t work, your web player won’t be able to connect either.

Socket Policy Server - The last piece of the puzzle

This very helpful github issue ( was the key to solving the security issue to quote… “You need a Socket Policy Server”.  I had tried several different ways of serving out the policy file from within my existing node server (and this might still be possible) but in the end, I decided to use a standalone policy server.

I used the project from here ( but I had to hack around with it to get it to work.  You might have better luck with the ‘out of the box’ version but if not, here’s what I did to it:-
  • Stripped out all of the startStopDaemon stuff in favour of a custom upstart/forever config (see below) because that is the standard approach for all my node projects
  • Stripped out all of the Global Config stuff because It was annoying and I couldn’t get it to work.

Wrapping up

So after setting up my socket-policy-server to run, the game was now able to connect to the server and the game works!  Despite all of the hassles, I still think this is a good stack for this type of application.

A note on Adobe Flash

Apparently the Unity3d Web player security approach closely mirrors the approach used by the Adobe Flash player.  If you are having a similar problem with a Flash player app talking to a node/ server, using the same approach may be helpful.

Check out the game! (pre-alpha, be kind)

Tuesday, June 16, 2015

Debugging is Evil: Do it less

Debugging is Evil

Debugging is evil.  Debugging is not coding.

Coding is a creative flow.  Coding is bringing together objects and methods and classes to represent and solve problems for your users.  Coding adds value, solving problems for your users is useful.

Debugging is not coding.  Debugging is an analytical process.  Debugging adds no value in and of itself.  The very best you can do with debugging is to get it over quickly so you can realise the value that you already added when you were coding.

Do it Less

Avoid it (TDD/BDD)

TDD and BDD are careful and considered processes that allow you to incrementally build up your code so that it solves the exact problem it is meant to.  It also helps you to identify any bugs as soon as you have coded them.  This helps get your debugging over quickly because the code is fresh in your mind and you have only written a little bit of code since you were last 'green'.

Go Around it

Sometimes coding something in a completely different way may take less time than debugging a problem in the method you have used.  Did you really need to introduce that new library? did you really need that abstraction?  Was that breaking refactor that seemed more 'elegant' really necessary or would the previous 'clunky' approach that worked be ok (btw, your users don't care about elegant code, just features)

Talk to a Duck.. or a person

Some people do this.  It is called 'Rubber Duck Debugging'.  I like to talk to team members, they say useful stuff back :)

Saturday, January 24, 2015

Integration Testing a Restful Endpoint with Request and Jasmine and Node.JS

What is it for?

I am building a simple restful API using Express over MongoDB in order to support a mobile application.  Even though the endpoint was quite straightforward, I wanted to ensure it is properly tested.  In creating this test, I wanted to fulfill some simple objectives
  • Integration style test - completely independent of the implementation
  • Setup and Teardown of the database.
  • Fast, simple, as little complexity as possible

What Am I Testing?

The API is simple
../rules/clientId/ruleId (get) - Retrieve a specific rule for a specific client
../rules/clientId (get) - Retrieve all of the rules for a specific client
../rules (post) - Store a rule
../rules/clientId/ruleId (delete) - Delete a specific rule for a specific client

Why Use Jasmine? Why not use Frisby.js?

Ah tool choice, such a fraught area.  Jasmine is well established and  there is a great node port of Jasmine here that is reasonably active.  All you Mocha folks and Karma fanatics, pls comment and tell me why framework X is better than Jasmine :)

Frisby.js seems to have a lot of search engine traction but It doesn't support setup/teardown ( and seemed to force me into a certain way of doing things which I didn't like.

Enough already let's do it

The full gist is here if you want to look at it...


To setup, I use beforeEach with the done option because I want to asynchronously move on to the test once the MongoDB call is finished.  To setup for the tests, I insert a single 'rule' document containing just ID information.
        MongoClient.connect("mongodb://" + config.mongo_db_address + ":" + config.mongo_db_port + "/" + config.mongo_db_name, function (err, db) {
            var collection = db.collection('rules');
            collection.insert({"clientId": "test","ruleId": "test1"}, function (err, result) {


To teardown, I issue a global delete for all rules belonging to the test client.  This is a bit crude but as in all integration style testing, I don't have the luxury of simply making tests transactional.  Note that again, I am using the Async form and using a done method to indicate that things can move on.

    afterEach(function(done) {
        MongoClient.connect("mongodb://" + config.mongo_db_address + ":" + config.mongo_db_port + "/" + config.mongo_db_name, function (err, db) {
            var collection = db.collection('rules');
            collection.remove({ "clientId": "test" }, function (err, result) {

Update: I am now using uri: not url: and also using the json:true parameter in the request options.  this means I don't need to JSON.parse the bodyString like I was before.. much cleaner.

Testing the Get

Testing the getter method is simple.  I simply use the request component to retrieve the body string from the endpoint, use JSON.parse to convert it to an object littoral and then assert its values.

    it("should retrieve a specific rule", function(done) {
            uri: "http://localhost:3000/api/rules/test/test1",
            json: true
        }, function(error, response, body){

Testing the Post

For the Post, I really should check the addition to the DB but I cheat a bit by making a nested get call and verifying the return result (I use the same Kluge for delete).

    it("should store a rule", function(done) {
            uri: "http://localhost:3000/api/rules",
            json:{"clientId": "test","ruleId": "test2"}
        }, function(error, response, bodyPost){

                url: "http://localhost:3000/api/rules/test/test2",
            }, function(error, response, body){


Thats it, hope this helps.  I certainly thought this would be easier than it was and had dead ends with Frisby.js (no setup/teardown) and fiddling about with Request but this works.  All comments and suggestions accepted.


Thursday, December 25, 2014

The key problem that AngularJS solves (and React does not)

Software exists to solve problems for people.  Software frameworks exist to solve problems with developing software.  Reflecting on the hype and excitement around React, I thought it was a good time to think about the key problem solved by the AngularJS 1.x framework and contrast that with the React framework.

Web design and coding are different
HTML and CSS are fundamentally about visual layout, look and feel.  To be good at these, you need a sense of design and a lot of patience.  Coding data access, UI interaction, callbacks and form validation is a completely different discipline and there are not many people that are productive at both of these.

AngularJS solves this problem by providing a clean separation between the two disciplines.  A developer can take a completed HTML/CSS layout and 'tag it up' to make it interactive, a designer can refactor the visual layout of a page without messing about with the code.

React does not solve this problem at all and requires you to 'cut up' the HTML/CSS and emit it to the framework from the code. Inevitably, this means that to be productive at coding and refactoring your React solution, you need to be productive at both disciplines.

Not every developer is a Front End developer
I have introduced AngularJS to development shops with no specialist front end developers at all. We needed to use a consultant to build the initial framework and build some components for us but that having been done, my team of backend Java developers were able to crank out a lot of UI and were very productive at it.

This worked because we were able to use a stock standard CSS approach (we used Bootstrap) and the HTML could be safely cut and pasted from templates and already existing applications and let our coders do coding.  The separation of concerns inherent in AngularJS made this possible.

React code is spaghetti code

Just going through the tutorial, I found myself hunting around in the code, looking for where a particular piece of code or feature was.  It might just be unfamiliarity with the approach but the code just looked like spaghetti to me and I have serious concerns about productivity and the cost of refactoring.

MVC was created for a reason
The MVC pattern and all of it's variants work because it offers a clean separation between the layers, a separation of concerns.  React is smashing these things back together and this seems like a backwards step to me.

Monday, September 29, 2014

How to NOT Learn Coffee Script in 90 Minutes

So I am tired of looking at reading otherwise reasonable articles on angular.js or and finding myself bamboozled by this crazy ruby-esque nonsense that is coffeescript.  Time to learn.

My train ride home is about 90 minutes.  that should be enough.  Lets go

8:19 - start (


Michaels-MacBook-Pro:learn_cs michael$ npm install -g coffee-script
npm http GET
npm http 200
npm http GET
npm http 200
/usr/local/share/npm/bin/coffee -> /usr/local/share/npm/lib/node_modules/coffee-script/bin/coffee
/usr/local/share/npm/bin/cake -> /usr/local/share/npm/lib/node_modules/coffee-script/bin/cake
coffee-script@1.7.1 /usr/local/share/npm/lib/node_modules/coffee-script
└── mkdirp@0.3.5



done.. I guess I'm ready (8:27).  where to start...

8:33, I have written some functions in coffeescript and javascript (using a node console)  the parentheses feel more solid and familiar but the coffescript is more fluid to write and I am digging that I can invoke a function without parenthesis (cube 8.... cool)

Michaels-MacBook-Pro:learn_cs michael$ coffee
coffee> square = (x) -> x * x
coffee> square(3)
coffee> cube = (x) -> square(x) * x
coffee> cube 8

8:39 oops, first problem, coffee command line can't do multiline functions (node commandline can do this, i guess because it knows about brackets n stuff...)

coffee> fill = (container, liquid = "coffee") ->
coffee> "filling the #{container} with #{liquid}"
ReferenceError: container is not defined
  at repl:1:22.....

Ok so i can switch to multiline (thanks stack overflow) with ctrl-v (

but it doesn't work!

coffee> fill = (container, liquid = "coffee") -> "filling the #{container} with #{liquid}.."
coffee> fill "cup"
'filling the cup with coffee..'
------> shit = (container, liquid = "coffee") ->
....... "filling the #{container} with #{liquid}.."
ReferenceError: container is not defined

its now 8:55 that was seriously annoying and I have burned 17 minutes on it.  poor form.  switching to an IDE for mutiline i guess.

YAML style littorals are cool...

kids =
    name: "max"
    age: 11
    name: "ida"
    age: 9


Michaels-MacBook-Pro:learn_cs michael$ coffee test.cs
{ brother: { name: 'max', age: 11 },
  sister: { name: 'ida', age: 9 } }

But If I accidentally mess up the whitespace in the file.. my code breaks!

kids =
name: "max"
age: 11
name: "ida"
age: 9


Michaels-MacBook-Pro:learn_cs michael$ coffee test.cs
/Users/michael/Workspace/learn_cs/test.cs:2:9: error: unexpected newline

even single spaces can mess up the meaning of my littoral..

   name: "max"
  age: 11

Michaels-MacBook-Pro:learn_cs michael$ coffee test.cs
{ brother: { name: 'max' },
  age: 11,
  sister: { name: 'ida', age: 9 } }

9:10.. having serious concerns about cs now. It seems flakey

9:20.. have never had a problem with reserved words and I don't mind typing 'var'

9:32.. writing some code now, ifs and thens.

9:37.. running out of time.  I didn't get splats , or comprehend comprehensions.
Overall, I don't like it. 

Javascript is straightforward, the same as Java is straightforward, no surprises.  I don't mind ruby, i get that it is beautiful and all that.  I think coffeescript is trying to be ruby but doesn't quite make it.  It allso seems to try to please javascript developers but doesn't quite do that either. 

All in all it's a bit of a hot mess IMO and I will be continuing to avoid it, along with all the other things that compile to Javascript like GWT (Yuck) and Typescript (Yuck also).


Sunday, August 17, 2014

App Idea: Support your personal learning with revision reminders

Being myself in the throes of re-learning Java, Maven and IntelliJ (don't ask) I found this article resonated a lot with me...

In particular, this statement..

 If you study, wait, and then study again, the longer the wait, the more you’ll have learned after this second study session.

This is 100% me.  I study, understand and then do nothing and all the good learning evaporates away.  I will come back to the topic much too late and have to start from scratch again.  I know I should set reminders and come back to material sooner but that never happens in practice.

Then it struck me that perhaps a simple app might assist here.  The pitch might go something like this..

"You know how when you're self learning, you first forget to revise the material and then you forget the learnings?

Well what we do is make it easy for you to post entries each time you learn a key concept and then play them back to you at exactly the right time to maximise your learning retention.

In fact Research has shown that if you study, wait and then study again, the longer the wait, the more you'll have learned."

It wouldn't be a hard app to build.  

Capturing the learning entries and making it 'easy' would hard to get right, I thought maybe use a 'share' type functionality might work except you are sharing it with yourself.

The 'exactly the right time' thing is also challenging.  I thought maybe you could ask the user a question for each revision, something like "Too soon | Just Right | Too Late" to help train the replay algorithm to the users retention profile

There are also opportunities to do other cool stuff with the data like maybe you could 'cram' a particular topic by pulling together all of the entries for that topic.

Just a thought.


Tuesday, July 01, 2014

2 Things I learned by reading the AngularJS Source Code

I'm busy working on a curriculum for my favourite front end Javascript framework AngularJS.  To really understand it, I have been stepping through and reading the AngularJS Source.

This codebase is awesome! well written and well documented.  Over and above understanding AngularJS, this is what I have learned along the way.

1) Doing more things faster with for
I have always just used for for the basic pro-forma like this:-

for (var j=0; j < myArray.length; j++) {
//do stuff with j

But the for loop can do so much more, check this out from the AngularJS source...
    // iterate over the attributes
    for (var attr, name, nName, ngAttrName, value, nAttrs = node.attributes,
        j = 0, jj = nAttrs && nAttrs.length; j < jj; j++) {

Wow! here, they are initialising all sorts of variables that will be used in the loop, not just the iterator variable 'j'

Also, note that they are 'caching' the length of the array in the variable 'jj'.  Turns out that this is a great optimisation technique and makes the loop go faster because you don't need to re-evaluate the length property on each loop.

for more details on optimising loops, check out these links

2) Assignment returns a value.. Use it

Look at this..
if (directiveValue = directive.scope) {

This looks like a mistake at first.. usually you use '==' in your if statements however this is definitely on purpose.  The assignment returns a value.  In this case, it returns the value of directive.scope to the 'if' statement.  'if' will evaluate any object to true (unless it is undefined) so this statement has both sets the directiveValue to the directive.scope object and checks if the directive.scope is defined.. elegant!

There are some more good examples of this here..