The Goldfish Chronicles

I added a few more bits to my dumb OS X scripts:

function jvm() {
  if [ -z "$JAVA_HOME" ]
  then
    echo "No JAVA_HOME set, setting to default"
    export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/
    PATH=$JAVA_HOME/bin:$PATH
  elif [ $# -eq 0 ]
  then
    echo $JAVA_HOME | sed 's/.*Versions///' | sed 's//Home.*//'
  else
    if [ -d  /System/Library/Frameworks/JavaVM.framework/Versions/$1 ]
    then
        export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/$1/Home/
        PATH=$JAVA_HOME/bin:$PATH
    else
        echo "No such JVM: $1"
    fi
  fi
}

function jvms() {
    ls -1 /System/Library/Frameworks/JavaVM.framework/Versions/ | grep '^[0-9]'
}

Typing just ‘jvm’ will output the currently chosen jvm, unless there is not a default in which case it will set your JAVA_HOME to the CurrentJDK link in OS X.

This is all unnecessary though, browsing around I found David Blevins’ setjdk script which has the added enchantment of tab-lookahead. This can be found at http://docs.codehaus.org/display/ninja/setjdk.

I’m sure it’s going to hit issues somewhere, and such probably already exist, but the following seemed worth sharing for switching Java version on a Mac.

function jvm() {
    if [ -d  /System/Library/Frameworks/JavaVM.framework/Versions/$1 ]
    then
        export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/$1/Home/
        PATH=$JAVA_HOME/bin:$PATH
    else
        echo "No such JVM: $1"
    fi
}

function jvms() {
    ls -1 /System/Library/Frameworks/JavaVM.framework/Versions/ | grep '^[0-9]'
}

Usage is:

cuckoo:hen$ jvms
1.3
1.3.1
1.4
1.4.2
1.5
1.5.0
cuckoo:hen$ jvm 1.5.0
cuckoo:hen$

Copied from an email to the ASF infra mailing list

Putting an email on the infra list to provide an update (from a
spectator’s point of view) on today’s issues.

Minotaur, which is chiefly handling the SVN repository, Apache project
sites, people.apache.org sites and login@apache.org email addresses
had a kernel panic and was acting up after the reboot (errors on
commands that should not have errored).

Things were taken down for a memtest run and the static websites (not
the dynamic tcl.apache or perl.apache) were failed over to Ajax
(failover machine in Europe). The memtest passed, and the subversion
repositories are being checked for validity while also making sure
that an up to date backup of the svn repositories is made.

Minotaur is slowly being brought back online. Sometime tonight
read-only SVN will be re-enabled; and presuming things go well I
imagine read-write and unix accounts will be turned back on. Medium
term, SVN will be moved to one of the machines that Infra have
recently been getting ready.

About a week ago I bought a speaker setup for our iPods. After a little bit of Amazon research, I chose the Klipsch iGroove (which has in the week since dropped $50 in price). We’re very impressed with it, and Nathan loves having music on. At $199.99, I heartily recommend getting these to turn you iPod into an agile home stereo.

Note: Notice the word home. These are the type of speakers that you can easily move around the house, but you’re not going to be popping them in your luggage. For that kind of thing you need the crapper, cheaper models.

A week or so ago I installed JProfiler along with open-source usage license (sent them an email asking if such was available after hearing that Matt Raible had done the same). The aim was to use it on a bit of Commons Lang performance testing, but I ended up doing that by hand. Instead the first usage was to investigate the performance of Commons CSV (in the Sandbox).

As always, it performed admirably, but there was one rather painful teething problem. At first nothing worked, no matter what happened I just couldn’t drill down into the source code. Eventually I realised that by default JProfiler lists ‘org.apache’ on its global ignore filter, because usually such a package is not the code being worked on.

So….JProfiler rocks, but remember to modify the global filter if it’s for Apache code.

This is something I wrote on the 27th March 2005. No idea why - some commentary that must have been spinning around in my head.

Much of the strength of a community is built upon the subtle agreement to ignore the cracks in the foundation stones.

One of the foundation stones of the Apache community is that the community develops the software, instead of one or two inspired hackers. This is the major difference between Apache and Codehaus for example, Codehaus focuses on the existence of these icons of inspiration, declaring them a project’s despots. However, for Apache the only sign of despotism is in the oversight funnel that leads from the committers, through the chair, to the board, and on to the legal heart of the community, the members.

The issue with this community-developed software view is that in many places it’s not backed up by reality, most of the codebases are coupled directly to their inspired hackers, and while the community are aware of issues, inspiration (aka merit/doing) is often a leader in what the community is seeing.

So it is easy to see why this concept of community-developed software can be a bit hard to swallow; much of the time it’s not a piece of committee-development, but a piece of focused work - probably better quality most of the time, given the pain of committees.

Despite this reality, of inspired hacker/despots, there is a very strong mantra that the code is developed by the community and a general blindness to admit the despot reality. This seems odd, but it’s an issue of perception which lies at the heart of the ASF way of doing things. “The community is more important than the coder”.

In a despot-driven project, it is always obvious that the inspired hacker is the core of the project, if they should dry up then chances are the project will dry up. Few have the brazen guts to dive in and wrest a dying project from its despots hands.

In a community-perceived project, the whole community is the core of the project and even when the inspired hacker vanishes, the mental ownership of the project spans more than that one absence and there is far greater chance that somebody will feel empowered to step in and fix things, or make a new release.

So the difference is not the existence of despots, but the focus on their importance. The “community” mantras are an attempt to encourage the users to step up and take the despot role when previous despots have moved on. Unfortunately the pain of getting commit access works against the community mantra, the community may be more important, but they’re not allowed to commit.

Sometimes you have to remind youself that the fun things are the reason for opening your eyelids in the morning, not the obligations. For the last couple of weeks I’ve spent a little of each evening fixing bugs in Commons Lang. Maybe it’s an odd definition of fun - but it gives me short bursts of code flow and when taken as a collective it adds up to a release. Fifteen bugs to go.

Once that’s released, and a quick 3.0 with deprecated methods deleted also released, maybe I can try to stay on top of such things so it doesn’t end up with a year or two’s worth of bugs accumulated.

Carrie had an email bounce back from her mom, seems insightbb (local ISP come cable monopoly in KY) were blocking our email server. Digging into it, it seems it’s an AT&T blacklist and Insight just sit on top of it. Arse, thinks I, blacklisted.

Digging further. Turns out that AT&T consider forwarding of spam to be spam. So if you are a mail forwarding service (which is what we do for a few parental email addresses), you can’t simply forward said email on to the real destination - instead you have to be running spam filters and doing most of the ISPs work for them (here’s their policy).

Irritating.

So how do people manage their OpenPGP (specifically GPG) keys? For the last year or more I’ve avoided releasing things at Apache due to a general confusion at just how to manage my keys. There’s nothing available at Apache to do so, so you have to come up with something locally. Putting it on another server seems insecure, but client-wise I’m never that stable. Currently I’m on a work laptop, so probably not something to get too attached to in the long-term.

My current solution is to use a usb key and symlink my .gnupg directory over to that as I’ve not seen anything in the gpg command help to let me spcify where the keys live. This worked fine for signing, but I just realised that it means that I have to have the usb key in to verify keys - ie: it needs to find my list of public keys and those are in the .gnupg directory too. This sucks. Any ideas on how to better manage this out there?

One downside of the usb key approach is that it gets automounted in a way that gpg doesn’t like. The files are world readable, and lock() isn’t supported. So lots of errors. This is on a mac, so in the long-term I’d have to look into understanding how to configure its automounting.

I’ve got a little tool called ReportRunner that is currently rather tricky to use - as you have to grab the jar, create the configuration files and get the exploded webapp; ie) lots of jsp and javascript etc.

I’m not too concerned with the config; but does anyone have any thoughts on how better to do the small web wizard? I’d like it to be in the jar if possible - currently I’m slowly migrating the jsp to velocity - but other ideas would be welcomed.