I’ve been using Blogger as a blogging engine for way too long. It’s time for an engine switch–and a complete site overhaul, for that matter.

My lack of posts are strong evidence of the apathy I’ve been experiencing lately, primarily due to just being so busy with non-technological pursuits as well as a lull in exciting development at work.

My attendance at CFUnited 2006 has helped end my famine of enthusiasm.

The only thing I’ve been remotely excited about lately has been AJAX. At the conference, I attended the AJAX class by Rob Gonda, and it has jazzed me to push forward with more sophisticated AJAX approaches, as well as consideration of different AJAX frameworks, like Dojo.

Furthermore, I’m excited about actually considering the adoption of an application framework (perhaps Model-Glue or ColdSpring), using a source code repository (like Subversion), and finally making the switch from Dreamweaver to CFEclipse.

If that weren’t enough, the typical networking benefits of the conference have taken effect, and I’ve been energized by the enthusiasm of a lot of guys in the industry.

It is actually that last point that leads me to my determination to overhaul my website. I need to stay more active in the industry, and one way I should do that is by more actively working on my blog. And not just for ColdFusion, but for any other web development topics that interest me, as well as my typical interest an Apple, Linux, and Microsoft news.

Keep an eye out. The overhaul is coming.

After a great hiatus, I can finally begin posting again.

For awhile, my webserver no longer had FTP access, meaning an external service like Blogger.com was useless for managing my blog (ahem, if I had gotten around to developing my own blog–or at least modifying a preexisting package like Ray Camden’s BlogCFC–this hiatus would have been unnecessary)!

Well, I will continue to limp along on Blogger.com, and I still do have plans on implementing a homegrown blog of sorts.

I thought it only made sense to incorporate some searching functionality into my site.

Even though I am still using Blogger.com as my blogging engine, I realized that I could still provide a search functionality via ColdFusion. To do this, I have used the Verity search engine included in ColdFusion.

Really, the search functionality is easier now than it will be once I develop a CF blog engine, because it is very easy to create a Verity collection by just scanning a directory of HTML documents.

One problem I experienced when implementing this feature, however, was the fact that I had a “Previous Articles” section in my navigation. The titles of those links would be pulled when performing searches, which was misleading and distracting. As a quick fix, I eliminated the portion of my navigation and reindexed the collection.

When I have a blog engine driven by ColdFusion and a database, this issue will be eliminated, because I’ll set up the Verity collection via a query instead of a path.

I knew of HTTP Compression and for some reason never checked to make sure that my webserver had it turned on. The thought was prompted while reading Chad Dickerson’s series of articles about RSS and the related bandwidth issue it has caused, albeit not a “crushing” issue, as Chad acknowledged in the second article, “RSS Bandwidth Blues“.

What a concept, compress webpage code and content before transferring it, in cooperation with browsers that can transparently decompress the page upon receiving it. In other words, utilize that under-used CPU power to decrease web slowdown where it’s bottleneck really exists: Bandwidth.

If you want to know more about HTTP Compression (not terribly grimy detail, just a nice overview), try this WebReference HTTP Compression article. I take exception at some of the wording about IIS on the second page in the bulleted list, however, because it says, “If it finds a pre-compressed version of a requested document it might send it but has no real-time compression capability. It will, however, use precompressed files if they are available.” This makes it sound like some special process has to be ran to compress your site’s pages before IIS can send compressed versions of the pages. But as described in Microsoft’s HTTP Compression documentation, if no compressed version of a static document is available, IIS will send the document in an uncompressed form on that first, initial request, and compress the file in the background immediately thereafter. Thus, the static document will be available in it’s compressed form on any subsequent requests, automatically. I can live with that. Further, dynamically generated documents are compressed on-the-fly. Granted, the article does explain this a little more clearly in the following paragraphs, but the introductory paragraph is very misleading.

All that being said, I’ve enabled HTTP Compression on my webserver for static documents, which is what Blogger.com uses, since it publishes the blog as HTML files every time a change is made. Cool.