Two Weeks at Broadchoice (A Brain Dump Wrapped in a Blog Entry)

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!