Java to Ruby on Rails: Julian’s Adventures

In my view, a good test of how solid a framework is, is what you have to do to get good performance out of it. Does it all go to hell? That is, does the code you wrote before have to be mangled beyond recognition to get things to go fast?

This article on by Stefan Kaes on Common Rails Performance Problems, and Stefan’s blog RailsExpress dedicated to Rails Performance make it clear that Rails is a bit of both:

• The core Rails framework definitely has some pieces that just seem to work pretty slowly and should be avoided on critical pages: URL mapping (’routes’) is one:
  

  “In general, all helpers that take a URL hash will invoke the routing module to generate the shortest URL referencing the underlying controller action. This implies that several routes in the route file need to be examined, which is a costly process, most of the time”

• ActiveRecord is slow in a number of circumstances:
  

  “Retrieving a large number of ActiveRecord objects from the database is relatively slow. Not so much because the actual wire transfer is slow, but the construction of the Ruby objects inside Rails is rather expensive, due to representing row data as hashes”

• Another one of use: the MySQL adapter for Rails has a performance bug in it which makes it degrade significantly when accessing 1000s of rows. Full discussion here on how to make sure your Rails MySQL performance is optimal.

These aren’t surprising in a framework that’s only been out a couple of years now. What I’m particularly interested in low cost tunings that won’t be made redundant by the next rev of Rails. Stay tuned.

How to find the problems: performance tools

Another aspect to consider is tools for Rails performance assessment: Railsbench for performance regression testing, and a commercial Rails performance analysis tool for $US199 which Stefan also recommends.
Whatever happens, memcached is very likely to be part of scalable performant Rails apps for quite some time.

I’ve been spending a lot of time recently trying to make boxedup.com scale. Before I started, I’d watched the right screen-casts, read the right books, and I thought I knew what had to be done to speed up rails applications when the need arose.Boy, was I wrong.

A quick look at the three methods of caching rails pages reveals that page caching is of no use to a site which insists on displaying the current user on all pages.

Thanks Craig Ambrose for his generous sharing of performance engineering in Ruby on Rails. Craig’s experience is that fragment caching is the only practical way of scaling most rails apps and makes a point about some gotchas around cache expiry.

Also, he refers to the memcached framework for distributed in-memory caching. Twitter makes extensive use of memcached too.

“If you’re building a real site, go straight to memcache”

That’s nice and clear. Looks like I have some refactoring to do. But I’m not sure whether what I’m doing could equate to a ‘real site’. I’m assuming a ‘real site’ means 1m page views a day. Probably won’t hit that for a year or so, if ever.

A clever trick Craig uses is the fact that memcached automatically discards stuff that’s old. So for example to manage cache coherency on a ‘recent activity list’ he uses ‘last activity id’ as the key — when it changes, it needs to refresh the item. The old last activity just falls off the end courtesy of memcached. Nice! Shopify uses this caching technique by having a version number as part of the cache key.

By Patrick Lenz at Sitepoint. Link will be removed at some stage
It’s for absolute beginners — for those who also want an introduction to concepts such as MVC etc, yet, not enough beginner material really — I’d give it a 3 — it skims over the surface of Ruby so much as to be virtually worthless in this regard, even for experienced programmers. To rub it in, it says “you’ll learn the latest web 2.0 techniques” — but doesn’t really, in any way. If you want a great book that covers nearly the latest “Web 2.0 techniques” then buy Alan Bradburne’s Practical Rails: Social Networking Sites.

Selenium is a GUI testing framework. Jonas Bengtsson wrote a screencast illustrating RSelenese guiding you how to do Selenium on Rails (Feb 2006). I’m keen on Selenium, but trying to figure out how it fits within the plethora of testing support Rails already has.

“In the demo I create a new Rails project, install Selenium on Rails, create a test case using Selenium IDE, create another in RSelenese, and run all the test as a Rake task.”

From Ruby-lang.org: a high level summary of the main differences between java and ruby.

It’s pretty basic and I’ll be fleshing this out further in due course.

Rick Bradley generously writes a detailed case study on Rick’s experience moving from an enterprise application written in Java to Ruby on Rails back in Nov 2005. Centernet is a large scale healthcare application (see also the Rails mailing list.

As it was in 2005, it will have been done with an pre 1.0 version of Rails than the current 1.2 — I hope to update this with responses to some of the obstacles encountered with a modern 2007 view.

Here are his most interesting points in précis:

• Vastly reduced code footprint
• zero configuration
• DRY principle: Simply put, “Don’t Repeat Yourself”.
• Rapid development methodology
• Single-stack application framework
• AJAX UI support
• IDE automation not required
• Dependency Injection (IoC) much less necessary
• Integrated unit and functional testing support
• Share-nothing horizontal scalability
• Built-in memcached support
  Language stability
• High-profile defection from the java camp

Considerations made

• No EJB Remoting
• Commercial Support options more limited
• Lack of clustering
• Harder to support legacy databases
• Confused i18n support
• In-house experience/retraining
• Code conversion: Hibernate mapping files would be discarded, with very little effort required to duplicate their functionality in Active Record—at a great savings in mapping elimination, and significant decoupling.

The ‘no magic’ rule

Before I start I want to enforce a rule that few ruby sites I’ve seen do: no magic here. That is, no unexplained hieroglyphics or syntactical sugar when explaining Ruby or Rails to you java folk.

Also, I won’t bother explaining stuff that you can figure out really easily, like the use of ‘<’ in Ruby for ‘extends’.

Now, on to the advertised programme.

Strong type declarations are overrated.

Hear that sound? That’s the sound of me running for cover. But I’ll try again: strong type declarations are overrated when you use test-driven development. Rails is big on TDD and has great support for test fixtures etc.

You always start start with your test in Rails

Here’s some Ruby code to do a unit test against a User. The magic is explained under it.

class UserTest < Test::Unit::TestCase
  fixtures :users
  def test_authenticate_user(password)
    assert users(:joe).authenticate(password)
  end
end

What’s that freakin colon thing?

  fixtures :users

This warrants some explanation: it’s a method call but it’s just floating around in what java guys would think is a declaration. What’s going on?

Turns out you can just write code any old place and it’s a bit like Java’s static{} block. So this line of code is run once, when the file / class is loaded.

So what about

:users

?

Any piece of text prefixed with a ‘:’ is called a Symbol. Symbols are globally-scoped: the :user used above is the exact same :user Symbol referred to elsewhere, while writing “user” defines a new instance of a String object each time, and Strings are mutable in Ruby (but more on this magic later).

NOTE: Symbols, like everything in Ruby, are classes. So you can call all the Symbol methods on :users directly. Again, more on this later.

For more info see Symbols vs Strings

Rubylang.org has a list of differences moving from the java language to ruby. It’s very high level and I’ll be elaborating on the points in due course.

Here are some areas I want to focus on — chapters if you were, but probably more categories.

Rails Magic: the conventions

I don’t mean ‘magic’ in the emotive way — I mean in the ‘ooooh how did that happen’ kind of way.

Rails takes on the approach of convention over configuration: set up sensible implicit relationships rather than needing to explicitly define everything and you end up with a much cleaner system.

Except it can take some time to figure out. So one area I’m going to cover is the Rails Magic used.

Uniquely Cool Things

Another area is aspects of about Rails or Ruby that really set it apart from my experience with Java. Some of these points may become contentious as it’s been a little while since I’ve actively programmed in Java, but there you go. Two here off the cuff are ActiveRecord, and database migrations.

Sucky things about Rails

Here I will talk about things that I feel let Rails down, as it stands. One here is, despite everything, poor documentation in key areas.

New ways of thinking

Another area I’m looking to do is capture ‘useful insights’ as a java programmer — things that really do require a new way of thinking: the change is conceptual, and does require work, more work than you may have had to invest when moving to java, for instance. For example:

Extensions: Plugins, Gems, and Engines

Particularly interesting extensions to Rails I’ve found, with a bias towards social computing apps (which is where I live). Stuff like acts_as_versioning, acts_as_taggable_on_steroids, etc.

Development Tools and Resources

Tools to support development: IDEs, etc. Good books too, and sites.

Case studies

Where there are stories of people moving from Java to Rails — I’ve captured them under this section.

I’ve been flirting with rails for about a year now on and off. I spent a day with rails just over a year ago and recently the opportunity has come up to go forth.

This blog will attempt to document my experiences as an experienced java programmer (which started in 1998), so reflecting specifically on the differences between the Ruby on Rails framework and the Java world.

There’s a book, ‘Rails for Java programmers, which I plan to read, but there’s no resource I’ve found to-date covering this migration niche of Java to Ruby on Rails.