Colin Thomsen's Microsoft Blog : Microsoft

Tech-Ed 2008 Wrap-up

colinth — Wed, 11 Jun 2008 01:34:00 GMT

Quite a few people at Tech-Ed wanted to know more about the various components of Visual Studio Team System (which we sometimes refer to as SKUs). For example, how does Team Foundation Server (TFS) fit in with the client SKUs? What are the differences between Visual Studio Team System Development Edition and Visual Studio Team System Test Edition? What is Visual Studio Team Suite?

These are very valid questions when you're considering which SKU to buy and since I'm not a sales or marketing guy I'll defer to some nice diagrams and comparisons already available on the web:

Visual Studio Team System Overview - a diagram that shows all the pieces of Team System.
Visual Studio 2008 Product Comparison - compare flavors of Visual Studio across many different categories.

While we were demoing at Tech-Ed we were giving out trial versions of Visual Studio 2008 Team Suite, with some detailed tutorials (called Hands-On Labs) and they were very popular. If you'd like to try out the Virtual PC Image as well, download it here.

Some of my colleagues at Microsoft were interviewed for a panel discussion about various aspects of Team System which is worth watching to see where Team System is heading (Visual Studio Team System Panel - Meet the Team).

I also managed to catch a few sessions at Tech-Ed and one of the more interesting talks was about Visual Studio 2008 Tip of Day. Each day for more than 230 days now, Sara Ford has been posting blog entries with tips for Visual Studio.

UPDATE: I forgot to mention an interesting series on Channel 9 that I found out about while at Tech Ed. This Week On Channel 9 covers some of the highlights from Channel 9 blogs, articles and videos. The focus is on the developer, which works well for me. The current episode talks about PDC, Pex, Build Bunnies, UltraCam and the Live Agents SDK.

Tech-Ed 2008 Demos

colinth — Tue, 03 Jun 2008 06:25:50 GMT

Last year my boss took a trip to sunny Orlando to present at Tech-Ed and to offer help and suggestions in the Technical Learning Center (TLC). This year I'm lucky enough to be attending with a couple of other folks (Habib and Tim) and since I'm not an official Speaker I'll be spending most of my time hanging out in the Application Lifecycle Management (ALM) demo station for Visual Studio 2008 Team System, Development Edition.

We've prepared a few demos covering things like:

Profiling using Instrumentation Mode on a Virtual PC image.
Collecting Allocation and Object Lifetime information.
Analyzing Performance Reports.
Using Code Analysis to improve your code.
Enabling Code Analysis Check-In Policies.

We're also looking forward to discussing your specific scenarios so if you're at Tech-Ed and interested in diagnostic tools and solving performance problems we'd love to chat with you.

Performance: Inserting Marks Using Code

colinth — Thu, 01 May 2008 17:55:00 GMT

Ian previously covered using the VS 2008 Data Collection Control to choose when to collect data. The Data Collection Control can also be used to insert marks into the performance report, but sometimes it is convenient to modify the source code to do this automatically.

Consider a typical application (PeopleTrax) where I am interested in gathering profiler data only between when a button is clicked and when data is displayed. The application is shown below.

After the 'Get People' button is clicked, data is displayed after just over 6 seconds. This seems a little excessive so I want to focus my performance investigation in this area.

To filter the data so that it only shows information collected between those two points, I could use the Data Collection Control, but maybe I'm planning to run a complicated scenario and don't want to have to remember to insert the marks manually. Instead, it is possible to modify the original code to request the profiler insert marks in the required locations.

The Profiler API is available for managed code in an assembly that can be added directly to the project from \Program Files\Microsoft Visual Studio 9.0\Team Tools\Performance Tools.

After adding the reference it shows up in the 'References' list for the PeopleTrax project.

I can then use functions in the Profiler API to control the profiler. This might include starting or stopping data collection or in this case, inserting marks into the datastream. This is easily achieved as shown below.

I can then profile the application and when I open the Performance Report and switch to Marks View I see that the marks have been correctly inserted. We can also see that the time elapsed between the marks is about 6.5 seconds, which corresponds with the measurement that is already displayed in the PeopleTrax UI.

I can use the marks to filter the report to only show profiling data for the time between the two inserted marks and then start my performance investigation.

Visual Studio Team System Chat – December 5th

colinth — Wed, 21 Nov 2007 22:04:00 GMT

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

We will be holding two sessions:

Join the chat on Wednesday, December 5th, 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

-and-

Join the chat on Wednesday, December 5th, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

---

I'll be in the Wed 4 pm - 5 pm chat to answer any questions related to profiling. Another member of the profiler team will be online for the earlier chat.

---

Microsoft Blogs I Read

colinth — Tue, 16 Oct 2007 21:50:00 GMT

There are a lot of Microsoft bloggers, literally thousands of them. When I first joined Microsoft I wasn't sure who to read. I've gradually built up a list based on interesting product and feature announcements and people I've met. Here they are:

Profiling

Our Team Blog
IanWho's Blog. Written by a fellow dev on the profiler team, Ian has probably written the most about profiling across the team.
joc's bLog. Written by my bosses' boss.
mgoldin's blog. Written by a senior dev on my team. Find out about the difference between different types of samples etc.
My Code Does What?!. A relatively new blog about profiling by another fellow dev.
scarroll's Blog. Written by my boss.

Technical

bharry's WebLog. Written by a Technical Fellow (read more about this) with a huge amount of experience who has a big focus on TFS.
Greggm's Weblog. Written by a senior dev on the Debugger team. Has many advanced debugger tips.
Mark Russinovich. Mark wrote some cool Sysinternals tools and now blogs some fascinating posts about his investigation into problems he finds everyday just using his PC.
Rico Mariani's Performance Tidbits. Written by a senior Microsoftie who has been here for a long time. Gives tips for analyzing performance and provides guidelines to use in writing .NET code.
ScottGu's Blog. Find out about LINQ, ASP.NET AJAX etc. etc. This blog has many examples including screenshots and source code.
Somasegar's WebLog. As the corporate VP of DevDiv, Soma covers a lot of Visual Studio features and other developer tools.

Other

Microsoft International Tech Jobs. I keep an eye on Microsoft's international opportunities here.
Microsoft's JobsBlog. Discusses many aspects of Microsoft's recruiting. Covers the Vancouver office developments and has tips for prospective Microsofties.

That's just some of the Microsoft blogs I read. Are there other 'must-reads' that I'm missing?

The Honeymoon Is Over

colinth — Fri, 28 Sep 2007 17:39:00 GMT

I've been here at Microsoft for more than 6 months so I guess you could say that I've passed through the Honeymoon Phase. By now the initial joy and excitement should be starting to wear off and I should be settling into a monotonous routine.

Well I'm happy to say that it hasn't happened so far. I'm still learning a lot, including things like:

Shipping big products is fun. We get to think about cool new ideas and some of them we implement and some of them get implemented by other smart folks.
Shipping big products is hard. We have to worry about things like localization, corner case scenarios and crashes that smaller products just don't need to consider. All of this takes time and there can be periods of time where you're fixing strings or working in high-contrast mode.
Our debugging tools are cool. For most of the bugs I need to fix my primary tool is Visual Studio. It is a good sign that even working with less stable dogfood versions is better than using another tool.
Bug/Feature Triage is important. We have so many people using our products that all kinds of bugs are reported, from serious (crashes) to suggestion (please improve this feature by...). If we did everything that was asked of us, we would never have a stable version to release. However, triaging can be much more lenient in the early stages of development. Here we go through stages:

Code review - any change you make must pass a code review. The reviewer might say 'hey, why are we fixing this bug!' and it may not be accepted.
Tell mode - closer to a release our team leads will go along to a meeting (called a shiproom meeting) and they will say "hey, we're fixing these bugs". If a lead goes along and says "we changed the font size from 9 to 10 points" without a good reason there might be some raised eyebrows.
Ask mode - even closer to release, before a bug is submitted, it has to go to the shiproom and be approved. Usually there are only certain classes of bugs that will be approved (blocking bugs, localization bugs, etc.). It is important that this 'bug bar' is known so that developers/leads know whether to attempt to fix a bug or not.

All of this means that the number of bugs we fix gets fewer closer to a release, which means the product has time to stabilize and be thoroughly tested. At the same time, more minor bugs get a chance to get fixed early in the release cycle.

Company Meetings are exciting. There was a lot of shouting, collective back-slapping and cool demos. It was amazing that 1/3 of a baseball stadium was all from the same company.
Seattle summers are great. There is so much talk about how rainy Seattle is, but over summer the weather is warm but not really hot and it doesn't rain all that much. Daylight hours are long and it is perfect for getting out and about.

I also like hearing about new features and products and being able to try them out before they're distributed to customers. Let's see how the next 6 months go.

Developer Dogfooding at Microsoft

colinth — Thu, 07 Jun 2007 21:24:00 GMT

I hadn't heard the term dogfooding used much before I started here, but it has already been explained so take a look here. The basic idea is that if you're not happy using your product (i.e. eating your own dogfood) then why should you expect your customers to be? Working at Microsoft gives you incredible scope to dogfood a wide variety of products.

As a Microsoft employee, I should be using Internet Explorer, Vista, Office, etc etc and I am. This doesn't necessarily mean I shouldn't run alternative products as well or when a Microsoft product doesn't provide the functionality I need.

As a Microsoft developer, I should be using Team Foundation Server for bug tracking and source control. I should be developing Visual Studio using Visual Studio. I should be profiling my code using VSTS profiling tools. Fortunately, I am, although not exclusively and probably not in some other parts of the company.

The main reason I think this is a good idea is because we get to feel any of the pain that customers do. We have extra incentive to fix any problems instead of ignoring them. We often catch problems early on before customers even see them.

I'll admit it, the process can be painful. The pain typically increases as you get closer to the bleeding edge of technology. For example, my Visual Studio dogfooding experience involves running the latest build of VSTS while developing. There are issues which delay my development, but facing these issues every day helps me drive improvements to the product. Imagine if your source control system went down - you'd want it fixed pretty quickly and that's just what we want from our TFS dogfood server.

Here's a few of things that I think need to happen for successful dogfooding:

The process must not be voluntary. As an individual dev I must use a pre-release version of TFS. As a Microsoft employee my computer is automatically updated to use the latest updates before they are pushed out to customers. There isn't a choice.
There must be a feedback mechanism. If things are broken it must be easy to report this and critical breaks must be fixed quickly.
Things must actually get better. Limit the audience for really unstable dogfooding. For example, we don't make devs outside the VS team build their own VS from last night's source. They get a 'Last Known Good' build of a release that has had extra testing carried out on it.

If you're an application developer, are you using your own alpha/beta software before it is released to the public?