From the slightly bizarre files:

...over 50 redheads rode the subway together and protested a Manhattan Wendy’s for their “racist logo.”

It sounds like they had fun... I like the idea of riding a train and suddenly realising that everyone else on board has red hair.

Microsoft just hired two developers I respect:

• Scott Hanselman, of Computer Zen, Hanselminutes, Bathrooming with Rory fame has just signed with Microsoft in ScottGu's team.
• Alex James, inventor of Base4.net and NZ user grouper and MVP announced he's off to Seattle, and joining the Data Programmability team.

Here's hoping we can look forward to both of them coming to the next New Zealand TechEd (and Code Camp).

I'm always impressed by the super-clever people that Microsoft hire. Congratulations, Microsoft!

dot.net.nz has got it good!

Andy Oram posted to the O'Reilly Radar about his recent research on mailing lists, and linked to his article "How to Help Mailing Lists Help Readers".

In his article, Andy followed threads on some mailing lists (Linux, Perl, Ruby), and uncovered some patterns of behaviour (summarised below):

• Many questions aren't satisfactorily answered (46%)
  
• Helpers give up after a few attempts
• Beginner users have fundamental gaps in knowledge, and need direction to other documentation sources

Now despite recent unrest about the effectiveness of the dotnet mailing list (at www.dot.net.nz), in particular the performance of the mail sender, I've always been convinced of the relevance of the answers given on the list, and impressed by the tone of the replies. We've got a nice little community going, and people offer quite in-depth help wherever they can.

I'm always impressed when people go out of their way to solve a problem, such as installing a piece of software to help diagnose someones problem (Ivan Towlson, I think that was you :) ), or reliably pitching in to solve a problem (PeterB and "shane ~" are among the regular "helpers").

So I collected some statistics following a similar process to Andy's:

• 15 recent threads from the NZ dotnet mailing list where a specific question was asked
• I measured similar statistics on the effectiveness and time to resolution, although for some of the threads where the orginal poster didn't reply with thanks, I defined "resolution" subjectively as whether I thought a satisfactory answer had been given
• A count of the number of messages in each thread, the number of helpful / on topic messages, off-topic, irrelevant and unhelpful messages

Results:

• 80% of questions received a satisfactory reply!
• There were no off-topic, irrelevant or unhelpful messages!
• Median time to resolution was 20 minutes!
• Longest time to resolution was 2hrs 34mins.
• Best response times are early-mid morning, and mid-afternoon. Slower responses over lunch time.

I expected to see the dotnet list coming out well, but when you compare these numbers to the ones Andy collected, and even if you factor in some differences due to sampling / processing technique, the differences are staggering:

Table 1 (modified). Resolution times for questions on mailing lists

	Minimum	Median	Maximum
NZ .NET list	8 mins	20 mins	2 hours, 34 mins
Perl	2 hours	8 hours	1 day, 21 hours
Rails	0.5 hours	16 hours	7 days, 10 hours
Both operating systems	0.1 hours	10.5 hours	2 days, 10 hours
Both languages	0.5 hours	13.5 hours	7 days, 10 hours
All lists	0.1 hours	11.5 hours	7 days, 10 hours

Some of the things that I believe make the dotnet list so successful:

• The list is an extension of the user groups, and many people know each other in person
  
• Everyone is in the same timezone and industry, which means the responses are fast, and usually at the same time of day that you need help
  
• Off-topic conversation is kept to a seperate off-topic mailing list
• The list subscribers have a wide spread of knowledge and experience, with some members having very deep .NET knowledge
• Timaru is discussed monthly :)

The list server that runs the mailing lists (dotnet, sqlserver, dotnet-offtopic and others) has been tirelessly maintained by Lukas Svoboda over the past 5 or 6 years, and the not inconsiderable costs of sending out many thousands of emails a day has been sponsored by him, Microsoft, Irongate, Orbiz, Intergen and others over the years. Thanks!

It's very exciting to start advertising the NZ.NET Dev Code Camp, which will be happening in Auckland next month -- Sunday 12 August. We're running it the day before TechEd, and using one of the larger TechEd conference rooms.

Registration, and further details can be found at http://www.codecamp.net.nz, and more details will be added there as we confirm them.

Tell all your friends!

Kirk

Darryl has just posted that the NZ TechEd schedule has been updated and is available on Comnet.

I'm excited to be presenting on Windows PowerShell again -- last year was a blast, and there's new things to talk about this year.

One of the first things I do is look at the competition. It's always good to know what you're scheduled up against. At 10:45 on the Tuesday morning, I'm up against these sessions:

ARC308 - Software Factories

CON311 - Building Microsoft Windows Workflow Foundation Enabled Windows Communication Foundation Services in .NET Framework 3.5
Speaker(s): Matthew Winkler

DAT309 - Implementing Scale-Out Solutions with Microsoft SQL Server 2005
Speaker(s): Don Vilen

DEV318 - Strategies for Moving Your Microsoft Visual Basic 6 Investments to .NET
Speaker(s): Paul Yuknewicz

OFC301 - Capacity and Performance Planning for Microsoft SharePoint Products and Techologies 2007
Speaker(s): Mike Fitzmaurice

UNC302 - Microsoft Windows Mobile 6 Security In-Depth
Speaker(s): Steve Riley

WEB317 - Enhancing ASP.Net AJAX applications with Silverlight
Speaker(s): Nikhil Kothari

Come and hear about PowerShell, you know you want to!

So true: "It's so easy to write, but not always easy to read". Perl 5 in a nutshell

I've spent many happy hours spent writing perl code :)

"Help, help, I'm trapped in a nutshell! Somebody get me out of this bloody great nutshell!"

Simone writes that he's leaving NZ soon. Simone has been a welcome addition to the Wellington geek community and has contributed to presentations and conversations at the .NET user group and the Wellington geek lunches.

Come back soon Simone, we'll miss you!

Test message

Ayende briefly outlines the 7 approaches for interception in .NET, techniques which are used for Aspect Oriented Programming (AOP), Dependency Injection, and other methods of ensuring that the thing you write ain't the thing that runs.

This topic is dear to my heart (a little too dear!). My University research went into different interception techniques in depth, and I surveyed the different techniques and implemented a few prototypes. My main implementation was a mixture of runtime and compile-time weaving, as they gave most flexibility in the interception points that can be attached to. Other approaches typically work by subclassing, limiting you to interception of virtual member methods only.

The .NET runtime allows a few interesting points of interception, particularly if you are interested in playing around with the Profiling and Debugging API's. Things have gotten a little better now that people have written managed wrappers, but back then, those API's made my head hurt.

One day I plan to go back into that part of my writeup and pull some text into this blog. I'd also like to fully implement my injection system, especially now that the library support has improved (Cecil is superior to R.A.I.L.) and the runtime supports lightweight code-generation.