Technical Musings

Currently I'm working on updating the main blog at safnet.com with a refreshed look and feel (the design was last changed "way back" in 2008), then I'll move on to this technical blog. In the meantime, this garish built-in template will serve to remind me that work needs to be done.

New tech-blog entries have been rare primarily because I have been spending much of my technical-writing time on internal documentation at work: trying to build-up a thorough set of documentation in a SharePoint Wiki. Most of that content is proprietary, and would not be useful outside the company anyway. But I do hope to start posting comments here again soon, starting with a few entries after recently reading the classic The Mythical Man-Month.

Microsoft's Books Online article on SQL Injection does a great job of reviewing the possible attacks against dynamic SQL statements (using EXEC or sp_executesql). I won't re-hash their discussion and suggestions. What I offer below is a sample remediation effort for this set of statements (the @Fields and @Values variables are actually stored procedure parameters):

DECLARE @Fields VARCHAR(1000), @VALUES VARCHAR(1000), @SQL NVARCHAR(2500);
SELECT @SQL = 'INSERT INTO MyTable (' + @Fields + ') VALUES (' + @Values + ')';
EXEC(@SQL);

Recently, I received a code delivery that worked on our development server but failed in unit tests on my box. The culprit was a method that transformed a List<T> into a DataTable and used that DataTable to load data into SQL Server using SqlBulkCopy. Lesson: apply column mappings.

Fundamental Modeling Concepts: Effective Communication of IT Systems by Andreas Knopfel
My rating: 3 of 5 stars

I have mixed feelings about this book. I've spent several years working diligently on my flow-charting capabilities, using what scan resources I could easily and quickly sift through on the Web and in the Visio Help, studying the charts in all the comp-sci books I've read, and garnering feedback from my colleagues. This book might have sped up that process significantly, and has already had a positive impact on the communication efficacy of my charts. But, I simply didn't completely like the specific modeling "language" presented by the authors.

A friend just wrote to me, asking about agile. He's been seeing software job posting with the vague request/promise of "agile" in them, wondering what the big deal is. Initial reaction: if no specific methodology or agile principle is cited, then at worst they are glomming on to pop culture, at best they want to make sure you can (a) handle changing requirements, (b) deliver prototypes and/or working code frequently, (c) take an iterative approach to documentation, coding, and testing.

"Being agile" means both that you aren't going to freak out at the lack of a locked-down, step-by-step waterfall process, and that you aren't going to go cowboy and give the client a product at the last minute, with no conversations or demonstrations between the initial requirements "gathering" and delivery.

I’m writing a class with several methods that take integer input. The input values cannot be less than zero. Since we’re not on .Net 4.0 yet, I’m manually writing code contracts (that is, my functions check preconditions, i.e. before doing anything else, I write something like…

if (sequenceNumber < 3)
{
throw new ArgumentOutOfRangeException(
"sequenceNumber", "Sequence number must be 3 or greater");
}

This got me thinking: why don’t we ever use unsigned integers? Seems like have a uint would better communicate the requirement, and would simply not allow a negative number. The main answer seems to be that casting between uint and other data types, which is inevitable, is ugly. And that uint is not CLS compliant. Even though I’m not trying to write CLS-compliant code at the moment, I think I’ll stick with int – because that is our existing convention, and I don’t see enough reason to change the convention.

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.

"global temporary tables are visible to all sessions," says the MSDN documentation. I have occasionally wondered when this would be helpful. This week I finally found a use, albeit limited: I want a quick-and-dirty process that will e-mail a CSV file to me every day for a week. I wouldn't do this for a full on production system (without dwelling on it, it just strikes me as too error prone and inelegant), but for some testing I want to do over the course of a week, it makes sense.

I run a query that populates a temp table, and I want to e-mail the contents of the query using sp_send_dbmail. Again, the documentation tells something important: "Note that the query is executed in a separate session, so local variables in the script calling sp_send_dbmail are not available to the query." This applies not just to a table variable, but also a local temp table (i.e. #temp). But a global temp table (i.e. ##temp) is a different story: works just fine. So there you go, quick and dirty way to e-mail yourself some query results when you don't want to just pass the raw query directly to the send command.

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.

I wonder how many others didn't think to scroll down further on the Pex download page, and find this link? Visual Studio 2010 Moles - Isolation Framework for .NET. Moles is available for free, while the full Pex environment requires MSDN.