I filled in the Durham University staff survey yesterday, which got me once again rather miffed about the way that postdoctoral positions work within this university, but also more generally. A good number of the questions were of the "can you do your work within normal working hours?", "do you have enough resources to do your job?", "do you feel stressed by work?" and so on. Answers: no, no, and yes. But while this "dialogue" is all very well in principle, there's nothing that can actually be done about these things: research positions are funded to do research in a particular area and if that's a lot of work for one person, tough. And if you don't manage to do it, also tough: no permanent position for you, matey. So hurrah for the new touchy-feely Durham University, but if they stump up University funds for the needed extra manpower to make my post a full success, I'll eat a hat of anyone's choosing.
...think again. Although I have been curiously quiet for the last month or so, it's all to do with the usual "swamped by work" excuse, rather than either death or lack of things to moan about. Plenty in the pipeline, just all going very slowly: that's the problem with attempting to parallelise your workload.
On the plus side, I went for a big MTB ride around darkest Northumberland on Saturday, which was knackering and awesome, then we got out for our first climbing in ages today at Brimham Rocks. At this rate, maybe the incipient belly can be staved off for a few more years!
Last week we received our wedding gifts delivery and put up a few pictures as mementos of the wedding and honeymoon (sorry Tom, your gift isn't up yet...). Particularly since I put up new kitchen shelves to accommodate the New Stuff and am basking in the associated masculinity of drilling and spirit-levelling, here are a few photos of no interest to anyone other than gift donors and the irrepressibly curious:
I've been using Python for maybe 4 or 5 years now. On the whole, the experience has been very positive: big pluses include the excellent (although rather stylistically disjoint) standard library; built-in collection types and list comprehensions; the experience, at least, of finding that duck typing actually "sort of works"; and the clean syntax. However, the "elegant" indentation-based scoping for which it's so famous is, all told, a very bad idea, regardless of what die hard Pythonistas may tell you.
Let's start with a consideration of syntax --- the most visceral feature of a language. Syntax is the most immediate feature of a language, and you know right from the start whether or not you like the feel of it. User interfaces appear secretly everywhere, from the symbols chosen to represent particular quantities in algebra to the syntactic sugar aspects of a programming language. Some experienced coders, especially those who know several languages well, may dismiss syntax-worrying as pointless and superficial, but I'm not so sure: a good syntax makes it not only fast to code up common tasks, but it will also emphasise the structure of an algorithm at a glance and be based on a few consistently applied core concepts. This is a lot more than lily gilding. Strictly, I can do anything in any Turing complete language, so the whole point of a good language is that it makes code for its target tasks readable, elegant and extensible: syntax plays a major role here. Python does well from this point of view: you can see right away that this is a language which doesn't render your own code unreadable when you go for a whole week without reading it. Contrast Lisp or Perl, or PHP: all serious languages suffering from serious syntactic defects (okay, so the most serious is the least heavily used... but that's got a lot to do with it having the worst syntax).
Ooh mama - I was just looking up some more info on Colemak, especially to see if my GB layout hack is useful, and found this amazing keyboard linked from this handy forum post. Wow! Every key face is dynamic, with little colour LCD screens under each one, so if/when you update your software keyboard layout, your hardware keyboard changes to match! At over $1500, I don't think anyone will be getting me one for Christmas, though... but maybe one of these would be almost as good :-)
Oh yes, in other news I got married, spent a lovely 3 weeks in western Canada with my new wife, and met a bear while out mountain biking near Jasper. But you didn't need to know that, right? Photos will be available once I've torn my hair out over EXIF alignment headers a bit more... I'll get on to that again when I get back from the parallel programming course that's taking up this week.
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!
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
10.4, etc. Here's a
configure.ac snippet which apparently solves the problem for projects using GNU
## 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
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.
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!
One characteristic of passing from being a novice programmer to being an experienced developer is learning to make
decisions based on the logic behind such 95% rules rather than sticking rigidly to the letter of the law just because.
It's a bit like in kung fu films --- the more styles you know, the better you're equipped to deal with difficult
situations! The main class of exceptions in this case is where your object is little more than a glorified data
container. If you're really sure that the current variables will forever be the relevant ones or, if not, that method
wrappers will do little to protect you from refactoring anyway, then there's little point in typing all those extra
lines and parentheses.
As of version 1.5, or "5" as the marketing people have it, Java has been equipped with covariant method return values.
Not a particularly obvious name, is it? What this means is that if a method of class
Base returns an instance of class
RetBase, then a derived class of
Base (let's call it
Derived) can implement a method with the same signature which
returns a derived class of
RetBase, rather than a
RetBase itself (let's call it
All very well, but does this solve any problems?