Adam Tuttle

Framework Is No Longer a 4-Letter Word

Raise your hand if you have ever used Fusebox, Model Glue, or Mach-II. (Do jazz-hands if you've used ColdSpring.)

Keep it up if you've ever seen your application time out on the first request while trying to load the framework configuration.

If you raised it for the first prompt, chances are you still have it up after the second prompt. I'm right there with you. You can put your hands down now.

I started coding web-spaghetti in CF 4.5, and learned about frameworks at around the same time CF8 was starting private beta (I don't think I was in that one). Model-Glue became my weapon of choice mostly because Joe was a captivating speaker and his sessions at CFUnited were awesome. I ended up maintaining some Fusebox apps later on in my career. And more recently I worked in a shop that was 100% Mach-II for the better part of the last decade.

They all suffer from the same problem: They were slow because object-creation was still slow in CF back then, and unless you were very careful and deliberate (and sometimes not even then), you were very prone to burying things too deep. XML that defines Listeners that proxy requests to Controllers that call Services that use DAOs. It was painful to make a tiny change because I had to make that change in 5 files... And I'm guilty of it too. Much of my code from this era is equally—if not more—cringe-worthy.

I don't think the developers behind these frameworks are guilty of anything. The tools they gave us were leaps ahead of what we had earlier (see also: <cfswitch>).

BUT... Depending on how bitter you allowed this experience to make you, the reputation that "frameworks" earned in your mind may have been deserved. Most people's experiences with frameworks (and I include myself here) was poor... and the jerk that originally wrote the app you're stuck maintaining is to blame.

Always code like the person that will inherit the app when you leave is a deranged serial killer that knows where you live.

Whether you blame the developer that came before you, or the system that allowed it to happen, many of us have painful memories of frameworks past.

I'm here to tell you that Framework is no longer a 4-letter word.

Modern frameworks use much (much!) less configuration, if any, and orders of magnitude fewer objects. FW/1 (a badass MVC framework) is one object. DI/1 (a badass Dependency Injection framework) is also just one file. And if I may be so bold as to place my own work on the same stage as Sean's, Taffy is only a small handful of files, has super-terse syntax that almost forces you to write as little code as possible, and runs fast as hell.

How well you know your tool matters much more than what tool you know.

At the end of the day, you can still write terrible messes of code with new tools. Just because you have a bad experience doesn't mean the tool is to blame. But framework developers are learning the common pitfalls their users (a.k.a. you and I) run into, and putting up police tape and stanchions to keep us on the path to success. If the word framework gives you sweaty palms and makes you start looking for the exit, I would urge you to come back and try more modern iterations.

You might be surprised.

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:

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.