January 2006 Archives
For some time now component technology has been touted as the saviour of the software development industry. The theory being as a developer I can purchase a set of components off the shelf and glue them together with my own code to create a completed application in double quick time.
As is often the case the reality is often quite different from the theory, over the last week I have been working with several frustrating problems in third party components in my own software.
Most commercial software has bugs, it would be quite unreasonable to expect components to be any different from the rest of the software world. The problem comes when your component supplier’s priorities don’t match your own. My business is small and flexible enough to address most issues in the product within a day or two, this gives us a huge advantage over bigger competitors who might not be so nimble.
Unfortunately even if your component vendor is able to respond as quickly as you you are still looking at double time to fix and resolve any problems. Sadly it’s usually much worse than that, it’s quite rare to find a component developer who gives support a high priority.
One option is to purchase source code to the components you are using, you can then dive in and fix any problems you encounter yourself. Back in the real world this isn’t much of a solution, the code is usually written with different conventions to your own and the learning curve is often substantial. Right now I’m struggling with some code in a HTML printing library, the issue I have will require many changes throughout the code.
Having gone through these problems with every third party library or component I have used I am coming to the conclusion that I will end up rewriting the code for all of them myself in the end. As to whether it makes sense to avoid using components from the start I’m not so sure, getting your product to market quickly is probably more important.
Like most software developers most of the traffic I get from download sites comes from CNet and Tucows. The other three hundred or so sites generate a fraction of the downloads that these two create.
There is a cost to listing on these sites, a small fee to get listed quickly or at all but more importantly the time managing updates or fixes for stolen key codes. My problem is I don’t know whether this investment in time and money gives me a large enough return, one of the most important things I figured out about this business is not to invest if you can’t measure the return you are getting.
Normally I track customers at my site by setting a cookie when they first arrive so by the time they get to order the software I can see where they first came from. For both CNet and Tucows this isn’t feasible as they host the software on their servers so the customer will download and try without visiting my sites.
The way I am doing this is by embedding the id of the download site in the file name of the program, for instance setup.exe is named setup_cnet.exe for the CNet site and setup_tucows.exe for the Tucows site. The installer stores the setup name in the registry and a small linking tool reads that information and embeds it in the url when launching the web browser, when the customer lands at my sites a cookie is set and tracking is working again.
Serving up a different file for all the download sites and affiliates would be a nightmare but fortunately Apache the server software on my web host supports a facility called url rewriting. This allows you to serve a different file to the one requested in the url, in my case CNet links to setup_cnet.exe and Tucows to setup_tucows.exe but the actual file downloaded is setup.exe. The important thing is this isn’t a redirect so the filename remains intact when downloaded. Enabling this required just two lines in my .htaccess file:
RewriteEngine on
RewriteRule ^setup_[a-zA-Z0-9]*\.exe$ /dl/setup.exe
This works by matching the url with a regular expression, anything starting with setup_ and ending with .exe and serving up the setup.exe file instead.
Storing that information in the registry is fairly easy, I use Inno Setup to create my installers and that has a variable {srcexe} which holds the path and name of the setup program. I just store that whole path in the registry ready to be read and interpreted when the user selects a link in the software to my web site.
If you want to have a play around with this I have created a sample (1 kb) which demonstrates the concept.
