As I Twittered on Monday, the new release of the Broadchoice Community Platform (our hosted content management system) was in QA and had hit zero bugs. QA completed successfully so today we pushed the new release to production. It's mostly a bug fix and minor enhancements release but it contains one new feature I wanted to talk about from a technical point of view.

The Community Platform has a number of "modules" (applications) that you can add to a page and one of those is a list of documents for download (or external links). You add the module to the page and then select documents (from your document library) to add to that module. In previous releases, authors had to add documents in the order that they wanted them to appear on the (generated) web page. We looked at a number of UI options for allowing authors to "rank" the documents within the module but felt most of them were fairly clunky, involving entering ranking numbers to reorder things or up/down arrows requiring authors to move documents one position at a time. Ugh!

Ray pointed me at one of the cool jQuery UI interactions: sortable. It allows you to mark a "container" tag (e.g., a div) as sortable and then users can drag'n'drop the "child" elements into the order they want. You can attach event handlers that fire at various points in the drag'n'drop operation.

Here's how we do it:

That's all you need in the HTML. Then you add the following JavaScript: This causes two things to happen:

1. jQuery marks the sortable div contents as being, well, sortable!
2. jQuery adds an event handler for update - when the drag'n'drop operation completes - that invokes a URL on the server, passing in the serialized data from the children of the sortable div, i.e., the id values as a list in the new order: doctag[]=1,3,4,2. It assumes an underscore as a separator.

The server side code simply updates the module data to put the documents in the specified order.

Oh, sorry, that was the title of the BACFUG presentation by Bill Shelton and Marc Esher (of MXUnit fame)!

Unit testing has defined my working day. I've been working on the licensing subsystem of the next build of the Broadchoice Workspace today and because we practice Test-Driven Development (thanx Brian!), that means writing unit tests "first" or at least alongside the production code.

I started by writing the License bean and an accompanying LicenseTest. The bean has a handful of properties and two methods. The unit test has nine test methods.

Fairly confident that the bean was correct, I moved on to the data layer. Apart from encryption, this mostly follows our well-tested generic Hibernate DAO. That meant only a couple of unit tests.

Once those tests passed, I moved on to the service layer. Six unit tests for four service methods.

At this point I'm ready to write the remote service facade (which implements user-level security) but I'm fairly confident our licensing subsystem will work as expected. 623 lines of code, just over half of which is unit tests (327 lines to 296 production code). I'll probably add some more data layer unit tests since I have a couple of "untested" methods (they're used in the service layer tests).

Unit tests may seem dull and tedious but they really can make your life easier.

Adobe's Cocomo technology entered public beta at MAX and the day one keynote featured an extremely brief demo of a little of what Cocomo can do. Nigel Pegg (of the Cocomo team) did a couple of sessions during the conference which I had planned to attend but, as is usual with MAX, my schedule got derailed early and often so I didn't make either of them. I'll be writing up my MAX experience on my own blog shortly (and may contribute an extended version as an article for Fusion Authority as I have done with conferences in the past).

Now MAX is over, Nigel has blogged more about Cocomo and talks about what beta testers get access to in terms of source code, documentation and features. Nigel includes a nod to me for contributing the Groovy version of the provisioning script and and a mention of the Broadchoice Workspace which uses Cocomo behind the scenes - and which we demo'd at both the Adobe Partner booth (Wednesday lunchtime) and on the Ribbit booth.

If you didn't get a chance to look at Ribbit, check out this video of Joe and Rick (our CTO) talking about Ribbit integration into Broadchoice Workspace (as a proof of concept for now - would the ability to make phone calls from within the Workspace be valuable to you?).

Now that the Broadchoice Workspace has been officially released, I thought I'd post a quick entry with some code statistics. I ran the codebase through a line counting tool that gives a breakdown by file, folder, language, etc. We all know that lines of code is not a very good way to judge quality or effort, but it is still interesting in a general way. This is only lines of code, all blank lines and comments were excluded:

• Total Lines of Code: 50,125
• Total Files: 633
• Lines of MXML: 10,784
• Lines of ActionScript: 12,675
• Lines of CFML: 7,730
• Lines of Groovy: 8,878
• Lines of XML: 1,757
• Lines of CSS, HTML, JavaScript, etc.: 7,612
• Lines of SQL: 1,089
• Lines excluded as comments or blank: 15,778

Here at Broadchoice we've been working on our new product for close to three months now. I've gotten a crash course in Groovy, Spring, and Hibernate, all of which are slightly familiar to me from my time with ColdSpring, Transfer, and Java. I'm really digging these new technologies, but of course, I'm a die hard ColdFusion user at heart. A few weeks backs I needed to work on a quick iPhone web application prototype. Joe set up the connection and all I had to do was write CFML (lucky me). Little did I know that along with setting up basic CFML compatibility on the server, Joe also added one of the slickest things I've seen ever in my life as a developer.

The application I'm working on is pretty simple, but I wanted to use Model-Glue 3 for it since - well - you never know when a simple prototype will turn into a large, complex application. The following code snippet comes from a controller used to load bookmarks:

Nothing in the above code should be too odd or even that exciting really. I'm using a service (injected via the beans scope in Model-Glue 3) to retrieve my content. My controller begins with...

Note the beans value specifies which beans configured in ColdSpring should be passed to my controller. I love this new automation in Model-Glue 3. If you open up my ColdSpring.xml file, you will see my beans configured:

Hmmm. Ok, there's my config bean, wheres my contentService bean? Oh yeah - here it is:

You can find the above in our Spring file. Just in case the above didn't quite make get through, let me make it real nice and obvious:

The above line of CFML is using a bean injected from Spring, not ColdSpring, and points to a Groovy file. This is the same Groovy code used to drive the AIR application. No createObject("java") here baby. I'm using the Groovy code just like it had come from a CFC. This is done using a ColdSpring/Spring adapter that Joe wrote. It lets ModelGlue get Java-based beans from Spring. (I'm simplifying it here a bit, but hopefully you get the significance of that!) Once that connection is done, you can easily get beans from the Spring file and inject them into your controller. So for example, when my UserController wanted do handle login, I added: beans="userService,config" and then simply ran a userService.validateAndLoad on the authentication information.

It's always been easy to use Java from CFML, but never has been so sexy! Now to be fair, I did have to use a JavaCast once or twice, but not nearly as much as I would have thought.

A few days back Sean gave us all a sneak peak of the Broadchoice Workspace. He also mentioned we're all very busy lately, and guess what ... the Broadchoice Workspace is not the only application we're working on. Today I'm going to introduce the Broadchoice Workspace Analytics platform.

[More]

If you happen to work with Adobe AIR at some point, and you want to download a file from a server, you may run into this helpful error:

I/O error 2038

Not very helpful. After a lot of digging and trying out solutions, I think I've figured it out. I was doing something like this in a Delegate object:

The problem seems to be the scope of the File object that is used to perform the download. Because it is locally scoped to that method, when the download completes and the completion event is announced, the file object is essentially gone. I'm not sure if AIR is garbage collecting it, or if the variable is just not accessible because it is function-scoped. Either way, I got this error over and over and was pulling my hair out.

The solution is to not var scope the new File object. Unfortunately that seems to open up potential concurrency issues. Because the Delegate object is essentially a Singlton, if I add the file as a public property of the Delegate, and more than one upload goes at the same time on the client, it will get overwritten. That's not good.

I got around it by creating an Object to wrap around my file called SharedFile. This object has a public property which is a File object. In that case, I can do something like this:

So I'm setting the sharedFile.file property to a new File, then using that file object to perform the upload. The I/O error vanishes because the file object is not locally-scoped, and so a reference to it still exists when the completion event fires. Again, I'm not sure of the exact underlying cause of the problem, whether a function-scoped file object is simply not visible when the completion event fires, or whether the AIR runtime is garbage collecting the variable before the completion event fires. Either way, this seems to fix it!

We have a live system with customer data and a new requirement comes along that a particular piece of customer data must be encrypted in the database from now on. We already encrypt some columns (using Triple DES - which you might have guessed given the recent posts on my blog and here about mimicking ColdFusion's encryption in Java/Groovy). What is the smallest possible code change to ensure that as any user updates their data in future, this item will automatically be encrypted - whilst still handling the case of legacy data being unencrypted?

We use Transfer for all our persistent business objects and almost all of our business objects have a decorator defined (for validation or some additional business logic). We also use Brian's TDOBeanInjectorObserver to automatically inject services into our business objects - just add a setter for a service and the bean injector takes care of the rest.

Here's the bean injector definition in our ColdSpring file:

Normally you would declare it non-lazy but we already do other non-lazy initialization so in our ColdSpring factory initialization code, we do this: to force the bean injector to be initialized which, in turn, registers itself as a Transfer event listener (so that it can intercept object creation). The suffixList specifies that any set*Service() method or set*Datasource() method on the business objects managed by Transfer should be matched to beans defined in ColdSpring and injected.

So how do we add the on-demand encryption to our business object's data?

[More]

As a fun way to while away a Saturday evening, I decided to look at Joe's Behavioral Analytics backend code to see if I could create a Flex-based AIR application that talked to services written in Groovy. There's not really much documentation out there to help so it was a very hit and miss experience but eventually I had a simple AIR application making a RemoteObject call to a Groovy class and getting data back. I'm going to have to talk to Joe about cleaning up the installation I've ended up with but here are the highlights (and I'll blog more about this once I have all the pieces cleaned up):

• JBoss 4.2.3 GA installed as a Server in Eclipse (using the Web Tool Platform JEE stuff)
• Spring framework 2.5.5
• A Spring-based Flex factory that allows Flex Remoting to talk to objects via Spring (author Jeff Vroom)
• Groovy - set up per Joe's recent instructions
• BlazeDS providing the Flex Remoting service

Create a Dynamic Web Project in Eclipse and then unzip BlazeDS into it (per the BlazeDS installation docs). Add Spring and the flex.samples.factories.SpringFactory Java class. Configure Flex Remoting according to Lin's instructions to add the Spring factory: and the context loader: and the destination for the RemoteObject:

Create a Flex AIR project and define a RemoteObject that refers to the destination you just defined:

Add the placeholder bean definition to your applicationContext.xml file:

com.broadchoice.bcp.Placeholder is a Groovy class that contains a test method (for testing it just takes a string and returns that string plus some additional text).

The Broadchoice Collaboration Platform (BCP) is deployed on a cluster of servers and this has a number of interesting implications for the design of the application as well as the actual deployment process and file system structure used.

I'll be posting several entries on clustering considerations but I wanted to start with something that surfaced with the recent launch of this blog. BlogCFC is part of our standard SVN repository (I'll also be blogging about our source code control processes) and so it is also deployed to the same cluster as the BCP. Each server runs the same code from its own local file system. BlogCFC allows authors to upload images and files that are used as part of the blog entries. If you simply deploy BlogCFC onto each server in the cluster and then create a blog entry and upload an image, that image will be stored directly on the file system of the server on which your request is processed (in fact, the server on which your entire session is processed, since we use "sticky session"). The other servers in the cluster won't know about the image. For user requests that come in to that first server, the image will be served correctly. For user requests that come in to the other servers, the image will be missing.

The BCP has the same issue - it allows authors to upload CSS, images and documents - but we have to ensure that all these uploaded assets are available to all servers automatically and immediately. Our approach was to design the application in such a way that shared assets are stored in specific directory trees that contain nothing but shared assets. We have a NAS - Network Attached Storage - which is mounted to every server as /var/www/html. That contains a documents directory and a custom assets directory - into which all uploaded content is placed. Symbolic links are used to "map" those shared directories to the appropriate place in the deployment directory tree:

/var/www/production/lib -> /var/www/html/lib
/var/www/production/wwwportal/custom -> /var/www/html/custom

We deploy our source tree to /var/www/production (direct from SVN) with lib and custom ignored by SVN. Each server then shares the same uploaded content without needing to use different file paths to how we would deploy to a non-clustered server.

Tonight, I applied the same fix to BlogCFC, adding blog_images and blog_enclosures directories on the NAS and adding symbolic links back into the BlogCFC deployment tree (as wwwblog/images and wwwblog/enclosures respectively). We have not yet dealt with making blog.init.cfm cluster-safe or the XML file generated by the pod manager. For both of those, we actually keep the files under SVN and handle changes as part of a managed process (i.e., by tickets in Trac).

This is just one of many things that need to be considered when designing applications for clustered environments. I'll be blogging about other clustering issues over the next few weeks.