24/Jun 2015
1 min. read
The “apps” section of this site is by invitation only. It is secured by Oauth2, and we use Google as our identity provider. We realize this is not a perfect arrangement (no security arrangement is), but we can assure you that Google’s role is strictly to assure us that you are indeed who you claim to be. We do not receive any information we do not already know (i.e. your email address), and we do not share any of this information with other parties.
21/Jun 2015
2 min. read
So, gremlins. I guess that’s what happens with some hard disks. One of them turned a peaceful weekend into a mad scramble for backup space and mdadm tips. Call it a fire drill without the staircases. I guess the server means to say I’ve been taking it for granted. Some lessons learned: You can use drives with different geometry if you have to. An IMPI display would have been very useful for this first-timer.
27/May 2015
1 min. read
So, now that I have this blog updating after changes (i.e. local changes + push to remote), I’m looking to get a little more ambitious. Here are my new requirements for pushing single page apps to my site: An editing model similar to my blog post workflow (see previous post) Pushing to the repository runs tests instead of blindly deploying If tests are successful deploy to host Restart any server processes required Enable dynamic discovery for new apps (i.e.
26/May 2015
1 min. read
I’m in the midst of automating deployment of my site using Git hooks. See here for a nice tutorial. There will be other pieces to my ultimate workflow too, such as creating a richer build using grunt and coffeescript, and maybe testing with Jenkins, etc. I’ll probably experiment with these things now that I’ve got my first automated push going. But so far I’m just happy to have a new editing strategy for web site content that works like writing code: Pull site source from repository Add or edit some content (flagged draft) Check it out offline (i.e.
26/May 2015
2 min. read
Seems this is a pattern: I get setup with a new blogging engine and I immediately dump a bunch of URLs that have been cluttering up my browser tabs for a couple of days. Some tabs you just can’t close, am I right? What engine, you may ask? Hugo (many thanks to Nate Finch for a great starting point … hope you don’t mind my borrowing your layout). Anyway I’ve already got another one of these undisciplined link lists on my GitHub site (see this post), but I’m keeping a separate one here, kind of off the radar.
26/May 2015
1 min. read
Skelton is a skeleton for a Node-RED UI (with apologies to fans of the late great Red). Star Fork
26/May 2015
3 min. read
Experiments with TUIO and NodeJS using Express Star Fork Project Description This work demonstrates one possible use of osc.js in the browser, extending their udp-browser example found here to reflect TUIO messages. The project is a proof of concept client-server pair meant to demonstrate the viability of: Defining a TUIO implementation in the browser Improving reconnects by means of socket.io Supporting multiple distinct TUIO sources through a single server Supporting a variety of TUIO message types Server The server performs the following roles: provides client-side static resources (JavaScript and HTML) listens for raw TUIO bundles over UDP wraps bundles to add sender identity (many devices lack “source” packets) forwards wrapped UDP packets over socket.io Client The browser-based clients perform the bulk of the work with respect to TUIO: interprets raw binary into JavaScript-legible bundles maps OSC bundles into packets and then infers operations from packet types maintains cache of TUIO objects by sender and type retires defunct objects no longer appearing in ‘alive’ packets raises events for downstream applications Architecture Diagram UDP HTTP | | PHYSICAL DEVICES | SERVER | WEB CLIENTS | | | Raw TUIO packets | | forwarded over | | socket.io with a | +-------------+ | thin wrapper for | +---------------+ | | | device identity | | | | TUIO Device | ------+ | | + -- | osc.js client | | | | | +--------------+ | | | | +-------------+ | | | Express | | | +---------------+ +--> | --> | and | --> | ---+ +-------------+ | | | socket.io | | | +---------------+ | | | | +--------------+ | | | | | TUIO Device | ------+ | | + -- | osc.js client | | | | | | | | | +-------------+ | | | | +---------------+ | | | | ...
28/Jul 2014
2 min. read
I am a prodigal student at Carleton University in Ottawa, where I’m following up on a successful undergrad in Computer Science with a Master’s degree. My focus is on building web tools for collaboration and decision-making. When I’m not coding I’m probably out walking the sweetest little whippet you ever did see. What do I mean by “average bear”? The idea comes from the observation that we are very often confronted with secondary tasks, like keeping passwords (primary task: accessing a valuable resource), or remembering touchpad gestures (primary task: operating a MacBook), or documenting our work (primary task: doing the work), or securing a system (primary task: building one).