I will be presenting on this year’s TechEd China for the following topic, if you are interested in ALM (Application Lifecycle Management), Team Foundation Server and Visual Studio; welcome to my session.

Code: DEV-T-200-7

Date and Time: 2011-10-12, 8:30 – 9:30

Location: Room 3

Link: http://technet.microsoft.com/zh-cn/teched2011_session

This is going to be an overview session for all dev-tools session during the TechEd, I will cover the following topics

- Break the wall of PMO to Dev-Team: Project Server 2010 and Team Foundation Server 2010 integration

- Team Management: Process template customization

- Configuration Management: CI, Done Criteria & Quality Control

Sounds like a big session; however the major part I’m going to focus on is the 1^st one, Project Server integration which is pretty new, only introduced to the product since this year’s SP1 release. Base on customer feedback, this is a much demanded feature for TFS to expend its usage to the whole organization and bring real “end to end” solution to customer. There will be detailed demo for managing a dev-team using Microsoft Project 2010 and Project server 2010 and I will do some role play with my colleagues

Many of other great speakers will share other topics, if you are interested in the following topics, you can go to these sessions below:

Architect:

• DEV-T-200-3: Jeffrey Zhou – Understand your system using Visual Studio Ultimate Architect Tool
• DEV-T-200-6: Vision Wang – Case Studies – Improve your enterprise architecture design

Testing:

• DEV-T200-5: Jianbo Li – Functional Testing – Manual Testing to Automated Testing
• DEV-T-200-2: Hao Xu – WebApp Performance Testing and Analysis
• DEV-T-200-10: Darshan Desai/Cheng Yin – Stop “No Reporo”

LightSwitch

• DEV-T-200-8: Suwei Gui – Using Visual Studio LightSwitch to build LBS in 30 mins

C++:

• DEV-T-300-1: Rong Lu – Application Lifecycle Management for C++ in vNext
• DEV-T-300-9: Jason Yang – Visual Studio C++ Code Analysis to improve quality

vNext:

• DEV-T-200-4: Sam Guckenheime/Jackson Liao – Lap around Visual studio 11

Azure:

• DEV-T-200-11: Wei Xia – Developing in the Cloud – the future of software development

Note: We have Sam in Beijing this time, make sure you don’t miss his session about Visual Studio 11, it’s going to be awesome.

The 2^nd day after this year’s MVP Summit in Redmond, just 14 hours after I got back from the U.S, I took another flight from Beijing to South China for a job. The job turned out to be one of the most challenging one that I’ve never done, pushing the performance limit of Team Foundation Server.

Figure: with Brian Harry @ MVP Summit 2011

Some background information first, the client is one of the biggest who also owns one of the biggest development team all around the world, with over 20,000 developers. The system we are developing has to be able to cope such amount of requests, sometime concurrent requests in a timely fashion. We are using TFS Object Model mainly to implement most of the functionalities, and we initially thought TFS should be able to handle the load without problem because Microsoft has been dogfooding TFS (http://blogs.msdn.com/b/bharry/archive/2009/09/04/dogfooding-tfs-2010-in-devdiv.aspx) for a long time in their even bigger and much more demanding environment, and TFS survived. However, like every story, things will never run as you expected; with all the data access, business logic and interfacing implementations on top of TFS Object Model, the initial end result was kind of disappointing.

Test Case	Before tuning	Target
Create Operation
No concurrency	1200 ms	200 ms
10 concurrency	2700 ms	500 ms
100 concurrency	>3000 ms	1500 ms
Query Operation
No concurrency	234 ms	200 ms
10 concurrency	565 ms	500 ms
100 concurrency	3000 ms	1500 ms

Figure: before tuning the performance was kind of disappointing

As you can see from above, all of the benchmarks are offsetting from the target, some of them are even 5-6 time bigger than the target. These results were collected on a SQL database (Tfs Collection DB) with around 500 million data entries.

Shocking? Isn’t it? Yes, I was when I first saw these. But like every story, there is a happy ending, so here is the result after our tuning.

Test Case	Target	After Tuning
Create Operation
No concurrency	200 ms	87 ms
10 concurrency	500 ms	399 ms
100 concurrency	1500 ms	2500 ms (single server) 1500 ms (NLB)
Query Operation
No concurrency	200 ms	28 ms
10 concurrency	500 ms	32 ms
100 concurrency	1500 ms	200 ms

Figure: The client is happy with the results, we made our target in each case. That said, I think we are at TFS 2010 limits

So, back to the topic, the lessons that we learned:

Lesson 1: Team Work

I put this as the top one like always, software developing is ever a one man job especially when you are dealing a complex system, like TFS. You need to know Windows Server 2008, IIS 7, SQL Server 2008 R2 and TFS web services and Object Model. You need expert in every part of these in order to combine them together to achieve your goal.

During the whole project, I got help from Microsoft, my boss and many other MVPs around the world; including Brian Harry (Microsoft Technical Fellow, father of TFS), Aaron Hallberg (TFS DevTeam), Tiago Pascoal (MVP), Adam Cogan (Microsoft Regional Director, MVP, my boss ;) ), Ramesh Rajagopal (DevDiv from MS Shanghai Dev Center), Julia Liuson (Manager of MS Shanghai Dev Center) and Yongming Yi (MS Technical Specialist) … and there is a long list that I couldn’t include all of them here.

To be short, if you want to do the job right, you need the right people. Having such a great team is essential for the end result.

Lesson 2: Performance testing as earlier as possible

We adopted scrum in the whole project and we have built in unit testing and load testing at the very 1^st sprint of our development cycle; however because of resource limitation, we were not able to achieve that much concurrency and gain enough hardware until we are at the very end of the whole project.

Although we were not able to do tunning along the way, the testing results have been given enough transparency to the client, so when the 1^st official test result on top of the staging hardware out, the client was not too surprise and gave us enough time and understanding. To me, transparency is always the biggest benefit of using agile methodologies; having your client support is sometime the best resource you can have in a project.

Another benefit of having performance testing in early was that I had enough time to contact helpful people and gain enough support beforehand.

Lesson 3: Avoid virtualization in demanding production system

To be continued …

 

The 2^nd day after this year’s MVP Summit in Redmond, just 14 hours after I got back from the U.S, I took another flight from Beijing to South China for a job. The job turned out to be one of the most challenging one that I’ve never done, pushing the performance limit of Team Foundation Server.

Figure: with Brian Harry @ MVP Summit 2011

 

Some background information first, the client is one of the biggest who also owns one of the biggest development team all around the world, with over 20,000 developers. The system we are developing has to be able to cope such amount of requests, sometime concurrent requests in a timely fashion. We are using TFS Object Model mainly to implement most of the functionalities, and we initially thought TFS should be able to handle the load without problem because Microsoft has been dogfooding TFS (http://blogs.msdn.com/b/bharry/archive/2009/09/04/dogfooding-tfs-2010-in-devdiv.aspx) for a long time in their even bigger and much more demanding environment, and TFS survived. However, like every story, things will never run as you expected; with all the data access, business logic and interfacing implementations on top of TFS Object Model, the initial end result was kind of disappointing.

 

Test Case	Before tuning	Target
Create Operation
No concurrency	1200 ms	200 ms
10 concurrency	2700 ms	500 ms
100 concurrency	>3000 ms	1500 ms
Query Operation
No concurrency	234 ms	200 ms
10 concurrency	565 ms	500 ms
100 concurrency	3000 ms	1500 ms

Figure: before tuning the performance was kind of disappointing

 

As you can see from above, all of the benchmarks are offsetting from the target, some of them are even 5-6 time bigger than the target. These results were collected on a SQL database (Tfs Collection DB) with around 500 million data entries.

Shocking? Isn’t it? Yes, I was when I first saw these. But like every story, there is a happy ending, so here is the result after our tuning.

 

Test Case	Target	After Tuning
Create Operation
No concurrency	200 ms	87 ms
10 concurrency	500 ms	399 ms
100 concurrency	1500 ms	2500 ms (single server) 1500 ms (NLB)
Query Operation
No concurrency	200 ms	28 ms
10 concurrency	500 ms	32 ms
100 concurrency	1500 ms	200 ms

Figure: The client is happy with the results, we made our target in each case. That said, I think we are at TFS 2010 limits

So, back to the topic, the lessons that we learned:

 

Lesson 1: Team Work

I put this as the top one like always, software developing is ever a one man job especially when you are dealing a complex system, like TFS. You need to know Windows Server 2008, IIS 7, SQL Server 2008 R2 and TFS web services and Object Model. You need expert in every part of these in order to combine them together to achieve your goal.

During the whole project, I got help from Microsoft, my boss and many other MVPs around the world; including Brian Harry (Microsoft Technical Fellow, father of TFS), Aaron Hallberg (TFS DevTeam), Tiago Pascoal (MVP), Adam Cogan (Microsoft Regional Director, MVP, my boss ;) ), Ramesh Rajagopal (DevDiv from MS Shanghai Dev Center), Julia Liuson (Manager of MS Shanghai Dev Center) and Yongming Yi (MS Technical Specialist) … and there is a long list that I couldn’t include all of them here.

To be short, if you want to do the job right, you need the right people. Having such a great team is essential for the end result.

Lesson 2: Performance testing as earlier as possible

We adopted scrum in the whole project and we have built in unit testing and load testing at the very 1^st sprint of our development cycle; however because of resource limitation, we were not able to achieve that much concurrency and gain enough hardware until we are at the very end of the whole project.

Although we were not able to do tunning along the way, the testing results have been given enough transparency to the client, so when the 1^st official test result on top of the staging hardware out, the client was not too surprise and gave us enough time and understanding. To me, transparency is always the biggest benefit of using agile methodologies; having your client support is sometime the best resource you can have in a project.

Another benefit of having performance testing in early was that I had enough time to contact helpful people and gain enough support beforehand.

 

Lesson 3: Avoid virtualization in demanding production system

To be continued …

 

The longest holiday in the past week made me really bored, so I decided to try a little bit of new. Build a iPhone development machine and try some iOS programming, should be fun.

 

After some research on internet, I found out that although installing MAC OSX on my Laptop (ThinkPad T61) was possible, it would be difficult to enable all hardware due to lack of driver. Having found that, I did still give that a try and failed after 3 attempts, soI decided to give up and choose a proven workable path: installing it on a vmware virtual machine image.

 

Here are the required packages you need to download before heading off:

• Darwin.iso – you need this file to be the bootable image and load your OSX installation ISO below; this file is also required to boot up your virtual machine once it’s installed and ready to use. So keep it in the same directory of your VM HD images.
• OSX Snow Leopard Disk image: this is the OSX installation disk image.

you can download this file from VeryCD: http://www.verycd.com/topics/2765539/

• VMware drivers for OSX: there are 3 of them

 

The Darwin.iso and VMWare drivers can be downloaded here:

http://cid-738185eeb137555c.office.live.com/browse.aspx/OSX-Vmware?permissionsChanged=1&1

 

Step 1: Convert the OSX Snow Leopard Disk Image to ISO image

The downloaded image will be in .dmg format which couldn’t be attached to a vmware machine directly, so you need to use UltraISO to convert to a ISO image, you can download UltraISO here:http://www.ezbsystems.com/ultraiso/

 

Step 2: Create the VM

Open VMWare Workstation and choose “Create New Virtual Machine” in the welcome screen and choose “Custom (Advanced)” mode in the 1st of screen of the wizard:

 

 

In 2nd screen, choose “Workstation 6.5-7.x” as the Hardware compatibility level

 

 

In “Guest Operation System Installation” screen, choose the darwin.iso as the installer disk image; DO NOT choose the ISO you converted from the Leopard dmg file, this file will be used later.

 

 

In “Select a Guest Operation System” screen, choose “Other” and “FreeBSD”; there will be no Mac OSX option, we need a little trick to get this in there.

 

 

Give your machine a name,

 

 

Give your virtual machine 1 processors and on 1 core, 1024MB (1G) of RAM

 

 

 

In the “Network Type” screen, you should choose bridged networking if you are connecting to a LAN environment, if your host machine is using dial up to access internet, you should use NAT. 

 

 

Keep default settings to other screen and choose to create a new virtual hard drive, make it at least 40 G. And place the virtual hard drive in the same folder with your darwin.iso and your virtual machine configuration file.

 

 

Once the machine is created, use notepad to open the .vmx file.

 

Edit the line for “guestOS” make it to be “darwin10” which is MAC OSX.

 

guestOS = "darwin10"

 

Once this is done, restart VmWare Workstation and and open the VM setting dialogue, you will see “Mac OS X Server 10.6” showing in the version drop down.

 

 

Step 3: Installation of Mac OS X

 

Now, start up the virtual machine you just created, pressing F8 during the start up and the machine will show you the options to load your OSX installation ISO.

 

 

Click the little disk icon on the bottom right of the window and replace the darwin.iso with the Leopard installation ISO.

 

 

When you hit “Ok” in above screen and back to the vm, press “c” to allow the disk to load.

 

The virtual machine should load the OSX installation program and the 1st thing you need to do is to use “Utility-> Disk Utility” to creat a new partition for Mac OS.

 

 

Once this is done, the rest are pretty straight forward, just follow the instruction and you will be fine. The whole installation will take around 30 mins to finish.

 

 

Step 4 : Switch your bootable device to darwin.iso

 

Once the installation is done you should attach the darwin.iso back to the vm in order to boot up the machine because the HD won’t be able to boot on vmware directly.

 

 

Step 5: install VMWare drivers and Addon

 

Open Safari and open http://cid-738185eeb137555c.office.live.com/browse.aspx/OSX-Vmware?permissionsChanged=1&1

Download VMDRIVERS.zip file, and install the following two files

• vmsvga2.pkg – Video driver
• EnsoniqAudioPCI 2.mpkg – Sound driver

 

 

The installation requires you to reboot, then you will be able to switch resolution and using sound.

 

Step 6: Install XCode

 

XCode and iOS SDK can be downloaded from http://developer.apple.com, the download require you to register and you will need to update your OSX system before able to install them.

 

This download, update and installation will need another 1-2 hours to finish depending on your network condition. Finally, you can run Xcode and say “Hello World” to your free iPhone 4.

 

Enjoy  

 

 

End and Beginning of a new journey

 

http://developer.apple.com provides very comprehensive materials for you to learn Object C and iOS programming, and you can use iTune U to download the iPhone Development course from Stanford university which is a very good resource to get started.

 

Note: VmWare does have a known issue that if you leave your OSX VM unattended for a while, it will lose focus and becomes unresponsive, just be careful of this, save your work asap.

Unit Test is a very important aspect in Agile development, it plays a central role in CI and quality improvement process. The main purpose of Unit Testing is to make sure the logic of your code is adhere with the requirement, and continuously ensure the consistency during your application lifecycle. It makes possible to run regression test easily and this is very important when your application becomes very complex, a single line of code change may affect some other already implemented logic hidden somewhere that couldn’t be found easily by human eyes.

 

Therefore, you should encourage your developer to write as many unit tests as possible, you can also use code coverage to measure their effort easily. With Visual Studio 2010 and Team Foundation Server, this could be easily done by enable code coverage in the test configuration file.

 

But there comes a problem, when your project is running for a while, you will find hundreds or even thousands of unit tests in your project, make them very hard to maintain. When a test breaks, people will ask the question:

 

- How would I know which one is correct, either the unit test itself or the code?

 

This leads to a fundamental problem in testing, how would I ensure the test itself is correct, or how would I tell what is the test’s intention. It may be easy to answer such a question to ask the people who wrote the test, but what if the person is not available? Then you can only rely on the documentation to figure this out. Instead of write comment, you should write your unit test method name as the following format:

 

[ObjectToBeTested]_[MethodToBeTested]_[ExpectedResult]

 

This way, you can tell the purpose of the test with a quick glance. Also, when the test is showing in “Test View” in visual studio, the only information you can see is the name.

 

There are some scenarios you need to consider:

1. When test breaks, the developer should read the name to understand the test first; then read the code to make sure the test itself is correct according to the name suggests;
2. If the requirement keeps the same, the developer should fix the production code to make the test passes;
3. if the requirement has changed, the developer should first update the unit test itself; run the test again to see if the new production code is correct.

 

Point 3 is actually asking the developer to follow TDD; so a better way to do this is make sure the developer always check the impacted tests before making changes to the production code. This could be done by using the Test Impact View in Visual Studio 2010, this new feature will help the developers to find the affecting tests when they changes the code.

 

In unit tests, don’t worry about the length of the name, make it meaningful enough is the most important thing.