164 posts tagged with "tech"

Many of the recommendations Dr. Brooks makes in this work can seem outdated at first glance; however, it does not take much to bring them into today's software development environments. Take the telephone log for example:

"One useful mechanism is a telephone log kept by the architect. In it he records every question and every answer. Each week the logs of the several architects are concatenated, reproduced, and distributed to the users and implementers. While this mechanism is quite informal, it is both quick and comprehensive." (p69)

Aside from being a fascinating inside-look at some of the challenges faced by the mainframe programmers of the sixties, The Mythical Man-Month presents many lessons-learned that are no less applicable today. This is the second article in a series exploring some of these lessons, in particular: conceptual integrity.

When last I worked with C++, it was while working on my master's thesis ten years ago, using a basic text editor in a Red Hat Linux 5.0 installation. A new task in front of me: replace a Reporting Services report, which was exporting to CSV, with a new solution that will allow me to create multiple files, with max 150,000 records each. The first challenge is speed: with that many records, only bulk copy will be reasonable. The second is splitting the file. I thought about calling BCP from a C# process, because unfortunately managed code only offers bulk loading into a SQL Server database, not from database to file. But C++ is another story, thanks to the Bulk Copy Driver Extensions made available by Microsoft. So, time for a C# developer to brush up on C++, and learn it the Visual Studio way!

Dr. Brooks is my new… well, I can't think of an appropriate noun. Certainly not a deity. One book does not make him a favorite tech author. Static text cannot make him a mentor. Maybe tech hero?

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

1. handle changing requirements,
2. deliver prototypes and/or working code frequently,
3. 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), e.g. before doing anything else, I write something like…

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

This got me thinking: why don't we ever use unsigned integers? Seems like having 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.