82 posts tagged with "programming"

Stephen's first law of diagnosing problems in production should have been: make sure you actually know the scope of the problem. We have a process that checks for duplicates in an inbound file. Records marked as duplicates are not moved into production. A refinement of the process was installed this week. All the sudden, e-mails showed that thousands of records were being marked as duplicates. I came over to help investigate, and found people looking at code, trying to figure out what was going on, because they knew without doubt that these records were not in fact duplicates.

But we needed to step back and ask what is the scope of the problem? We looked at the e-mail with the duplicates, picked a name or two from the list, and looked in the original input files and confirmed that they were not in the files. So how/why were they reported? But then let's set that aside, and ask: did all of today's records make it into production? If yes, then we have a problem but not a crisis. The answer was yes: we could see a 1-1 match between inbound file and outbound production data. Therefore, we have a minor reporting problem, but the core of the system was working just fine. Panic averted.

So what was the cause? A staging table that had not been truncated after a previous file was processed. All those records were being reported as duplicates.

Stephen's first law of diagnosing problems in production: try to replicate in test. (Assumptions: you have a test environment, you use it regularly, and it is reasonably close to production). Sometimes you just can't replicate the problem — for instance, it might be due to an oddity in a customer data file that you're not allowed to run outside of production. In those cases, see if you can use a proxy. For instance, try copying the file and masking the sensitive data, then running it in the test environment (of course, the masking process might cover up the error that is causing all the problems).

Production needs to stay clean, and as developers we need to keep our hands out of it as much as possible. This is particularly true in a highly secure environment with strong separation of duties, wherein you might have to drag a sys admin into the picture just to get to obscure log files, for instance. Replicate the issue, solve it, document it, and make sure everyone else in the company is able to share in the lessons learned.

Can someone please tell me why Visual Studio 2010 no longer has the "Promote Local Variable to Parameter" refactoring? I use this every day. Thankfully CodeRushXpress has it, but the current version is a bit unstable, causing VS2010 to crash periodically.

I am using the latest edition of Service Factory - Modeling Edition (VS2008). I've created a number of FaultContracts in my DataContract model, and utilized them in my ServiceContract model. The generated code for the ServiceContract does not include the namespace or action for the FaultContract, e.g.

My team often starts Tuesday morning status meetings with a round of win/learn/fun - a team-building exercise where each person gets to mention an exciting "win", something they learned in the last week, or just something fun. Several weeks ago someone brought up C# Extension Methods as a learn. I could see the potential, but I didn't immediately think of any practical examples.

Problem​

You have an ASP.Net web service/site that needs to access network resources, and IIS is running in a service account that you do not want to have access to those resources.

Solution​

Create a custom network account and setup a separate application pool. Microsoft article How To: Create a Service Account for an ASP.NET 2.0 Application outlines some pros/cons and gives a few alternatives, as well as giving the basic instructions. However, I found that these instructions had to be modified with inclusion of a few extra security rules. Steps:

Here's a really dumb scenario that will illustrate a point about the usefulness of the "red, green, refactor" approach to testing and coding. Here's the functionality - need to test whether or not a string has a value other than 1. Let's say I write a method before any tests:

What's wrong with this code? There are unnecessary lines. So? Why care about unnecessary lines? Because it shows that the programmer was not really thinking about what he was doing.

MyObject obj = someList.Find(delegate(MyObject test)
{
    if (test.Id.Equals(packageId))
    {
        return true;
    }
    else
    {
        return false;
    }
});

We just upgraded our servers to support .Net 3.x, so at last I'm able to start migrating some of my code. I haven't taken a close look at all the features available yet, but one that caught my eye and initially excited me is automatic properties. However, I had two conflicting reactions:

1. This is great, I don't have to create a private field and write getter/setter in a public Property anymore.
2. But then what's the point of not just creating a public field and using it directly?

Well, this article addresses a primary benefit: this facilitates refactoring. If, for instance, we find later on that we need something more advanced than a simple get or set statement, then we can add it without breaking the interface. I'm sold.

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.