Signal to Noise Ratio in Rails

Like all the other Mac-toting fashion hounds, I've been playing with Ruby on Rails of late. I have the good fortune of having a buddy who has a paying gig building a Rails site and he is kind enough to give me commit rights so I can use it in a meaningful way without giving up my day job as a J2EE guy, and without having to find an excuse to use it at work.

Without getting all hysterical about it, there are many things in Rails that should give pause to the J2EE crowd. When I switched from C++ to Java, the thing I liked most about coding in Java was the much improved signal-to-noise ratio compared with C++. I found I spent much less time thinking about computer stuff and much more time thinking about the problem at hand and the concepts of the problem space, largely ignoring the problems of the implementation space. This was partly the language, partly the libraries, and partly the community around Java at the time, but when you add it all up, the result was better software faster, which is really all I want.

Now, having used the classic J2EE stack for a while (Struts/Tiles/Hibernate, et al), and having watched J2EE vendors bloat their products to the point of collapse, using Rails has given me the same feeling. No struts-config.xml, no tiles-defs.xml, no *.hbm.xml files, and much less time thinking about the machine and its implementation layers. The signal-to-noise ratio is simply better than in the form of J2EE I've learned. Ruby/Rails also appear to have the libraries and the community to make the whole stack work. The whole setup feels more supple and malleable than Java, and, since that feeling was what attracted me to Java, that has to be a concern for those who think Java is some kind of universal maximum, rather than just a local one, as all technologies are.

There are some things in Rails about which I retain mixed feelings. ActiveRecord seems to me to be less of an O/R mapping layer, and more of an O/R unification layer. This caused me severe brain ache for a while, but I'm suspending disbelief for the moment. The unit testing model involves database access (and lots of it), which is a definition of unit testing I've always disliked strongly. The functional testing model (so far as I have looked) doesn't use a model based on parsing and filling out and submitting the HTML forms served by the running application. It appears to be more a controller-testing setup than what I would call a functional testing setup. But I'm only a newbie and might have missed some stuff.