After 18 months of abuse, my NAS200 finally lost a hard drive. I heard a muffled beep this evening while working on a new design for this website. Thinking it was one of my daughter’s many noisy toys, I dismissed the alarm and continued working. About an hour ago I attempted to save my work to a share on the NAS200, but was greeted with this rather ambiguous error message.

I could ping the device, but browsing to its administrative website resulted in a 404 error.

The NAS200’s power and Disk 2 lights were blinking in alternation. The Disk 1 indicator was not lit at all. My heart sank at this point. So I next did what all IT professionals do when disaster strikes. I hit the power button and said a small prayer. Unfortunately, my NAS200 would not shut down. I yanked its power cord from the wall, let it cool down, and plugged it back in. As the NAS200 powered up, its fan whirred and lights began blinking.

After reboot, the NAS200’s lights blinked in the same pattern as before, but this time I decided to wait a few minutes rather than have a panic attack. During this time the ACT light flickered rapidly for about 10 minutes. When it finally went out, the power and Disk 2 lights stayed lit, but Disk 1 remained dark. At this point I was able to browse to the administrative website and view Disk 1’s status. The drive appeared to be “removed”. Huh?

I’m perplexed as to what this means. I did not receive a hardware failure e-mail and the “removed” status makes me think that the controller has failed rather than the disk itself. Hmmm… Disk 2 is still accessible so my plan is to back it up as quickly as possible and then proceed as if I’m dealing with a disk failure. Wish me luck.

*Update: The second part of this article can be found here.

I’d recently been struggling with a .NET application that sends email via SMTP through Exchange 2007 outside of my domain at work. That is, until I found a workaround that uses the Exchange 2007 Pickup folder. This eliminated my authentication hassles and resolved the dreaded Mailbox unavailable. The server response was: 5.7.1 Unable to relay error. I’ve posted the solution here, but I also suggest reading the original post.

SmtpClient smtpClient = new SmtpClient("EXCHANGESRV", 25) {
    DeliveryMethod = SmtpDeliveryMethod.SpecifiedPickupDirectory,
    PickupDirectoryLocation = "\\EXCHANGESRV\PickupFolder"
}

Keep in mind that you’ll either need sufficient write permission on the Pickup folder or be able to impersonate somebody that does. I happen to have written about identity impersonation a few months ago. You’re in luck.

Kudos to stackoverflow.com. I only wish I had enough rep to upvote the submitter. :(

I’ve got some explaining to do. I was hesitant in posting this code for fear that it might be too niche to benefit anyone. It may be, but the underlying problem affects many programmers working in the IT industry. What do you do when the company legacy system’s data model doesn’t work with your fancy ORM (Object-relational mapping)?

“Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem.” - David Wheeler

At my last job, the ERP (Enterprise resource planning) system was something of mystery and voodoo. Only a few had sufficient knowledge to work with it and because of its arcane nature it was deemed untouchable. Within my first months as an employee I wrote a rudimentary ORM to serve as a layer between our client applications and the ERP system. Its performance was terrible. I wrote it off as “experience” and the department ultimately decided to ignore interfacing directly with the ERP system.

I’m using the SubSonic ORM on a few ASP.NET projects with my current employer. SubSonic has worked great, but a few of its database requirements have left me in the dust with yet another ERP system. The ERP’s tables have no primary keys, constraints, or relationships, but rather than write a complete ORM I decided to roll my own data layer.

All of the strongly-typed collections in the ERP’s data layer implement the AbstractList type. AbstractList implements List where ItemType implements IUniqueIdentifier. That is a mouthful, but the key (pun intended) to removing duplicate items is to make sure they’re unique.

The IUniqueIdentifier interface contains only one property, UniqueIdentifier.

public interface IUniqueIdentifier
{
    string UniqueIdentifier
    {
        get;
        set;
    }
}

If the ERP system contained a table called Customers a Customer type implementing IUniqueIdentifier would be created.

public class Customer : IUniqueIdentifier
{
    private string uniqueIdentifier;

    // etc...

    public UniqueIdentifier
    {
        get { return this.uniqueIdentifier; }
        set { this.uniqueIdentifier = value; }
    }
}

I’d also have a CustomerCollection class:

public class CustomerCollection : AbstractList<Customer, CustomerCollection>
{
    // etc...
}

After such a long-winded introduction I can feel better about dumping the following code on anyone that has happened to read this far (kudos to you).

public abstract class AbstractList<ItemType, ListType> :
List<ItemType> where ItemType:IUniqueIdentifier where
ListType:AbstractList<ItemType, ListType>, new()
{
    public ListType RemoveDuplicates()
    {
        Dictionary<string, int> uniqueStore = new Dictionary<string, int>();
        ListType list = new ListType();

        foreach (ItemType item in this)
        {
            if (!uniqueStore.ContainsKey(item.UniqueIdentifier))
            {
                uniqueStore.Add(item.UniqueIdentifier, 0);
                list.Add(item);
            }
        }

        return list;
    }
}

I’d love to hear how others have worked around legacy systems and still kept their code clean.