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.

Symtoms:

  • 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).

Baseline Web Development Environment on Debian 7.2.0

Installed a fresh copy of Debian 7.2.0 in a VirtualBox VM and am gong through the process of setting up a web development environment on top of this Linux distribution. FWIW, I like KDE and am using it instead of Gnome on Debian.

I’ve already installed Chromium browser. Also, if you’re new to Debian and wondering WTF Firefox, it’s Iceweasle (should be perfectly obvious right?) Google it if you’re curious. I was.

Step 0: Become member of sudo group

As root, adduser username sudo

If su’d, exit, logout/login user to get sudo group priviledge.

Step 1: Node.js

Node.js is too fast moving for Debian package support so you need to do a little work. Helpful stackoverflow thread: http://stackoverflow.com/questions/10478768/installing-node-js-on-debian-6-0

I’m following the instructions here: http://sekati.com/etc/install-nodejs-on-debian-squeeze. Credit: Sekati


sudo apt-get update && apt-get install git-core curl build-essential openssl libssl-dev
git clone https://github.com/joyent/node.git
cd node

# 'git tag' shows all available versions: select the latest stable.
git checkout v0.10.23

# Configure seems not to find libssl by default so we give it an explicit pointer.
# Optionally: you can isolate node by adding --prefix=/opt/node
./configure --openssl-libpath=/usr/lib/ssl
make
make test
sudo make install
node -v # it's alive!

# Lucky us: NPM is packaged with Node.js source so this is now installed too
# curl http://npmjs.org/install.sh | sudo sh
npm -v # it's alive!

… which works like a charm.

Note: I’m seeing a single failure in the make test step currently (64-bit Debian and Ubuntu-based distros). I’m not sure what the impact of this is. Seems like the issue is known: https://github.com/joyent/node/issues/5343

Step 2: CoffeeScript

http://coffeescript.org/

sudo npm install -g coffee-script

Note: You might be setting up a new VM? Better make sure that that your ~/tmp directory ownership is correct; if the first use of ~/tmp is as root then it will be created with root ownership and later when you try to npm install later you’ll get an EACCES error…

Step 3: Emacs

because old habits die hard

sudo apt-get install emacs

Step 4: Yeoman

http://yeoman.io/gettingstarted.html

… and follow the directions remembering to sudo all those npm install -g ‘s!

This will get you Yeoman, Grunt and Bower installed.

Edit: Glad I took the time to write these steps down because when I came back this AM to continue on, I hit a nasty unresolved bug in VirtualBox 4.2.18 r88780 that made the saved VDI boot media inaccessible.  The only way to work-around was to loose the latest VM state and revert per directions posted here: https://www.virtualbox.org/ticket/11750

http://beshoy.girgis.us/2012/11/virtualbox-ubuntu-chrome-rendering-issue/#comment-136

^— possible fix for annoying rendering problems with Chrome/Chromium under KDE executing in latest VirtualBox 4.3.4 (works for me).

So You Want Your JavaScript Library to Run Everywhere?

Guess this is going to be a running-edit post as the more I dig, the more I find… Damn it, this should be easier.

Originally I wrote:

A very helpful post on SitePen.com: Run-Anywhere JavaScript

All I have to say is what a #*&^Q mess… Suppose it’s not too bad once you work through the details and arrive at stable implementation pattern for your library but it’s a serious mess if you just wander in cold off the street and try to understand the various JavaScript module packaging options in use.

One fairly straight-forward example that seems to cover the bases is is available in the node-uuid module (boofa/node-uuid) on GitHub. I’m reading the SitePen.com blog post in one browser instance and looking at the node-uuid source in another to audit my understanding. Helpful.

Edit (and I’ll leave it here and cover what I learn in another post):

node-uuid seems to be leveraging a boilerplate approach. The SitePen.com blog post is several years old and the most recent comment (a year old) on uRequire appears to be the correct vector from my starting point in the zone of ignorance.

This also will drag me through several topics on the list of things I need to know. For example Yeoman (and everything else required to set up an actually defensible/sensible build and test environment for the ONMjs library which today, although it “works” in the browser, and encapsulates a bunch of really useful ideas (says me) is not the holistic little generally useful library I want it to be).