Welcome to MSDN Blogs Sign in | Join | Help

Syndication

Sending Out of Office Information

This is so simple and useful that I don't know why we don't use it more.

If you want to tell people in your team of your vacation time then rather than send a mail you can send an appointment with the time marked as free. You can even mark no response required.

This will update your calendar and other's with your time off without blocking up the calendar itself.

Here's how

From the Calendar, click New:

image

Fill in the appointment details and make sure to mark the time as Free as well as marking as all day event

image

Add the people you want to know you are out of the office.

(optionally) Once you have added these people on the Scheduling tab the 'Attendees' section will appear in the ribbon.

If you don't want people to respond just click the 'Responses' icon shown below.

image

Hit Send and you're all set! If people don’t care they can delete the request, otherwise they can see your time off as a nice bar at the top of their calendar.

image

So the ask to the Outlook team is: Please make this easier and integrated with setting my out of office assistant :)

Posted Wednesday, December 19, 2007 6:23 AM by conorm | 1 Comments

Visual Studio Team System Case Study - Multidomo

Recently, when on a trip to Tech Ed Barcelona (LINK) myself and Marc Popkin-Paine visited Multidomo, a home automation software company and Team System user in Madrid, Spain.  My contact in Multidomo is Luis Fraille who is a Microsoft MVP.  We visited their site to better understand their work environment and how they were using TFS to help with their application lifecycle.  This is a fairly long post so you may just want to read the overview at the start and conclusions at the end.

Overview

Multidomo is a software company that builds home automation software. It allows you to control various devices in the home from your computer or across the Internet.  There is a demo on the site where you can turn on and off lights and move blinds in the house.

The Company

This is a small business with only 2 employees, Luis and David (was 3 previously). They hire the services of a designer for some of the UI. The main office is just in the home of one of the employees. This home is also set up with all the home automation you could think of with lights, blinds, ac units, garden sprinkler, front door etc. all wired up with X10 or EIB protocol devices to allow them to be automated. The latest version of their software is always running in the house so they get self-host test regularly. There is also a web page where users can play with some devices in the house.

David works on a desktop machine that is also connected to the devices. Luis does all his work on his laptop and works mostly from David's home but sometimes he works in his apartment in the center of Madrid.

The setup at home consists of a server machine in the basement and a main automation machine in the top floor. There is also a media center PC in the living room. The system exposes some web services and these are hosted externally by a company in Miami, FL.

Software Overview

Functionality

There are multiple clients for accessing the system.

  • A Media Center front end (client) - this is implemented in MCML (and was very difficult to achieve). The end result is a very slick and usable front end.
  • A PDA client - this works on the smart phone or a regular pocket PC. It works very nicely when driven from the HTC touch. There are some ideas of future versions for Symbian OS.
  • A web client - this uses Silverlight technology, Ajax and PSP.
  • A web administration front end - this allows users to be managed etc.

These can list all the devices in the system and allow you to control them. For example, for web cams you can connect and retrieve the image shown on the camera. For blinds you can move them up, down, or some preset openings (25-75% open). 'Atmospheres' can be programmed which are named presets for the devices. For example, movie mode could dim the lights in the living room. There are also programs which can be executed through a simple workflow-like engine. For example there is a program for opening and closing the doors into the driveway. This is combined with a delay to implement open, wait, close. There is a simple interface for building sequences of actions.

Design Overview

The devices conform to X10 or EIB protocols for home automation. These are driven through an WCF web service which exposes all the operations for the devices. The client code provides front end and builds requests to the appropriate web services then interprets the results.  Communication is WCF throughout, except for some video appliances and some ASMX services for terminals not usable with WCF.  In those cases sockets are used.

Code Organization

They work off 4 different solutions and have one branch:

  • A solution with 49 projects that contains all the client code. These are placed in solution folders and nested according to the component breakdown of the system
  • A solution for the Media Center project
  • A solution for the Silverlight project
  • A solution for the database project
  • A solution for terminals like mobile devices

Debugging

  • For debugging Luis prefers attach to process for web projects (as he doesn't need to compile them usually).  For Media Center he uses attach to process since there is no other way.  For the rest of the projects he uses the traditional approach of F5.
  • Luis uses the aspx design view to find the control then the properties page to find the binding.
  • Luis uses (and likes) the visualizer for data set.
  • Luis also keeps dbgmon open so that he can easily monitor the trace output whether or not visual studio is running.

VSTS Usage

  • They use the source control for all code and are not branching.
  • They are using the document folders and the Sharepoint site for their docs (there are not many docs).
  • Architecture documents were created early in the design process (including UML sequence diagrams) but these were not kept up to date.
  • They are using a modified SCRUM template and are very happy with the work items.
  • They didn't think the supplied reports were very useful.
  • They have many areas for the work items to quite a fine degree of granularity. They use the iteration field to track the product version and tag work items based on sprints. The sprints are numbered consecutively through a manual update of the appropriate work items (in sprint planning).
  • When they had the designer doing work they created the work items and hooked up to Excel. The designer would then update the file and send it back via email for upload.
  • Work item check-in policy is enabled so that all check ins should be associated with a work item.
  • They use team build and have customized the build quality field to their needs (so they can indicate what has been done with the build: upload to main servers, upload new web front end only etc.)
  • They are planning to use build retention in 2008.

Typical issue resolution workflow

When we visited they were starting some work to plan out the next iteration and reduce the backlog of work items.  The list below is typical of how they handle smaller issues.  Code is shared rather than owned although there is a concept of owner/author in that each person has areas that they worked on mostly and are the expert for but everyone touches everyone else's code and makes fixes in the code.

  • Luis starts from the work items and looks at all the issues for all 3 people to pick up new work.
  • Moves the work item to in progress
  • Start debugging the issue
  • Luis browses through the source files (rather than using find in files)
  • Fix the issue and ad-hoc manual test
  • Associate work item with check in
  • Check in and launch build
  • On build complete copy all to 'staging' file share.
  • Manually deploy and verify
  • Mark the work item to Done and ping David to verify the fix.

Issues

We saw a number of issues as we watched Luis work.  We are following up on these internally.

  • In MSDN there is a lot of documentation and sample code for individual technologies but not for solutions. The samples are too narrow.
  • In the media center part of the product they would like to stream the web cam. This cannot be done because media center markup is not supporting it.
  • In media center it would be useful to customize the info menu for example to give a 'dim lights' option while watching a movie (instead of having to go to another menu system to get it).
  • Silverlight install is clunky (compared to flash). If you implement a web site with Silverlight you risk the user abandoning trying to reach your content.
  • In solution explorer with solution folder, if you nest them then the expand opens all sub-folders on first click.
  • In team build, when you build it does a force get of everything. This really slows down the build process. Get takes 10 minutes for the large project.
  • In the document window for Java Script (.js) files, the highlighting is very slow.
  • MCML Pad is a poor debug and design experience compared to something integrated in the VS IDE.
  • When there are 3 web applications in the solution, if you attach to one of them then the other 2 are started as well for some reason.
  • After creating a profile of over 2Gb and then stopping the profiler and closing the project, devenv.exe was ratcheting up memory.
  • When running a web test on a page that has Ajax, the browser doesn't show the page.
  • Miscellaneous issues with recording a test on a page that has Ajax.

Conclusions

This is an interesting usage of Team System. Since the company is so small it seems that TFS would be more than is needed and overly heavyweight. Instead, Luis is a strong proponent of TFS and sees it as adding value, even in this small a company. Of course the source control is a significant feature that adds value even to one developer but also of value is the process template, work items and team suite tools.

By using the process template Luis was able to get started easily and customize according to the team needs. The result is a lightweight process and correspondingly lightweight work items - he never even opened the work item since the preview has enough space for his entire work item form.

With only 2-3 people they still get the benefit of the centralization of work and ability to track. This is particularly true when they include their contracted-out work in the list.  They easily and efficiently tracked the designer work using Excel hooked up to work items.

From the development and test sku they are using code metrics, code analysis, profiler (with a bunch of saved traces) as well as debugger of course. They also use web and load testing from the test sku and have found particular value in the DB sku from the schema diff tool. The checkin policy also helps them keep track of which change corresponds to which work item. 

Another big motivation for their usage is that they are starting to grow. Whereas now they all trust each other and liberally share code and have completely open checkins, in the future they will expand to a larger team and so Luis is keen to have the pieces in place for more control and tracking as soon as new people come on board. For example, he could create a private branch for the new hires to work in as they get up to speed or he could add more policy around check in such as requiring a code review or having code analysis rules applied on checkin.

Posted Tuesday, December 11, 2007 4:54 PM by conorm | 4 Comments

TechEd Europe 2007 - TLA 307 Demo Code

This post contains the demo code for TLA 307 presentation at TechEd 2007. 

Note: One demo, The Beer House exceeds the maximum permissible size for attachments on this blog so has not been uploaded.

Posted Tuesday, December 04, 2007 6:20 PM by conorm | 3 Comments


Attachment(s): TLA 307 - Demo Code - Upload.zip

TechEd Europe 2007 - TLA 329 Demo Code

This post contains the demo code for TLA 329 presentation at TechEd 2007.

Posted Tuesday, December 04, 2007 5:59 PM by conorm | 1 Comments


Attachment(s): TLA 329 - Demo Code Zip.zip

TechEd Europe 2007

I recently attended TechEd Europe in Barcelona, Spain.  This was my first Tech Ed and was a great experience.  Myself and Marc Popkin-Paine shared two talks:

1) Writing Maintainable and Robust Applications

This talk covers the tools available in the developer edition SKU of team suite.  This includes the Profiler for finding performance issues, Code Analysis for analyzing your code for common issues, Code Metrics for reporting on the scale and structure of your code and Unit Testing with Code Coverage.  There are plenty of demos to keep it real.  We hope you find the information useful. 

Slides Video Demo Code

Link to slide deck

Link to Video

Timeline

Topic Intro Demo
Code Analysis 7:54 11:35
Code Metrics 26:53 35:43
Profiling 41:25 43:57
Unit Testing w/Code Coverage 51:21 53:10
Profiling w/ a Unit Test    
Demo Code

 

2) Improving Code Performance with Microsoft Visual Studio 2008 Team Edition for Software Developers

This talk covers the many ways you can use the profiler to instrument your application performance and find issues with your code.  This includes instrumentation to trace every single call, sampling to periodically snapshot the call stack while your application is running and memory allocation profiling to track your allocations and object lifetime.  There are lots of demos in this talk also.  We hope you find the information useful.

Slides Video Demo Code

link to slide deck

Link to Video

Timeline

Time Topic
2:23 Performance Lifecycle
6:00 Quick Profiler Demo
14:45 Profiler 101
19:45 Allocation Profiling and Sharing what you've Learned
27:50 Web/Load Test and Comparing Data
36:50 Narrowing In
50:00 Tips and Tricks
Demo Code

Posted Tuesday, November 20, 2007 8:32 PM by conorm | 0 Comments

Code Metrics as Check-in Policy

This is the first in a series of posts around questions I am getting asked related to code metrics.

One question that is coming up is:

Can a check-in policy be defined based on code metrics in TFS?

Well, code metrics itself does not have a check-in policy but fortunately the Maintainability Index, Class Coupling, Depth of Inheritance and Complexity metrics are all available as rules in Code Analysis in Visual Studio.  This means you can use code analysis check-in policy enabled with those rules.  The rules are grouped under the "Maintainability Rules" Category and are configured as follows:
 

Metric Corresponding Rule Threshold
Depth of Inheritance CA1501 AvoidExcessiveInheritance Warning at above 5 levels deep
Complexity CA1502 AvoidExcessiveComplexity Warning at above 25

Maintainability Index

CA1505 AvoidUnmaintainableCode Warning at below 20
Class Coupling CA1506 AvoidExcessiveClassCoupling

Warning at above 80 for class and above 30 for a method

In the policy editor this would look like the following:

Policy dialog image

This allows you to enforce that code meets these thresholds before check-in.  In future we are looking in to allowing the threshold values to be changed.

Posted Thursday, November 15, 2007 2:06 AM by conorm | 2 Comments


Attachment(s): VSTS.pptx

Page view tracker