Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks)

Posted Oct 16, 2006 22:42 UTC (Mon) by k8to (subscriber, #15413) [Link]

Without real rails experience, I'm going to guess.

Often, a tool that makes the simple cases magically simple is still worth it, because a good chunk of your web application consists of simple cases, while some portion is the fiddly bits you care about. Making the unimportant parts automatic can be a huge win, even if it doesn't seem impressive.

Posted Oct 16, 2006 23:07 UTC (Mon) by gravious (subscriber, #7662) [Link]

I am only just starting down the ruby road but let me tell you what I have learnt thus far.

As the article explains (and as the tutorials on the Rails site show) there is quite a bit of magic because rails infers the field names and table names from the names you give stuff in the ruby code - as they say "convention over configuration". And that's nice. I mean id generally is your primary key, is it not?

You are wrong about the web server requirement. Rails ships with a default web server to get you going quickly Webrick (written in Ruby) but it requires just a one line change to tell it to use Apache or (to name an up and coming candidate) Mongrel.

PHP is cool. I love it - Ruby on Rails is new. You are right to be sceptical as to it's long term maintainability, I guess we'll find out in the long term :) From what I can see Rails seems to have hit a sweet spot - it is probably inadvisable to call it a toy. Also the fact that prototype.js seems to have grown out of Rails is kudos enough in some ways give the evilness of Javascript.

{okay I confess - any language that turns literals into full blown objects, has inspired a poignant guide to itself, that has come from Japan, and has spawned the most left-field database driven web application framework out there is going to get my attention... live and let live huh, there's room for us all :) }

to.each { |there| there.own }

Anthony

Posted Oct 17, 2006 8:40 UTC (Tue) by tomsi (subscriber, #2306) [Link]

The deal with rails is to speed up development of certain a type of applications: those applications are web based and needs a database.

It contains a nice object/database wrapper called ActiveRecord, it uses to MVC pattern to make sure that your model and display stays separate, and it uses templates for presentation.

It has a "convention over configuration" philosophy. By shunning configruation files and forcing a specific way of creating database tables and field names, you get an application that is more self-documenting and easier to maintain (as there is only one way of doing things).

If this fits with your way of working and the problem you are trying to solve, it is great. And quick.

It is definitely worth a try.

Tom.

Posted Oct 17, 2006 11:41 UTC (Tue) by hummassa (subscriber, #307) [Link]

and the real deal is: starting is easy. with PHP or Mason, starting is
kind of difficult, putting more things is more difficult. With ruby,
starting is easy, putting more things becomes more difficult. That's it.

Posted Oct 18, 2006 17:35 UTC (Wed) by rfunk (subscriber, #4054) [Link]

Part of it is that Ruby is a much saner and more powerful language than
PHP. Part of it is that Rails encourages good web programming practices,
while PHP seems to encourage bad practices at every turn. Part of it is
that Rails makes the mundane tasks easy, letting you concentrate on the
interesting and unusual parts.

For small things our web dev shop still uses PHP, but all our large
projects are now being done with Rails. We're still learning, but after
working in Ruby/Rails for a while PHP is just too painful to deal with.

Oh yeah, and we're currently deploying them on virtual hosts with Apache
1.3 and fastcgi. Eventually we'll probably replace the fastcgi part with
Mongrel. Deployment is the biggest difficulty with Rails right now,
though there are other issues that are symptomatic of a young project.

Posted Oct 20, 2006 1:55 UTC (Fri) by kbob (guest, #1770) [Link]

One more opinion...

Ruby is just another scripting language. It's cleaner than Perl5 or TCL, and grottier than Python. Not especially great and not particularly broken. Ruby on Rails would have worked just as well if it had been called Perl on Poles or Pythons on a Plane. (-:

Rails has two main technical strengths: a surprisingly clean, well-thought-out architecture, and aggressive use of defaults and conventions to keep you from having to write boilerplate code.

Rails also has better marketing than any other web framework, and was lucky enough to be in the right place at the right time. A bunch of Java refugees found it and noticed that it sucks a lot less than the EJB stack.

Last year, I gave a Rails talk at the local LUG, and I presented a CD librarian sample app. It was about 15 lines of code, but it was fully functional. I dropped in a ~100 line CSS file and it was fully functional *and* attractive. (Well, geeky-attractive. I'm no designer.)

When a tutorial starts adding features, it may be more about showing more of Rails than because that stuff is needed. I haven't had to drop into raw SQL yet, though it's nice to know I can.

Rails comes with its own minimal webserver which is great for development, but it also plugs into Apache and other web servers. It can even be configured as a CGI script which is nearly universal.

Rails is not perfect by any means. ActiveRecord (the database abstraction) gets flaky when you combine advanced features. The page templates are just as easy to abuse as PHP. (Rails discourages putting application logic in the templates, but bad programmers are incorrigible.)

IMHO, Rails is a good framework. It's not the Second Coming, and it's not snake oil.