September 27, 2006

Another .NET spammer

There used to be a time when spamming was limited to mass sales articles. Viagra and things like that have an immense marketing potential, and at least I could convince myself to believe that the spam-based sales originated from less advanced home users who didn't realize the global impact of the economy they were feeding. My beliefs have suffered serious blows. Although majority of the spam is still aimed at mass markets, there's been more targeted stuff too.

Today an ad from a French software company called Novalys managed to squiggle through my double spam filters. It says "Dear .NET user" at the beginning, and is sent to my email address used exclusively for newsgroup postings. The signature even says "Microsoft partner", and the footer assures "You're receiving this email because we thought you might be interested in VG news"... Well thanks, but you're obviously mistaken. While something called Visual Guard certainly sounds interesting, I don't need it.

Well, what can I say? Avoiding dealing with organizations that rely on destructive marketing measures is something I can do. I wouldn't place my spam ethics before a customer's benefit, but in a 50-50 situation I'd definitely tip the scales against somebody who blatantly ignores the Internet rules of conduct (and some legislation, too). I hope many of you will do the same as well. Software developers need not support this sort of dark economy. Truly excellent products have many great - and free - advertisement channels already.

Posted by Jouni Heikniemi at 07:57 AM | Comments (7) | General

September 20, 2006

Refactorability is not an excuse for bad code

According to Wikipedia, "Refactoring is the process of rewriting a computer program or other material to improve its structure or readability, while explicitly preserving its meaning or behavior". Since the agile culture emphasizes refactoring of the code as necessary, it does set a new stage for code quality demands: How relevant is the initial quality of a code block? Can't refactorings be later used to "restore quality" as considered necessary? Is "high quality up front" an anti-agile beast on a level equal to "big design up front"?

"No!" screams the choir of agilistas. High quality has always been in the limelight in the agile methods community. The desire to use refactorability as an excuse for lowering the quality bar is cowboy coding, a mutilation of the agile ideals. In fact, quality is refactorability - only decent-quality code can be refactored, bad code must often be rewritten.

What is the true intended scope of refactoring, then? It is to avoid the need to build extensive hooks and abstractions for anticipated future needs. It is to enable flexibility that allows the design to adapt. All these ideals relate to changes in requirements or architecture, not to the quality preferences of an individual developer. If the main use of refactoring is reduced to making code conform to best practices or coding guidelines, many of the true benefits of refactoring are lost.

To summarize: Refactoring is not about using the rename pattern for fixing mindlessly named constants ("string s"). It is about turning a monolithic, bit-by-bit-grown customer object into a small class hierarchy to improve design. Be minimalistic, do what you need and only what you need - but do it with quality. If you see bad code, don't just accept "Feel free to refactor it" as an excuse - it's nothing but "I didn't care to do it properly" in disguise.

Posted by Jouni Heikniemi at 09:35 AM | Comments (0) |

September 18, 2006

"An error occurred accessing the website application data folder" in Virtual Server 2005 R2

I had a pretty grueling duel with a fresh installation of Virtual Server 2005 R2. The error message mentioned above popped up on the administration web site even though the installation was completed flawlessly. I also had "You do not have permission to access the event viewer" on the same page. All Google matches returned hits referring to installations on a Domain Controller or Windows Vista.

My problem was neither of the above. Rather, the issue was that my IIS web site wasn't configured to use Windows authentication. Apparently the anonymous user didn't have access to some directory somewhere on my hard drive, although I did try the Everyone / Full Control medicine on several directories. But configuring the site to use Windows Authentication did the trick. I'm just wondering why doesn't the installer do this... Or maybe it does? The installation did work fine for me on several other computers.

Hope the experience allows somebody to save an hour or two...

Posted by Jouni Heikniemi at 10:18 PM | Comments (8) |

September 13, 2006

"The handle is invalid" from an ASP.NET app

Some time ago we encountered a really strange problem with ASP.NET. A site that had worked properly under ASP.NET 1.1  suddenly freaked out. .NET 2.0 was installed on the server, but no settings were changed. At approximately this time the site suddenly broke down with a "The handle is invalid" error message. It was none of the usual ASP.NET error messages, it was just that text on a blank page.

Well, this was certainly something new! I'd never before seen an ASP.NET error message without a single HTML tag, just the text. Well, as it turns out, ASP.NET never even got started (there was no aspnetwp.exe for instance, but everything failed before that).

Reinstalling .NET didn't help, nor did the usual aspnet_regiis trickery. A new IIS site demonstrated the same issue. I was pretty stumped after some googling returned only a single useful discussion thread, which unfortunately provided no answers. Well, it was again the time to send our prayers downwards... wait, no, call the Microsoft Support.

As usual, they were able to help, but we were never particularly enlightened by the real reasons. After some diagnostics, removing and re-installing IIS was the proposed cure; a considerable effort on a server with several heavily configured sites, but we managed - and it worked. We - and I think this includes the support engineer - never got to know if the .NET 2.0 installation was to blame here.

Perhaps it's time to start considering heavier backup plans on 2.0 installations, at least on the most critical servers. It's certainly not common, but pretty nasty when it hits you. Well, at least I hope sharing the experience will save somebody the trouble  of discovering this (and a support ticket).

Posted by Jouni Heikniemi at 11:05 PM | Comments (1) |