June 2005 Archives

Update (Jan 2006): If you would like to use some of the features of VSTS from Eclipse then you might want to take a look at my new employer, Teamprise. They provide an eclipse plugin to access Team Foundation Source Control from Eclipse running on multiple platforms including Windows, Linux and Mac OS X.

Original Post: I have just managed to get a quick test java client talking to VSTS and retrieving a list of projects running on my Team Foundation Server. I know this is a small step towards the goals of the VSTSEclpse project, but I'm really happy I've got this working and wanted to tell everyone. Thanks to Davanum Srinivas, Dexter Wong, Evgeny Beskrovny and the rest of the folks over at the axis-user mailing list for all their help in getting NTLM authentication with a Windows Web Service working from a Java application. I've been trying to get NTLM authentication working for something I needed to do at work recently, so this came in doubly handy (another example of working on Open Source projects in your own time directly benefiting your employer).

Joe has managed to get an article into the August edition Dr Dobbs Journal about our VSTSEclipse project. Good work fella! Now all we need to do is get it written...

If you have ever tried interoperability between an MS environment and any of the others you are likely to have tripped over NTLM authentication before now. Obviously there is no RFC for this one, but Eric Glass has an excellent explanation of NTLM that was gathered by reading public available information and a bit of network sniffing. This information was used by the Samba developers when they were enabling Windows File Sharing to/from *nix which is such a great achievement I am still in awe that they ever got it done.

Just found this interesting article on documentation in Agile projects by Scott Ambler. As with everything in the Agile world, we must strive to do just enough to meet the business objectives - this includes documentation. One point which Scott makes very well is that "Your team's primary goal is to develop software, its secondary goal is to enable your next effort."

Even when I am not working in an environment which requires a formal design phase, I often write stuff down during the design stages so I can get my head around a problem. These take the form of Design Notes, a logical UML diagram or a scribble on a whiteboard - whatever works best as a way of communicating the design to myself and the rest of the development team. In my view, the key to a good design is that each component should have a very discrete job to do (low coupling, high cohesion). I just wish I could figure out a painless way of sticking the artifacts produced during the initial design stages into a document that someone could pick up and get an understanding workings of the system.

I find presenting the design the best way of communicating, but that is probably because I enjoy talking. A document is quite often not the best form of documentation, but you sometimes cannot avoid them.

I'm currently thinking a lot about different testing strategies. Martin Fowler has an intesting post entitled Mock Aren't Stubs in which he also discusses the differences between State testing and Interaction testing. In summary state based testing is when you set up your test conditions and say that when you do x the result in the data or from your method is y. Iteraction testing is when you say that when I call the method it should call a, b and c passing the appropriate parameters.

In the days when I first started learning to write code professionally (on an MVS mainframe in PL/1) a test was described as a set of conditions that if your code passes then by definition it is working. This is classic state testing. We didn't do interaction based testing then, possibly becuase we couldn't - we didn't have nMock on the mainframe..

Stepping back into the modern world of TDD in dotnet, by doing state based tests IMHO you are more free to refactor and test all possibly branches of the code by adjusting the inputs to the public interface. With a state based approach you find yourself having to edit the tests much less and just wait for the magic green lights to say you have finished.

Interaction testing allows you a much finer granularity of control in your tests, leading to smaller, discrete sections of code. It also allows you to quickely identifiy which part of the code is broke (by following the single red light in xUnit). However, I've recently run into a few instances where problems have been spotted in the very final stages of programmer testing because assumptions were made about the interaction that turned out to be false.
I'm not saying interaction testing is bad. It is just emitting a slightly bad smell for me at the moment, hence why I am re-evaluating how I test.

Proof, if it was ever needed, of the power of modern browsers. Nuts to Google Maps, DHTML Lemmings is the perfect use of your browsers power. This works for me in Firefox 1.0 and IE 5.5. Oh No!

You know, this internet thing might just take off one day. One of my good buddies, Clark Sell, has just fired up Wordpress and started blogging. His first post is a good story that Kevin Rice sent him about how a company policy begins. This piece is very true, sadly the original source of this gem is unknown.

Keep an eye on his blog as he has some interesting TDD techniques with partial classes in C# that sound interesting. Hopefully he will post them once he has chance to make sure they work. You can guarantee there will be a picture of one of his beloved cars sooner or later...

Skypehave just gone public with their affiliate programme. Feel free to click on one of the links to Skype from the times I have recommended it in my blog and if you purchase Skype-Out credits, I'll get some money to waste on my own Skype spend...