My next mini-experiment is to explore different ways to getting data into Kinetic diagrams.

Kinetic diagrams are stored in plain text files. Initially, my idea described in earlier posts was to create a custom domain-specific-language (DSL) using Ragel, to define all the objects in the diagram. Each object can have metadata attributes. For example, suppose there’s a “Salary” box in my finance diagram. “Salary” might have the following attributes: label=Work Salary, vendor=Coal Mines, and amount=3580.  Here’s how the DSL would describe the objects in the finance diagram:

+ Salary    | label="Work salary",    vendor="Coal Mines",  amt=3580
+ Checking  | label="Checking",       vendor="BigBank",     amt=400
+ Emergency | label="Emergency fund", vendor=" ",           amt=150
+ Savings1  | label="Savings",        vendor="MegaSavings", amt=720
+ Savings2  | label="Savings",        vendor="BigBank",     amt=214
+ Stocks    | label="Stocks",         vendor="Tradetek",    amt=1196
+ Wallet    | label="Wallet",         vendor=" ",           amt=143
+ Purchases | label="Purchases",      vendor="stores",      amt=212

But something about this approach just feels wrong. After all, can I realistically expect users to type vendor=”Coal Mines” in order to set an attribute value? Of course not. Most users aren’t programmers, nor care to be. So my next idea was to allow the user to type a textual data table:

-------------------------------------------------------------
name           | label              | vendor         | amt
-------------------------------------------------------------
Salary         | Work salary        | Coal Mines     | 3580
Checking       | Checking           | BigBank        | 400
Emergency      | Emergency fund     |                | 150
Savings1       | Savings            | MegaSavings    | 720
Savings2       | Savings            | BigBank        | 214
Stocks         | Stocks             | Tradetek       | 1196
Wallet         | Wallet             |                | 143
Purchases      | Purchases          | stores         | 212
----------------------------------------------------------- 

This textual table is much clearer and readable. The gotcha, however, is that this requires the user to format that textual table perfectly. I’d need to define some required format in order to distinguish the header values from the rest of the table, and separate columns from each other. So while readable, this approach is still too brittle for real-world use.

The new approach I’m exploring now is to just read the data from a spreadsheet or database directly. After all, wouldn’t it be great if the user can just edit the data in a spreadsheet?

This will be a fun mini-experiment…stay tuned.

A couple of weeks ago, I accepted “Mission Capistrano” to automate the deployment process. I figure I owe an update: Well, it’s “Mission accomplished!”…all thanks to Capistrano.

(Photo by pasukaru76, Creative Commons license)

Meet Capistrano, my new unpaid and overworked robotic intern. Today, instead of dealing through multiple tedious steps, I simply type:

cap deploy

and Capistrano automatically takes care of the dirty work. What used to take 15 minutes now takes less than 4 seconds.

Here’s my 8-line configuration file…feel free to use it as a starting point for your projects:

set :application,  "kinetic"
set :repository,   "."
set :scm,          :none
set :deploy_via,   :copy
set :copy_exclude, [".DS_Store", "vendor"]
set :deploy_to,    "/home/kinetic/kineticdiagrams.com/"
set :user,         "kinetic"
role :app,         "kineticdiagrams.com"

With Capistrano, I can painlessly to deploy to multiple servers in parallel. And my favorite feature is that I can roll-back to any previously-deployed version. Let’s say I accidentally deploy a bug in my application code and expose my gaffe to the world. With Capistrano, I can easily roll-back to an earlier working version

cap deploy:rollback

and continue with the rest of my day, dignity intact. If only my romantic relationships had a similar “undo” button…

Graphviz now successfully works on my Snow Leopard installation.

The root cause: Turns out that some of my earlier MacPorts ports were outdated since they were built when I was still running Mac OS X Leopard. Installing the graphviz-gui port would appear to be fine, however, since some of the Graphviz dependencies were outdated for Mac OS X Snow Leopard’s 64-bit architecture, running the graphviz-gui port would fail.

The fix: By re-installing the graphviz-gui port after wiping out all the installed MacPorts ports (and therefore starting from a “clean” starting point), all of the Graphviz dependencies were re-installed correctly to work with Snow Leopard’s 64-bit architecture.

Command-line history:

sudo port -f uninstall installed
sudo port install graphviz-gui
dot -Tpng /tmp/diagram.txt > /tmp/test.png

Running into issues getting Graphviz to play nicely with Snow Leopard. This post describes my very issue; unfortunately, the only potential “fix” it describes is to re-install MacPorts from scratch. Frustrating.