The autumn TV schedules are causing me a bit of a headache. Do I watch Hex or Carnivàle, The West Wing or Stargate Atlantis (or Champions League Football), Long Way Around or Spooks? The TV companies are really battling for viewing figures this season. Something has to give...

It's time to turn to toys. I need some sort of hard disk recorder that can record the programmes that clash. As I have a Sky subscription, it's a bit of a no-brainer, it has to be a Sky+ box. They have also just released a new version with 160GB (80 hrs) storage and a subscription deal that makes it only £150 more expensive than the standard model.

A couple of clicks on a web site, Google AutoFill for the credit card details and it'll be here next Friday. Sweet.

Microsoft has decided to delay the release of SQL Server 2005 from the first half of 2005 until later in the summer of that year. A Community Technical Preview will be released as an interim beta with possibly more to come before the final beta and the product’s eventual release.

(via The ServerSide.NET)

I guess my previous post was correct in it's assumptions. The SQL Server delay has allowed the Visual Studio team time to add C# Edit & Continue.

I thought it was interesting how my article on C# Edit & Continue was handled by a couple of Microsoft bloggers. On the one hand we have Robert Scoble who stuck it on his link blog, there by making it available to a much wider audience than normally reached by my site.

The flip site was a little different. I left a comment on Somasegar's web log pointing back to the article for two reasons. The first because I'm not sure that dasBlog ping-backs work with .Text and secondly I thought it polite to let Somasegar know what I'd written. He has comment moderation turned on so gets to decide what gets published. Unfortunately he decided not to let this one on his blog.

I prefer Scoble's blogging approach, so the rule on this site is I will never delete a comment unless it's personally defamatory or libellous. Otherwise, lets have a discussion about whatever you disagree with.

As a side note, I found a useful feature of Google Desktop whilst writing this article. My internet connection at home wasn't working tonight so finding the URLs for the links was a bit difficult. No problem - just search for the stuff with Google Desktop and use the cached page instead.

I'm just working on the membership part of the web site and as the user configuration is stored in a file I wanted to make sure it was going to be saved safely. Simple, just copy the file to a backup before saving. If anything goes wrong then restore the backup. The code is a little fiddly and I want to use if everywhere I save a file so I've created a little utility struct.

    public struct AutoBackup : IDisposable
    {
        private string file;
        private string backup;

        public AutoBackup(string file)
        {
            this.file = file;
            this.backup = file + ".bak";

            if (File.Exists(this.file))
            {
                File.Copy(this.file, this.backup);
            }
        }

        public void Dispose()
        {
            if (File.Exists(this.backup))
            {
                File.Copy(this.backup, this.file, true);
                File.Delete(this.backup);
            }
        }

        public void DeleteBackup()
        {
            if (File.Exists(this.backup))
                File.Delete(this.backup);
        }
    }

It's a struct because it should always be created on the stack. Initially I had some problems because I was trying to modify the fields after initialisation; something you can only do with reference objects. Usage is as follows:

    using (AutoBackup bak = new AutoBackup(membershipFile))
    using (FileStream fs = new FileStream(membershipFile,
            FileMode.Create, FileAccess.ReadWrite, FileShare.ReadWrite))
    {
        serializer.Serialize(fs, membership);
        bak.DeleteBackup();
    }

The DeleteBackup() call is to stop the auto restore functionality from kicking in. If anything happens during the save that causes an exception to be thrown then the using block ensures the old file is restored.

A couple of days ago Somasegar announced that C# would have Edit and Continue support in VS 2005. Wow, great news... But hold on, haven't they been saying all year that they didn't have time to do both refactoring and edit & continue? What changed and more importantly, how has that affected the final delivery date? You don't just add in a major feature and expect everything else to stay the same. So I guess one of the following has happened:

• They found a bunch of devs and testers who have nothing better to do
• Yukon has delayed some more and since VS2005 shares the same CLR version they now have so much slack in the schedule that they can add the feature
• The new feature has delayed the product

I don't expect the first option is correct. I suspect the second has happened. Even if it's the third then we have a schedule slip somewhere and an even longer wait. Come on guys, I thought Microsoft's 21 Rules of Thumb was all about begin schedule driven and not feature driven? I'm under pressure to use alternative technologies so if the wait is too long then I'm afraid you may lose your chance.

I was just thinking about the overall architecture for the Golf Web application and whether or not it would be better to try and use existing products instead of trying to roll my own. I could use dasBlog and nGallery like this site does to provide pictures and allow members to update what they are doing.

This is the classic "buy vs build" decision that sometimes gets overlooked in software development. The cost equation is simple: will the purchase cost of the bought component + integration costs be greater or less than the cost of developing said functionality + support costs. Putting numbers in the equation is a little more difficult. Remember the purchase cost may include additional licensing fees. At Exony we have a simple rule for commercial components - if the component can't be redistributed royalty free or under OEM license then we don't use it. Open Source can be useful must don't forget to check the license especially the part about derivative works where the wrong license can commit your entire product to the public domain.

I'm not keen on using the two products mentioned above because they are complete overkill for what I want. There is a third way though, to use parts of the code base. The architecture will be mine but using code from the other two; sort of like a code snippet library. I've checked the licenses and this is allowed as long as I include the original license and copyright notices.

What I couldn't find though was any sort of .NET web contact manager. Does anyone know of one?

As promised previously, I want to dig a little deeper into the requirements and discuss some solutions. This post is going to be about the security and membership. The relevant requirements are:

1. There system will only allow access to members, i.e. no public access
2. The system should be simple and that includes registration
3. Registration and security should be self maintaining wherever possible
4. Lost password handling must be automatic

There are standard patterns for login and registration and you really want the users to feel in familiar territory whilst starting out with your application in otherwise they are likely to give up and never return. Also I want new users to be up and running as soon as possible.

First I have some choices to make so lets start with login id. Personally I find it difficult to remember my user names, particularly if registered with lots of web sites. I tend to try and pick the same one but obviously if someone else is using it then I have to pick a different one or a variation. I think using an e-mail address as a login is much more memorable and the chances of a clash are near zero. We will need the e-mail address as part of the registration process anyway so using it as a login id removes the need for choosing an additional login name or providing additional registration pages dedicated to telling the user to pick another name because it already exists.

Next the password. This is usually a weak point in any security system and I believe the best approach is to make it easy and secure for users retrieve a forgotten password. This way you can urge them to pick a more complicated pass phrase without them worrying about forgetting it. I need to allow for long passwords so there should be at least 100 characters available. Whilst we are on the subject of passwords, I intend to only store a salted hash so retrieving a password will be impossible. Lost passwords mean that the user will have to recreate a new one. There are two ways I could do this: either by generating a new password and e-mailing the result to the user or sending a special "one time" link instead which, when clicked on, allows the user to set a new password. As e-mail will travel unencrypted I prefer the second approach because the user is forced to select a new password and the link will only work once.

Finally, the registration process. This one is a little more complicated because I know Laura already has a list of contact details she wishes upload to the site. This means that contacts may already exist before the relevant user registers. I'm not sure if Laura intends the users to edit any contact or only their own details (I must remember to ask). If it's the latter then I'll need some mechanism for tying up the user to the contact. I could get the user to type in their address at registration and match that to an existing contact but there too much room for error when you consider things like "street" can be written as "st." etc. What I shall probably do is some sort of fuzzy match based on the post code and any other digits in the address. More on that at a later date. One benefit of matching the user to an existing contact is I can automatically validate a registration request saving Laura from a manual step. Any non-matches will have to manually verified unless I can think of some cunning way around the problem.

Thats all for tonight. As it's my birthday I'm going for dinner with friends tomorrow so the next installment will be at the weekend.

My step mother asked for a favour this weekend. She has a rather large Word document of unsorted contact details and pictures that she wants to publish on the web. She wants me to see if I can provide a solution. I should start by saying this is a classic request of a programmer similar to "will you help fix my computer" and "I can't read my e-mail". I'm happy to do this, particularly as it's a fun little project, but it can turn into a bit of a commitment.

So what is this application supposed to do? Lets review some of the requirements from Laura:

• The application will support a membership of a virtual golf club; they meet up for social reasons and to play different courses in the US and UK
• Manage contact details for golf club members
• Each contact has name, address, phone, e-mail and a picture
• Members should be able to update their own details
• Members can search for other member's details
• The system will only allow access to members, i.e. no public access
• The members can add descriptions of what they are up to

After thinking about this for a while I can see that there are some additional unwritten requirements. It's usual for the customer to not fully understand what they want and as an analyst you have to use your experience and fill in the gaps. You do need to go back to the customer and check your assumptions are correct though. So what are mine?

• Simplicity - the users of this application are in their 40's, 50's and 60's so I'm going to make a sweeping generalisation and say they aren't too comfortable around computers.
• Manageability - Laura is a busy person with better things to do than continually login and manage the system
• Registration - to ease the management burden on Laura, this should be as automated as possible
• Lost passwords - this is not an every day application so the large gaps between logins will increase the chance that the members have forgotten their passwords. It also needs to be automated so Laura doesn't have to do anything.
• Meet-ups. This was not in the original list from Laura but it's the primary reason the club exists. Would it be worth placing on the product backlog?
• Notifications - do the members want to be notified if anything has been updated? This will save them from the burden of logging in frequently.
• Logging - this one is for me because if anything goes wrong then I'm the one getting the call to fix it
• Hosting - I'll need to find somewhere appropriate to host the application. Luckily we checked and a suitable domain name is free.
• Data Storage - I don't have experience of using databases on web hosts, though I know it's possible, so I want to try and use a file based data storage mechanism

Next time I'll discuss some of the requirements in more detail with respect to some possible solutions.