Quick Data Access Layer

While trying to find information on what exceptions a table adapter could throw, I came across this blog post from Scott Guthrie on how to build a data access layer with XSDs in Visual Studio 2005. It’s a nicely-done set of tutorials with plenty of explanations and screenshots. I’m particularly interested in tutorial 8, which describes how custom code can be added (via subclassing or with partial classes). I’m responsible for one application that could probably make great use of this technique.

One of the concerns this technique raises is tight coupling with the database.  An older article by Brian Noyes provides a comparison between strongly-typed datasets and custom business objects that covers the issue quite well.

The Obsolete Attribute

One of the consultants I work with told me about an alternative use of the Obsolete attribute last week.  Its original intent was to identify methods and classes that shouldn’t be used anymore.  But using this:

[Obsolete(“”,true)]

turns out to be a rather nice refactoring tool as well.  Passing “true” as the second parameter instructs the compiler to flag all uses of a method or class so decorated as errors.  So far, this practice has helped me hunt down the one instance in code where a particular method was used.  Today, I should be able to eliminate an unnecessary custom exception class with it.

Don’t Derive from ApplicationException

According to this blog entry (or rather, the annotations), deriving from Exception is the correct course to take. ApplicationException apparently doesn’t provide any discernible value. Coming from the folks who actually built the .NET Framework, that’s quite a surprise to me. I can’t think of any example I’ve seen from Microsoft (or anyone else) on exceptions that doesn’t derive from ApplicationException.

A quick look at my office bookshelf confirms that this guidance is even older than the blog post. In Applied Microsoft .NET Framework Programming, Jeffrey Richter writes the following on pages 410-411:

“… I don’t think there is any value in having the SystemException and ApplicationException base types in the exception hierarchy.  In fact, I think having them is just confusing.”

Hackers and Fighters

I found this post on “street programmers” and computer scientists quite interesting because I manage a staff where the former outnumbers the latter significantly. In this environment, his conclusion that the street programmer is better than the CS graduate is wrong. The staff that have formal training consistently deliver higher-quality results when compared to the street programmers. The code they produce is easier to maintain and better-tested.

Mark Tarver’s definition of street programmer is the exception, not the rule, when it comes to people who write software for a living. It doesn’t include the people who got into this line of work because of Internet bubble; people who did it because they saw dollar signs rather than out of a genuine interest. I believe the person who self-teaches well is quite rare indeed.

I can’t dispute Tarver’s points about the state of computer science education. Far too many of them have been confirmed by friends of mine who are in Ph.D programs now. He’s certainly right about the conservatism of CS courses too. I still remember learning Pascal in the early 90s as part of my CS curriculum.

Even with the shortcomings of today’s computer science departments, the degree still serves as a useful filter when trying to decide if an interview with someone is likely to be time well spent.  I’ve also encountered enough good programmers in my time with degrees in math or physics that I’d certainly hire them if they interview well enough.

.NET Progress Bar

I’d managed to avoid all .NET WinForms work of any consequence until today.  We’ve assigned one of our developers to fix an application in need of a working progress bar.  Since I haven’t done this before today, I’m scrambling to get up to speed on the right way to do this.

This article looks like a good place to start.

Microsoft vs. Open Source–Don’t Worry

That’s the gist of this rather comforting post at groklaw.net about Microsoft’s claims of Linux patent infringement. It baffles me that a company which made over $12 billion in profits last fiscal year would stoop to the sort of patent trolling last seen from SCO Group.  It seems desperate.  It’s the kind of move I would expect from a company who had clearly lost the battle in the marketplace and didn’t have any other cards to play.