Why You Want Rails

Several sessions have been devoted to Rails at JavaOne 2008. The nice thing is that have invariably used the same example: a simple blog app that Rails creates in seconds.

Whether by accident or design, that confluence has worked out well. It has made it possible to see the same application from multiple different vantage points. So far, I've seen it constructed from the command line and from NetBeans, worked with it in an interactive lab, and seen a walk-through of the process that explained what was going on and discussed various options along the way.

At this point, I've got enough familiarity with it that I could reach in and do something with it--and the high-level understanding of the architecture I've gained will make it easier to come up to speed when I'm looking at someone else's app. Most importantly, though, design thoughts are swimming in my head, along with experiments I want to try. So this convention has been unexpectedly good for learning about Rails.

There are good reasons for wanting to know about Rails, too, if there are any web apps in your future:

• You can create a running app in seconds, with a couple of commands. You won't spend hours just to get Hello World to run.
• Less Rails code than Java application configuration (which should pretty well end the discussion).
• Rails uses Rake for builds--and Rake is a hecka-fun build language.

But perhaps most importantly, Rails lets you do agile development, primarliy due to the fact that Ruby is interpreted:

• You can do true "test first" development: You can create your test and watch it fail before you begin writing the code that will make it succeed. The RSpec framework even distinguishes between code that fails (red) and code that hasn't been developed yet (yellow). (Were it a compiled language, the tests wouldn't compile until the application classes and interfaces had been written.)
• You make a change and run it. There is no need to recompile, redeploy, and restart. That makes the process a lot more fun. (Some changes require you to run a new instance of the application--database changes, if memory serves. But for most changes, you just refresh the browser!)

Rails apps are also more maintainable, due to:

• A "database create" task that is useful for testing.
• A "database migrate" task that's helpful when you're debugging a problem in a previous version of the application.
• A fixed directory structure, so developers have an easier time coming up to speed on new applications.
• A "convention over configuration" mantra that also makes it easy for new developers, so there are fewer configuration connections to understand before you can make sense of the app. In addition, the skills developed on one project translate readily to the next. (For example, if you see a data class called "Tractor", you will expect to find a "tractors" table in the database.

Why You Want JRuby

According to Ola Bini, a core JRuby developer from Thoughtworks, "JRuby on Rails is taking the world by storm". Bini, the author of Practical JRuby on Rails, went on to show a lengthening list of companies that are using it.

There are a variety of reasons that JRuby is popular for Rails apps:

• Database connections are made through JDBC, which provides broader, more scalable database support.

• On average JRuby, runs 2 and a half times faster than Ruby, except at startup. (That time is inconsequential for production, but does slow down development cycles a tad. Fortunately, the JRuby guys have found a simple library trick that will shorten the current startup time of 1.5 seconds, bringing it down to .5 seconds.)

• In addition to native threads, JRuby supports Unicode natively.

• There is a whole team at work on performance and garbage collecting on the JVM, so there is that much less for the JRuby implementors to worry about.

• Code can be fully compiled ahead of time or just in time. (For performance, you need to experiment to find out which works best. Hotspot can do a pretty amazing job of runtime optimization. But pre-compiling has another advantage: protection of source for a commercial application.)

• A JRuby on Rails application can be packaged into a WAR, and then deployed onto any compliant server. There tend to be a lot of those in the IT world, these days, so you can deploy your Rails app without asking your IT department to support a whole different server with unknown security vulnerabilities. (The packaging can be done with Goldspike, or with the new kid on the block: Warbler. More on that tomorrow.)

• Glassfish--the Java web app server that scales well--is available as a JRuby gem. (Right now, there is a bit of configuration to do to make everything work. But glassfish v3 will have direct support for Rails, so you just develop and run.)

• A Ruby on Rails app can scale, but it does so at the cost of one process per connection. A large application like Twitter was running 180 processes, at last count. Each process consumes system resources, and context switching adds latency, so minimizing the process count is a good thing for scaling. Glassfish gives you multiple listener threads, while JRoR gives you multiple processing threads. Result: Big performance, vanishingly small process count (on the order of, like, one).

• With JRuby you get the best of both worlds: Ruby applications and libraries, plus Java libraries. And you can access those libraries with Ruby syntax (or Java syntax, if you want).

• JRuby provides a plethora of language features that are missing in Java--features that tend to make programming more fun. Some, like closures, are under consideration for addition to Java, but simple things like Ruby's literal syntax for hashmaps make code easier to read and write:

  require 'java';
  import java.util.HashMap
  h = hashmap.new
  access with ruby syntax: h["foo"] = "bar"
  h.key.sort { |key| ...do something here... }
  

One JRuby on Rails application worth examining will be Mingle, Bini's tool for project collaboration. It's the first JRuby on Rails application, and it does some selective pre-compilation to protect internal sources. (The pricing is interesting, though. The first 5 licenses are always free. After that, you spend anywhere from $300 for a six-month license to $1000 for a perpetual license.)

Why You Want NetBeans

I'm a huge fan of interactive development environments (IDEs). In general, I subscribe to the philosophy that the computer ought to be doing everything and anything it can do, leaving me to take care of the rest. IDEs do a great job of off-loading development work, and for Ruby and JRuby on Rails, NetBeans does a pretty decent job.

Note: Eclipse developers will use RDT or Aptana/RadRails, but this post is about NetBeans.)

To start, NetBeans provides a bunch of conveniences that save time:

• Ctrl+click to jump to a declaration
• Right click to move between model, controller, and view.
• Auto-recognition of camel case in the search menu, so so "AC" gives you a list of ActionController entries.
• Ctrl+Shift+Space for code completion (you get a list of possible completions, with API documentation showing in a separate pane when an entry is highlighted.
• Ctrl+Shift+Space in a comment to preview the RDoc HTML that will be generated (either to check your code or to view the comments in a more readable way).
• Indented code in a comment is automatically pre-formatted (so you don't have to add <pre> tags. When displayed, the code is syntax highlighted (making it easier to read).

NetBeans also adds useful functionality:

• Refactoring support. For example, when you select code and extract it to a separate method, NetBeans automatically sets up the parameter-passing and multi-value returns necessary for the refactoring to work. (And of course there is renaming, which helps to keep code readable and maintainable.)
• Testing support. You can interactively go to tests and run them, whether you're using the standard unit testing framework or RSpec. (RSpec is geared more for behavioral testing. It also has more readable syntax, and gives you a yellow bar for unimplemented code in addition to the red bar for a failed test.
• Warnings for code that will be incompatible with Rails 2.0
• Support for javascript as well as rhtml in erb files, so you get code completion, and refactoring. You also get a visual display that shows how things will appear as your formatting rules are applied.
• The ability to run a single test out of a suite, so you can zero in on the code you're working on.
• Interactive debugging, which helps you see how things work together.
• The ability to debug template files as well as code.
• When you add a WAR-producing plugin like Goldspike, the Rake tasks they add are available in the NetBeans menu. You select that task to create the WAR, then copy it into the Glassfish autodeploy directory to run it--all without leaving the IDE.

Resources

• Mingle

  http://studios.thoughtworks.com/2007/5/7/mingle-to-run-on-jruby http://www.thoughtworks.com/press-releases/Mingle-JRuby-Release.html http://studios.thoughtworks.com/mingle-project-intelligence/pricing-and-license

• Glassfish

  https://glassfish.dev.java.net/