Ever have the need for a user to enter a date into a textbox, but not sure how to validate that they actually did?

<asp:CompareValidator id="dateValidator" runat="server" Type="Date" Operator="DataTypeCheck" ControlToValidate="dateTextbox" ErrorMessage="Please enter a valid date."></asp:CompareValidator>

This beats the heck out of writing my own code to do this, and surely this is better tested as well. ;)

Looks like the JetBrains folks (the ones that brought us Resharper) have started a new EAP for a .NET Profiler, which helps to optimize performance of .NET applications.

You can download it here, but do keep in mind that this is very early beta software. I’m really looking forward to how this progresses though. I’ve really been looking for a quality profiler for .NET.

Enjoy!

When working with virtual machines, it is very helpful to run SysPrep on the operating system that you want to clone. This way, the guest operating system receives a unique GUID and MAC address when they start up. Otherwise, you will (like me) encounter any number of conflicts when bringing a new VM online.

Megan Davis has a very helpful post that details how to sysprep a virtual machine step by step.

This is going to save me lots of time when bringing a new VM online. If you’re working with base virtual machines, you also need to be doing this. Thanks, Megan!

After upgrading to iTunes 4.7.1, DRM-protected files that I had unprotected with iOpener refused to play. After a bit of digging, it seems as if JHymm will actually scrub the files completely. You’ll need to go in and add the atoms to remove. Instructions are available at the link.

Via Peter Provost, I found Brian Button’s fantastic “TDD Deep Dive” series, which is a great introduction to TDD and refactoring.

In part 4 of this series, Brian talks about one of the most interesting refactorings Ive seen in a long time. The whole idea of refactoring is to improve the design of existing code, and removing duplications.

One of the most duplicated blocks of code is a loop over a collection. Not only is it duplicated, but it is also breaking the rules of encapsulation, since exposing the enumerator like that allows potential misuse by clients.

The idea is that you place a method on the collection that does the iteration, and create a delegate that gets called inside that method. For example:

public class PersonCollection
{
    public delegate void IteratorAction(Person person);
 
    public void Iterate(IteratorAction action)
    {
        foreach (Person person in persons)
        {
            action(person);
        }
    }
 
    // other collection methods such as Add and Remove
}

The client code then looks something like:

public class EntryPoint
{
    public static void Main(string[] args)
    {
        PersonCollection coll = new PersonCollection();
        coll.Add("Matt");
        coll.Add("Fred");
        coll.Add("Bob");
 
        coll.Iterate(new PersonCollection.IteratorAction(SayHello));
    }
 
    private static void SayHello(Person person)
    {
        Console.WriteLine("Hello, {0}", person.Name);
    }
}

This refactoring is pure genius, and one that I am definately going to look for and apply when I can.

So, it seems that my previous idea regarding comment spam may not have been quite as good as it could have been (you were right, Steve).

Over the last few days, the comment spam has started to trickle back in. Granted its not nearly at the volume that it was previously. However, it is enough that I’ve decided to integrate a CAPTCHA (Completely Automatic Public Turing Test to Tell Computers and Humans Apart) system for posting comments.

I know that this involves entering one additional item in getting your comment posted to the site. However, I hope everyone will indulge me this, so I can save my sanity.

Martin Fowler has introduced several new enterprise patterns for his new book. The one that has intrigued me the most so far is Model View Presenter.

Model View Presenter separates the behaviour of a presentation from the view while allowing the view to receive user events.

Take the code below as an example:

public interface IMyView
{
    string FirstName { get; set; }
    string LastName { get; set; }
 
    string FullName { get; set; }
}
 
public class MyPage1 : System.Web.UI.Page, IMyView
{
    IMyView.FirstName
    {
        get { return txtFirstName.Text; }
        set { txtFirstName.Text = value; }
    }
 
    IMyView.LastName
    {
        get { return txtLastName.Text; }
        set { txtLastName.Text = value; }
    }
 
    IMyView.FullName
    {
        get { return fullNameLabel.Text = value; }
        set { fullNameLabel.Text = value; }
    }
 
    void btnButton_Click(object sender, EventArgs e)
    {
        // this would probably be a class level declaration
        // so that it is not recreated every time. In this trivial example,
        // it doesnt matter
        MyPresenter presenter = new MyPresenter(this);
        presenter.CreateFullName();
    }
}
 
public class MyPresenter
{
    private IMyView view;
 
    public MyPresenter(IMyView view)
    {
        this.view = view;
    }
 
    public void CreateFullName()
    {
        view.FullName = String.Format("{0} {1}", view.FirstName, view.LastName);
    }
}

At this point, the Concrete View contains all the UI widgets. Since we do not have any UI components in our View interface, this would make the view and the presenter truly portable.

All of our business logic is contained in the Presenter. We could take the Presenter and the IMyView interface and create a winforms application just as easily. Even better, since we’ve completely abstracted the view and made it as dumb as possible, we could easily test our application as well.

Since we’re using Constructor Injection (Type 3 Inversion of Control), we can easily create a MockView that derives from IMyView that merely contains accessor variables for the properties. Our test then passes the MockView object into the MyPresenter object. With that, we’re able to completely test the presenter.

I’m looking forward to investigating this pattern more, and hope to show a working sample using this pattern soon.

Yesterday, the UPS truck delivered my recent purchase of Code Complete, Second Edition.

Having never read the original Code Complete and having heard so much about it, I could hardly wait to open the box and immediately started skimming through some of the sections. Yesterday evening, I started at page 1 and am working my way through it. I’m now about 20% into the book and am thoroughly impressed with it.

This book is filled with many “why didnt I think of that” items, including one of the best things Ive heard in a while. In the chapter that talks about building your designs (Chapter 5, if you have the book), the author mentions a heuristic called ‘Avoid Failure’.

The idea is that design failures could be avoided if you consider the ways that the design might fail, rather than just copy the attributes of other successful designs.

This is a very intriguing idea, and one that can be taken outside of the realm of building design. A place that I saw an immediate benefit by thinking about avoiding failure is in testing (unit testing or quality testing).

For example, if I have a simple unit test that does this:

class MyMath
{
    public static int Divide(int dividend, int divisor)
    {
        return divident / divisor;
    }
}
 
[TestFixture]
class MyMathFixture
{
    [Test]
    public void TestDivide()
    {
        int expected = 6 / 2;
        int value = MyMath.Divide(6, 2);
        Assert.AreEqual(expected, value);
    }
}

Our test passes perfectly. However, what happens when we think about avoiding failure? Is there another test hiding in there? What if we pass 0 as the divisor?

The same idea can be used when testing a web page. Let’s say that we have a simple data entry form that takes a persons birthdate and saves it into the database.

A common testing scenario would be to enter the following information into the corresponding fields on the web page:

Name: John Doe
Birth Date: 1/2/73

Once this is done, look at the data in the database. Does it match? Yes! It must work… right?

Maybe! Now, if we think about avoiding failure, we may ask ourselves what happens if I type the persons name into the birth date field and the birth date into the name field.

These are trivial examples, but one can see how you might get a lot better test coverage when thinking about considering the way an application could fail, rather than the way it should work.

Over the last several months, Ive had an increasingly challenging battle against comment spam. I’ve been getting all sorts of undesirable comments/trackbacks.

One of my main objectives was that I did not want to shut off the comments, because I like the idea of people being able to leave feedback about a certain topic when they read it. I also didnt want to expire comments after a set time, because again, I want people to be able to leave feedback for me and others, even if they read the post two years from when it was authored.

MovableType (the blog engine that I use) has been around for quite some time and has matured quite nicely over the years. There have also been some wonderful plugins authored for it. One of the most notable is MT-BlackList by Jay Allen. Using MT-BlackList, I’ve been able to stop an incredible amount of undesirable content from reaching my readers. However, MT-BlackList only solves part of the problem (blocking known comment spam urls).

I’ve recently discovered another, very effective, way of stopping comment spam for MovableType weblogs. This technique involves modifying the mt.cfg file and changing the name of the comments cgi script. The only drawback to MovableType being around as long as it has is that people have become very familiar with it. Knowing the name of the cgi script and the parameters to pass, they can set up bots to hit it with a list of data (ie: blog 1, entry 1; blog 1, entry 2) in sort of a war-dialer fashion.

So, if you can remove the attack surface (by changing the name of the well-known MT comment script), you should be able to significantly reduce the amount of comment spam received. To do this, follow these steps:

1. Locate the mt.cfg file (in your MT root)
2. Search the file for the line that says # CommentScript mt-comments.cgi (in my file, it was line 333)
3. Uncomment this line by removing the # character
4. Change mt-comments.cgi to a different name (making note of what you changed it to)
5. Using your FTP program, rename mt-comments.cgi (in your MT root) to the name used above
6. Upload the modified mt.cfg file to your host
7. Log in to the MT control panel and rebuild all your files

When this is completed, you should be able to view source on your pages and notice that your comment forms have a different action. The action should now be the name that you gave the CommentScript configuration item in the mt.cfg file.

Now, since you’ve reduced the attack surface against your blog, comment spammers in likelihood move on to an easier target. If, for some reason, you find automated attacks are back, simply follow the above procedures again.

I’ve noticed a very steep decline in comment spam since making these changes. We’re talking from 30 or 40 per day to 0 for the last 5 days. I really hope that this can help someone else as well, since comment spam is something we are all battling together.

A very intriguing look into a C# application, this book formerly published by WROX is now available as a free eBook.

I’ve downloaded it and skimmed through it a bit. Very interesting to see how and why certain decisions were made.