Desert Code Camp -- Day 2

Well, it’s actually day 1, but it’s day two in Tempe (tem-PEE) for me.  Here’s the summary.

C# 3.0 Beyond Linq:  This was my presentation.  Nothing special here.  Take a look at the Simple Properties and Extension methods screencasts that I have posted and you’ll get the basic gist of the presentation.  I swear that I will finish the Lambdas screencast soon….honest.  The coolest thing in this presentation was the 10 year old kid that attended.  What I was covering wasn’t rocket science, but this kid asked some of the most intelligent and pointed questions.  He was really groking potential limitations and implementations of the stuff I was showing.  After the presentation I spoke with him and his mom and this kid is working, with a mentor, on writing an ASP.NET application for a real live client.  I really wish I’d had opportunities like this when I was a kid.

Intro to Linux for Desktop Users:  Painful.  These guys were trying to show how easy it was to use Linux as a desktop OS.  Well….I admit that I don’t use a projector at home, but when that doesn’t work and the presentation is done by holding up a laptop screen in front of the room, I begin to thing that there still might be a problem.  The guys were good enough to provide a CD with Ubuntu so that we could follow along.  This was very painful to watch and didn’t, unfortunately, give me the intro that I really wanted.

ObjectBuilder/Composite UI Application Block:  This is the first time I’ve sat in a technical presentation and felt like JP would in a presentation on DataSets.  It’s obvious that this guy knows CAB.  Ha!  He just muttered “It seems so complicated”….a sure sign that it is more complicated that it needs to be.  CAB looks like a beast.  I don’t like the fact that your type mapping (i.e. when asking for ICustomer please give me the Customer object type) is burned into the code.  When I asked why you’d want this the response was that it allows you to compartmentalize your code so that no knowledge of it is made outside your “module”.  Apparently putting the mapping into an XML file, like Castle Windsor does, would expose to much information for potentially nefarious uses (what they may be eludes me, but whatever).  CAB will not allow you to provide dependency injection to the first form that is being loaded by the application.  I guess you’d better hope that the first form doesn’t have any smarts.  I hope that this is not his standard coding practice….multiple public classes in one file…blech.  The ProfileCatalog is how the modules are registered with CAB.  It loads the objects in reverse.  Oh my…..Single Responsibility Principle hasn’t made it to this part of Arizona yet.  This is some nasty shite.  Looking at this I don’t see how it could be easily mocked.  It would probably take a lot of proxies and wrappers just to be able to mock.  I might be wrong on that, but I don’t see why I should have to go to all that extra work just to mock a layer.

My analysis….CAB is a plug-in architecture that is using dependency injection.  Not something unreasonable to be hand-rolled in a day or two with the right tools.  If you did that you’d have something a little less “elephant-in-a-china-shop” and it would probably expose a lot prettier interface to the developer that was consuming it.

Wrapup:  Well, according to Lorin they gave away about 400 handouts so this has to be considered a big success.  The content was good and the attendees were pretty intense.


Well, we’re off to a Google piss up.  Like always, I’m going to see if I can bankrupt one of the biggest computer companies in the world through alcohol consumption.