It's taken me much longer than I had anticipated to get this post up, but since my return from San Francisco on Thursday, I've been really really busy. Here are some highlights from sessions on day 3.

• Object Relational Mapping in ColdFusion 9: This was probably the most anticipated session of MAX for me, as I really wanted to see what the CF team was doing with Hibernate support. Jason Delmore, the product manager for CF, showed off what they've got working so far, and it's typically simple and typically awesome. In your application.cfc, you simply enter:
  
  this.ormEnabled = true
  
  and CF and Hibernate does the rest. All the CRUD work? Gone (for the most part) with a single line in your application.cfc. You can generate a Hibernate Mapping File to tinker with later, and Jason says you can use any standard Hibernate XML config tool editor to get at many of the advanced features in Hibernate not exposed directly by CF (and there were hints of visual data modeling tools in CF9, maybe via Bolt). Oh — - and if you prefer to work from the model-driven development perspective, you can add
  
  this.dbCreate = true
  
  and Hibernate will create your database from you from the CFCs that comprise the model in your application. How terribly inconvenient. =)
  
  The <cfproperty> tags of your value object CFCs will define relationships between objects. Jason indicated that you can also pass in the CF FORM structure in to a Hibernate call in CF and it will map FORM values to the appropriate object properties — another nice time saver.
  
  
• Event-Driven Programming in ColdFusion: Sean Corfield gave this talk about aligning the way that Flex (and other event-driven systems) handles events within an application to the asynchronous, request-response model of the Web. He brought up Edmund, his long-gestating project for bringing Flex-style listeners to CF applications. I wasn't aware that the code was available, but it is, and it's worth checking out as it integrates nicely with other Web-based frameworks for CF.
  
  
• Developing Collaborative Apps with CoCoMo: I'm excited that CoCoMo is now available to the public — it's a great way to develop collaborative applications in Flex with a lot of the ugly groundwork being done for you. CoCoMo comes with a host of widgets that you can build on top of, and all of those widgets are the ones you'll find in Acrobat.com and (I assume) the next version of Adobe Acrobat Connect Professional. If you want to add a Flex-based audio and text chat to your site or app, it's really easy to do with CoCoMo. You can even build your own collaborative components using CoCoMo's API and make some really nifty collaborative apps. I know we'll be using this service shortly.
  
  
• Developing Enterprise ColdFusion Applications: Joe Reinhart is an excellent speaker, able to break down complex concepts in to simple, easy-to-grasp examples. While there wasn't a lot new, for me, in this talk, but he made his points about isolating multiple points of integration very well and did offer this fine definition of enterprise software:
  
  An enterprise application is an appliction that can aggregate one or more lower-level systems, such as DBMS, Web Services, or third-party APIs and identically expose its functionality in multiple formats, such as HTML, SOAP, REST and AMF. An enterprise application uses external systems as components while being able to act as a component in other external systems.
  
  To the point, and true. Kind of like Joe's conference sessions!

MAX has gotten big — about 5,600 people big, That makes it harder, in some ways, to network and meet random new people in a sea of anonymity, but Adobe still works on the challenge. To what degree of success, I'm not sure. In any case, highlights from the day:

• The Keynote: Day 2: Ben Forta and Tim Buntel took the stage to show off a range of shipping and future projects which will make it easier, theoretically, to deliver rich experiences via Flex and in the browser. The high point for pretty much every ColdFusion developer in the room was the long-awaiting announcement of Adobe's ColdFusion plug-in for Eclipse, code-named "Bolt." Although we saw a disappointingly brief demo of Bolt, here's a few things that we did see:
  • Start and stop a CF server instance from within the IDE
  • Launch and run the server monitor from within the IDE
  • Introspection on components in a project so that when you create an object, you get a the "intellisense" drop-down list of methods in that object, as you would in Flex Builder
  • Introspection on queries on the current document, giving you a drop down of columns in each query
  • ORM management tools — which, intriguingly, Ben said would support "projects currently in the community." Does that mean Transfer?
  • Right-click on a table in the RDS dataview to generate a service CFC
  • Right-click on a generated component to generate an AJAX client for quick testing of that component
  That was all shown in about 3 minutes, but it was great to see. Bolt isn't even available in preview form, but you can sign up on Adobe Labs to get in on preview releases.
  
  In addition to Bolt, a good deal of time was spent on Flash Catalyst — the designer tool for Flex that used to be code-named "Thermo." Flash Catalyst has really moved towards being a designer's tool and seems to have left the middle ground of the designer/developer that it occupied in its initial premiere. It's a very impressive tool, importing full layers from Photoshop and Fireworks, and offering copy/paste between itself and Illustrator. Any piece of artwork can be turned in to a Flex component (button, list, slider, datagrid), and it offers 3D transitions thanks to Flash Player 10. Interestingly, the preview of Flash Catalyst that they made available to conference attendees was Intel Mac only. I guess they really do know their developer audience.
  
  While there were other projects and tools presented (including a look at what some of Flex Builder 4 will be able to do, including simpler services generation), one other highlight was Project Alchemy: the C/C++ to ActionScript3 translation library. This library allows developers to take any of the millions of C/C++ libraries and use them in ActionScript 3 projects. The demos were very impressive (including running the original Doom and a Super NES emulator inside of a Flash application), and it's great to see Adobe really reaching out to more developers who otherwise would never have considered Flash as a platform for application development or deployment because C/C++ is now "locked" to the desktop or server).
  
  
• The Error of Our Ways: Robert Hoekman, Jr., whose two books about usability and design I've written about before, gave this talk on why users, be they well-educated or not, old or young, thinkers or doers, suddenly become "idiots" when dealing with computer-based technology. Now I have my own theories on learned helplessness and computer-based technology, but Hoekman took a good part of his talk to discuss the psychology behind this evaporation of common sense when using computers. The points he made dovetail nicely in to his books, and while there wasn't a lot new presented here if you've read his books, his main point was this: humans make mistakes, change their minds, and are imprecise. Software doesn't allow for this, which causes impedence between what we expect to happen and what does happen. In the end, people aren't idiots. We make them idiots. We don't help them. We write bad error messages. We allow them to make simple errors in the first place. We aren't flexible and we don't allow them to fix their mistakes. Using the concept of poka-yoke, we can set up systems that prevent users from making mistakes in the first place and offer tools to let them get out of a place that they didn't want or mean to be in our application.
  
  

That's it for now. I did want to give a major shout out to Ted Patrick and his MAX organizing team who did an amazing job with the conference party on Tuesday night. The California Academy of Sciences is a phenomenal building, with an amazing and diverse amount of content under that beautiful, living roof. I'm telling all my friends and family in the area that they really have to go, and I know it's going to be a major stop on future trips to San Francisco. Coupled across the park with the beautifully renovated De Young Museum, the two locations made for probably the best party that Adobe has thrown for MAX attendees in years.

This seems to be the year that MAX, Adobe's annual developer conference, has finally gotten over the assumption that some attendees aren't familiar with Adobe and their products, and so the conference organizers need to offer introductory material and basic product pitches. This year, MAX seems targeted at the mid-level to advanced developer in a way that it has not in the past. I find that a most welcome change.

A lot has been written about the keynote and the conference by others, so I'll simply offer a brief summation of my experiences and the sessions I attended throughout the week.

• The Keynote, Day 1: Refreshingly free of the "Flash on mobile is going to be huge in the U.S. real soon now!" chant we've heard each year for the last couple of years, the keynote provided a good look at where the larger Adobe ecosystem is at, but not really where it's going next. Breaking down the company's initiatives in to three groups — cloud computing, social computing, and workflow across multiple screens — the keynote provided Adobe to show of current work in each of these areas and how many partners (more so than in keynotes past) are working with Adobe to create a broad and thriving system. The final bit of the keynote, with the self-recognizing devices sharing information across screens, was interesting, but didn't seemed a logical extension of where they are at now, and not what's next. I wasn't disappointed. I just wasn't too inspired.
  
  
• Delivering Multibitrate HD Experiences: Will Law did a great job at going through the technical details of the new multibitrate video support in Flash Media Server 3.5 and Flash Player 10. What's interesting about Adobe's approach is that they're letting the client determine when to switch between streams because of bandwidth unavailability (or availability), rather than the server. It's great to see that Adobe has finally brought this critical piece of the streaming video infrastructure to Flash, and they've made it easy to drop in a prebuilt video player, or for you to write your own and still take advantage of a lot of technical encapsulation.
  
  
• Forms Gone Wild: An average presentation about bad practices in form design which unfortunately didn't tell me much that was new. If you keep current on Web application usability, then this session wasn't particularly inspiring. I didn't agree with all the dictums laid out, but I could see why the speaker was making those points. I did, however, pick up one tip for handling bounced registration confirmation email messages that I thought was quite useful.
  
  
• Deploying ColdFusion into Large Scale Corporate Environments: The presenter in this session wasn't particularly strong, and the content seemed very poorly organized. Rather than talking about some key guidelines based off hundreds of hours of technical experience, what was instead presented was a laundry list of options for installing CF in an enterprise, multi-server, multi-box environment. I understand that everyone's setup is going to be different, but a few more concrete guidelines would have been quite helpful. What the session really cemented for me was that Adobe seriously needs to reconsider using JRun as the default J2EE server for CF. It's a product that Adobe has End of Life'd, it has memory leaks and performance problems galore, there is little to no documentation or support for the product, and configuring it properly for a specific situation is a black art known only by a limited few (who make good money doing that, as well they should). The session showed a raft of JRun configuration options without explaining them in any detail, and it just made me wonder why the hell Adobe doesn't simply license Tomcat — a powerful, well documented, well supported J2EE server — and use that instead.
  
  
• Playful Design: This session offered a look in to Adobe's index team, which focused on creating designs and experiences for five years for now. What was really interesting about the presentation was their emphasis on technical iteration — building a framework to play with, then iterating over and over until you reach something that you like. Some of the examples were quite interesting, but, again, for me, not really inspiring.
  

Some of my colleagues attended presentations which they said were great, and picking conference presentations really is like playing roulette. You may get black, red, or the occasional green but it's almost always a surprise.

Because I have the opportunity to take mass transit to work (and it's awfully convenient), I have about an hour or so to read each work day. I spend that time either reading the magazines to which I subscribe, the occasional novel, or technical books. As a result, I read quite a few technical books each year. It sounds thrilling, I know, but it's a great opportunity to expand my knowledge base, especially in areas where I'm not getting to do a lot of day-to-day work. I just finished another in a line of books about Flex.

Programming Flex 3 by Chafic Kazoun and Joey Lott is a rich and comprehensive guide to developing Flex 3 applications with many details about developing Flex applications that are left out of other books and publications. From the start, with its close look at the application startup sequence and how to manipulate that sequence, you know that you are in for a book that's thorough in every aspect of Flex application development.

One of the great strengths of the book is that the authors demonstrate both the MXML and ActionScript versions of the same framework features, where possible. This allows those new to the whole idea of XML-based declarative development the opportunity to see how things work while giving those who want (and will shortly need to) dig deeper the opportunity how the same tasks are achieved in code. The one startling omission from this approach is the <mx:RemoteObject> tag, about which the authors say "Because we have found no practical use for RemoteObject, we are omitting any discussion of RemoteObject in this chapter." I suppose that they made this statement because putting a RemoteObject tag in your MXML conflates the model (and remote data processing) with your view, which isn't good practice, but their statement seems quite severe.

While the authors demonstrate their mastery of the details of Flex and manage to explain even relatively complex concepts (such as the Flex component lifecycle) in a clear manner, the book does feel a bit bit haphazard. Very advanced topics are mixed in with introductory topics. I realize that this is done so that if you write a chapter on CSS and fonts in Flex, you cover every angle of it, but those new to Flex will find themselves getting in very quickly over their heads in each of the book's chapters. Everything is explained quite clearly, but it ends up feeling a bit random.

I'm a big proponent of context while learning. I've been to far too many trainings and read far too many books where you cover feature after feature without tying those features back in to a big picture. Being able to answer how to solve an application development problem with a particular tool is as important as knowing the extensiveness and details of a toolset. While the authors do introduce a "sample application," it's at the end of 605 page book. Although it can be limiting (because you can only write so much and publishers have limits on the number of pages they'll print), sometimes having an application you build along the way to demonstrate the concepts covered can be extremely useful.

But this is an O'Reilly book and as such, the audience may be more inclined to use it as a thorough, comprehensive reference, which it is, than a getting started book.

My team has used Adobe Acrobat Connect Professional for a few years now to provide synchronous meeting and learning opportunities in the online courses and trainings from the Bloomberg School of Public Health. I really like Connect. I think it's superior to competing products from WebEx, Wimba, Elluminate, and others. I'm a big advocate, and have spoken to numerous institutions about Connect, and was featured in an Adobe success story about Connect.

We upgraded to Connect 7 in July. The new version of the product brings to the table some significant usability enhancements, particularly in the educational environment where not everyone in the live session is going to be a "presenter" and managing temporary user abilities permissions is important. During our testing, we encountered a few problems, mostly related to UI display redraw issues, but nothing significant.

Imagine my surprise when a few weeks in to production, recordings of sessions on the Connect server began to fail. Recordings are really quite important to our online courses. Most of our students are working adults. They can't always make these live, synchronous sessions. As a result, watching the recordings is critical to absorbing the full set of content presented in the course. No recordings = a really bad thing.

What followed was a six week process of working with Adobe's support engineers on the problem. They were diligent and careful to examine many possible causes of the problem, as were we. In the end, though, it turned out to be the result of an undocumented change.

You cannot run anti-virus software on the drive where the Adobe Connect server or storage of live sessions resides.

Our server setup for Breeze Meeting (Connect 5) and Connect 6 included full virus-scanning on the entire server, and we never once encountered a problem. Anti-virus software is kind of a necessity on a Windows-based server. You'd be foolish to run without it. However, Connect 7 brought this lovely, undocumented change in to play.

You need to install Connect on a drive other than the boot drive of your server and then exclude that drive, and any drive which houses the recorded content, from anti-virus scanning. If you don't, you'll end up with broken or empty recordings of live sessions.

I've suggested to Adobe that they make this requirement clear in their documentation, but I haven't seen anything yet, so I thought I'd post it here.

On Monday, Adobe introduced Acrobat.com and the new collaborative services based around that site and Acrobat 9. When Adobe acquired Buzzword (an online word processor) back in October, I wrote a post titled "On Adobe's Acquisition of Buzzword and the Future of Word Processing." I argued that word processing, as we knew it, is dead. Adobe's acquisition of Buzzword was very much about building rich media documents as that's what is going to make up "word processing" in the future.

I got it partly right.

One of the really cool things about Acrobat 9, which was launched alongside Acrobat.com and ties in to Acrobat.com, is that you can embed Flash files in to PDF documents with the new Adobe Reader 9. This opens up a whole world of high-fidelity documents with Rich Internet Applications, video, animations, presentations, training materials, or 3D environments directly embedded. You get all the document control of Acrobat with all the interactivity and richness of Flash. It's made me start to think about how we might deliver educational content differently in the near future. Imagine packaging up a lecture presentation with synchronized audio, animation and slides, readings, interactive exercises, and applications which connected to real-time or asynchronous collaboration and communication all in to a single, portable file that opens on a platform that's fairly ubiquitous. You could also generate these packages on the fly using ColdFusion's PDF functionality (assuming it's updated in CF9 for this) or LiveCycle Data Services, and then control distribution and printing through Acrobat's built-in rights management features. It opens up some very interesting possibilities for content distribution.

Unfortunately, much of this functionality isn't available within the PDF services currently available on Acrobat.com (as it doesn't appear to export to the Acrobat 9 format, which isn't entirely surprising, given they just announced it today). My guess is that by the end of the year, Buzzword will enable you to embed .swf files and then export those as part of PDF output.

But that's just Acrobat 9. On Acrobat.com, there are services to collaborate on documents, collaborate in real time on just about anything, and store and share files with others. It's not exactly Google Apps or Sharepoint Services 2008, but I think for the market Adobe wants, it's a damn fine start. With Acrobat.com, Adobe isn't going after enterprise installations, like Google or Microsoft. Adobe is going after their core customer base: smaller shops with 5-20 people who need to collaborate with customers both locally and in remote locations. They want the independent designer who needs to quickly and easily share high-fidelity documents with her clients. They wants the small advertising firm who want to build high quality documents together, in real time, from the comfort and convenience of their own homes. If they get a company of 100 who uses their services, great. They, like Google, are going for the long tail but with a major twist: from the get-go, Acrobat.com is focused on collaboration.

Buzzword is a pretty decent word processor and a primitive page layout tool. You can do more with it than you can with documents in Google Docs (at least it feels that way to me). You can leave inline comments, see a history, use more fonts and colors and layout styles than you can in documents in Google Docs. Buzzword is more focused on collaboration than documents in Google Docs. That's not to say it's not without flaws: sometimes the interface just gets in the way of the app, and some interface decisions seem driven by a sense of "See what we can do!" rather than pure utility.

Neither Google nor Microsoft offer something as well implemented or as easy to use as ConnectNow. My guess is that the next generation of the more powerful (and more expensive) Adobe Acrobat Connect Professional application will probably crib some of the simplified UI and functionality from ConnectNow to improve the user experience in that application. ConnectNow is a very usable, very useful collaboration tool for small groups. GoToMeeting, WebEx, the very primitive collaboration services found in Google Docs, and (God help me) NetMeeting just don't hold a candle.

And it's nice to see that both services export documents in to something other than PDF. Recognizing that the world does, for the present moment, revolve around Microsoft Office-based formats, you can export content in to .doc format, not just .pdf (a restriction that applies to Google Docs).

This isn't an "Office killer" nor a "Google Docs killer," though Buzzword does present more of a direct attack on Google Docs than Office. This is about recognizing that collaboration, online sharing, telecommuting and cloud computing are the future. Google's pretty far along on this path. Microsoft is hopelessly delayed (though Mesh is interesting, if it ever matures). Adobe's shown just how quickly Rich Internet Applications can level the playing field even against a very large competitor like Google.

It'll be interesting to see where Google goes on the collaboration front. It's not easy stuff to do and they've got a big challenger now. Adobe's got a lot of work to do to build out the richness of their online application suite, but they've laid a solid foundation on which they can get to work.

Adobe posted information about and a prerelease version of the Flash Player 10 on Adobe Labs today. While much of the marketing front-end is focused on changes to the visual experience, like 3D and hardware acceleration (which are both very nice), the features detailed in the release notes are much more compelling. Let's take a look:

• Dynamic Streaming: This is a huge change for the way video is streamed to the Flash Player and a major win for content creators who use Flash to deliver video. Currently, the Flash player can't dynamically switch between a higher- or lower-bandwidth stream based on the current state of the user's Internet connection. QuickTime, Real, and Windows Media have all been able to do this for years. It's absurd that it's taken Adobe this long to implement this, but it's very welcome. I realize that a majority of Flash video is delivered via HTTP download (on sites like YouTube and many, many others), but if you stream video, then this is a big change and a big win for the user experience.
  
  
• The Speex Codec: Hooray! Applications which use the Flash Media Server or do anything with microphone input will finally get a long-needed upgrade to the old, poor-sounding NellyMoser codec. This will result in much higher quality voice in voice applications, like Adobe Acrobat Connect Pro. If you use Connect, you'll see a big jump in audio quality when Connect 8 comes out (whenever that may be).
  
  Note that both of the above will require an update to the Flash Media Server. Who knows when that update (maybe version 4) will come out, however.
  
  
• Read Files in to an Application: You will be able to now read in a file (say, a .txt or .mp3 or .xls file) in to your Flash application directly, rather than having to upload the file to the server, then read the file back in to your application. You can even save the edited version of the file back to the local hard drive. All of this without having to use the AIR runtime.
  
  
• Text Layout Components: The new text engine is very cool (especially if you happen to use a right-to-left language like Farsi as your primary language), but the layout components which will be coming to Labs in the future will allow for simpler, yet more flexible control over how Flash applications are laid out. No more pixel-by-pixel layouts (unless you want to do that). Instead, you'll be able to let the layout managers do the hard work of spacing and tiling for you, just like what you get in Flex.

These are some serious changes and will open the door for more mature applications to be developed for the Flash platform. Now if only Adobe would do MP3 and mobile-ready export of Connect content, I'd be super happy...

One of the highlights of the 2007 Adobe MAX (developer's) conference for me was the demonstration of Adobe's next-generation prototyping and developer/designer tool code-named "Thermo." It's a great example of rapid application development: designers (or developers like me with limited design skill) can quickly prototype a Flex application, even going so far as to import an composite image from Photoshop and having the tool recognize the controls in the image and convert them in to real Flex controls. The tool is smart about watching what you're doing and the controls you are laying out and offers to, say, turn a series of repeated controls in to a real repeater in MXML. It's helpful in a good way, not a Microsoft Office Clippy way.

If you haven't seen a demo of the tool, there's a video from C|Net's Web 2.0 coverage. Thermo has a lot of promise, and I hope it can make good on that promise because if it does, it will make developing Flex applications that much easier and faster.

So this is pure conjecture, but it struck me this evening: Could Apple's much-anticipated iPhone SDK in fact be Adobe's AIR (Adobe Integrated Runtime)?

The arguments in favor of this possibility:

• Apple wants an SDK that will protect the core iPhone runtime. Jobs made a very specific point during his announcement of the iPhone SDK that Apple has to make very sure that whatever SDK they release isn't going to allow third-party applications to crash the iPhone. AIR provides a separate runtime for applications that function very much like (at least on a Mac or PC) desktop applications: there's support for file system access, drag and drop from the host operating system, a simple, local database, and more. You can make rich, desktop applications using AIR with a very low likelihood of crashing the host OS.
• Consumers and developers alike have been demanding support for Flash on the iPhone since it launched last year. AIR is built on top of the Flash player (and brings PDF reading support to the table as well), so if AIR is the solution that's chosen, Flash becomes possible/enabled within Safari on the iPhone. That would make a whole lot of people happy.
• The iPhone OS is not the same as Mac OS X. It's not clear that you could compile applications in Objective-C and get them running on the iPhone. AIR lets you write applications in Flex, Flash, or HTML/JavaScript. This is a path that Apple has already begun to push developers down with the initial release of the iPhone, claiming that developers should write Web-based applications.
• Safari is based on WebKit. AIR uses WebKit as its HTML rendering engine.
• Apple has gotten consumers used to taking "Web pages" from Safari in the iPhone and turning them in to icons on the main iPhone screen. They could easily customize Safari on the iPhone to offer the same option when AIR installation badges are discovered on Web pages that users surf to using Safari on the iPhone.
• It's unlikely that Apple would allow third-party developers to tap in to phone functionality even if their SDK isn't based on AIR. That's the domain of AT&T and AT&T, I'm sure, will do everything in their power to control the data and services that relate to phone activity. Of course, if Apple's iPhone SDK is AIR, then third-party developers could write VoIP applications, even those using libraries like Ribbit. I don't think Apple cares about that. AT&T does, but Apple just wants to sell more devices and get people using the Internet with their devices. AT&T ultimately needs Apple and Apple's exclusive agreement with them than Apple needs AT&T.
• Apple will want a secure, controlled way of delivering third-party applications to the iPhone. AIR allows for certificates and digital signing. Adobe plans to have a marketplace for AIR applications, and Apple could use iTunes to do the same thing.
• Just a coincidence: Apple's iPhone SDK is due at the end of February. Adobe have made it quite clear that they're winding down Flex 3 and AIR 1.0 development right now. The timing is interesting.

The arguments against this possibility:

• The more developers who write in Objective-C for the iPhone, the more developers who know Objective-C, and the more developers who could then write for the Mac OS (and any device that runs the Mac OS, including the AppleTV).
• Apple will want a secure, controlled way of delivering third-party applications to the iPhone. Apple will probably use iTunes for this. They wouldn't want anyone else delivering applications to users of the iPhone, as control of the whole experience (from opening the box to making your first call) is critical to their corporate culture. Letting people install applications from any Web page with an AIR install badge would probably not sit too well with them.
• Putting Flash on the iPhone helps bolster the supremacy of Flash Video. Apple has a lot invested in QuickTime, and uses QuickTime to deliver its audio and video content (including anything that plays on an iPod). Apple is banking on broadband connections to deliver HD content anywhere, using MP4 codecs played back within QuickTime. I'm not so sure they're willing to cede that to Adobe by putting Flash on the iPhone.

• The Flash player may be too power consumptive for good performance on the iPhone. I doubt this, because QuickTime decodes video just fine on the iPhone, but it's possible.

I'm sure there are more arguments against this, but it's an interesting possibility.

Comments?

It's been a while since I've posted about software development or ColdFusion, but I have a few blog posts percolating away about the design of Web-based software. In the meantime, it looks like Adobe is finally going to do something about the craptacular state of development tools for my language of choice for Web-based apps: ColdFusion.

ColdFusion (CF) has long been in need of a truly capable, responsive, rock solid editor for the language and the frameworks that go along with that language. Eclipse and CFEclipse are great projects, but they're still rough around the edges in many ways (hello, no drag + drop?!). Many vendors make excellent plug-ins for the Eclipse platform that really assist the development process, but no commercial products exist for real ColdFusion development. The team behind CFEclipse has done a great job on a volunteer basis, but more is really needed. And Adobe should step up the plate. They've done it for Flex/ActionScript, so they can do it for ColdFusion.

Adobe just opened a survey about editors for CF. It's worth the time of anyone who's a CF developer to fill it out and help them make a tool that will help you in the long run.