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

Comments

Re:Python Version of RoR

[jellomizer]

It is always good to have two closly competing languages. Ruby and Python are so close in design it helps keep both on their toes. Some people consider Python and Perl to be competive but the language syntax is much more different, and often lead to more of a holy war debate on what is better. While I don't find this type of argument for Python vs. Ruby But I could just be looking in the wrong spots.

What is this?

[Lovesquid]

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.

Re:What is this?

[JamesOfTheDesert]

It's a collection of Java Best Practices rewritten in a 'cool' geeky language. Nothing new....

Quite true. For example, Java Best Practice #1 is to avoid using long, detailed XML files for configuration, and instead use the programming languge itself, which is dynamically loaded and interpreted when needed.

Another Java Best Practice is to let the framework write the tedious boilerplate code for you. For example, in Struts, you just run

% struts myAppName

and you're halfway done writing your Web application.

Here's one more Java Best Practice: Avoid expensive , complex application server software, and do rapid development using the Web server that is built into the standard library. Then deploy to the Web server of choice with no code changes or quirky vendor-specific API hacks.

Re:What is this?

[coldtone]

Halfway done?! You must be kidding!

Being a java web developer, and using struts to build 3 different applications I have to say that enough is enough.

Struts is a very simple web framework, which will do several things for you.
Dramatically increase the size of your app.
Limit the functionality of your app.
Makes the code hard to read and follow. Just about everything runs though the struts config file.

The only benefit I see with struts is that is provides some clean definitions for code. (A place for display, a place for validation, a place for the work to be done) And gives you some tags to help with internationalization. (Just help mind you, if you need to have a totally different layout for a different language then, well you're screwed.)

I would only use struts again if I was writing an application that was to be localized and translated, and was working on a large team. Otherwise a well written set of JSP's will get the job done faster and will be easier to read.

Re:What is this?

[tigeba]

Please correct me if this is a mis-characterization, but RoR replaces maintaining long detailed XML configuration files with maintaing long, detailed database specific sql files.

Using RoR, you create a table and let Ruby dynamically determine a bunch of information about relationships and data types and then you access various properties of this data. You are also forced to use RoR's Object model (You have to extend ActiveRecord, correct?)

Using something like Hibernate, you write an object, then do something do describe it (Java Annotations, XDoclet markup, tedious XML configuration file) and It can create the DDL/alter tables on the fly for you, and you are not forced to extend any object.

To me each approach seems to have merit, as well as inherent drawbacks.

Re:Python Version of RoR

[Colonel Panic]

Wouldn't that be PoR?

Seriously, though, I really think that Ruby the language is part of what makes RoR so great. I'm not sure you can do a lot of the same stuff in Python as you can with Ruby. Being able to define natural looking domain-specific languages using Ruby's code blocks seems like something that would be very difficult in Python. But as they say, imiation is the sincerest form of flattery...

Re:Python Version of RoR

[Simon]

Being able to define natural looking domain-specific languages using Ruby's code blocks seems like something that would be very difficult in Python.

Do you any examples of this in action? I mean a non-trivial example showing a Ruby block based solution for a problem that is clearly better than the more tradional (messy?) solution.

Impress me. :-)

--
Simon

Re:Any interesting projects?

[gavri]

And there's Odeo about which there was a New York Times Article

Frameworks closely tied to languages, WHY

[Tablizer]

Anyone who wants to post reasons for why I need to learn yet another language?

Indeed. Why can't somebody make a fairly language-neutral framework? Why are all the UI frameworks so tightly bound to specific languages and why do people accept that?

Things like data/field dictionaries, screen descriptions, UI widget attributes, and event handling frameworks don't need to be closely tied to specific languages because they are mostly declarative in nature, so why are they in practice?

It just does not seem very efficient to reinvent the wheel for each and every language. There about 100 languages in popular use. If we reinvent a web/ui/gui framework for each and every one, then we have spent 100 times the effort than need be. (Well, adaptors and sharing for similar langs may make it more like 50.) It would seem wiser to make one standard and do that one really well instead of do it 50 times poorly for each lang. We managed to divorce database usage from being language-specific. Time for UI also.

Shortcomings of Rails

[sean23007]

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.