I hand't heard a whisper of Adobe Shadow before it was released a couple of weeks ago. In a nutshell, Shadow is a tool which lets you perform simultaneous, synchronized browsing on both your desktop and mobile devices. Everything has to be on the same network node, and your mobile devices have to be running a small iOS/Android companion app, but the tool just works, beautifully.

When running Shadow, you pull up a page in your desktop/laptop web browser. At the same time, the same page reloads in the instance of Webkit inside of Shadow. (I'm assuming that they used Adobe AIR to create Shadow, because AIR has an embedded Webkit browser.) This is a huge timesaver when developing mobile sites. Instead of making design/CSS tweaks and checking first on the iPhone, then a co-workers Android phone, then the iPad, then the desktop, you can simply reload the page in your Web browser and all of the mobile devices reload at the same time. It's awesome, and a big, big time-saver.

If you're doing any kind of mobile Web site development, Shadow will rapidly become an indispensable tool in your arsenal, as it has for me.

I blogged earlier this month that ColdFusion Builder 2 ships with a number of extensions for the major ColdFusion frameworks. MachBuilder is the extension for the Mach-II framework, and was built by Kurt Wiersma and I.

The extension ships with ColdFusion Builder 2 and can be found in the "extensions" folder inside in the ColdFusion Builder 2 install directory. You can also get it as part of the core Mach-II 1.9 download.

MachBuilder currently has two major features:

1. Configure and create a new Mach-II application skeleton

This option is available to you when you right-click on a project folder or a folder within a project. Selecting this option brings up a simple form that provides you some configuration options for a new Mach-II app skeleton. This includes:

• Specify the application name
• Specify the event parameter name
• Enabling the ColdSpring property
• Enabling SES URL writing in the Mach-II app
• Enabling the on-screen Mach-II logger
• Providing the password for the Mach-II Dashboard
• Specify a custom webroot path if you don't want to use the default

When you tell the extension to create the application skeleton, it parses through the application sekeleton files and inserts the values that you enetered as required. If you wanted the ColdSpring property to be set up, it does that for you. The same goes for SES URL rewriting (using the default /key/value/ pattern), and the logger. The Dashboard is included by default, as it's part of the core Mach-II 1.9 framework. If you don't want to include the Dashboard, you can delete the related lines from the mach-ii.xml configuration file.

All of the files end up in the folder which you right-clicked on to fire off the extension. You'll want to make sure that you're running the extension in the correct folder. If you want the Mach-II application skeleton files to be put into your webroot, then right-click on your webroot folder. If you want the application to live inside a folder in your webroot, right-click on that specific folder.

2. Display Mach-II Dashboard

This option is only available when you click on files in a project. It does one thing: launch the incredibly useful Mach-II Dashboard for the currently selected server in a view inside of ColdFusion Builder. That view stays open, like all ColdFusion Builder 2 extensions that create views, until you either close it or quit out of ColdFusion Builder 2.

The Mach-II Dashboard is what I would consider to be a required tool in developing Mach-II applications. If you're not using it and you develop using Mach-II, you're missing out on significantly improved development.

We had hoped to provide code assist on Mach-II configuration XML files with this extension, but ColdFusion Builder extensions currently do not work on non-cfc/cfm files. The ColdFusion Builder team is aware of this issue, but if you want to make sure that this becomes possible in the next version of ColdFusion Builder, then please vote for this enhancement request!

Side note: You can get code hinting and assistance on your Mach-II configuration XML files if you use the Mach-II DTD and the free Eclipse Web Tools Project (WTP) XML editor (not Aptana, which is the default XML editor in ColdFusion Builder).

One other feature of this extension is that it will automatically notify you when there's an update to the extension. (Kurt spent a lot of time for this 1.0 release implementing the auto-update mechanism.) We plan on adding more features to it in the future (see this Google Doc for more), and you're encouraged to add feature requests to the Mach-II Trac site. Mach-II is community-driven, after all.

If you want to see how this extension works, including the callback to refresh the Eclipse project view when creating a new Mach-II project, look at the "Mach II Builder Extension" directory that gets created in your webroot when you install the extension into CFBuilder.

In all the coverage of ColdFusion Builder 2, one thing that hasn't been mentioned is that the IDE now ships with a bunch of framework-specific extensions. There are extensions for:

• Mach-II
• ColdBox
• Model-Glue
• CFWheels

Each of the extensions provides functionality for building apps with that framework. Each extension has different functionality, but if you're using one of those extensions, you should find that it makes you more productive (or at least we certainly hope it does!).

These extensions can be found in the CFBuilder Install Directory/extensions.

I helped write the MachBuilder extension for Mach-II. The super-smart Kurt Wiersma did most of the work, but my contribution to the project was doing the Mach-II application skeleton work.

I'll detail the MachBuilder extension in a future blog post, but the key thing to remember is that these extensions do exist for the major CF frameworks. Use them — or contribute to making them better!

"Wallaby" is the code name for Adobe's Flash to HTML5/CSS conversion tool that they recently posted on Adobe Labs. A lot of people heard about this tool (even when it was previewed back at Adobe MAX in 2010) and assumed it's a full Flash to HTML5 converter tool. It's not. It only converts animations built in Flash. It doesn't convert ActionScript to JavaScript...yet. That's probably being built into a different tool. Wallaby also doesn't support sound export in its current iteration, but my guess is that it wouldn't be too hard to add.

Wallaby converts a Flash animation and generates HTML5-based HTML, CSS3-based CSS, including heavy use of CSS transitions, and some JavaScript for animation support. It's actually pretty impressive, and I hope Adobe begins to use it across a number of tools in their arsenal.

Where I'd really like to see Wallaby applied is in the Adobe Presenter and Captivate products. Both products produce Flash-based animations that are designed for presenting information in a sequential fashion. Presenter created PowerPoint-based lecture presentations, and that's where I think Wallaby has its most immediate applicability (except for the real target of this product, which I'll talk about in a minute). Presenter presentations require Flash, which excludes them from working on iOS devices. And there are a lot of those devices out there. There isn't much ActionScript used in Presenter presentations, so it seems a natural fit for broadening the number of platforms on which content can be delivered from an Adobe product. Presenter is frequently used in higher education (it's a core tool at my place of work), and in higher ed, saying "Oh just have people use Android devices" isn't enough when it comes to solving mobile content compatibility issues for students.

Captivate would be a bit more difficult to implement the Flash to HTML5 conversion engine. Captivate uses a lot more ActionScript, plus has numerous options for custom variables and other fairly complex tracking mechanisms that wouldn't necessarily translate well into a HTML5/CSS/JavaScript combination. RJ Jacquez, who is an Adobe Evangelist, published a video showing a rudimentary conversion of a Captivate movie to HTML5 using Wallaby, so that's quite promising.

(Another product that could benefit from Wallaby is After Effects. It already exports to Flash and as it's purely animation-based, it could go the HTML5/CSS3 route pretty easily.)

The reality of Wallaby is that it's most likely being developed to create HTML5/CSS3 animations that can be used by advertisers in lieu of pure Flash animations. Saying that it's a HTML5 tool gives Adobe the leverage to capitalize on the latest in technology buzzwords for advertising and marketing groups, thereby making those groups feel that they're up to date in the solutions that they can provide to their clients. More importantly, a rich HTML5/CSS3 editing tool would allow those groups to create animation-based advertisements that would get around popular Flash-blocking tools like FlashBlock and ClickToFlash, as well as similar animated GIF-blocking tools. Add in a little tracking and monetization JavaScript, and you have a rich-media advertising tool that works on most mobile devices — something that can't be said of most similar tools today.

I'm a pretty big fan of Adobe Connect. We use it in my job and it's a critical part of our learning infrastructure. Adobe even featured us in a case study about using Connect in higher education.

We've been using Connect since it was Breeze Meeting 5 (remember that naming debacle?), and the upgrade process from one version to another is really quite simple and seamless, particularly if you're not building multiple clusters with multiple origin-edge configurations. There's one big, giant gotcha about setting up Connect that has not changed since the days of Breeze Meeting 5: getting people outside your network to actually access Connect meetings via a Web browser.

The default approach of the licensed version of Connect is that Connect will be deployed behind your firewall to your company and its employees alone, and that no one from outside your network will need to access your Connect setup. That works well for quite a few of the customers who have a licensed version of Connect. If you're an educational institution that needs to have students from around the world use your Connect setup, that's a bit of a problem.

The solution, which isn't well documented, is this: you need to add a line to the custom.ini file in your Connect installation that tells the Flash Media Server inside of Connect (the server which powers the actual Connect meetings, not the administrative UI) how to resolve itself to your external domain name. The line needs to be all in lowercase, and should look like this:

host.machine name=connectServer.domain.name

So if the machine name of your Connect instance is bigBadConnect1, and your domain is connect.mysupercoolsite.com, the line you need to add to the custom.ini file is:

host.bigBadConnect1=connect.mysupercoolsite.com

This tells the Flash Media Server running inside of Connect to resolve to the external domain name of the server. Without it, people from outside your network will be able to access the Connect administrator, but not actually connect to any meeting sessions or watch any recordings. They'll get stuck "Connecting..." to your Connect meetings and never get any farther in the process, even if all the appropriate ports are open on your (and their) firewall. With this addition to the custom.ini file, all works well.

Note that this doesn't affect the hosted version of Connect at all. It's only an issue for licensed (internally hosted) customers.

It's really nice to see Adobe showing their commitment to the development of HTML5 and Flash tools that make life easier to those of us who develop Web applications. Adobe yesterday released the HTML5 Video Player widget which writes in a video player which, by default, uses the HTML5 <video> tags, but falls back to a Flash video player if the browser doesn't support the <video> tag. There are already a number of video players out there that do this, but what's great is that we're seeing a major player like Adobe doing this. It's based on an open-source project, Kaltura, so it's nice to see open-source getting some high-profile love from Adobe as well.

The player is accessible through the Dreamweaver Widget Browser, which is a nifty AIR application that lets you preview all sorts of HTML/JavaScript based widgets, supply parameters to them, and generate code that you can use. I imagine that we'll be seeing Adobe use the Widget Browser to deliver a lot of HTML5-focused tools in the short term. (And you don't need to use Dreamweaver to use the Widget Browser, thank you very much.)

I really hope that this is just the first in a long line of HTML5 tools from Adobe, and that we'll see them come out with a brand-new HTML5-focused tooling set in the future. They did some pretty impressive work with Flash Catalyst as a front-end to Flex tooling, so I believe they can do the same for HTML5.

Now it's time to really start converting all those .flv movie files to .mp4 movies files...

A little more than a year ago, I wrote a post called "Adobe Throws Down the Collaboration Gauntlet," in which I talked about what I assumed to be Adobe's different approach to online Office-style application suites. Just recently, Adobe added both Presentations and, now, Tables to their online offerings. This gives them an online word processor, and online presentation editor/player, and an online spreadsheet tool.

The differentiator, in some ways, is the heavy emphasis on collaboration. While Google Docs offers collaboration to varying degrees in their online suite (more so in their spreadsheet app than in others), and we've yet to see how far Microsoft will go with their upcoming, online version of Office, Adobe has made it pretty clear that collaboration, rich media, and a really good user experience are the cornerstones of their online office suite. In some ways, I look at Tables and think "You know, if Apple made an online version of Numbers, this is kind of what it would look and feel like." just because it looks and feels so good.

There are a couple of niceties that aren't found in Google Docs, though. The "Private View" is really nice because if you want to sort or filter data while others are working with you, you can do so without changing their view. Tables is a pretty serious demonstration of Adobe's LiveCycle Data Services (which is supposed to get a pretty nifty update today), as I'm assuming that it's LCDS that's used on the back end to handle all the data synchronization between collaborators in Tables (and probably in Presentations and Buzzword too). On the other hand, Google Docs has some pretty nice data import features (ie; being able to say =http://some.data.service.site/ in a table cell, as seen here), which Tables doesn't.

Now I'm not much of an Excel guy, so I can't say just how much coverage Tables has on formulas compared to Excel, and there's no pivot tables (I'd imagine that's going to be added sooner rather than later), but as with most things software, only 20% of the possible features in an application are used by 80% of the people. I've posited that Adobe's audience is the small office, or the small workgroup, where a handful of people need a simple way to communicate and collaborate in real time on various types of Office-style documents. Tables goes after that audience with Adobe's usual style.

As I work in a shop heavily dominated by technologies from Adobe, I tend to keep pretty current with the company's latest Web development activities. Adobe has been really busy this past week, churning out beta after beta of new technologies and products. In addition to the launch of the Flash Builder 4 and Flash Catalyst betas, and the launch of Adobe Presentations beta, Adobe yesterday announced the availability of the beta of BrowserLab (code-named "Meer Meer").

BrowserLab lets you see what your Web pages look like in a variety of browsers on both the Mac and Windows platforms. Everything is done inside of your Web browser and everything is rendered as part of a Flex application. You can see what a single browser rendering looks like, or compare two side-by-side. There's even an onion skin view which, while hard on the eyes, lets you see the pixel-precise differences between, say, how Firefox 3 and IE6 render pages.

BrowserLab currently only supports Firefox 2 and 3 on Windows, IE 6 and 7 on Windows, Firefox 3 on the Mac and Safari 3 on the Mac. One would expect that additional browsers (eg; IE 8) will be supported soon. I'd personally like to see support for Safari on Windows and Safari 2 on the Mac, but given the small market share of those browsers, my guess is that Adobe will forgo them. There's no mention of mobile browsers (Opera Mobile, Mobile IE and Safari for the iPhone), which is surprising given the rise of mobile browsing — especially on the iPhone.

BrowserLab currently supports previewing of public Web pages only. That is, if the page requires a login, BrowserLab can't access it. Additionally, if you develop on your desktop, you need to be using Dreamweaver CS4 (and a couple add-ins provided by Adobe) to see your locally developed content in BrowserLab. That's kind of a bummer for those of us who don't use Dreamweaver CS4 (or Dreamweaver at all), and something of a major oversight compared to a tool like Litmus (which also supports many more Web browsers, as well as email clients). Most designers and developers build and test pages locally before going off to a staging or testing server, so the inability to do the comparison work while you are developing locally is a pretty big drawback to the service, in my opinion. Of course, I could always go purchase Dreamweaver CS4 and then I'd have nothing to complain about.

I understand why Adobe is doing this, though: make Dreamweaver a requirement and you can sell more software. Adobe has an interest in getting people to use more of their software and their services, so tying the two together is no surprise. It's Microsoft's stated approach, and, ultimately, Google's as well (remember that not everything Google does is free — try using Maps for anything other than a non-personal, non-profit site and you'll have to pay).

BrowserLab is currently free, but the expectation is that once it comes out of beta, a fee will be required for the service.

Adobe today released a beta version of Presentations, their latest addition to the suite of collaborative tools hosted on Acrobat.com. While I'm not sure when Adobe will really start to promote Acrobat.com as a real collaboration solution for the mobile worker (it's there, available now, and there have been some half-hearted links to it from within Adobe's site), seeing Presentations added to the suite of tools available in Acrobat.com is an important addition.

If Adobe is really building a Flex-based alternative to Microsoft Office, focusing more on collaboration than Office itself, then Presentations is a natural and needed fit. The next logical application would be some sort of Excel clone, as users of "office"-style suites would require a spreadsheet application. Google already offers this via Google Docs.

As they did with Buzzword, their online word processor, you'll find what distinguishes Presentations on Acrobat.com from presentations in Google Docs is the rich suite of formatting and styling controls. The level of styling and design control is clearly enabled via the rich media capabilities of Flex, and something that's currently way out of the reach of Google Docs and its reliance on JavaScript and CSS.

I'm not sure that Presentations (in its current, beta form) stacks up as well against SlideRocket, which has been around a lot longer and has equal if not superior design controls. SlideRocket also offers PPT import and export, Google Docs integration, an offline player, and greater sharing and content re-use between a group of users. Again, SlideRocket has been around a lot longer, so it's able to offer these features while Adobe's product is a first beta. (In all honesty, I expected Adobe to simply buy SlideRocket as they did Buzzword, which would have given them a more capable and mature product from the get-go.)

Still, as Adobe begins to provide a suite of office-style products for online collaboration, people who are already using Buzzword for creating Word documents will find Presentations a natural and easy fit. The product has a long way to go to catch up to SlideRocket, but I can easily see how students where I work will take to building group PowerPoint presentations collaboratively using Presentations just as they do for their group Word documents in Buzzword. Of course to turn in those presentations to faculty, Presentations will need to export to PPT and not just PDF. =D

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!