GenXJamerican

I came across this James Avery post via Mike Gunderloy’s blog.  Avery attempts to make a similar point to one Martin Fowler puts forward about the best developers moving away from the .NET platform.  Beyond the sort of anecdotal evidence I’ve read, I don’t see much abandonment of .NET as a platform.

When I read this post by Dave Laribee, I decided that Avery missed his point.  The point of ALT.NET isn’t as a bridge to a different set of tools, but to recognize two things:

1. The best solutions on the .NET platform won't always come from Microsoft.
2. The best ideas from other software development communities can work very well on the .NET platform.

I learned an annoying lesson about these late last week.  I’d created the dataset by dragging and dropping the necessary tables from SQL Server in Visual Studio 2005.  Then I added a query to one of the tables that didn’t include every one of its columns.  Unfortunately, a number of the columns my query didn’t return didn’t allow nulls.  I ended up modifying my query to include those columns, even though I don’t use them.  I didn’t try removing the columns from the dataset, but that probably would have worked too.

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.