For some reason I've found other things to blog about recently and have been ignoring Yukon. I was going to get around to writing about partitioned tables but there is no need now. Kimberly Tripp has released a fantastic paper on the subject:

While getting ready for the PASS Community Summit in Orlando this week (where I plan to talk about SQL Server 2005 Partitioned Tables/Indexes), I realized we were close but not quite ready to release the post-beta II whitepaper on MSDN.

So, in preparation for PASS we decided to post a pre-release of the partitioning paper here.

(via Kimberly L. Tripp: Improving your SQL skills)

Chris Rathjen has a post requesting information on how we deal with branching in change management so I thought it would make a good post subject.

At Exony we use Perforce as our source control system for two reasons: it's wickedly fast plus the branch and integration features are excellent. It is similar to SourceSafe in that the repository is structured much like a file system. We have a number of products that use internally developed shared libraries and third party SDKs. The tree on the left of the diagram below shows how things are structured. The right hand side shows the version lines with branch and integrations.

Each product or library has a folder which contains sub-folders representing available versions. All new development happens on the main branch. The nightly build scripts will attempt to integrate changes into the build branch (orange arrows) and then rebuild. If, for any reason, the build fails then the integration is rolled back. This ensures the build branch is always in a build-able state. Perforce change sets come in handy here because you can either commit or revert them based on the build outcome.

When it's nearly time to ship we branch the latest build branch into a "QA" folder (green arrows). This is the v1.0, v2.0, etc folder. This is the build that gets QA'd before it goes out of the door. Any fixes are still made in the main branch and once the nightlies copy the code into the build branch, we do manual integrations into the QA branch. This way we can verify that nothing major is going to de-stable the QA line.

After a release any fixes are made in the correct versioned branch before being reverse integrated back to the mainline if they are still relevant there (not shown on diagram).

Also, every time a build script is run the file versions in that branch are labelled with the build number. That way we can go back to any build on any branch if needed.

The third party SDKs, e.g. Microsoft SOAP or MSXML4, are also stored. These third party folders only contain headers, libs and DLLs used in the build process as there is no reason to store additional binaries such as CHM files.

Sharing code is also based on branching and integration (red dotted lines). Once a shared library is released then its actually integrated into the relevant product mainline. That way we isolate the product from any changes that may be happening to the shared libraries or any other product.

Overall the process works well and we haven't had any build related late nights since implementation (although there have been a couple of product related ones). It's nice to be able to hit a button, grab a coffee and wait for your product ISO to drop out at the end ready for burning onto CDs.

According to this survey, my personality type is The Discoverer: "Your distinct personality, The Discoverer, might be found in most of the thriving kingdoms of the time. Your overriding goal is to go where no one else has ever gone before. Regardless of the number of available natural problems to be solved, it is not unusual for you to continually challenge yourself with new situations or obstacles that you have created. You are an insatiable explorer of people, places, things and ideas. You thrive on constant change and anything new or different. On the positive side, you can be creatively rational as well as open minded and just. On the negative side, you might be an impractical and indecisive procrastinator."

Sounds about right...

(Link to survey via Sells Brothers -- Chris's Home on the Web)

So you spend the odd evening and weekend playing with the brand new technologies emerging from Microsoft. Whether it's Yukon, Whidbey or Longhorn, there is plenty to mess around with. The more you play with these tools, the more you can dream of new ways to deliver exciting products in next to no time. Life is rosy.

However, we all need to pay the bills and that means going to work. Work is not about dreams, it's about delivering real solutions to customers now. Here is where the misery starts. You can't actually use these tech previews and betas for production code so you have to do things the old way. The old way is no fun. It's depressing and we are still at least a year away from a more pleasant life. It's not that the current tool set is bad, in fact it's great. Compared to the new versions, though, the difference is immense.

Personally, I think it's worse as I can't see any of our customers (apart from one very progressive one) upgrading to Yukon until it's been on the shelves for at least a year. In fact Cisco ICM is a product we depend on and their recent release has only just caught up with SQL Server 2000. Understandably there has to be a business benefit for them to upgrade. Maybe there is but at the moment all I see is developer benefit.

I talk primarily about Whidbey and Yukon as I'm not even going to look at Longhorn until it's a bit more tangible. Blog land is full of posts wondering if it's worth using WinForms for development. In fact Microsoft has recently been on the offensive trying to persuade customers that WinForms is not dead.

On a final note, I do actually like what Microsoft is doing with tech previews. It helps me align my architecture and development plans with theirs. It just makes going to work a bit of a drag in the meantime.

I was on the verge of posting something last night that I'm glad I didn't. I was angry and had a lot to say. As it turns out, I feel differently today. I think there is a lesson here - posting to your weblog is much like writing an e-mail. The same golden rules apply; primarily - don't hit the send button when emotional. You might say that it's easy to change an article later but people will have seen the original and as Scoble points out: your original words will live forever in the various search engine caches.

I have to admit I'm one of the people that Rob Caron was helping out this weekend. With living in the UK I find it second nature to set the system locale to 'English (United Kingdom)' whenever I do an installation. On this occasion it turns out to be fatal when installing the Team Foundation Server. The main effect of which is that the installer will fail to create the correct ADAM structures.

After reinstalling the application server I was able to connect to the Team Foundation Server and create Portfolio Projects; but during creation it failed to create the corresponding Sharepoint site. After checking that I could access the Sharepoint Central Site (administration page) I remembered I hadn't changed the locale on the client computer. A few clicks later and everything is now working. I just need to work out how to delete all the failed Portfolio Projects from the system.

I haven't spent too much time looking at it yet as the 8 hour time difference to Redmond means support from Rob came late in the evenings. Initial feelings are that it's going to be a great product. The thing the really impressed me is not the product (yet), but the customer service I received from Rob. He spent a large amount of time this weekend trying to solve my problems when he didn't need to. All he wants in return is feedback on the product. It makes you feel kind of special. Certainly it makes me want to use the product. Thanks Rob. 

Whilst browsing Will's Blog: he's found a cool little utility called Microsoft TimeZone. It's a small .NET application that sits in your system tray, when you click it shows the time in up to 5 locations. Useful for knowing how to greet your Messenger buddies.

What it really interesting though is the download. It seems Microsoft would like you validate your copy of Windows before you download (this is a picture so don't try and click):

The link takes you to a page describing the benefits of genuine Microsoft software. I love the fluffy reasons they give: "greater reliability, faster access to support and overall richer experience". What they really mean is "we don't like people who steal our software, we are going to make it hard for them". As a software developer, it's a sentiment I agree with.

[Edit: there is more detail at http://www.microsoftmonitor.com/archives/003782.html]

I was just looking to get into music downloads and guess what Scoble says. Is he psychic?

Need some fun rave-style music to get your productivity up? Mix Of the Week provides it.

(via Scobleizer: Microsoft Geek Blogger)

Sometimes, when you have to get a lot done in a ridiculously short time, you need a different approach. As a case in point, we need to replace all the remaining ASP code in our product with ASP.NET before we add some essential new functionality. If we don't we will be stuck with the old code forever. This new functionality has to be delivered in a matter of weeks. It could be implemented in classic ASP but it will be much easier and faster using .NET.

What is called for is a few days of pure implementation. No "discussion", no "difference of opinion", just code. It's risky - probably only a 50% chance of success but if it works then we could save days in the immediate future and additional weeks down the line.

There is a way this could work; by modelling the team on an operating theatre. In this setup, there is one person who does the bulk of the work backed by a second to provide help and support. These two make the core pair - everything goes through them on the way into the product. The rest of the team are assigned packets of work by the core pair on an as needed basis. When the packets are complete they are given back to the core pair to stitch into the product. Effectively, one feature at a time is worked on by the whole team.

The main benefit to this style of team is the minimal communication needed, resulting in a higher code to comms ratio. The packets of work are usually so small that they can be described in a couple of sentences. If the result is not quite right then the core pair make whatever changes are required saving the time usually spent explaining additional work to the developer.

There are two key points to note before you embark on a development style such as this. Firstly, the core pair has to have a very strong shared vision of what the result should be. If not then you won't be on a straight line to goal and too much rework will kill the efficiency of the method. Secondly, it can be a bit ego bruising to the non-core developers. They are told exactly what to produce, they have no real opportunity for free thought and the code they return may be modified or even not used. Nearly everyone can put their needs and feelings on hold for a week (even developers) but I wouldn't push it beyond that. This is only for tiger-team style development.

I have my guest systems configured to use their own network because I don't want my ISP moaning about DHCP and domains appearing on the subnet. The lack of "Shared Folders" in Virtual Server makes life difficult as it also won't mount ISO's larger than 2GB; you have to actually burn the image onto a DVD to use it in a guest operating system. The next challenge comes from Sharepoint Team Services and Active Directory Application Mode - these setup files are executables not CD images so can't be mounted. The solution, use mkisofs to create an image with the correct files on.

Finally, Visual Studio 2005. The handy hint here is not having "undo disks" enabled or you will grow old before it completes. If you are going to install the supplied MSDN then block out a full day anyway...

OK, everything installed... Fire up Visual Studio and connect to the Team Foundation Server... Yep, it connects. Try and create a portfolio project and... Bam! Access Denied... F#!%$%*k

I've just given a whole Sunday to this thing... Does anyone know what the problem is? I've tried adding the user to Global Administrators group as described in the docs but GssUtil reports that the identity "adm:" cannot be resolved.

The Photo Gallery is out of order at the moment. I seem to be having some nGallery issues with it. Thanks to everyone who mailed me to let me know.

[Edit: Actually, it's up and down like a whore's drawers so try your luck with it...]

I was in a customer data centre today. It's quite impressive seeing all the racks of servers they have. The customer in question is one of the UK's leading banks and the physical security of the place is amazing:

• No company name on the building - you have to know it's the right place
• Double layer prison style fencing with security cameras
• Steel gate that opens for your car when buzz and speak to security
• You have to pass though an outer door (operated by security again) before signing in and picking up your pass
• To sign in you have to have a prearranged visit organised 72 hours in advance
• Then an inner door (security personnel operated)
• You are now in the building but only have access to the canteen and toilets
• You get collected by a member of staff and go to the data operations gallery to pickup a second pass (green level -> limited access)
• Finally with this second pass you get access to the room and rack where your servers are

Once inside the server room you understand the reason for all the security. It's full of mainframes and storage systems where the bank keeps their data. Very impressive to see and kind of makes our two 2U servers look a bit small.