Now, I own a Windows box (which runs VMWare, which runs three other Windows images and a Linux image, so perhaps it is fairer to say that I own lots of different virtual boxes but I still feel most at home in Windows), and I've tried to get the JDK (since version 1.3? 1.4? when they first introduced the SCSL licensed-source) to build under Windows on my own. Oh, I've managed to get pieces of it to build--most notably the VM--but I want the whole thing, lock-stock-and-barrel, so I can start doing some major spelunking across the entire JVM-and-related-libraries, and maybe even do a book on it.

Enter this page.  I haven't tried it yet, but wow, talk about step-by-step. Have to give that a spin, maybe on a fresh VMWare image (just to avoid cluttering up the others).

John Haren, of CodeSnipers.com, recently blogged about something I feel pretty strongly about:

There's a common trope in CS education that goes something like this: "All software evolves, so be prepared for it."

Far be it from me to imply that one shouldn't be able to respond to change; that's not my intention. But the idea expressed above contains a flaw: software does not evolve.

Duh, John… everyone knows that software changes. Features creep. Scope broadens. New platforms and whizbangs are targeted. Get with it!

I concede the obvious: of course software changes. But repeat after me: software does not evolve. Because change != evolution.

Evolution is a blind, natural process; the result of random mutations in an organism. Now it may just so happen that the result of the mutation is beneficial to the reproductive success of the organism, meaning we’d expect to see creatures with such a trait outperform others without it. That's how traits are selected for. In the overwhelming majority of cases, mutations are detrimental, and they don't stick around for long (since there are many, many more ways of being dead than alive).

Now in order to say that software evolves, you'd have to accept that your development process goes something like this: Developer opens a file at random, positions the cursor at random, punches a few keys at random. Developer then recompiles and sees what happens, hoping for the staggering luck that the resulting change actually does improve the software, and everybody loves it, so they buy it, and you'd expect to see more of it.

Okay, insert joke here about how your development process seems that way from time to time.

Jocularity aside, there's more at issue here than a flawed analogy. Of more significance is the type of thinking it can engender. Nothing "just happens" in software. Whatever it is, somebody made it happen. Someone decided. They may very well have decided in error, but they decided. They decided "well, let's just try and fit that feature in; it shouldn't cause too many problems if it goes out only 70% tested... if it breaks, we'll deal with it then." Or they think "yeah, a talking paperclip… why not?" In other words, magical thinking. Don’t do that.

And CS departments should stop teaching that. Let them stress peopleware instead.

His presumption here, which may seem fair at first, is that all evolution is basically random. And, frankly, that's not entirely without truth. But what he sees as the randomness in the system is different from the randomness that I see, and that's that the users are what bring the randomness into the system.

Look, how many times hasn't a user told you, "We need this feature", only to discover six months after shipping that feature that nobody's really used it, but that it in turn sort of answered a different problem that you ended up providing for them as a new feature? See, the software itself doesn't evolve randomly, but the users' interactions with the software do. That's evolution, that's healthy, and that's how software evolves.

In short, it's recognizing that the users are part of the system, too, part of the organism that makes up this bizaare and wonderful world we live in, and their input is often exactly that: random. Which is probably why it's so important to have the on-site customer, as per agile development's recommendation, because you never know when randomness will strike and make your life better/faster/easier.

I gave two talks at the JavaZone 2005 conference, which I've made available here, "Concrete Services" and a few items from "Effective Enterprise Java", because I didn't get the slides into the organizers in time for them to include on their site. Enjoy.

The title is a bit scary, but "Rootkits", by Hoglund and Butler, really is anything but. Oh, I'll admit, their talk of how rootkits--programs that hackers install onto your system that patch into kernel space and thus are undetectable by any user-mode program--is scary, but then they walk you through the process of developing your own rootkit, thereby giving you some awareness of what a rootkit looks like, acts like, and therefore can be discovered and killed.

Well, in theory, anyway.

To put it bluntly, I'm loving this book, if only because it's the first book I've run into that really sits down and explains how to write a device driver, not to mention how to communicate with it from user mode. I've been fascinated with that very idea for many years now, but all the DDK-based material I've found--books, articles, etc--all assumed that you wanted to write some variation on the SCSI driver or something, implying that you care more about device-level details than you do in writing kernel-mode code. Rootkits, of course, are nothing like real device drivers, but a lot more like what I'm interested in exploring and displaying (that is, getting at program information from within the kernel--very useful for debugging scenarios, for example).

By page 30, you've already written and compiled a basic kernel driver, and by page 39 they've discussed how you can have your driver expose itself as a special file handle for communication with user-mode code. Pages 40-43 talk about loading the driver from code, and 43-46, how to extract your driver from a user-mode program as a resource, suitable for loading (because, of course, rootkits need to piggyback on top of other code to install themselves, stealthy-like). Pages 46-47 talk about how to make your rootkit survive reboot, and that concludes Chapter Two.

Wow. I'm in love.

It's not the be-all-end-all book on drivers, nor is it going to necessarily turn you into a l33t hax0r, but if you ever wanted to get started understanding how rootkits work (so as to start looking for them on your own system in order to remove them) or just use that knowledge for more benign purposes (such as trying to figure out NT internals so you can more efficiently--and automatedly--debug services or server-style programs), this book rocks. Easily a classic, and one I'm probably going to carry around with me as much as I do Hoglund's other book (with Gary McGraw, one of my favorite security authors), "Exploiting Software".

I'm in Oslo, Norway, for the next four days, ostensibly to speak at the JavaZone 2005 conference, but the truth is, I don't really care why I'm here.

Truth is, I've discovered that Oslo is quite possibly the closest place on the planet to claim being a real-life Norman Rockwell scene.

The drive from the Oslo airport to downtown Oslo (to the Radisson SAS hotel) is quite possibly one of the most beautiful drives I've ever had the pleasure of making--it really is like driving through a Norman Rockwell painting, with the farm fields off to both sides, thick lush forests rising on the hills, and the buildings just barely visible, nestled in amongst the trees and rising slopes. If it weren't for the fact that I know this place is going to be just buried in snow in the next month or two, I'd seriously consider living here for a while.

Oh, and I've also discovered that Norway is one of the western European nations that doesn't (yet?) take the Euro--tip to American travelers, don't take cash out at the Amsterdam airport when you're headed off to a non-Euro country. It's an expensive mistake.

For anybody who's not been paying attention to the technical news front, this week is Microsoft's PDC in LA, and one of the things they've announced for the next release of Visual Studio is Project LINQ, short for Language INtegrated Query. In essence, C# 3 and VB 9 are going to integrate (through a variety of language extensions, such as lambda expressions) query capabilities directly into the language, making much of the need for an automatted O/R mapping layer (such as Hibernate or JDO) a thing of the past (at least, in theory).

If you haven't had a look, check out Dion's or Ben's weblogs for details; there's also a paper coming out (by Don Box and Anders Hjalsberg) with the LINQ Preview bits that contains the best description of the language/tools I've seen thus far.

Ben Galbraith discovers a little snippet about XML encoding that is both subtle and evil:

A while back, I was working on a system feature that read in some XML from the filesystem, XSLT'd it into HTML, and served it up to a browser. The XML had a bunch of characters from the higher Unicode ranges (i.e., >255), and wouldn't you know, when viewed in a browser, these characters showed up as garbled data. Not "The Box"–that ugly little placeholder used when a font doesn't contain a character for a given code point–but usually one to three seemingly random characters that had nothing to do with the character that was supposed to be displayed.

...

And then, whilst reading through some of the backend code, I saw this innocuous little line:

Document document = new SAXBuilder().build(new FileReader(file));

See the problem? Look again. ... This is the code I should have written:

Document document = new SAXBuilder().build(new FileInputStream(file));

If you hand an XML parser bytes, which is the currency of InputStreams, the parser handles converting those bytes to characters itself, and uses the encoding in the XML prolog to configure itself for that process. If you hand it characters... it's stuck using those characters and can't affect the decoding process one whit, since it occurs a level beneath it.

The lesson? Be aware of your encodings, at all levels of the translation and processing machine... And if you don't know the difference between UTF-8, Unicode and ASCII, you're falling to the trap that goes by the name of Leaky Abstractions....

So I've finally unpacked my office enough to find my game machine... er, workstation, that is... which has as its main benefit a removable drive tray that contains the drive I boot from. Advantage being, when I want to try out new stuff (such as Windows Vista) on a raw hardware machine, I don't have to screw with partitions, nor do I have to be worried about trying to make it work inside a VMWare or VPC image. So, dusting off the removable drive tray that contained the PDC build of Longhorn, I stuck it into the drive tray and prepared to install (by blowing away the Longhorn partition already there) Vista Beta 1.

For starters, it's nice that it boots into a graphical mode right away (though I'm sure the 2-tone black-and-white "Longhorn" boot animation-and-image isn't going to remain as such, because it looks really ugly), and then only asks for which partition to install on (choice of two in my case, the boot drive or a data drive inside the box) and a machine name, before it gets to the "I'm going to chug away for Lord knows how long" screen indicating that it's installing stuff. This is kinda nice, particularly for so-called "power users" like my father, who has more of a tendency to get himself into trouble with options than is really served by having them. (He'll moan and gripe, I'm sure, but frankly, if it means less tech support calls to his son, then that is a Good Thing.)

Of course, installation took forever (I didn't bother timing it--I didn't have a calendar handy), but it's been a pretty well-understood truism about installing software for a few years now, that when you get to that "Please wait" screen, you go off and do something else. (In my case, it was running network cords behind the office furniture and putting my kids to bed, including chastising the elder son for playing with my Magic cards without my permission.) One thing I would like, however, is that the green progress bar at the bottom of the screen actually monitor progress of the complete installation process, not whatever step it happens to be executing--it keeps crawling across to the right, then resetting and starting over. Kinda like the bullies used to do on the playground--snatch your lunch money, then hold it up over your head, "C'mon, reach for it, reach for it, HUP!" and yank it up out of your reach when you do jump. (Not that I'm bitter about the experience or anything....)

When installation finally completed and the box rebooted, it goes through an interesting set of personalization settings application--not sure what they were all for, but I guess that will become more apparent over time. Immediately on bringing up the user shell, though, the Vista beta tries to load XP drivers that aren't natively supported inside Vista, which is kind of a nice touch, because I could tell this would be rough if I had to go back to 640x480; at least I think it was 640x480, because it felt like 200x150. It found my graphics card (a GeForce something-or-other, I forget) and installed those drivers, though it still booted into Really Hideous Fat Pixel Mode on startup. That said, though, a quick right-mouse-click on the desktop and changing-of-settings brought it into a more reasonable 1280x1024 mode pretty snappily. It still didn't recognize my sound card, however.

That's about as far as I've gotten with it thus far, although I noticed fairly quickly that Microsoft still hasn't fixed that critical bug that's been in Windows since the 3.0 days... you know, the one where they don't let you cheat at Solitiare...?

Scott Hanselman recently announced that he was doing to do a review of a product on his weblog, which isn't unusual; what is, for him, was that he was being paid to do the review, and a couple of readers of his weblog took issue with the fact that Scott was violating his own ethical blogging policies to do so. To wit:

Er.. that's not a review, that's dangerously close to payola.

Yeah, but in an earlier post you said you'd only post about software you felt passionate enough to post about.*

Sho' nuff. That's the essence of a blog; it's why they work.

I could maybe understand if they provided you a free copy of the software to review at your discretion, but directly _paying_ for a review is kinda strange IMO. It's definitely not wrong, and you had a nice disclaimer in there and all. But it ultimately undercuts the whole passion argument. "I'll only write about products that I think kick ass.. oh yeah, and products that someone pays me to write about."

I'll say the same thing to you that I say to my wife: I still love you, just a tiny bit less than I did yesterday. ;)

* as I recall, you made a big deal out of this specific point.

Frankly, I think Scott caved, and there was no reason for him to do so. Here's why:

1. Scott's ethics and sense of ethical responsibility are so far above reproach, it's hard to believe we're having this conversation about him.
2. There is a crucial difference between "reviewing", "endorsing" and "sponsoring", as I see it (though all of these terms are weaselly enough that we could easily spend a lot of time just in definitions and semantics). A "review" implies that the individual in question (Scott) will offer up a candid, no-holds-barred discussion of the product/tool/technology/whatever, with no implicit bias and no implicit agenda in performing the review. An "endorsement" means the individual has evaluated the product, and thinks that people should be using it if they're not already. Neither of these thus far implies payment for review or endorsement--for example, I endorse Java, and I endorse .NET. In fact, I endorse a whole bunch of books, too.
3. That said, however, my time (as is Scott's) is a precious resource--I don't have a lot of it to give away. If a company wants me to do a review of their product, particularly if it's something I'm not going to pick up as part of my normal activities, then I want to justify the time--the time I spend working on the review is time I'm not spending on other paying work or writing. The economists call this "opportunity cost": what are you giving up in order to pursue a particular activity? In Scott's case, like mine, it's either paying work or else it's personal time with the family, neither of which I'm gong to sell cheaply.

Where I think Jeff Atwood (the commenter on Scott's blog) is concerned is that it's hard to tell if Scott's review was positive because of the fact he was being paid for the review, and there we have the crucial question, that of motivation. What was Scott's motiviation while he was writing the review? This is a question that only Scott can answer (and frankly, I think he did a damn good job of answering it when he turned down the fee), but for readers of Scott's weblog, the crucial question has to be, "Do you trust Scott to offer up a fair review even if he's getting paid for it?" For my money, I think yes, because Scott's one of those people who can only be described as "brutally honest". The idea that Scott would change what he says just because he's getting paid to review something just doesn't jibe with what I know of the guy.

Meanwhile, moral support for Scott has emerged, in the form of endorsements (yes, I use that word deliberately) of his character from Carl Franklin and Greg Hughes, and Mike Gunderloy points out that

The software review business is an ethical muddle - much more so on the printed magazine and major site level than in blogdom. Many people aren't aware of it, but print magazines generally approach software vendors with a pitch similar to this: "We'd like to review your product X in our upcoming issue. You'll need to send us a copy with a full license for our reviewer. We're sorry, but this has to be a full license, not a Not-For-Resale license. That's our firm editorial policy." The reason for this policy? Because the pay for writers for writing reviews stinks, and reselling products on eBay after the review is written is a nice little bit of extra income.

Pretty much everyone, big or little, accepts free licenses - sometimes full, sometimes NFR - of the product under review. I do it myself (and disclose it on my site). So you always have to take that into account; the reviewer didn't pay the $10,000 for that fancy product that he's raving about. Possibly his opinion would be different if the money were coming out of his own pocket.

All that said, I'm glad to see that Scott isn't taking money directly from product vendors. That crosses a traditional journalistic ethical line, and I'm enough of a traditional journalist to not want to cross that line.

I won't say that I've never written about a tool or technology that I didn't believe in--fact is, there were some slow months in the past couple of years, and I, like the proverbial young starlet, had to do some pieces that I hope don't come to light someday. That said, though, all of those pieces (and there were thankfully very few of them) I refused to sign my name to. Because, in the end, that's what Scott--and I--really sell. My name, Scott's name, there's an implicit trust from the people who respect us, that we won't attach our name to something cheaply. And folks, I can guarantee two things: I won't, and neither will Scott. And in the end, you either trust our word on that, or you probably don't care about our names to begin with.

Stefan Tilkov blogs about my rebuttal to ERH's rather limited comment about "nobody's doing Web services over anything over HTTP anyway" (which generated some additional postings, most notably from Steve Vinoski), but says something pretty fundamental:

I think its just a matter of perspective: for Web scenarios, nobody uses anything but HTTP anyway, and for the vast majority of company-internal use-cases, Id consider HTTP to be a much better solution than some vendors proprietary messaging middleware. But even if one assumes that HTTP is going to become the protocol of choice for EAI as well, WS-A still has merit to support asynchronous processing of SOAP messages.

The problem is that when we say "Web services", the "web" part of it implies HTTP and REST and all that other stuff. It's time we faced reality: SOAP is not just for doing stuff over the Internet. It's time we started calling them what they are: XML services. Unfortunately, I don't think the W3C is going to change the name of WSDL to XSDL or XS-Addressing any time soon, but that doesn't stop us from at least trying. My promise: if you catch me, in a presentation or class lecture, using the term "Web services", and you're the first to point it out, I owe you a quarter. Long live XML services!

After a circuitous route through Davis before it got here to Seattle, my copy of Java Developer's Journal finally showed up at my doorstep over the weekend, and from the top of the magazine's cover blared Calvin Austin's editorial entitled "C#: Is the Party Over?"

Huh?

As I read through the editorial, I began to realize that not only were the points ill-conceived, but that Mr. Austin doesn't even offer up credible or factual basis for his perspective--in other words, this is FUD at its best, the very same tactics that Sun accuses Microsoft of using when the facts don't suit.

Mr. Austin begins by justifying his expertise on the subject by saying,

One of my tasks at Sun was to keep abreast of the technologies in the marketplace that competed with Java.

Next, he begins his arguments as to C#'s iminent demise:

The .NET platform has been under constant development, often too fast for many corporate users to accept. There has been a 1.0, 1.1 and 2.0, each which could be counted as a significant version in their own right.

What I find fascinating, however, is the implicit criticism that innovation and progress is bad. Corporate users aren't accepting of too many changes, true--this is precisely the experience Sun faced during the 1.1.x hyper-release cycles, when they were castrated in the press for doing too many releases in too short a period of time. But an eighteen-month release cycle (which is the current development cycle for the .NET teams) is hardly what you call rapid, and frankly, I've heard a number of developers complain that the releases are too far apart to begin with. Coupled with the fact that both platforms support a very good side-by-side deployment story, I think both Sun and Microsoft could stand to shorten their cycles, not point-and-kvetch that the other side is releasing too quickly.

Next we see Mr. Austin point out that C# hasn't been the astounding success Microsoft wanted it to be:

Looking at the forums, Visual C++ and Visual Basic and not C# attract the lion's share of the forum attention.

In addition, the underground community site, gotdotnet.org, has undergone significant site and management changes.

The C#, C++ and C compilers are now free, although not obviously as optimized as the professional edition.

Mr. Austin continues with his analysis by pointing out that C# "didn't make the grade" because:

... the Java platform did not stand still. Many of the benefits that the Java platform delivered were not solved by moving to C#, the most significant difference being OS independence.

While C# was in rapid release mode, the Java platform was able to fine-tune the language and at the same time invest heavily in stability and scalability.

Deploying a .NET service leaves a company a small choice of application servers and OS versions.

The criticism continues with his prouncement that "open source changes everything":

While developers had to get budget approval for MSDN licenses, the Java colleagues were able to deploy a system for free.

The growth of open source Java hasn't stopped there. You only have to look at Hibernate, the Spring Framework, and Struts/Shale to see that developers can work together to solve their own problems.

And no Java-centric criticism of .NET is complete without bashing Mono for a bit:

Mono today is still a development project much as .NET is still looking for full traction.

Mr. Austin wraps up his editorial with:

Is the C# party over? If the plan of C# was the slow the defection of Visual C++ developers to Java, then it was certainly better than nothing. The long-term savings for Microsoft in sharing a CLR between projects was more than worth the initial effort. However, C# is still not the de facto choice for web site or enterprise development and other languages such as Python and PHP, which are bringing in a new generation of developers who don't have a need to migrate Visual C++ applications. C# isn't going anywhere soon but its best days may be behind it.

• Is the C# party over? Considering how he's been equating C# and .NET as one and the same thing, Mr. Austin clearly demonstrates his inability to tell the difference between languages and platforms, a failing of Sun's for the past decade. Even assuming C# as a language were to fall apart tomorrow (highly unlikely), the other languages--Visual C++, Visual Basic--would keep .NET alive for a very long time to come. So, if you're to refute my arguments, make sure you clearly delineate between refuting the language (C#) or the platform (.NET). Combine this with the fact that Microsoft is about to unveil the plans for C# version 3.0, it hardly seems logical to suggest C#'s party is over.
• If the plan of C# was to slow the defection of Visual C++ developers to Java... An interesting insight, one that I particularly agree with. But it also sells short the idea that Microsoft simply saw the union of Java-the-language and the platform (COM at the time) as a Good Thing, one that they wanted to enhance and adopt for themselves.
• ... then it was certainly better than nothing. Ah, a masterful choice of words, implying that there were much better things they could do, but chose not to for a variety of reasons. What those things were, who knows, particularly since Microsoft DID try to use Java as the core of their platform going forward (by leveraging Java and custom attributes, yielding J++) but were sued out of it by Sun.
• The long-term savings for Microsoft in sharing a CLR between projects was more than worth the initial effort. Don't be too quick to toss this off, Mr. Austin--the costs in sharing a platform between languages are subtle and deep. The cross-language .NET project is a lot more complicated than many people believe, and we can see that trying to build a platform that's somehow "universally acceptable" to all kinds of languages is a difficult thing by looking at the efforts under way on the Parrot project. Microsoft has certainly done a powerful thing in building the CLR--and standardizing it--but it wasn't easy, and something whose costs and effort hasn't been fully measured yet.
• However, C# is still not the de facto choice for web site or enterprise development... Not amongst the Java crowd, certainly, but there's a lot of sites out there with ".aspx" in their URLs--measure for yourself if you don't want to believe somebody else's statistics--seemingly putting the lie to Mr. Austin's cavalier statement.
• ... and other languages such as Python and PHP, which are bringing in a new generation of developers who don't have a need to migrate Visual C++ applications. Huh? This part of the sentence doesn't even make grammatical sense, but what I think he's saying is that a whole collection of website developers, who currently use Python and PHP, have no need or desire to adopt C#. Got news for ya, Mr. Austin, this is the same crowd that has no need for Java and J2EE either. They're hung up on Ruby and Rails right now, and probably still have a huge collection of Perl scripts that they use on a regular basis that have no easily-ported Java--or C#--equivalent. Fact is, the scripting crowd has very little use for any statically-typed, compiled language, be it C++, Java, or C#. Or VB, for that matter.

In the end, the reason I refute the meat of Mr. Austin's editorial is simple: Java developers are being fed a constant stream of FUD about the .NET platform these days, just as the .NET community is being fed its own set of FUD about the Java platform by various players there, too. I find myself spending about equal amounts of time explaining the Java community to the .NET world as I do explaining the .NET world to the Java community, and although I typically get nothing but ridicule, anger and/or disbelief from the various zealots on both sides, I find that the majority of developers I speak with on the subject are quite interested to hear what the "other side" is doing. It goes back to what I said earlier--the more you know about the other platform, the more you can leverage their experiences and innovations for your own use. But the first step to learning about the other platform is to recognize that they're doing something useful, and not just write off everything happening as irrelevant or meaningless, or to make such boldly unsustainable claims as "The Party's Over" or that "its best days are behind it". More importantly, it's editorially irresponsible that JDJ published this tripe; granted, JDJ's readership may think it wants to hear that the .NET platform isn't useful and powerful, but that's a factually incorrect statement and is likely to cause more pain in the long run than to simply face up to the fact that .NET is Java's twin brother and can do anything Java can do.

Jared Richardson took issue with my assertion that there's no such thing as best practices, stating that, in essence, it's not kosher for me to deny existence of something that I have to define:

They said "There are no best practices" and then they had to define the term... but they defined it wrong! A best practice isn't a required practice or a universally dominant practice. It's just one of the best ones. It's used quite often, but not everywhere and not always. (No such thing as best practices? Sure there are!)

Unfortunately, Jared, the semantics of the term "best practice" implies exactly that: something that's used everywhere and always, for when would anyone choose not to use a "best practice"? And if it's not used everywhere and always, then it's not "best", implying "better than all alternatives", ya?

How about, at the end of the day, we just drop the term "best practice" altogether, and stick with "useful practice" instead? Would that satisfy everyone's sensibilities?

A couple of people have asked me what my speaking schedule looks like for the next quarter, so, barring any last-minute cancellations or shifts in schedule, here's where I'm going to be over the next few months:

• Aug 27-28, Cincinnati, Ohio: Southern Ohio Software Symposium, doing my usual raft of $NFJS talks: "The Ten Fallacies of Enterprise Computing", "Effective Enterprise Java: Security", "Introduction to Web Services, 2005 edition", "Java Metadata", and an architecture/end-of-conference open forum
• Aug 31, Portland, Oregon: Portland Area DotNet User Group, doing a talk on .NET persistence options
• Sept 14-15, Oslo, Norway: JavaZone, doing talks on "Concrete Services" and "Effective Enterprise Java"
• Sept 16-18, Chicago, Illinois: Great Lakes Software Symposium, another $NFJS show
• Sept 20, South Bend, Indiana: Michiana Area DotNet User Group, doing "Intro to WS-2005"
• Sept 25-30, Arhus, Denmark: JAOO, doing "Passing Messages", "Core Indigo Patterns", "Effective Enterprise Java" and "C# Intro" (for Java developers who haven't picked up the CLR/.NET thing yet)
• Sept 26-29, Boston, Massachusetts: SD Best Practices (yes, I know this overlaps with JAOO; it's going to be a very interesting travel week for me that week ), speaking on "Passing Messages" and "The Fallacies of Enterprise Systems"
• Oct 11, Orlando, Florida: VSLive! Orlando, talking on "Hosting ASP.NET"
• Oct 14-16, Seattle, Washington (my new hometown!): Pacific Northwest Software Symposium, another $NFJS show
• Oct 28-30, Reston, Virginia: Northern Virginia Software Symposium, another $NFJS show
• Dec 5, Salt Lake City, Utah: Utah .NET User Group, talking about... er... something interesting (we haven't decided what yet)
• Dec 13-17, Belgium: Javapolis, though... I'm not sure what I'm speaking on, and I'm not on the wiki (yet?)

And it's entirely possible I've left something out, so if you think I'm speaking at an event near you and I don't have it listed up there... email me? Please?

Update: It looks like I won't be at the $NFJS Calgary show, despite my earlier having committed to it; the travel logistics required to get there are just horrendous. So no, I'm not doing NFJS Calgary, despite what it says there on the website.

If you're going to take the time to leave a comment, you obviously want your views to be heard, by either me or the people who read my blog, or both. So, then, take the time to make sure your views--and not just your opinions--are presented in the best light possible. Offer arguments, credible or otherwise. State your reasoning. Explain why your conclusions differ from mine. Don't just write "I don't agree" or something similar to that effect, because several things happen when you do this:

1. Basically there's nothing for me (or others) to learn from it, so I pretty much ignore the comment.
2. Because your email is (often) associated with the comment, it sorta makes you look bad.
3. Worst of all (to me), you let go an opportunity for either or both of us to learn.

This isn't a general ban on comments--I could do that without posting. This is an attempt to point out that if I wanted the conversation to be one-way, I wouldn't leave comments turned on in the first place. This is the best mechanism I know of thus far for you to call me out on my arguments--why waste your time otherwise?

James Bach recently blogged about something I've been saying in conversations with friends and conference attendees: there ain't no such thing as a "best practice".

He lays out his points in a letter to his blog readers, and I want to comment on a few of them.

First, "There are no best practices. By this I mean there is no practice that is better than all other possible practices, regardless of the context. In other words, no matter what the practice and how valuable it may be in one context, I can destroy it by altering things about the situation surrounding the practice." James hits the nail on the head with this one: any practice, taken out of context, can easily be turned from "best practice" to a "worst practice" without too much difficulty. The patterns guys had it down: A Pattern, or let's call it practice, so that we can talk more about concrete things, is a Solution to a Problem within a given Context that yields certain Consequences. You cannot avoid this basic relationship. (The patterns guys then wanted to take practices, examine them across domains, and find the commonality and elevate it so that we could apply them in a domain-independent manner; hence the reasoning behind the Rule of Three, which so many pattern "writers" seem to miss.) It makes sense, even on an intuitive level: I walk into a doctor's office, and say, "I have a cough". What's the Best Practice here? Meds? Diet and exercise? Immediate surgery? It clearly depends on the context--other symptoms, the pervasiveness of the cough, the reasons behind the cough, and so on. Doctors who fail to establish the Context before offering a Solution are often called Quacks... or sued for malpractice.

He goes on to say, "Although some things that don't exist can be useful as rhetorical signposts, "best practice" is not one of them. There is nothing honorable you get from pretending that a practice is best that you can't also get from suggesting that a practice may be good in a specified context, and making a case for that. Sure, there are dishonorable things you can get from "best practice" rhetoric-- say, causing a dull-witted client to give you money. If that has tempted you in the past, I urge you to reform." Unfortunately, the temptation is too strong, particularly for those who are pushing a new platform upon the world. Java got tremendous success from pushing patterns rather than canned solutions (and I think we pushed too many patterns, not enough practices, to be honest), and so now it seems a requirement for any new platform that in addition to the platform, you need to have an established set of practices with it to help guide the newbies to the platform. After all, how comforting does it sound when somebody seeking to sell you on a new platform, when asked "So how do I use this thing best?" turns to you and says, "We really don't know yet since there's not a critical mass of people using it yet"?

"It has a chilling effect on our progress as an intellectual craft when people pretend that a best practice exists. Best practice blather becomes a substitute for the more difficult, less glamorous, but ultimately more powerful idea of learning how to do your job. By "learning" I mean practicing the skills of identifying and solving patterns of problems we encounter as testers. Of course, that will involve patterns of behavior that we call "practices". I'm not against the idea of practices, I'm against pretense. Only through pretense can a practice that is interesting in a particular context becomes a "best practice" to which we all must bow down." Again, I'm fond of the patterns terminology here, because it clearly highlights the problem he's stating here: if we think we have a "Best Practice" to a particular problem, in other words, making it a two-part tuple, it becomes a deceptively simple list: we only need state all the Problems, and the Solutions will be apparent, since when would you choose not to use a "Best Practice"? When you list it out as a four-part tuple: Problem, Context, Solution and Consequences, it becomes more clear that a particular Problem doesn't have one "Best Practice", but depends entirely on Context and desired Consequences.

I would challenge anyone to name a "best practice" for which there is no situation which makes the "best practice" a "worst practice". To use James' example:

"A doctor who prescribes a drug without examining the patient is committing malpractice. Isn't that obvious? Would you respect such a doctor? Why should we respect people who prescribe practices without regard for the problems faced in a project? The answer comes back, "What if the doctor tells you to eat right and exercise?"

People often cite EJB as a terrible technology. Bullsh*t. People who do that are missing the point. (Even Rod Johnson agrees with this point, or at least he did in a private conversation at The ServerSide Symposium in 2004.) The problem with EJB was that it was highly oversold: another case of "best practices" gone awry--most projects don't need EJB, despite the advice from EJB vendors. (Hmm....) EJB offers a much simpler programming model when dealing with two-phase commit programming against transactional resource managers, particularly given the context of seeking something industry-standard (for fears of new programmers having to burn all kinds of ramp-up time when they're hired). That's not really the problem space that Spring seeks to solve. (Leaving the reader to perhaps realize that maybe there's a place for both Spring and EJB in the world?)

Why the frenzy to use the term, if it has so many things wrong with it? Easy: "Best Practices" are easy to sell. Who wouldn't want to hire somebody who practices only "Best Practices"? Who would want to hire somebody who doesn't? It's an easy term for managers and HR practitioners to latch onto, and this is why most of the time you see unsophisticated speakers and tech leaders climbing all over themselves to use the term. Come on, admit it, which title sounds better and more "bang for your buck" at a conference? "J2EE Best Practices" or "Patterns of J2EE"? Most developers will pick the first, every time. And, worse yet, not realize they're being sold a bill of goods.

If you find yourself tempted to use the term, stop and examine your rationale for doing so. Are you really asking somebody what the best way to use something is, without regard to context? Or are you implicitly seeking to push your own agenda? As a speaker, I routinely get questions like, "Is it a best practice to ... ?" that are followed up by, "But what about when ....?", in essence seeking to know if I change my advice when the Context is different than what they think I'm thinking about. And usually, yes, it does.

Challenge to the reader: the next time you see somebody use the term, "Best Practice", ask yourself (or them) if you can come up with a situation (a Context) where it would be a "Worst Practice" instead. If you can't, or if they can't, it's probably indicative that you--or they--don't quite "get it" yet. Or, more likely, that they've just never seen a situation where it wouldn't be applicable... which then makes me question exactly how much this particular practice has been used. Think it's a silly exercise? Almost all of the great technology books in our industry have either explicitly or implicitly brought this point to the forefront of the book, even to the point where the contradict themselves sometimes. Still not convinced? Then how about this: after you can begin to see the separation between Problem, Solution, Context, and Consequences, you may be able to stop listening to "experts" and start making up your own mind.

Context matters.

Elliotte Rusty Harold blogged about the WS-Addressing specifications reaching Candidate Recommendation status, and did a bit of editorializing along the way:

These specs are seeing some serious pushback within the W3C. The problem is that there already is an addressing system for the Web. It's called the URI, and it's not at all clear that web services addressing does anything beyond URIs do except add complexity. In fact, it's pretty clear that it doesn't do anything except add complexity.

Here's the problem. Web Services Addressing "defines two constructs, message addressing properties and endpoint references, that normalize the information typically provided by transport protocols and messaging systems in a way that is independent of any particular transport or messaging system." In other words this is another example of the excessive genericity problem, just like DOM, and remember how well that worked. One of the big fundamental problems with DOM was that they tried to develop an architecture that could work for all conceivable programming languages; but developers don't want and don't need an API for all programming languages. they want an API that's tailored to their own programming language. This is why language-specific libraries like XOM and Amara are so much easier to use and more productive than DOM.

Web Services Addressing is trying to define an addressing scheme that can work over HTTP, SMTP,