Do you remember when it was not cool to be a geek?
Not that I ever let it bother me. I have attended every PDC since 2001. It’s tough to be the coolest guy out of 8000.
Now a days it's cool to be a geek , people are coming out of the wood work to proclaim their geekyness with pride. Below are three examples I came across in the past few weeks.
1. A developer who changed his girlfriend’s favorite game (beleweled) so when she achieved a certain score it displayed display a proposal of marriage.
2. I remember when that one kid in a class with a laptop was the geek. Who’s the outcast now? 
3. Cat 5 Wedding rings, need I say more.
On Feb 7th ObjectSharp hosted a free event at the Paramount Scotia Bank Theatre downtown. The morning after one of this winters largest snowfalls 160 people showed up for a morning of what's new in Visual Studio 2008. I did a piece on VSTS and TFS 2008. My slides are attached.
Even with the snow the event turnout was great, thanks to everyone who ventured out. I hope you enjoyed it as much as we did.
A few pictures were taken at the event you can view them here.
Living in Canada I don't get to the Desert very often. I have always been under the impression it doesn't rain there very often. So on my first trip to the desert what does it do? Rain, the whole weekend. I was in Palm Springs attending a conference, which was a bit different for me. I have been to many conferences in my time; however I normally attend developer conferences like Microsoft's PDC and Tech Ed, DevTeach and in the past Client Server World. This time it was Lab Automation 2008.
I was there to help one of our clients, Thermo Fisher Scientific. Thermo is showing off some new software that allows its users to define and execute an automated Laboratory. Thermo is a leader in this space, and this is the next generation of their Lab Automation Systems named Momentum. I have wanted to Blog about this project for some time now but couldn't say anything until the show made it public. Now that the show has taken place, and the world knows how cool Momentum is, I can talk about it. J
I have worked on some cool projects in my 25 years of software development; this is definitely in the top 5. Thermo has built a Software Factory that allows their clients to create laboratory automation systems that can be configured to execute experiments using any vendor's instrument. In the world of Lab Automation there are hundreds of instruments that perform various tasks, from changing a plate's orientation to filling it with a compound. For the Lab Automation conference we created a demo that helps illustrate what Momentum can do. I took a short video before I left for home. In the video below you see three robots that are executing a process which is moving a plate from one location to another. Then when an conference attendee drops their plate into the shoot a bar code reader detects the plate and instructs momentum to add another process to the run which returns the attendees plate along with a plate containing a prize. How cool are Robots!
[youtube]http://www.youtube.com/watch?v=rMpwqRjSSkE[/youtube]
In case you haven't heard ObjectSharp is hosting a free VS2008 What's hot and what's not event at the Paramount Theatre downttown on Feb 7th 2008.
It's going to be a lot of fun. Our graphics guy has been busy making movie posters for the event. They are wonderful not to mention very funny.
Check out Rob Windsors Blog he explains wonderfully.
The Team Foundation Build Server at one of our clients was getting out of hand. We set up continuous integration so we are getting a lot of builds per day. The server had hundreds of builds that we just didn't need hanging around anymore. We asked our IT guy extraordinaire, Max if he could write us a script to automate the cleanup of TFS Builds. He rose to the challenge and now we have one.
He wrote the VB Script attached to this post. I tried it out on the server last Friday and it worked great. Here is the command to call it.
cscript TFSBuildCleanup.vbs http://<Server>:<port> <Project> <Build Location> <BuildType> <Days>
- Server = Team Foundation Server
- Port = TFS port
- Build Location = Folder that contains the builds on the server (ie: c:\Builds)
- BuildType = Name of the build Type to remove
- Number of days of build to keep. If you put seven it will remove all the build 8 days and older.
I set it up as a task on the build server to run each night.
I hope it's useful to someone out there.
I have been using a tool that is new to me. I am very impressed and would like to share my experience.
The product I am talking about is GoDiagram from Northwoods. I of course am using the .net version there is also a Java and MFC version of the product.
The tool is used for creating diagrams and also includes a library of Instruments, if you buy the right license.
The object model is a little complicated at first but there is a good document that comes with the product that explains the architecture, I recommend reading it before you begin it really helps to set the stage.
The documentation is OK, but could be better. However Northwoods makes up for that via support. Their online forum is watched very closely and responses are very quick and helpful. I called and left a message the other day and someone called me back. We chatted for ages, he gave me his email and personal number. They are so eager to help its very refreshing. The other wonderful support tool they have is their samples. When you install you get a bunch of samples, with source code. They have been a great help in learning the tool.
It's amazing how powerful and flexible this product is. If you have a need to create any kind of diagram or free form drawing tool I highly recommend it.
Some of my favorite features include:
- Overview: A control that duplicates your diagram in a smaller window with zooming and scale changes of the main diagram.
- UndoManager: Automatic undo and redo capabilities.
- AutoLayout: Costs extra but it's worth it. AutoLayout does just what its name implys. It will automatically organize your diagram for you.
- Images: With the GoImage object you can easily add graphics to your diagram.
- Flexability: You can create your own Node and Link classes and they can look and behave any way you want them to.
If you have a need for such a product, do yourself a favour and make sure this product is on your list to evaluate.
I recently found out that my favourite XP Background was a photograph taken in Burlingto ON, Canada, my home town. A friend of mine pointed out this article in the Toronto Star.
Imagine that!?
Did you know there are two ways to Deploy files to be used when executing unit tests in VSTS.
You can added them to the .Testrunconfig:
Or using the DeploymentItem attribute on the TestMethod:
[TestMethod,DeploymentItem(@"Bin\fr-CA\Thermo.Automation.Foundation.Tests.resources.dll","fr-CA")]
public void Multilanguage()
{
Message msg = Message.Retrieve(Messages.Multilanguage);
msgServ.Post(msg);
Assert.IsTrue(msgServ.ValidateMessageReceived("English message"));
Thread.CurrentThread.CurrentUICulture = new CultureInfo("fr-CA");
Message msgFr = Message.Retrieve(Messages.Multilanguage);
msgServ.Post(msgFr);
Assert.IsTrue(msgServ.ValidateMessageReceived("French message"));
}
Two great tools come together to make our lives easier.
I have been a fan of Snagit for many many years, and more recently Camtasia, both from Techsmith. Now snagit has a hook into Team Foundation Server, allowing you to create a Work Item from a Snapshot of a screen. Using the tried and true features of snagit to capture a portion of your screen you can now use the newly added Team System tool bar item to create a Workitem and automatically attach the screen shot to it.
TechSmith has a Camtasia demo here so you can see it in action.
Thanks Andre
If you have done any serious unit testing with Visual Studio Team System and tried to include these tests in your Team Build you will have come across issues with the .VSMDI. It might drive you crazy until you completeley understand what is going on. Lets see if I can explain the situation with a series of truths.
- The .VSMDI file is Test Meta Data
- Each Solution can have only one .VSMDI
- The .VSMDI stores, amoung other things, test lists created using Test Manager
- Test lists are required to execute tests in a Team Build
- The .VSMDI must be checked into source control for this to work
- VS for Developers does not come with Test Manager
- A solution can have multiple .testrunconfig files
- The active .testrunconfig is stored in the .VSMDI
- When a developers switches to another .testrunconfig it will change the .VSMDI
All these truths together mean that everyone on a team including the Build server sharing one solution (which I see happen a lot) is a pain in the ass.
So how do you each have your own .testrunconfig without messing up the build server. There are plenty of blogs and forum entries out there complaining of this in one way or another.
From what I can tell there are a couple of things you can do.
- Download and use the TFS PowerToys TestToolsTask so you can run tests in a build without test meta data files and test lists. The problem with this is it's more difficult to include only the tests you want executed on the build server. Not impossible but not as easy as using test lists.
- Create a solution for the Build Server to use. It can have it's own test run config and test lists .VSMDI ( You still need team suite or VS for testers to create them) of course all the developers should have their own Solutions also. This can have it's own headaches on a large project when many VS Projects make up the solution. As developers add projects to their solution they have to make sure everyone else knows as well as the build server solution.
I hope they address this in a coming release, I'd like it to be more transparent to the developer.
I am speaking today at EnergizeIT. I'm doing a talk on unit testing with VSTS at 3:30. I'll be talking to the kids about some of the things to watch out for when doing unit testing in VSTS, as well as some of the really nice features.
I attached my demo apps to this Blog entry if you are interested.
Yesterday I blogged about a class I came across in the SystemInformation namespace called PowerStatus. It was working great for me until I tested it on a machine with three UPS's plugged into it. The three UPS's were not for that machine of course :) they were in a rack with a bunch of controllers etc. We wanted to monitor all three UPS's and find out how much life was left in the weakest, so we can shut down the system and save all data before any of them go.
The problem with Power Status was it seemed to give me an average of all three batteries and on my laptop it got nothing. So I asked my network of developers and Andrew pointed me to WMI (Windows Management Instrumentation). Well there is a wealth of information in there. And it can all be called nativley from .Net. I thought I would post some sample code. Gives me a place to come look for it next time I need something similar.
This code gets a collection of Batteries from the current machine and fills a listbox with their Names and remaining life.
ConnectionOptions options = new ConnectionOptions();
options.Impersonation = ImpersonationLevel.Impersonate;
options.Authentication = AuthenticationLevel.Default;
options.EnablePrivileges = true;
ManagementScope connectScope = new ManagementScope();
connectScope.Path = new ManagementPath(@"\\" + Environment.MachineName + @"\root\CIMV2");
connectScope.Options = options;
connectScope.Connect();
SelectQuery msQuery = new SelectQuery("Select * from WIN32_Battery");
ManagementObjectSearcher searchProcedure = new ManagementObjectSearcher(connectScope, msQuery);
this.listBox1.Items.Clear();
foreach (ManagementObject item in searchProcedure.Get())
{
this.listBox1.Items.Add(item["DeviceID"].ToString() + " - " + item["EstimatedRunTime"].ToString());
}
Notice the query in the middle of this code that is looking in Win32_Battery click here to see what else you can query out there.
The project I am working on right now is a software factory that will eventually allow it's users to build software that controls robots and other devices in a laboratory.
Today I wrote a service that monitors the power on the machine it's running. The idea is the service will raise an event if the machine loses power, and will then monitor the remaining life of the UPS. This will allow the system to save any data to disk before the UPS gives up the ghost.
To write this I used a class that is new to .NET 2.0 called PowerStatus. This is a very useful little class.
First of all you can check various useful properties relating to your machines power supply. 
Also you can handle the PowerLineStatusChanged event which will fire when the Power State changes. In this event you can tell if the Power is connected or not and if the computer is about to resume or suspend.
There is a great code example and sample application here.
A colleague and friend of mine Andre who in my opinion is a guru of Test Driven Development discivered this issue.
If you're used to Nunit and how it fires methods in your test Fixture you may assume VSTS fires the equivalent methods in a similar way. Well think again. I am specifically talking about the method you decorate with the ClassCleanup attribute.
Lets assume you have some code in your ClassSetup and ClassCleanup methods you would expect it to setup and cleanup for all the tests in that class. According to the comments generated by MS when a test class is created automatically, you would assume these methods execute before the first test runs and after the last test in that class runs.
Here is the comment you see in the Additional Test Attributes Region of a auto generated Unit Test.
//Use ClassInitialize to run code before running the first test in the class
//Use ClassCleanup to run code after all tests in a class have run
The Comments seem clear enough, or do they?
The Nunit equivalents would fire in the order you would expect from the above comments:
Class1.ClassInitialize
Class1.TestInitialize
Class1.Test
Class1.TestCleaup
Class1.ClassCleanup
Class2.ClassInitialize
Class2.TestInitialize
Class2.Test
Class2.TestCleaup
Class2.ClassCleanup
In VSTS they fire in this order:
Class1.ClassInitialize
Class1.TestInitialize
Class1.Test
Class1.TestCleaup
Class2.ClassInitialize
Class2.TestInitialize
Class2.Test
Class2.TestCleaup
Class1.ClassCleanup
Class2.ClassCleanup
Do you see the difference? The cleanup from class1 is not done until after class2 tests have been executed. All the class cleanups are done at once.
What if I wanted to set something up and tear it down for each class? Do I have to keep track of what order people will be running the tests and make sure I perform the setup only once in the first class to execute a test. What if I only want to run the tests in Class 2.
To me this is a design error, intentional or not.