July 2007 Archives
In the interests of RSI-avoidance and just interest itself, I’ve finally made a move to ditch my QWERTY (i.e. “normal”) keyboard layout. As Jared Diamond and others like to point out, QWERTY is an anti-engineered layout which became popular and obsolete at the same time. QWERTY typists have to work hard for no reason, risking RSI. Since I sometimes get typing-related wrist pain, a switch seems sensible.
I initially planned to switch to Dvorak, the most popular alternative layout, but a recent discovery of the Colemak layout, which is more computer shortcut-friendly, means that that has become my target layout. So far, so good: I’ve installed the X server keymap, adapted it a bit for my GB keyboard and moved the keys on my laptop. While it’s painfully slow at the moment, I can already feel how much more efficient than QWERTY it is. It’s bound to be a bit of a journey, so I’ll post any interesting developments or experiences here. When my typing is back at more than 5 w.p.m., that is!
Posted by Andy Buckley on Jul 08, 2007
Apparently, building C++ code against C or Fortran on OS X introduces an unexpected error of duplicate symbol declarations. “Apparently”, because I don’t have a Mac of my own anymore — I’m relying on others’ reports here. What seems to happen is that forward-declaring a non-C++ symbol using the extern keyword actually creates a fully-fledged symbol, and then the linker goes mental when it finds the “duplicate” definition — i.e. the real one.
It seems that the MACOSX_DEPLOYMENT_TARGET environment variable can fix this if set to the appropriate OS X version number: 10.3, 10.4, etc. Here’s a configure.ac snippet which apparently solves the problem for projects using GNU autotools:
## OS X
AC_CHECK_TOOL(SWVERS, sw_vers)
if test x$SWVERS != x; then
MACOSX_DEPLOYMENT_TARGET=`$SWVERS -productVersion | cut -f 1,2 -d.`
AC_MSG_NOTICE([MACOSX_DEPLOYMENT_TARGET = $MACOSX_DEPLOYMENT_TARGET])
fi
Posted by Andy Buckley on Jul 08, 2007
My sincerest apologies to the bunch of idiots driving gas canisters and burning cars around the UK at the moment — if this is meant to either inflict any real damage or have me quaking in my boots it really isn’t working. Grow up, please.
On the other hand, if the idea was to give airport security guards more reasons to confiscate my nail scissors, bottled water and armpit spray as suspected WMDs, its been a great success. Chances are if all Brits abroad from this point on have no access to deodorant, we’ll be an international pariah before too long.
I’m so glad this has happened just in time for our honeymoon… travelling to and from Canada via a succession of foam-mouthed airport staff is bound to be a delight.
Posted by Andy Buckley on Jul 04, 2007
It’s an oft-recited design principle when building object-oriented software that you should always protect a class’ data members by making them private and only accessing them via public ”get” and ”set” methods. The mechanism by which this is achieved varies according to the language, but the idea is the same: if you access your data via methods rather than directly, then you have a lot more flexibility for refactoring later, without breaking your class interface. A less appreciated fact is, that as for pretty much every simple rule, there are a plethora of quite reasonable exceptions. In this article I’ll focus on one such exception — how maintaining object relationships with the Java Hibernate persistency framework is best done by directly accessing data fields and keeping them private!
Continue Reading…
Posted by Andy Buckley on Jul 04, 2007
