Do you remember January of 2004? Macromedia had just released ColdFusion 6.1 a few months earlier. CFCs finally worked! Fancy JavaScript techniques were not pulled together under the moniker of AJAX. Rich Internet applications were just a casual mention in a Macromedia whitepaper. There was only one ColdFusion framework in common use and Flex was an unnamed beta behind the Macromedia cloak of secrecy. Macromedia Central was the way to deploy Flex apps to the desktop.

In January 04, I also wrote the first issue of this column. It's been a long ride, and I'm glad I took it. My face and name have appeared in almost every issue since February of that year. I've submitted 37 articles to CFDJ, including this one. One got lost in the system and never made it to print. The rest is history. Unfortunately the time has come for me to move on.

A Look Back
In the years preceding this column, I had written three ColdFusion books for Osborne McGraw-Hill. I pounded CFCs during the MX beta period to figure out all their secrets, only to later discover that while the concepts were right, a lot of the content was just wrong. My two main contacts at the publisher left during the writing of the third book. That compiled with less than stellar sales left me without a contract for my next book. I co-wrote an article for CFDJ with Charlie Arehart in September of 2003 about setting up your dev server for different versions of ColdFusion and BlueDragon. It went over well and, shortly thereafter, Simon Horwith asked me if I was interested in writing a beginner column, and the next thing I knew I was in the routine.

During the first year of the column I focused on very beginner newbie topics, like complex variables and ColdFusion expressions. I quickly tapped out such topics and moved into more complex, but very important things. For a while CFDJ tried to tie into deep focused issues, so I tried to tie into that focus, bringing articles such as XML and reading files from Java.

Still, I wanted more. As the deep focused issues started to drift, I decided to try something different. In June of 06, I started a two-part series intended to dissect my thought process of building an application. I wrote an RSS Aggregator, explaining each step along the way. Many of you e-mailed me to ask why I hadn't posted the code yet. Sorry, you were right. I should have. The RSS Aggregator code became a staple in the column, and something I'd use for most of my examples from then on. You can download the code from my blog at www.jeffryhouser.com.

Reader Feedback
Lately I turned to topics such as design patterns and object-oriented development. My previous column, on Object-Oriented Pizza, is personally one of my favorites. It didn't generate nearly as much flame as I was expecting. The two design pattern articles generated some feedback, which I wanted to share here.

First up was the article on Data Access Objects. In that article I stated that I rarely use DAOs. Most of my applications are custom built for clients, and it's rare that a company will change database platforms. The additional time to add a DAO layer doesn't seem worth the advantage. "Michael Long" commented on this article on a SYS-CON site. He mentioned that you should use a framework such as Transfer or Reactor to create the DAOs for you instead of creating them manually. That is a fair suggestion, but such was beyond the scope of the article. The article was intended to discuss the concept behind DAOs, not frameworks for generating them.

Michael goes on to say that without DAOs, your insert and update statements will be spread out across multiple places. This assertion made me chuckle a bit. When developing, there are always many ways to accomplish different tasks. To suggest that DAOs are the only way to encapsulate insert and update functionality is just wrong. What I didn't say in the original article, but perhaps should have, is that I often roll the DAO functionality directly into the bean object. This provides many of the benefits of DAOs. The functionality is encapsulated and sitting in a single spot within the application. It just isn't given its own layer.

In my next article, I tackled Data Gateways. As part of that article, I created a generic gateway object from which all other objects could inherit. Someone wrote in to me via my blog (he didn't give a name) to ask why I didn't specify a table instance variable in the generic gateway. The reason for not adding a table variable in the generic gateway was because the table is going to be custom to every other gateway. Why create a placeholder variable that is going to be overwritten every single time? The answer, I believe, is for documentation purposes. Adding the table variable to the generic gateway makes the generic gateway easier to understand, and it is a bit more self-documenting. I should have put it in there.

A Look Forward
As with Macromedia Central, JavaScript, Flex, and ColdFusion, all things must eventually change. I'm sorry to be leaving the column, but as I look forward I think it is the best move for me. The industry has changed, and so have I. DotComIt (my company) is now an Adobe Solutions Partner. We are starting to focus more heavily on the RIA space using Flex (and ColdFusion and AIR). I've started up a podcast to focus on Adobe Flex, and my co-host is RIA extraordinaire turned Adobe Evangelist Ryan Stewart. It is time for me to turn my literary expenditures to Adobe Flex. Although at this time I'm not sure what form that will take.

I want to thank everyone for reading, and especially those who took the time to respond. Please feel free to look me up. Info about my company is at www.dot-com-it.com. (Call if you need help.) If you want to hear me blab about Flex, check out the podcast at www.theflexshow.com. If you want to keep tabs on what I'm doing next, read my blog at www.jeffryhouser.com. If you're really dangerous you can probably find my twitter account.