Bob On Development

I encounter this code very often when the intent is to remove multiple spaces from strings and reduce them to single spaces:
someString = someString.Replace("  "," ");
No, no, no. This will find all instances of two spaces and replace them with one, provided that the instances aren’t consecutive. In other words consider the following string, where spaces are replaced with periods for clarity:

FOO..BAR..FOO

The above code will reduce this to FOO.BAR.FOO as expected. But suppose we have this:

FOO…BAR…FOO

Now we get FOO..BAR..FOO. Uh-oh.

The only foolproof way is:
while (someString.IndexOf("  ",StringComparison.Ordinal) > -1) {
  someString = someString.Replace("  "," ");
}

The included StringComparison enum is optional and not relevant to this discussion but I throw it in there to remind you that if you’re not dealing with culturally sensitive strings, using Ordinal or OrdinalIgnoreCase comparisons is faster. And since you’re dealing with spaces, the very fastest possible Ordinal comparison makes sense in this case, even if the rest of the string may be culturally sensitive.

For some reason, I haven’t had to do this in a long time, so had to look it up.

There are three options for doing case-insensitive regular expressions in .NET.

The first is to use the RegexOptions enumeration to specify case-insensitive behavior:

Regex.IsMatch("Fubar","^fubar",RegexOptions.IgnoreCase)

The equivalent option is to put (?i) at the start of the expression. This is useful if you want to feed data-driven patterns to the matching engine and control from the expression whether it’s case insensitive or not:

Regex.IsMatch("Fubar","(?i)^fubar")

Lastly, you can put part of an expression in a group and specify that only that part is to be case insensitive. In this example, Fubar is matched case sensitive but FOO is not:

Regex.IsMatch("Fubar Foo","^Fubar (?i:FOO)")

My old friend Whil Hentzen, who is still somehow making a living in the FoxPro world with a side of Linux, posted a hilarious and enlightening explanation of Twitter, how it’s used in the real world, and why it might be necessary to indulge in even if you were born before dirt was invented.

I’m almost persuaded.

Insanely hilarious stuff — if you don’t “get” twitter you should definitely read it.

I’m fortunate to be paid well for doing something I love. But I know quite a few developers for whom software development is not a joy, but a job. Nothing inherently wrong with that, and in fact, I think it’s inevitable as the craft matures. Even so, I’m seeing a little too much of certain things lately, for example:

Try blocks with empty catch blocks. The legitimate uses of this little trick are so super-rare that we might as well say it’s Evil. Even when you do it temporarily it’s Evil because you inevitably forget to take it back out. Just cut it out, okay? I’ve seen code, for instance, that loads records into a database, where maybe 20% of the records vanish silently into thin air because some minor, easily fixable exception is masked. Don’t make me come over there.

Failing to do simple things to make code more robust. I’m getting a little tired of noobish code that concatenates date strings together and then parses them in the blissful assumption that the code will never be run under any locale other than en-us. It is no harder to just use the DateTime constructor, but people don’t do it because … why?? I really don’t know.

Have a little pride in your work. If you really don’t care … find something you care about and do that instead.

Thanks. Carry on.

In my last post I mentioned that powerful forces are working to bend software development to the needs of mass production. It’s only partially successful, compared to, say, the mass production of automobiles, but it’s successful enough to have a big impact already on software developers. Consider the following things we already do pretty much without thinking about it:

• Use a set-oriented query language that specifies what to find, not how to find it (SQL)
• Use designers to create user interfaces (e.g., WinForms, WebControls)
• Use code generators to produce the skelton of things like components, services, and data access layers.

Quite awhile ago in one of my most popular posts, I made gentle fun of the goals Charles Simonyi’s company, Intentional Software. I was very skeptical that Intentional would succeed in capturing business rules and requirements in a way that would allow useful, maintainable, performant, quality software to be generated from such a captured spec.

On the other hand, it is possible that Intentional’s initial blue-skying has been tempered enough by reality to reconsider. It certainly has Microsoft’s attention, because Oslo, their road map for the next release of Visual Studio (2010?) appears to contain very similar technology.

Indeed, some of Microsoft’s other trial balloons, such as Volta, seem to be heading towards similarly higher levels of abstraction.

It is incredibly ambitious to invent a world where you and I will be writing XML documents describing what an application does rather than how it does it. But Microsoft has the billions (and the brain trust) to pull it off, if anyone can.

That said (ahem) I’m still a skeptic. Is it just me, or is this description by Charles Petzold of a new XAML-like version of C# that’s apparently gestating over at Intentional just making matters worse? Petzold describes three simple lines of C# as a “notorious syntactical absurdity” and then replaces it with something he says “can almost induce the modern programmer to weep for joy”: 45 lines of XML! Lord have mercy.

I’m sticking with my mantra that I’ll look into these things when I can see that they make business sense. It’s not ready for prime time yet!

I read a post this morning about the “lack of craftsmanship” in software development. The basic argument in a nutshell is that the “lack of commitment to quality” is pushing the whole industry towards the “commoditization” of software development. In fact, the author feels that “the days of in-house software development as we know it are in danger of extinction.”

Despite the fact that I agree with the author that “commitment to quality” is generally weak and contributes to the problem, I believe that larger forces are the primary driver behind this trend. It wasn’t lack of craftsmanship, after all, that resulted in the success of Henry Ford’s mass production methods. It was the demand for quantity at the expense of fit and finish. And let us not forget that the mass-produced Model T was not better or even easier to use than many of the hand-crafted cars that preceded it. That didn’t stop it from being a success.

Closer to home, the success of DOS comes to mind. It was an adequate product at the right time and price point. I’m not pretending that this fact is appealing to me as a craftsman, but I have to acknowledge that is was a success nonetheless.

History is full of examples of new products, produced originally by craftsmen, and eventually bent to the will of mass production. It’s a basic, natural business and technology cycle issue any time you’re dealing with something that there is a quantity demand for.

We’re in a similar situation in the software industry. Business and government need software of all kinds more than ever, but we can’t produce and maintain / extend “good enough” software in the quantities and within the time frames that the world needs (or thinks it needs, which in practice amounts to the same thing).

The only thing that has saved custom software development at all is that software does not, and never will, lend itself to commoditization efforts to the extent that mass produced physical goods will. However, it lends itself to more commoditization than most developers give it credit for.

Consider humble VisiCalc, the first spreadsheet program. It was a metaphor that took the world by storm, simply by allowing a small subset of bean counting and statistical tasks to be performed by non-programmers. I submit to you that Excel 2007 has just taken spreadsheets to the next level, by the simple expedient of removing Excel’s old 65,535 row limit. Several versions back, Excel acquired some basic database functionality, resulting in much mirth amongst database developers as accountants and casual developers tried to make Excel serve as a crude “database”. The exponential growth of typical table sizes so that a table of over 64K rows is no longer considered huge or even hefty, has pretty much knocked Excel out of the competition for awhile. But suddenly, it’s back in the running again, with bigger capacity, better DB features, and with user-friendly features like pivot tables in place of SQL GROUP BY queries. And with multiple sheets, users are no longer limited to single tables, so we’re not just talking about a simple list manager substitute here. Add in the ability to read and write to real databases with greater and greater ease, and you have modern Excel “spreadsheets” doing more useful work than the custom applications of twenty (or in some cases, even ten) years ago.

Now of course the scope and reach of modern database applications has also grown, and it’s still way beyond what even the newly beefed-up Excel can cope with. But the point is, at the low end — where it doesn’t need to scale and where standard capabilities are “good enough” — there will always be a place where casual and non-programmers can get by without us. And what constitutes “low end” is constantly growing. Eventually, “low end” will probably encompass all the elementary things that a small to medium-sized business needs for it survival, and the projects that require actual skilled developers will probably be more and more esoteric.

I see no point in bemoaning this. It’s just the usual march of progress. It’s not up to reality to conform to us. We have to conform to reality.

The only question is in how we chose to place our bets. What will we educate ourselves about? What kinds of projects will be seek out? And with how much urgency?

One thing’s for sure. The world is moving too fast to imagine that the craft of development will look anything like it does today, some twenty or even ten years hence. It was possible for a developer to learn COBOL in 1965 and stick with it until retirement, provided you didn’t care about the bleeding edge or the top dollars throughout your career. But I very much doubt that C# or VB.NET or even the darling of the moment, Ruby, will be employing anyone at all come 2040.

That’s going to burn a lot of people in this business, because for all our embracing of computer technology ahead of the rest of society, we developers have a strong conservative streak in us. We become emotionally attached to certain platforms and even languages, and fight to the death to keep them alive. A lot of us find something that appeals to us aesthetically and want to stick with it because it becomes our identity. That’s not going to work any more.

I am currently responsible for a fairly large members-only web site that was originally authored in classic ASP years ago and has been partly migrated to .NET. One’s impulse is, of course, to move it to VS 2008 and then go about purging the last of the classic ASP stuff. However, this might be bass-ackwards.

A factor I hadn’t considered is that VS 2003 has built-in support for debugging classic ASP pages, and that this support was removed in VS 2005. So VS 2003 is arguably the place to be if you have a mixed classic / .NET site. You might want to finish porting the legacy pages and then upgrade to the current platform.

It is still possible, however, to debug classic ASP from VS 2005 (and I presume 2008) if you’re willing to manually attach the debugger, but it sounds too much like work to me. You can even cruft up a VS 2005 template so that classic ASP pages show up as a project type and/or file menu item. But you might want to give serious thought to porting the classic ASP pages to ASP.NET before migrating to the current version of Visual Studio. The only downside I can see of doing the port in VS 2003 is if you really, really need to use goodness from CLR 2.0 or later.

I had strange problems today with “Login Failed” messages from an ASP.NET application using SQL Server authentication. Mixed mode is enabled in the server; the user ID and password were correct; it wasn’t a remote connection and those were enabled in any case. Exact roles / permissions were identical between development and production. All the usual suspects covered.

Since it was only an issue connecting to my test development database, I finally said “getting work done is better than understanding what’s happening here” and created a new user and login, and changed my connection strings. Now it worked on one of the two databases, but not the other.

For security reasons, the exception that SQL Server raises isn’t very informative, just “Login Failed for User FUBAR”. But the information exists: it’s in the MSSQL\LOG folder for your SQL Server instance (C:\Program Files\Microsoft SQL Server\MSSQL.1 in my case). Sort that folder by date / time and grab the most recent ERRORLOG*.* file, which is probably just named ERRORLOG without an extension. Open it in Notepad and look for the error, and it will show you something along these lines:

2007-12-13 13:42:13.92 Logon Error: 18456, Severity: 14, State: 8.
2007-12-13 13:42:13.92 Logon Login failed for user ‘FUBAR’. [CLIENT: 192.168.170.159]

The key here is the State code. Code 8 indicates “Invalid password”. In my case, duh, I had fat-fingered an extra character onto the password in my web.config file and although I’d looked at it twice, I simply could not see it until I looked the third time.

How about the other possible state codes? Glad you asked. They’re here.

I could no longer put off some work on an ASP.NET 1.1 application so I fired up Visual Studio 2003 and immediately got the “specified web server is not running ASP.NET version 1.1″ error. This, despite the fact that ASP.NET 1.1 was set in IIS as the framework version for that app.

There are plenty of posts about this around the Net, and most of them tell you to either run aspnet_regiis -i (and/or aspnet_regiis -r) or to do some sort of time-killing mummery that involves uninstalling / reinstalling some combination of IIS, VS 2003, and/or the 1.1 framework.

I found only one passing mention of what I really needed: this error can also be caused if you either don’t have FrontPage extensions installed, or have inadvertently deleted some or all of the FrontPage folders (_vti_conf, _vti_pvt, etc) from the application root. Indeed I had blown away some of those folders. The solution is to fire up Add/Remove Programs | Add/Remove Windows Components, highlight Internet Information Services (IIS) and click Details, then uncheck FrontPage Extensions to uninstall it, then go through the process again, checking the Front Page option to reinstall it.

I have clearly died and gone to heaven. The reason I know this is because a couple of days ago one of the suits I work for asked me how long it would take to process 1.7 million records coming in from one of her customers. I told her 6 days to run it through my system.

As you well know this normally results in the revelation that the suit has already told the customer that they can have it tomorrow morning. It’s written somewhere in the union contract, I think.

But that didn’t happen. She wrote back and said she told the customer it would take two weeks because she figured she should give me more time in case there were unforeseen difficulties. That’s how I knew I’d died and gone to heaven. I must have died in my sleep the night before.

Being as I’ve died, I though you all might like to know what it’s like here in heaven.

The truth is, it’s almost exactly like earth, except that suits under-promise and over-deliver, treat developers with respect by expecting actual answers when they ask questions, that sort of thing.

Well, what did you expect? If the streets were paved with gold, gold would be commonplace and would have no value anyway. I’ll take humane, sane customers with reasonable expectations any day. You poor mortals will just have to put up with abitrary deadlines. But maybe this will give you something to look forward to.