Steve Freeman and I are giving a presentation at QCon this Friday. In the schedule we're listed as presenting "Mock Roles, Not Objects", which we've presented several times before. This time we are going to focus more on how to use TDD with Mock Objects to guide the design of object oriented software. We call this "Listening to the Tests". Other people talk about "Test Smells". Taking the mixed metaphors to heart we've retitled our talk "Synaesthesia: Listening to Test Smells".

Recently I've been writing a system that performs reverse geocoding. It reads input from a GPS device over a serial cable and translates that to a human readable identifier of the user's current location. That sounds simple but my pair and I had a great deal of difficulty coming up with good terminology in our domain model. What should we call the type of values that the GPSReceiver object parses from the device's data stream?
Location? That wasn't right because we were converting GPS data into location information. Locations are named regions, such as rooms, buildings, post codes, wards boroughs, or towns, not points.
For a while we called them GPSCoordinates. But passing around single values of type GPSCoordinates read poorly. The mix of singular and plural didn't work. We considered LatLon, but not for very long: too ugly. We thought about Point, but that was too easy to confuse with 2D points. GeographicalPoint didn't seem right either.
Eventually we came up with the ideal name: Position.
And then we realised: GPS stands for Global Positioning System. If we hadn't been using an acronym in the name of the GPSReceiver class the correct name would have been obvious.
I usually try to avoid using acronyms and abbreviations as identifiers, except for really common ones such as URL, HTTP and GPS. But this has shown me that even the most common acronyms can befuddle my thinking about the application domain and software design.

The MoGo Mouse is an elegant, portable Bluetooth mouse that fits into a laptop's PC slot and charges its batteries while in there. I find it very useful when travelling with my laptop but the process of getting it connected to the Ubuntu desktop is not as smooth as it could be. Here's how.
First, find the Bluetooth address of the mouse with thehcitool command:
% hcitool scan
Scanning ...
AA:BB:CC:DD:EE:FF MoGo Mouse BT
Then tell the Linux HID daemon to connect to that Bluetooth device and use it as a mouse:
% sudo hidd --connect=AA:BB:CC:DD:EE:FF
If your GNOME Bluetooth setup is configured correctly you'll be asked to enter the mouse's PIN and then you'll be connected.
For convenience I've set up a GNOME application launcher to run the following command so that I don't have to connect the mouse from the terminal every time I want to use it:
gksu --message="Enter your password to authorise the connection to the MoGo mouse" \
"hidd --connect=AA:BB:CC:DD:EE:FF"
I've also created this icon for the launcher that you can download if you want to do the same.