Youhana's WebLog

Introducing Lambda Expressions – Validating a List without a loop

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4:  

   5: namespace LambdaExpressionDemo

   6: {

   7:     interface IValidator

   8:     {

   9:         bool Validate();

  10:     }

  11:  

  12:     class RandomValidator : IValidator

  13:     {

  14:         private static Random randomGenerator = new Random();

  15:  

  16:         int value = 0;

  17:  

  18:         public RandomValidator()

  19:         {

  20:             value = randomGenerator.Next() % 2;

  21:         }

  22:  

  23:         public bool Validate()

  24:         {

  25:             return value == 0;

  26:         }

  27:     }

  28:  

  29:     class Program

  30:     {

  31:         static void Main(string[] args)

  32:         {

  33:             bool success = false;

  34:             while (!success)

  35:             {

  36:                 //We have a list of items for example controls

  37:                 List<IValidator> listOfItemsToValidate = new List<IValidator>();

  38:                 for (int count = 0; count < 5; count++)

  39:                     listOfItemsToValidate.Add(new RandomValidator());

  40:  

  41:                 //We want to validate that the value of all the items 

  42:                 //even number.

  43:  

  44:                 //Without Lambda Expressions we would have validated the 

  45:                 //list using a for loop

  46:                 success = true;

  47:                 foreach (IValidator item in listOfItemsToValidate)

  48:                     success &= item.Validate();

  49:  

  50:                 //With Lambda Expressions we could do the 

  51:                 //validation in a single statement

  52:                 bool success2 = listOfItemsToValidate.Where(

  53:                     (item) => !item.Validate()).Count() == 0;

  54:             }

  55:         }

  56:     }

  57: }

Team Foundation Server 2010 & Visual Studio 2010 Beta 2 Ships

Earlier, this week TFS & VS 2010 Beta2 was made available for everyone to download and try out. You can download it and try it out here.

I will be starting a series of “Getting Started” blogs to walk you through getting started with TFS 2010 & VS 2010 highlighting the new features of this release.

Q&A About TFS Version Control

In my last post about Visualizing Change using TFS 2010 I mentions that I am going to post some answers about different questions I usually get asked by other software engineers when I mention that I work for the TFS team. In this post I will list the most commonly asked questions and answers:

Q: When I do a “Get” TFS does not get the files I requested?

A: I heard this complaint from a couple of TFS users. The user scenario here is

1. The user synced his workspace to local disk
2. The user then deletes some files from the local disk
3. When the user executed get again from VS or using “tf get”
4. VS prompts the user with a message saying “All files are up to date.”

The reason that this is happening is that TFS server keeps track of the version for every file you last downloaded and will not do an subsequent downloads unless a newer version of the file exists on the server.

To mitigate this problem you need to execute “Get Specific Version” and check the force flag and that will force the server to sync your files again.

Q: Does Microsoft use TFS internally?

A: Yes. Microsoft uses TFS internally in some divisions. My team dogfoods (uses) TFS as our source control / bug tracking / build system. Brian Harry usually blogs out our internal TFS offerings. Here is his latest post about that.

Q: Can I force my developers to only check-in when their changes build?

A: Yes, a new feature called “Gated Check-in” was developed in TFS 2010 to address this issue. In this feature basiclly when the developer clicks “Check-in” he/she is prompt to start a build to submit the changes. If the build completes successfully, the changes are checked in. For a demo of this feature you can read, Jim Lamb’s our Team Build’s PM post about gated check-in here.

Q: Can I undo my changes when I am working offline?

A: No. For TFS 2005/2008/2010 the user has to be connected to be able to undo a change. This request aligns with an enhancement that is planned for later releases around the experience of working offline. For TFS 2010, we did a lot of enhancements in the Offline Experience when working with bound solutions and projects. However, you still need to be connected to be able to undo your changes.

Presenting “Visualizing Change Using TFS 2010” @ the Raleigh Code Camp (RDUCC)

Last week I had the honor to present a subset of the features we developed for version control in TFS 2010 at RDUCC. In this presentation I introduced the audience to branches and what advantages we get by defining a branching model and adhering to it. I then used 2 common problematic scenarios that usually happen when you work in different branches and I illustrated how the new history, annotate engine and branch visualization help solve these problems. Here is a summary of my presentation:

1. Working With Branches

A branch is a self-contained snapshot of the sources. In a typical small project “MyDemoProject” for example, we will have a “Main” branch that will always have our latest stable bits, of that we will have “Dev” branch where we do all of our un-stablizing development activities, we will only merge changes made in the “Dev” branch to “Main” when a certain iteration is complete. When it is time to release our product, we will create a release branch where we can branch “Main” to a “Release”, the “Release” branch is where we do the final testing and release activities.

Some teams will have a different structure with a “Dev” branch, “Staging” branch and a branch for every release.

Why do we typically work in branches?

We need branches for a lot of different reasons, I will only list 2 of them here:

1. Branches provide team isolation : e.g. A team of 10 developers is building an application. There are two feature teams, each led by a development lead. Each team want to work independently from the other team without having to worry about the changes the other team is doing. They only need to integrate the common areas from time to time. Branching is the answer.
2. Branches helps you easily provide patches to maintain your release: e.g. A development team has just gone live with the first release of a Web site. The development team has started working on the next version of the site, but a critical bug is found by an important customer on the live site instance. The fix can easily be made on the release branch and published to the customer.

For more information about what Microsoft’s branching recommendation you can refer to the Team Foundation Server Branching Guidance.

2. Scenario # 1 : Figuring out a source of a change

Typically during release times you will get an email that will sound something like this. “Using Beta2 build#1013, I cannot add do such and such” and a P0 bug is opened. The developer will jump in, attach the debugger to figure out the problem. And the answer is that “This happened because of a change that was made in ‘Program.cs’ that came from a recent merge to the Beta2 branch”. And the key question here is “WHO DID THIS CHANGE AND WHY WAS IT MADE?”

To figure out the source of this change, you will typically execute “tf history” or history from inside visual studio. Unfortunately, the history view in Visual Studio and TFS 2008 will only show you the merge changeset but not a break down of what the merge brings. To find what you are looking for, you will have to figure out which branch was merged into your Beta2 branch. You will then need to re-execute history there to figure out the information you are looking for.

In Visual Studio 2010, the history dialog was re-designed to perform these tasks for you. In Dev10 you will be able to drill down any merge or branch operation to see the actual changesets that made it with this merge. Further, history dialog will also show you the path of the files where these changes were made. This is a snap shot of the new history dialog. As you can see the history control is now a tree view to enable you to drill down a merge as deep as needed.

Instead of the History Dialog, the developer could have chosen to use annotate. Using VS/TFS 2008 annotate will only show the merge edit changeset and will not drill down further too. As you can see here both fixes were attributed to the merge changeset 29. Although the main experience of the feature has not changed much, but for Dev10 Annotate was enhanced to automatically drill down any merge changeset to show you the real changeset where the change actually happened. As you can see here, the change sets that contain the edits are the ones displayed.

VS/TFS 2008 VS/TFS 2010

The first scenario was addressed by the new History dialog and the annotate engine enhancement.

3. Scenario # 2 : Figuring out whether your change was merged in Branch X

One other typical scenario that happens will be when you are about to release and conducting the final testing phase on your release branch, you find a bug in that branch that you are 100% sure you already fixed. And you wonder, was that fix made before the release branch was created or after? What if you actually want to know which branches in your project have the fix and which don’t. If you have a couple of branches that would be easy. But what if you have tens of active branches.

To address this issue, TFS 2010 introduced the concept of first class “Branches”. A first class Branch is a container of files and folders with a tag that indicates that this is the root of a branch. The Branch holds some meta data about the branch such as the owner, description and information about its relationship with other branches. With first class branches comes a whole new set of features:

1. Visualizing Branch Hierarchy
2. Tracking Changesets
3. Tracking WorkItems

VS/TFS 2010 provides you with the capability to actually visualize the relationship between the branches in a hierarchy view just by right clicking on any branch and invoking “Show branch hierarchy”.

To address the problem where the developer wonders if his fix made it to the target branch or not, the developer can easily query the history of the file that has the fix and from the history window invoke a “track changeset” request. The track changeset window will show you whether the fix was merged into the target branch or not and if it was merged it will show you the changeset of the actual merge. The developer will “VISUALIZE the CHANGE”.

The developer also has two views to chose from. The Hierarchical view to see the change in relationship to the branch hierarchy. Or the time line view to see how the change actually propagated by time.

In conclusion, VS/TFS 2010 includes a lot of enhancements to version control to enrich the developer experience when working in different branches. During the presentation I had a lot of questions from the audience about other upcoming features in VS/TFS 2010. I will post a summary response to these questions in an upcoming post.

Hello World !!!