One of my team members sent in the following piece of code, which is clearly
intended to update the OrderNumber field for all objects in a
List<T> of
objects that match a particular productId. I took one look at it and thought
"you can't do that!". But then I let the automated test run to see what
happens... lo and behold, it worked. And well it should, once I thought about
it.
Coding Horror, almost two years back, christened a name for the principle variously known as "don't repeat yourself," "once and only once," etc.: Curly's Law. Excellent formulation of the principle. In sending this to my development team, I thought it would be useful to pull this from the abstract to the specific through a few questions:
Lately I've been working with my team to understand and utilize good automated unit testing strategies with NUnit. A code release I was inspecting revealed a couple of good points that seem worth expanding on: the importance of testing each layer, and the need to pay attention to code coverage. This is a rather facile treatment; for more in-depth reasoning and details, I recommend xUnit Test Patterns.
Something I was reading this weekend pointed out that leaving braces out of a one-line block can be dangerous. For instance, it is correct to code the following (and I do it all the time!)
if (someCondition)
this.doSomething();
We had a horribly pernicious timeout problem recently. It was occurring in a .Net 2.0 application written to retrieve reports from SQL Server 2005 Reporting Services via its web services interface. The query behind the report was a bit large, but typically would run under 30 seconds. We had judged that new indexes were out of the question because of their impact on the already slow program that loads the key data. All of the sudden, we started getting continuous timeouts. After a couple of days, the underlying query was up to 15 minutes execution time!
In the end multiple interacting problems had to be solved in order to get the reports running properly. For the past few weeks they've been running without a hitch.
I once read that .Net's String.IsNullOrEmpty
performs better, and is safer, than just checking to see if a particular string
has an empty value. I.e. replace if (myString == "") or if (myString.Equals(string.Empty)) or if (myString.Length == 0) with if (String.IsNullOrEmpty(myString)). It is certainly easy to read, and points out
that the string should really be checked for null value before doing anything
else.
you have an application that needs to trigger some process via SQL Server but don't want your main process hung up waiting. So you decide to setup Service Broker in order to make an asynchronous call, with the receiving service doing your work for you. You've read all about it, and tried it out after hours, but it didn't work. What gives?
You have a long-running query in SQL Server that is causing failures all over the place. Activity Monitor shows you the cause is blocking.
Causes: Blocking essentially means "you've locked a table, and now someone else is stuck waiting for you to unlock it." We all know (or should know) that transactions cause table locks, and thus blocking. That's one reason that transactions need to be short and sweet. But there is another source of blocking, one that can be a bit more subtle: long-running queries that are trying to read committed data only.
I've been having problems migrating some SSIS packages from localhost (32bit) to
the server (Windows Server 2003 64bit, SQL Server 2005 Enterprise SP2). These
packages have Excel data connectors, and hence must be run in 32 bit mode. When
I try to run them with the 32bit dtexec, I get the "generic" error "the package
failed to load" (0xC0010014). I stripped down the package until I found the
source of the error: a ForEach container, using the File Enumerator with the
directory set to a variable. When I remove the variable setting it works, when I
add the variable expression it fails. Note: this does not fail in the 64bit
dtexec.
A few weeks ago I started trying to better understand the concepts behind service oriented architecture (SOA), how I can apply them to my work, and if doing so is actually a good idea. When I first started hearing about SOAP years ago, I understood it as an alternative to objects — you build and consume services instead of objects. This sounds great for highly distributed environments, but also sounds like a performance nightmare in a business environment that does not need distribution. So I largely ignored it, and assumed I could ignore SOA as well.
