This week, that week, any old week.

If anyone is keeping track I am on something like step “11. Hour: Final clean-up and code submission.” of my 12 step plan. I skipped step “9. Cats: Create an easy to use installer.” because it would require me dishing out about $20 for a decent installation creator that automagically installs most prerequisites. A project in itself. On to more important things.

This week I was trying desperately to get the sensor working on a production server. Mainly my home computer outside of the virtual machine. Most things went ok, there are still some bugs, and boy oh boy you better set your file permissions correctly. I am going to try to get someone else to test it again (where is Luke…) but I need to sort out one very annoying bug. There is a problem when I run the sensor outside of the development environment computer. No matter what I do, every time I try and access a TFS API function I get something similar to this:

Very descriptive right. Looking around the net gives two possibilities and ONLY two possibilities.

• The compiler compiled a very large program with to many variables. … NOPE!
• The TFS API does not compile for x64 systems. Maybe…

My system at home runs on an Intel x64 processor but I am specifically running Windows XP Pro 32-bit instead of x64 to avoid such issues. Either way I am pretty sure its not my fault, and something is going strange with the compiler. I even added an “if (tfs != null)” statement, which CRASHED! How the heck do you crash on that. It’s either null or its not null. Sheesh, maybe there really is a third-bit. I’ll try testing it on a strictly x86 system next week.

Looking at the code right now I think some of it is good and well… lots bad. It all works pretty flawlessly in development but who knows about a release server. Therefore I am trying to break it as hard as I can. I also need to add in some more GUI prompts when things fail (like trying to find the TFS server or loading the sensorshell). Everything is logged in the log files of course, but who wants to check that every three seconds. And what happens if the log file cannot be written because of say… permissions?

I also migrated all the code and most of the documentation over to Hackystat TFS on Google Code. I think it will be happier there as it will allow more people to help contribute to it. It also better fits the Hackystat motif. This means that I will be deleting all my code and documentation from the Dr. Project site so others don’t get confused later. BTW: Anyone know how to limit image sizes with the Google Wiki Syntax?

I also need to make a screencast video showing of my awesome sensor working. Any tips (programs, editing) on that would be very helpful.

Advertisement

Near the end

Well there are only two weeks left according to the GSoC timeline. That means its time to hunker down and start testing on a production server and write some documentation. Thats what I started doing on the end of this week. Most of the week though was spent using the TFS API to try and extract additional info from the server. For example I was able to extract the number of lines added, changed, and deleted for a revision compared to its previous revision. The result can be given in a variety of different formats but all of them are plain text (not objects or datatypes) which I think is pretty silly. Therefore I choose for the API to deliver the goods in unix normal format and wrote a small parser to identify the valuable info. Its pretty bad but according to the Hackystat commit datatype, having the number of lines added and deleted is required so I put it in.

I also figured out how to use the API to trigger certain events such as builds and commits. I later found out its pretty much usless for testing though since its near impossible to test an asynchronous item with synchrnous unit tests. For example if I commit a “test” item to the repository how long do I wait for a response back, what if it never comes, is it even possible to wait for a response in a unit test environment.

Though learning how the API functions was not in vain. Most of the code and knowledge I learned was used for imporving upon previous features that I had been doing in a sort of round about way. For example, I was using the BisSubscribe.exe tool to subscribe to VSTFS events. This has bad idea written all over it but I didn’t want to mess directly with the pre-created tables in the VSTFS MSSQL server directly in fear that I may cause some horrendous error, not to mention all the security issues. Luckily while learning the API I found there was a class that was used for just this purpose. Since my code is pretty modular I simply wrote another method which used this service and then gave the user the option of selecting between subscribing using the eventing service API or the BisSubscribe. I think its a good compromise.

I am not MIA

I kindof forgot to post an update last week. Sorry all. Then I got sick this week for a few days which hampered my progress somewhat. Not to worry though. I didn’t just sit around doing nothing I actually did some reading. At a university industry lunch  I was given the book “Professional Team Foundation Server” book by Jean-Luc David who co-wrote. It really has a lot of good material for using and extending Visual Studio Team Foundation Server. After I recovered a bit from my cold/flu/bug I began to write some Unit Tests that incorporated some of the things I had learned from the book. For example I really wanted to be able to programming check-in things to source control or work items so I could truly test the system instead of simply using mock data. I haven’t worked out all the bugs for the new Unit Tests this week so they are not in source control yet but hopefully but Tuesday next week.

Also sometime within the past two weeks I was able to fix a small bug with the sensorshell controller which would create multiple instances instead of just one. I also added some simple controls for manually shutting the sensorshell control down without reset the server. Theoretically this would be useful if the sensorshell needs to be updated while the server is running. Any data received during that time is of course lost though.

I also extended the functionality of the subscription service. Team Foundation Server allows users to specify XPath expressions when subscribing to a service and I put in the necessary GUI to allow for that to work. This lead me to realize that I had not been validating any of my input fields. Since its so easy to validate input in ASP.NET I added some validation controls and used the C# XPath library with these controls to check whether the XPath expression was correct. It was pretty easy to do but it really made things alot more robust.

Lastly I added some extra settings to allow users to easily specify default settings before the server loads. The original settings are loaded from a file and then additional settings can be loaded from the VSTFS database if they wish. An example settings file. If a setting is missing or corrupt a default setting will be created upon server load.

Lastly. I was also able to figure out how to link external cs files into the Unit Test project so that I did not need to copy them.