Adam Tuttle

Taffy 3.0.0-alpha

The first alpha of Taffy version 3.0.0 is ready for public testing!

There was a recent burst of development, thanks to some corporate sponsorship in the form of this conversation with my employer:

"Taffy can do that, right?"

"No, but it's something I've wanted to add for a while."

"Go do it."

There have been a lot of changes and improvements, and one of those is that the documentation now includes a What's new section, so I'm not going to copy over all of that content into the blog post. There are a few breaking changes from 2.x to 3.0 that you should be aware of, but in terms of how long it will take you to update your code, the impact is only a minute or two of your time.

The test suite is fully updated as well, so please run the tests on your environment and report back if you have any troubles! I've verified things are working well on Adobe ColdFusion 8.0.1 and 10u13, and Railo 4.2 (Cheers to Adam Cameron for helping out with this!), but I can't check every platform. As always, if you run into any problems, we've got the mailing list and you can file bug reports.

Also important: If you try out v3 and don't have any problems, please let me know that, too! Silence either means nobody is testing or nobody is having problems, and there's a world of difference.

As always, thank you to everyone that submits bug reports and feature requests, participates on the mailing list, and talks about Taffy in the #ColdFusion channel on IRC. My biggest thanks this time go out to Dan Short, Jean-Bernard van Zuylen, and phipps73 for their pull requests.

If all goes well with the alpha over the next few weeks, I'll release an official v3.0.0 by the end of the month.

Jakarta Redirect Error when adding new IIS Websites to an existing ColdFusion 10 Install

Does this look familiar to you?

IIS HTTP Error 404 jakarta/isapi_redirect.dll

I spent a few hours on 3 different days trying to figure out what was wrong, here. I was trying to add a new website to an existing CF10 installation on a Windows Server Box with IIS7.5. The other sites were working fine.

What led me astray was that as part of the initial setup of this new site, I also added a web.config file with a port of the old .htaccess URL Rewriting rules from the site's previous hosting. This whole time I was chasing what I thought were edge cases in Rewrite rules, when in fact the answer was so obvious that "if it was a snake, it would have bit me" (to borrow a phrase from my mom)...

I thought it was a problem with the rewrite rules, and the presence of the "isapi_rewrite.dll" in the error reinforced this assumption. If I had only remembered that as of ColdFusion 10, we now have to add a "jakarta" Virtual Directory in IIS that points to the wsconfig path (in my case: C:\ColdFusion10\config\wsconfig\1\). I think this is taken care of for you if/when you run the web-server connector tool, but I hadn't done that.

So there you go. Just add your virtual directory named "jakarta" and you'll be on your way.

ColdFusion Bug with image functions on OSX with Java7

Yesterday afternoon I found myself getting the very same exception message as this bug report from May 2014: java.lang.ClassNotFoundException: javax.media.jai.util.ImagingException

What sort of horrible monstrosity of code was I attempting to slip by ColdFusion?

var img = imageRead( imagePath );

Oh, the humanity.

So, what crimes am I guilty of, thus causing this error? I'm using Java 7 (build 1.7.0_60-b19, to be precise) on OSX Mavericks (10.9.4 build 13E28, to be precise).

Let's see:

I guess my JDK is slightly ahead of the officially supported version, but something tells me that downgrading my JDK would be a waste of my time: I doubt it would work on 1.7.0_15. Here's the download, if anyone wants to try it, though. The reason I believe it would be a waste of my time is that the issue is marked Unverified and otherwise has had no adobe contact, at all.

If you also happen to be a ColdFusion developer that uses a Mac with OSX 10.9 (Mavericks), could you maybe lend a hand and go vote for this bug? I'd appreciate it.

To Scope, or Not To Scope

Adam Cameron has another of his surveys going, about your personal taste in variable scoping. It's something I've written about in the past, but my approach has evolved since then, so I figure it's worth writing about again.

Previously my position was that all references (if-statements, display, etc.) should be scoped, while it was not strictly necessary for variable definition (foo=42) — unless required to actually put the variable where you want it, e.g. in Request scope. I still think this approach has merit, and for the same reasons (you never find yourself asking, "ok, but WHERE is the variable foo coming from?") but its primary drawback is verbosity.

Since then, CFScript has matured (which is not to say that it "is mature"), and I find myself writing more JavaScript than CFML/CFScript, anyway. So, it's only natural that my personal style when writing CFML/CFScript is starting to take on the appearance of my JavaScript, too.

This means that I am tending to use traditional var foo = 42; statements in my CFCs over my previously-preferred style of var local = {}; local.foo = 42;. I preferred the latter because of its explicitness. As of CF9 we no longer needed the var local = {}; but I still find littering my code with dozens of local. prefixes to be a bit verbose, cumbersome, and at times distracting.

Another part of the evolution of my style has been that my code gets smaller and more decoupled (and in many cases, functional), which means the surface area of any given function is smaller and more manageable, so we don't need as much brain power to keep everything in our heads at once. Since I've got some additional brain bandwidth available from that change, I find myself preferring the more terse var-scoped approach, because I love terseness. This sort of creates a feedback loop: By writing smaller, more discrete functions, I'm able to use a more terse syntax, which takes up less space (mentally and physically), which itself makes the functions smaller and more manageable.

In the end, my preference is still that if you can't look at a variable and immediately know where its value was set — even when reviewing the code 2 years later — then you need to be more explicit. It's just that my tooling and my general style have enabled me to reduce the amount of time that extreme specificity is required.

Tools help! I can look at a FW/1 controller and tell you that a variable named rc.foo is input from the user: a form or url variable. Likewise, this means that things not prefixed with rc. are not user-generated and are then more likely to be var-scoped. My controllers don't use anything variables-scoped except injected services, so those service methods are prefixed by the service name: fooService.getFoos();. I could write variables.fooService.getFoos() but what's the point? All in all, those controllers are very easy to follow. (Well done, Sean!)

Likewise, my FW/1 services use injected service dependencies and no other variables-scoped data. If I need a config setting, it's available through my configService. So knowing this, all unscoped variables inside my functions are (better be!) var-scoped locals.

But that's just my personal style. What is yours like? (And hey, take a minute to fill out Adam Cameron's Survey, too!)