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.

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.

Wow.

* "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

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 :)