GenXJamerican

Scott Westfall, a member of the SlickEdit development team, weighs in with three “theorems of programming languages”.  The second theorem (If programmers do not understand a piece of code, they will either break it or rewrite it.) is definitely, and painfully true.

There’s a Codeplex project that enables developers to use their Subversion clients with Team Foundation Server (TFS). It’s certainly an interesting project, though I don’t quite grasp the rationale. TFS is really expensive, so if a shop can afford it, they can afford Team Explorer too.

I found out about initially via TheServerSide.NET.

This piece by Martin Fowler interests me more for his contention that the best technical leaders are abandoning .NET than for what he writes about Ruby. It’s the sort of argument that seems true because anecdotal evidence seems readily available.  I’d be interested to see if there’s more quantitative backing for the assertion.

Some poking around on Google did reveal at least a couple statistics:

• Computer language use by projects in SourceForge (9/2000-2/2006)
• Programming Language Popularity

Apparently this is where Visual Studio 2005 stores connection strings when you add strongly-typed datasets in an application.  Even though I had an app.config file and I’d changed it to point to a new database, I was still getting SqlExceptions when I ran my unit tests.  I just didn’t know the old value was still stored in Settings.settings and needed to be updated.

I don’t do much WinForms work.  So when I was trying to find out how to get the equivalent of ASP.NET validator controls for WinForms, this article by Michael Weinhardt was a great find.

We still use Visual SourceSafe at my job for version control.  I inherited the administrative duties (for one VSS database and a TFS installation) after one of my colleagues left to join a startup.  We found a legitimate need for its “shadow folders” functionality not long ago, and finally implemented them this morning.  I came across this page when figuring out the particulars.

This list comes courtesy of Patrick Cauldwell, an architect at Corillian Corp.  I’m definitely in favor of most of their list, especially test-driven development, continuous integration, and buy vs. build.  I’m not so sure about the Windows authentication point simply because it takes so much effort to get developers access to our databases at work.

I asked a group of consultants currently working in my office for advice on which FxCop rules were actually applicable to our environment.  One particularly useful piece of advice was to consider whether or not unknown people or applications would be using what I’d written.  It allowed me to disable the following rules:

• Mark assemblies with CLSCompliant.  Since there won't be any third-party users of the assemblies I ran FxCop on, that rule can go away.
• Mark assemblies with ComVisible.  The same argument as above applies to this rule.
• Assemblies should have valid strong names.  Once we get certificates, we would reactivate this rule.

Eric Sink wrote this post in favor of code coverage.  I wasn’t terribly familiar with the concept before two years ago, and my current job is the first one where I’ve seen such tools used seriously.

The best applications our organization puts out (correctness, performance, ease of maintenance) are the ones that have unit tests.  The application I have the most confidence in though, is the one that has code coverage.

I’m trying to develop that habit for the code I write, so I can be a better example to the team I manage.

Eric Sink’s post on requirements is the best and most concise treatment of the subject I’ve read yet.  The document vs. database treatment of requirements and his comparison of traceability to a compiler are inspired.  He even touches briefly on the shortcomings of bug-tracking systems as requirements management systems.

I haven’t read the book he recommends in his post (Software Requirements, by Karl Wiegers), but I have no doubt that it’s good.  The book on requirements that I can vouch for is Exploring Requirements: Quality Before Design.  It has tons of great advice on the process of gathering requirements. If you analyze, design, build, and/or test software, read Eric Sink’s post.  If you manage technology projects, you should definitely read it.  Highly, highly recommended.

They’re ok if all you want to do is display data in a GridView control (and sort it, page it, etc). They become a pain in the neck the moment you actually want to modify data. The only I could get modifications to work is was by naming the parameters of your class methods exactly the same as the table column names (I’m using strongly-typed datasets in this application). I suppose it’s not so bad if you’ve named the table columns sensibly. But the database I’ve inherited doesn’t have this property.

What’s worse is the error messages you get when you haven’t configured something correctly. You get an entirely unhelpful message like “ObjectDataSource could not find a non-generic method that has parameters”. The number of search results for that phrase should have clued me in that this control was sketchy.

That’s one of the drawbacks of these new controls from Microsoft. They’re supposed to be better than code you’d write yourself–but God help you if they don’t work and you have to figure out what’s wrong. It’s not like you can debug them.

I came across this opinion on software patents via the programming reddit.  It makes a great for why software patents are a problem without even mentioning Microsoft’s foray into patent trolling.

Stallman makes an interesting proposal for a new software-only form of intellectual property (IP) at the end of the piece.  Unfortunately, I don’t think it would survive the gauntlet of legislators (and lobbyists) to become law.

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.

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)]

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."

Say you have a user with no password question and answer. It turns out that calling ResetPassword() on that user will throw an exception. There’s an overload that takes password answer as a parameter, which also throws an exception if the wrong answer is provided.

The way to get around this issue for me turned out to be changing “requiresQuestionAndAnswer” to “false” in the membership provider configuration.