Initial Impressions of Adobe Durango

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.

Sneak Announcements at MAX: Server-side ActionScript and Durango

I was a little surprised this morning to find little or no mention of the announcements made at the Sneak Peek session at MAX last evening on any of the ColdFusion blogs aggregated by Adobe Feeds. Either I'm missing something or everyone had too much fun at the after-session party last night. :)

I don't really have any of the details about the announcements, since I was only half-paying attention to the live blogging from the event and the Twitter stream, but two items stood out for me.

One was the announcement that server-side ActionScript is in the works. For those who don't know, ActionScript is the language of Flex, which is a client-side technology. Someone on Twitter said that the announcement meant that you could run ActionScript on the ColdFusion server, so that you could code certain things in ActionScript rather than CFML, but I don't know if that's really the case or not (I'm sure that will be clarified within the next few days).

The second announcement that caught my attention was about Durango. To quote the Durango web page on Adobe Labs (it's already available for download): "Durango is a framework that allows developers to build Adobe AIR applications that can be customized by end-users." Basically, it sounds like a means of allowing user-created mashups in an AIR application. Giving end-users the ability to make their own mashups seems to be a trend in the industry lately. It remains to be seen whether users will make use of that kind of power and flexibility.

Anyway, I expect folks who are actually at MAX will blog about these items and provide some more details, but I figured I put these items out there so people know what to look out for in upcoming posts from the community.

New Adobe Social Network: groups.adobe.com

One of the later announcements in the MAX Day 2 keynote was the launch of http://groups.adobe.com.

At first I thought it was simply a directory of all of the Adobe usergroups around the world, but it's more than that. In addition to giving each user group a blog and a place to list upcoming events, individuals can sign up and create a profile. Once you've established a profile, you can then associate yourself with one or more user groups, event groups, and other individuals within the community.

As far as I can tell, it's not quite as fully-featured as the ColdFusion Community social networking site, but it's cool that Adobe has decided to put this out there as a means of encouraging networking and collaboration.

I've already set up a bare-bones profile there (username: bcswartz). Not sure what I'm going to do with it or how much I'm going to use it, but I'm there.

Adobe MAX Day 2 Keynote In Progress. News So Far: New CF IDE (Bolt)

The MAX Day 2 keynote address is still in progress. So far, the biggest news so far regarding ColdFusion is the announcement of Bolt, a ColdFusion IDE based on Eclipse to be released at or around the same time as ColdFusion 9. Sounds promising.

You can sign up to participate in pre-release testing of Bolt on Adobe Labs at http://labs.adobe.com/wiki/index.php/Bolt

Not much else about ColdFusion so far: I'm trying to keep apprised by watching Twitter and the live blogging being done by two Adobe evangelists at http://www.webkitchen.be/2008/11/18/max-san-francisco-keynote-day-2-liveblog/

Unfortunately, I am at work, so I can't entirely devote my full attention to what's going on. :)

CoCoMo Now Out on Adobe Labs

This morning I read on Ryan Stewart's blog that CoCoMo is now available as a beta on Adobe Labs.

CoCoMo is a set of Flex components (described by Ryan as a "framework") that lets you add real-time communication and collaboration features to Flex applications, functions such as VOIP, webcam videoconferencing, multi-user whiteboards, and file sharing.

I haven't touched Flex since dabbling with Flex 2, mainly because none of the apps I build involve rich media such as audio and video (an area where Flex has a clear advantage over HTML and JavaScript). CoCoMo gives me new reasons to look at Flex as a production development platform.

The North American session of Adobe's huge MAX conference begins today, so I expect that there will be more news and announcements regarding Flex, ColdFusion, and AIR coming this week. Could be an exciting week!

Applications Are Only as Beautiful as the Processes They Replicate

In an ideal application development process, you work with the client to get an accurate picture of all of the business logic involved in the process the application is supposed to handle, and the end result is a robust system built with clean, understandable code.

But it doesn't always work out that way (some would say it never works out that way). Most of us have had to deal with "scope creep." In fact, one could argue that most modern CFML-coding frameworks and patterns came out of the need to deal with "scope creep" and other reasons for changing our applications.

But sometimes the challenge in creating a clean application comes from the nature of the business "logic" itself, the real-world process that your application is supposed to mimic and replace. It occurred to me the other day that that is often the biggest hurdle I have to overcome with the applications that I'm asked to construct.

When I work with my clients to figure out what exactly what tasks the software needs to perform, I often discover that the processes at work are often riddled with exceptions and conditionals. Sometimes my clients are consciously aware of these exceptions, but other times I have to point them out and we have to figure out how they need to be dealt with.

We humans can handle exceptions within our thought processes very easily. Computer logic, on the other hand, doesn't handle exceptions so casually (which is probably why errors can be referred to as "exceptions"). Coding for even a single exception to an otherwise iron-clad rule can make the code involved twice as complex and perhaps a bit less than pristine.

While we do all we can as responsible programmers to deliver a beautifully-coded application, I think that sometimes there's no avoiding the touch of ugliness that comes from trying to represent and replicate an "ugly" human-driven process.

BlogCFC was created by Raymond Camden. This blog is running version 5.1.004.