djwonk

I’ve seen the phrase “rock star software developer” one too many times. This trite and misleading metaphor needs to die. By decapitation if necessary.

In my opinion, the key ingredients of being a rock star are mediocre talent, a massive publicity machine, and an insatiable ego. These are not qualities that I want to see transfer into the software world. Software development, in its ideal, is about curiosity, teams, and skills. It should be about merit, clear thinking, and sharing. It should not be molded after irrational cult followings, record company influence, boy bands, or beat-it-into-your-brains radio station overplay.

I agree that good software development might have things in common with a good music. Developers must perform! But the nature of the audience is different — it involves other software developers (who read the source code) as well as people who use the software (who probably don’t care if the programmer has a mohawk, leather pants, and a life expectancy of 27 years).

So let’s not use rock stars as our model. Only a select few rock stars, in my opinion, are masters of music. I would take an average jazz musician over the average “rock star” any day, because the jazz field encourages real-time improvisation and understanding music on many levels. Let’s find programmers who can deliver (similar to performance artists) but also understand the culture and history of programming (similar to musicologists).

There have to be more useful metaphors for greatness in software development. They should be fresh, specific, and (hopefully) strange or funny. Here’s an example I just threw together: “I’m looking for a software developer that is a direct descendant of Perseus. Someone who can refactor some horrible code (i.e. slay Medusa) without turning to stone.”

P.S. Ever met someone who proclaims their own greatness? Perhaps it is better to let someone else to credit your skills than to wave a flag brandishing your mighty abilities. I hear that a sign of true greatness is humility. Putting yourself on a pedestal is probably counterproductive, unless you want to surround yourself with other arrogant people. Instead, aim to be approachable. This opens up a learning frame of mind, which allows you to become even better in the long run.

MySQL was feeling lonely, so I decided to install PostgreSQL as well:

sudo port install postgresql83 postgresql83-server

Now update your path by adding this line to your .profile:

export PATH=”/opt/local/lib/postgresql83/bin:$PATH”

# the exact order is up to you

I also recommend adding the architecture flag if you use an Intel-based Mac:

export ARCHFLAGS=”-arch i386″

# Don’t forget to restart your terminal or resource .profile

Install the postgres rubygem:

sudo gem install postgres

Create the default database:

sudo mkdir -p /opt/local/var/db/postgresql83/defaultdb

sudo chown postgres:postgres /opt/local/var/db/postgresql83/defaultdb

sudo su postgres -c ‘/opt/local/lib/postgresql83/bin/initdb -D /opt/local/var/db/postgresql83/defaultdb’

To start the server:

sudo su postgres -c ‘/opt/local/lib/postgresql83/bin/postgres -D /opt/local/var/db/postgresql83/defaultdb’

To start the server with a logfile (warning this does not work for me):

sudo su postgres -c ‘/opt/local/lib/postgresql83/bin/pg_ctl -D /opt/local/var/db/postgresql83/defaultdb -l logfile start’

This post was partly inspired by the March 2008 article by ShiftEleven.

I recently installed Ruby 1.8.7 in /usr/local. I have Ruby 1.8.6 installed via MacPorts in /opt/local. I couldn’t understand why TextMate’s Ruby bundle was running Ruby 1.8.7 even though my bash .profile was setting PATH correctly; i.e. /opt/local/bin was before /usr/local/bin.

Several people in the #textmate IRC channel helped out, including Allan, the creator of TextMate, the popular text editor for the Mac. These are the must-read resources:

• TextMate Search Path
• TextMate Ruby Version Issue

The key thing I learned is that TextMate has two execution contexts: the “bash execution environment” and the “shebang execution environment.” Each context acquires its PATH in a different way.

Examine the PATHs

Here is how you can see the value of PATH for each context:

# bash execution environment
echo “$PATH”
# Highlighting the above line and pressing CTRL-R…
# …will give something like:
/Applications/TextMate.app/Contents/SharedSupport/Support/bin/CocoaDialog.app/Contents/MacOS: /Users/djwonk/bin: /opt/local/bin: /opt/local/sbin: /usr/local/mysql/bin: /usr/local/bin: /Users/djwonk/bin: /opt/local/bin: /opt/local/sbin: /usr/local/mysql/bin: /usr/bin:/bin:/usr/sbin: /sbin: /usr/local/bin: /usr/X11/bin: /Applications/TextMate.app/Contents/SharedSupport/Support/bin

# shebang execution environment
#!/bin/sh
echo “$PATH”
# Highlighting the two above lines and pressing CTRL-R…
# …will give something like:
/usr/local/bin: /Users/djwonk/bin: /opt/local/bin: /opt/local/sbin: /usr/local/mysql/bin: /usr/bin: /bin: /usr/sbin: /sbin: /usr/local/bin: /usr/X11/bin

(Note: I added spaces between : and / purely for blog formatting. That way the lines wrap at sensible places. Your actual results won’t have these spaces, and you shouldn’t have any extra spaces in your PATHs.)

My bash execution environment was fine. However, my shebang execution environment was incorrect: /usr/local/bin was in front of /opt/local/bin.

The Solution

The solution for me was to create the ~/.MacOSX/environment.plist file with the desired path. In my case it was:

{ PATH = “/Users/djwonk/bin: /opt/local/bin: /opt/local/sbin: /usr/local/mysql/bin: /usr/bin: /bin:/usr/sbin: /sbin:/usr/local/bin: /usr/X11/bin”; }