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."

Comments

Interesting, but VB.NET is better

[Anonymous Coward]

Ruby doesn't have FlexGrid ocx which basically makes it useless for database apps.

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.

Re:Nice framework...

[leonmergen]

Besides, if you do things The Right Way, when programming in OOP, the design takes a huge part of your time... and I don't really see how Java or Ruby differ in that...

Re:Nice framework...

[Anonymous Coward]

Wow, you obviously haven't used Rails. It *IS* much faster than Java. Hell, anything is much faster than Java.

When you add something to Java (a new controller let's say), you have to configure it in a big XML file (with most if not all of the frameworks). Or a new template. Or a new model object. In rails you don't have to do any of that, it dynamically finds it! You literally *fly* in Rails (partly because of Rails, partly because of Ruby).

Re:Nice framework...

[tundog]

In rails you don't have to do any of that, it dynamically finds it!

Thats a great concept as long as everything goes as planned. But wait until it 'dynamically finds' the wrong thing. Try debugging that nightmare. (Think VB Script + Option Explicit).

Re:Nice framework...

[DevNull Ogre]

The "ten times" claim is about development time, not run time. You didn't take it a step further, you took an orthogonal leap.

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.

Re:Nice framework...

[Jerf]

I'm actually a Python partisan (like the philosophy and user base better), but the same basic thing applies to Ruby too: If your first criterion for evaluating a tech like this is "Is it written in Java/C++/Visual Basic?" or whatever other legacy language you're thinking of, you've already lost.

Learning Python or Ruby and using it will pay off in mere weeks vs. Java, C++, Visual Basic, and most other things like that. Pay off might be a month for C#, but only if you use C# like an expert to start with. (Also, if you use C++ like a mega-expert, but even then, to use it that way you lose with the staggering quantity of typing that takes... and I mean keypresses, not object typing!)

Ruby and Python have done everything they can short of directly downloading themselves into your brain. You have to expect to exert some effort to reap the benefits. And like I said, it pays off in mere weeks, so opportunity-cost-wise, you lose big for delaying it.

(Note "you" here may be your company, if you only program professionally. In that case, you personally may not have any choice, but the company is still losing big.)

Re:Nice framework...

[Jerry]

Learning Python or Ruby and using it will pay off in mere weeks vs. Java,

That is my experience, too.

I attempted to build an inhouse app using Java and JDev against PostgreSQL. Where I needed to add functionality always ended up in a method which included the phrase "Generated DO NOT EDIT". I spent six months learning Java (including a class, which emphasized text editors for making gui objects. Gui by the blind ???) and attempting to build the inhouse app. I gave up in frustration.

I decided to try Python and use Boa_Constructor against PostgreSQL. Ten weeks after I began I had learned both Python and Boa_Constructor, and had competed the app. It was 10X faster than the Java app against the same database, had all the features I had wanted to use, including reports, was easier to maintain, and MUCH easier to deploy.

I liked the fact that ALL the files in your Python/Boa project are ASCII files and Subversion does an excellent job of version control on them. Also, the apps looks and feels the same on Linux as it does on Windows, and I had to change less than a dozen lines to make it so.

Re:Nice framework...

[JamesOfTheDesert]

Besides, if you do things The Right Way, when programming in OOP, the design takes a huge part of your time... and I don't really see how Java or Ruby differ in that...

Um, yes and no. If your point is that there is a certain amount of abstract thinking required before you write any code, then yes, they will share a comon process. But, after coding in a language for a while, you tend to start thinking in the terms and abstractions the language facilitates.

So, in perhaps the common case, Java designers will soon be thinking in terms of factories and adaptors and filters and all sort of entities that are often required in Java but which are extraneous in an agile language.

And the time spent on those extranous objects is not time spent adressing the actual problem, but time wasted working around or through the demands of Java.

Re:Nice framework...

[MightyMartian]

Hoo boy! He're we go. Another shot across the bow in the never ending OOP Wars of Religious Supremacy. Back away ten paces, ready your Smalltalk and C++ code and come out firing.

Played with it

[tenchiken]

And did a quick application with Ruby on Rails already. If you are confortable with Perl, you may find this easier to deal with then Python and it's love of whitespace. The object model is much more developed then either python or perl, but it still retains much of the flexability of the other two systems.

Ruby has already inspired a few efforts to duplicate the technology in Java and in .NET. Since the core technology behind RoR is open classes, and the ability to add accessors and functionality on the fly, the other languages just don't cut it.

The usual warnings apply. Implicit code is easier 90% of the time, but that other 10% is painful to debug. With large projects you can prototype fast, but maintaining may be much more difficult.

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:Played with it

[Merk]

Once you get used to the idea of passing blocks of code around, you'll love it, and won't be able to go back to Python... er... I mean, won't be able to go without it.

The canonical example is the iterator. Given an array pets containing ["dog", "cat", "fish"]:

pets.each { |pet| puts pet }

Will return
dog
cat
fish
If you want to print out the uppercase versions

pets.each { |pet| puts pet.upcase }

Or if you want to add some text:

pets.each { |pet| puts "I love my pet #{pet}" }

Big deal, right? Not much different from a for loop. But blocks are amazing when dealing with things like a database. You can put all the setup, teardown and error-handling code in a method that's hidden from the user, and all they have to do is pass in the block they want the DB object to execute:

require 'dbi'

DBI.connect('DBI:Mysql:test', 'testuser', 'testpwd') do | dbh |

puts "inserting..."
sql = "insert into simple01 (SongName, SongLength_s) VALUES (?, ?)"
dbh.prepare(sql) do | sth |
1.upto(13) { |i| sth.execute("Song #{i}", "#{i*10}") }
end

puts "selecting..."
dbh.select_all('select * from simple01') do | row |
p row
end

puts "deleting..."
dbh.do('delete from simple01 where internal_id > 10')

end

Unfortunately, slashdot eats my indentation, but fortunately, Ruby not being as picky about whitespace as *some languages*, that doesn't matter. Note that all that code is wrapped in a DBI.connect() call, which connects before it starts executing the block, and disconnects after. There's no "close" call required, it's all wrapped up for you.

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")

Useful Ruby Online Resources (categorized)

[Anonymous Coward]

A categorized collection of ruby links can be found here in a nicer format:

http://www.rubygarden.org/ruby?RubyOnTheNet

Interactive ruby resources:

irc://irc.freenode.net/ruby-lang - the #ruby-lang channel is popular. More info at RubyOnIRC

http://www.ruby-forum.org/bb/ - a forum for ruby novices to ask questions

news://comp.lang.ruby - the ruby newsgroup

Ruby websites:

http://www.ruby-lang.org/ - ruby home

http://www.ruby-doc.org/ - ruby docs and online reference

http://www.rubyforge.org/ - rubyforge ruby projects

http://raa.ruby-lang.org/ - ruby application archive

Ruby Code Examples and Snippets:

http://pleac.sourceforge.net/pleac_ruby/ - ruby pleac

http://www.rubygarden.org/ruby?RubyOnlineCookboo k - ruby cookbook

Popular ruby and ruby-related projects:

http://rubyinstaller.rubyforge.org/wiki/wiki.pl - ruby installer for Windows

http://rubyforge.org/projects/rubygems/ - rubygems ruby package manager

http://www.yaml.org/ - ruby 1.8 includes built-in yaml support

http://www.rubyonrails.com/ - web framework in ruby

http://rubyforge.org/projects/instiki/ - wiki in ruby

Re:Useful Ruby Online Resources (categorized)

[geoffspear]

Thanks. That should help if google gets slashdotted and we can't find information on our own.

Code, Snort, Code, Snort

[MrAsstastic]

Back where I am from, using rails all night to code a project can land you in trouble with the law, drain you financially and mentally, and leave you with a nosebleed. Best stay away from this nonsense.

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.

Re:Ruby still needs ISP support

[Aredridel]

http://theinternetco.net/offers/ruby

Ready, installed, and waiting.

Re:Ruby still needs ISP support

[JackRuby43]

so does Modwest (a great host and supporter of Open Source)

http://www.modwest.com/

Re:Ruby still needs ISP support

[swimmar132]

And, if you get hosting at TextDrive, they'll give half of your money to supporting RubyonRails development!

Re:Ruby still needs ISP support

[JimRay]

You might try TextDrive

Fantastic tech support, lots of support for opensource projects, a full ruby on rails implementation. These cats kick ass.

Lurk on the forums for a day or so to get a feel for things, it's not a bad place to call ~/

Re:Ruby still needs ISP support

[poboxbot]

True and true.

There's one host that looks promising: http://www.textdrive.com/ -- It's run by Dean Allen (wrote TextPattern), David Heinemeier Hansson (wrote Rails), Matt Mullenweg (wrote WordPress), among others.

Not astroturfing -- I co-lo elsewhere, and almost wish I was willing to do the virtual host thing again to try it out.

Re:Ruby still needs ISP support

[badboy_tw2002]

I saw that, and the philosophy of giving half their income back to the project is _awesome_. What a way to fund an OSS project, and especially cool in this case because they can convert people (like me) with websites for small clubs or groups that would like to try Rails but don't have an ISP that can do it. One question about all this though, how long has the company been around? Are they kind of fly by night? I could see a real nightmere if they collapsed and you were left swinging without any place to run your webapp.

Re:Ruby

[ggvaidya]

That's actually "-1, Redundant", but as of right now, your post is precisely at "1, Redundant"! Good call! :D

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.

Re:Ruby

[ReeprFlame]

Figured that may be the case. Rubies and Perls are all gems!

It's just a pity

[Metteyya]

I like Ruby, even before I got to know Rails. The only thing I regret is that LAMR sounds really bad.

I develop webpages with LAMR - imagine saying something like that ;).

Re:It's just a pity

[legirons]

"imagine saying I develop webpages with LAMR ;)"

The alternative being serious, professional names like Plone, Drupal, and Zope?

Re:Good for "recipe" queries but little else

[Minam]

You might want to tell that to Basecamp, 43 Things, and Tada Lists, since they obviously have no idea that Rails isn't good for anything of that magnitude. Might also mention it to all the thousands of people that use those sites, daily, and to the handful of developers who built and deployed those sites in a fraction of the time and cost of other web solutions.

Then again, maybe you shouldn't...

Rails is just the tip of the iceberg

[Paradox]

Rails is an incredibly good framework for Ruby, that really shows off its power and makes it easy to get a web application going, but it's not all that Ruby has to offer.

Ruby is full of incredible libraries and frameworks like this, especially where text processing and web development are concerned. It's because Ruby has such a rich set of features.

Anyone who likes Rails should dig deeper. Heck, Ruby's standard library comes with some amazing things. Ruby also has a framework called RubyGems,
which is very much like Perl's CPAN integration or CommonLisp's ASDF framework.

But... But... There's IIS!

[MooseByte]

"If you are using Windows though, looks like this could be very useful."

Only if it can match the stability and security of IIS that we've come to depend on. Otherwise it's just another shoddy product built by communists for communists.

Have you ever programmed a web app before?

[Paradox]

Well, most of the article is setup. But I do agree the article is less than a stunning demo of rails. Instead, you might want to fire up the video at www.rubyonrails.com which walks you through a 10 minute application build.

It's extremely cool to watch someone set up a working webapp that fast.

But I have to take issue with:

Take a look at this example. It's incrediblyl complicated and all it does is display a horrible little form that lets you query cookbook recipies!

Half of the darn article is setting up MySql and installing Ruby and Rails from scratch on a windows machine. Do you have any idea how much harder this crap is to write in other frameworks? You'd have to write at least 2x as much code. No one has an Active Record class as good as Rails'. You'd double the code count just doing the SQL linkage!

It's one thing to be unimpressed, but it's another to know jack shit about the domain and say it's all worthless. Anyone who's ever made a web application will appreciate it.

Re:Have you ever programmed a web app before?

[draven]

Dude.
That's just not true. Class::DBI lets you set up your application just as easily as Active Record. Try looking at some Maypole application examples to get a clue.

Re:Good for "recipe" queries but little else

[Tobias Luetke]

This is not insightful. If you want to see how well it scales look all all the production grade applications out there. The source to hieraki is freely accessible.

Rails is NOT your run the mill proof of concept framework. Its the next level of programming environment right now and here. Available for you to download under MIT license. The people who use it make applications magnitudes faster than the people who aren't. Single people can be as productive as whole teams.

There hasn't been an improvement in productivity like this in recent programming-history.

And don't just put down what you don't understand, give it a try.

Your attitude will just get you boring jobs.

How does this compare to other stacks?

[darekana]

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

Re:How does this compare to other stacks?

[dash2]

or indeed Maypole?

Re:Okay, so what else does it do?

[swimmar132]

Perhaps the documentation for ActiveRecord will help answer your question?

http://ar.rubyonrails.org/

You can automatically retrieve data from the database in the form of an object, do manipulations or calculations, display it, modify it, then do a save() method on the object and it'll go right back into the database.

Re:Good for "recipe" queries but little else

[Minam]

Consider Hieraki, or RForum, or any of the other projects listed at the bottom of The Ruby-on-Rails docs page.

FlexGrid?

[ackthpt]

Ruby doesn't have FlexGrid ocx which basically makes it useless for database apps.

FlexGrid? FLEXGRID?!?!

Implementation of FlexGrids is responsible for extreme stress, male pattern baldness, genital warts, dry heaves, infertility, webbed toes, seeing spots, loss of super powers, carpal tunnel syndrome, diarrhea, dandruff, dispepsia, gas, fingernail rot, yellowy wax buildup, stink foot, Plantars warts, incontinence, communism, crusty boogers, arthritis, bursitis and and cooties. The only treatment is 500mg of Dammitol, fiftytwo times a day.

You, sir, are a maniac.

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!

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.

Re:Rails is awesome

[Anonymous Coward]

Oh please, not this fallacy. Just put an ad out for a Ruby programmer. Do you really think there are only about 5 or 6 in the world or something?

And what makes you think Java or PHP or whatever is magically maintainable because the language is familiar? It takes me at least a week to get comfortable with another developer's layout, structure, conventions, etc. It might as well be a different language anyway.

Besides, any good programmer could learn Ruby in a weekend. It's a *simple* language.

It's not so bad, Rails is unit tested very well

[Paradox]

Firstly, Rails's ActiveRecord class is very simple Ruby code, so it's naturally bug-resistant.

Secondly, the author knows that ActiveRecord could be a source of problems, which is why it's got dozens of unit tests, covering nearly every line of code.

Thirdly, even with all that bugs can and will sneak through, which is why ActiveRecord can, upon command, write a detailed log of its attempt to dynamically bind and create the classes you want. The logging is at the message-passing level of Ruby, which is nearly as atomic as you can get (you could hack the interpreter to go further, but that'd be pointless).

The dark ages of hideous bugs in dynamic code are gone my friend. We have the tools and techniques to make code of this type both safe and maintainable. Don't be afraid of it.

What about SCGI?

[Craig Ringer]

Personally, I'd like to see SCGI deployed more widely. Then we could drop the requirement for mod_ 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).

Empire Builder?

[ackthpt]

Thats interesting. Never heard of Ruby before but it seems very useful especially with the DB integration.

Rabid Empire Builder (and Euro Rails, British Rails, Russian Rails, Iron Dragon, Lunar Rails, India Rails, Australia Rails, Nippon Rails, etc.) fan that I am, I saw the title and thought immediately that Ruby Rails was the next game from MayFair which would somehow bridge programming and empire building at the same time. Alas..

you rolled a 1, ha!, didn't compile!

One Click Instalation

[davi_slashdot]

1. Download the latest One-Click Ruby Installer for Windows (shown in Figure 1). As of this writing, the latest is ruby182-14.exe).
2. Double-click on the downloaded executable and follow the installation instructions. Unless you have some special needs, just press Enter to accept all of the defaults.

Believe me guys, no hype at all :-).

TMTOWDI

[ryantate]

Perl has its own rapid application development framework, Maypole. Here are some screenshots from a Perl.com article where Simon Cozens sets up an online sales catalog in 11 lines of code. (Here's a followup article, and the Maypole home page.)

These systems all demo well because the developer gets to decide what functionality to demo, and it not coincidentally happens to be the functionality the framework was designed to easily support. The real test of the system comes when you want to do something the designer did not anticipate, and you find out how flexible the system is and how sensible the designer's instincts are.

With these environments I think time will tell, with most developers watching the few willing to take the risk of investing the time needed to learn the framework and how to customize it extensively.

Real-life applications launched on the Rails

[Webster132]

Ruby on Rails is growing at an astounding rate right now, which is not at least due to the growing number of real-life applications that has been build upon it. Including:

Basecamp -- The original Rails application from which the framework was extracted. A hosted project management application that combines weblog, todo lists, milestones, file storage, and more to keep everyone on the same page in a project.

43 Things -- The "What do you want to do with your life?" application that lets you enter the 43 things that you're currently looking to achieve in life. You can blog about doing it, find others doing the same, and give advice to people who are doing things you've done.

Ta-da List -- The todo list component of Basecamp factored out into a free mini application. Uses XMLHttpRequest and other JS techniques to keep the interface super snappy. Sharable todo lists for every occasion.

And those are just a small sample of all the public applications out there on Rails. On top of that, there's a wide range of e-commerce, content management, business intelligence, intranet systems, and more being build inside a lot of organizations.

Exciting times!

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 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.

Development time

[cardmagic]

I originally built Web Collaborator in 8,000 lines of PHP over a couple of months. In about 16 hours, I had completely rebuilt it from scratch in the Ruby on Rails framework with 1,000 lines of code.

I have since created sites like The Conjuring Cabaret and S5 Presents, both with astonishing simplicity and rapid development. Rails gives me short-cuts for almost everything I ever want to do with web development.

Re:Do you know what makes me laugh?

[swimmar132]

Writing SQL statements smack dab in the middle of one's code is generally a bad thing. You want to get the code that talks to the database separated out from the rest of the application.

Re:Do you know what makes me laugh?

[Paradox]

Well, Rails does lots of things behind the scenes. A simple piece of code like this Object-Relational-Mapping statement:

class Column < ActiveRecord::Base
end

does at the very least, the following:

1. Pluralizes "Column" into "Columns"
2. Finds the table "Columns" and requests its schema.
3. Maps every column into methods.
4. Provides logging for all SQL sent, all actions undertaken, and also allows for use of the ruby debugger on otherwise external ops
5. Provides search and iteration methods that you'd otherwise have to write on your own
6. Caches data for performance

That's an awful lot of bang for your buck with just 2 lines, especially now that it's loggable and debuggable. I'd say that alone makes it better than inlined SQL.

Is that your python reimplementation?

[Merk]

If so, it seems to leave the db handle, and the cursor handle dangling. That was the main point I was making, is that when wrapped in a block, these things are cleaned up for you when you're done. Other than that though, this is basically a good Python translation of what the Ruby code was doing (although the Ruby version is database-independent, I imagine Python also has a DB abstraction layer).

Btw, how'd you get the indentation right? Manually inserting &nbsp; entities?

Re:Do you know what makes me laugh?

[raxx7]

PostgreSQL at least does.

Anyway, SQL embebbed in Python/Perl/Ruby is so simple there's nothing to gain from a SQL precompiler except static checking.

Nope.

[Paradox]

Not necessary.

Besides, Ruby doesn't have real continuations. Their continuations are based of longjmp() C call, so it has some limitations that real continuations don't have.

Re:Offtopic - Ruby

[Paradox]

Ruby has an amazing community, almost everything you could want is online.

Check out www.rubycentral.org, which has an online ruby book (for 1.6, but it's a place to start). It will take you to all the other sites.

I highly recommend getting in on the mailing list, ruby-talk. It's very interesting.

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. 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.

weird directory structure

[drew]

i've tried rails a little bit, and jsp before that, and wasn't particularly impressed with either. is there a reason all web frameworks require a weird directory structure? rails seems better then jsp because it doesn't require an arcane descriptor file, but it still requires you to use a funky directory structure, which means the structure of your application doesn't seem to correspond in any meaningful way with your web site structure.

why can't someone build a decent framework that follows the simple "directories are directories and files are pages" model used by asp, php, cgi, etc.

and what's with the database naming conventions? the author kind of brushes it off at the end with this statement: "Even if you have to use a legacy database that does not use the Rails naming conventions, you don't have to give up the productivity advantages of using Rails--there is still a way to tell Rails explicitly what table and column names to use." personally I would not use those conventions no matter what database i was using, nor would any decent database developer or administrator i have ever known.

at any rate, at work i program in whatever language they tell me- currently asp+jscript, before that php. for personal projects, my current favorite is perl's HTML::Mason. all the benefits of php (and then some) without the awful language conventions.

Re:weird directory structure

[andreas1245432]

It doesn't prevent you from mixing static with dynamic content. You can put any kind of static files in the "public" directory, which is the document root for the server. Only when a request cannot be satisfied directly from the document root it is forwarded to Rails (with mod_rewrite); Rails then extracts the information which controller/action is responsible for handling the request from the URL. For example if you request "/forum/list" from the server and there isn't a file with this name in the "public" dir, Rails calls the action "list" in the controller "forum". (The template file for this controller would be in "/app/views/forum/list", but you can easily override the template path, render a template from the database, return plain text, the content from a file or redirect to another page.)

This also offers some nice possibilities for caching: save the result from the dynamic "/forum/list" request to a file called "/forum/list" in the "public" directory, and the web server won't bother Rails with this request at all, but will deliver the file directly. If the list content is expired, delete and recreate the file. Rails also provides methods to automate this.

I suggest you just try the tutorial; I'm sure you will find that Rails is extremely flexible and doesn't set any limits to your development style.

Re:Offtopic - Ruby

[objo]

Dave Thomas' Programming Ruby book - aka "The PickAxe" is all you will need. He just released the second version of the book and it will be enough to do anything you want. rubyforge.net is also a great are for projects.

Re:There's that bloody MVC again

[swimmar132]

In Rails, the model is responsible for getting/putting data from/to the database and creating objects used by the controller.

The controller is responsible for manipulating the objects from the model.

The view is used to display controller data and to send user data back to the controller.

It works very well.

Re:class Client ActiveRecord::Base

[supavillain]

You can overwrite the default database connection method in individual classes.

From http://rails.rubyonrails.com:

"Connection to multiple databases in different models

Connections are usually created through ActiveRecord::Base.establish_connection and retrieved by ActiveRecord::Base.connection. All classes inheriting from ActiveRecord::Base will use this connection. But you can also set a class-specific connection. For example, if Course is a ActiveRecord::Base, but resides in a different database you can just say Course.establish_connection and Course *and all its subclasses* will use this connection instead.

This feature is implemented by keeping a connection pool in ActiveRecord::Base that is a Hash indexed by the class. If a connection is requested, the retrieve_connection method will go up the class-hierarchy until a connection is found in the connection pool."

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.