Well, after flirting with the idea of learning Ruby on Rails for months, I’ve finally found a reason to actually dig into it. There’s an application I had in mind for personal use that involves recording data and presenting it in various reports, and I have some ideas of how it could be expanded to be useful to many users. Rather than write it in PHP or Java, I’m writing it in Rails.
Despite some silly mistakes, I got a very basic skeleton working in just a few hours of work. The data model right now consists of three tables, all of which are related, and I can now enter data and view it using the basic scaffold pages. I had to customize them to get the relationships working (for data entry), and the next step is to incorporate the relationships into reporting.
My first impressions are very good. I’m not sure how I’d describe Rails to a PHP user. To a Java user, I’d say that Rails is a combination of Struts, Hibernate, XDoclet, and AppFuse. Code generation is a huge part of Rails, as is reflection of the database structure through ActiveRecord.
The other most important feature of Rails is abstraction of most things that you’d use configuration files for in a Java framework. As long as you follow the conventions, you can skip configuration. I’m eager to find out what happens when those abstractions start to leak.
August 2, 2005 at 9:35 pm
How would you describe it to a Perl user?
August 3, 2005 at 12:25 am
I’m glad to hear you’re jumping in with both feet, Rafe! It really is the only way to grasp what Rails can do for yourself.
I was curious about your statement about code generation being a huge part. While there are generators that build skeletons of class files for controllers and models, there’s not really any actual code generation going on anywhere unless you mean scaffolding code (which is not really suitable for production use, in my opinion). Supplemental stuff like the login generator is an exception I suppose.
There is a lot of implicit dynamic code generation going on behind the scenes to supply the config-free ActiveRecord data abstraction. What little I’ve dug into the Rails source I’ve found mostly baffling because of this, not being a Ruby expert by any means. I get the gist of what’s going on, but the syntax escapes parseability for my feeble brain.
As for breaking naming conventions on the data side, I’ve not had any trouble. Rails lets you override just about every assumption it makes about the database schema, so I would bet that as long as your data stays relatively within standard relational bounds, you are in pretty good shape.
Uhh, sorry for the long comment, discussing the pros and cons of Rails really whips me into a verbal frenzy. (I’m of the pro persuasion if you hadn’t noticed.)
August 3, 2005 at 9:52 am
As far as Perl users go, I’m not sure how I’d describe it. (When I was doing Perl I just used CGI.pm and DBI for everything, and Ruby on Rails is a layer or two above that.)
As far as code generation goes, I didn’t mean that as an insult. I use code generators all over the place in the Java world — in my IDE, with XDoclet, and anywhere else I can get away with it. Code generation (like building the models and scaffolding with scripts) is what lets you get a basic Ruby on Rails application up and running in minutes instead of days. Once you’re through that, it’s up to you to make it into a real application rather than a scaffold, but having all the basic operations stubbed out is a massive time saver.