Things I learned at RailsConf 2008

There were about 2k people at RailsConf 2008, and like most of them, I thought of posting my review of each of the presentations I saw and heard about. Thankfully, the masses have spoken, and there are lots of reviews for you to read elsewhere. Also, if you want to check out some of the presentations themselves, O’Reilly is hosting many of them online.

What I’d like to do instead is to document the things I learned at RailsConf, that stretch across presentations. The first thing that I noticed were the themes that seemed to find their way into almost every session, lighting talk and hallway conversation. There was a lot of focus on testing, deployment, automation, performance benchmarking, design (anti-)patterns and the social aspects of distributed source control management. These are real topics, discussed in great detail by people with real experience to an impassioned audience. It was impossible not to get caught up in the energy and passion, two things that may seem at odds with the typical software conference. Thankfully, RailsConf is anything but typical.

JRuby

WIth all this talk of the various Ruby implementations, my colleagues and myself have been interested to learn more about JRuby. I attended a few JRuby events (the “hackfest” on Thursday was great!) and got a much better understanding of JRuby and what sort of costs/benefits there may be in using it.

The Good:

I was able to get a small Rails app running on JRuby in a few minutes. It just works.
The availability of Java types from Ruby is astoundingly simple
Simple .war and .ear deployments can make for easy integration into a Java environment
Using JDBC drivers and JNDI is pretty sweet
For some applications, switching between Ruby and JRuby can be seamless. Thoughtworks does dual-development on some projects (for reasons not explained)

The “bad”:

Exception handling in Java/JRuby projects is tricky. Exceptions wrap either a Java or JRuby exception and you must unwrap and inspect upon rescuing them.
It is not uncommon to get Java stack traces in JRuby projects. It would be nice if these were entirely hidden regardless of root cause.
Windows paths for file URIs is currently broken (I reported this bug during the hackfest, JRUBY-2591)
The ease of integration for Java libraries can turn an otherwise clean and simple Rails project into a horrific beast of amalgamation. While this is an implementation detail and not a problem of the project, I can see a Java team not wanting to follow “The Rails Way”, and taking away any and all advantages of using Ruby and Rails by overusing Java.
JRuby is essentially on par with Ruby 1.9 in most performance benchmarks. The JRuby team will be focusing on making Rails perform better on JRuby, but for the time being it does not bring significant performance improvements.

Rails Hosting

With Engine Yard as a major sponsor of the conference, and many startups opting for hosted solutions, this was a well worn topic, with a few key insights.

The golden ratio is 3 to 4 mongrels (or instances of your app) per CPU core. Don’t debate this, it’s written in copper.
Cache, cache, cache. Use the same file system across your app instances so they can share page cache. Engine Yard and others spoke highly of Red Hat’s GFS system.
(Almost) nobody needs database sharding. It is a special use case, with lots of considerations. If you don’t understand it, you probably don’t need it.

Building Software with a dynamic language

Neil Ford had a “Design Patterns” in Ruby presentation, and Obie Fernandez had an interesting talk that showcased awful Rails code, which started to identify some anti-patterns.

The Gang of Four design patterns are all structural, in that they use objects to construct them. In Ruby, many of these patterns are solved within the standard library, and in an elegant and simple manner.
Dynamic languages allow you to do things that you can’t conceive of when working in static languages. The mixin/unmix portion of his presentation was good on this point.
An interesting code smell for refactoring: If code looks visually similar, and differs only in whitespace, it’s likely that you should refactor.
An obvious notion that should go without saying: Know your tools. Github’s rss feeds on projects (like Rails) makes for an easy time keeping up with the direction of the project, on each commit.
OOP paradigms are still critical in Ruby and Rails projects. A programmer without OOP experience will likely make for a terrible Rails programmer. Thanks Obie for reiterating this point. Don’t get caught up in the “blog in 20 minutes” vision of what Rails is.
Beware of Helpers that try to do too much. They can feel anti-OO and are usually the first to break down.

Scalability and Performance Monitoring

Scalability, on large and high-volume systems, is a never-ending battle of finding and reducing bottlenecks. There is no single solution or architecture. Understand how your app performs, and rely only on data, not hunches.
Someone else’s benchmarks are as relevant to your application as pickles to ice cream. Sure there is an edge case where they relate, but that’s just gross.
It’s essentially impossible to benchmark a framework. However, it may be relevant to get lots of specific performance data from lots of Rails applications to determine some relationships. I asked Koz about this during his presentation and he has already talked to New Relic about allowing their customers to share the framework-relevant performance data with the Rails core team.
Rely solely on real-world performance data in production when making scalability or performance-related adjustments to your system. All else will be either time poorly spent, or will end up hurting you.
Trending is nice, but the unexpected hockey stick graphs can still happen. Sometimes you just hit a wall (cache sizes, max IO nodes, etc.) that you never saw comming.
Understand the ratio of capacity to application instances. If you are not getting close to linear growth, find out why.
New Relic offers some great real-time performance monitoring. Their monitor points are extensible, so you can wrap your own stuff (SOAP calls, etc.) and have it monitored automatically

Testing

There were several talks on testing, and the topic came up in many others. It’s nice to see a community so focused on testing from both TDD and BDD perspectives.

Josh Susser’s obscure quote that summed up his presentation well: “De gustibus non est disputandum” or, There is no accounting for taste. Josh Susser wrote test suites in all the top testing frameworks for Rails and noted that personal preference and taste may be the only core difference.
Some testing frameworks (Rspec) influence code design to some degree, although all were capable of helping you evolve your API during the test cycle.
Each framework had similar levels of test code to test the same app. None stood out as particularly terse or verbose in comparison to one another.
It is certainly possible and in some cases ideal to mix-and-match testing frameworks. Using test/unit for unit tests and shoulda for functional (behavioral) testing would work well.
unit_record gem allows you to run unit tests without touching the database. Huge speed improvement, but means you need to plan accordingly when dealing with models.
fixtures, when used for test data are evil and should be avoided. Instead rely on a Factory pattern or Object Mother pattern which assumes reasonable defaults.
unit_controller gem allows you to better separate controller tests from the view
deep_test gem for running tests in parallel. Will sometimes cause problems, decent for individual developers, not for CI

During the conference, I also got a better understanding of Phusion’s Passenger, a.k.a mod_rails. While I didn’t attend either of their sessions, I met with one of their developers at breakfast. They seem to have a great story for reducing the complexity of rails deployment, they leverage some of the great performance of Apache and can handle up to 20 instances of your app per Apache (+mod_rails) instance.

Both David and Kent Beck’s keynote presentations were of an inspirational nature. While David played role of “life coach”, Kent Beck talked a lot about what the best perspective might be on “agile” development, and the various value propositions that make sense when selling ideas to the masses. While I took several lessons away from these great presentations, it’s pretty difficult to sum them up in writing. I’m sure (better quality) videos of them both will be online soon, so you can see them for yourself.

Overall, the conference far exceeded my expectations. It was nice to meet and hang out with a lot of the Rails community, see where our collective heads are at and learn a lot along the way.

Posted by Brian Doll on June 4, 2008
Filed Under java, rails, ruby, software

Testing: Static vs. Dynamic Typing

Cedric Beust recently wrote an article entitled Continuous Tax where he describes the term “Continuous Tax” to be “dead-on” in describing what it’s like to work with dynamically typed languages.

This topic interests me for a variety of reasons but mostly because Cedric is quite authoritative in the world of software testing, what with the framework and the book and all.

I commented on his post and to my delight, he responded.

I can’t say that I disagree that static typing is akin to “free tests”, as you may decide you need to write those types of tests in dynamic language. These tests however, are not free. They come with a cost of dealing with types in the first place. This is less of a discussion about the maintainability of software systems as it is one of values.

To quote myself:

Typically when discussing this religious topic (it’s a debate about values, as one is not superior to others in all circumstances) …

What needs to be decided, on a project by project basis, is what things you’ll value most.

Here is a little snippet of Martin Fowler’s thoughts on the typing thing (the “we” refers to himself and Bruce Eckel ):

…we both agreed that one of the most frustrating things about the static/dynamic typing debate is that it’s very hard to put into words the advantages of working in a dynamically typed language. Somehow things just seem to flow better when you’re programming in that environment…

Posted by Brian Doll on September 28, 2007
Filed Under java, ruby, software

Passing by Value, Reference and somewhere in between

I had recently run into what one might call an anti-pattern in a code base I was recently working in, and wanted to refresh my memory on exactly how java deals with object parameters that are modified within the method body. To be totally honest, the code (similar to the first code snippet below) was so strange to me because I had never ever seen that (anti-)pattern before. It’s likely an artifact left over from a C programmer that may have forgotten the language differences.

This discussion is often had, but usually leaves the participants more confused than when they started. Java passes by value, right? Or is it reference? What is it with primitives again? Oh man, forget it.

First, let’s read up on the specifics of this subject:
http://www.yoda.arachsys.com/java/passing.html
Another reference, with pictures!
http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html

Now, let’s grok this:

What is the value of snappy and happy?

In the above code, we see that we’re checking our Map for null, and if it is null we assign the parameter to a new HashMap object. This is where the world turns upside down. When we do this, we re-”point” (there, i said it, point, like pointer, i digress) the parameter to an entirely new object which we are then modifying. Snappy continues to be null after this code is run, but happy now has its foo/bar pair within.

AAAARH! You know what is so frustrating about this? The method will look like it’s operating on the original map parameter. Sometimes it will. When map is null in this case (or anything else that the programmer of addToMap decided to muck with), the method does not modify the original map.

Wait! It’s not all bad. Let’s note that the method addToMap does actually return something. It happens to return the right thing, all the time, in fact. Why all this madness then? Well, if we look above, the caller is completely ignoring the return value of the method! If we always were to assign the returned value back to the map in question, it would work the same way, all the time. It is possible to write a method that acts on the original parameter (object) without modifying it by using copies, but that’s expensive and usually redundant.

In the above case, we would have two maps, both with a foo/bar pair inside them.

This example is using a HashMap, but imagine we were talking about Strings. Strings are immutable in Java, so whatever you do to them, you’ll end up with a new string object, which of course, isn’t the one you passed in.

The point of this rant is that just because the compiler will let us, we should not rely on the confusing art of methods that modify their object parameters in place. As the article linked above states: “If a parameter is an “in-out” parameter, then its original value should be passed into the method and its result moved to the return value.”

Posted by Brian Doll on March 28, 2007
Filed Under java, software