In an ever more agile development world, we gradually learn to accept that requirements change constantly. Of course, it has always been thus, but I do remember a time when we pretended that requirements were locked and could not be changed. But then I remember delivering a product some months later which did not then meet the client's requirements despite what they had agreed to only months before. Their requirements changed, you see.

Now I work in an environment where this norm is the norm. Requirements change and they change often. Or better put, requirements are discovered daily and old requirements change into new requirements nearly as often. This is the unavoidable nature of the business I'm in. I accept it.

What I hate and cannot accept in this ever changing world are requirements documents written in a proprietary binary format. Sure they're stored in source control, so when I do a little update on my Subversion client in the morning and see that several requirements documents have changed, I'd like to just do a nice simple DIFF on them and see what's changed. But no. Oh, sure there are probably some diff tools out there I could get, but why should I when we could have just written the requirements in text or even a simple transformable XML rather than the binary gobbledygook in a Word or Excel file.

And can anyone tell me how to "blame" a change in a particular line in a Word doc on a certain author? Oh sure, I could use the gooey sticky messy change tracking--no thanks. Just give me a good text file and an editor that can handle it well.

Is my rant a cry for a product or what? Is there an existing product you can recommend? If so, please tell me. And then maybe we can ban the use of Word and Excel for the production and maintenance of requirements. We can say goodbye to the lack of transparency and traceability. We can say hello to simplicity and accountability. Ah, how would it be.

Sometimes your logger throws an exception while logging an exception. At least it does if you have luck swings like mine from time to time.

Here's how I deal with it.

using System.Diagnostics;

try
{
    //some logging code that can throw an exception
    //but the exception has to be handled and logged
    //somehow
}
catch (Exception e)
{
    try
    {
        //write exception to OS event log
        if (!EventLog.SourceExists("MyAppName"))
            EventLog.CreateEventSource("MyAppName", "Application");
        EventLog.WriteEntry("MyAppName", "Log Exception: " + e.Message);
    }
    catch
    {
        //sorry charlie
    }
}

It's not perfect, but it seems to work in most cases.

This code comes in handy especially in Windows Services where in the .NET Framework 2.0 and up (as near as I can tell), an unhandled exception will result in your service being stopped with little or no evidence as to why.

I've recently begun to explore MySQL a bit more, mostly out of curiosity. Primarily I work with SQL Server 2005 in my day job but it seems prudent to know a bit more about some of the other databases servers and it's been a while since I dusted off MySQL.

Happily I found that MySQL AB has released a really great ADO.NET provider for MySQL.

If you have used the SQL Server specific ADO.NET provider, you'll easily make the transition to using this one.

But I digress. The reason for this posting was to permanently remind myself and anyone else making a transition between these two database engines that TOP = LIMIT but not in the same place. That is to say, the TOP keyword is used in SQL Server to limit the number of returned rows just prior to the column specifiers. The LIMIT keyword however is used at the end of the select statement. Thus:

SELECT TOP 1 * FROM MYTABLE WHERE FKID = 3

And for MySQL use:

SELECT * FROM MYTABLE WHERE FKID = 3 LIMIT 1;

Yes, I know. It ought to be obvious, but having a quick reminder here will help to seal this minor difference into my brain.