Go MoGo Go!

So it seems fitting as its 40th birthday has just passed, that I've been playing with this ingenious little gadget for the last couple of days and have to admit: it is ingenious and it is little. However like so many profligates in these suddenly straitened times I found myself asking, "why lord, why?" ("Just because" no longer seems to be a satisfactory response.) So what follows is a post-hoc rationalisation, the economic collapse between its order and its delivery having taken everyone by surprise --- including all economists, masters themselves of explanation after the fact.

Setting it up was a breeze, even after a couple in the pub and on a laptop running Linux (although it was the very latest version of Ubuntu). The manufacturers must have been quite confident on this score, especially of punters' ability to deal with Bluetooth, because all the (short, illustrated) manual says is (paraphrased) "use your laptop's bluetooth manager to pair with it." However it worked first time for me so no complaints on this score.

(In the interest of full disclosure I do have a bit of experience with the wireless-connection-protocol-from-hell^H^H^H^HSweden but if you're a child with Bluetooth experience, or indeed a slightly inebriated engineer, you'll have no problem. Probably.)

The advantages over this laptop's former mouse (a wired, optical and equally small but not so sleeket beastie) are exactly two --- or exactly three, depending):

1. It doesn't seem to care about the surface you use it on; the older one required a mat (a dinner mat as it happens).
   
2. I can now actually use my laptop on my lap with the mouse on a table nearby without that tiresome cable business.
3. (Maybe.) If you had a really snug carrying case, and an aesthetic dislike of unsightly bulges caused by an external mouse, the drug-mule characteristics of this one would appeal to you. (Of course this is an elegant solution to the recharging problem as well but hey with a cable you wouldn't have that.)
   

On the downside I miss a scroll wheel: I seem to be able to scroll down but not up again, at least without making an exaggerated gesture. Perhaps this is just me, or the Linux device-driver. Also it's hard to hit the middle button without engaging the scrolling action, which is annoying.

Finally what's with the manual? In parts the language is really hokey: "Sync [...] with your laptop so you can go, man, go!" and "... that means you're ready to MoGo." (French people will be relieved to learn that these solecisms haven't made it past the language barrier; I imagine a French translator just saying "non.")

Irony

So I read that the uk.gov (as it was known in the old days of Janet when they did domain names backwards) has managed to lose the personal details of around 10,000 habitual offenders and all 84,000 prisoners in England and Wales. The data was on a USB key, unencrypted natch, and includes their names, addresses and dates of birth.

Am I the only one to imagine what would happen if some wannabee crim found it and used it as identity theft fodder. And whether there'd be a certain poetic justice in that?

"But what is it for?"

One of the symptoms of an approaching nervous breakdown is the belief that one's work is terribly important, wrote Bertrand Russell, and let's face it, he got through enough work to know a thing or two about the stuff.

Paradoxically however, the primary strategy most people employ to survive the three, four or five years of solitary enquiry which entails a Ph.D. in many parts of the world, is to maintain such a solipsistic belief. (We don't treat here with the vanishingly rare cases where a student's work actually is important, sub specie aeternitatis: this is a blog for cynics and luddites remember.)

How then is the poor student to stave off the nervous breakdown awaiting after their viva when it begins to dawn on them that the subject which has obsessed them for the greater part of their recent existence has no more importance in the greater scheme of things than, well almost anyone else's completed Ph.D. thesis? Why, a post-doc of course!

Post-doctoral research years are an ingenious invention of the academic community whose ostensible purpose is to separate relatively functioning members of the newly graduated doctoral cohort (those who's theses are actually worth further investigation, or, more frequently, those who wish to pursue careers in academia) from those greater numbers thinking, well, what the hell do I do now?

For the latter it plays an extremely valuable role as decompression period in which this cognitive dissonance can be resolved, allowing the freshly-minted dr to play with their shiny new title before putting it away in the back of a drawer where it belongs.

Those of you who have led more normal existences may like to use the analogy of those Sundays where you come down from two or three days' partying before the inevitable Monday-return to work.

Quote of the Day

This little gem from Keith Braithwaite:

"The only reason we'd bother to use map/reduce is because of its non–functional characteristics (as the properties of software that make it actually useful are called) [...]"

Keith is being polemical here (and, in fairness, as we Irish say, I've quoted him out of context). And as far as I can go with this he has a point. However his point stops at the place outlined by Josh Bloch in his excellent book Essential Java in which the lessons of functional programming in the small (the use of 'final'), i.e., thread-safe constant-objects which were not obvious before Java 1.2 (or is it 1.3) became apparent --- at least to me as a non-lisp-programmer. Thread-safety is evidently (tautologially) an emergent property of concurrency in the language.

Test-driven Development

Test-driven development (TDD) is commonly understood to connote the simultaneous construction of a test-suite with the system-under-test. This is "developer testing": the programmer writes unit-test classes in the same sitting as the classes being tested. Less commonly, a test is written before the class or method it's meant to test: in this case the test acts as the 'first client' of the tested code, helping the developer to explore the 'problem space'. This is test-driven design and I see such tests as analogous to the scaffolding which festoons buildings under construction, except of course they aren't thrown away when the construction is complete.

So far, so good and plenty of smart people have thought longer and harder than me on this topic. In the rest of this post I'd like to describe a unique (in my experience) application of TDD in which it worked out better than I'd imagined.

In an earlier existence I worked at an start-up which specialised (in those days) in building implementations of JSR-82, better known (if that's the mot juste, which I doubt) as the "Java APIs for Bluetooth Wireless Technology" (or JABWT possibly the Java world's first five-letter acronym and unpronounceable to boot). This was fairly exciting stuff: we were members of the expert group working on embedded Java on cool hardware... and we had a tab at the coffee shop around the corner!

In those days, Bluetooth hardware was expensive and one of the company's offerings was a simulator which allowed users to experiment with the APIs without having to buy any. Better still this simulator provided an implementation of the APIs which ran on standard Java so no messing around with on-device testing. In true TDD fashion, a spin-off from these simulated JABWT APIs was a comprehensive testsuite. This was very useful because JABWT is a deceptively complex specification: although it comprises only 21 classes and interfaces, a working implementation (i.e., one which passes the TCK) can easily run to a hundred concrete classes.

Back then, the Linux Bluetooth stack was in its infancy, there was a kernel implementation of the L2CAP protocol and a couple of user-space daemons to manage device hot-plugging (hcid) and service discovery (sdpd). The code for the latter had been donated to the community by Nokia but was no longer supported by them.

You're miles ahead of me.

What we did next was a skunk-works implementation of JSR-82 over this embryonic stack. How we did this was entirely test-driven: we would run our comprehensive testsuite over our implementation, see which tests failed and only implement enough to make the tests pass. Since this was a guerrilla activity, the latest test-reports always gave us a point at which to resume the implementation, when we found time from our 'real jobs'. Serendipitously our test-suite also indirectly tested a large part of the underlying Linux infrastructure and allowed us to feed bugfixes and missing features back into the community, and I ended up as the maintainer of the SDP subsystem for a year or so. A further benefit (this time to the company itself) was that it became much easier to build and test subsequent implementations of JABWT: since one half of the testsuite was typically run on Linux and the other on the embedded implementation, we could use Linux's low-level packet inspection (hcidump) to see what the other side was trying to do. Serendipity, financial benefit and bonus karma points all round.

Archaeology

When was the last time you used (or even saw) a floppy disk, in these days of the ubiquitous... err, what are they called? (You know: pen drives, usb keys, memory sticks --- I've heard all these terms but I want one sufficiently metonymic, i.e., as "hoover" is to the class of "vacuum cleaners".)

Anyway for me the answer to the first question is "last week". Although I have several machines at home, of various ages, only one (the oldest natch) is still capable of reading floppies and managed to read the disk in question successfully, to my great surprise as it was in a box which I hadn't opened since I returned from London, exactly 10 years ago today.

The disk contained a program written by three of us, I, J and K, to some version of Borland's C++ IDE and ran on Windows (versions 3.1 and 95). The original customer, which to our great surprise had been happily using the program for the last 10 years, wanted some new features added and could we help?

The last time I touched this program was to compile it on Windows 95 on a machine with a 133MHz Intel processor and 32MB of memory, a laptop which I'd bought second-hand for £800 (somewhere in Swiss Cottage as it happens).

God, I thought, I'll never get it to run now, where do I even start? The original compiler CD is lost, I don't even have Windows 95 any more...

Snapping suddenly out of my 1995-era malaise, I googled for "Borland C++" and found this wikipedia article. Someone actually had bothered to write down all of the releases of this product in a place where I could find it! An hour or so later, thanks to a bittorrent index, I had downloaded a version of the compiler which had managed to compile the code.

Now this program runs in a Windows XP virtual machine which is itself running on Linux on a 1.8GHz dual-core Intel processor laptop with 3GB of memory which I'd bought new for €500 (over the Internet as it happens).

We haven't found out what the new features they want are yet but it seems Windows XP is already out of date.

The absurdity of Web-2.0

So today I find myself writing a helper class for updating my online To-Do list via a popular micro-blogging site and calling it, quite accurately, ToodledooTweetBuilder.

Now I don't know about you but I am old enough to remember the original series of Star Trek where they had real computers, ones which fought wars with each other, you know with Blinkenlights? I certainly didn't expect to find myself dealing with user-interfaces looking like Fisher-Price(tm) toys or an episode of the Tellytubbies in my day-job.