Also if you want to use the awesome AngularJS powered slide deck I showed off you can fork it on GitHub.

• 1.0 Reasons to try AngularJS
• Building High Availability Services
• Production Ready JavaScript

It was great getting a chance to talk about JsTD and Angular. They’ve really changed the way I develop web apps and write javascript in general. It was also awesome finally making it to this conference after hearing great things about it for so many years.

Thanks everyone!

• Intro to AngularJS, JavaScript Done Right
• Test Driven Development in JavaScript with JsTD and Jasmine

This is a really fun presentation and I’m super excited about getting a chance to give it again. Some cool ideas that have come from this presentation are even being incorporated into ColdSpring 2 being developed by Mark Mandel.

If you want me to talk about something specific feel free to comment. Otherwise, see you Thursday. :)

I’d encourage anyone who uses ColdFusion to download this test suite and run it against their server every time they update with a hotfix or to a new version. It’ll expose many language bugs and regressions before your application code does.

Note this isn’t following the official CFML2009 standard since that was never released, but instead follows the ColdFusion language as it existed in the year 2009.

You’ll soon find that with this enabled the delete key doesn’t seem to work when you’re typing in certain contexts in the Terminal and not connected to a remote server. An easy way to experience this is to run php and type some text and then hit delete. You’ll see the text ^H appear in the window but nothing will be deleted.

The issue here is that the local erase character is not configured to be ^H, but is instead ^? which means that while Ubuntu now understands the delete key, OS X doesn’t. Doh.

The fix is easy. Add this line to your .bash_profile in your home directory.

stty erase ^H

Now the delete key will work as expected on both OS X and when connected to remove servers.

Despite fixing most of the outstanding bugs, there are still a few notable ones that might catch you off guard, and may cause some head scratching.

Cannot call function pointers in attributes scope

CF9 breaks calling function pointers you may have stored in the attributes scope. This breaks passing a function to a custom tag and calling it directly as attributes.myFunction(1,2,3) and will produce the error that the function “myFunction” doesn’t exist, even though if you dump that variable it certainly does. While an annoying bug, and certainly a regression from CF8, this is an easy bug to work around, just reassign the function to a local variable. Hopefully Adobe improves their test suite to exercise language features better so regressions like this can’t happen.

Operator precedence is wrong for implicit arguments

This bug is really nasty. The order in which implicit arguments are evaluated inside a boolean expression is wrong. The arguments are evaluated before the boolean expression is. A code example illustrates this bug better than a long explanation.

// Function that does nothing
function test() { return true; }

// Note that there's only THREE elements.
numbers = [1,2,3];

// Note that 3 gt 10 is always false, the function is NEVER called
// but CF will still try to access position 10 of numbers.
if( 3 gt 10 and test([numbers[10]]) ) 
{
	writeOutput("this never executes");
}

This code produces an index out of bounds error saying that the variable numbers has no element at position 10. This shows that the implicit array is being created before the function is called. This will catch you off guard if you use a boolean check in a while loop to protect array accesses so that they don’t go out of bounds. It also, more seriously, cause your code to produces side effects and execute code paths that you may not have expected because the first part of the boolean expression is false. Be really careful with this! Hopefully Adobe releases a HF2 since this bug really is bad.

While neither of these bugs should have happened with proper language testing, it’s really great to see that Adobe has been pushing forward with fixing so many language bugs in CF9. I put together a fairly comprehensive test suite to find language bugs in CF9 and these are the last two outstanding regressions now after CF9.0.1 HF1.

I’ll be releasing this test suite soon, and hopefully with that we’ll see the end of language regressions in CF10 (or dare to dream, CF9 HF2).

A good example I’ve found of this problem is the Railo railo.runtime.op.Constants class in the Railo runtime source. This class contains a cache for java.lang.Integer instances and methods for getting them from primitive values. It also contains named constants for the values up to 10 and creates the values manually up to 99 and puts them in an array. Another method is provided that converts boolean primitive values to java.lang.Boolean instances.

The sentiment behind this class makes sense. It reduces the number of Integer instances that need to be created and reduces the amount of garbage being generated by the program.

The problem here is that both of these methods implement a feature that already exists in the Java API. Moreover since the method is part of the API it’ll likely get compiled to native code much faster.

Had the Railo developers trusted the API (and read the documentation) they would have used Integer.valueOf(int) and Boolean.valueOf(boolean). Both of these standard API methods use a cache, and the Integer cache provided in the standard library caches values from -128 to 127 (as required by the Java Language Specification) providing a much more expansive cache than the 0 to 99 values the Railo developers implemented.

So back to what I said in my presentation: Trust the API: It is Faster!

Railo Bug Ticket 934

Note:

It should be noted that Railo supports Java 1.4+ and the cache is only present in 1.5+ so using their own cache in Railo does make some sense, but their use of new Integer() instead of Integer.valueOf() and only caching values of 0-99 means you never get the benefit from Java 1.5+

Second Note:

Apparently this has been fixed in bleeding edge Railo, though the source bundle and the SVN repo haven’t been updated. For anyone else who wondered, they keep that source on Git Hub.

So I’m happy to announce the Unofficial Adobe CFBuilder Bug Database Mirror!

Enjoy.

This performance hit is not some small amount. Creating an empty component that’s imported will cost anywhere from 8-16ms without the cache. That makes CF7 createObject() performance look fast!

Definitely go bug Adobe about this because this kind of performance hit makes import useless. Until it’s fixed leaving component cache off will quickly cripple any new CF9 app and makes development a lot slower too.

Here’s the bug ticket: Bug 83864

Note:

The reason you might disable Component Cache is because the feature is quite buggy and has a tendency to resolve components to the wrong locations between applications that use application specific mappings. Meaning that most shared hosts will probably need to leave this off. That means that object creation performance is going to be terrible on shared hosts if you use import and don’t qualify your components, and qualifying them and still using import rather defeats the purpose.

It was so great to meet everyone new, and see everyone old. Hope to see you at the next conference, whatever that may be!

• Designing Scalable and Creative Algorithms
• I bet you didn’t know you could do that with ColdFusion