Furnish Your Seattle Start-up on a Budget

Here’s what I dug up for sources of used office furniture in greater Seattle.

Particularly interesting is the City of Seattle’s surplus warehouse.

I’m looking for a new desk for a whole bunch of monitors…

Node.js App Debugging

Install node-inspector:

npm install -g node-inspector

Start the node-inspector server:

node-inspector &

Start your node app under node-inspector debugger:

node --debug your/node/program.js

Break on entry:

node --debug-brk your/node/program.js

Attach Chrome debugger locally:

chrome &

Link: Lua scripting for Redis

Useful links with information on writing Redis extensions in Lua:




Chevy misses ford, sinks.

Springtime in the Snoqualmie River Valley:


Please support the Snoqualmie Valley literacy program.

I couldn’t drive by this scene w/out stopping to take a photo.

You Can’t Connect the Dots Looking Forward

Printed and hanging over my workstation:

“You can’t connect the dots looking forward. You can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something; your gut, karma, life, destiny, whatever. Because believing that the dots will connect for you down the road will give you the confidence you need to follow your heart even when it leads off the well-worn path. And, that will make all the difference.” – Steve Jobs


Object Namespace Manager on node.js

I’ve been porting the Object Namespace Manager library (formerly ONMjs, now simply onm) from a global namespace implementation to CommonJS and working on a Grunt-based build strategy. Here’s what I need to do:

  • Maintain the onm source code, in CoffeeScript, using a single module format. I’m thinking this will be CommonJS. But, we’ll see.
  • Generate debug and release CommonJS packages for node.js/npm.
  • Generate debug and release packages for the browser using (likely) AMD/RequireJS, and possibly a global namespace option for pure HTML clients that leverage an AppCache manifest for this JavaScript.

onm on node via npm

Going forward, the Object Namespace Manager (onm) will be distributed via the npm package for node.js.

npm install onm

Or, to save onm as a dependency in your package.json:

npm install onm --save

using onm on node

// index.js
var onm = require('onm');
var dataModel = new onm.Model({ jsonTag: "testNamespace" });
var dataStore = new onm.Store(dataModel);
console.log(dataStore.toJSON(undefined, 2));

… will print to the debug console log:

  "testNamespace": {}

consuming public onm data models via npm

In essence an onm data model declaration defines a data exchange protocol. To make your data exchange protocol public, package your onm data model declaration as a node.js package and publish it via npm.

For example, I’ve published the node package onmd-scdl for a complicated data model called Software Circuit Description Language (SCDL). The details aren’t important. What is cool is how easy it is for you to work with SCDL data now.

Do a little setup:

mkdir test && cd $_
npm install onm
npm install onmd-scdl

Now a little code:

// index.js
var onm = require('onm');
var scdl = require('onmd-scdl');
// Default construct a SCDL object store.
var scdlStore = new onm.Store(new onm.Model(scdl.DataModel));
console.log(scdlStore.toJSON(undefined, 2));

… execute the node program:

node index.js

… prints the following JSON to the console log:

  "scdl": {
    "catalogues": {}

Generically, that is without regard to the data model, the onm package provides object create, remove, enumerate, traverse, introspect, address, observation, and and serialize services via its API (https://github.com/Encapsule/ONMjs/wiki).

So there’s a lot more that we could have done in the above example.

Here’s a more complicated example that leverages the onm package API to affect data model introspection and initialization of test SCDL data set.

GitHub: https://github.com/ChrisRus/scdl-data-model-demo

onm in the browser

I’m between solutions for the browser as of this writing. The current onm package build (based on Grunt) produces a single-file JavaScript file for use in the browser via grunt-browserify. I have not tested this yet. And, I may never.

I’m looking at uRequire as a possible way to achieve the single source code base, multiple build target scenarios I have in mind of onm package’s Grunt build.

Weird Chome/Chromium Rendering Problems in KDE 4.11.2 under VirtualBox

I recently upgraded to VirtualBox 4.3.4 on a Windows 7 host machine and noticed a bunch of strange rendering problems with Chrome/Chromium in Debian and Kubuntu Linux guest instances running the latest stable KDE 4.11.2.


  • Whenever Chrome opens a modal dialog box, it is rendered _below_ the active window (i.e. not visible). Because it’s modal, Chome appears to hang.
  • When the modal dialog is displayed, dragging the outer frame of the Chrome window shears: the tab remains in-place during drag and the frame moves. Releasing the drag snaps the client area of the tab back into the correct coordinates making the previously invisible modal dialog visible.
  • This same “shearing” (due to what I believe is a Z-order bug) is manifest in drop-down menus, and also when moving other non-Chrome app windows over the tab client area of a running Chrome instance. The client area of the active tab appears to remain pinned at the top of the Z-order.

I tried re-installing the VirtualBox guest additions, and even switched Linux trying to get out from underneath this problem. Finally, I tracked down some useful information:

The relevant tip is to modify the google-chrome.desktop file to add the –blacklist-accelerated-compositing option to the end of the exec lines (see first link above for details).

This is preferable to completely disabling VirtualBox 3D acceleration. I’ve only seen this problem with Chrome/Chromium (so far).