I wasted days of my life trying to figure out how to create a solid deployment of node.js applications across heterogenous environments. Maybe I can spare you some of the trouble.

To me, deployable means that the application should be

1. able to be rolled out, with 100% confidence across development, quality assurance, and production environments, with no modification to the codebase.
2. Require only a minimal subset of pre-installed libraries. In the case of node.js, this means each environments should only guarantee the correct node version and npm version. Nothing else.
3. The application can be monitored for uptime, and can be restarted like any other unix service.

So, I have written a node.js application. I have provided a package.json file. I run npm install in the application’s folder. All the dependencies are installed correctly and my application runs. Great!

I then git add the application to the repository. And then I go to another server and do a git pull of my current branch. I try to start my application, and it fails, due to missing libraries. Why?

The problem is that npm-installed modules include instructions to the developer’s source code management tool. Instructions such as svn ignore, or git ignore. The files are included in their code when they export their modules to the archive.

So if you are unlucky enough to be using the same source code management tool as the module developer, you might be running afoul of the instructions the developer gave to his or her own repository.

So, as a git user, when I install my node modules and then issue the git add command, the downloaded modules are not allowing git to add their dependencies, because of the included .gitignore files telling git to ignore the node_modules directories. Thus, the application works locally, but not when you try to pull into another environment.

Developers need to ignore their own dependencies during development and packaging. This is appropriate. But they should also be removing their source code management tool’s helper file before they share their code.

That, however, is not going to happen, so it’s up to us to resolve.

So what I do now before adding and committing new code in a node module is this:
for f in ` find . -type f -name '.gitignore'`; do
sed -i'' -e '/^node_modules/ d' "$f"
done

which removes all the references in the .gitignore instructions for node_modules directories.

Then, when I git add, *all* the npm installed code gets added to the repo, not just the top-level dependencies. Pulling the code into another environment now retrieves all the dependencies, even three or four levels down.

I will follow up with some suggestions covering the other points I made about making a node.js app deployable.

I was saddened to see that the lovely, generous, and top-notch independent developer Peter Borg decided to quit developing his sharp little text editor “Smultron” (which is Swedish for wild strawberry, in case you’re wondering).

The package is still available from sourceforge.net, of course, but if you are a Mac OS X tiger user like I am, you might be discouraged to note that none of the recent releases work with Tiger, and there are no release notes or comments indicating which file is the most up-to-date Tiger-compatible release.

I did some brute-force testing, and discovered that version 3.1.2 of Smultron is the last release that supported Tiger.

You can download Smultron for Tiger here: http://sourceforge.net/projects/smultron/files/

One of the reasons I like Smultron so much is that it supports bash syntax highlighting, something BBEdit has never done. (I might also add, incidentally, parenthetically, sotto voce, etc, that the bash syntax hightlighting was a feature Mr. Borg generously included due to me literally begging for it.)

Now I’m sure he’s working on the next great thing. Meanwhile, a fork of Smultron has been created (aptly named Fraise, French for strawberry) and development goes on.

Courtesy of twitter user @hotdogsladies (). Pithy, always brilliant:

via @hotdogsladies (June 3, 2009)

“Star Reviews
(ordered by typical usefulness)

1. ★★★
2. ★★
3. ★★★★
4. ★★★★★
5. ★”

Background

I sometimes use my Treo 680 as a voice recorder to capture ideas for songs. For a long time I thought all the files were being backed up to my Mac. It wasn’t until I had to do a hard reset, that I realized they were not restored to the Voice Memo application as selectable voice memos. They were still on my Treo, but I couldn’t get to them or play them.

When I looked through my Palm user data files on my Mac I saw that they were in the backup folder as vpad.pdb files.
[ ~/Documents/Palm/Users/palm_username/Backups] $ ls -al | grep Vpad
-rw-r--r-- 1 user user 5430 Jul 5 20:13 07-10-22-16-32-Vpad.pdb
-rw-r--r-- 1 user user 3782 Jul 5 20:13 07-10-22-16-322-Vpad.pdb
-rw-r--r-- 1 user user 188406 Jul 5 20:13 07-11-14-1-24-Vpad.pdb
-rw-r--r-- 1 user user 64214 Jul 5 20:13 07-11-20-18-22-Vpad.pdb
-rw-r--r-- 1 user user 11590 Jul 5 20:13 07-11-20-18-222-Vpad.pdb
-rw-r--r-- 1 user user 79030 Jul 5 20:13 07-11-20-18-23-Vpad.pdb
-rw-r--r-- 1 user user 84390 Jul 5 20:13 07-11-20-18-25-Vpad.pdb
-rw-r--r-- 1 user user 40790 Jul 5 20:13 07-11-25-19-38-Vpad.pdb
-rw-r--r-- 1 user user 60518 Jul 5 20:13 07-3-16-21-37-Vpad.pdb
-rw-r--r-- 1 user user 107014 Jul 5 20:13 07-3-20-0-19-Vpad.pdb
-rw-r--r-- 1 user user 28038 Jul 5 20:13 07-3-20-0-23-Vpad.pdb
-rw-r--r-- 1 user user 43270 Jul 5 20:13 07-3-20-0-25-Vpad.pdb
-rw-r--r-- 1 user user 425270 Jul 5 20:13 07-7-24-1-45-Vpad.pdb
-rw-r--r-- 1 user user 131254 Jul 5 20:13 07-8-5-0-25-Vpad.pdb
-rw-r--r-- 1 user user 317942 Jul 5 20:13 07-8-5-22-36-Vpad.pdb
-rw-r--r-- 1 user user 333974 Jul 5 20:13 07-9-17-23-06-Vpad.pdb
-rw-r--r-- 1 user user 278870 Jul 5 20:13 08-2-10-18-31-Vpad.pdb
-rw-r--r-- 1 user user 85606 Jul 5 20:13 08-5-20-21-25-Vpad.pdb

However, there were no playable audio files where I expected to find them (/Users/username/Documents/Palm/Users/palm_username/Voice%20Memo/). That was when I realized that the hotsync conduit for Voice Memo did not work, and never had been working. There seems to be some incompatibility between the Treo 680 voice memo files and Mac OS X. I don’t see why this has not been fixed yet, but whatever the cause of this negligence on the part of the developers, I was stuck with a bunch of Vpad.pdb files that I could no longer access on my Palm or play on my Mac. Some of them were extremely important to me, containing ideas for an upcoming album.

Details of my scenario:
Palm Treo 680 running Palm OS Garnet v. 5.4.9
Voice Memo version 1.4
HotSync Voice Memo conduit version 1.0 (so that's why!!! :-) )
Mac OS X 10.4.11


Nevertheless, I felt fairly confident that embedded in these pdb files were some kind of normal audio file format. I could not imagine that Palm would have invented an entirely proprietary compressed audio format.
Continue reading ‘Recovering vpad.pdb files from a Palm Treo 680 with Mac OS X’

Convoluted title, eh? After many years of intermittently being miffed when I couldn’t just type cd /NameofAlias and have the bash shell transport me into the directory the alias pointed to, I finally decided to do something about it.

First stop: Mac OS X Hints, where I looked at these two hints:
Enable ‘cd’ into directory aliases from the Terminal
A script to reveal alias paths in the Terminal

From the insight gained there, I cobbled together my one-step solution to the problem…
Continue reading ‘Making the Mac OS X bash shell alias and symlink agnostic’