Working with Azure

Recently I've begun putting all of my HTML5 experimentation together, and coalescing it towards a single product offering.

I needed a platform on which to implement them, and settled on Windows Azure as my backend .

I figured I'd share some of my experiences with the cloud as I go, after all, it's a new environment to many of us, and the more we can inform each other, the more we can make of it.

So, a handful of tips and stories, to recap the last week or so of my life:

Connecting to a SQL Azure database

Trying to connect to the database engine itself in Management Studio won't work.

What you can do is connect directly to a database, by clicking "New Query", filling in the database connection string, which you can grab from Azure's management portal, and then specifying the database itself in the Additional Connection Parameters tab, like in the picture yon:


Moving out of SQL, and into Table Storage
I've decided to remove SQL from my backend, for various reasons. The first thing I needed to do was rejigger my entities to derive from TableServiceEntity class.

 This was a fairly simple task, as I didn't have very deep object graphs to work with, but since table storage works as a list of key/value pairs, no relations between objects are stored, and you must restructure data so each thing can stand by itself.

A quick solution I came up with for storing complex object graphs was to derive a simple base class from TableServiceEntity, which exposes domain specific key, holds a property storagetext, and a reference to an object which implements an interface, IThingTranslator, where T is the type of the root object. I called this class Thing.


All my entites now derive from Thing, and an appropriate concrete instance of ITranslateTableEntry is injected by the DI framework. Every table operation works on instances or lists of Thing, and the function of the translator is to serialize the object into storagetext on a write, or deserialize and reconstitute it on a read.

    public interface IThingTranslator where T : Thing

    {

        T Translate(string s);

        string Translate(T thing);

    }

This is a pretty flexible approach, as it lets me swap out my serialization routines to use the most appropriate one. I use JSON if I want to work with an object on the client, or something more optimized if I wanted it only in server side or lower level code, and changing between them is merely a configuration tweak.

My ongoing shenanigans can be followed at http://playground.cloudapp.net, and I'll of wild adventures about developing for WebKit and Android, using Microsoft IDEs and server-side tools.  Stay tuned!

My nonsensical WebGL javascript NES Emulator

I present to you my wholly javascript NES emulator. It spins in a cube and a monkey throws barrels slowly, that's about it.

Though it started as more of a science experiment than anything else, I wanted to see just what can be done with pure JavaScript in this brave new world of 'browser apps can do it all'.

I actually ported the code a long while ago, optimized it a little, but there's still much more I could do.

I had abandoned it until typed arrays hit the street, as I figured the performance boost over regular javascript arrays for holding everything from the memory maps to the output buffers might give me a running chance again. It did, but just barely.

The next step is to run the emulator in a web worker, sending back partial frame update information to the calling thread. That may help, besides that there's still more code to flatten, and plenty of tweaks to be found.

I wanted to play with the file api, so I'll maybe write a function to load ROMs. I only have the most basic of mapper support at this point, so there aren't many that would load, but it's about the experience.

It would be nice to have it run fast enough to add sound. It might be fun to port my apu code over one night and have it just play back register dumps.

In the meanwhile I think I'm going to move on to kicking WebGls tires some more. Multiple textures were annoying me (broken?), and I want to set up a reusable post-processing chain I can play with. Then move on to loading models, skinning and animating some meshes, terrain generation. Make it so you can lock a smart bomb on the guy and blow him up with all your twitter friends.

Of course, if you just want to play some nintendo in your browser, my Silverlight version still works. It's still missing working IRQs, sadly, and who knows if and when I'll come back to it.