Snow Leopard’s System Preferences loves to complain when you try to open older 32-Bit preference panes and will require you to restart in 32-bit mode to open them. One of the annoyances of running the MySQL on Snow Leopard is that even though they have an x86_64 package they still ship a 32-bit preference pane with it. The guys at Swoon got sick of this and have put out a 64-bit preference pane. Not an every-day annoyance but a small one that’s been fixed. Hopefully it’ll be rolled into the package released on mysql.com soon.
I’ve fallen in love with Java’s instanceof; it makes me feel a bit more at home when i’m away from my beloved Ruby. I recently ran into a situation where i needed to determine if an object implemented a specific interface and it turns out that instanceof is just the tool to do it.
Vector foo = new Vector();
boolean comparable = foo instanceof Comparable; // false, Vector doesn't implement Comparable
boolean serializable = foo instanceof Serializable; // true, Vector does implement Serializable |
I’ve recently been sucked back into the world of Java to work on a fairly agile-friendly project. We’ve got 2-day iterations going on and quite a lot of communication. Despite a severe lack of testing – which i’m working on – all seems well. But i’ve noticed a habit that bugs me a little. We’re meant to be passing this code off to some other teams and as such are trying our best to keep it clean and well javadoc’d for those that follow us. The problem i have with this is a simple little tag that Eclipse likes to throw in whenever you start a javadoc comment for a class; that tag is @author. I can’t stand the little bastard. We’re a team – we’ve all ripped at the guts of this code and if we’re anywhere near as agile as we aim to be then ownership of code shouldn’t matter. I’m aware this this auto-generated tag doesn’t really mean much but its mere existence irks me.
Oh, and if you’re wondering about the Tacate truck it is actually related. As the old coding parable says: “how many developers could be hit by the beer truck and the project still survive?”. Figured it’d be fitting since i was ranting about the topic of code ownership.
We switched to Git from Subversion on one of my projects at work because of some rather untimely downtime on our gforge server (for the record i hate that beast of an app and it’s pathetic attempts at UI design). I’d struggled with the transition to Git as i’d largely heard the “it’s distributed and solves world hunger!” arguments for the switch but when i looked around i saw everyone hosting on GitHub (which i love) as a centralized server much like you would with SVN and thus retreated into grumpy old man territory in which i shouted at this new-fangled version control system to get off my lawn.
It wasn’t until i read Josh Susser article on Agile git and the story branch pattern that some of the other advantages of Git really began to sink in. It’s truly a great little intro to the concept of story branches which clicked quite well with me. I’m now a happy Git convert and enjoying the freedom of slapping code at branches not having to worry about the inevitable pain of merging.
Wanting to have easy access to all the documentation for my installed gems i decided to setup a startup item for the gem server that comes with RubyGems.
Come to find out the process is incredibly simple. First create a shell script to star the server:
#!/bin/sh
/usr/bin/gem server --daemon
Then create a plist file describing the startup item:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">
<plist version="0.9">
<dict>
<key>Description</key>
<string>Ruby Gems Server</string>
<key>OrderPreference</key>
<string>Late</string>
<key>Provides</key>
<array>
<string>RDoc Server</string>
</array>
</dict>
</plist> |
Create a folder, i named mine GemServer, and name the shell script the same. Put the script and the plist into this directory and copy it to /Library/StartupItems (you may have to create this).
Or, you could just download the startup item and extract it to /Library/StartupItems.
Restart and point your browser to localhost:8808 and peruse your documentation ’til your heart’s content.
