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.

This is a little creepy...

Just as Pluto gets demoted from being a planet, at work we decomission a server whose name is Pluto.

This alone means we should never use Earth as a machine name for a server.

Just a quick note...

Adobe Acrobat reader is slow... FoxIt Reader is Fast. 

Nothing in it for me, just sharing the good vibes :)  Thank you FoxIt

So I've been battling against using the Solution task in NAnt to automate the build of a large VB.Net solution that includes heaps of libraries and a web service and all sorts

I was hoping to have it done like this:

    <solution configuration="Debug"
              solutionfile="LargeProject.sln" >
      <webmap>
        <map url="http://localhost/Project/ProjectWebService/ProjectWS.vbproj"
             path="C:\Inetpub\wwwroot\Project\ProjectWebService\ProjectWS.vbproj"/>
      </webmap>
    </solution>

...but was getting lots of errors like:
error BC30002: Type 'Xml.XmlDocument' is not defined.

It turns out the source of this is all the odds and ends that VB.Net automatically includes in your project - I was only vaguely aware of them, and it seems like there is no option on the Solution task for it.

After some googling and general messing around, I added an Exec task to the build as thus:

     <exec program="C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe">
           <arg line="EPOnline2.0.sln /build Debug"/>
     </exec>

The down side is there is no nice output from devenv.exe like you get from the Solution & VBC tasks, but my build succeeds and that makes me happy

After blog mint [?]:  I didn't read the devenv.exe /? help close enough!  If you include /Out at the end of the command line (i.e. after /build Debug in the above example) you do get the pretty output.

This is more along the lines of the CI threads that have been occupying my thoughts of late.

I'm really impressed at the kind of technical documentation I can get from NDoc + the VBCommenter power toy, even more when it is generated and copied to my fileserver nightly as part of an NAnt script!

The next project for me on the NDoc front is to coax is to produce user documentation (rather than technical documentation) from the same sources with no extra work from me

Has anyone done this before?  Is it another case of when you are holding a hammer everything looks like a nail?

There's not much to tell since my last (vague, sleep deprived, rambling) post on continuous integartion as a development technique in .NET...

But what I have found useful is using Draco and NAnt on a VB6 project!

The problem I was looking to solve is reporting in Microsoft Visual Source Safe.  Draco.NET supports VSS, so I made an NAnt build script with one target containing no tasks and I have Draco build it every night. 

The plus is Draco includes in its post-build email the details of what checkins have happened since the last build and by who... Instant daily check-in report emailed to your door

I've alluded to this before - when all you have is a hammer everything looks like a nail.  I was thinking about XML then, but after chatting with an old mate the other day it became clear that it applies to Flash as well...

So a couple of profound rules: - I'm putting the Flash community on notice

1. Don't play music.  I was already listening to something, thanks.  ...and I liked my music better.

2. If you absolutely must redesign the common UI metaphors like Buttons and Check-boxes they must work as well as the ones I am use to.  Dont make me have to 'Learn' how to use my computer again.

3. I'm not a mouse in a wheel and no I am not having fun following & clicking a beeping whatcha-mahoozit just to get what I came to the site for.  Yes, I came for a reason and yes that stuff is standing between me and what I want to see.  And No that dosen't mean you are not still very tallented at making beeping whatcha-mahoozits.

But on a more serious note, there are two issues still outstanding with the Flash community that can be an obstruction to less savvy users:  The Back button is useless and I can't bookmark where I am at.

So imagine I am training someone very new to computers about the web... it's going to go something like this:
yes, this is a web page... you can go Back (think bread-crums analogy) and you can save your spot (bookmarks in a book analogy)... oh except for this page - this is what we call a *Flash* page... no, not flash as in... oh forget it....

The point:  No one should have to care what technology the content is written in.  Not beginners and certainly not me.

What's the silver lining?  When the signal-to-noise ratio in any space takes an injection of background cosmic radiation the real cream of the crop just shines through.  Well implemented Flash is sublime.  The rest, well its just the rest.

I've decided to try the Visual Studio IDE enhancements from Developer Express after hearing some rave reviews.  One nice thing I noticed is that the installer detects the presance of VS2003 and VS2005 and installs into both IDEs if need be.  I like the philosophy of not having to buy the thing again whenever a new Visual Studio is released.

More specifically, these tools are Refactor! and CodeRush.

One way to describe CodeRush is as a template based code generator on a small scale.  It can insert comon language constructs with a shortcut key combination.  For example if you select a block of text and press t, the selection will be put inside a generic Try... Catch... Finally block.

First impression was that this thing was getting under my feet.  I know how line completion in Intellisense works and I like it.  In fact I preempt it.  Now things have changed aargh!  I might have to back-off the speed at which this kicks in, or maybe its a new trick for an old dog?

Refactor! is a different animal.  It provides Refactorings to your code inside the IDE with previews of the changes that look unreal.  All kinds of useful stuff like in one click you can extract an interface from a class's public definition.  Sweet!

Now all I have to do is learn to type properly, or just buy a better keyboard

I don't know what it is, but today I got this in my junk mail:


Dear Sir/Madam,

We have logged your IP-address on more than 30 illegal Websites.

Important:
Please answer our questions!
The list of questions are attached.


Yours faithfully,
Steven Allison


*** Federal Bureau of Investigation -FBI-
*** 935 Pennsylvania Avenue, NW, Room 3220
*** Washington, DC 20535
*** phone: (202) 283-4108


I'm insulted.  If you are going to prank me into running your spyware, please put some effort into it.  Not to mention the small matter of jurisdiction...

There's this thing called the Turing Test.  In a nut shell it is can a computer be so clever that you don't realize that it's a computer you are communicating with.   The test must then assume some  benchmark level of human intelegence.  Could a drop in the benchmark of human intelegence be measured by how lame the lure has to be before someone bites?

And a quick post-script to any law enforcement agencies out there:  If you ever get so lazy that you start to question suspects by email...  *rolls eyes*