Slashdot Mirror
Part 2 of Ruby on Rails Tutorial Online
An anonymous reader writes "Curt Hibbs has released Part 2 of his tutorial Rolling with Ruby on Rails to the O'Reilly ONLamp site. The first part was published in January. Topics covered are database transactions, callbacks, unit testing and caching." From the article: "In Rolling with Ruby on Rails, I barely scratched the surface of what you can do with Ruby on Rails. I didn't talk about data validation or database transactions, and I did not mention callbacks, unit testing, or caching. There was hardly a mention of the many helpers that Rails includes to make your life easier. I can't really do justice to all of these topics in the space of this article, but I will go into details on some of them and present a brief overview of the rest, with links to more detailed information."
http://subway.python-hosting.com
It's rough, but it's coming along.
Hmmm... nowhere in the summary does it tell what "Ruby on Rails" is, or why I should care about it, and with the server getting hammered, I can't RTFA to find out. How about including a 1-sentence summary of what the topic of any story IS before posting it, for those of us who don't already know everything there is to know about everything.
Has anyone actually done some interesting stuff that now works in a productive environment?
"A Rails web application can run under virtually any web server"
Now that really made me curious. Is that really true, tried, and tested? If so, we need another bunch of tutorials about how to use Rails under Tomcat, Apache, etc. There is no way this framework will replace existing Java frameworks, but using it for prototyping is promising.
To explain Ruby on Rails, I could say it is a highly integrated model-view-controller type web application framework. That would be like saying a Ferrari is a 4 wheeled internal combustion vehicle: true, but misses the point.
For more info, see RubyOnRails.com. An good alternative tutorial is at http://rails.homelinux.org/.
There are even better introductory materials coming. Dave Thomas (of Pragmatic Programmers) is working on a Rails book, chapters are being reviewed presently.
Rails is powerful an flexible. More importnatly, it's a lot of fun. If you are a programmer who want to enjoy web-based application development, please do take a look at Rails.
When the part one was published, I had severe problems getting Rails to work in Debian. There was a lot of really odd tools that needed to be installed and all that. Rails web page had tons of Ruby packages that I was pretty sure I didn't need...
But one thing has changed since then: Rails is now in Debian unstable!
As a guy who has written db-driven web apps in ASP, asp.net ( alittle), perl CGI, plain JSP/Servlet and j2ee app server with EJB's (both with and without a persistence framerwork/Object-relational bridge), I can tell you ROR is my favorite. I've only been using it for two weeks on a part-time project. It's ... beautiful. I can't think of any way to describe it. It. Just. Works.
And ruby is a really nice scripting language. You should check it out.
DO NOT DISTURB THE SE
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!)
Ruby on Rails Screencast
I have worked through the RoR tutorial and re-implemented a simple admin web app that I originally wrote for a customer using JSPs and Tomcat. I must say that what took me 4 hours to write using JSPs and JDBC took about 30 minutes using RoR.
A big advantage that Ruby and Python have over Java is that they are dynamic languages that makes it not too difficult to write a database wrapper class that dynamically looks at database/tables meta data and generates access methods on the fly. Java Tails (using XDoclet market tags) can't really compete.
I really love the full J2EE stack for developing large scalable web applications but I am now looking at alternatives for creating smaller systems much more quickly.
BTW, I really like RoR's templating scheme: much like JSPs in syntax (JSP non-XML syntax, that is) but do to Ruby's much terser notation for enumerating collections, the the templates tend to look a little cleaner.
For Python, I really like the light weight CherryPy web application framework. I plan on checking out Python Subway also when I have some time.
-Mark
I considered using Ruby on Rails for a large project I was doing, and found that though it was extremely easy to get started and do simple applications, it fails on more complicated databases. It does everything for you automatically, and you can easily write functions in Ruby that do the work of the database, but this is best only when the database isn't doing a whole lot itself except for holding data.
My database is in PostgreSQL, and uses a lot of dynamically named tables and schemas, as well as many trigger functions written in pl/pgsql. In order to get RoR to work, I found that I was going to have to edit the framework itself extensively, and would still be hampered by the slowness of Rails, which I found to be unforgivable.
I ended up having to design my own framework in Python, which can handle the most complicated databases without any more trouble than the simplest. The construction of the pages now takes a little more time than it did in Rails, but pages that used to take over a second to load are now instantaneous.
That said, I translated a small web app from Rails to my own framework, and the translation took less time than it did to write it in Rails in the first place and ran a lot faster, but that's because the design was done in Rails. I'd say that Rails is really good for prototyping small applications and getting them working really quickly, and then translating them to another framework for production becomes quite simple.
For non-trivial web applications, Rails has the problem of being optimized for ease of use, not for complete control. Note that I'm not trolling, or saying Rails has no use. Just that I found that it wasn't sufficiently capable for what I was trying to do with it.
Lack of eloquence does not denote lack of intelligence, though they often coincide.