Well, I think more than a few folks spent much of last night in or around the bar because this morning it was quite a bit quieter at breakfast (let’s just say most folks wandered in closer to 9). As you might expect at a conference with 500 or so developers (nearly everyone with a laptop) the wi fi is, at best, spotty, still it’s quite something to see a bushel full of Macs at every table! Seriously, there can’t be more than 10-20 Windows boxes running around and from what I’ve seen a fair portion of those are actually running some flavor of Linux. Anyway, I started me day listening to Obie Fernandez of ThoughtWorks talk about the projects he’s been involved with over the last year or so. Clearly there is a lot of interest in Ruby and Rails at ThoughtWorks and considering how “enterprisey” they are, that bodes well for wider adoption of this “niche” technology.
While there were lots of details he couldn’t reveal, it was quite something to see just how many projects they’ve done (and the variety, from standard web apps to touch screen kiosks) - and more importantly, how interested customers (big customers at that) are in Rails. Regarding the “data center issue” (i.e., the excuse that we can’t use Rails because it’s not supported) Obie relayed a story where, when finally asked, the manager at the data center didn’t have any problem letting them do what they needed to do. This is the first time I’ve ever seen Obie live - but I get the feeling he had a long night 
he seemed a tad tuckered, perhaps even a bit hung over, I’m not sure. All in all, it was very encouraging to hear his experiences - if ThoughtWorks is doing this much work in the space, I suspect they’ll have some influence on those that still think Rails isn’t ready for the enterprise.
The next two talks I hit were on DSLs/metaprogramming. One of the things I find so interesting about Ruby is the ease with which you can create a DSL thanks to open classes and the “missing method” hook. The first talk was by Steven Hammond and he discussed his experience building a DSL for a game he’s working on. Steven focussed more on the background material - what a DSL is, when you need one and what the pitfalls are.
While Steven’s talk was more focussed on more philosophical issues Brian Katz did a deep dive on an authorization/identity DSL that he put together for one of his projects. I have to admit, much of his talk was above my Ruby-fu (and I don’t think I was alone based on some of the chuckles from the audience when he asked the audience if we understood some less than trivial Ruby) but I still found it pretty useful. He answered lots of questions about why he made certain decisions and he also explored the “meta-classes” which was pretty helpful. While I’ve understood the concept ever since reading about language workbenches, it was always pretty nebulous how’d you actually create one. I might not be ready to actually sit down and write my own DSL, but I feel like I know where to start!
The argument I hear over and over regarding Rails is that it isn’t “enterprisey” enough. While not nearly as widespread as Java or .Net, Rails is indeed being used to power something more than “yet another social tagging site” and that’s what Rick Bradely and Charles Johnson of Centerstone discussed in their talk on Rails and the Enterprise. Centerstone started out writing the prototypical Java EE application using JBoss, Hibernate et al but after getting started they quickly moved to Rails where they saw a significant decrease in the amount of code they produced (on the order of less code than the XML in their Java EE approach…) You might recognize this from Rick’s blog Following the Rewrite - while I wish he and his team were writing a tad more, it’s still a great example of yet another enterprise application that is being written in Rails.
Rick relayed a quote from his CIO which basically was: “A year ago, no one knew what Rails was, now they say no one uses Rails.” How many more applications have to be built before people realize how wrong that last line is? Obviously, there is a class of application for which Rails is clearly the wrong answer - but the variety of solutions that can be built with Rails is much larger than many enterprisey folks want to believe. But hey, as Paul Graham said yesterday, the value is in the margins so maybe I should just look at this as a huge opportunity.
Dealing directly with web/app servers is relatively new to me - at least as done in the Rails world. While I’ve worked with Apache, Tomcat, WAS, etc, I’ve never dealt directly with configuring them. Considering how key things like lighty and FCGI are to a Rails app, I figured I better attend at least one session on the topic hence why I went to Jan Kneschke’s Accelerating Rails with Lighty. All I have to say is I have a *ton* to learn in this space and frankly I think it’s one of the things that the Rails world needs to overcome. At the end of the day, I’m a developer - I don’t want to have to deal (much) with issues like what mod I need to install and which app server works best with which web server. I think it’s interesting that for a framework that “just works” and is so opinionated, the deployment issues are the real hang-up. I’m not sure whether most Rails developers *should* concern themselves so deeply with the inner workings of lighty or FCGI. Again, some things were a tad over my head but there was a lot of material in this talk - enough that Jan went about 20 minutes over his scheduled time (no real sense of urgency in his talk…even when he knew he was running long, he didn’t really speed up his cadence).
Next up the indefatigable Mike Clark on testing! When you see how freaking easy Rails makes testing…well, it makes me want to cry actually. The functional and integration tests are fantastic, especially with the new named routes feature but the support for fixtures makes unit testing a snap too. I’ve written Java systems with thousands of tests but there were lots of areas we just couldn’t get to - with Rails, we wouldn’t have the normal excuses. Mike walked us through the essentials including why we as developers should care about testing, the basic asserts in Test::Unit, what Rails adds to the mix, and how straightforward integration tests actually are.
When you first look at a Rails app, one thing you might notice is the gentle reminders (or is that just good old fashioned midwestern guilt?) about the importance of testing. After all, you’ve got directories that are just sitting there begging to be populated! Testing is just part of the culture, part of the community. Rails itself has a slew of tests, running rake causes all the tests to run and rake stats lets you know how much test code you’ve written. It doesn’t hurt that Ruby and Rails makes testing so much easier than it is in other languages; creating a little testing DSL is a snap thanks to Ruby. Want to mock out a class? No problem - just put a class of the same name in your mocks directory and stub out whatever method you want! We use mocking libraries on my projects, but they aren’t even close to that easy.
I think the emphasis on testing speaks highly of the Rails/Ruby community. After three days here (and I’ll admit, this is a pretty self selecting group) I can’t help but think there are a lot of really top notch professionals in this space - people that feel a responsibility to produce good, working code. I’m not saying these types don’t exist in Java or .Net, but it just seems to be part of the DNA of these individuals. I’m not sure what the cause and effect is here (are more adept developers just drawn to this or does Ruby/Rails just make it so natural?) but it really is something. I have to say, I wish my Java apps were this easy to test… Honestly, you would think the test infected nature of Rails would make it an easier sell at the enterprise level.
The last talk of the day was by Nathaniel Talbott (what a great first name!), creator of the aforementioned Test::Unit. Nathaniel spoke on Homesteading; basically, he was challenging us to do what we love, to “buy the ticket” and get out there and build something. We’ve got so many opportunities available to us, so many ways to create our own little businesses - we just have to execute. We are all at risk, whether we realize it or not, however we have to assess that risk and expose our assumptions. Anyway, there were so many great thoughts in his talk that I don’t think I can do it justice in this post but let’s just say between listening to him and Paul Graham, I’m really tempted to take the proverbial plunge. Nathaniel’s talk really was a call to action and I’m interested to see how many people take him up on that.
After dinner, we were regaled by the creator himself, DHH. David’s talk was more tutorial than inspirational but it was quite interesting to see where he is taking Rails. I can see where the arrogant label comes from but it’s also clear he has a real passion about software - and many of this opinions are rooted in sound thinking. A key theme was using the HTTP verbs to indicate the action on a controller instead of imbedding it in the URL. He also spent a great deal of time talking about intersection entities between many to many associations and RESTful web services. All in all, a pretty interesting talk - and I’m sure others will do it more justice than me!
