My first thought is actually about some news that wasn't part of the keynote, but was announced on the Internet during the keynote: Adobe's acquisition of PhoneGap. PhoneGap is an application framework that allows developers to build mobile apps using web technologies (HTML, CSS, and Javascript) and the PhoneGap API (to access particular device functions like geolocation, the camera, internal storage, etc) and then package and deploy those apps such that they work on most mobile operating systems (Android, IOS, Blackberry, and a few others).

What struck me about that news was that it means Adobe now provides two ways for app developers to develop cross-platform apps. If a developer is already familiar with Flash and Flex development, they can build mobile apps using Flash Builder and Adobe AIR. If the developer is more skilled with web design and programming, they can build apps using PhoneGap. In both cases, the end result is an app that runs natively on your device of choice (IOS, Android, whatever).

First of all, it's yet another example of Adobe's willingness to support both Flash and HTML5 as development platforms going forward. A number of tech analysts contend that Adobe's development of new tools that play nice with HTML5 is a capitulation of some kind to the way the industry is moving. I don't see it that way: Adobe may be synonymous with Flash, but it's never been all about Flash with them. They have always supplied the tools that the digital and web creation markets have demanded, just as any sane company would, regardless of what their internal preferences might be.

The other thing about the PhoneGap acquisition is that it will expand the number of developers using Adobe tools and technologies to create mobile apps for both Android and IOS. And now suddenly Adobe potentially a big player in the smartphone and tablet space, not by release their own mobile OS or mobile hardware, but by providing the tools to any developer who wants to write on any and all of these platforms. To be clear, at the moment there are certain kinds of apps or app functions that a developer would want or need to develop in native OS code, but as the Adobe tools provide ways to overcome those limitations (such as the ability to include native code extensions in Flash/AIR apps), the number of reasons for writing an app in native OS code (and hence writing a second version for deployment on another platform) are going to become fewer and fewer.

My second observation regarding the keynote concerns the suite of touch-optimized mobile apps - the Adobe Touch Apps - coming in November to Android devices and later to IOS devices. While some of the apps are geared more towards visual designers, the Proto wireframing app is something I could use in the design phase of my web and mobile application work, and, well, who wouldn't want a touch-optimized version of Photoshop to use to mess around with their photos?

And that's when the thought occurred to me: here were some apps that I could use to be productive with a tablet. I'm an application developer who writes code. I have access to two tablets and I don't use either of them to write code or generate digital content of any kind. For me, tablets have always been digital consumption devices (something Amazon seems to recognize with their new Kindle Fire tablet) for viewing video, looking at pictures, or reading web pages or books, and kinda superfluous given I can do all that and much more with a laptop (to be clear, I do love my Nook Color as an e-reader, but I rarely use it to surf the web or anything else).

But the apps Adobe showed off today made me feel like I would in fact want to use them on a tablet, because they were designed specifically with tablets and touch-interaction in mind, not as desktop apps shrunk into a mobile form factor. That to me is a step in the right direction, and it's apps like those that are going to grow the tablet market by making the tablet experience more compelling.

So just when I thought that all of the rhetoric regarding the Apple verses Adobe dustup over Flash had died down, Steve Jobs published an open letter entitled "Thoughts on Flash" on the Apple website today, ringing in yet another round in this boxing match.

I encourage those folks who care about this issue to read the letter in its entirety (rather than someone's summary of it).

Some quick thoughts I have on what was said (just my opinions/observations):

When Jobs dings Adobe on the issue of Flash being proprietary, he acknowledges that Apple has proprietary products as well, but that "we strongly believe all standards pertaining to the web should be open." Why, exactly? What makes it okay to engage in proprietary protections off of the web but not on it?

Jobs makes the point of mentioning WebKit to illustrate that Apple contributes to the open standards for the web. He fails to mention that Adobe also makes contributions to web standards as well (the partnership with Mozilla on Javascript engine code comes to me) and that Adobe does have products in their toolset to allow developers to create websites using the latest advances in HTML, CSS, and Javascript. Adobe certainly has an interest in promoting Flash, but they continue to support other competing technologies.

It's interesting that Jobs implies that Adobe was tardying in providing support for the H.264 hardward decoder, yet it has been pointed out by a number of sources that Flash has long suffered from performance issues on Macintosh computers because Flash was not allowed to make use of the graphics accelerator on Macintosh chips.

Jobs states that any Flash sites that rely on "rollover" events to activate certain functionality would have to be re-coded in order to work on the iDevices. That may be true in some cases, but let's not forget that certain HTML and Javascript events also rely on the idea of hovering over a page element with a mouse, or dragging and dropping an item. The need to adjust to a multi-touch paradigm is not something that just affects Flash-based sites; it affects websites built with those open web standards as well. And just because something doesn't work quite right on a new device doesn't mean you should throw it out and start over from scratch.

I see the issue of allowing Flash to run as a browser plugin on the iDevices and the issue of letting Adobe provide a tool for developers to translate Flash code into a binary file that runs on the iPhone OS as two separate things, yet the way the letter is written it seems to combine the two issues. Perhaps it was done as a means of using the earlier arguments to sway some options regarding the Flash-to-iPhone compiler issue.

A lot of these complaints Jobs has regarding Flash (valid or not) can be or are being rectified. Instead of encouraging Adobe to address the things he has issues with, he "suggests" Adobe should drop Flash and stop criticizing Apple. That certainly implies to me that even an open, secure, battery-friendly, and efficient version of Flash would still never be allowed on the iDevices.

I have to wonder what he thinks this letter will accomplish. The fact that he wrote it at all seems to imply either some desperation or annoyance over the fact that that Apple's anti-Flash stance hasn't been as widely accepted amongst the industry and amongst consumers as he'd like. Perhaps he's looking to gain a few more converts to his stance at the cost of making his opposition that much angrier with him?

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.