I love it when things come together:
CodeRush and Refactor! - I'm a fan
I love a good keyboard too.

Here's a nice little plugin for Refactor! that can show available refactorings or metrics on the display of a Logitech G15.  Too cool!

I thought it was about time I refreshed my rules for what good error messages are:

• Consistant.  This could be visually consistant in the case of message boxes, or if they are being logged to a file or database table then being consistant helps them also to be machine readable.
• Informative.  Consider ADO & ADO.Net's old "General Network Error" as the best example of how not to do errors.  The key point here is the message should first say:

1. what did not work correctly, and
2. what you should do next to fix it

Stack traces etc should come later.

• Appropriate.  Consider the audience of your application.  They are the audience for your erorrs too!  The level of detail I expect in an error from SQL Server is completely different to the kind error I expect from iTunes. 
  
• Respect my attention span.  750 Event Log messages a day means I won't look at them.  Once a quater means I won't look at them.  The latter case should be emailed.  The former case probabbly should be replaced with one critical failure message
  
• Respect my privacy.  Passwords, maybe even user names, or anything that is sensative in the context of the application should not apear in an error message.  I don't have a convienient example of one with a password in it (maybe check a more complete source) but this would probabbly also extend to stack traces.

This is a growing list.  It gets revised when I see something done well, or something done poorly (or when I do something well, or when I do something poorly.  Now I've blogged it.

It started out with just the Informative rule, motivated by the cost of the support desk having to get involved in a support issue vs. the user working it out for themselves.

More formally, we could look at an error with the following criteria:

• What does this message do for the user experience?
• What does this message do to avoid the user having to call someone?
  

One thing I have to say I am excited about in the .NET future is Windows Presentation Framework. 

So, on top of Vista RC1 (build 5600) and Visual Studio 2005, what do you need:

Microsoft Pre-Release Software Microsoft .NET Framework 3.0 - Release Candidate 

Microsoft Visual Studio Code Name “Orcas” Community Technology Preview – Development Tools for .NET Framework 3.0 

Microsoft® Windows® Software Development Kit (Web) for RC 1 of Windows Vista and .NET Framework 3.0 Runtime Components (you only need the .NET 3.0 doco, grab the rest later if the download is too long)

Microsoft Expression Interactive Designer September 2006 CTP 

 

So I've just worked it out...

If you want to edit a list in Datasheet View - an insanely useful feature - you must not have Office Basic or Office Small Business versions.

You have to have the Pro version of Office and make sure the "Microsoft Office List Datasheet Component" is installed in the "Office Tools\Windows SharePoint Services Support" option in selected as Installed under Office setup.

To the end of making my unit tests as easy to write as possible, I thought the default CodeRush template for adding a new NUNit Test Fixture to my projects could do with some tweeking, or at least customization.  Here's how I like mine:

<TestFixture> _
Public Class «Caret»«Field(ClassTests)»«BlockAnchor»
    <Test> _
    Public Sub «Field(MethodTest)»()
        «Marker»
    End Sub
End Class

My next question is, how can I make the ClassTests field default to the name of the file?

After blog mint [?]:  There are extra fields that you can insert into the template expansion, these are Text Commands and String Providers.  You get to these by right-clicking the Expansion area and choosing Text Commands or String Providers and selecting from the list.  The FileName string provider might be just what I need.

I was sitting on the train this morning with my mate Robbie, we both had laptops out, both hacking a little bit of early-morning-commute-code.  Must have looked like a right pair of nerds

Anyway, he was coding in IDL (no, not the IDL VC++ guys are use to...), no doubt doing some high science with DICOM data, and I was coding in VB.Net, so naturally the conversation drifted to languages!

I remarked that the bit I was working on was not an elegant example of VB.Net, but rather some hackage that works and will be cleaned up in a future rev.  I apologised for its lack if readability.

Rob remarked that, it was readable... but more like readable in the same way a novel is! 

I am so sorry about the title.  I am a child of a certain generation.

I deal a bit with XML in my day-to-day and "getting" XSLT was a pretty significant step forward in this for me.

Doug Tidwell's book XSLT was the key.

What prompted this revolation was seeing that XSLT was more than just a way of rendering XML to HTML in a browser, but that XML to XML translations can be exceedingly powerful.  Right now I am dealing with a data source that has been flattened from a normalized relational structure, and now it needs to be put back together into a third, different structure.  All this is do-able.

FWIW, my tool of choice currently for XSLT development is Architag's XRay... but I still prefer WMHelp's XML Pad for general day-to-day XML editing.

I thought I'd post an update from my path to continuous integration nirvana...

Today's installment is things I have learnt about writing unit tests.  Specifically I'm all about .Net and NUnit, but these are probabbly applicable in other scenarios too.

Name your unit tests correctly

What I mean to say is, name your tests as a verbose description of what the purpose of your test is. 

A good example:

<test()> _
Public Sub FooCanGenerateValidIDWhenInputValueIsNegative()

A bad example:

<test()> _
Public Sub FooSaveMethodWorks()

Can someone who dosen't code on your project (or better still, a non-coder) understand what the designed behaviour is for the Foo class from your NUnit results? 

But the most important reason is these tests must be granular and focused.  If you can't tell me what you are testing by the name of the test it is probabbly time to step back and look at the code you are testing.

Bug fixes should have a unit test

This is in two flavours:  Forwards and Backwards.

When I fix a bug, how do I know it is fixed?  How can I prove it is fixed?  Good bug reports are focused & granular.  Add steps to reproduce and now you are talking about a good bug report. 

It is also no mistake that the words focused and granular words are in this lesson too. 

Forwards:
By the time the tests are done they should describe the desired end result of the bug report.  Again there is no need to go all TDD unless you want to, but if the bug report is in the form:

An unhandled exception is thrown under some specified bad input data

then your test should show that no exception is thrown with taht bad input data.  Instant proof that the bug was fixed!

Backwards:
Looking at a closed bug report, how do I know what was done to fix the bug?
Looking at a broken build report because some unit tests failed, how do I know what bugs that code relates to so I can retest them?

The purpose of this lesson is to remove well it worked on my PC from the developers vocabulary.

Writing unit tests is a mind-space thing

While not going as far as TDD in my current projects (caution: there are TDD fanatics out there the lesson I learnt from the TDD thing is when you are writing your tests you need to put yourself in the mindspace of the client of your code.  Forget for a minute how you implemented the method and express what you aimed to do in the method with your tests.

Confession alert:  At first I thought this was a bunch of bovine compost when I read it in the Agile/unit testing/TDD echo chamber.  Then, one day, when I wasn't paying much attention, I found a bug in my code through this method as I was writing it.  Clouds parted, a little beam of sun light came down and touched my head.  All became clear.  Lay your hands on the radio, children; for we have a new believer.

Tests should be easy to write

When writing heaps of tests agains the same class or library or whatever, write a base class that does the setup etc and descend your test class from this base class as a way of making the test method only contain as little code that is not the test as possible.  This can make it easier to bang out plenty of tests. 

Or if you want to use Code Rush or Snippites in VS2k5? 
Or if you want to do absolutely anything else to make it easier to bang out unit tests?
...just do it.  There is no wrong answer.

There is no need to make this harder on yourself than it has to be!

Hows that for a long title? 

So there is a new version of Visual Studio (in CTP at time of writing) called Visual Studio Team Edition for Database Professionals - its aimed at people who might associate themselves with the title Database Professional.  I gotta say, it looks like a really good solution to some problems.

I attended a cabana session at Tech.Ed (Tech.James?) this year hosted by Greg Low on data generation in the product, and during the presentation it came up that it would be nice to have custom generator for Australian-specific data... so I thought I'd take a stab at it.

Below is a screencap of the kind of random data my generator will spit out.  Handy for columns where a check constraint may be forcing a given format for the data.  The format of the phone numbers is configurable by a property and the rows are conistant for a location so that if we generate a Vic address it will have a valid Vic phone number etc.



The good news is its really easy to do.  Even at this early stage the product has some pretty reasonable doco on what to do to write your own generators.

So my custom generator is available for download by clicking on this link

To install it on your copy of vsdbpro:

1. Copy the DLL from that zip into the following path on your PC: 
   [Program Files]\Microsoft Visual Studio 8\Common7\IDE\PrivateAssemblies\
2. Edit the config file at:
   [Program Files]\Microsoft Visual Studio 8\DBPro\Microsoft.VisualStudio.TeamSystem.Data.Extensions.xml with a suitable XML editor and add the following line:
   <type>deepdark.net.PersonalDetails, AustralianDetails, Version=1.0.0.0, Culture=neutral, PublicKeyToken=341d0bd35c6f7d28</type>
   
3. Restart Visual Studio, you should see a new generator called Personal Details in the list.
   

The source code is hardly going to start a revolutiuon, but I can make it available if there is any interest - just let me know.