The Limber Lambda

In a previous post, I detailed how to cheat at a popular Zynga game which is a play on the age-old hangman, but with cute balloons (the style of which you can upgrade with purchasable coins).  I covered the part of the game where you need to choose a word that your opponent needs to guess.  I mentioned that, of course, it’s also possible to cheat on the flip-side, that is, in having to guess the word that your opponent has set as a challenge for you.

At that stage, I was resorting to grepping through all the words, with a regular expression, using the “any” regex token for letters that hadn’t yet been guessed (“.”).  i.e., if the word so far ended in at and consisted of four letters, finding possibilities was a case of:

grep –i “..at” /tmp/scowl/final/*

 

Of course, this isn’t particularly smart, because it will return words that aren’t candidates by virtue of the fact that they contain letters that I may have already incorrectly guessed.  Assuming that I have already guessed e and r, neither of which were correct, then a better grep would be:

grep –iE “[^er]{2}at” /tmp/scowl/final/*

 

Enter Ruby

I’m a great fan of knocking Unixy bits together in impressive ways, but the poor mans word-guesser above needs an upgrade, and since I’m learning Ruby at the moment, I figured it was time to put in the effort to Ruby-fy what is essentially a simple need.

In Part 1 of the cheating story I defined a class called EnglishWords which serves to encapsulate all possible words and operations on those words that I may be interested in.  I need to re-use this class for my word-guesser, so it’s time to move it out into its own source file.

Using EnglishWords from a script then becomes:

require File.join(File.dirname($0), 'english_words.rb')

$0 is the path to the script being executed and File.dirname gives us the directory part of the path.  This require assumes that english_words.rb resides in the same folder as the top-level script.  Fortunately, I have a bit of background in Perl, from-which Ruby borrows many things, so the idioms are familiar.  Ruby also borrows a few things from Unix shell script, e.g., $0, $1 etc., and dirname/basename.  How do I get the directory of the currently executing script in Bash?

echo $( dirname $0 )

 

This is one of the reasons why this language is growing on me so quickly—an example of the principle of least surprise in action (provided, of course, you’re a Unix-head and not from a purely Windows background).

I took the grep above and Rubyfied it without much translation at all:

  1: words = EnglishWords.new ARGV.shift

  2: word_so_far = ARGV.shift

  3: wrong_letters = ARGV.shift

  4:

  5: regexp_so_far = wrong_letters.empty? ?

  6:                 Regexp.new("^#{word_so_far}$") :


  7:                 Regexp.new("^" + word_so_far.gsub('.', "[^#{wrong_letters}]") + "$")

 

Line 7 is the important part; just replace all instances of “.” with a regular expression character class of the letters already guessed, and we’re ready to apply the regular expression.  Lines 1 to 3 are another example of a Unix idiom, namely, shift which “knocks” the first item of the array being acted on off and returns it.  Interestingly, shift is an example that I’ve come across in Ruby of a deviation from another convention—that of naming “dangerous” methods (that is, methods that alter the state of what’s being acted on) with a bang at the end e.g., gsub!(..).  I guess in this case, assuming you’re familiar with the Unix shift, the bang is redundant since shift by definition changes state.

Searching for (and outputting) candidate words becomes:

  1: words.each do |w|

  2:     puts w if regexp_so_far.match(w)

  3: end

But wait … EnglishWords has no definition for each yet.  Here it is:

  1: def each()

  2:     @words.keys.each { |w| yield w }

  3: end

Notice how each above takes no parameters, but I’m passing it a block (blocks are the same as lambdas in C#-speak).  Another feature of Ruby—the implicit block parameter which can be passed to a method and invoked with yield.

Without too much effort, and a little bit of Ruby, we’re up-and-running in the word guessing department .

For a while now, at work I’ve been in a kind of limbo; not quite an architect, not quite a developer, a pinch of project manager and a a sprinkle of business analyst.  To tell the truth, as of recently, mostly business analyst—however that may be interpreted (as unforutnate as it is, I don’t think there’s a coherent view of what a BA does, or is responsible for in our industry).

As the challenging project that I’ve been involved with for the past five years draws to a close, I’ve found myself reflecting on it’s early stages and contrasting it with things as they are now.  There’s this cliché that  there’s 20/20 vision in hindsight, so this is the perfect opportunity to challenge those things that we look at now as being so clear in hindsight which were such murky choices early on.

A natural tendency, when "shown the truth" through experience is to focus on the negative.  I want to make a conscious decision though, to focus on the positive.  Focusing on the positive, and recognising what we would normally term "failure" as being "opporunity for improvement", is what popular wisdom teaches us as being what we should strive for.  Why would I argue with that?

The Project

"The Project" as it will be known, in hindsight, was enormous, is enormous.  We didn’t fully recognise it as being enormous at the time.  I’m not at liberty to explain what it’s about, suffice to say it is in the financial industry (that shouldn’t be enough to incriminate me), and suffice to say that the business logic involved is highly complex.  I doubt whether I will ever again, in my life, encounter a bespoke development project involving business logic as complex as this.

In any case, we spent some time coming up with a detailed functional requirements document.  This is a story I’m sure you’ve heard before.  You might even be sighing internally as you read this … a sigh of pity; "more poor souls who didn’t embrace Agile" you might be saying you in your head.  There are no excuses here, because I don’t think that specifying requirements in detail up-front was entirely the wrong thing to do in this case.  That’s because,  what was required was poorly understood,  difficult to understand and prone to misinterpretation.  The subject matter was, and is, the domain of academia, being tackled by folk who for the most part didn’t have formal qualifications.  Due diligence, even if through up-front requirements specification and review was justified, however you look at it.  The only way that interpretation of requirements could have been tackled efficiently in an agile setting in this case would have been if the product owner was uber-qualified—someone who knew the business backwards and who had a sufficient personal stake to take delivery personally.  No such person existed.

The positive: specifying requirements as a detailed document, up-front, was the best thing to do given the circumstances.

Following on from the requirements, as is dictated by a well-behaved waterfall implementation, is the architecture specification.  That was, and continues to be, my responsibility.

The guiding principles that lead me to the architecture that shapes our lives:

1. Live, Eat and Sleep Objects;
2. Keep it Simple (S);
3. You Aint Gonna Need It;
4. If Microsoft Says it, it Must Be So;
5. Don’t Repeat Yourself.

If you read between the lines from the above, there’s a theme, let’s call it "minimalism", engendered primarily by "Keep It Simple (S)" and "You Aint Gonna Need It", but arguably, also by "If Microsoft Says it, It Must Be So" and DRY.

Let’s back up a bit and start with …

Live, Eat and Sleep Objects

I have always, in my heart-of-hearts, believed that modelling a real-world problem with objects is the way to go.  It’s all parcelled up in some deep beliefs I have about the consequences of lying to oneself.  If you represent something as something other than what it is (or at least as something not as close as you can get to what it is, given the tools at hand), you’re on a slippery slope to invevitable doom.  As it turns out, through experience, and through confirmation by Martin Fowler in his PoEAA, there really was no other choice—when presented with a sufficiently complex domain, the choice of whether or not to use a rich domain model is a simple one … it is, for all intents and purposes, made for you.

The positive: modelling the domain using well-understood OO modelling techniques was far and away the right choice; with such a complex domain, anything else would have been death-by-duplication.

Keep It Simple (S)

What has been said about KISS has been said many times before and continues to be said—it’s one of those instances where one can be forgiven for repeating oneself.  Ironically one would think that one can’t go wrong with KISS, the benefits are simply obvious … matched by the implementation.  Sadly, this is not always the case.  The fact is, when confronted with a complex domain, there is a certain amount of “not-so-simple” that one must take on as necessary baggage in order for things to be manageable, and that’s where this little four-letter-bundle-of-wisdom has a sting in the tail.

Never-the-less, this particular post is all about the positive, so here are some positive things that KISS influenced me on:

Two tiers: a client tier and a database tier; that’s it.

And I have great news … this has served us well.  We did need to take on a persistent service running on an application server, simply because there are things that are global and shouldn’t be influenced by whether or not a client workstation is on or not, but that’s the extent of it.  No need for Windows Workflow Foundation, Windows Communication Foundation or Microsoft Message Queue, just a good ‘ol database.

The positive: KISS has it’s benefits—we didn’t take on some unnecessary technology because we thought we just might need it or because it has a warm-and-fuzzy enterprisey feel to it.

You Aint Gonna Need It

This one is pretty closely related to KISS, and I have to admit, my approach at the outset was quite heavily influenced by the “last responsible moment” camp.  YAGNI at a details level is helpful, even necessary, but at an architectural level it has far-reaching consequences.  I will continue to give it it’s due, but not with the same rigour as DRY, for instance, and certainly not at macro (read architectural) level.  The problem is that YAGNI dictates that you only consider what you can see, and in doing so provides a false sense of peace that it’s Ok to forge forward with inadequate knowledge of the territory.  For example: “I’d like to use objects, but damn … all this talk about ORMs—all I need is LINQ-to-Sql, right?”.  Wrong.

The positive: as a meta-lesson, YAGNI shouldn’t be applied at an architectural level, and I’ll even go so far as to say that this whole “last responsible moment” talk is somewhat irresponsible.

If Microsoft Says It, It Must Be So

I feel sorry for the tens of thousands of developers out there whose lives are bound by the Redmond Reality Distortion Field.  I know I shouldn’t need to, because the vast majority of them are in bliss and will continue to be as long as ignorance will allow them to be.  When I started this project I had come out of what was effectively six years of Java and Unix and even though prior to that I had done Windows development, I was happy to accept any guidance from the Mothership that I could get.

Sadly, experience has proven that Microsoft makes best-of-breed product in some areas, but not others.

Things where Microsoft is best-of-breed:

1. The .NET platform;
2. Visual Studio.

Things where Microsoft is not best-of-breed:

1. Test-driven-development, and associated tools (MSTest);
2. Domain-driven-design and associated tools;
3. Build tools (MSBuild);
4. Source-control (TFS);
5. ORMs (EF);
6. IoC containers (Unity);
7. Aspect orientation (Unity).

We adopted a few of the technologies above simply because it was the “Word from Redmond”, and didn’t adopt other of the technologies above because they didn’t yet exist and Microsoft didn’t have an answer to equivalents in the Java world that had been around for years.  I’m not going to labour on this one, because too much emotional energy has already gone into it; suffice to say that I’m disappointed.

The positive: the lesson is, don’t blindly follow what may, in fact, be akin to a faith.  Question, dig deep, analyse, consider, understand and criticise before you marry yourself to a technology—I’m much wiser for this experience.

Don’t Repeat Yourself

I don’t know how much I’ve repeated this, but as ironic as it is, I’ll continue to do so.  The problem with DRY is that it’s only when you don’t observe the principle that you discover how valuable it would have been if you had observed it.  Everything we’ve done has revolved around this, including:

1. An aspect-orientation system for applying cross-cutting functionality in a type-independent way;
2. A single view of data and generation of types from the data model that are used by the data access code;
3. Generation of enumerated types that have an analogue as a table in the database from a single source;
4. A philosophy of single-responsibility at project, type and method level engendered into how we develop and refactor as a team;
5. A philosophy of writing code that is self-documenting.

Revisiting the statement I made about knowing the value that DRY has delivered, and referring to item 2 above, we have not once had a situation where we referenced a table or column at runtime that didn’t exist in the database.

The positive: By diligently observing DRY, both at an architecture level as well as design and code level, we’ve averted a lot of potential wasted time in correcting unnecessary inconsistencies.  The real plus though, is the durability of this benefit—the fact that such potential wastages in resources, time and money won’t ever be repeated.

In Conclusion

There’s a lot of wisdom bandied about on “core values” when it comes to software architecture.  In fairness, one needs to contextualise things before one arrives at a set of values—that is, when embarking on a project, figure out where you’re at in terms of project scale, complexity, and in particular, what would be considered as acceptable as “success”.

I’ve put myself in a position now where I feel obliged to distil all of this into a neat uber-tweet of wisdom.  Now here’s the real irony … a principle that I didn’t explicitly follow, but that arguably trumps all the others—figure out what’s really important, remembering to express it in business terms and optimise for that (can you say 80/20?)

So, at work we’re in this recruitment cycle again.  This time it’s aggressive, and we’re really after the cream-of-the-cream.  Those hard-to-find coding ninjas who generally don’t ever need to approach a recruitment agent, because of course, the second someone sniffs that they’re on the market, they’re wooed with shares and options and Wii’s and iPads and rubdowns.  It’s a mad scramble.  Did I mention that I’ve never had to approach a recruitment agent? ;)

The best way to finger these types is through someone you know who’s really good, who knows someone they worked with at some point who blew their socks off.  Unfortunately the network method has failed us—sadly it looks like all talent has gone deep underground, or left the country.  I’m partial to the latter because quite frankly, the quality of the meat that our corporate designated agent is passing our way has been found wanting … repeatedly.

But before I get ahead of myself—let’s approach this methodically, like we should a new project.

Step 1: Clearly define what we require

Enter the Senior Developer.  As expected, this is all too subjective … a quick zoot over to SO confirms our fears and leaves us unsatisfied: it depends.  I wish it was as easy as “Spanish male developer” (si señor!).

Being the “main technical peanut” using our PM’s terminology, the responsibility of defining the standard falls on my shoulders.  I do subscribe to Joel Spolsky’s “smart and gets things done”, but the definition somehow falls short … it just isn’t complete.

Drawing from that deep unknowable über-developer essence that I supposedly have access to, I therefore decree:

Senior Developer Quality 1: Professionalism

Now we all know that you can’t distil what makes a senior developer into one simple thing, but this is one of those undeniably big differentiators.  Can you do a good job, consistently?  If yes, then proceed to next assessment gate.

Senior Developer Quality 2: Intelligence

Where I come from, there seems to be this unspoken rule: “one doesn’t explicitly talk about smarts”.  Because of course, smarts is one of those things that if you don’t have, no amount of experience is ever going to improve the situation.  Let’s square up to this, for crying out aloud—if you want to be a senior developer you absolutely must be smart.  Preferably, very smart.

Senior Developer Quality 3: Passion

Another big differentiator from the unwashed Mort-cast.  You gotta wanna learn, all the time, during meals, on the can, driving to work, driving from work, on the treadmill, aside the water cooler and anywhere else you care to mention.  Senior developers have technology in their veins, they live it and breathe it.  Excitement isn’t derived from the promise of a ticket to the Super 14 final, but rather the appearance of a postal collection note for that 200MB/s write-rate SSD from Newegg.

Senior Developer Quality 4: Humility

Getting to the point of truly grokking that no matter how good you think you are, there’s always someone else out there who’s better than you are is a watershed moment.  In all honesty though, no-one enjoys an arrogant git … it just isn’t conducive to greasing the cogs of the team dynamic.  The more numerous the alpha-geeks in a team, the more critical the quality of humility becomes.

Senior Developer Quality 5: Experience

There’s a bit of cross-over here with quality 1, so let’s say that in this case we’re particularly interested in the sort of experience that gives you that technical “gut feel”.  After a number of years, the neural pathways have been set up so that you can generally “smell” whether something sounds right or it doesn’t (when interacting with colleagues), and your hunch about where problems may lie tend to be more often right than wrong.

Step 2: Screen ‘em

When it comes to finding good people, and when you don’t have the luxury of a network-enabled direct route, it boils down to a numbers game.

Spolsky advocates the phone screen, but we’ve opted for a technical assessment.  Do we really want to waste our time sitting down to chat with someone if they don’t make the bar?  So to be sure, this is an effort to weed out those who think they represent our definition of Senior Developer, but who don’t.

A simple test should suffice.  I drafted one this morning, and I’m going to publish one of the questions (with sample answer).  Now you’ll notice that the problem posed isn’t very challenging (although some of my colleagues beg to differ), but you’d be surprised at how many people who sell themselves as senior developers who can’t do it.

My lazy side originally opted to go for one of those shrink-wrapped multiple choice online assessments ala Brainbench.  I’m not going to mention the brand of assessment that is our corporate standard because I have nothing good to say about it—typographical errors, and code that wouldn’t compile in almost every single question?  I wasn’t impressed either.  Suffice it to say, it’s not Brainbench.  Whatever the choice of assessor though, all of these tests suffer from the same problem; they tend to test stuff that we would naturally expect to Google these days.  I don’t rate that as being particularly useful at all.

Solver, above, may seem overly mathematical and unrepresentative of typical “throw-stuff-in-a-database-and-pull-it-out-again” business requirements, but what it does do is very quickly highlight the sort of person we don’t want.

• Do we want someone who can’t understand the question because it contains “nasty unknowable symbols”?  Even if you didn’t do maths at university, surely you did algebra at school?  That’s all you need to know.
• Do we want someone who can’t do research on the Internet?  Jeepers, I even provided the exact Wikipedia search.  The corresponding article, predictably, contains pseudo-code for various algorithms—would you honestly need more than that?
• Do we want someone whose brain can’t be stretched to understanding an iterative algorithm to which they haven’t previously been introduced?
• Do we want someone who doesn’t know enough to fire up the browser and at least try “+”root-finding” +C#” on Google?  (Yes, I do check the browser history afterwards :)

Of course I’m not expecting Newton’s method here, simple bisection will suffice.  Even if our prospective senior has never attended a calculus class, I would expect her to be able to fathom this one unassisted.

Here’s my bisection code, written up and tested in 20 minutes—too much time, I might add, for what I would consider a senior who lives and breathes code:

	class Program
	{
		static void Main(string[] args)
		{
			var lhs = (Func<double,double>) (x => x * x - 3);
			var rhs = (Func<double, double>)(x => x * Math.Log(x));
			var diff = (Func<double,double>) (x => rhs(x) - lhs(x));
			const double threshold = 1e-5;

			Func<double,double,double> findRoot = null;
			findRoot =
			((l, r) =>
			{
				if (Math.Abs(l-r) < threshold)
					return l;
				var mid = (r+l) / 2;
				return (Math.Sign(diff(l)) == Math.Sign(diff(mid))) ? findRoot(mid, r) : findRoot(l, mid);
			});

			Console.WriteLine(Math.Round(findRoot(1,50), 2));
			Console.ReadLine();
		}
	}

Now the big problem with bisection, of course, is local minima, but that is a non-issue because I even provide a graph illustrating that there aren’t any local minima.

It’s time to wrap this post up, and defer description of the how testing against qualities 1 to 5 should be done to another one.  Today we presented our first senior candidate with Solver, but you can probably guess what the outcome was when I tell you that he couldn’t nail Fibonacci which was to print out the first 30 terms of the sequence of the same name.  Sad, indeed.

Today is the penultimate day of my three day stint at Africa’s premiere Microsoft event.  Things have improved significantly from the dull-and-wet environs that I stepped out of the plane into two days ago, to a very pleasant, warm and cloudless tropical playground.  Too bad I haven’t had a chance to do any “fun in the sun”.

The event itself has been very well organised thus far, starting with a cool, hip and happening keynote and intro party on Sunday evening.  Being the staid geek that I am though, and despite the extremely enticing party hats and masks, I left early.

Monday was a mad-rush to make very efficient use of my time, and not a moment was wasted on anything but sessions … one after another with on average, less than 20 minutes between each one.  From sunrise to sunset, no time for lunch (lunch packs were provided for those whose information appetite overshadowed their gastric cravings).  Sadly, my eagerness has since waned.

Let’s do a walk-through to date:

Monday, August 3^rd

Starting the day, Brian Noyes told us about new tools and controls for WPF.  Brian is clearly very sussed when it comes to the relatively new “dub-effs”, namely WF, WCF and WPF (anyone know what happened to CardSpace?) and I’m quite sure it doesn’t stop there.  This demo-driven talk was thorough, and correct, and aimed just right re the audience.  Problem is … I found myself nodding off.  That may of course be an indication of my generally poor ability to focus—I’m going to give Brian the benefit of the doubt here.

Next up was Bart de Smet, with a talk on how to deal with the inevitable paradigm shift from Hertz to cores.  I subscribe to Barts blog, but I have to admit that I usually set aside half a day to read any new entries, since it’s not exactly light reading.  This guy is super-bright;  we’re talking a young Richard Feynman with a sense of humour to match.  In any case, a very technical subject was dealt with deftly, and we got to hear about all the various incarnations of Microsoft’s attempt to give us a developers a way of “spreading out” to multiple cores.  The principle message here being that there’s no silver bullet (meh).

Ahmed Salijee then gave us a fairly comprehensive overview of what’s new in .NET 4.0.  Apart from the new WF stuff, there wasn’t anything that I hadn’t already gleaned from a rather old PDC Anders intro that I’d watched quite some time ago.  Ahmed was our first South African presenter, and held the flag high.  I would say though that the pre-arranged code snippets made things a little difficult to follow, but given the huge amount he got through in the relatively short amount of time, it was a noble effort.  At least everything worked!

Now jQuery is just so super-cool that I couldn’t resist the session by Hilton Giesenow on the same.  Hilton is made for speaking and there wasn’t a moment where I found myself distracted.  Everything was demo’d using the awesome Firebug to such an extent that at one point I was wondering if jQuery’s glory hadn’t been stolen by Firebug.  Of course, all the demos happened in Firefox which made the presentation all the more satisfying.  Hilton has awesome potential, but wow … things went pear-shaped.  The little bits of code that he demo’d were hand-written, and well … didn’t work.  There were regular appeals to the audience of “can someone see the problem here?”.  Just a little bit of prep can make a world of difference, Hilton.

Tuesday, 4^th August

I was scheduled to attend Brian Noyes’ talk on developing service oriented workflows, but since I’d forgotten my caffeine tablets at the hotel, I opted to try out Jayesh Mowjee’s non-dev talk.  Jayesh endeavoured to inspire us with a Windows 7 security overview.  Jayesh is a seriously dynamic speaker and could probably do some stand-up moonlighting; he’s that confident.  He also knows his stuff.  Being a dev at heart, I can’t say I was inspired to preach his message from mountain-tops—let that be no reflection on his abilities though.  So what’s new in Windows 7 security?  Erm … lots of cool audit trails that’ll keep your annually visiting Delloitte and Touche droids happy as pigs in the proverbial.

Up next: John deVadoss on Windows Azure and the Cloud.  It’s funny how a small glitch in someone’s talk can ruin the whole thing—like not being able to connect to your box at Redmond so that you can do your key demo—the demo that makes or breaks your session.  Someone should have told John that we have a virtual telecoms monopoly in South Africa that on Monday just so happened to be the victim of a wage strike.  So do an rdesktop with 24-bit colour at high resolution over that thar Internet connection … at your peril.  The content?  I forget … still having flashes of embarrassment on Johns behalf, as his presentation went into an unrecoverable tail-spin.

After an extended break I attended Donald Farmers talk on a groundbreaking initiative, namely Gemini.  This presentation was stellar.  Donald went to great lengths to prepare a novel presentation for us—completely different from the somewhat tired bullet-point infested standard PowerPoint slide-set.  He used a great metaphor of the evolution of a bicycle for everyone’s workhorse … Excel.  Tandem bicycles represented Excel extended for workgroups, bicycles with shoe-spoked wheels talked to Excel being used as a square peg being pushed into a round hole, an envious kid looking on as friends ride their shiny new bikes past, communicated how everyone wants the latest-and-greatest incarnation of Excel.  All in a retro setting, for effect … a great, fresh, unexpected approach.

Oh, and the content was good too.  I got excited by this stuff because it promises to address a pervasive issue that’s close to home.  It’s the story of how in any organisation, the systems story doesn’t end at those systems that are looked after by us IT people.  There are a myriad systems out there that we don’t know about.  They may be mentioned idly in conversation—if we’re lucky.  They may be mentioned when they fail, and, unbeknownst to any IT staff, just happen to support a critical function in the business.  They live inside Excel, on a business-persons desktop.  Gemini promises to address this issue—make it maintainable, sustainable and monitor it.  Instead of chastising business for building un-maintainable spreadsheets, it supports this practice, but fills in the gaps, by providing an interactive OLAP-like experience, right inside Excel, and by tracking data that’s used by business through integration with Reporting Services.  An emphatic thumbs-up to Donald for what I’m sure we will see become the next killer app.  Excel hasn’t seen an enhancement this momentous to date.

Now, that’s not really everyone, it’s just everyone who made an impression on me.  I do get the impression though that TechEd Africa is seen as kind of a presenters sandbox.  This is because, in general, there was somewhat of a lackadaisical approach to presentation from the overseas presenters (that is, except for Donald and Bart)—almost as if it didn’t matter too much if there were screw-ups … it’s Africa after all.  The basics just weren’t covered—like doing a little research into the nature of Internet connectivity in South Africa (it’s nothing like what one gets in the States), and not hinging the better part of your presentation on an RDP session to some server at Redmond without testing it beforehand.  That’s just plain unprofessional.

In general there was also a disparity in quality of presentation between overseas presenters and local presenters—for that reason I tended to favour the Americans when choosing sessions.  Eben de Wit and his entourage could have geared up the pre-keynote prep before inflicting numerous demo failures on the audience.  I didn’t appreciate the anti-Linux gag when demo’ing the systems management stuff either, everything about Microsoft’s recent culture shift says that we’ve all moved on from juvenile sniping.

Is there anyone I haven’t managed to slag off yet?  Seriously though, all-in-all a pretty well organised affair, even though the general quality of presentations could be upped a notch.  Apart from Donald’s talk I can’t really say that I learned anything earth-shatteringly new … well … I did get to read about booting VHD’s from Windows 7 on Scott Hanselman’s blog during an inter-session break :).  In fairness, the jury isn’t out—perhaps today I’ll be completely blown away by some newfangled technology that allows you to remote to a Windows server over a flaky 54kbps connection using 10000:1 fractal compression whilst making things seem like you’re on the LAN … but I doubt it.

UPDATE: The ending keynote by Arthur Goldstuck was definitely worthwhile, otherwise Lynn Langits talk on migrating applications to Windows 7 was enlightening.  Morne Blakes “level 400″ talk “Case of the Unexplained 3″ (Mimicing Mark Russinovich’s notable series) left a whole lot to be desired and definitely wasn’t as advanced as it promised to be (pretty much everything he said I already knew).