Coding Horror

I have no problem with XML. It's a fine way to store hierarchical data in a relatively simple, mostly human-readable format. But I've always disliked its companion technology, XSLT. While useful in theory-- "using a simple XSLT transform, XML can be converted into anything!"-- in practice, it takes painful contortions to do anything practical. Evidently I'm not alone; Martin Fowler hates XSLT too:

All of this site is written in simple XML documents and transformed to HTML. I find this works really well, and means I never have to worry about dealing with HTML formats. (Not that fancy layout is my style, as you can tell.) I've even written a whole book that way.

For most of this time I've used XSLT as my transformation language. I've got pretty good with slinging XSLT around and getting it to do what I want.

But no more.

When I wrote the software for this Bliki (on a long flight) I did it in Ruby. Prior to that I used Ruby to do a new version of my home page. My conclusion from this exercise was that using Ruby for XML transforms was much easier than using XSLT.

I've had almost the same exact argument with a few developers I used to work with. After working through a bit of the XSLT necessary to accomplish something, I concluded that it was easier and simpler to use procedural code to do the same thing. Not always, of course, but most of the time. As Fowler points out, this does beg the question: what good is XSLT?

I think this may raise some real questions about XSLT. There's still much I like about the power of XSLT, but I hate the syntax and the walls you keep running into. I'm not going to convert my whole site over to Ruby tomorrow - most of the XSLT works fine - but I can certainly see my way to doing that at some point in the future. But the bigger question is whether you're better off with scripting language for this kind of task than XSLT.

Maybe the idea of XSLT transforming XML into "anything" is fundamentally unrealistic-- just more Write Once, Run Anywhere snake oil.

I'm currently working on a project where almost every function has its own region. At first I found this convention onerous, but as I used it, I saw why it was necessary. The default Visual Studio .NET outlining support leaves a lot to be desired. Take your typical commented Page_Load method:

/// <summary>
/// This method is called when the Page's Load event has been fired.
/// </summary>
/// <param name="sender">The <see cref="object"/> that fired the event.</param>
/// <param name="e">The <see cref="EventArgs"/> of the event.</param>
private void Page_Load(object sender, System.EventArgs e)
{
if (!Page.IsPostBack)
{
// do stuff
}
}

That function will outline in two blocks: one for the XML comments, and another for the actual code itself:

It's aggravating that there is no built in support for outlining the entire function and the comments. Hence, the need for a simple region around the comments and the function, which provides the outlining support you might expect in the first place:

I just checked, and VS.NET 2005 (aka Whidbey) has this same bad behavior. What a bummer. I am working on a macro that Region-izes all the functions in a file, but in the meantime you might want to check out the Documentator macros on CodeProject. They combine commenting and regionizing into one function, which isn't always what I want, but it's close enough to start.

I use POPFile bayesian filtering to keep email spam at bay. With a little training, this works amazingly well-- I'm at 99.8% accuracy, and that's with a little over a month of "training" precipitated by a recent server migration. But bayesian filtering has one big weakness that I'm seeing more and more: spoofed emails.

You know what I mean-- emails titled Your Account Has Been Violated from, ostensibly from service@paypal.com. The body is a direct cut and paste from a real PayPal email:

Security Center Advisory!

We recently noticed one or more attempts to log in to your PayPal account from a foreign IP address and we have reasons to belive that your account was hacked by a third party without your authorization. If you recently accessed your account while traveling, the unusual log in attempts may have been initiated by you.

If you are the rightful holder of the account you must click the link below and then complete all steps from the following page as we try to verify your identity.

Of course, the spoofer is desperately hoping you won't notice that the crazy URLs in their email ..

http://paypaldemo.com.previewyoursite.com/source/service/ema/helpextsourcepage/PaypalISAPIruhttp3A2F2Fmyebamcom3A802Fws2FeBayISAPIdll3FMyeBay26ssPageName3DH253AH253A/
http://ebay.doubleclick.net/clk;13012399;10693575;h?http://cardsavetransfer.com/cmdr_login/index.htm
http://ebay.doubleclick.net/clk;13012399;10693575;h?http://paypalcardstraznact.com/cmdr_login/index.htm

.. aren't actually pointing to paypal.com (or ebay.com), and you'll key in your account and password on their servers.

These spoof emails contain so-called "kryptonite" because they so closely mimic actual emails from PayPal with valid words and phrases. Bayesian filtering is useless against this type of spam; if the spammer knows what any email in your actual inbox looks like, he can construct one that will beat any Bayesian filter. This is a a strict requirement at the very heart of bayesian filtering itself; any knowledge of valid contents (eg, things that "get through") has to be strictly eliminated.

I usually just delete these emails from my inbox; what else can I do? One thing is for sure: popular web-based services can no longer communicate via email with their customers. That's like giving spoofers a free pass; once they have the "template" email they can copy and paste it into a spoof email that is almost guaranteed to get past bayesian filtering for users of that service.

eBay, for example, has almost given up altogether on email communication. You have to visit eBay.com and check your web-based "message center" to communicate with them. I can't say I blame them; what other choice do they have?

The anonymous mini-microsoft blog has a fascinating entry on the pitfalls of Microsoft's curve rating system:

I totally accept that we need to have a rating system, especially to reward our kick-butt super-contributors who end up doing most the hard work around here. I have not, however, come to accept the bucketing rating system we employ, especially around the 3.0 review score. Now then, I have met dev managers who have reached acceptance with our system and with dolling out the 3.0s. In their presence, I experience a cult-like allure to these folks as they tell me how they are totally behind the peer relative 3.0 review rating and that's how we do business in managing our performers. They make it sound so calm and simple that I feel like if I could just drink up that Kool-Aid I, too, could not rip myself up inside over this.

I touched on this briefly in managing with trust. Performance metrics are useful, but only privately to the person who is being measured. The minute you make these performance metrics available to the manager as anything other than a sanitized average, you've turned them into a self-defeating cudgel to beat people into submission. I know, it seems like a logical idea-- measure and reward performance-- but there's tons of data supporting the harm this does. Peopleware goes into great detail on this; without belaboring the point, for best results, forget the bonus.

"Do this and you'll get that." These six words sum up the most popular way in which American business strives to improve performance in the workplace.

And it is very popular. At least three of four American corporations rely on some sort of incentive program. Piecework pay for factory workers, stock options for top executives, banquets and plaques for Employees of the Month, commissions for salespeople -- the variations go on and on. The average company now resembles a television game show: "Tell our employees about the fabulous prizes we have for them if productivity improves!"

Most of us, accustomed to similar tactics at home and school, take for granted that incentives in the workplace are successful. After all, such incentives are basically rewards, and rewards work, don't they?

The answer, surprisingly, is mostly no. While rewards are effective at producing temporary compliance, they are strikingly ineffective at producing lasting changes in attitudes or behavior. The news gets worse. About two dozen studies from the field of social psychology conclusively show that people who expect to receive a reward do not perform as well as those who expect nothing. This result, which holds for all sorts of rewards, people and tasks, is most dramatic when creativity is involved.

I suppose this only works for software development if you consider it a creative activity, but the arguments against the use of rewards are quite compelling:

• for every reward, there is the lack of a reward, an implicit punishment.
• rewards discourage cooperation and encourage competition.
• rewards are one-size-fits all approach that ignores causality.
• rewards deter risk.
• rewards undermine interest by focusing on the reward rather than the process itself.

Scott Mitchell says the best new ASP.NET feature in VS.NET 2005 is the integrated webserver. I agree. No more ditzing around with annoying IIS dependencies and install issues: aspnet_regiis, anyone? Tight coupling of VS.NET to IIS is also number three in K Scott Allen's worst of the .NET 1.x years. Good riddance IIS, hello Son of Cassini!

Unfortunately, we're still stuck with VS.NET 2003 in the meantime, and Windows XP's IIS 5.1 is thoroughly crippled out of the box. It allows only one root website, and a maximum of ten concurrent connections to that website. Microsoft really, really doesn't want us hosting slashdot.org on our XP Pro box. These limits are so aggressive that they can get in the way of legitimate localhost development. But there are workarounds.

1. Increase the 10 concurrent connection limit
   
   Are you getting 403.9 "Access Forbidden: Too many users are connected" errors on an XP Pro website? You're limited by default to 10 concurrent connections by design, but this can be increased. First, make sure your default windows script host is set to the console (cscript.exe) one.

   cscript //h:cscript
   

   Next, let's increase the connection limit to 40.

   C:InetpubAdminScriptsadsutil set w3svc/MaxConnections 40
   

   Note that this is a hard-coded limit; it can't be increased any further unless you like patching windows system files. You can, however, make the IIS connection timeout more aggressive so connections don't last as long.

2. Run more than one root website
   
   IIS 5.1 only allows one root website. This is fine if your websites run under subfolders:

   http://localhost/MyWebsite1
   http://localhost/MyWebsite2
   

   But it's kind of a pain if your websites must run as root, or need to be tested when running as root:

   http://MyWebsite1/
   http://MyWebsite2/
   

   In that case, you'd have to edit your hosts file, and switch the default home directory for the default website. But there's a better way. You can hack up multiple web sites in IIS 5.1 via command line tricks, or you can use this nifty little GUI utility which automates that for you. It works great-- you'll even see multiple websites show up in the IIS manager. But bear in mind that, unlike the server versions of IIS, only one website can be active at any given time.