Rolling With Ruby On Rails

Bart Braem writes "The Ruby community is abuzz about Rails, a web application framework that makes database-backed apps dead simple. What's the fuss? Is it worth the hype? Curt Hibbs shows off Rails at ONLamp, building a simple application that even non-Rubyists can follow."

Nice framework...

[Anonymous Coward]

Looks good, nice to see some competition in the database backed web applications category for Java/PHP/Perl. However, I'm dubious about the claim that it's "ten times" faster than Java. It may be a bit faster, sure, but the amount of code doesn't look hugely less than what you might write to create a simple application using one of the many JSP/Servlet frameworks available.

Ruby still needs ISP support

[Anonymous Coward]

The biggest drawback to RubyOnRails is that you wont find it installed on very many webhosts.

I given it a testdrive, and RubyOnRails is an amazingly fast and powerful way to develop webapps, but even so, it's been around for a while and still 99% of webhosts only stick to tomcat & PHP/MySQL, so that's what I code for. Even Python w/o Rails has more ISP support.

My question is: When will RubyOnRails get "popular enough" to make inroads? I'm looking forward to it, because it means I can be way more productive and get a head start on all the other PHP "solution providers" out there.

Ruby On Rails

[ezmobius]

This framework is very nice. If your looking to get away from the sometimes mess of php web development, then this is a great choice. Ruby is a very expressive and powerful language that is very easy to read and code. And also very easy to make wrappers for c libraries. The rails framework does make it _very_ fast to develop MVC web apps with a small amount of intuitive code. And the rubyonrails mailing list is very active and friendly.

How does this compare to other stacks?

[darekana]

Any comparisons to Hibernate stacks, Struts, Zope3, CherryPy etc?

Re:Nice framework...

[Paradox]

Sir, may I ask you exactly how you're going to get your Java framework of choice to connect, comprehend, and dynamically bind to a SQL table in only 2 lines of code? Because that's what you're going to have to do to beat Rails in code count. For instance, if we have a table called "Clients". It has lots of fields.

If we want to link it to Rails, we'd use the following code:

class Client < ActiveRecord::Base
end

Yeah. That's really it. And you can specify relations with a simple micro-language in the class declaration (that's based out of ruby syntax). Once you've done this, you can write code like this:

my_client = Client.find( 26 ) # Find by primary key
my_client2 = Client.find_by_manager_id( 12 ) # Find by some field

# This code prints out each client's id and name
Client.find_all.each do |c|
puts "#{c.id}: #{c.name}
end

And Rails makes the action mappings just as simple. I'd eat my old shoes before I'd believe that there is some lurking JSP/Servlet framework that has evaded my sight (and everyone's sight, really) that can do better. I know Java's limitations pretty well.

Rails is awesome

[swimmar132]

I've almost finished developing a real estate site using it. First time using Rails.

In PHP or other related language, probably would've taken me about 80 hours or so to develop the site. In Rails, I've spent maybe 15 hours or so total on it. And I'm charging $8k for the site. Admittedly, that doesn't include time working on the graphics or design of the site, just the backend, search, etc.

So if you look at it from one perspective, I went from making $100 an hour to $533 an hour using Rails!

What about SCGI?

[Craig Ringer]

Personally, I'd like to see SCGI deployed more widely. Then we could drop the requirement for mod_<whatever_language_of_the_day> for many apps, and make it much easier to deploy frameworks and languages on hosting providers.

I've been really impressed with SCGI for my own work (a Quixote + Python based web app).

Re:Played with it

[rainman_bc]

Kind of off topic, but I still have a hard time wrapping my head around the idea of passing code blocks to functions... It's really a strange way of doing somethings IMO...

Not that it's bad, it's just an interesting programming paradigm, and one that would take some getting used to.

Rails seems like an interesting. Am I correct in think it's like mixing mod_ruby with an app framework?

Re:Rails is awesome

[swimmar132]

Considering that I've written less than 500 lines of code (not counting html or css), I'd guess pretty much anyone could get up to speed with it in less than a day, even with Rails experience.

Hell, I probably only spent two days studying Rails prior to creating the site.

For Python, CherryPy is another simple framework

[MarkWatson]

I played with Rails and liked it, but I am now trying to cut down on the number of programming languages that I use (trying hard to just use Java, Python, and Common Lisp) and even though it was fun working through a Ruby tutorial, I think that I am going to give Ruby a pass, at least for now.

For Python, I have been experimenting with CherryPy [cherrypy.org] which is a fairly low level web application framework, but is easy to use for publishing web services using XML-RPC, generating dynamic HTML (it does not have a template language but works with a few Python HTML template packages), etc.

Anyway, CherryPy "seems just about right" - light weight and easy to use - definitely does not have the capability of Rails though.

Re:Played with it

[raxx7]

# I don't know Ruby but I hope I understood your code correctly..

import MySQLdb as mysql

db = mysql.connect(db="test", user="testuser", passwd="testpasswd")

cursor = db.cursor()

print "inserting..."
for i in range(1,13):
songName = "Song #%d" % i
songLenght_s = str(10 * i)
cursor.execute('INSERT INTO simple01 (SongName, SongLength_s) VALUES (%(songName)s,%(songLength_s)s', vars())

print "Selecting..."
cursor.execute("SELECT * FROM simple01")
for row in cursor:
print row

print "Deleting"
cursor.execute("DELETE FROM simple01 WHERE internal_id > 10")

Re:But you're missing an important implication

[Tassach]

Your web app can be depolyed, and you can modify the tables. Need to add a new field? Just do it. You can also (on-the-fly) make new test actions to play with these parts of the database.

You call that a feature. I call that a symptom of an inherent design flaw.

The whole Ruby-on-Rails framework seems predicated on the idea that the application (and hence everyone on the internet) has unfettered access to the database. There's no way in HELL I'm granting an untrusted user (someone on the internet) permission to directly update or delete my tables. Hell, I don't even want them to be able to SELECT at will -- they get ONLY do what I explicitly tell them they can do. This is done via stored procedures.

If you care about your data AT ALL, you filter all user access through stored procedures. If the untrusted user account has no permissions to touch the tables directly, and only has execute permission on a limited set stored procedures, it's impossible for them to mount a successful SQL injection attack. Defense in depth is a Good Thing. Furthermore, stored procedures allow you to implement very fine-grained row- and column- level access constraints, and they allow you to do robust data integrety checks at the database layer, where they belong.

The phrase "stored procedure" doesn't even seem to be in the R-o-R developers' vocabulary [google.com]. This causes me to immediately discard it as a tool for serious work. It may be OK as a rapid prototyping tool, and it might be acceptable for a non-critical system which will only be exposed on an intranet, but I can't see it using it for any public-facing mission-critical system.

It looks like a nice toy, and perhaps even a useful one, but it's still a toy.

Re:Do you know what makes me laugh?

[Anonymous Coward]

I "sort of" agree with you.

Database expressions should be embedded in the language just like arithmetic is. I.e., we do:

x = y + 3

Rather than

x = MathServer.send("ADD %s to 3", y.value)

But the problem is that SQL SUCKS. It takes something mathematical (relational algebra) and turns it into weird semi-procedural code.

Instead of:

customers_with_orders = Customers JOIN Orders

we have

customer_with_orders = DB.fetch('SELECT * FROM
Customers INNER JOIN Orders
ON Customers.customer_id = Order.customer_id');

That shit makes me laugh. Who wants to embed that or even use it!

So when the day comes when we replace SQL with an actual relational language, I'll be happy to see it embedded in the language. Until then I'm content to HIDE that ugly junk.

Re:But you're missing an important implication

[Earlybird]

• The whole Ruby-on-Rails framework seems predicated on the idea that the application (and hence everyone on the internet) has unfettered access to the database.

Rails does not assume this. Rails only does what you let it; if you write data-reading code, the connection must have read access to the DB, and if your code updates the data, the connection must have write access.

You how structure and delegate this access is up to you.

• The phrase "stored procedure" doesn't even seem to be in the R-o-R developers' vocabulary. This causes me to immediately discard it as a tool for serious work.

Rails does not rely on stored procedures because the SP is not a relational construct -- it's an imperative language construct. Rails relies on relations, and it relies on introspection features in the database to automagically map tables to classes and rows to objects.

You can certainly invoke stored procs from Rails. While Rails abstracts data access, you still have direct access to the database if you need it. But this means bypassing the nice object-relational mapping sugar that makes Rails such a productive framework in the first place.

You could certainly extend Rails's mapper (which is called ActiveRecord) to let users specify the extra metadata needed to map stored procedure calls to objects.

And lastly, ActiveRecord is not required to use Rails. You could replace it with something equally simple; ActiveRecord is just 5,000 lines of Ruby code plus another 3,500 for the database adapters.

• It looks like a nice toy, and perhaps even a useful one, but it's still a toy.

I'm going to counter your arrogant, childishly intolerant trolling with a sensible counter-argument. It's a difference in philosophy -- monolithic database apps vs. distributed ones.

Some developers like to keep the database pure -- let the database worry about the data and provide a few basic operators to access and manipulate the data. Then on top of that you layer whatever data-management engine you want. These developers consider stored procedures a bit dirty because it couples the logic more tightly to the data, and introduces portability problems.

Of course, stored procedures have benefits, too, such as centralizing the core logic so that it can be accessed through the database CLI from any component in any language. That kind of model is powerful and useful, but is growing weaker as databases become increasingly loosely coupled.