From Santa: Continuous Integration, Progress Bars, Build Scripts, Oh My!

Continuous Integration is a wonderful concept.  The basic idea is to get integration-level feedback as quickly as possible.  It’s done wonders for cutting down on “it builds on my machine but not on anyone elses” phenomenon.

A piece of software, the free version of CruiseControl.NET in this case, runs on a PC and checks the version control repository periodically (usually every 15mins or so).  Once it detects changes it grabs them and runs the build.  So when you forget to check in that COM library that a library your library depends on needs you find out within 15mins or so instead of the next morning.  Nightly builds are nice but continuous builds are nicer.

The rules of thumb that I’ve seen are for Progress bars are:

  • If an action takes up to 3 seconds to complete show an hourglass/busy cursor.
  • If an action takes 10 seconds or more then it needs to have a Progress Bar.

Progress Bars are pretty much the first thing to go when deadlines are tight so the holidays present a wonderful time to go back into those UIs on top of long running processes and add a progress bar.

When you've got a mix of managed and native code (a mixed blessing?) Visual Studio’s otherwise stellar dependency checking may show signs of wear.  This is probably due to the cobbled together mixture of post-build scripts and external bat (or NAnt) scripts that represent your “evolutionary” build.  The holidays are a wonderful time to make the build process less “evolutionary” and more “cultured” so-to-speak.

COM Interop Dance: To C++ or C#

So there’s a managed class that I’m using from within native code via COM Interop.  The managed class has a property that’s a bit like a collection; it stores multiple elements and can retrieve an element by it’s position within the collection.

Each element has an integral ID and a string descriptor.

The problem is that I now need to access these elements from within native code in a certain order (integral ID ascending).

A few approaches come to mind:

  1. Do the sort in native code.  Create a structure that stores the ID, Desc pair OR get a little more fancy and use an STL class.  Store these in a collection (or array).  With the STL class writing the code to sort the collection is more elegant (e.g., easily adapted to different element types) but ultimately I’ll still need to write what is essentially a function that the sort function will use to compare elements.
  2. Do the sort in managed code.  Since this is COM Interop, provide a method that returns a collection of the IDs in order then use the existing method to get the Desc for a given ID.  The collection can be accessed in native code via the smart pointer mscorlib::_ArrayListPtr.  This is probably easier to write but still doesn’t match what I think is conceptually the correct solution.
  3. Provide an enumerator over the collection of ID-Desc pairs.  This will require both managed and native code changes since there’s a little bit of plumbing to use a managed enumerators from C++ (no handy built-in foreach).  In pre 2.0 C# I’d say that this is the correct solution.
  4. Provide an iterator over the collection of ID-Desc pairs.  I think this is closest to the conceptually “ideal” solution.  Unfortunately I have no idea how to use iterators from native code.  And time is extremely short.

Since time is so extremely short I think I’ll go with option 2.  I spend more time in managed space (usually, though for the past month this hasn’t been true) so there’s less ramp up to making this work.

Design and the Nature of Things

While working on a project involving two applications an issue came up involving site customization.  It illustrates the importance of not fighting the nature of a given thing when faced with a design decision involving that thing.  This heuristic will usually save you a world of headache even if you can’t immediately think of circumstances in which it’ll prevent error.

There are 2 products (aka applications); when product A is installed, product B is also installed.  Unlike product A application B is often installed by itself.

Application B has a wonderful piece of software for site customization.  So wonderful in fact that it’s being drafted to perform its wonders in service of application A.

While going back and forth about the best way to accomplish this, someone suggested having the site customizer automatically detect the presence of application B and update both application A and application B so that the user doesn’t have to remember to run the site customizing software twice.

So far so good right?  What’s the problem?  Being a purist at heart the idea of having a site customizer automatically update 2 separate products immediately runs afoul of my instincts.  But instincts are not evidence and unless you’ve really developed an intuition for these things they aren’t compelling arguments.  Put another way, until you develop an intuition for design many conceptual objections will tend to be unpersuasive.

This being a project in the real world we quickly moved on to other problems.  Fortunately everyone was ok with not having the site customization software automatically update the 2 products.

Why fortunately?  Given a little time to think about it (in between long-running builds) it occured to me: What if product B has already been independently updated at the time the site customizer is run?  It could end up overwriting newer data with an older version of the data.  One of the benefits of having product B as a separate product was that it allowed us to get functionality out in the field in a way that didn’t require updating every product in the suite.

Of course this objection could be handled by the site customizer; it could check to make sure that it isnt overwriting a newer version of the data with an older version.  However, doing this well would require the data to carry along its own version information.  This is information that it currently doesn’t have.  This kind of version information often requires a system of its own to maintain since a file can go for many releases without any changes.  Without an automated system it’s yet another task to be forgotten during the often hectic process of releasing an upgraded version of software.

Versioning can be a pain but it’s not insurmountable.  Another objection is that it creates a dependency between the site customizer and the 2 specific products it was supposed to automatically update.  In computerese, the proposal raises the coupling between the site customizer and the customized applications.  Product B can no longer change its location (e.g., to support side-by-side installation) without breaking the site customizing program.

The cascade of issues resulting from a proposal that tends to fight against the nature of the underlying things is a design smell.

Another approach that provides the desired convenience without fighting against the nature of the products involved is to have a separate program/script/process that invokes the site customization program twice.

What’s the difference between putting this intelligence into the site customizer or having it invoked externally?  For one putting it in a separate program provides an opportunity to make explicit to the user the fact that they’re customizing product A and product B.  Several months down the road the fact that customizing product A automatically customizes product B may be forgotten (and lead to the unintended data corruption mentioned above).

Recall that the site customizer, initially intended to customize product B, has already been drafted into customizing product A.  It won’t be long before it’s customizing product C, D, etc… 

Having a separate program invoke the customizer will tend to encourage a design that easily accommodates customizing more than 1 product.  This kind of parameterization (loose coupling) of the customizer will make it that much easier to apply to products C, D, E, etc…

All of these benefits could have been lost, or made much more expensive, had we ignored the conceptual incongruence of making a relatively general purpose customizer try to do too much.

Visual C++ 6 to Visual Studio 2008

Porting the last vestige of VC++ 6 to Visual Studio 2008.  Over the years the Microsoft C++ compiler has gotten more standards compliant.  Oddities like:
for (int i=0; i < SOMEVAL; i++)
{
// ...
}

if ( i > SOMEOTHERVAL )





no longer pass muster; ISO C thankfully limits the scope of i to the block in which it is defined.  I say thankfully because it’s so common to use i as a loop variable that promoting its scope to the enclosing scope (the default behavior of older compilers) is asking for loops to step on each other’s loop counter.

Other things to keep an eye out for:

  • Turning off wchar_t as an implicit type if the existing 2008 solution/project has it disabled.
  • Mixing MBCS and Unicode.
  • Hardcoded paths to old versions of SDK header files (e.g., program files\visual studio\vc98\include\…)
  • Use of swprintf() without specifying a count for the maximum number of characters to write.

Design Patterns Quick Reference

A colleague recommended what appears to be a wonderful podcast for people interested in building software well.  IEEE Software’s On Architecture.  It’s authored by Grady Booch (one of the heavyweights in the Object Oriented Programming/Design world), the podcasts are short and sweet (typically less than 10minutes) and it’s even got a bit of a pedigree (being affiliated with the IEEE and all).

After listening to a few of the podcasts I was struck with a desire to revisit basic heuristics of the trade.  The classic work on design patterns was written by a group of authors colloquially known as the Gang of Four.  It’s an excellent reference but it isn’t exactly compact.

I stumbled onto a Design Patterns “cheat sheet”.  It’s even color coded by pattern type! (structural vs behavioral vs creational).  Kudos to Jason S. McDonald for his handiwork.