Goodbye Basecamp

So I stumbled upon Project Pier, an open source project management tool not that dissimilar from basecamp. (I actually think the project started out as a ripoff of basecamp)

So I downloaded it, installed it on one of my dev machines, and started using it for a couple of days instead of basecamp to see how it would compare. With the exception of no comments on task lists or task items themselves, I must say I'm in love with it. The UI could use some work, but the project does have a full theme system built in (at least I think I saw that out on the site somewhere) There is even some discussion of importing basecamp projects from xml, so I'm super excited about all of this.

Being that its all open source, we won't be restricted to a set number of projects or have to pay the monthly SaaS fee. Its codebase is entirely in PHP, so we'll be able to throw it on our linux hosting that we already have. The only thing that wasn't straight forward and does make less sense (from a users perspective) is that the installation requires its MySQL database server to run InnoDB instead of the MyISAM data storage engine. I can understand if it made the project easier to get started development-wise, but now that its released to the public, you would think that they would use as much standardization as possible. (my dev box's mysql server was easy enough to configure properly, but I'm sure it will be a nice little battle to talk to our web hosting platform into helping us configure our linux machine's mysql servers to run the proper storage engine) I guess in all fairness there is a 'hack' around the innodb stuff so that it will run through the myisam storage engine, but it is just that: a hack....

Well there you have it. I'm sure I'll be posting more about Pier in the near future.

This seems to be the way to go...

Installer woes

I have been working like a madman for the past few days trying to clean up some installation problems that have crept up on some old releases that are still being distributed to Appian's update client list...

One of the components of the installer has a US and a Canada version that seem to be working separately, but when we combine them to run as one process using all of the data for both versions, it starts getting a little foggy and the service isn't starting anymore for some reason.

For a while I was using some nonstandard/funky end of line characters that Windows' notepad didn't particularly care for. (square boxes instead of text resuming on the next line, but wordpad opens it up just fine... go figure) Anyways so I figured out that in NSIS I need to put in
$/r$/n
for an end of line, instead of what i've been using in c# (just the classic /n).

So I thought all was well, but now I'm finding that I didn't update all of my code like I thought I had. So I've been going through each installer to make sure that I've got everything updated with the correct end of line character...

Some of my tests have also turned up that not all of the required data for the US is installing correctly. There are a number of files that do not exist on the target machine after my installer completes.

So if I never have to reverse engineer someone else's installer just to streamline our own installation process I will be a very happy man. It pays the bills, but boy is it ever so tedious, meticulous, and error prone.