Friday, November 23, 2007


I'm starting to regret that I recommended to my manager that we use InstallShield to build our installers. InstallShield does have a few nice features, such as allowing side-by-side installations of the same product, but from a developers point of view, it is so awkward to work with that I get frustrated each time I try to do something. The list of annoyances is getting rather long:
  • The COM automation interface is not complete: there is no way to create a new InstallShield project, certain attributes on components are not accessible, and you can add "previous media" in order to create an update installer. This forced me to manually patch the XML project file.
  • Silent operation is clunky at best, and just non-functional at worst. You need to twiddle around with response files, non-existing error reporting, weird command line flags, and there is no guarantee that it works. Why not have one single flag which runs the installation using all default values? And why do I need to supply a response file for uninstalling? Just remove the damn product!
  • InstallScript: this is a Pascal-ish language which just makes my brain hurt. There is no design behind it, data-structures have been added in an ad-hoc manner, and it's just painful to use. At least to people like me who are used to more modern programming languages such as Ruby and Python. (Actually, I'd choose just about any language before InstallScript: Perl, Java, Delphi, C, C++, Lisp, Smalltalk, you name it. Well, maybe not Cobol.)
  • There are several types of installers you can create: InstallScript-based, MSI-based, and a mixture of them. (And a bunch of others as well.) I would like to have different user manuals depending on which installer type you're using. The current manual is one monolith which is unclear all over the place about which options, functions, methods, etc. that applicable to each project type.
Oh, well. Now I'll stop whining and get back to work.

Thursday, November 15, 2007


Sometimes you stumble across a tool you wish you had started to use several years ago. A tool which solves (or at least simplifies) a lot of the problems you have when you're developing software. CruiseControl is such a tool; and I had had it on my radar for a couple of years but never gotten around to actually start using it until a few weeks ago.

CruiseControl (or one of its cousins: CruiseControl.NET, CruiseControl.rb) is a tool used to support Continuous Integration, a software development practice which is characterized by frequent commits (usually at least once a day), and regular automated builds several times per day. We haven't gotten around to adopting CI completely, but CC is still a great framework to take care of your automatic build. Here are some highlights:
  • It has nice web dashboard for monitoring the state of the builds. It tracks the time each build takes, and when a build is in progress it estimates time left based on the previous build.
  • It is easy to configure.
  • It can automatically trigger builds when commits are made to the source repository.
  • It can automatically send mails to all users which have participated in the last build (i.e. have commited code since the last successful build). If you want it to it can send mail to everyone for every build, but with several builds per day that quickly becomes annoying.
If you aren't using CruiseControl for your automatic building, you should do so. Now.