'Arghh, Rails on Ruby is better than Java'
Chris Nelson was recommended by Jim Weirich (the Rake star) to have a look at Ruby on Rails at a Cincinati Java Users Group meeting. When he did, this was what he saw:
[I]t's called Ruby On Rails. And gosh darn it, it's just too darn good. Makes me sick. I'm no Ruby guy, believe me you. I don't go in for that alternative language kind of thing one bit. Unamerican if ya ask me. But confound it, I was blown away. Just watch the video ok.
Naturally, Chris has some concerns after watching the video. He's holding them dear as they're the only thing keeping him from "...spend[ing] every minute of my time at work crying while I code". I'd advise a big box of Kleenex for work tomorrow, Chris.
(UPDATE: Avik, another Java guy, discovers Ruby on Rails)
It worked from the database first. The video showed him adding tables and then poof they had screens appear. That's cool but where's my objects, mmkay?
The database holds just the attribute definitions. The stuff you would normally slave over as manual getters and setters in the Java class along with definitions in the XML mapping file and the DDL's. By the magic that is Ruby, these will now be available to the model class that can be further extended with domain logic ala:
class Milestone < ActiveRecord::Base
# deadline is defined in the DB as a date field
def late?(comparison_date = Date.today)
deadline < comparison_date
end
end
Basecamp has domain model of 44 such classes comprised of 406 methods (for a total of 2.8 KLOC). Rails believes strongly in the domain-driven approach and goes out of its way to make it easier to archive. Keep business logic in the domain. Use the classes and methods to form a domain language ("Is the milestone.late?").
Umm, hmmff rurfle scalability mumble mumble
Rails follows the scaling model of PHP: Nothing shared. Rasmus Lerdof had a great conversation with IT Conversations about this very topic. Basically, it means that you use the database as the sole integration point. This enables you to throw as many application servers (Apache + FCGI/mod_ruby) at the behavior as you like while scaling the state using database clustering. The tools for scaling like this are free, open source, and doesn't require an advance degree in rocket surgery to setup.
The jsp like sytax is gross
Yet ERb (embedded Ruby) is nothing like JSP (embedded Java). Java is such a heavy-weight language that it's completely unsuited for template generation. Java needs taglibs, velocity, and similar attempts to banish the life of scriplets. This is simple not the case with Ruby that has syntax like:
<% for post in @posts %>
Title: <%= post.title %>
<%= "(Today!)" if post.posted_on == Date.today %>
<% end %>
And for the more complex stuff, you off-load that to template helpers. It's obvious that templates shouldn't be chok full of scriplets, but the core case of conditions, iterations, and outputs are expertly handled by Ruby.
How do I change those supermagical database editing pages. He showed how to create a separate page, but what if i want to change the way it generates the db edit pages, just changing a few things or what not. How do I that, hmm, can I, hmm, hmm?
This is the beauty of scaffolding in Rails. It's not an all-or-nothing offer, but a buffet. You can choose to overwrite each individual controller action or template. So you start out by overwriting the list.rhtml template to do application specific listing while still relying on the scaffolded create and update actions. So you start with a complete wireframe and fill in the details bit by bit.
