What's it all about, Alfie?

One of the things that I've really missed in the latest version of Mac OS X is the utility to set the default version of the JDK to use. Well, with all the clojure coding I've been doing, I have typically stuck to JDK 1.7, but recently, the auto-updater from Oracle has them shipping JDK 1.8. Yet this doesn't effect the command-line utilities. This is a pain in the neck.

So first, I got JDK 1.7.0_75 on all my machines - it's going to be the last version of JDK 1.7 that I'll get as it's off the auto-updater. Then I was sure that everything was OK, I also got the complete JDK 1.8.0_40 - which is what the auto-updater downloaded for the JRE, but not the JDK. Yes, annoying.

At that point, I started googling about what to do. Turns out, JAVA_HOME is all I need to worry about. The java, jar, java apps in /usr/bin are all respectful of JAVA_HOME. Then I found this function that I added to my ~/.bashrc:

#
# Clever trick to leverage the /usr/bin/java commands to take advantage
# of the JAVA_HOME environment variable and the /usr/libexec/java_home
# executable to change the JDK on-the-fly. This is so easy I'm amazed.
#
function removeFromPath() {
    export PATH=$(echo $PATH | sed -E -e "s;:$1;;" -e "s;$1:?;;")
}
 
function setjdk() {
    if [ $# -ne 0 ]; then
        removeFromPath '/System/Library/Frameworks/JavaVM.framework/Home/bin'
        if [ -n "${JAVA_HOME+x}" ]; then
            removeFromPath $JAVA_HOME
        fi
        export JAVA_HOME=`/usr/libexec/java_home -v $@`
#        export PATH=$JAVA_HOME/bin:$PATH
    fi
}
setjdk 1.7

At this point, I saw that the key command was /usr/libexec/java_home, and it had all the answeres I needed. I didn't need to update my PATH - just JAVA_HOME. I also could verify that I had all the versions of Java I needed:

  $ /usr/libexec/java_home -V
Matching Java Virtual Machines (7):
  1.8.0_40, x86_64:  "Java SE 8"  /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/
                                   Contents/Home
  1.7.0_75, x86_64:  "Java SE 7"  /Library/Java/JavaVirtualMachines/jdk1.7.0_75.jdk/
                                   Contents/Home
  1.7.0_51, x86_64:  "Java SE 7"  /Library/Java/JavaVirtualMachines/jdk1.7.0_51.jdk/
                                   Contents/Home
  1.7.0_45, x86_64:  "Java SE 7"  /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/
                                   Contents/Home
  1.7.0_13, x86_64:  "Java SE 7"  /Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk/
                                   Contents/Home
  1.6.0_65-b14-466.1, x86_64: "Java SE 6"  /System/Library/Java/JavaVirtualMachines/
                                            1.6.0.jdk/Contents/Home
  1.6.0_65-b14-466.1, i386:   "Java SE 6"  /System/Library/Java/JavaVirtualMachines/
                                            1.6.0.jdk/Contents/Home

And then with a simple command - in the shell of my choice - I can set - and reset the JDK I use. It's very click:

  $ setjdk 1.7
  $ javac -version
  javac 1.7.0_75
  $ setjdk 1.8
  $ javac -version
  javac 1.8.0_40

Everything else works like a charm. This is a handy little tool to have, and I'm sure I'm going to use it often as I migrate from JDK 1.7 to 1.8.

I've often said that Command and Control is a valid, useful, form of management. So is Consensus. Now the latter is a lot harder to achieve because you have to have very self-aware people in the organization. They have to be aware of their limitations, and know when it's best for the group for them to stop back, and to step up. Yet it is, without doubt, the most effective team.

But a lot can get done with Command and Control - as long as everyone does their part. The commanders have to assume responsibility for their commands, and they have to be available to make those decisions at any time - based on the needs of their subordinates to have issues resolved. After all, it's no good to have a great commander if he's never available to make the command decisions.

I've been thinking a lot about management lately, and I'd like to think I've made enough mistakes to know that I work pretty well in either form, but I think everyone works better in the consensus format - assuming they have the right teammates. After all - a good team doesn't have to be staffed will all-stars, it just has to be staffed with the right people, and then set the expectations accordingly.

What I have seen fail over and over is the organization that claims to be Consensus - but is, in fact, Command and Control. They want to appear that they trust the workers, that they have hired the right mix of people, but in the end, they really don't trust them because either they know the people aren't right (but are possibly hoping they will become the right people), or they just don't trust others.

This latter truth is really what I've seen more of than anything else - mistrust. A very smart guy - capable of being an amazing individual contributor gets promoted out of that spot, into a place where they are no longer outstanding. It's the Peter Principle all the time:

managers rise to the level of their incompetence

It's so true it almost makes me sad, reading the Wikipedia page. I can see in so many people that they have really risen out of the position where they were outstanding into a job that they really are very marginal at. They might have thought they could do it, or could learn to do it, or would get better at it, but in the end, their realization that they really are no good at their job is something that creates a great deal of friction for them - internally.

Unhappy people aren't necessarily the first to see it in themselves. They get irritable, cranky, intolerant, micromanaging - all things that the wouldn't normally want to be doing, but their current mental state is being heavily influenced by the fact that they are mad at themselves for taking this job over staying where they were and feeling a lot of job satisfaction out of doing something really well.

I don't think there's any real solution to this problem. The wikipedia page gives a few suggestions, but they are all virtually impossible to implement as human beings are involved, and the willingness to admit defeat is not something most people want to admit to. So we suffer through. Adults aren't going to change their beliefs and habits without a significant Life-Altering Event - and there's no way to predict those - nor would I want to inflict one on anyone. But that's what it'll take for these folks to re-asses the way they work.

Sadly, it's just considered normal.

I've got a few projects on Bitbucket, and while it's nice to have an alternative to GitHub's policy on private repos, the Markdown rendering on Bitbucket is really sad. The problem is simple: If I have a repo with images in it, and I want to include them in the README.md, then for GitHub I need to include something like:

  <center>
    <img src="docs/img/logo.png" width="450" height="200"
    border="0"/>
  </center>

and it'll work - but including the HTML, as per the Markdown standard, on Bitbucket is not allowed. They have written that they don't allow any HTML in their Markdown due to safety reasons. But then why does GitHub? Is it just because Bitbucket isn't using as good a parser?

In addition to the lack of HTML, the relative links in the Markdown aren't supported, either. This means that in order to include an image in the README.md, I have to do something like:

  ![Using the correct G-REPL URL](https://bitbucket.org/applieddl/
    pocket/raw/master/doc/img/grepl-url.png)

this means that the links don't work in local preview mode, and a lot of folks have been asking for more than a year, to have this fixed. Their answers have ranged from "It's a feature", to "It's on the list, with no ETA". Clearly, the company isn't listening to it's users. That's sad.

For Bitbucket, the issue seems to be revenue. They don't seem to feel the need to fix this serious documentation issue, and it can't be all that hard if GitHub has had it from the beginning. The people on the ticket have even quoted (and linked) the Markdown spec as well as how GitHub is doing this - and nothing has changed.

I can appreciate that this is their choice. Mine is to use it only if I have to, and realize that their idea of support is "No, thanks", and accept what is, over any hopes of what might be.

I had to update my work MacBook Pro, and I got the dreaded "login" Keychain problem because I guess the tools they created/used to update my local password were not up to snuff, and now that I've created a new KeyChain, I've also found that they have just horribly managed this laptop to the point that I'm surprised that it works at all.

It's this kind of lame administration that really makes me upset. They bought this bill of goods from some enterprisey shop about how to "Easily" and "Securely" administer their laptops, and rather than just teach people, or make it clear what to do, and not do, they have this crap with no way to remove it for those of us that simply don't need it.

It's frustrating. Yet in the end, I have to follow the advice I gave a friend just this morning... take it easy, this is just another indicator that this is not the place you really want to work. Simple.