« March 2004 | Main | May 2004 »

April 28, 2004

Microsoft's architectural hole

The print version of Microsoft's new architecture journal is wonderfully arty in a self-conscious sort of way. But what is the small hole cut out of the middle of the spine for no readily apparent reason?

Quick as a flash the cry goes up, "It must be the security hole!"

April 28, 2004 in Software | Permalink | Comments (0) | TrackBack

Windows CE documentation fights back

Ian Griffiths points to a cunning ruse for excluding that annoying Windows CE documentation from MSDN.

Unfortunately, Ian missed the bit at the top where Saurabh says "Visual C++ developer." Saurabh's fix almost works for the general case... but it also excludes some non-WinCE stuff. In particular, in current versions of MSDN, you lose the C# language reference. And that's just useful enough to make this fix impractical.


I don't understand why the MSDN folks don't just make NOT a unary operator. It's crazy.

April 28, 2004 in Software | Permalink | Comments (4) | TrackBack

April 27, 2004

ID card proposals published

Stand has the best quote on Blunkett's terror excuse: "I'd rather eat worms than risk terrorism — but I'd only chow down if someone demonstrated a causal link between my eating worms and the risk of terrorism."

April 27, 2004 in Current Affairs | Permalink | Comments (0) | TrackBack

April 25, 2004

Small nations

I love small nations
I love small numbers
The world will be saved by the few.

-- Andre Gide

April 25, 2004 in Current Affairs, Travel | Permalink | Comments (0) | TrackBack

April 24, 2004

A mailing list is not a debugger

People offering answers on developer mailing lists often apologise for typos by blaming the "Outlook compiler." Many subscribers seem to take the metaphor a step further by using the list itself as a debugger.

To be clear, I have no problem with people posting code which doesn't work and they can't understand why. Developer mailing lists exist to help people solve problems and gain understanding. But it does aggravate me when people don't even bother trying to understand the problem themselves: they turn first to the list, as a no-brainer action.

Look at this. The guy has an error in his stored procedure, it comes back with a clear error number, the error message tells him it's on line 31, and what does he do? He posts it to the mailing list. Does he even look at line 31? Clearly not, as the error is trivial. Does he look up the error message in his database documentation? Not that he mentions. No, just run it up in the "Outlook debugger" and make it somebody else's problem.

The reason this angers me is that, well, it's so parasitic. The message is, "I care so little about the time of the other 1000 guys on the mailing list that I can't be bothered to put in even 30 seconds investigating the problem myself -- I'll just leech off you." No, I'm sorry. My time is just as valuable as your time. I don't mind giving you my time to save you significant effort or if you're really stuck or if I'm going to learn something -- and I'm grateful that there are people out there who will do the same for me -- but I do resent giving up my time when you've shown no inclination to put in any time yourself.

Oh, and to add insult to injury, in this particular case the poster was bothering a Windows Forms list with what was obviously a T-SQL issue. If you're going to use a mailing list as a debugger, at least think about which mailing list to use.

I'd like to call out a notable exception to this rant. Developer lists often see dumb questions from beginners, and sometimes they get pretty short shrift. I do feel that modern development frameworks are sufficiently intimidating and hard to navigate that beginners do need to ask dumb questions just to get their bearings. Yes, often the answer is obvious or they should just read the documentation. And if they prove that they're not willing to try to get their bearings, but instead ask the list as the first port of call, then let's put them in the killfile at that point. But when you're just striking out, it can be really hard to know where to start, and a brief, courteous pointer to the right documentation or API can really save a lot of time.

On a related note, a quick reminder: putting "OT" in the subject line does not make it acceptable to post any random question or issue to an inappropriate list just because it happened to be at hand. Thank you.

April 24, 2004 in Software | Permalink | Comments (0) | TrackBack

April 20, 2004

P/Invoke wiki

Adam Nathan has set up pinvoke.net, a Wiki for people to lodge .NET interop declarations. Already seeded with plenty of useful stuff, which will hopefully be enough to bootstrap a community effort around it.

Plus it has a kewl fade effect between pages, which from experience is what you really need when you're interoperating with unmanaged code.

One small problem is that, at the time of writing, it's missing struct and constant declarations, but hopefully users will add these as they start using the APIs. It could possibly do with getting some VB folks on board as well, as currently the declarations are C# only. Still, minor niggles for a great resource.

April 20, 2004 in Software | Permalink | Comments (0) | TrackBack

April 17, 2004

Dave Winer seeks typewriting fogies

Dave Winer: "What happened to people who use typewriters?"

They're still out there, often nestling in the literary pages of the Guardian. Though the complaint du jour is no longer, "I think more before I write [with a typewriter]" but "with a word processor, people get hung up on revising every sentence as they go along."

And of course then there are the people who just don't care. A lot of older people just don't see why they should bother learning computers. They just don't need them. I'm sure my mother only forced herself to learn a word processor because she started having to do mailing labels. But they don't make a noise about it, except maybe to express baffled incomprehension to their families and neighbours. And computer people tend to forget about them because -- hey -- people who use typewriters instead of computers don't, by definition, have Web sites.

April 17, 2004 | Permalink | Comments (0) | TrackBack

The computerisation of aesthetics

Discover magazine dispenses justice to ugly Windows startup screens: "We wouldn’t accept this kind of visual disruption when we sit down to watch television -- The West Wing doesn’t begin with a string of time codes and copyright notices -- but somehow we’re supposed to take it for granted on a computer screen."

I guess these people have never watched a DVD. As computer aesthetics shift towards those of entertainment and art, so it appears entertainment aesthetics are shifting towards those of computing.

April 17, 2004 in Usability | Permalink | Comments (0) | TrackBack

April 14, 2004

Service-oriented architecture within an application

Ted Neward: "I submit to you that, as a simple measure, SOA == components + context-complete communication. Whether your services are in-proc or out-, the key is to understand the boundaries you wish to define and enforce."

Don Box likes to talk about four key tenets of SOA: explicit boundaries, autonomy of services, share schema not class and policy-based compatibility. To me, the boundary issue is the least interesting for in-process services -- from this point of view, in-process services look very similar to boring old components. But I am interested in what the SOAP style of messaging brings in terms of policy-based compatibility.

Let's recap. Services interact by sending messages. In the Smalltalk world, objects (components) also interact by sending so-called messages, but these "messages" are quite limited compared to SOAP and pretty much come down to method calls. In the .NET and Java worlds, components do interact using method calls: these can get translated into messages along the way, but actually using that messaging layer is a bit of a black art, and the callee still ends up receiving it as a plain old a method call. So in practice in-process messaging consists only of a method and a payload of arguments: effectively, the SOAP body.

In SOAP services, however, messages are much richer, with headers defining policies and demands that must be processed before the server can even look at the "method call" payload. Is there value in extending this behaviour to components?

I guess that depends on what sort of policies we can envisage affecting component compatibility. In the wild world of the network, issues like reliable delivery and security are obviously very important because the service is out there in some ill-understood cloud. Within a process, these policies seem rather redundant. What is the point of signing messages that are travelling only within your own memory space? Isn't reliable delivery a given within a process?

And yet compatibility clearly is an issue in the component world. Components can and do want to have guarantees of their peers' capabilities and behaviour. Perhaps, at a simple level, this is just proxy information for service policies -- for example, if a caller demands reliable delivery, the callee can bounce that request immediately because it knows it will not be demanding reliable delivery from the service to which it forwards messages.

I have to admit that I am struggling to come up with any truly compelling case for using header-plus-body messaging within a process as opposed to traditional body-only messaging. But it does seem to me that this is an avenue which bears investigation.

April 14, 2004 in Software | Permalink | Comments (1) | TrackBack

April 13, 2004

Dan Brown, The Da Vinci Code

One of my favourite Bloom County cartoons has Opus reviewing a film. "Bad acting," he complains. "Bad effects. Bad everything. This bad film simply oozed rottenness from every bad scene. Simply bad beyond all infinite dimensions of possible badness." Long pause. "Well, maybe not that bad, but Lord, it wasn't good."

The Da Vinci Code is like that. Bad plotting. Bad writing. Bad "brainy" bits. Somehow, it manages to be not as bad as that -- after all, I did manage to finish it -- but Lord, it isn't good.

Let's start with the brainy bits, as these are what supposedly lift this out of the ordinary. The book is crammed with excursus on art, architecture, cryptography, mathematics, Christian mysticism and secret societies. Most of these are lifted directly from The Holy Blood and the Holy Grail, though this is forgivable as most people won't have read this. The purpose of these excursus appears to be threefold: (a) pad out the book; (b) prove that Brown has done lots of research; and (c) break up any tension or pace that Brown manages to establish. For example, in the middle of our heroes' escape from the Louvre, Brown breaks off for 5 (five!) pages to deliver a lecture on the golden ratio. Not only is this a completely inappropriate time and a completely excessive length, the concept and the examples that Brown trots out are completely irrelevant to the story as a whole.

Most annoyingly, the "brainy bits" exhibit galloping Foucault's Pendulum syndrome. In Eco's book, "Everything is connected to the Templars" was a self-adopted challenge to the main characters as well as a satire on conspiracy thinking; Brown seems to have missed the joke. His characters are all to eager to take anything and everything he foists upon them and reveal that -- wow -- it is connected to the sacred feminine. Or the Templars. Or the number five. Or Leonardo da Vinci. Or-- well, you get the point. Once Brown's heroes have achieved "connnection critical mass" they can link any old cod to something on the list of "things connected to the sacred feminine," and thereby to everything on the list.

Then there's the fact that the plot is founded on a nonsense. And I'm not talking about any dispute as to the plausibility of the underlying mystery of the novel: on the contrary, I've been at home that that particular theory for twenty years. And that familiarity is exactly why the plot falls fundamentally apart. The crux of the story is that there is a secret which, if revealed, would precipitate the greatest crisis in the history of the Christian church. The problem is that when this secret was revealed some twenty years ago, the church remained conspicuously unrocked. Brown even cites the book and TV show which publicised the secret, and admits that the controversy was a nine days' wonder. But if the revelation of the secret was a non-issue then, why would it be a big deal now?

Finally, there's the writing. Normally I wouldn't worry about the quality of writing in a thriller. After all, what we look for in a thriller is to be efficiently transported out of our drab little lives for a couple of hours. Unfortunately, Brown's writing is so bad that the imagination continually stalls as it tries to take flight. One is the predilection for inopportune product placement: our heroine actually stops during their escape from the Louvre to tell our hero what mileage she gets from her SmartCar (tm). Another is character naming. I can forgive "Bishop Aringarosa" as merely infelicitous (the playground rhyme "a-ring-a-ring-a-roses" makes the name distracting and silly to British readers, but this is just a local quirk). But naming a major character "Leigh Teabing" was a fatal mistake. As a tribute to Leigh and Baigent, two of the authors of The Holy Blood and the Holy Grail, it would have been a nice touch for a minor character. Assigned to a major character, the clearly artificial moniker becomes a continual irritating reminder of the author's presence.

But the worst part of the writing, by far, is the dialogue. Oh God, the dialogue. Even I could write better dialogue while having my nadgers sanded down with a box jellyfish, though this is not intended as a boast: anyone could write better dialogue by copying their video recorder manual inside a pair of quotation marks. Here's a sample of our hero's conversational style: "The documents had long since been entrusted to the Templars' shadowy architects, whose veil of secrecy had kept them safely out of range of the Vatican's onslaught." Acceptable, if a little purple, as populist historical exposition, but this is meant to be dialogue. Try prefixing it with "As I was saying to Brian in the pub the other day," and tell me this is anything less than ludicrous. Every other time a character opened their mouth I had to put the book down in disbelief and go for a walk.

And this is the fundamental problem with The Da Vinci Code. Nobody should expect great writing from an airport thriller, but we are entitled to expect that the writing shouldn't break our suspension of disbelief. That, not literary quality, is the sole benchmark of escapist literature. But the writing and plotting in The Da Vinci Code are so obviously broken -- so intrusive, so distracting and so cringeworthy -- that it is impossible to relax into it and get carried away.

So there is really no reason to read The Da Vinci Code rather than Foucault's Pendulum or The Holy Blood and the Holy Grail. Even if all you want is a page-turner tastily spiced with art, history and mysticism, the originals are far more absorbing as well as more convincing. This is a bad book, and it oozes rottenness from every bad page. Please, please do not buy this book. Even at airports.

April 13, 2004 in Books | Permalink | Comments (6) | TrackBack