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.
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:
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.)
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.
Previous Topic
