Slashdot Mirror

RoR can not be successfully used with legacy databases that do not honor any kind of 'object' structure. I am not saying that Hibernate is any better, but you can not use RoR in this case, period.

Can you back this up? I think you're mistaken.
Antithesis

I've used rails in some small test cases with legacy databases. It's not as easy to set up but it's still easier than hibernate.

1. I don't believe your SOAP comment is correct. Remember, ROR doesn't provide SOAP per se; it's SOAP4R that does. ROR may provide basic SOAP4R capabilities, but that in no way means that it's using 100% of the features. The ROR team may have decided that the typical use of SOAP with a ROR site is likely to be 25% of the SOAP capabilities. You can *still* do the full SOAP support -- you just have to work a bit harder on it.

2. Yes, but J2EE is an overblown, overladen framework to begin with. When people need queueing and remoting technologies with ROR, it will be added. In fact, the remoting technology -- at least in part -- is already there through DRb (if you haven't looked at it, you should) and Florian Groß's breakpoints code. I would strongly disagree with your assertion that the J2EE components for these are "comprehensive" and especially "unified."

3. Again, you *can* do field name mapping, but it's a bit more work to do so. There's no reason you can't create aliases, e.g.:

def deg_f=(fahrenheit)
write_attribute("celsius", (fahrenheit - 32) * 9 / 5.0))
end

def deg_f
(read_attribute("celsius") * 5 / 9.0) + 32
end

See http://ar.rubyonrails.com/classes/ActiveRecord/Bas e.html for more information.

Field name mapping is easy; not as easy as simply following the Rails model, but it's *easy*. SOAP is a bit harder, and other stuff maybe a bit harder still. It's all still easier than trying to pick up all of J2EE.

-austin

Of course, you don't need me to tell you this, you could just check the documentation yourself.

C'mon, can you even pretend to look into things before you FUD them? There are plenty of valid criticisms for Rails, if you care to find them.

How did it start? Basecamp, a project-management tool by 37signals/Next Angle, was the original Rails application.

Man, there's so much wrong FUD being thrown around here, it's not even funny.

Rails DOES have caching. Rails CAN DO I18N. Rails can scale. Rails does have documentation (and a few books are coming out in a couple months).

http://manuals.rubyonrails.com/read/book/16 for how to use gettext with Rails.

Nice FUD... Except that its made up. Rails is very secure by default (uses pepared statements and things like this).

It does whatever it can do to make the framework part of the application secure and even offers a book on security on the hieraki bookshelf for the user side of things: Securing your Rails application .

This is a great example of rails quality documentation. have a look at the bookshelf itself: Hieraki bookshelf

And the application which powers it is open source (MIT) at www.hieraki.org

Nice FUD... Except that its made up. Rails is very secure by default (uses pepared statements and things like this).

It does whatever it can do to make the framework part of the application secure and even offers a book on security on the hieraki bookshelf for the user side of things: Securing your Rails application .

This is a great example of rails quality documentation. have a look at the bookshelf itself: Hieraki bookshelf

And the application which powers it is open source (MIT) at www.hieraki.org

There is no serious caching

No serrious transation capabilities

or messaging mechanisms.

hype and buzz.

Speed is a stupid mesure for web apps. There is nothing easier to scale then webapps in the world. You can cope with any amount of traffic by just throwing more hardware on the problem in a share nothing environment like php, perl or ruby/rails.

Whats interesting is the development speed and thats what the comparison between the java and the rails version highlighted well. For a great analysis look here: weblog

What makes the above link so special are the comments from the java community saying that the two examples are not functionally equivalent. This is really golden because they are really not. The rails version ( which is 3 lines of code ) does everything the java code does plus tons and tons of more things just by taking educated guesses after looking at the SQL schema.

Rails is a remarkable framework and a glimps of what programming will be like in the future. Yarv will just save some hardware costs

--
First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi

Since you have the luxury of not having locked yourself into a language, you have the ability to survey all the offerings out there, whether minority and up-and-coming, or well-known and entrenched.

After considering various languages to switch to for my scripting needs (ironically, it was prompted by the fact that PHP won't handle unsigned integers), I took a look at Python and Ruby and thus I would suggest taking a look at Ruby. I was one of those people turned off by Python's "significant indenting", and some other quirks. Ruby has a heck of a lot of niftiness beneath the surface.

Here is a ruby-gtk+ faq. I am currently studying Ruby on Rails myself, and lovin' it!

Not sure about scalabity and such, but RoR people like to go on about how small and elegant it is... If it's half as small and elegant as they claim, I guess it's scalable then =)

Basecamp is the slick pro site that was done in RoR. The Rails web site has a lot of other examples.

There are MVC frameworks for PHP (a random example I just googled), though I'm fairly certain they're nowhere near as elegant as RoR. phpMVC sure doesn't seem so elegant...

I was bugging my host to switch to PHP5, and then I recently discovered Ruby (and Rails), and am now bugging him to do that, since it is way more über than PHP, but there's even less of a chance of him going there anytime soon. =(

Ruby on Rails is where it's at now. There's a quote on that page that compares php to programming in assembly compared to using RoR.

Well that's a bunch of BS.

Rails isn't doing to drop your entire database. ActiveRecord reflects over the existing structure to provide a convenient object interface to your database. It doesn't modify the database schema.

In fact, I know of no place in the entire code that issues a DROP TABLE or the like. It's certainly possible to do smething like MyModelClassName.find_all.destroy, but that's to be expected. It's just doing what you tell it (similar to rm -r /).

If you don't believe me, you're welcome to examine the source.

I haven't read slashdot for a couple years now, and now I remember why. It's a sandpit of innaccurate claims.

The Rails is such a great showcase of Ruby it really got me interested in the langauge itself. In particular looking at their Object Relational mapping tool it's very impressive how easy it is express your mappings with very little effort. Have a look at this example and compare it to a typical set of java classes with Hibernate tags. Then in case of Hibernate you have the extra build steps with Ant to generate the hbm files and so on. Don't get me wrong I like Hibernate and use it every day but Hibernate must operate within Java's syntactic limitations. With Ruby there is so much more flexibility that helps Rails achieve much more simplicity and expresiveness.

Dave Thomas' new book "Agile Web Development With Rails" is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

One of the big problems with Ruby on Rails is that it is well documented, but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe book.

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

(Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)

Dave Thomas' new book "Agile Web Development With Rails" is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

One of the big problems with Ruby on Rails is that it is well documented, but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe book.

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

(Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)

Dave Thomas' new book "Agile Web Development With Rails" is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

One of the big problems with Ruby on Rails is that it is well documented, but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe book.

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

(Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)

Dave Thomas' new book "Agile Web Development With Rails" is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

One of the big problems with Ruby on Rails is that it is well documented, but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe book.

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

(Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)

Dave Thomas' new book "Agile Web Development With Rails" is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

One of the big problems with Ruby on Rails is that it is well documented, but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe book.

If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

(Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)

Another great resource is the Ruby on rails weblog which has links to more tutorials, job postings about rails, updates, etc., There's also an updated video tutorial on building a weblog.

Another great resource is the Ruby on rails weblog which has links to more tutorials, job postings about rails, updates, etc., There's also an updated video tutorial on building a weblog.

Whoa, where have you been?

Check out Ruby on Rails NOW .. before you get contaminated with PHP thinking.

You will be glad you did.

Coming from some work in PHP, I've been burying my head in Ruby lately, to much joy, and have also discovered Ruby on Rails, which was also featured in a recent Slashdot article. What I've seen is amazing so far (not to mention that Ruby code is so much more readable than PHP that it's not even funny). Just an FYI...

It is just that, if you aren't running Windows, you'll have to make a lot of adjustments in reading this article. Just a heads up.

Have you worked through this?

Three levels of caching: I implemented page, action, and fragment caching for the Action Pack in Rails so I could be able to use it in Ta-da. And it's working exceedingly well. Lots of pages went from 50-70 req/sec to 400-1100 req/sec due to caching.

That may also answer your PEAR::Cache deal (as I understand PEAR::Cache anyways). But Ruby doesn't need a framework to cache method calls. Making caching function calls is kind of a learning excercise. It's covered in the old, online version of Dave Thomas's "Programming Ruby" book. Specifically, in this chapter. Search for "class and module defintions" and read on. It's really quite interesting how easy it is.

I am not sure about SCGI, but FastCGI can be used for Ruby

In fact, Ruby on Rails seem to suggest using Webrick or mod_ruby for development, but then switching to FastCGI for production (and greater speed)

Last time Ruby on Rails came up, someone mentioned this example showing off their object-relational mapping. I observed then that it makes way too many queries because the SQL it produces isn't very good. (And too many queries means a lot of slowness, especially when your database server and your webserver aren't on the same machine.)

It's not as obvious here because all of the queries are behind the scenes, but I suspect the same sort of crappy SQL is driving this example.

There are a lot more demos on the Ruby On Rails Website, and it's documentation section.

You're a Zope fan, which means you're a Python fan. Probably the only language that can compete with Python on even terms is Ruby, and the languages are extremely similar.

I'd highly recommend you check it out. The language should be close enough to Python to learn in a day or two, and Rails is really powerful. It's different from Zope-no doubt about it-but that doesn't mean it's bad.

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

What a generic term.

Do you want to *code* web sites? Do you want to *draw* the pictures on web sites? Do you want to *lay out* web sites? Do you want to .. *design* web applications?

If you really want to make an impact as a "web designer", learn *usability*. This is what's really missing from web design these days.

And please avoid PHP and MySQL. Please don't flood the market with MORE half-assed code. "Everybody else uses it" isn't a good enough reason to learn it. In fact unless you really want to learn about data integrity and the relational model please just stay away from databases entirely.

However if you must, you can try ruby on rails as your first web framework. It will blow you away if all you're used to is PHP. But do try and learn what the purpose of a database is. It's not just a place for programmers to stuff objects.

Try and avoid buzzwords like XML or SOAP or whatever it is this week. Try and learn *simplicity*, *usability*, and *durability*. One thing you have to learn is HTML and CSS and Javascript, of course, because you don't have a choice with those.

I guess the one thing I'm trying to say is, please AIM HIGHER than 99% of all the other web designers out there.