Soon about 20 people from all parts of the region had showed up to practice TDD and learn with each other, including one guy who came all the way down from Marquette, MI just to attend. He officially got the “I traveled the furthest” award for the day. We were also joined by Ron Jeffriesand Chet Hendrickson, who had agreed to come and be my professional trouble makers for the day. Shortly after 9:00, once everyone had been sufficiently caffeinated, we decided to get started. One of the attendees had mentioned something about Corey Haines putting together aset of Cucumber features at one of the previous Code Retreats in Chicago, so some of the pairs decided to give that a whirl. After some yak shaving we managed to get through the first iteration of the morning and retrospected on what happened and continued on into the second iteration of the day.

My original plan was to just sort of float around, help facilitate, and observe everyone else pairing, however when I noticed Ron Jeffries didn’t have a pair for the second iteration, I took the opportunity to pair with him. Neither of us knew Cucumber very well, so we decided to give that a whirl. If ever you get the chance to pair with either Ron or Chet, don’t think twice about it, just do it. Ron had at one point in the day managed to – as one participant described “…[kick his] BDD mindset a bit out of place. . . “

Before we knew it, lunch was upon us. It turns out that Corey Haines was hosting another Code Retreat in Seattle that day, so we fired up Skype and greeted our fellow Code Retreaters on the west coast as they were just getting ready to start for the day. Then we all proceeded to enjoy the taco bar that had been delivered for lunch and continued to retrospect on the days events so far. When we were all finished stuffing our faces with Qdoba, Mike Sweiton and myself gave our participants a quick tour of Atomic Object HQ, showing off our open space, stoplight, CI server, and our embedded projects workbench.

Now that our food had a chance to settle, it was back to pairing for a few more iterations of Conway’s Game of Life. After one of the afternoon retrospectives, for a little bit of a distraction, we watched a video of someone implementing Conway’s Game of Life in APL. This was spawned by an email thread that circulated right before the Code Retreat about how to implement theGame of Life in a single line of APL, which still blows my mind.

Finally, by the time the end of the day had finally arrived, we had lost a few of our fellow coders and we were ready to call it a day. Those of us who were still left standing at the end of the day took a walk around the corner to The Green Well, one of the many local establishments in the Eastown area, for some much needed unwinding. We continued to retrospect on the day’s happenings over a few local microbrews and some delicious items from the menu. All in all I would have to say this was a successful Code Retreat. Everyone had a great time, we all got to pair program with some great folks we wouldn’t normally get to pair with, and – most importantly – learning happened. Though many of the Code Retreats in the past have used Java as their language of choice, in my opinion I think using Ruby for this Code Retreat was the right choice. It afforded us much less yak shaving than would have probably been necessary had we been using Java. I’m looking forward to hosting another Code Retreat later this year when the weather is a little warmer, and hopefully attending the upcoming Code Retreat being hosted in Philadelphia by Sebastian Hermida.

So to get to the point, now that I’ve had some time to look at the tool, I’m rather pleasantly surprised.  I’ve seen this tool in action, and generate a bunch of integration tests for a service layer for an application, which will allow you to refactor confidently.  Jump over to the website (http://frogyourcode.com) and check it out.

How we got here is kind of an interesting story. I’ve always been a big fan of RIAs and had looked at Flex a few years back in one of my “I hate HTML” phases and really fell in love. Unfortunately the price tag was really expensive and could never show a ROI on this really cool framework that provided such a rich user experience. Fast forward a couple of years and Adobe has acquired Macromedia, and decided to open source the Flex Framework as well as create an open source fork of their LiveCycle Data Services and now it is possible to do Flex development without spending a dime. So I decided to pick up a Flex book and re-acquaint myself with RIAs, only to struggle to find a good title that would show me how to integrate Flex into my everyday job as a Java developer.

A few months back I had somehow gotten on Manning’s list of people they call on to do manuscript and proposal reviews, and I had reviewed a proposal on Flex and AIR, and it looked interesting. Come to find out the authors pulled out at the last minute, and they were looking for someone to write a title on Flex. So, for whatever reason, I’m still not quite sure exactly why, I opened my mouth and volunteered. After a couple of exciting conversations with the publisher about what I thought would make a good Flex book, I decided to recruit BJ and put together a proposal.

Keep your eyes peeled for the MEAP to show up on Manning’s site in the near future. In the meantime I plan on blogging about the experience, when I’m not up to my ears in writing this book.

In 2002 Macromedia used the term “Rich Internet Applications” (RIA) to describe the next generation of web applications that have all of the benefits of a traditional desktop application, with the flexibility of being deployed via the Internet.

However, it’s 2008 and RIA has not been able to penetrate the business application sector with any real success. The old days of RIA are history. (Maintenance nightmares, weird or no unit testing, and little friendliness toward other agile developer practices.)

With a RIA framework like Adobe Flex it’s now possible to unit test RIA applications and even write tests first. It’s possible to connect up to a CI server just like server-side code and pick up coverage stats. It’s possible to evolve a simple design incrementally and emergently.

The speakers will model how to make standard agile development practices work in the RIA world: Refactoring, Test First Design, Simple Design, Continuous Design, and Continuous Integration & Automated Builds.

The bottom line is many businesses have invested much time and money into their existing applications and their staff. For this reason, this session will guide the attendees on how to refactor an existing web application with familiar server-side technologies. We’ll show how to integrate Flex into existing applications in order to build a next generation application that will delight users.

Rather than trying to teach the basics of Flex, the speakers will demonstrate how to develop robust applications leveraging the Flex framework in concert with enterprise technologies like Java. These applications can be deployed not only to the web but also to the desktop using the Adobe Integrated Runtime (AIR).

 

Process/Mechanics

 

Refactoring to RIA’s will be a demonstrative (tutorial-like) session geared towards Java developers that would like to refactor existing applications in an agile way. Test First, CI, and other friendly agile practices will be key in making this possible.

The session will consist of live code and practice demonstrations leveraging an already existing application. Requirements for creating a new rich client interface will be explored and code will be refactored in a Red/Green/Refactor manner.

So I’ve decided to start a Google Code project called agile-flex, where a couple of other developers and I will attempt to build some agile tools for the Flex framework, starting with a test runner that will help enable continuous integration for Java, .NET, or even just plain old Actionscript. The runner will likely be based off an article I found from Aaron Spjut here. In a nutshell we will create a test runner in Adobe AIR that will generate XML output similar to JUnit and NUnit for the CI server to be able to interpret. This will also enable the generation of report artifacts using the JUnit Report tasks or even a custom XSLT if desired. I’ll post more details as the project continues.

UPDATE… The Flex-Mojos project now fulfills this need, so I’ve deleted the Google Code Project that we started for this.