I hate strings. I like strong typing. Its that simple. I guess that is why I have a slight aversion to web development. Too many string literals make me nervous. It's not paranoia if every string literal *is* out to get you, right?

Thankfully, the .NET framework comes to the rescue more often than not and I have often found myself using the System.Net.Mime namespace to alleviate my paranoia about string like "text/xml".

Or is it "text\xml"?  XD

In particular the MediaTypeNames class has a lovely declarative series of classes and string constants that define some of the most common mime types used today. Whilst not comprehensive by any stretch, it covers the standard cases. For example if you intend to use the "text/xml" type, then the syntax is as follows:

 

 

using System.Net.Mime;
.
.
.
string textXml = MediaTypeNames.Text.Xml; //look Mum, no strings!

Of course this is just a bit of a buck pass to the framework; it all boils down to a string literal eventually, but it lets me sleep better at night nonetheless.

I scared myself this morning, I thought I had managed to get the testing policy to ignore inconclusive test results and allow check in for change sets that had no business doing so.

We use sub lists, that is to say we have a few master test lists that are parents to several sub lists of tests. It seems to make dealing with many tests a little easier. When you initially set up the testing check in policy for a team project you select which test lists you want it to ensure pass before the user can check in.

We started with a single list, and added sub lists at whim and will, wherever the need arose basically. However what we didn't realise was that, if you don't go and update the testing policy to watch your shiny sub list, any failures or inconclusive results will bypass the policy check. 

It would be nice, although its not imperative, if the testing policy could automate this process so we plebs don't have to remember. If you happen to agree, then submit your vote to Microsoft connect here.

Hooly dooly batman, as it turns out, if all goes well between now and April/May 2008 we will be the proud and bewildered parents of identical monochorionic, diamniotic twins.

Interestingly, according to the repository of all knowledge, identical twins do not occur as a hereditary predisposition (as with fraternal twins), but rather as a random event distributed evenly across all populations. I don't think I will ever look at GUIDs the same way ever again!

I'm such a stunned mullet I can barely type, but needless to say my wife and I are absolutely ecstatic at the thought of having two bundles of joy. I didn't think I could get any happier. Wish us luck, we're gonna need it :)

I forget every now and again that VSTS Test runner does not run your shiny test suite in place, it makes a new folder for each test run and....well you know the story.

 So this post is really just here to remind me that if I want to read in a file or have some other file system dependancy in a test then I really must apply the DeploymentItemAttribute to my test as well as setting it to copy to the output directory in some fashion. Oh, and I can get fancy by using the OutputDirectory property of said attribute if need be.

*sigh* If I say it often enough I will remember...

...I will use DeploymentItem and not scratch my head as every test fails...

...I will use DeploymentItem and not scratch my head as every test fails...

...I will use DeploymentItem and not scratch my head as every test fails...

It's been a while since posts, and I have a few brewing so stay tuned, but I found out today that my wife is pregnant and I'm going to be a Dad. Wow!

I'm so excited!

Jeremy Miller's post on software teams berates the use of strict enforcement mechanisms of development processes, in favor of a more nurturing environment of self awareness and coaching. He writes:

Quality gates are a very common tool in software development processes to enforce quality by making the people on the project demonstrate some sort of compliance to a standard or process before the project is allowed to proceed.  I'm not sure that I'd say that quality gates are necessarily a bad thing at all, but by themselves, quality gates are absolutely worthless in promoting software quality.

I wholeheartedly agree. Personally, I like to see the odd quality gate, simply so that people are periodically reminded that quality is an issue. However the overuse of gates will simply lead to process apathy.  One of the reasons why I feel such checks are usually pointless, is because they check for the symptoms of good behaviour, rather than rewarding actual good behaviour itself. Besides, we all know that where there are systems of forced quality assurance, there are people who will deliberately pay lip service to prove to themselves that they can beat the system.

Teamwork is about trust and communication, and no amount of Office Nazi-like behaviour is going to produce more of either qualities. Participating in a team must be about nurturing these qualities. By imposing hoops to jump through, you prove you don't trust your fellow team members. By dictating progress rather than collaborating on it, you are denying your team the ability to communicate effectively with you. 

If you don't trust your team members, or you aren't interested in their opinions, why are you working with them?

I came across a cool looking TV show on G4TV, and it's fashioned in the classic style of 8 bit graphics. Entitled Code Monkeys, I think anybody who owned one of these books or similar as a kid, will appreciate this for at least 5 minutes.

It's not for the faint hearted or easily offended though. Personally, I'm hooked and I can't get enough. Have a look at the previews.

I'm not sure what to make of this. Deftflux has created a library to aid brave C# developers in their dark quests to use duck typing.

Given that C# 3.0 is around the corner with anonymous types I feel the duck typing library is a bold move towards Rubyesque abilities. While anonymous typing only gets you some of the niceties of duck typing, I think the greatest advantage of anonymous types is compiler checking goodness.

There is no doubt duck typing can save a lot of time coding. I admire languages like Ruby for their declarative, artistic form of expression. The .NET framework makes use of it too; duck typing has very real use cases.

The TDD crowd has a distinct advantage over the rest, in that one could happily duck type all day long, trusting in the safety of ones unit tests to provide alerts to type mismatches.

 Sure, if you write a thorough test suite you can theoretically avoid most of the dangers of duck typing. Though all it takes is one hole in the tests and the time saved coding is spent debugging. I would rather my compiler tell me about a type mismatch, than the beta testers complaining of unhandled InvalidCastExceptions. In the spirit of using the right tool for the job, surely the compiler is the right tool to inform us of type mismatch problems? It does a fantastic job of it. Cedric Otaku puts it in a way that's hard to ignore:

In a way that's typical for dynamically typed languages, the error will therefore only appear at runtime and only if such code gets run.

If you are duck typing in copious amounts and not writing tests, then you are walking on shaky ground.

I guess I like to be explicit in general; say what you mean and mean what you say. Life is simpler that way. I like suspense & innuendo in movies, not code. I can't wait for anonymous typing in C#, but perhaps even more so, I look forward to the day work lets me use languages like Spec# to enable me to be even more explicit to the compiler as to my intentions.