Setup of TFS for Virtualization

I was reminded today that the first step in working with TFS is to get it setup. If I were to start from scratch I'd do so with "virtualization" and a single-server dedicated server solution. Whether to go with Hyper-V, VMWare, Virtual Server, etc. all depends on your IT shop. I feel this way primarily because of the importance of backup/recovery procedures being reliable and straight-forward. The leading virtualization platforms have solid backup/recovery procedures in place that can be used effectively for TFS. I also recommend a one-server solution that's completely used for just TFS and its components and nothing else. Whoever is managing the backups/recoveries for your web servers, email servers, data servers, etc. ought to be the same person(s) managing these same processes for your TFS server(s).

See http://tinyurl.com/tfs2008hardware for the best timely article on TFS 2008 hardware recommendations. For most organizations running TFS it can be done with a 50 GB hard disk space server instance using the 32-bit edition of TFS 2008, 32-bit edition of SQL Server 2005 and a 32-bit edition of Windows Server 2003 or Windows Server 2008 OS. For virtualization during runtime it'll need to run with 2-3 GB of available RAM. I'd also plan for about 1 GB per month in hard disk growth. Now if the IT teams are putting up a lot of multimedia content as attachments then your space requirements will grow proportionally.

Some other links to read include:

http://msmvps.com/blogs/vstsblog/archive/2009/01/06/hardware-recommendations-for-team-foundation-server-2008.aspx
http://beyondthispoint.blogspot.com/2005/11/building-virtualized-team-foundation.html
http://www.woodwardweb.com/technology/increasing_the.html
http://social.msdn.microsoft.com/forums/en-US/tfssetup/threads

I'd also like to suggest bookmarking this site at http://www.tinyurl.com/TfsInfo and http://tinyurl.com/AlexReading.

Building a SharePoint Custom List

Microsoft is quickly moving the world towards SharePoint for everything application-related including TFS. Don't be surprised to see me write about SharePoint-related matters here as they greatly impact the possibilities with TFS.


I'd like to provide an article that covers how to create a basic custom site definition, how to create a basic custom list definition, and how to display that custom list on the default page at site creation. This knowledge is useful in TFS as SharePoint lists are great for collaboratively working with constituencies in setting priorities, gathering requirements, reporting bugs, reporting bad implementations and coming up with todo lists that are meaningful. Build your custom list templates right and you'll extend TFS functionality more properly.

See http://www.heathersolomon.com/blog/articles/1300.aspx for the article. And I'd highly recommend reading http://msdn.microsoft.com/en-us/library/ms946721.aspx to get some understanding of CAML as it relates to custom views.

Future Improvements on C# Code Commenting

Read http://alex-tfs.blogspot.com/2009/01/best-practice-on-c-code-commenting.html to see a tutorial I wrote on what I consider to be the current "best practice" for C# Code Commenting. I have a few suggestions on future improvements to this "Best Practice":

(1) There should be a way to automate adding a post-build event for source code projects to have the Sandcastle CHM generated as part of the build.
(2) Certainly other project documentation (such as project charters, requirements documents, design/architecture documents, TFS reports (i.e. builds, work items, changesets, etc.) and other artifacts can be integrated into the post-build event.
(3) Certainly the whole post-build process done locally on auto-building the CHM file and including other artifacts can be included as part of the TFS Build process.
(4) Certainly templates with the HP logo, SLM-labels, and other process needs can be integrated into the help-files generation process.
(5) Considering that code comments are compiled into a XML file using a defined schema we can always customize the documentation however we want with XSLT, third party tools, etc.
(6) As Sandcastle is "open source" and Visual Studio is quite extensible it should be possible to specify custom XML tags that can be processed to generate whatever output or perform whatever tasks we want done at build-time.

Do you have any suggestions to add?

Best Practice on C# Code Commenting

For the next 30 minutes I recommend you do the following 7 steps. They'll teach you how to become proficient on a best practice for self-documenting your C# code in projects done using Microsoft Visual Studio. The same lessons apply for other .NET languages but I mention C# because its the most popular one. Once you've learned this process I'm confident you will use it for now on because it automates the documentation process for all development work to allow you to build HTML/Help files on-the-fly. Make sure you have Visual Studio 2005 or later installed on your workstation and that you've been able to successfully create and build a solution/project before proceeding with these steps.

(1) Read http://www.winnershtriangle.com/w/Articles.DocumentingCSharpSourceCode.asp which is an excellent intro to C# Code Commenting.

(2) Read http://www2.sys-con.com/ITSG/virtualcd/Dotnet/archives/0108/horan/index.htm for a nice explanation on code commenting.

(3) Run Visual Studio, open a solution/project and follow the following instructions. (a) Open the property page for the project, usually by right-clicking on the project in the Solution Explorer, and click Properties. (b) After the dialog has opened, click the Configuration Properties folder. (c) Click the Build option. (d) In the right pane, there will be a property field called XML Documentation File. Set this to the path and file name of the desired file. The path entered is relative to the project directory, not absolute. (e) Put some "Hello World" text in a summary tag on at least one class/member within the project. (f) Build the project and view the XML Documentation File to see your "Hello World" text. (source: http://msdn.microsoft.com/en-us/magazine/cc302121.aspx)

(4) Download http://www.microsoft.com/downloads/details.aspx?FamilyId=E82EA71D-DA89-42EE-A715-696E3A4873B2&displaylang=en and install the product. If you skip this step then you will be very sorry.

(5) Go to http://www.codeplex.com/SHFB/Release/ProjectReleases.aspx, download the latest "Sandcastle Help File Builder Installer" MSI file and install. Then run it on your desktop start menu as follows: "All Programs -> Sandcastle Help File Builder". In the GUI click the ADD button to include the DLL file that corresponds with the assembly you generated in Step (3)(f) of this tutorial. Then select "Documentation -> Build Project" from the menu to build a Help file. Finally select "Documentation -> View Help File" from the menu to see the help file and search for your "Hello World" text.

(6) Read http://msdn.microsoft.com/en-us/library/5ast78ax(VS.71).aspx on recommended documentation tags and try them out in the project you used in Step 3. Build the project in Visual Studio. Then build the help file in Sandcastle to see the resulting help file.

(7) Read http://www.csharpfriends.com/statics/tools.aspx to see some other code commenting tools for .NET. However I recommend using Sandcastle because it has plenty of functionality, its source code is freely available at http://www.codeplex.com/Sandcastle/SourceControl/ListDownloadableCommits.aspx and a google search such as http://tinyurl.com/sand-code-doc shows that there is sufficient documentation, assistance and community support for Sandcastle's future.

Did you do all 7 steps and bookmark this link for future reference? If so then you should now be sufficiently proficient enough on the current best practice for self-documenting your C# or VB.Net code in projects done using Microsoft Visual Studio. Congratulations Guru!! See http://alex-tfs.blogspot.com/2009/01/read-httpalex-tfs.html for ideas on enhancing this best practice.

TFS Build and WSPBuilder

This may be the "holy grail" for Sharepoint development as Brian Farnhill describes how to make TFS Build and WSPBuilder work well together. This makes full-service collaborative large team Sharepoint development possible. Read the following link and keep in mind my summary notes on the 7 steps.

http://pointstoshare.spaces.live.com/Blog/cns!AEC42F315B4528B0!3290.entry


1. Install WSPBuilder on the TFS build server.

2. Add WSPBuilder to the paths environment variable. Add the WSPBuilder path (C:\Program Files\WSPTools\WSPBuilderExtensions) to the PATH system variable on both the development box and the TFS build box.

3. Set files included in the WSP file to copy to output directory. In the Solution Explorer window of Visual Studio you select and do the following on each 12-hive content file in the properties window: (a) set the item to be content, (b) copy if newer for each of these 12-hive items you set. Thus when TFS does a build in the directory that it puts the DLL's it will give you the other files for the 12 hive in the same directory at the same time on the TFS server, ready for the WSP builder call to run.

4. Add the post build activity to the appropriate projects. For each project in your solution producing a WSP you need to follow Brian's instructions for post-build action code. So if your solution builds 9 WSP's you need to do this 9 times. Usually there will be just one WSP per solution and just one post-build action code snippet written. I advise setting the $(OutDir) variable to always be the complete path to where the build is outputting to on the TFS Build server.

5. Create a new build in TFS. Simple creation of a new build but its VITAL to make sure you choose the debug option because WSPBuilder expects everything to be in the debug folder.

6. Add additional reference paths. Open the TFSBuild.proj file that is created for your TFS build and add one as Brian instructs to the appropriate section (the very last one by default, read the comments to be sure). Then you can set this folder up as a network share and drop referenced assemblies in there as required.

7. Add a pre-build action (if more than one WSP file in solution). With multiple WSP's you will find that if you don't follow Brian's instructions that the DLL's from the first projects that are build will make their way into the second and subsequent WSP files. With just one WSP you can skip this step.

Now you should find that your drop location will now contain all the DLL's, PDB and config files, as well as your WSP files. Mission accomplished.

More links for my personal research

The following is here for knowledge retention purposes only so be forewarned that it might bore you and you can stop reading now.


Today I've been doing plenty of blog-reading. There are many more things I'd like to read further but I'm out of time. Here are 5 links without notes and 2 links with notes.


http://www.smashingmagazine.com/2008/02/21/powerful-css-techniques-for-effective-coding
http://community.zevenseas.com/Blogs/Daniel/archive/2008/12/31/free-web-part-codeplex-statistics.aspx
http://blog.sharepointhosting.com/Downloads/SharePoint-Tutorials.aspx
http://www.myvisajobs.com/Top_Visa_Sponsors.aspx
http://alexking.org/projects/wordpress
http://ayende.com/Blog/archive/2007/03/09/Calculating-most-popular-posts-with-SubText.aspx


http://www.codinghorror.com/blog/archives/001129.html

The Greatest Invention in Computer Science is "The Routine"

Aside from the invention of the computer, the routine is arguably the single greatest invention in computer science. It makes programs easier to read and understand. It makes them smaller (imagine how much larger your code would be if you had to repeat the code for every call to a routine instead of invoking the routine). And it makes them faster (imagine how hard it would be to make performance improvements in similar code used in a dozen places rather than making all the performance improvements in one routine). In large part, routines are what make modern programming possible.

the problem with routines: they only take a minute to learn, but a lifetime to master ....

* How long should this routine be? How long is too long? How short is too short? When is code "too simple" to be in a routine?
* What parameters should be passed to this routine? What data structures or data types? In what order? How will they be used? Which will be modified as a result of the routine?
* What's a good name for this routine? Naming is hard. Really hard.
* How is this routine related to other nearby routines? Do they happen at the same time, or in the same order? Do they share common data? Do they really belong together? What order should they be in?
* How will I know if the code in this routine succeeded? Should it return a success or error code? How will exceptions, problems, and error conditions be handled?
* Should this routine even exist at all?

One thing I'll add is this. I LOVE STUBS. That's where I decide for a subroutine on a test value that will get sent back to the calling method until I have time to properly design/write the subroutine. My favorite phrase is "Hello World from ". For example a subroutine called MyNamespace.MyClass.MySubroutine will send back "Hello World from MyNamespace.MyClass.MySubroutine 001" the first time. As new test versions are built and the code gets improved I might increase the number so it now says "... 002", then "... 003", etc.


http://www.codinghorror.com/blog/archives/001161.html

It is the job of a good software project manager to recognize the tell-tale symptoms of this classic mistake and address them head on before they derail the project. How? By forcingencouraging developers to create a detailed list of everything they need to do. And then breaking that list down into subitems. And then adding all the subitems they inevitably forgot because they didn't think that far ahead. Once you have all those items on a list, then -- and only then -- you can begin to estimate how long the work will take.

Until you've got at least the beginnings of a task list, any concept of scheduling is utter fantasy. A very pleasant fantasy, to be sure, but the real world can be extremely unforgiving to such dreams.

Johanna Rothman makes the same point in a recent email newsletter, and offers specific actions you can take to avoid being stuck 90% done:

1. List everything you need to do to finish the big chunk of work. I include any infrastructure work such as setting up branches in the source control system.

2. Estimate each item on that list. This initial estimate will help you see how long it might take to complete the entire task.

3. Now, look to see how long each item on that list will take to finish. If you have a task longer than one day, break that task into smaller pieces. Breaking larger tasks into these inch-pebbles is critical for escaping the 90% Done syndrome.

4. Determine a way to show visible status to anyone who's interested. If you're the person doing the work, what would you have to do to show your status to your manager? If you're the manager, what do you need to see? You might need to see lists of test cases or a demo or something else that shows you visible progress.

5. Since you've got one-day or smaller tasks, you can track your progress daily. I like to keep a chart or list of the tasks, my initial estimated end time and the actual end time for each task. This is especially important for you managers, so you can see if the person is being interrupted and therefore is multitasking.

Reading and Blogging in 2009

IMHO the year 2009 will be the year when the best-organized IT managers/professionals get themselves in the habit of well-managing their blog-reading and knowledge retention. The IT professionals in 2009 who are going to be leading the efforts in the industry to apply technology to real-world business needs are going to be doing plenty of reading in order to stay current, solve problems and come up with the best solutions for their organizations. Typically this will be done through an "in-the-cloud" RSS reader that's also installed on their mobile phone and allows them to analyze statistics and prioritize their RSS feeds to be more productive. They'll spend at least 10 hours/week reading blogs. It'll happen on the train, in restaurants or anywhere they're "waiting" on their mobile phones. It'll happen while they are using their computers at work or home. They will typically be following hundreds of blogs and add at least a dozen or more additional ones every month to their subscriptions. Next they'll track the statistics on their subscriptions and organize them according to which ones are most useful in their jobs/work and then focus on getting updates from the blogs that are the highest priority. In a typical week they'll glance at thousands of titles and then pick a few hundred of the titles to click on to see the opening sentence in the posting. Of these a couple dozen will actually be read and most of the rest just skimmed. With all the constant change in technology there is no more effective way to stay current on technology in 2009 than through fast-speed-blog-reading.

If you want to be heard then you need to earn trust and be rated high on their watch list. You can accomplish this by doing the following:

(1) Regularly update your blog with current useful content.
(2) Generally make each entry short and easy to read.
(3) Provide all possible links and references to avoid plagiarism.
(4) Its imperative that you sincerely try to be completely unbiased and objective.
(5) Warn your readers if you are going to write lengthy details for your own knowledge retention purposes.