Valeriu Caraulean – Building Software

A snippet from a project I’ve been reading:

// -- FILE ------------------------------------------------------------------
// name       : UserConfig.cs
// created    :
// language   : c#
// environment: .NET 2.0
// --------------------------------------------------------------------------
using System;

namespace TheNamespace.Configuration
{

    // ------------------------------------------------------------------------
    public class UserConfig
    {

        // ----------------------------------------------------------------------
        public UserConfig( System.Configuration.Configuration configuration )
        {
            if ( configuration == null )
            {
                throw new ArgumentNullException( "configuration" );
            }

            this.configuration = configuration;
        } // UserConfig

        // ----------------------------------------------------------------------
        public System.Configuration.Configuration Configuration
        {
            get { return this.configuration; }
        } // Configuration

        // ----------------------------------------------------------------------
        public string FilePath
        {
            get { return this.configuration.FilePath; }
        } // FilePath

        // ----------------------------------------------------------------------
        // members
        private readonly System.Configuration.Configuration configuration;

    } // class UserConfig

} // namespace TheNamespace.Configuration
// -- EOF -------------------------------------------------------------------

It’s a matter of taste, of course, but I’m wondering, what is the reason to decorate the code with a such ceremony?

Much of the time we, developers, are spending reading the code. That’s why the code that is clean, easy to read and understand is so much appreciated.

Jimmy Bogard has a very nice summary of steps you can do to speed up building of your project or solution. By “build” I mean not just rebuilding solution from scratch, but doing also a complete run down: cleanup, rebuild and run your tests. This can be a local build performed on a developer’s machine, or a continuous integration build performed by dedicated build/integration server.

Some time ago, when build times grew to intolerable limits, we cut down number of projects in our solution. Along with a common output folders, this improved dramatically performance especially on integration server, where a single committed change threw running of few cascading builds and code analyses.

Now, slowest part of our build process are integration tests. A big part of them are “testing integrations” with database. Since we’re using real MS SQL Express 2008 instances to run them, tests are very slow. A natural solution is using of an in-memory database like SQLLite. We spent some time on this, but since our database interactions are not trivial (kind of multi-tenant & multi-database application) we gave up until better times. But I think we will be back to finish that, because with more tests written we’re pushing up build times. To give an idea how this can be done, Ayende Rahien has a very basic example how to use in-memory database to run NHibernate integration tests.