Reflections on three days at Tech Ed

This is my third day at Tech Ed 2008 in Barcelona, the breadth of the technologies and languages that we as .Net developers now need to at least understand and preferably master to some degree is enormous. I believe that developers will need to specialize more explicitly on certain technology areas to remain productive in the future. It has been impossible to master all of Microsoft's products for many years now but up until a year or so ago it was at least conceivable for a developer to master all of the developer technologies that Microsoft had on offer. With the introduction of cloud based services and all the news in .Net, both libraries and new languages I cannot see how any one person will be able to master it all... I want to sum of some of my thoughts on the sessions that I have attended here at Tech Ed on Visual Studio 2010.

Fixing Continuous Integration

CI is a great principle and has moved into the mainstream along with many other agile principles. While Continuous Integration as such has never been broken there has always been a problem with developer discipline. If you check in something that is broken then it will be discovered quickly with CI but if you don't fix the broken code other developers will be less productive if they cannot get the latest code or have their own checkins fail in CI due to previously broken builds. With Visual Studio Team System 2010 Microsoft is introducing a new concept for CI, the gated check. It is not a big change to the CI flow but a very clever use of a shelving, a feature in TFS which I find generally is underutilized. Instead of doing a standard checking in and then running a build on that code, gated checkins shelve the developers changes and then performs a build on the shelveset. If this build is successful then the shelveset is promoted to a proper check in, if the build fails then the check in is not committed to the mainline. The visibility that CI offers is maintained but using gated checkins other developers will never get failing code from other developers which was discoverable! Obviously undiscovered errors can still sneak into the code due to bad or missing tests or incorrect configuration of the build environment but it I believe that this will lower or eliminate the fear of checking in that some developers have. It will also allow you to check in before you go home without the need to wait and see that the CI build completes successfully. If I check in my code 5 minutes before I go home I should ideally wait to see that the build is successful, if it does not then I need to fix that immediately since other developers will be getting that code tomorrow morning when they come in. Using a gated check in I can go home, let the CI build complete on my shelved changes and if the build is successful then everyone can get my changes in the morning, if it fails I can safely wait until the morning before fixing the code and no one else is impacted by my errors.

Reproduction of Errors and Architecture Compilation Failures

Visual Studio 2010 looks like it contains some pretty good testing tools like the ability to record a testers GUI while performing manual tests and also including debugging and tracing info from remote machines. Pretty powerful stuff! It seems Microsoft have their mind set on eliminating the problem of irreproducible errors.

Another interesting feature is the architecture layer diagram which allows you to specify how the different layers in your application may and may not call each other. This is useful for validating that your code follows the intended architecture at compile time instead of detecting it when problems arise. All of these features (and there are more) are great but unfortunately Microsoft still has silly distinctions between different editions of Visual Studio Team System, so many of the cool demo features will probably be marginalized in most organisations due to them not actually having the appropriate edition of Visual Studio.

Comments [1]

Add intellisense for any file extension in Visual Studio 2005 or 2008

I have been messing about with some template experiments in dasBlog using Notepad++ and Visual Studio 2008. That is changing the site layout by editing homeTemplate.blogtemplate, dayTemplate.blogtemplate and itemTemplate.blogtemplate for a dasBlog Theme. These files are basically html files with dasBlog specific macros for inserting the blog functionality.

Notepad++

First off I love Notepad++ as a replacement for Notepad. I have had a hard time doing more complex things in Notepad++ due to my addiction to Microsoft's intellisense... Editing the .blogtemplate files is dead simple in Notepad++ since it is very easy to get syntax coloring - you simply choose a language (html) from the language menu and viola everything is color coded. The file that you are editing doesn't need to have the correct extension or even be written in the language you choose. Notepad++ does its best and highlights whatever it can recognize.

There is also an auto completion function that you access by pressing CTRL+space, but this function is really only a text completion function and does not take any notice of the context that you are typing in. It just pops up an alphabetical list of potential text candidates based on the letters that you have already typed. For simple programming tasks this is more than adequate and Notepad++ does have a significantly smaller footprint than Visual Studio, so you can install it on pretty much any computer or server without anyone complaining for quick debugging tasks.

What I really have been missing is proper html intellisense for the .blogtemplate files.

Visual Studio 2008

Obviously Visual Studio does not have support for the .blogtemplate extension. For awhile I hacked my way around it by renaming the files to have a html extension while editing, which sort of works. The main problem is that I keep forgetting to change the extension back before I start testing my changes - so this was causing unnecessary pain... I had a vague memory of configuring something like this before and found these instructions. For the sake of completeness I include them here also:

1. Go to the Tools->Options menu.
2. Pick Text Editor -> File Extension from the tree in the left part of the Options dialog.
3. Type your file extension, .blogtemplate in my case, in the Extension text box.
4. Select the appropriate editor from the Editor dropdown.
5. Click Add and then Ok to close the dialog and re-open your files.

If you cannot see the Text Editor node in the tree view of the Options dialog then you probably need to click on Show all settings in the bottom left hand corner of the dialog...

Using this feature you can set up pretty much any color coding and intellisense support that you like in Visual Studio for file types that Visual Studio lacks support for. All I am missing now is auto completion for dasBlog macros in .blogtemplate files, this seems like a much tougher problem.