5 Things You Didn't Know About Me

Rob Caron tagged me, so here goes.

1. I didn't try eating tuna salad until my first year of university.

2. I might hold a record for the variety of dead-end jobs held; during my 10 year dead-end job career, I have been a telemarketer, a jack-of-all-trades at Taco Bell (I am a master of the 2-hand stuff technique BTW), a cook at a pizza joint, a dishwasher at Red Lobster, a host at a chinese all-you-can-eat buffet, and finally a salesman in a men's clothing store.

3. I might hold a record for the variety of positions held at Microsoft; during my 8 years there, I was a STE (software test engineer), SDE/T (software design engineer in test), SDE (software design engineer), PM (program manager) and PM (product manager).

4. Following the example set by Indiana Jones and Chewbacca, I now sport a man-bag.

5. My enthusiam for computer science began late in life - it wasn't until I was in my 3rd year of university and learned C through X Windows and Motif.  I still look at AJAX sometimes and think it is a poor-person's x-windows; I also believe that I might be the only person who thinks that way :) 

I'll tag: Prashant, Juan, Grace Francisco, Steven Borg, and Richard Hundhausen.

Thoughts on Recycling SCM Branches

Hey guys,

Chuck Walrad and Darrel Strom wrote an article on what they call “branch-by-purpose” model of branching: “The Importance of Branching Models in SCM”.

It is an excellent article that outlines a very useful mechanism/strategy for branching in SCM models.

The basic idea of 'branch by purpose' is to use a branch to satify a specific purpose. For example, a release is a 'purpose', so is a hot-fix, so is the need to do system testing, etc.

It's a very nice model that corresponds well to many development methodologies.

However, it is becoming more commons for organizations to do very frequent releases. During my time as the Team Foundation Server Product Manager, we worked with a very popular social networking site that released twice a day. That is probably an extreme example, but it is not uncommon fo organizations - consumer facing and otherwise - to do weekly or bi-weekly releases. That type of release model does magnify a side effect of 'branch by purpose' - you can end up with a lot of branches :)

Of course, Team Foundation Server has excellent support for renaming, deleting and moving, so you could easily just move release-branches into archive directories or just delete them altogether. I've suggested that to several customers in the past and it's never been all that well received. That's understandable - Team Foundation Server does support these operations, and it is very good about not storing too much overhead per branch, but it does feel strange to do this on a weekly or bi-weekly basis.

I've seen a lot of customers use labels instead to represent their releases. That works fine - but I'll admit, I've never been an extensive user of labels so I don't normally recommend it. It's a bias not really based on any bad experiences, just one of those things :)

Another option that combines the clarity of branch-by-purpose with the perceived efficiency of labels is to use a fix number of branches and recycle them.

This is something that I saw mentioned in an excellent presentation from Laura Wingerd of Perforce.

Based on ideas from that presentation, a reasonable initial set of branches would be:

• Main - based on your initial check-in of source code
• QA - created by branching from Main
• Beta - created by branching from QA
• Live - created by branching from Beta

What we will do is recycle QA, Beta and Live so that we can release as often as we would like, but never increase the number of branches that we have.

When we decide that whatever our developers have been working on is ready for a full test pass from QA, the code is merged from the Main into QA. The merge in this case is really basically a copy - anything coming from Main takes precendence over what is in QA. From QA, the code will be merged into Beta when it is deemed ready, and so on.

Once QA has been merged into Beta, it can be recycled. That means it is ready to take changes from Main again as soon as Main is ready. The same is true of Beta and Live. Beta can be recycled as soon as it is merged with Live and Live can be recycled as soon as that code has been delivered to customers.

To recycle a branch, we could literally delete every file and folder under that branch.

Laura's paper pointed out some 'rules of the road' for branching and merging. In this case, one rule would be that changes can only be merged 'up'. That is from Main 'up to' QA and from QA 'up to' Beta and so on.

One way to enforce a rule like this is through check-in policy. I'm making some harware changes right now, but as soon as I'm back up and going, I think I'll post a sample check-in policy that checks for proper merge direction.

In any case, using a recycling model like this, these 3 branches can accomodate an unlimited number of releases.

Laura's paper has a wealth of other really good ideas - I'm going to explore them in future posts.

Thanks!

Eric.

Hail to Integrated Search!

Hey guys,

I wanted to share my experience with Windows Desktop Search 3.0 (WDS).  It is really a fascinating technology, particularly from a developer point of view.

WDS 3.0 is built into Windows Vista and can be installed on Windows XP/2003.  In Vista, it is directly tied into Windows Explorer.  Besides basic searching (i.e. find me files that contain XYZ), it can do property based searching.  The 'modified' date is a property that all files in Windows Vista have, so if I want to find all files that were modified in 2006, I can just type the following:

The search in Windows Explorer is instant, so you don't hit return, just type your query and if there are results, they will show up.

I've modified a lot of files in 2006 :) so I'll get way too many results.  I can narrow down my search and look for only C# files that were modified in 2006.

If for some reason I wanted to be even more specific, I could further narrow my search to find only C# files modified in 2006 that are bigger that 10KB

Now that's all well and fine, I'm sure the Windows developers worked really hard to build in that functionality.  But how hard would it be for a developer outside of Microsoft to build the same thing.

As it turns out, it is really quite simple.

Windows Search is exposed as an OLE DB data source; so all you really need to know is the connection string that it uses.  As it turns out, the connection string is just:

"Provider=Search.CollatorDSO;Extended Properties='Application=Windows'"

So I can create an OLE DB connection as follows:

Windows Search understands a subset of T-SQL, however, all of the fancy property based stuff that we did in Windows Explorer (modified:2006, size > 10KB, etc) has to be translated into that query syntax.

Luckily, the Search API has a helper object do this translation for us.  The SEARCHAPI.TLB for this API is .NET friendly, so we can just use tlbimp.exe to create a wrapper for us.  The .TLB comes with the Platform SDK, and can be found in the Lib directory.

The SearchAPI has a simple 'GenerateSQLFromUserQuery' method that takes our input (i.e. modified:2006) and translates that into SQL that Windows Search understands.

For example, GenerateSQLFromUserQuery() turns 'modified:2006' into:

SELECT "System.ItemUrl",
"System.DateModified"

FROM "SystemIndex"..scope()

WHERE (("System.DateModified" >= '2006/01/01 08:00:00' AND
"System.DateModified" < '2007/01/01 08:00:00'))"

All in all, it takes about 30 lines of code to integrate search into your application the same way that Windows Explorer does it.  I posted my sample project here if anyone is interested.

Thanks!

Eric.

The Joys of C++/CLI

Hey guys,

I've been spending a lot of time programming against Windows Vista lately, and during that time I have really come to enjoy the second incarnation of managed C++, now called C++/CLI.

Unless you are really good at .NET marshalling, a lot of great Windows Vista features just aren't that accessible from .NET.  This is where C++/CLI really comes into its own.

A perfect example of this is when writing a preview handler in Windows Vista.  Preview handlers are lightweight viewers that give you a sneak peek at a file before opening it up.

You can enable preview handlers in Windows Explorer from the Organize menu as shown.

Once enabled, any document type with a preview handler will get triggered - Word 2007 is a good example.

The file that I am previewing is quite big - about 10MB - so it's nice to get a preview before starting up Word 2007 to open it up.

Preview Handlers are pretty easy to implement - but they do require that you implement a few COM interfaces.  The interfaces that you have to implement don't belong in type libraries that you can use tlbimp to generate .NET wrappers.

So, if you are using .NET, you have to craft your own COM interfaces (MSDN has an article about doing this for preview handlers), otherwise, you have to dust off your COM skills and get going with C++ :)

I've always been against hand crafting .NET interfaces for COM interfaces for a few reasons.  First, I absolutely abhor marshalling.  I'm no good at it, and I feel like I have to learn 2 things at once; I have to learn/re-learn how to marshal, as well as learning how to use whatever interface I'm using.  Second, I don't think the approach scales very well.  I'm always afraid that one day I will run into a COM interface that I absolutely don't know how to marshal.  Lastly, I'm impatient :) I hate having to take time to write marshalling code instead of my applicatio-specific code.

This is where C++/CLI becomes really handy.  To implement my preview handler, I first created an attributed ATL project for my COM server.

Attributes in ATL really clean up your code - for example, the declaration for my various DLL methods (DLLMain, DllRegisterServer, etc) is all taken care of with the following.

As soon as I build my project, my COM server will get registered.  No messy class factories or registration code to write.

To add a COM object, I just have to add a new class to my project and decorate it with the following attributes.

It's been years since I used ATL, so I didn't just crank this out on my own; I followed a nice walkthrough that the ATL team published. 

Note - in order to use the CLR in a ATL project, you have to adjust a few project settings; the walkthrough found here describes this nicely.

Once I had that, I just did some cutting-and-pasting from the Platform SDK preview handler sample to implement the interfaces I needed.  To be a preview handler, you need all of the interfaces shown below.

At first I found that list to be a bit intimidating, but the samples in the Platform SDK are quite good, so I was able to borrow a good amount of code to get going.  I don't want to kick off a pointless .NET vs C++ debate (I've been on both sides of that one), but one of the nice things about using C++/CLI is that you kind of get the best of both worlds.  When you're working with a COM-based technology like preview handlers, most of the samples will be in C++.  Since I'm using C++/CLI, I can just copy those right in.

Now since we are writing a preview handler, we need some visualization.  In my opinion, one area where C++ struggles a bit is in building user interfaces.  Win32, WTL, MFC are all great solutions, but I think it is fair to say they aren't the most approachable technologies.

I like using C# for building user interfaces - Winforms for 'regular' interfaces and WPF for more sophisticated ones.  Again, because we are using C++/CLI, we can do that.

To build the user interface for my preview handler, I just create a C# user control library with 1 user control.  Using the designer, I created a simple user control with 1 read-only, multi-line text box.

 

All I'm going to do in my preview handler is dump out some text.  This text is going to come from the Windows Shell through the preview handler infrastructure.  From the point of view of this user control, I don't really care where it comes from, I'm just going to take a string and display it, so I added one method called ShowPreview.

With our UI set, we can go back to the C++.  In order to reference our C# user control we can use the gcroot type in C++/CLI. 

Notice the ^ syntax, that denotes a 'handle' to a .NET object. 

The last bit of funny syntax is the gcnew keyword to instantiate the class.

With the ^ and gcnew, we can use this object just like any other C++ object.  Members are referenced with a -> just like we are used to.

A user control inherits from a Control, which exposes a Handle property.  That gives us a way to get the HWND's that the preview handler interfaces need.

Our user control will be a child of a HWND that is given to use through the IPreviewHandler interface.  A simple call to the SetParent() Win32 method will setup the parent-child relationship correctly.

The last bit of coding necessary is to pass the contents of our file to our user control.

The String class has a constructor that accepts BSTRs so we don't have to do any marshalling.

The end result is pretty basic, but does give an idea into what it's like to build a preview handler.

One of the reasons I decided to try C++/CLI is that I knew that if I got into trouble, I could always fall back to the excellent C# example in the MSDN article that I mentioned earlier :) 

That said, I'm pretty pleased with how C++/CLI gave me a way to mix what C++ and ATL do pretty well (COM, Shell Extensions, etc) with what .NET does pretty well (user interfaces, dnd design, etc).

I know the C++/CLI guys worked really hard on this second release of managed C++, here's to hoping that Vista gives their work an opportunity to really shine.

Thanks!

Eric.

2 Handy Features in VSTE\Software Testers - Transactions and Analysis Notes

Hey guys,

There are 2 features I wanted to call attention to that are really handy in Visual Studio Team Edition for Software Testers.

Small features sometimes go a long way - the Analysis window might become one of those features.  When looking at the results of a Load Test, the context menu for just about any part of those results will give you an Analysis... option.

That option is basically a handy scratchpad for recording your thoughts for the results.  This can really be helpful given that load test results can be very time consuming to analyze.

The second feature is related to web and load testing as well.  One very handy feature about a web test is the ability to group requests into transactions.

Often times, a series of web requests make a single user action.  For example, working your way through a series of registration pages could be thought of collectively as the registration action.  It may be of interest to categorize scalability and performance results based on these actions.

In the web test editor, the Transaction feature is used to do this categorization.  This option is available on the context menu.

Basically, you just choose your begin and end transactions.

Once your transactions are defined, when you run your web test inside of a load test, you can see transaction-based timing information.

This data is available as a table in your load test results.

The information you get on a transaction basis can be very valuable - for example, the load test will gather the average time it took to complete a transaction for you.

Just a couple of handy features that I wanted to share.

Thanks!

Eric.

Quick post about Windows Vista - Thumbnail Provider Sample

One of the things that I fondly remember about working on the Visual C++ team years ago are some of the folks I worked with at the time.  I was relatively junior, and the people on the MFC and ATL libraries teams were quite senior.  What always struck me was how much those guys knew about the inner workings of Windows.

With a new version of Windows to play with - Vista - I've been spending some time plugging away at the plumbing underneath.  Namely, the Windows Shell.  Funny to say that it is 'plumbing' given that it is the most visible part of Windows.  The one thing I've learned about the Windows Shell is that you don't really know Windows until you start programming against the Shell. http://shellrevealed.com is a great site for learning more about the Shell.

I'm hoping to eventually take some of what I learn about the Shell to eventually write a Team Foundation Server Shell extension or two - namely, I'd like to be able to right-click and check out/in.  But also, I would like a preview handler for source files and what not.

One of my first steps towards this is building a thumbnail provider.  A thumbnail provider enables you to tell the Shell to render a specific thumbnail for a file.  That in of itself is nothing new - you could always associate an icon with a file extension.  But Vista takes this to another level.  By inheriting from a IThumbnail provider interface, you can decide what thumbnail Vista should render for each instance of a file type.  It's just another way to deliver information.  For example, in terms of Team Foundation Server, I could imagine writing a thumbnail provider that tells you if a file is checked out or not.

I had been really struggling with getting the Thumbnail Provider sample in the Platform SDK working. 

I'm not sure what I'm doing wrong, but in looking at a few forums, I noticed some other people having the same problem.  I re-did the sample using ATL attributes and for some reason that seemed to have fixed my problem. 

You can get my sample here; hope it helps, suggestions are welcome!

Eric.

A *New* Humble Blog!

Hey guys,

Happy New Year!

I hope everyone had a nice holidays.  I've finally found a new home for my blog - I'll still keep my old blog http://blogs.msdn.com/ericlee up, but all of my new blogging activities will be on this site. 

I've gotten off to a good start with my new company CounterPunch Software.  I've had a chance to do some Visual Studio Team System training through my company and I'm looking forward to doing some more in the New Year.

Since my blog has been in limbo for a while, I've got a few posts that I've been waiting to make.  Look forward to talking to you soon.

Eric.