Sorry about the late write-up, been a little busy!

Small turn out, with 5 us in all, including new comer Jamie - a recent graduate from
Auckland University, it was great to talk with someone just
entering the industry proper and I think everyone else found it
very interesting to hear about what's going on at Auckland
Uni.

So first off we discussed adventures with alternative licensing
products - Gareth had a few war stories, and mentioned he's
returned to using .Net
Reactor and got a refund on the previous product he tried out
because it just wasn't living up to expectations, and had some
questionable weak points.

We talked about the C5
Generic Collection Library - though none of us have attempted
to use them in anger, a few people had heard about them recently
because it seems to be doing the podcast/blog rounds, even though
the project first debuted at the start of 2006, and was in
development well before then.

The classes were developed at the IT University in Copenhagen,
and feature a large number of specialised collections, as well as
introducing features to provide event handlers and sliding views,
support for clearing collection ranges etc.

There is a recent video on MSDN Channel 9, which is worth a
watch
as well.

Because we didn't have it in our hands last year before I wrapped
up the Architecture Chat I discussed the ASP.Net Web Extensions CTP, mentioning the amount of
community interest in MVC and that the Data Services (Astoria) is
looking better and better.

From there we talked about the MVC Contrib. project
(and community) that's sprung up after the ASP.Net MVC release,
which is getting some New Zealander's attention around the world
because of their contributions of both an XSLT View engine and NHaml View engine - the contrib project is also providing
integration with the popular IoC containers in .Net and a number
of other extensions.

I talked about F# parsing, and my explorations of writing parsers
in F#, especially after reading the series
of posts from DevHawk (Harry
Pierson), and experimenting with writing DSL's in F# by
hand.  I think my next "goal" is to master integrating F#
libraries into my C# code, so I can commercialize on it and start
weaving it into my day to day tool set.

I'm not sure I articulated how elegant F# syntax can be - but
hand writing custom parsers in F# with the aid of Active Patterns
is much nicer then the equivalent in a language like C#, If
you're following the pragmatic programmer guidelines of learning
a language a year, you could do much worse than to learn F# for
2008, it certainly gives the brain a good workout :)

From their I mentioned PEX for use in automated
white box testing - Jamie said he had worked on a 4^th
year project to do automated black box testing, and found it
interesting that white box testing of this nature could be made
viable/useful... PEX seems to have done it though.

Though it's not been made available to the general public as yet
(only academia) - I suggest having a listen to this hanselminutes
podcast,
and then watching this screencast
to get a better idea of just what PEX is doing/aiming to
achieve...  I find the support for
mocking particularly interesting, as I'm always sceptical of
automated test generation, as it normally falls apart once you
start to work objects when have numerous injected dependencies
that are used by the class to do it's work.

Last of all I mentioned TeamCity (JetBrains CI
& Build server) Professional Edition is
free, and I've been starting to play with it - and
considering migrating over from my current CruiseControl.Net
setup for new projects, I'm going to trial it on a small project
and see if it's worth moving to for what I do.

Last of all - though I forgot to mention it at the time - I've
also been looking at Jazz (or more so Rational
Team Concert) lately, it certainly looks to resolve many of the
headaches I suffer with managing concurrent versions of products,
especially from the build server perspective - obviously anything
with the name "Rational" is to be feared by the small or micro
ISV because of prohibitive costs - but it's nice to see just how
they approach solving the problem, as shown in the video
"fixing
a bug in a previous release".

Not a bad start to the year, hopefully we can make the next one
bigger and better, and maybe get some more long-running
architectural discussions going on ... maybe around Behavior Driven
Development/Design or maybe Feature Driven
Development and what makes it more suitable for fixed-price
jobs.

See you all next time!