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.
Friday, July 18, 2008
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.
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.
Wednesday, July 2, 2008
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.
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.
Subscribe to:
Posts (Atom)