The marketing material provided by Adobe is vague about the growth of the product, focusing mainly on the growth of the developer count. This is misleading, since the amount of developers familiar with ColdFusion can’t really decline much, and those developers are not asked how much they still use CF. They also mention the amount of companies using ColdFusion. That’s like Ford announcing the amount of companies that use their trucks. Even if a huge company has an exclusive agreement with Chevrolet, I’m sure they have a Ford stuck in a garage someplace.

The marketing information is also heavily aimed at large enterprises. This is where the product is being used right now and where it will continue to be used for the foreseeable future. ColdFusion finds itself in this corporate world, where product cycles are slow and bleeding edge technology is avoided like the plague. It is rare to see a development team using the latest version of  any software, shunning it until others test and discover the bugs. To this end, I still encounter ColdFusion apps in active use that are running on version 5, soon to be 10 years old.

I once worked with a team of 5-6 developers on a ColdFusion Project. I mentioned that I was excited about the new features coming up in CF8. None of the other devs knew that there was a new version coming out, and a couple asked which version we were using.

ColdFusion has some huge benefits. In short time a developer can be brought up to speed and developers of all skill levels can contribute to large projects. Large companies love this model, since developer turnover can have lower impact on product support. I’d have no problem recommending ColdFusion for huge projects based on its capabilities, but that is not the only factor. You need to make sure your developers (who will be the source of any innovation in your project) are working with tools that inspire them to innovate.

And What About Those Developers?

Part of each developer’s inspiration needs to come from her peers, and not only the ones she works with every day. Good developers are active in the community, contributing to or consuming streams of daily RSS feeds. I’ve found the ColdFusion community to be second to none on all levels, except perhaps, their relative abundance. Anyone who has searched for a code snippet or a solution to a CF problem knows that four times out of five a Google search will land you on one of a handful of blogs for your answer. We all know who they are, and they are all fantastic and extraordinarily helpful, but they are few, and the success of the platform relies heavily on this group.

Conferences are also a wonderful forum for developer inspiration. ColdFusion is down to two or three conferences a year, occupies only a small part of the MAX conference (thankfully bolstered by an excellent community driven “un-conference”), and the content is frequently focussed on Flex, which Adobe prefers to keep arm’s length from any mention of ColdFusion. In contrast, there was a Ruby on Rails conference every week this summer, for a total of 20 in a six month span.

I find that developers are much happier working on a project using a technology that they know will be around for a while. I do my best work when I know the code I’m writing will be pasted into a future application. This helps me on my next project and helps the next developer who sees my code.

In the places where ColdFusion thrives—Fortune 500 companies, government agencies, and universities—developers are often locked into a routine that does not include innovation. I’ve seen this first hand. Innovation is inextricably paired with risk, the mitigation of which is often the most important goal in these institutions.

The Future

It’s getting easier to get an application out to the public. Finding good hosting is a breeze, and you don’t need a sysadmin to install your application. Cloud computing allows us to go from a test application on a laptop to a scalable thriving website in a day. The fact is that small development teams launching medium sized applications are using Ruby, Python, and PHP. These applications used to be out of question for enterprise use, but that is changing. Small teams like 37 Signals have seen their applications creep into some very large companies—even against their own recommendations.

Corporations have tended to choose ColdFusion when building applications in-house, but now more often than not, they are outsourcing the work, buying well tested and supported enterprise level applications that reside on external servers.

A huge benefit of ColdFusion is the time in which a server can be up and running for any size of project. It is no longer a leader in this department, and given the fact that most of the competitors are open-source projects with massive user groups, ColdFusion needs to offer a lot more to keep up. Adobe is capable of this, but only if it is profitable, and that’s not a sure thing.

ColdFusion is Not Dead

I happen to think the future of CF could be quite bright indeed. Adobe does some amazing and innovative things, and they have the ability and creative minds to build this product. My biggest fear is that growing the product will become less worthwhile for them as fewer corporations invest in their own applications. If CF is offered in a cloud computing environment (which I believe Adobe is still considering) its ability to integrate well with existing enterprise products will allow it to be a great rapid deployment option for companies of all sizes.

This is a good argument for URL rewriting, as is the fact that semantic and descriptive URLs assist in search engine ranking, and general usability. I rewriting my URLs because I like the way they look. I think a website looks much more polished when the URLs are descriptive, free of variable/value pairs, and as short possible.

Since I tend to use Apache with most of the sites I work on, and I recommend you do the same wherever possible, I’m only going to talk about using mod_rewrite, an almost universal Apache module for URL rewriting. There are similar solutions available for other web servers. I’ll show you an example use of mod_rewrite for a skeleton example site. I’ll provide all the code as well so you can play around with a working example. Please remember that this is just a quick overview of the mod_rewrite functions, and how they can be used with ColdFusion. It is always a good idea to lock down your Apache install as much as possible for public sites, and it should also be noted that using mod_rewrite does involve a small performance hit.

Turn on mod_rewrite

You may already have the mod_rewrite module activated in Apache. It’s simple to check. You need to be familiar with editing the httpd.conf file for your Apache install.

Make sure the following line in your httpd.conf file is NOT commented out (it commented out by default).

LoadModule rewrite_module libexec/apache2/mod_rewrite.so

Another thing you need to be sure of is that the AllowOverride directive is turned on for your web root.  The default settings in apache is “none”.  This needs to be changed to “all” to enable the .htaccess file to change Apache settings. This can be found either in the default section it can be set on a per directory basis.

1
2
3
4
5
6

<directory />
    Options FollowSymLinks
    AllowOverride All
    Order deny,allow
    Deny from all
</directory>

If you need to make a change, remember to stop and restart Apache for your changes to take effect.

Looking at the Rewrite Directives

Here’s my example .htaccess file. This file goes in your web root. I’ll go through it step by step in a minute. One important prerequisite for understanding the mod_rewrite file is that you will need to have a good understanding of regular expressions in order to write your own rules.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

RewriteEngine on
 
RewriteRule ^$ app/index.cfm [L]
RewriteRule ^(contact|about|blog|categories)/?$ app/$1.cfm [L]
RewriteRule ^demos/([0-9]*)/?$ app/content/demo$1/index.cfm [L]
RewriteRule ^c/([a-zA-Z0-9\-\_]{1,30})/?$ app/categories.cfm?cat=$1 [L]
RewriteRule ^([a-zA-Z0-9\-\_]{1,30})/?$ app/post.cfm?key=$1 [L]
 
RewriteCond %{HTTP_USER_AGENT} MSIE\s(\d)\.(?!.*Opera)
RewriteCond %1 <=6
RewriteRule ^(/[a-zA-Z0-9\-\_\.])*assets/css/main\.css$ css/main-ie.css [L]
 
RewriteRule ^(/[a-zA-Z0-9\-\_\.])*assets/js/jquery\.js$ js/jquery/jquery-1.3.2.min.js [L]
RewriteRule ^(/[a-zA-Z0-9\-\_\.])*assets/css/main\.css$ css/main.css [L]

Line 1 is important, as it activates the Rewrite engine.

The rewriting starts on line 3. I like to keep my main site files in a folder called “app” in my web root, so the first line rewrites a call to the web root to “/app/index.cfm”

Line 4 redirects a few of the regular top-level pages in the site to their respective locations in my directory structure. /contact to /app/contact.cfm, /about to app/about.cfm, etc.

Line 5 redirects links to demos I included on the site. /demo/1 goes to /app/demo1/index.cfm, /demo/2 goes to /app/demo2/index.cfm, and so on.

Line 6 is for the categories pages for the blog that is part of the site. For example, the link /c/cars would get redirected to /app/categories.cfm?cat=cars.

Line 7 will take any remaining link that does not contain a “sub-directory” and assumes it is a blog post. The links would be forwarded like this: /apache-url-forwarding would be rewritten as /app/post.cfm?key=apache-url-forwarding. This allows you to use the key to lookup a blog post and display it for the reader. These short titles are usually called “slugs” by blogging software and are unique titles given to your posts for use in search engine friendly URLs.

Line 9 and 10 are conditional, and serve the purpose of rewriting the CSS file differently for Internet Explorer 6 and below than it is for the rest of the browsers. You can see that line 11 directs calls to the main CSS file to an IE6 specific file. The preceding rewrite conditions apply to the rewrite rule that immediately follows the condition.

Line 13 rewrites the CSS file for the remaining browsers. You may wonder why I bother rewriting the URL of the CSS file. I like to keep several sets of CSS files on hand – sometimes different themes, sometimes different versions, and sometimes just a specific set of CSS files for development only. Rewriting the CSS URLs allows me to switch between the files with ease without touching my application code at all.

Line 14 rewrites the call to an external JavaScript file – in this case jQuery. This is helpful for managing versions of a jQuery library. In this case, I’m just calling a file called jquery.js, but I’m linking to a minified version of jquery 1.3.2.

The Code

I’ve gone through this pretty quickly, and without a ton of detail, but I’ve included the code all zipped up nicely for you to try it yourself. Stick the whole directory structure in your development web root, and give it a try. Remember to turn on mod_rewrite.

Working Example
Zipped Up Files

I have to admit that at the time, I didn’t think it would be something I needed to explore yet, but it’s getting there. I think that the cloud computing model will fit perfectly for the medium sized websites. Sites that occasionally spike, and get a large, but not CNN/Digg sized, amount of traffic.

There are already entire companies based on providing cloud solutions for Ruby, Python and PHP, among others.  CFML is behind on this, and although there are a bunch of good people working on rectifying that problem, we are going to need more.  I think Adobe could kill a couple of birds with one stone by offering a ColdFusion hosting environment to users, in a cloud-like configuration, for a regular hosting fee.  This would solve the licensing issue for those that want to deploy their CF apps in a cloud environment, and allow some companies that are wary of the costs to get in on the ground level, and see what ColdFusion has to offer.

Many of his criticisms were resolved 8 years ago. Also interesting to note is the fact that there are almost 100 comments to date, and the author has yet to back up his criticism.

Let me step back for a minute here. While ColdFusion is currently my preferred language for RIA development, I am not hanging my hat on the language, and neither are most of the people I know in the CF community. I make a lot of time to learn other languages. I’m currently knee deep in learning Python/Django and try to keep up with PHP as well. Learning new languages benefits you by broadening your abilities with something new, as well as supplementing your skills in your old language.

The more I learn about other languages, the more I believe that there is very little that CF can not do well. I’ve read these posts about ColdFusion’s death before. We’ve been reading them for years. The criticism of the language does not bother me – that is necessary for improvements to happen. What bugs me is that the blog posts about the death of CF are always by someone who does not know the language, and it gets read by people who are equally ignorant about the language, but have the ability to make decisions about choice of platform.

Download it here

Coda is marketed as “one window web development” and it really is. I’ve been going back and forth between Dreamweaver and Eclipse for coding over the past few years, and both are great tools. I still use Eclipse for large sites at work, but I needed something for building small sites, and for quickly editing sites I’ve built in the past.

Coda lets you set up as many sites as you want, and for each site, remembers which files you have open. To make a change, you edit the file, or files and hit publish. It FTPs the files in the background, and keeps everything synchronized. You can even edit files directly on the remote site, which is great if you have specific server config files that you don’t want to be synchronized.

Also, code recognition is available for HTML, CSS, Javascript, Actionscript, Coldfusion, Perl, Ruby, PHP, Python, and several more. Coda is one of those programs that I’m happy to pay for. It’s $79, but will save you time every single day. There is a free trial that I think is fully functional.

Give it a try.