I'm happy to say that the Broadchoice Workspace application has gone gold! If you haven't already given it a look, please download it and let us know what you think. If you don't already have Adobe AIR installed, the installer should set that up for you as well.

On a personal level, we built this application in an incredibly short time, and my hat is off to our entire team. Many long days and late nights were poured into this effort, and I hope that shows in the final product. Working with Joe, Ray, Sean, and the numerous others who helped put this together has been incredibly rewarding.

And even though we're all breathing a sigh of relief at making it to this point, we're not anywhere near finished. We plan to keep adding new features and incorporating user suggestions, so in many ways this is just the beginning. (Yes, sorry, that was cliché, but it's true!) Thanks also go out to our beta testers for all their great feedback. I hope everyone finds Workspace to be a useful and promising new collaboration tool.

Sean already mentioned this late last week, but the first beta release of the Broadchoice Workspace is nearly here. If you're interested in seeing what Sean, Ray, Joe, Nicolas, and I have been working so hard on, take a second to sign up for the Workspace Beta. We need good feedback to ensure that this application is as solid as possible! Thanks.

It's probably glaringly obvious, but I haven't had much time for blogging lately. Any regular readers will know that it's due to a total focus on the work I'm doing for Broadchoice and our Collaboration Platform and Analytics Suite. A big part of my ongoing effort with this has been further refining my Flex and AIR skills, as well as ramping up quickly on Groovy.

Since Groovy seems to be a slowly growing topic of interest around the ColdFusion blogosphere, I thought I'd take a moment to recommend "Programming Groovy" by Venkat Subramaniam. This is a very recent book (April, 2008) and is by far the best of the Groovy books that I've looked at.

While you do need a basic understanding of Java and object-oriented programming, the book does not assume a huge amount of experience and it goes through the features of Groovy (as well as how they actually work under the hood) in a very step-by-step, systematic way. Each element is introduced and explored (with lots of code examples) before moving on to the next building block.

The book is essentially broken into three sections: Beginning Groovy, Using Groovy, and MOPping Groovy. The beginning section explores what Groovy is, the differences between it and Java, and begins to look at the core features such as Closures, dynamic typing, and the convenience methods that Groovy adds to normal Java classes. The second section is a more thorough rundown of using these features to solve problems. And the third section is devoted to the Meta-Object Protocol, which is Groovy's approach to fully dynamic programming, runtime method injection, introspection, and DSL (domain-specific language) creation.

In many ways, Groovy is quite similar to ColdFusion. It doesn't provide the huge services layer that CF does (such as PDF creation or image manipulation), but is more low-level. All of the things that CF'ers have been experimenting with like duck typing, onMissingMethod(), dynamic method invocation, etc., are all present in Groovy.

Like ColdFusion, Groovy attempts to make much of the common grunt work that Java requires go away. It adds many helper methods to commonly used Java classes (such as the Collection classes) to make many tasks that are overly complicated in Java work much more simply.

It also places much more trust in the developer, and as a result, highly advises you to adopt a test-driven development approach to ensure code quality. Unit testing is built right into the language, so this is very easy to do. You don't have to catch every exception that could ever be thrown within your code as Java forces you to do. You don't have to type everything, though you can if you want to. Essentially, it offers a pretty sweet spot where you can decide how dynamic you want to go vs. how much you want the compiler to check at compile time.

We're experimenting to a certain degree with integrating Groovy code into CFML-based apps, since its dynamic nature makes it quite a bit easier to deal with than straight Java. Anyone who's tried to integrate CF into a lot of Java code will grow to hate the JavaCast() function. A lot of this goes away when integrating with Groovy since it is dynamically typed.

In any event, the real point here was to direct folks to "Programming Groovy" if they have any interest in checking out this very cool language. I've found Groovy to be quite fun to get to know, and this book was really helpful in understanding its inner workings and capabilities.

Broadchoice has finally started taking the wraps off of the project that we've been working on like crazy. You can see some screenshots and details of the application, as well as an option to sign up to be a beta tester, at The ArgumentCollection corporate blog. This is indeed the application that's pulling together the wide range of technologies I blogged about earlier: Groovy, JBoss, Spring, Hibernate, BlazeDS, and AIR.

I'd encourage anyone who's been following what we've been up to to sign up. The more people we have to kick the tires on the beta software, the better the final product will be! Thanks in advance for your interest and your help. Obviously, we'll be unveiling more specifics about the different parts of the application as we go forward.

I have to apologize for not blogging here lately. As you might imagine, my first few weeks at Broadchoice have been utterly packed with learning and coding. You know that scene in The Matrix, where Neo lays down in a chair and has the cable plugged into his brain socket?

Neo: Ju-Jitsu? I'm going to learn Ju-Jitsu?
(Tank pushes a button. Neo convulses in the chair, then gasps for air.)
Tank: Hey Mikey, I think he likes it. How about some more?
Neo: Hell yes. Hell yes.

That pretty much describes it! I thought I might take a moment to run through some of the things I've been up to.

• Groovy: To be blunt, Groovy is the bomb. I had dabbled with it a bit after this year's CF.Objective() conference, but really diving into it opens up a whole new world of wickedness. It's very easy to learn, especially if you have some experience with Java. The great part about it is that the learning curve is essentially flat. Anything that you aren't sure how to do best in Groovy you can just write in straight-up Java. As you learn more, you can go back and tweak things to use the Groovy idioms.

Closures really change the way you will look at coding forever. Groovlets are a great alternative to the full-blown servlet syntax. And the ability to mix and match strong typing with dynamic typing wherever you want to is incredibly powerful. It makes me wonder if there is a way they could adopt something similar in ColdFusion. You can type things where you want to, if you want full code completion in Eclipse for example, but you can leave typing out when you need more dynamic behavior.

The only problem I've run into so far is, I believe, a bug in the Eclipse plugin under Eclipse 3.4. I had a hard time getting my Groovy classes to automatically compile. I was having to select the Groovy files individually and choose "Compile Groovy Class". I believe the problem arises when you have a certain combination of real Java classes mixed with Groovy classes, and the two depend on each other. For example, a Groovy class that depends on a Java Interface, but the Java Interface references a Groovy class. I think the compiler can't figure out which to deal with first. I ended up writing a short ANT build file that will trigger two compilation sweeps and that forces things to compile in an order that works around the dependency.

Even with that minor headache (the Eclipse plugin is still very much a work in progress), Groovy as a language is very, very slick. And if necessary I can always look at IntelliJ, since that IDE has much more mature Groovy support built into it.

• TestNG: One more great thing about Groovy is that it has JUnit built right into it. You can just write a JUnit test and it will work, with no extra work or imports necessary. However, TestNG brings some extra goodies to the table that made it worth looking at. One big one is the ability to use annotations to declare dependencies between tests, so that one will run only if another one already passed. This can be pretty helpful to avoid having to write big individual test methods just to test that, say, a file uploaded and then could be downloaded successfully. With TestNG, you can say "only run the download test if the upload test runs first and passed". It offers more as well, but that was enough to make it worth trying.
• Spring: I'm a committer on the ColdSpring project and have been using it for a really long time. Of course, it's based on Java's Spring framework, which is like an 800 pound gorilla compared to the subset of features that exists in ColdSpring. And having used ColdSpring extensively makes moving to Spring feel very easy. Just as with CF, I really can't imagine using Java without using Spring to help manage dependencies. On top of that it has killer support for things like database transactions, security, and more. Groovy makes the AOP features in Spring less of a huge win because it is so easy to attach runtime behavior to Groovy objects, but I'm still learning about that and even so, I'm sure there are limitations to what it lets you do or how easily it lets you manage things across large numbers of objects.
• Hibernate: I've only scratched the surface of what Hibernate brings to the table, mainly because what I've been creating didn't involve a lot of actual database interaction yet, but Hibernate looks to be an insanely powerful ORM. I'm very familiar with Transfer and Reactor, and Hibernate takes a different slant on many things. But many of its features are also quite familiar, such as HQL to define bits of custom SQL just like TQL does for Transfer. I think part of the power comes from how all of these pieces layer together like puzzle pieces, with Spring being able to integrate with Hibernate, and Hibernate being able to integrate with Flex/AIR through DPHibernate. Each piece kind of layers on top of and enhances the pieces around it. Which probably makes learning it more difficult since they start to merge into one big blob of knowledge, but also makes them more useful when used together.
• JBoss: One of the things I never really got into was full-blown J2EE web development. And one of the reasons was always what a pain in the ass it was to configure and deploy J2EE web applications. I swear, they either want to make this as complicated as possible, or they want to make it so only people already familiar with J2EE can ever figure it out. This is one spot where ColdFusion just spoils the hell out of us. You just "turn on CF", put files into the web root, and run them. The Java folks really need to simplify this whole side of the process because it remains a major stumbling block. However, we were using JBoss to deploy our Groovy code for web usage, and that meant I had to bite the bullet and figure it out.

  After much pain and cursing, I believe I am finally over the hump. Eclipse does has some nice capabilities that let you configure a J2EE runtime like JBoss and then deploy your web application to a running JBoss server instance from right inside Eclipse, so that helps somewhat. Don't get me wrong, it's still way more difficult than it should be in my opinion. But its nice to see some light at the end of this tunnel and finally have at least a partial grasp on how this actually works.

• BlazeDS: Blaze is one of those things that I kept hearing people talk about but never really understood. It lets us do Flash Remoting? Don't we already have that in CF? Yes. Don't we already have LiveCycle Data Services too? Yes. So what's the point of Blaze? Well, Blaze gives Java developers that same power, with some other benefits and some other restrictions. It isn't limited to one CPU like the "light" version of LCDS that we get with CF8. It offers messaging, which is a very powerful technique to get real time information flowing between your Flex and AIR clients. And it integrates directly with Spring, so you can define remoting endpoints that point at Spring-managed beans. Very slick!
• JMS: JMS is another one of those things that I've heard a lot about and understood in a basic way what it was, but hadn't every really used directly. Thanks to Joe (what DOESN'T this guy know?!), we have our system set up to allow our Groovy model to dispatch generic JMS messages. Because JMS is generic, this is a really powerful thing. It means that anything that can listen for JMS broadcasts (which, when using Java and a J2EE application is basically anything) and respond. For now, Joe set it up to allow these JMS broadcasts to feed into Blaze, which in turn broadcasts them out to any AIR or Flex clients using the Blaze messaging capability. So right off the bat that is great, we can push messages out to Flex/AIR from our Java model without the Java model knowing anything about Flex or AIR. But this goes much deeper since it means that anything that can interact with JMS can also be notified. So other parts of the Java model, or even completely separate applications or servers, can be notified in this way without any dependencies existing between them.
• AIR: I had build some applications in Flex but hadn't really tried out AIR yet beyond a few demos or "hello world" applications. Well, AIR is really nice. And at a basic level, building an AIR app is really just building a Flex app and wrapping the application with a different XML tag. So starting off with it is dead simple. However, it opens up all sorts of very cool capabilities by allowing interaction with the native operating system and the native file system. And of course, the ability to work offline and then sync data once the user goes back online is a feature that we're looking at very closely. Working with files is also very simple, including uploading and downloading files. AIR 1.1 just came out so I'm already looking at what that release brings to the table.
• Swiz: Last but not least, I'm very happy to finally have the chance to kick Swiz around. In case you don't know, Swiz is a Flex framework developed by Chris Scott, who also is a huge part of the ColdSpring effort. Having worked with the beast that is Cairngorm, using Swiz is like a breath of fresh air. Again, knowing full well the benefits of IoC from ColdSpring and Spring, it's very easy to see how Swiz makes Flex development soooo much easier for the same reasons. One of the biggest problems I always had with Flex apps was just getting the pieces to be able to talk to each other in a way that didn't cause a ton of coupling. With Swiz, there is no need for a ModelLocator and no need for tons of dependencies where one component creates a child and passes a bunch of information into it, and the child creates another child, etc. Swiz uses annotations in your ActionScript to autowire the entire system automatically. So everything is very loosely coupled and you can avoid a ton of the boilerplate code that most other Flex frameworks push on you just to let your application function.

So it's been a very busy few weeks for me, but also an amazing few weeks. And there's no slowdown in sight, we're continuing to ramp all of these up in preparation for building some pretty amazing things. We can't talk about the end result yet, but don't worry, we will. ;-) Until then, if anyone has comments or pointers on any of these, please fire away with comments!