GoRuCo 2009 impressions
I passed on RailsConf this year, mostly for scheduling reasons. Instead, I attended the Gotham Ruby Conference (GoRuCo) this past Saturday at Pace University at NYC. Overall, I was very impressed with the caliber of attendees and would go again.
While all of the talks were outstanding, there were a few that I felt really stood out:
Where is Ruby headed?
Gregory Brown, creator of the Prawn PDF generation library for Ruby, funded completely by the community.
This was the first talk of the day. I didn’t sleep particularly well the night before and was a bit worried that I wouldn’t be ready to get anything out of the talk, but I’m happy to say that I was wrong. Gregory addressed several of the issues he had with making sure that Prawn would be compatible with both 1.8.6 and 1.9.1. He addressed various topics from very specific code samples of 1.8.6 and 1.9.1 differences to various workarounds for code that needs to be compatible with both versions (I/O iterators … #each is now #each_line). Eventually, this led to a few interesting discussions:
- The Ruby versioning system is EXTREMELY confusing. 1.8.7 is not a *minor* update, but a rather significant one, and 1.9.1 is way more mature than 1.9
- The general consensus is to not try to support 1.8.7, and to focus on 1.8.6 and 1.9.1. Eric Hodel, maintainer of RubyGems, will be moving towards only support 1.9.1+ in the coming months, but it’ll be a slow process.
- The best way to include external C libraries in Ruby on Windows is FFI with JRuby. It’s a mad, mad, mad world.
SOLID Object Oriented Design
The slides are here: http://skmetz.home.mindspring.com/img1.html
I thought this was an amazing talk. Sandi discussed the methodology behind refactoring Object Oriented code. In this case, she discussed the design of a Ruby FTP client that would download a CSV file and do some trivial computation.
However, I felt that Sandi’s example is purposely hypothetical and meant to illustrate refactoring techniques. Realistically, for something as simple as an FTP client, the example was an exercise in over-engineering. There’s a balance between extensibility/modularity and creating a simple to use interface. It’s clear that Sandi is leaning towards the former, as it got to a point where she was evaluating a class name from a YAML file (RED FLAG, RED FLAG). I disagree with this approach, since Ruby can be so terse and powerful that in many cases, code should be configuration, especially if the configuration is for specifying a class name for the purposes of dependency injection. This is not the Ruby way, and there were comments that we had essentially turned the FTP client into something that was all about configuration and not convention, and it eventually leads to death by XML. Use judgment. Sandi’s techniques are great for refactoring complex interactions, but as Rubyists we understand that not everything is an object. Make the code readable for humans, and make the APIs clean. I don’t know if I agree with Sandi’s philosophy that “since you don’t know how your code will be used, it should be as modular as possible”. That sounds to me like front-loading engineering. I’m going to quote Reid Hoffman: “If you are not embarrassed by the first version of your product, you’ve launched too late.” Be pragmatic.
From Rails to Rack: Making Rails 3 a Better Ruby Citizen
Yehuda Katz, Project Lead for Merb, Engine Yard
So did I miss anything? Please comment if I did!