Thought Delimited

If you've been following my updates on Twitter, you know that I was at the CFUnited conference last week. I didn't post anything during the conference because, quite frankly, I didn't set aside any time to do so, and there was lot going on most of the time.

I'm not going to try and sum up everything that was presented at the conference: I'm not sure any one person can. But there were a number of news items and developments that came about either just before the conference or during the conference that I thought were worth pointing out:

• ColdFusion 9 in the Cloud: In the opening CFUnited keynote, Ben Forta and the Adobe team announced that ColdFusion 9 would include licensing options for running ColdFusion in cloud environments, and that they would specifically support the use of ColdFusion 9 on Amazon's EC2 cloud environment. Details (sparse though they are) can be found on Ben's blog post on the subject. Though I'm not a fan boy of cloud computing, having this option is important for ColdFusion developers who have an idea for a high-traffic web application but don't have the money to invest in their own server farm.
  
  
• 4CFF: 4CFF is the acronym for the For ColdFusion Foundation, a new non-profit foundations founded by several member of the CF community with the goal of providing assistance and resources to ColdFusion open-source projects and establishing a "professional membership society for the ColdFusion Community at large." I missed their unofficial announcement/presentation, so I can't provide any information about how they plan to move forward with their goals, but I think the idea of having a resource where CF programmers can get help with the non-programming challenges involved in starting and maintaining an open-source project is a good one.
  
  
• Framework updates/changes: The final, production version of Model-Glue 3.0 (Gesture) was released just prior to the conference, while the beta release of ColdBox 3.0 was announced on the first day of the conference. But perhaps the most dramatic framework announcement was that Adam Haskell, previously the lead developer for the Fusebox framework, was going to resign from that role and lead the development of a new and separate version of Fusebox called FuseNG (Fusebox Next Generation), citing irreconcilable difference between himself and TeraTech, the Maryland-based CF development/training shop that currently controls the domain name and source code behind Fusebox. As a developer who uses Fusebox, I'm curious to see how this decision will play out. The current version of Fusebox is a very effective, usable, and mature framework, but Adam's a smart guy and it'll be interesting to see what he and the other developers involved in FuseNG will come up with.
  
  
• The Merlin Manager beta: The final event on Friday at the conference was the Demo Derby, where developers got several minutes to show off a project of theirs. While all of the presentations were noteworthy (and in two instances quite humorous), the one I thought really needed to be brought to the attention of the CF community as a whole was John Mason's Merlin Manager. One of the announcements regarding ColdFusion 9 was that it would provide an AIR-powered desktop application that would let ColdFusion server administrators manage and compare multiple ColdFusion server instances from one dashboard. John's Merlin Manager is also an AIR-powered CF server manager, but it's built to work with ColdFusion 7 and 8 servers. He demonstrated how his app provided real-time status information for a server, how it let you store current server settings as a snapshot prior to making a settings change, and that it could compare the settings between two different servers, highlighting where the settings differed. Even though the project is still in beta, it looked very feature-complete and could be of real benefit to those CF shops that won't be upgrading to CF 9 anytime soon. John is looking for volunteers to participate in evaluating the beta: if you're interested, visit http://www.merlinmanager.com/ to sign up.

As for the conference as a whole, I have to echo everyone who's already commented about it on their blogs and via Twitter: it was an excellent, informative, and fun conference, the best I've ever attended. And that statement is coming from someone who, for various personal and professional reasons, wasn't all that worked up about attending. Everyone involved in the planning and execution of the conferences, especially the folks from Stellr and those presenters who stepped up to fill in for last-minute speaker cancellations (all the presenters deserve credit, but those folks especially) should be proud of the work they did.

For those folks who weren't able to attend, be aware that a number of the presenters will be posting their presentations online, either on their own blogs, SlideSix, or both, so keep an eye out for announcements about those (and note that some of those posting and announcements were made last week during the conference itself).

Sometimes when you're working on an idea, the things you learn inspire another idea. It's not something you planned on doing, but it seems like a cool idea and it wouldn't take much time to do, so you jump into it without much thought.

That's pretty much how my CFQuickDocs Lookup Extension for ColdFusion Builder came about. For anyone who doesn't already know about CFQuickDocs (hopefully very few of you), it's a website created by Jake Munson that lets you quickly look up the documentation for any ColdFusion tag or function.ﾠ I knew from previous experience that it was possible to pull up the CFQuickDocs page about a particular tag or function by adding the tag/function name as an anchor parameter to the CFQuickDocs URL, so when I realized that I could design a ColdFusion Builder extension that pulls in content from an external web page, creating a simple extension to do a CFQuickDocs lookup seemed like a no-brainer.

But in my enthusiasm to follow through with the idea, it didn't occur to me to look more closely at ColdFusion Builder to see what kind of documentation might actually be incorporated into the IDE itself:ﾠ that thought didn't occur to me until after I'd finished the extension and submitted it to RIAForge. Turns out that all of the tags and functions for ColdFusion 9 can be found in the general Help menu under ColdFusion:ﾠ it's not front and center, but it's not hard to find either.ﾠ And the style and functionality of the documentation is fairly similar to how CFQuickDocs looks and works. That fact, plus the fact that you can have the Help window open and still interact with the IDE (something you cannot do with the dialog windows used in Builder extensions, which is one of the biggest limitations of extensions IMHO), diminishes the usefulness of my extension (comparatively).

Still, my extension can serve as a simple example of how to pull an external web page into an extension dialog box. And folks who are still using ColdFusion 7 and 8 in production (such as myself) may prefer to rely on the CFQuickDocs documentation rather than the CF9-centric docs in the IDE.

ﾠ

In my last blog post, I suggested that Adobe include a list of CFML community resources in the upcoming Bolt IDE in order to promote the community to isolated developers who might otherwise be unaware of all the resources out there.

After thinking about it a bit more, it occurred to me that maybe Bolt could take it one step further. Instead of simply using Bolt to point developers to the community, have Bolt bring the community to the developer. Build in an RSS viewer that displays the latest ColdFusion posts from Adobe Feeds. Put in a communicator tool so the developer can converse with other CFML programmers via IM or Twitter. Let the developer screen-share their code with other developers both inside and outside of their organization. Integrate geolocation into Bolt and show the developer a list of other Bolt users (and maybe Adobe user groups) that are nearby. Instead of using e-mail and message boards to communicate with CFML developers, Adobe could broadcast any news announcements to all of the Bolt installs, and Bolt users could submit questions to Adobe and other users via discussion forums displayed in a window of the IDE that gets refreshed automatically.

I'll admit, it's a pretty pie-in-the-sky idea. Given that Adobe only has a finite amount of time and resources, I would certainly not want Adobe to leave out any traditional IDE features, the things that allow developers to code quickly and efficiently, in order to take the time to add all of the things I just suggested.

But if they did have a little extra time, I think adding even one or two simple collaboration/informational features would certainly enhance the product, and perhaps set a trend for other IDEs to follow.

On Monday, Sean Corfield's thoughts on how Adobe MAX 2008 went were published on the Fusion Authority website. One of the events Sean cited in his article was a Birds of a Feather session moderated by Adrian Moreno about bridging the gap between expert/guru CFML developers (the ones most visible in the online CFML community) and "9 to 5" CFML developers.

I don't know the details of what was discussed in that session, but it relates to an issue that crosses my mind every once in a while: how do you reach out to developers when you don't know who or where they are? And, conversely, how do we help these "invisible" developers find (and participate in) the community?

I was a full-time ColdFusion developer for almost two years before I really became aware of the ColdFusion community. My predecessor, to my knowledge, never participated in the CFML community or went to any conferences or user groups, so it never crossed my mind that such resources existed. I don't remember how or when I realized that there was a community of folks with which I could converse about ColdFusion development (though it was probably at CFUnited '05), but the point is is that it wasn't an automatic process.

I think this is an area where Adobe needs to step up and promote the community as part of the overall "ColdFusion package". Every sale of ColdFusion should include a list of CFML community resources and a statement that encourage organizations to share that list with any ColdFusion developers they are aware of. If Adobe is skittish about including links to resources that might disappear over time, at the very least they can include Adobe-sponsored resources like Adobe Feeds or the new Adobe Groups site.

Even that kind of effort might not reach all the CFML developers out there: in some organizations (like mine) where the ColdFusion server is running in a shared environment, the organization that owns the CF license may not know who all is using the CF instance. So here's another idea: put links to community resources into the new Adobe Bolt. If Bolt is meant to be the premier IDE for CFML developers, then there's a good chance that even the "invisible" CFML developers will grab it and gain access to all the resources it provides.

In an earlier entry, I mentioned the announcement at MAX of Durango, a framework for allowing end-users to build AIR applications out of shared components. I took some time last night to check it out, and here's what I learned...

First off, the components that make Durango work are Flex-based, so if you like to create AIR applications using HTML/CSS/JavaScript, it doesn't look like you can make use of Durango.

Durango allows a developer to make the Flex components they build (whether visual or non-visual/service-based in nature) reusable in other AIR applications. The 10-page long PDF file on the Durango page on Adobe Labs explains how to add Durango functionality to components. It also explains how to configure your AIR application such that it can either donate Durango-enabled components, receive Durango-enabled components, or do both.

The installation package available on Adobe Labs lets you experience Durango in action. Once the install is complete, you are then able to create a blank AIR application (one set to receive Durango-enabled components) simply by choosing the "New AIR Application" option now enabled in your OS (on Windows, you can simply right-click on the desktop to get to that option). Then you can open one of 4 sample AIR apps included in the install (all of which are set to donate their Durango-enabled components) and put it in "reuse" mode. Once the sample app is in reuse mode, the Durango-enabled components can be clicked and dragged onto the window of the blank AIR app you created, and now that component also exists in your AIR app, and you can save the changes to the AIR app. Certain properties of the component can be coded in such a way that the user can change them in the new AIR app, allowing for some customization of the borrowed component.

All in all, it seems like a fairly straightforward idea for making components reusable. The big question is whether or not end-users will utilize this feature. Folks who use a lot of separate AIR applications may see some value in taking bits and pieces from multiple apps and combining them. And it remains to be seen how AIR developers will feel about allowing the components they worked so hard to build to be taken and repurposed by other developers.