Clint Hill

At work I have an opportunity (a great one I think) to make a case for choosing Ruby as a language and for Rails as a web framework. But the whole development staff is rooted in Java.

On a few projects we have chosen Rails and have had the success we hoped for. We went against standards for a bit, but now we have our Rails projects deploying to WebSphere with JRuby and no one is the wiser. Or upset even. We would very much like to continue getting approval to use Ruby and Ruby on Rails.

We are in a position to permeate Ruby and get more projects based on it, not necessarily all with Ruby on Rails. However, very high up managers are muttering things about Grails. And I guess for very good reason. Groovy is a very Java like language and it would all fit. Seamlessly. They say.

The opportunity I have is to write up arguments for Ruby. Specifically I have been asked to make a quick hit-list outlining benefits of Ruby and Ruby on Rails.

I’m asking for help. Here is the Bat Signal.

Give me your facts. Tell me where you have read things proving benefits of choosing Ruby and Ruby on Rails. Data that shows how Ruby has made development process better, time to market shorter, enhanced quality of code, eased project management, transitioning staff was easy, language momentum in the industry and whatever else. Give me the arguments in the context of using Ruby on Rails for building applications.

Remember - you’re not selling me - you’re selling my boss. Your boss. Anyone in a position of authority over the tools developers use.

Here is what I don’t want. Specifically things that start with these:

• “I think …”
• “I believe …”
• “I’ve heard …”

That’s all crap. Won’t work. I want facts. Studies, white papers and provable anecdotal evidence. Stats rock.

I also don’t want suggestions like these:

• “Use Python because …”
• “Haskell is better because …”
• “Real men use Lisp …”

If you want to get into those kinds of debates you can go to Reddit. If you believe I’m delusional for liking Ruby and want to suggest other languages - maybe next time. Right now Ruby is the target. I’m cool with other languages so we can chat later.

And don’t just say:

“37 signals uses it for all of their products.”

I know. That’s not what I’m after. I want to know your experience and knowledge. Big companies using it in situations where real money and services are involved. Real facts (not that 37 signals is some imaginary piece of anti-matter).

So give it to me. Help me out. What would you tell your boss if you had the chance?

Because Warbler made it so easy for me, and because I actually had to for my work environment, I took a first stab at a few rake tasks to EAR my Rails project.

[EDIT] I posted this without really saying “why”. At work we run everything on WebSphere. And as smart environments do, there are scripts to do about everything, including install applications. In order to get some adoption for Rails in our Java world we wanted to do our very best to make it all seamless for operations and engineering. The install scripts are all wired to work with “.ear”. Hence the need to take Warbler one step further. And by the way - all the credit goes to Nick Seiger.

Now these are the result of about an hour or so and definitely have some issues. For example this implementation is very specific to WebSphere 6.1 and moreover has no real configuration ability. But nevertheless it works and I wanted to share. (Is anybody else needing EARs instead of WARs?)

[UPDATE 12-11-2008] This worked out nicely. It made the development side of things super easy. In fact the EAR is working nicely during installs in WebSphere Admin Console. However, when I try using the install scripts (for automation purposes) in WAS it craps out. I’m hoping it’s due to a misconfigured application.xml file. But so far I’m stumped.

namespace :earlybird do
  desc "Build the EAR file for deployment"
  task :build do
    warbler = Gem::Dependency.new('warbler', '>=0')
    if Gem.source_index.search(warbler).empty?
      puts "=====  This task requires the warbler gem!  ====="
      puts "    sudo gem install warbler"
      return
    end
    gem warbler.name
    require warbler.name
    @warble_config = eval(File.open(Warbler::Config::FILE) {|f| f.read})
    @war = File.join(RAILS_ROOT,"#{@warble_config.war_name}.war")
    @ear = File.join(RAILS_ROOT,"#{@warble_config.war_name}.ear")
    @staging_dir = File.join(RAILS_ROOT,"tmp","ear")
    @meta_inf = File.join(@staging_dir, "META-INF")
    mkdir_p @meta_inf
    %w(application.xml ibm-application-bnd.xmi was.policy was.webmodule).each do |file|
      cp File.join(RAILS_ROOT,"config", file), @meta_inf
    end
    sh "warble war"
    @war_dir = File.join(RAILS_ROOT,"tmp","war")
    cp File.join(RAILS_ROOT,"config","ibm-web-bnd.xmi"), File.join(@war_dir,"WEB-INF")
    sh "jar uf #{@war} -C #{@war_dir} WEB-INF/ibm-web-bnd.xmi"
    cp @war, @staging_dir
    sh "jar cf #{@ear} -C #{@staging_dir} ."
  end

  desc "Clean out your ear"
  task :clean do
    warbler = Gem::Dependency.new('warbler', '>=0')
    if Gem.source_index.search(warbler).empty?
      puts "=====  This task requires the warbler gem!  ====="
      puts "    sudo gem install warbler"
      return
    end
    gem warbler.name
    require warbler.name
    @warble_config = eval(File.open(Warbler::Config::FILE) {|f| f.read})
    @ear = File.join(RAILS_ROOT,"#{@warble_config.war_name}.ear")
    @staging_dir = File.join(RAILS_ROOT,"tmp","ear")
    rm_rf @staging_dir
    rm_f @ear
    sh "warble war:clean"
  end
end

task :earlybirdy => "earlybird:build"

At work I’m assigned to a project that is a simple 2 view web app. There is a ton of information and a great deal of calculation. It’s a financial application focused on insurance premium processing. Moreover it’s a quoting system, so to speak, so there has to be a great deal of flexibility to the views. You have to be able to add/subtract items and modify percentages and rates. All the while the view must keep other parts of the screen refreshed with the new calculations.

Ruby on Rails is a great web framework. But for this kind of application I’m not sure it was the right choice. I would have possibly looked at SproutCore. In fact, the application I’m working on reads like a white paper for SproutCore. Rails on the other hand is super good at making data entry and data management a breeze. It has it’s abilities elsewhere, like AJAX support baked in and RESTful practices nearly required. But it just doesn’t really support a “thick” client the way SproutCore does. It is more focused on quick development of views that receive info and save them back to a database (wash, rinse, repeat). People have done enormously different things with Rails outside of this, but with great effort to shoehorn Rails.

Which sort of leads me to my thought - software designers/architects need to step away from the “hot” technology for a moment. Look around. Is there anything else that does what you need a little bit better than the newest trend? It’s really easy to just answer every question with the same answer. It ends up something like Rails but not like Rails at all. Rails without all the Rails.

To a man with a hammer, everything looks like a nail.

-Mark Twain

To be sure - I might have suggested Rails too. Rails is too easy to get something started with. It’s actually working out nicely. But when compared to other frameworks it turns out looking like more work than was necessary.

Now, would I be tempted to rebuild the application I’m working on in SproutCore?

No. At least not on company time!