There are a few alternatives to Adobe ColdFusion, and when I say “alternatives”, I mean ColdFusion engines other than Adobe’s official ColdFusion engine, not language alternatives like Ruby or PHP.

If you are developing for a large organization or company that can afford Adobe’s licensing (or actually needs some of the advanced features that only come with Adobe’s version of ColdFusion), then I certainly recommend sticking with Adobe. You will get strong support from Adobe, there may be newer features that you can get first while other engines play catch-up with Adobe, it is easy to install and get running, and it is the de facto standard. However, some of us are independent developers or [very] small businesses that don’t have the financial clout nor the need for advanced features that you see in Adobe’s editions of ColdFusion. There are alternatives for us.

BlueDragon from New Atlanta is probably the most popular alternative engine because it is cheaper but still a commercial product with support. Thus, this is a great alternative for a company that can stand to make the purchase but might sweat at Adobe’s price tag. Additionally, BlueDragon is available in a free edition for non-commercial, non-SSL use. If that fits your needs, BlueDragon is a great solution for you, still being easy to install and get running, and benefiting from the fine-tuning of a commercial product.

Railo is similar to BlueDragon in that it is a commercial product with a free edition, although the free edition seems a bit more crippled than BlueDragon. Admittedly, of all the ColdFusion alternatives, I know the least about Railo. Being that the company is based out of Switzerland, the pricing is not available in dollars, and the allowances for the free edition are a bit more confused, I am reluctant to experiment or recommend Railo. None of these barriers are technological and my conclusion is thus no reflection on the quality of the product.

Finally, Smith is a free ColdFusion engine. There are no licensing costs whatsoever. It is built upon several open source initiatives and, although it itself is not currently an open source project, it is offered as freeware. This is a great way to get your server running ColdFusion at a low cost, but recognize that nothing is free. What you save in product cost could just end up being at least partially reallocated to a cost in person-hours; Smith is [understandably] not as straightforward to configure as CFMX or BlueDragon. Smith does have its own web-based administration just like CFMX and BlueDragon, but it is not as thorough, and a deeper understanding of Tomcat or Jetty and other open source tools may be required to get your sites configured how you want. This may be a barrier for some, a deterrent for others. But if you have the technical strength to manage it and you don’t need the features it lacks, Smith is a great opportunity to save some money on a ColdFusion solution.

Which solution is right for you? It depends on your needs and your pocketbook. Smith is a great free solution but may require more hours for setup and maintenance; BlueDragon is a great solution to save a bit of money but still have an extremely polished product with good support; Adobe’s ColdFusion is obviously the industry standard and is ideal if you can swing it. These evaluations are considering very generic needs and do not consider other extenuating circumstances, such as driver support, .Net support, and so on. No solution is a “silver bullet” when considering your cost/feature ratio. Nevertheless, it is good to see the options growing.

In my effort to improve application documentation, I’ve found myself improving my versioning methodology to be more meaningful. I work on a variety of applications on an intranet site serving as an “application farm”, so my apps are constantly having revisions as our needs change or grow. Versioning is complex and should vary based on the needs of the development environment. I’ve found the following approach beneficial for my “application farm”.

Application Versioning

The following recommendation came from Don’t Back Down: New Versioning Guidelines. This methodology is best suited for application development, where versions are most meaningful in relation to the features being developed.

• Use a three-number, two-dot version number (X.Y.Z, such as 1.0.3).
  • The major version number (”X”, first number) changes when significant extra functionality is added to a release or a large number of smaller functions are added since the last major release so that the product is now vastly different. The latter scenario is obviously subjective; thus, simply using good judgment is required.
  • The minor version number (”Y”, second number) changes upon releasing new features that did not exist in the product before but do not vastly change the appearance or behavior of the application.
  • The release number (”Z”, last number) likely changes the most often, and is incremented any time a bug fix or optimization is released or an extremely small functionality enhancement is added.

Version incrementing. The three version numbers ought to be treated as separate numbers that do not impact their superiors. For instance, 1.1.9 would increment to 1.1.10, not 1.2.0. If the programmer decided that enough minor version changes have occurred to warrant a major version increment (i.e. 1.15.0 -> 2.0.0), that is acceptable and is the programmer’s prerogative. A version increment resets its subordinates to zero (i.e. 1.5.8 -> 1.6.0, or 1.5.8 -> 2.0.0).

Repository check-in versioning. In the case that the application is in a source code repository (and it should be), you may also decide to place the exact repository revision associated with the tagged version. This is superfluous, but leaves no doubt as to the precise version of the code. This number may be delimited differently since it isn’t really part of the tagged version number (i.e. 1.5.8R253 or 1.5.8-253, for “Release 253″).

Library or API Versioning

Versioning for functions, classes, custom tags, libraries, and APIs is better suited by compatibility versioning. That is, you can determine compatibility simply by looking at the difference in version numbers.

The following principles were pulled from ADC: Framework Versions and The Jakarta Site: Versioning Guidelines, which are guidelines for existing public systems, and Brian’s Waste of Time: Versioning at the Airport, a commentary on versioning by an open-source developer.

• Version numbers are of the form X.Y.Z, but do not have the traditional meaning of major, minor, and bugfix, though it frequently may work out that way. Call them major.minor.point versions; the version numbering serves as a guide for compatibility.
  • Different major (X) versions are not compatible. Thus, apps using v2.5 would break if they switch to v3.0.
  • Different minor (Y) versions are backwards compatible. Thus, apps using v1.4 would continue to function using v1.5 without any changes to code. They either add new interfaces or modify existing interfaces to provide new behavior without changing the old behavior.
  • Different point (Z) versions are forward compatible. Thus, if you are developing against v1.2.17 and find a bug that didn’t exist in v1.2.15, you can drop to the older version without any changes to code.

Major Version Examples. Examples of actions necessitating major version increments: (a) Removing or renaming public interfaces, such as a method in a class. (b) Changing data layouts, such as in a database or file. (c) Changing the signature (the order, type, or number of parameters) of a public function or method.

Avoiding Major Version Changes. Before implementing the library/class/API, consider its implementation carefully. Don’t publish a class, function, or method unless you want your clients to use them. Don’t delete interfaces; instead, leave them in for compatibility purposes, returning a reasonable value. If you need to alter the signature of a function/method, leave it compatible in the old form if possible. This frequently can be done by adding a parameter to the end of the list and assigning it a typical default value.

Minor Version Examples. Minor versions retain compatibility with their linked applications. They don’t change existing interfaces; they add new interfaces or modify the implementation of existing interfaces in ways that provide new behavior without changing the old behavior. (a) Adding a class/function/method. (b) Make enhancements that don’t change your public interfaces.

Point Version Examples. Point versions are typically bug fixes or optimizations implemented in such a way that dropping from a newer version to an older version wouldn’t break an application. (a) Bug fixes not affecting programming interfaces. (b) Optimizations that do not affect programming interfaces.

Development States

It is worth considering a list of defined standardized states an application or library may be in.

• In Development. Application is new and still relatively unstable.
• Beta. Application is considered relatively complete but not thoroughly tested. The programmer(s) and client(s) should begin rigorously testing the application, on a test platform or database if necessary.
• Released. Once an application reaches production quality, it can be set to this state, meaning it is ready to be deployed and used. Even when revisions are made and are individually in a beta state, the application itself, in its current version, remains in a released state.
• Unsupported. When an application is entirely supplanted by another application or for any other reason it is retired or obsoleted for supported use, it reaches an unsupported state.

Prerelease Versioning

Small projects may not have a tagged version until the final release. While in development, they may be referred to by their repository revision. If a project is large enough, the programmer(s) may opt to implement versioning on the prerelease project. If this is done, they could use a major version of zero (for instance, the first version thus being v0.1.0). The beta release would then also be a zero-version number. Once the development state moves from beta to released, the version can be updated to v1.0.0.

Conclusion. Again, the approach to versioning will vary from one team to the next, and from one environment to the next. Web app versioning may vary from compiled app versioning. But even web apps should be housed within a repository, with key points in the applications’ lives tagged as versions, to improve documentation and deployment tasks.

I was pulling my hair out on Wednesday trying to figure out why certain inline images in an email I was generating would not display in Outlook, whereas others would.

What’s more irritating is that all of the images worked in Outlook Web Access; only the desktop client of Outlook wouldn’t display some of the images.

The problem is that something like this is really hard to troubleshoot. After going down many different paths–such as assuming that I was attaching the image incorrectly, or perhaps that Outlook didn’t like spaces in its inline attachments, and so on–I finally found the solution.

Outlook was recently patched to flag image references that have a src attribute with a capitalized CID. Thus, changing < img src = "CID:myimage" > to < img src = "cid:myimage" > fixed the matter.

Oh man. That’s frustrating. So I’m blogging about it in hopes that I might save someone who googled the issue like I did from wasting a couple hours of time.