eRubycon 2008 - Severely Belated Wrap Up

I had the good fortune of attending eRubycon a few weekends ago and I can honestly say that I've never seen more value in a conference. My previous rant on how NFJS is letting the level of their speakers slip was only more evident in the 3 days spent at eRubycon. Neal Ford, Stu Halloway, Joe O'Brien, Jim Weirich, Charles Nutter and many others contributed valuable sessions that left me wishing the conference went on for a few more days.

The great thing about eRubycon was that it very rarely focused on what is typically the gateway drug in adopting Ruby, the Ruby on Rails framework. Rails is a multitude of patterns and practices that are worthwhile regardless of your current language, but it sometimes overshadows the true core of "beautiful code", Ruby.

The conference left me wanting to learn more about Ruby and to generally spend more of my time at work adopting Ruby. The challenge I (and many others have) is to do this while still meeting client requirements. Brian Sam-Bodden gave a great visual representation of how a Java project can incrementally adopt Ruby as a build language, scripting language, and testing framework. I missed half his presentation as I was so focused on pulling in buildr and some other utilities into my current project.

I think the two biggest topics covered though were essence vs ceremony and testing your application versus testing your framework. Stu Halloway gave a great keynote on essence vs ceremony and while his Java examples were typically very dated, his points remained true. Java (and C# by extension) force you to type crap that is just clutter or ceremony. The less ceremony in our applications, the easier they are to test, maintain, and actually produce on time. I don't recall who initially mentioned the difference between testing your framework and testing your application, but it was a point that haunted me all weekend. It's a very gray line typically between the two and one that can drastically impact a project schedule. Unfortunately, there is no easy answer to this one, so be sure to be cognizant of it when writing your unit, functional, and integration tests.

In summary, eRubycon far exceeded my expectations for a conference under $300. Speakers, content, hallway discussions, and after hours scotch induced discussions were all way above what I had hoped. Keep it up Joe, I'll see you there next year.

Ruby Integration with Spring

I recently gave a presentation at COJUG on ten facilities in Spring that you may not know much about. I saved my favorite for the last. Dynamic Language integration. This facility has been around since Spring's 2.0 release, but has been mired in the relative obscurity of Chapter 24 of their docs.

While many IT managers might be hesitant to adopt a language like Groovy or Ruby for their production environment due to misconceptions about performance, security, or what have you. The management types should have very little concern with testing code making extensive use of dynamic languages. If Ruby or Groovy provides a lower barrier of entry for complex testing or mocking, why not make use of it?

Spring provides the typical DI goodness of abstracting away the underlying implementation and allowing the developer to switch from mock to production code without changing client code. In the case of Ruby backed implementations, JRuby provides the hooks to allow the .rb file to be recognized as an implementation of the Java interface.

Here's a simple interface implemented in Java with which I've created a Java and a JRuby implementation.



A JRuby based implementation of this only has a few tricks like including the library and calling a method to include the class



Finally, with the spring integration facilities, a few lines of xml locates the file and plumbs in the implementation. Client code accesses the Java interface, none the wiser to the Ruby implementation.



There are a couple of gotchas to keep in mind with JRuby/Groovy Spring integration:
- JRuby 1.1 is not supported until Spring Framework 3.0, use JRuby 1.0
- Model code after what I have above, not what is in the Spring reference docs. At last check the docs were somewhat confusing in the use of include versus include_class
- AOP can be used to wrap the dynamic beans just as if they were POJOs. The one big caveat here is to make sure they are implementing an interface. Class based proxies will not work

Spring's support for dynamic language beans is pretty powerful in it's simplicity. The uses of this technology are much farther reaching than just mock scenarios, though. JRuby or Groovy files can be polled and reloaded without compilation or server restarts. This can be immensely useful for dynamic portions of applications like lightweight rules, environment configuration, validation, or even web site navigation.

Hope this helps get you started with integrating dynamic languages into your Java code. Please leave a comment with your scenario if you are using or planning on using dynamic languages integrated with Spring.

Code Mash Recap

Codemash came and went over a week ago but I've been hoarding my free time so the blog has gone by the way side. I must say that codemash is as unique a conference as you can find and the organizers do a superb job of providing valuable content and access to bright people. The speakers I saw were very good overall and made you question how the conference is not pummeled with only charging $200 or less.

The highlight for me had to be speaking with Jim Weirich on a couple of occasions about Ruby and his work at EdgeCase. He's the man behind Rake, XmlBuilder, FlexMock, and other pieces to the Ruby puzzle I'm sure I'm forgetting. He was extremely down to earth and very practical about using the appropriate language for the job. He's like DHH with his passion for Ruby and Rails, but without the arrogance.

Additionally, I was reminded why I really enjoy working with the people I do at QSI. We sent no less than 30 people there, had a couple of speaker/organizers, had the most rocking booth of all the vendors, and most importantly had great discussions about software over beer every night there. At least 5 people made comments to me about their desire to learn Ruby and/or Rails. We'll hopefully capitalize on this passion by forming a 12 step program to get us familiar with Ruby (first and foremost) and then Rails. I'll keep the blog updated through the journey to beautiful code...