Chicago Code Camp Retrospective

Today was a long day, because I made the trek down to the Chicago Code Camp.  Aside from the two hour drive each way, it was a good experience.  Here's a summary of the sessions.

Trends in Continuous Integration with Software Delivery

This was presented by Sean Blanton.  Essentially it was talking about the benefits of having a build server in your environment that creates a build more than just a nightly build.  There was very little technical information in the session, as most of it was a higher level view of the need of CI.  Of course the concept of build automation came up, but he also brought up about about workflow automation.  Essentially the pipeline concept that Cruise uses is a good example of workflow automation.  A build happens and the outcome will determine the next action.  Run the unit tests, run integration tests, code coverage, email status/reports of the build somewhere, create installation package, deploy to another environment, etc.  All part of the workflow automation.

Guarding Your Code with Code Contracts

This was presented by Derik Whittaker.  The topic was about the Code Contracts project that came out of Microsoft DevLabs.  It's going to be part of Visual Studio 2010, but is available now.  Of course it's still pretty early in development so the interface and functionality are a little clunky and are quite likely to change.  I recall reading an article about it not that long ago, but I can't seem to find it at the moment.  Overall the project seems awesome.  There's two extremely awesome things that Derik brought up in the presentation.  One was the ContractInvariantMethodAttribute.  What it does is insert a call to the method prior to any method returns for every other method in the class.  This comes in handy when you want to ensure that a class remains in a valid state after any method call.  And it saves the developer from having to manually add that call to every method.  The other awesome thing is that the contracts calls can undergo static analysis.  So being able to compile the code and see where there is violations to called methods is simply brilliant.  Granted they currently only show up as warnings in VS, but still awesome.

Testing GUI's

This was presented by Micah Martin.  During the session I re-read the abstract of the session and wished there was a little more detail about it.  Basically it dealt with reworking the UI in Ruby applications (both rich client and web apps) using a framework called LimeLight.  While I'm pretty sure I'd never end up using the framework, Micah did a pretty good job with the presentation despite the feeling that nearly the entire audience was expecting something else.  About the only thing I got out of the session was a reminder that I still want to learn Ruby at some point.

MassTransit

This was presented by Dru Sellers.  Mass Transit is a messaging bus that promotes the publish/subscribe design pattern in a very decoupled way.  It's under development by Dru and Chris Patterson.  Having read a few posts about it didn't really shed the light on what the project is or how it's meant to be used quite the same way that Dru explained it.  It was a very informal type of presentation, more like a group talk with Dru leading most of it.  While I can't currently see the need for a framework like it in most solutions I've worked with, it will be an interesting project to keep in mind for the future.

Developing Solid WPF Application

This was lead by Michael Eaton.  Despite being the last session of the day, Michael managed to present some great material.  He essentially took a WPF application that would be very representative of how a WinForms programmer would approach it: everything in the code behind, very simple use of bindings, extremely painful to unit test in any fashion.  Taking this horrible code, attempts to refactor it to make better use WPF features like RoutedUICommands and better bindings.  As well as decoupling the code and attempting a MVC pattern.  While that pattern can work, he then went into how the MVVM.  Unfortunately he was doing a great job of explaining things that he went short on time.  Also being that late in the day it was hard to stay focused on the presentation, despite how great the material was.

Updating the Last Modified Date of a directory

Working with a lot of compressed (.ZIP) folders can have some interesting side effects when you decompress them.  Windows will list all the folders (and subfolders) as having a last modified date of when you decompressed the file.  That may be well and good for most people, but it annoyed me to no end because I typically sort directories by the Last Modified Date as I work with the most recent files the most often.  Plus, downloading a file that hasn't been updated in a couple years and unzipping it can cause some confusion when you see the folder as being last modified today, but every file in it was created/modified a few years ago.  Why not have the folder actually reflect the date it was last modified by the files, not the OS?  That makes better sense to me, so I created a dead simple console app to do just that.

The console application will recursively go down a directory structure and give you a status of the folders and the Last Modified Date's new value.  By default, it will go down a maximum of 300 folders.  That should more than cover most directory trees.  If you want to limit it to only a couple levels, you can call the application from the command line, passing in a number after the folder and it will recourse only that many levels.

One thing you'll notice in the output (more so if you run it in a console window rather than from the context menu that's part of the installer) is that the path names are rarely wider than the screen.  There's a few different ways to accomplish this task, and since I'm not a fan of depending on system libraries in managed code, I took the approach of implementing the function myself based on code I found online.  I can't recall where I originally came across it, but I modified a couple logic errors that were in it.  Take a look at the DirectoryUpdater.CompactFilePath() method if you're interested.

I also built a Windows Installer Xml (WiX) installer because it's so much easier to just right-click on a folder and tell it to update the last modified date.  So as a custom action in the installer it creates the appropriate registry keys for the context action.  As I'm still extremely new to WiX, the only way to have it install them is to choose a Custom install and change the "Context Menu" item to "Will be installed on local hard drive".  Hopefully will get that figured out at some point.

Source code download from here.
Executable download from here.
MSI Installer download from here.