 |
| Screenshot of the VirtualBox Web Console (Photo credit: Wikipedia) |
But starting out means bootstrapping. Right now, after a couple of years of flailing I've got something that's sorta-kinda-good. And I can make it better faster because of that.
The first bit of awesomeness is that it runs in a VM. That makes it platform independent, easily cloneable, and I can snapshot it any time I'm doing something scary. More than once I've screwed things up. With a real system I'd have to undo a lot of crap. With a virtual machine I just go back to the last good snapshot and move forward.
The second bit of awesomeness is that on top of the VM I'm building components that run in a compliant browser. I'm using Chromium/Chrome as my compliant browser, but it should all work in Firefox and in newer versions of IE, in case anyone cares. I don't so let's just consider that Chrome is part of the awesomeness.
I'm using Virtualbox as my VM Manager, but my virtual disks are VMDKs, which means they should be able to run with VMWare as well. I haven't done the experiment because I find Virtualbox more than good enough for me.
Every couple of days I snapshot, then shut down my VM, turn it into a Virtual Appliance and upload the image to the cloud. A Virtual Appliance is a file in Open Virtualization Format. In theory it can be imported by any conformant VM Manager. Again I've only imported it into VirtualBox, but in theory that's the easy way to get to, for example, VMWare.
Right now my OVF appliance is a shade under 5 GB. It takes overnight and then some to upload from my home network, but I discovered on my last trip to the University of Maine that their guest network uploads at around 40 times home network speed. Woo hoo!
My VM has everything that I need to do my work, all pre-configured and kept up-to-date. And recently I've created a startup script so when the VM boots up it starts all the pieces. Since the stuff that I am using uses a browser at the front end, it needs a web server for the back end. So that's one of the things that loads up: a server that serves web pages and also WebSockets.
My back-end components are lightweight servers that run independently of the main server and talk to it and to each other using WebSockets. And they can talk to other components, as needed, by translating to regular sockets, or by using a server that spawns processes and creates WebSocket interfaces to stdin, stdout, and stderr. That means that any component can talk to any other component.
I use gulp as my back end, and that's what I'm going to talk about next.
