2003-02-15»
more details on the jhai pc»
For those of you who’ve seen the pictures of the Jhai PC in Laos, and read the note that said that the hardware wasn’t working on the launch date, here’s the full skinny, quoted from the mailout the Jhai people sent out this week:
Jhai Remote Village IT System Launch Delayed
At 4:30 a.m., Tuesday, 11 February, 2003, in Vientiane, Lao PDR, Jhai Foundation concluded here that the scheduled launch date could not be met.
The Problem
The original design was modified three weeks before launch to include a flashdisk (a data storage device that has no moving parts) at the village computer in Phon Kham. To include the flashdisk required a PCMCIA card. This was a solution developed in order to provide space for the size of the localized KDE, the Linux-based productivity suite, and related software so that the software more closely matched the hardware’s ability to do the job the villagers wanted it to do. To integrate this device and this card into the system will take more time due to a variety of issues. The manufacturers are cooperating with the Jhai team on this effort, but the time required for integration is substantial.
This night the data on two hard drives needed for development were corrupted. And a Jhai PC was rendered inoperable. Although data and programs were saved on CDs, the time lost due to this accident makes it impossible to meet our deadline.
“From our team’s perspective,” says Jhai chairman, Lee Thorn, “the design of the Jhai PC and communication system is more than sound – it remains the best solution we know to meet the needs of the villagers in the Hin Heup district and perhaps to meet the needs of many poor rural people worldwide.
The problem is not the design.
The problem is a combination of factors – money constraints, constraints on volunteers’ time, and my insistence on a deadline that turned out to be too optimistic. The responsibility for this delay is mine. I regret any inconvenience my decision has caused others. Any loss of face is my loss and should not be imposed on other members of our team.
Seeking Counsel From The Community
“We will be going to the villages today to seek their counsel on how to proceed from here. We hope to solve our problems before the rainy season begins in mid-April. This is a hope, not a prediction. However, we will not announce a launch date until more information is in hand.
“Jhai Foundation is about reconciliation and this is a reconciliation project of the Jhai Foundation. What is most important to us are our human relationships. We will remain true to our values and true to our friends here in Laos and elsewhere. As my fellow veteran, Kurt Vonnegut, once said, ‘The thing is to be honorable.’ We will continue to be honorable and we will continue to seek reconciliation of whole – and flawed – people with one another. The opposite of this is war and we will not go down that road. We will do this thing together. It will simply take more time.”
Lee Thorn, chairman of Jhai Foundation
Comments Off on more details on the jhai pc
2003-02-13»
whoops.»
My RSS feed is eating up bandwidth, so I’ve implemented a “If-None-Match”/”Etags” caching doobry. Let me know if anything breaks. Not that you’ll be reading this if it does.
Comments Off on whoops.
2003-02-10»
joke that, amazingly, no online tourist guide has used (yet)»
The Ten Minute Haight.
Comments Off on joke that, amazingly, no online tourist guide has used (yet)
once more, with vim»
A class browser (of sorts) in vim. I love vim, but only in a false-consciousness kind of way.
Comments Off on once more, with vim
2003-02-07»
another idol falls»
The Guardian said he coded it, and the truth is only slightly less shocking. Whitfield Diffie’s code was the inspiration behind Powerpoint. Is nothing sacred?
Diffie has long gray hair and likes to wear English suits. Today, he works for Sun Microsystems, as an internal consultant on encryption matters. I recently had lunch with him in Palo Alto, and for the first time he publicly acknowledged his presence at the birth of PowerPoint. It was an odd piece of news: as if Lenin had invented the stapler. Yes, he said, PowerPoint was “based on” his work at B.N.R. This is not of great consequence to Diffie, whose reputation in his own field is so high that he is one of the few computer scientists to receive erotically charged fan mail. He said he was “mildly miffed” to have made no money from the PowerPoint connection, but he has no interest in beginning a feud with an old friend. “Bob was the one who had the vision to understand how important it was to the world,” he said. “And I didn’t.”
As if Lenin had invented the stapler? As if Lenin had invented Standard Oil more like.
(Thanks, Matt. Yeah, thanks a lot).
Comments Off on another idol falls
xml would be a lot cooler if it were pronounced “zimmel”»
The House That Jack Build, in RDF.
Comments Off on xml would be a lot cooler if it were pronounced “zimmel”
2003-02-06»
three hours later…»
Here’s an ASCII copy of the EU draft constitution, as requested (thanks, Dan!)
(I guess it wasn’t scanned in after all.)
Comments Off on three hours later…
the united states of plaintext»
You’d think that with something as important as the draft of the forthcoming EU Constitution, they’d stick it into something more readable than a scanned- in PDF. Anyone got an ASCII version?
Comments Off on the united states of plaintext
blog zero»
Ben links to an Dear Raed, an Iraqi blog from Baghdad. Utterly fascinating, from its examination of the latest Saddam gossip (“Saddam is still meeting officers daily, and we have the pleasure of watching these meetings three times every day. Each batch he meets leaves the place with a 1.5million Iraqi Dinars check and a brand new car. The latest cars to be put in the warehouses I pass by are Toyota Corollas, all white. The warehouse has around 150 of them”) to bitchy responses to pro-war Americans (“Well you pooped on me buddy, don’t expect me to be all ah-great-america-we-love-you, and your government will be pooping on me some more, now how does that make me feel?”). Not to mention the Neuromancerish psy-ops that caught Ben’s eye.
Comments Off on blog zero
testiness»
Rafe asks about blogger’s test-driven development experiences. I’ve been messing around with XP on-and-off for the last month or two. Yoz and I are doing some long-distance pair programming via TightVNC, Leo, and Yahoo Messenger Voice Chat, which has been slow-going but fun. I haven’t used XP or unit-testing for large projects, but I’ve been thinking a lot about my experiences.
Unit testing is definitely the easiest part of XP to grasp, but the XPers have a point when they say that much of the benefit of writing tests before you code comes from synergies from XP’s other practices. One of the reasons why most of us don’t write as many tests as we should is because of the limited returns. You spend a long time writing little fragments of code, which only come into their own if a bad bug trips them up in a predictable way. Anyone who has got caught in the trap of writing test code to catch bugs, only to find themselves fixing bugs in the test code, knows that tests can be a real drag on the flow of programming.
Unit testing before you code ups that return on investment. Firstly, while you’re writing the test code, you’re also mentally fleshing out the interface and algorithms of the future class itself. Many times now, I’ve found myself wrestling – and solving – some of the biggest algorithmic problems I have to face in writing a method while I’m writing the early test code. This has a couple of effects: psychologically, coding up the tests seems much less of a waste of time. It feels like a useful warm-up to the final work, rather than a finickety post-facto dredge over your previous work.
More practically, it means that the final product itself is far less composed of the lumber of a a dozen experiments. The effectiveness of this is particularly true in XP’s iterative design process. There’s a minimal amount of upfront design in XP, but there’s design *somewhere*. One of the hidden places design gets done is throughout the testing process. Now, that may horrify you, but it definitely means there are rewards to writing tests first that may not exist in a less agile development environment.
It has another knock-on effect, which, I think, leads to more productive and pleasant testing. When I’m writing unit tests these days, I feel a strong pressure not to “code to the test”.
The initial temptation when first writing pre-code tests is to write the minimum needed for your code to work. For instance, the code we’re writing at the moment is a simple WAP client. We have a test which just “presses the button” on the WAP page, to see whether we’re actually activating a CGI script. Putting aside whether this is really a unit test or a functional test (I admit to not truly understanding the difference), our first bash at this had something along the lines of:
|
|
def testButtonPressable(self): full_url = self.wap_dir + self.formurl() # get url of form params = urllib.urlencode({'test' : 1}) # set form with "test=1" f = urllib.urlopen(full_url, params) # open the CGI script return self.assert_('<!-- TEST OK -->\n' in f.readlines()) |
Yoz and I discussed this for quite a while. I felt uncomfortable. It seemed to me that the test added code to the final version, but the wrong sort of code. It just adds to the main method code which fulfills the test’s requirement, and little else.
I was a bit surprised by my reaction to this, but realised that it’s partly what XP teaches you: because you’re outlining the skeleton of your later design in your tests, code like this feels like wasted effort. The test sketches the outline of code, but it’s not code that’s a step toward your final end product.
In the end, Yoz won this argument, and did so by pointing out, I think, one of the problems of unit testing the XP way. XP emerges, in large part, from Smalltalk best practices. One of the great features of Smalltalk is that you’re working in a completely OOP environment. Access and introspection just aren’t much of a problem. If there’s an object out there, you can talk to it.
No matter how OOPified our current programming world is, that’s just not the case, and that poses problems for unit testing with suites like JUnit. Take a look at the example above. One way that we could improve the design of the code, and write a test that fits in with the main execution flow is something like this:
|
|
def testButtonPressable(self): full_url = self.wap_dir + self.formurl() params = urllib.urlencode({'test' : 1}) f = urllib.urlopen(full_url, params) cgiobject = CgiObjectSingleton() return self.assertEquals(cgiobject.form['test'], 1) |
Here we really are testing something, without adding additional code. We’re seeing if opening the form’s submit URL passes data to our cgi code. To do that we get hold of the object that represents the CGI codes state, and peer in it to see if it received the form data.
Unfortunately, this approach is impossible without quite a bit of wrapper coding: the CGI script in our world is in a completely different process space, and lives and dies without being easily introspected by our test code. We could write a persistent CgiObject communication interface, but you wouldn’t normally do so when writing CGI code without a unit test.
This seems a random example, but I’ve hit the same problem in other places as well. Testing WxPython GUIs using PyUnit is difficult, for instance, because somehow you’ve got to interpose your tests into your Python app’s event loop. I have funky code to do this now, but it required some heavy extra coding. Unless you’re really enthusiastic about writing your own test framework code, such test framework hacking has got to feel like wasted time.
It goes without saying that in Smalltalk you hit these problems far more rarely. You’re all sitting in the same event loop, and all instantiated objects and classes are accessible.
Even with these problems, though, I still write my tests before my code. Why? Well, part of the reason is I rather like Smalltalky OOP: having easily examined objects I think does lead to better code, and it’s nice to have that kind of architecture fall out of the test code you’re writing. One of the recurrent problems with CGI code, for instance, is that it’s really tempting to write it in a procedural style. Splitting it up into individual objects makes things a lot easy, and unit testing helps build that discipline.
The other reason is, as the phrase goes, I’ve become “Test Infected“. My tests have now caught so many bugs, small or large, that it feels rash to write code without writing the tests first.
My infection was unconnected to XP practices. The first program I wrote tests for was the code that handles my mail archiving. I really, really, really didn’t want this to fuck up, so I carefully pre-wrote all my tests. Since I started using the code (about 700 lines of Perl), I’ve only hit one bug. I found the problem almost instantly by kicking up the test suite again. It turned out that the syntax of the GNU ‘date’ command had changed subtly between versions. It’s the sort of bug that would have taken days to track down without the testsuites.
My own feeling is that, if you’re uncomfortable with JUnit, just write tests the way you feel comfortable with. After a while, when you’ve received some outright benefits from using tests, you’ll feel more encouraged to get to grips with a more alien suite. In the end, the *Unit classes are just a fancy way of saying: test this, then this, then this, then this. And that’s all you need. For small programs these days, I’m spending more time in Python’s doctest .
Comments Off on testiness
