XML: restraining the knee-jerk reflex

XML is a useful technology, sometimes: that's about as positive as I can be about it these days. While there was a period when I got quite excited about the idea of a standard syntax for, well, everything, time tempers such enthusiasm. See, 90% of the time, XML is just too damn cumbersome. When what you want to say is

Param1 = 3

or something of that complexity, then having to write

<param name="Param1" value="3"/>

is just a bit hefty.

Read more…

The God Delusion

I've recently finished reading Richard Dawkins' The God Delusion. I was pretty determined to not read it when it first came out since a) I object to specifically indulging in writing that I know I'll agree with --- I suspect that searching out compliant opinions leads to foam-mouthed Daily Mail reader behaviour and obstinate old man disease, and b) Herr Dawkins has been on a bit of an ego/PR trip in recent years, in an area which he's not really all that qualified to talk about. But then, as he points out in the book, it's not like religious "authorities" are really qualified to say anything meaningful about well... anything, so when Jo got a copy, I decided to steal it and finish it before her ;) On the whole, I have to say well done to Mr D. Okay, so the style is pretty rough --- much less honed than his sublime The Selfish Gene --- but I think that's a concious effort to come across as a nice and normal chap to all the Joe Faithfuls that he's hoping to convert. And he has done his homework --- lots of nice factoids and references, although one gets the impression that his library at home is entirely filled with books called "Why God Is A Big Fat Lie" and other, similarly subtle titles. (Incidentally, what a pity that aetheistic books tend to be as ravingly, lowest common denominator as their religious counterparts --- and even more of a pity that intelligent people like Dawkins and Christopher Hitchins don't try to buck the trend.)

Read more…

Bundling LaTeX for arXiv submission

I always have trouble submitting papers to the arXiv, on account of my tendancy to use a whole bunch of style files etc. that aren't in the standard arXiv collection. They aren't usually in my document source directory, either, but are spread around my system in various texmf trees. Accordingly, getting papers to upload is a pain (and if you try to upload just a PDF, arXiv detects that the PDF was made with TeX and refuses to accept it! Dang, foiled!)

So here's the method that seems to work for me.

  1. Get the snapshot package, and use it in your document with the usual \usepackage{snapshot} 2. Run latex etc. on your document until it's happy (note, I use pdflatex pretty much exclusively these days, but arXiv will use good o' DVI-producing latex, so that's what you need to use when producing your submission) 3. If your document was called mydoc.tex, you will now have a dependencies file, mydoc.dep. This can be used to bundle your source files for submission. To do this, get bundledoc. 4. Run bundledoc on the deps file --- you may need to provide an explicit config file. Here's my command: bundledoc --config=$HOME/local/texmf/tex/latex/bundledoc/tetex.cfg mydoc.dep 5. You now have a tarball or zip archive, depending on whether you used the TeTeX/TeX Live or MikTeX config file. This should be okay for uploading to arXiv. Happy bundling.

Python indentation revisited

Amazingly, the article on Python indentation I bashed out a year ago at the Manchester parallel programming workshop has become the most popular thing on this website. Even more than all the lovely night climbing stuff: it seems the 'net is an even stranger place than I thought! It's also been nice to have the occasional bit of fan mail about the article (and a "you're wrong" mail, which is fine, except that it really missed the point and got into a fight with the tabs-vs-spaces straw man).

Read more…

Monte Bianco

Alors... another long time since posting but content yourselves with the knowledge that I've mostly been busy but not in the sort of way that I feel compelled to tell y'all about. Nyah.

Anyway, I recently had a "working" holiday masquerading as a Times photographer for Tom Whipple's recent article about Mont Blanc. A good wheeze --- I jetted to Geneva with (Hardcore) Dave Williams, met Tom and Al Young and then proceeded to spend the next few days running ourselves ragged getting a bit of practice and acclimatisation: with an intention to get up Mt Blanc by the end of the week we only had 4 days for preparation! We got rained off the Chapelle de la Gliere just as it was getting interesting, but the weather behaved itself on the second day and we had a perfect day on the Aig de la Perseverance that at least convinced me that months of no climbing hasn't hurt my ability to swing around on alpine V multipitches too much. So far so good.

Read more…

Environment variables considered harmful

High energy physics software (and, for all I know, academic software in other disciplines) is plagued by an obsession on using the system environment to define configuration aspects. This obsession has been applied to package dependencies, package behaviour and a host of other features, and is exceedingly misguided, being based on the simplicity of writing code to read in a configuration from the shell environment rather than using a configuration file.

Read more…

Mantras for software engineers

Mantras for software engineers

There are certain aspects of software engineering that are so close to being fundamental truths that all developers should have to repeat them to themselves 10 times per day and twice on Mondays. They are independent of language, operating system and whatever editor or syntax highlighting scheme you hold sacred. If you keep these in mind, at least the worst errors are less likely to come up and bite you in the bum when you aren't expecting it. Here's an attempt to write some of them down: since I'm a very fallible person this list is bound to be incomplete and (horror!) possibly even misguided. Let me know.

  1. Don't make one entity try to do more than one thing. This is so important, and so often ignored that it defies belief. Objects can do many things, but their components should only do one thing. The best historical example I can think of is that of old-school stack push-pop operations (which were firmly engrained in programmers' and computer scientists' conciousnesses) meeting the new world of threads and exceptions: it was eventually noted that pop could never be an exception-safe operation specifically because it reads and modifies the stack at the same time. Modern implementations of pop tend not to return the top of the stack they only throw it away am aesthetically nice solution is the explicit addition of a "peek" function. The moral lesson: atomicity is good. This example also has the nice feature that is shows how working with legacy code and engrained ideas can tie you into a world of pain, which can be fixed by taking a step back and thinking about how things can be simplified. 2. Keep it simple (stupid). Just because you can overload operators doesn't mean you should. Just because you could do the whole thing with one regular expression doesn't mean you should. Just because you could do it in Perl doesn't mean you should :-) In short, you or someone else will one day have to come back and re-hack code you wrote in the distant past: don't make them reverse engineer your cool tricks when "wasting" another carriage return would have made it clear as crystal. Good developers know when not to be clever. 3. Introduce version tags early With successful projects, you may end up with several versions of your library / file format / whatever "in the wild" at one time. If you didn't provide a versioning tag with your first release version, you are then in the nasty position of having to determine which version a given instance is by the absence of such a tag. Yuck. This makes handling "schema evolution" and related topics much harder and a great dela messier. So think about version tagging right at the start... otherwise you'll end up wishing you had access to a time machine (and that's an even harder problem!) 4. Comment your code Do I even have to elaborate? Okay, one elaboration: comment your code for use by an automated documentation system like Doxygen, epydoc, pydoc, JavaDoc...
  2. Modularise agressively... ... but not too agressively! It all gets very Zen when you think about it: the key to success in most endeavours runs along the lines of "strong but supple". A series of near contradictions, whose solution is the thin line between success and failure. Well, that's rather pessimistic the line isn't that narrow and there are always shades of grey confusing the neat black and white picture but you get the idea. Provide a function if you can use functionality intwo places in your code. Provide a new module/package if you have substantial functionality that can be used outside your project. 6. Hide complexity behind interfaces Operate a "need to know principle". Interfaces are the key to this: a developer should need to know what to put in, what comes out and maybe some commentary on efficiency and alternative approaches. They shouldn't need to know how in detail your code achieves its specification.
  3. Before you start, see if someone else has already done it Yes, I know your idea is so brilliant that it would take one person in a million to come up with it. There are millions of technical people, there is the birthday theorem (telling you that collisions occur with roughly the square root of the single event probability, so that one- in-a-million really becomes one-in-a-thousand). Chances are someone else has already made a start. Help them or use their work rather than learn their lessons twice.


I was pointed at this interview with maths/compsci/typesetting guru Don Knuth this morning. Apart from clearly being a magician in the Feynman sense*, it's wonderfully inspiring to see someone so at ease with the world and his place in it that he can say this:

Andrew: In late 2006, you were diagnosed with prostate cancer. How is your health today?

Donald: Naturally, the cancer will be a serious concern. I have superb doctors. At the moment I feel as healthy as ever, modulo being 70 years old. Words flow freely as I write TAOCP and as I write the literate programs that precede drafts of TAOCP. I wake up in the morning with ideas that please me, and some of those ideas actually please me also later in the day when Ive entered them into my computer.

On the other hand, I willingly put myself in Gods hands with respect to how much more I'll be able to do before cancer or heart disease or senility or whatever strikes. If I should unexpectedly die tomorrow, I'll have no reason to complain, because my life has been incredibly blessed.


* "There are two kinds of geniuses: the 'ordinary' and the 'magicians'. An ordinary genius is a fellow whom you and I would be just as good as, if we were only many times better. There is no mystery as to how his mind works. Once we understand what they've done, we feel certain that we, too, could have done it. It is different with the magicians. Even after we understand what they have done it is completely dark. Richard Feynman is a magician of the highest calibre." --- Mark Kac

Bose Companion 3 computer speakers

Last week I finally decided to waste some money and upgrade my computer speakers from the acceptable-but-a-wee-bit- harsh-and-tinny 50 Creative Gigaworks T20 pair that I've been using for about 9 months to a set of Bose Companion 3's.

The online reviews for the Creative Gigaworks speakers were just too good for me to ignore 9 months ago... and I think there's something to the advice that computer speakers with subwoofers will be boomy and unsubtle --- good for games maybe, but rubbish for music and wannabe-audiophile ears (like mine, ha!) But the moment I got them out of the box (mm, nice build quality) and plugged in (hmm, bit tinny...) I knew it wasn't quite right. Next time I'd just pay stupid money and get the Boses.

And so it has come to pass, and blimey they're brilliant. They are expensive, as any hi-fi nerd worth their salt will tell you, and yes I could probably have got the same sound for less by piecing together an amplifier from one manufacturer, floorstander speakers from another, and cabling from a third. But it doesn't matter, because these are tiny, come in one box, look and feel brilliant and sound outstanding. Convenience and aesthetics are worth spending money on, sometimes, and I didn't see anyone else selling speakers which produce sound of this quality from such tiny units.

Well, I nearly did. The Acoustic Energy Aegos were a serious contender and at a bit over half the price they certainly beat Bose on economic grounds. But life ain't so simple: the Boses are prettier, and they come with a beautifully designed little remote unit with a soft rubber volume control, touch-sensitive on/off panel and discrete headphone/input jack sockets. The AEs force you to rummage under the desk for the subwoofer to control the volume or plug your headphones in --- so I seem to have reached the point in my life where I'm prepared to pay 80 not to have to bend over. Life's funny, isn't it?

Anyway, my point is: if you listen to a lot of music through your computer speakers, and space and nice design are important things, then the Bose Companion speakers are fantastic little life-enhancing devices. Yes, you can do the same thing cheaper, for which the audio geek comments here may be useful, but you'll have to shop around a lot to find anything that does it with half as much style. IMO :)