Isn’t it cool how sometimes things just work.

Today everything was just working, and working well. The virtual machine was running super-fast, never glitched. My internet was fast and consistent (for once). I was able to quickly solve old problems I had with the VSTFS sensor and start making some real progress. The blogging software had all the nifty features that made posting and editing easy instead of cumbersome. Considering the number of mishmashed systems and application I am using simultaneous it just makes developing wonderful when it all works together.

Advertisement

Woot for progress!

So today I finished the subscription part of the application. I wrote a small app that would determine what events were available (unfortunately those are manually imported into an xml ATM), displays which events are currently be registered by querying the database, and also allows for manipulation of registred events (subscribing/unsubscribing) using checkboxes. The interface is mediocre but the whole system works very nicely and can be used to easily get the VSTFServer sending the specified events to the services defined in the TFS Notification Web Services Template. There is a ton of testing and a few hard-coded items that must be changed later; but for now step 3 is basically complete.

More of a personal reminder to myself than anything to report. It may be worth while looking at the possibility of using polling to extract other information that is not reported using a webservice by VSTFS. It would be slower but that database has a TON of info in it and its only just waiting for me to extract it. (BTW: SQL is teh awesome!)

The next step (goal for next week) is to build a simple hackystat connecter that will allow for data collected through the webservice to be sent to a hackystat sensorbase. This may be a bit trickier because the various events all collect different types of data so writing a unified general adapter may be a bit tricky if not impossible.

So many problems

Yesterday there was a massive bug in the eclipse plugin for Hackystat. Somehow it managed to record over 30GBs of data!!! Unfortunately this crashed the server which only had a 50GB drive most of which was filled with a large virtual machine and the client using the plugin who also had a small drive which ran out of space bringing their system to a halt. The problem has been fixed and the Hackystat team has been made aware but its a little discouraging. Hopefully during the course of this GSoC project I won’t encounter too many more bugs :p .

In other news I have begun work on the actual sensor and am currently in the midsts of writing a web-interface to allow for some basic sensor configuration and VSTFS connection items before I actually write the code to connect to the hackystat server. I am doing a ton of re-learning since I last used C# and ASP about 8 months ago. Overall though its pretty cool and I can’t wait till the first pieces of data start flying towards the Development Hackystat server.

P.S. When developing open-source software the key to reeling in the vast majority of clients is to develop software that is easy to install/update/repair/re-install/remove. Very few “average Joe’s” want to build your system from source, configure the environment variables, change the settings files, install dependancies… etc, etc, etc. As you can tell I have done way to much installing/repairing recently.

The current plan

So if anyone is wondering what exactly is going through my head at the moment, don’t worry, I have a fool proof plan…

<Step #> <Codename>: Description

1. Alpha: Setup the environment. (Complete)
2. Two’s company: Basic research into the architecture and design of a VSTFS app. (Complete)
3. Three’s a Crowd: Design a simple app that can listen for a small subset of the available events triggered by TFS.
4. The Fantastic Fourth: Design a simple app that can send data to a Hackystat server. May include looking at current visual studio sensor for Hackystat.
5. 5th element: Put simple apps together to get a beta app for the mid-point of GSoC.
6. Sixth Sense: Advanced research into the more obscure events/information I can get from VSTFS to send to Hackystat.
7. Lucky seven: Build on the simple apps to increase functionality.
8. Because 7,8,9: Begin work on some unit-tests and the documentation as a Google code-project.
9. Cats: Create an easy to use installer.
10. Decimal: Bug-testing.
11. Hour: Final clean-up and code submission.
12. Hex: Sit back and relax).

So thats the general idea. Obviously some parts may take longer than others but hopefully nothing will be too simple or too challenging.

With progress there is change!

So yesterday and today I delved into samples from the Visual Studio Team Foundation Server 2005 SDK which is a subset of the Visual Studio 2005 SDK. My goal was to investigate some way of listening to TFS (Team foundation server) events as outlined in the documentation I had been reading during the massive installation I had been working on. I learned two things (one of which I had already suspected since the beginning):

1. The “Team Foundation Server” does not directly allow for plugins/add-ins to be added (from what I have read and seen). I suspected this already and therefore prepared myself for some client<->server programming.
2. The existing architecture for listening to Events is web-based, which is still client-server and involves me programming in c# but may require some additional setup for whomever wishes to install the sensor in the near future.

I didn’t expect number 2 but after about an hour of searching around the web I found a nifty bit of code template to confirm my theory.

• TFS Notification Web Services Template

It took me awhile to get it running as I had never used anything but the default empty template before but after some more poking around the web and fiddling with using BisSubscribe to tell the server I was listening for events I was able to get this:

So now that a have a starting point for next week that will focus on building a small web-app that listens to some events and has some customizability. Overall its looking pretty good so far.

Microsoft Does Development Right

If there is one thing Microsoft does right its development tools. After using Eclipse, various python editors, Dev C++, Vi, emacs, etc… using Visual Studio again is like developing using “big-boy” tools. The interface is fairly simple and its very easy to find things. The debugger is easy to customize and learn. It can generate simple class diagrams from your source, can easily be linked to source control. Overall it just feels as though the environment was designed to help me not to be endlessly fiddled with like other IDE’s. It may not be open-source but it is extendible.

When using Visual Studio there is just a sense of stability (ya! thats right). Eclipse, Dev C++ crashed so often for me and often brand my computer to its knees. I’m currently running Visual Studio in a virtual machine and although its slower than normal its much faster than eclipse.

The only downside to using Visual Studio is that the only programs you can write with it that are (easily) portable to other systems besides Windows are c++ apps. Unless I am missing something really obvious.

Language choice?

I had originally planned to design the VSTFS Sensor in Java to keep with the current motif of Hackystat. The more I look at the VSTFS SDK the more I think it will need to be C#. The more I think about it this may also be beneficial since I will be actively testing the sensor while I am coding since I will most likely be using VS2005 to code if using C#.

Setting up Hackystat

First I suggest everyone reading this go find out “What is Hackystat “.

Last week I and my partner setup Hackystat on Linux (Ubuntu Hardy Heron 8.04 specifically). It toke quite a bit longer than I had expected but we finally got it all up and running as root on the machine. The documentation for Hackystat is very thorough which makes it easier to go through but there is also alot of it which takes some time. I definitely have a much better feel for the system and how it works as a whole. Unfortunately the sensor service is not at a publicly available address so you wont be able to view it, but you can view the main server at Hackystat Hawaii.

Beyond the realm of Hackystat I also had to setup:

• A virtual machine image of Windows Server 2003 Enterprise edition.
• Updates for windows (over 2GBs)
• Windows IIS Server
• Microsoft SQL Server 2005 Trial (6 months)
• (Visual Studio Team Foundation Server) VSTFS 2005 Trial (180 Days)
• Visual Studio 2005 (Pending as of today because of issues with VSTFS)

Needless to say this was very log process but luckily I had lots of documentation to go through:

• Hackystat Documentation
  
• Visual Studio Team Foundation Server SDK

I expect I will be going through more documentation this week as well. I hope to have some screenshots of the whole system working by the end of the week along with my progress on building a simple VSTFS plugin/add-in/service/”whatever they are calling it now”.

Also some info about using Hackystat at UofT for GSoC: Using Hackystat

P.S. Philip Johnson tells us the weather in Hawaii is amazing, the weather is Canada, is well, less amazing.

This is a test…

This is a test. The system is opperational and ready for awesome blog posts.