The "Ruby on Rails" thread

[trib767]

Does anyone out there use Ruby on Rails?

Love it, hate it, don't know what it is.... what's your view?

If there's a group of sensible "railsists" on here then perhaps we could share our experiences.

For those not in the know... Rails is a new and exciting web development framework built on the Ruby language.

[Nimetic]

Well I saw some nice presentations and stuff.

But I'm not sure what to make of it.

[ratbastid]

I'm in the middle of my first paid Rails gig right now. Took me a while to get my head around (as I've never used an MVC framework before), but now that I'm thinking Railsish (to say nothing of Rubyish), it's pretty awesome. Yesterday I built more features than I would in three or four days using PHP.

[Nimetic]

Is it really that good?

I mean... the framework thing.... I mean, I've seen a lot of frameworks come and go. Of course they tend to be vendor things.

I'm in DB programming by the way, I'm not a web developer (Oracle dev/DBA, BI, DW, ETL and so on). That's my context.

I'm thinking though, maybe I should give this a try.

[ratbastid]

What's great about Rails is two things. First, ActionRecord, which wraps the database and the relationships between database tables in objects.

To take the classic example of an e-commerce web site... You could list all the items a user has ordered with this code:

@user = current_user
@user.orders.each do |order|
  order.items.each do |item|
    puts "#{item.name}<br>\n";
   end 
end

Rails does all the data querying in the background. It's pretty magical, for those of us who have spent the last however many years hacking our chosen language (PHP and Perl in my case) to write valid SQL.

The second thing that's great about Rails is all the helper and support methods they provide. Imagine getting a date object with tomorrow's date in it from the code "1.day.from_now"! Amazing!

[trib767]

Originally Posted by Nimetic

Is it really that good?

In a word, YES

I'll admit there is a steep-ish learning with Ruby being syntacally quite different to those who grew up with C (and I think it's those that gravitate to PHP, like I did).

Once you grasp the ruby syntax it is really quite nice and the Rails framework on top of that is awesome. BY keeping "DRY", just so much gets done for you, for free!

My gripe is that the main books (the pragmatic one) doesn't have a great example of how to design a site that goes beyond a simple one page/one controller paradigm. I've ploughed through the learning and and it is now working well for me!

Also there are great plugins too - I've been using Markaby to write HTML code using Ruby and it is really cool!

[Nimetic]

On that last one though... I work in SQL and PLSQL mostly. So for me, tomorrow is simply today + 1.

ie

v_tomorrow := v_today + 1 (in PLSQL)

[bendsley]

You might search Digg.com for Rails and PHP. There is an article that was on there today about O'reilly going from PHP to Ruby on Rails in 2005. Now, they are going back to PHP. Good read.

[ratbastid]

Originally Posted by bendsley

You might search Digg.com for Rails and PHP. There is an article that was on there today about O'reilly going from PHP to Ruby on Rails in 2005. Now, they are going back to PHP. Good read.

It was interesting, but ultimately it highlights that large, legacy-heavy bespoke applications aren't a good match for ANY framework. Frameworks by definition make a lot of decisions for you. For very large applications with (god help the poor bastards) 95-table legacy databases... You're probably best off working from scratch.

[trache]

Was this Rails/PHP comparison the one from Slashdot et al regarding CDBaby?

If so, the article was very light on technical details. Not once did the author of the article expound the reasons /why/ he decided to move back to PHP, except to say:

- Rails didn't do what he thought it could
- He rewrote it in PHP so that it was compact and only what he needed

I have yet to find any articles from Jeremy Kemper, the gentlemen in charge of the main bulk of programming CDBaby. I do not know him in particular, except that I do know that he hacks on the Rails code itself and has contributed a lot to it.

With he being able to speak Rails and Ruby in his sleep, you would think that CDBaby would have been able to launch and perform well under the Rails framework - except that no one really knows the technical details of why the project was scrapped in favour of its ultimate incarnation in PHP.

Now, maybe Jeremy was smart, went above and beyond, and just got tired of having to fix everything to do what he wanted, or maybe the project manager just felt it wasn't working out? Either way, we will never know until some details surface. One comment on Slashdot says:

Different first-person perspective
(Score:0)
by Anonymous Coward on Sunday September 23, @12:37PM (#20719943)
(The post below provides insight into the situation. It was posted as a comment to the original blog. Another thing that comes out in the comments is that Derek has some serious issues that likely exacerbated the problems.)

I'm a little reluctant to add to the wasteland that is this post and these comments, but here goes.

I'm familiar with the situation here. The deal was this: Derek was not a programmer; he was a musician. He learned some PHP and cobbled together the old CDBaby site by himself. It was good.

Then, he heard about Rails, and became infatuated with it. He proceeded to attempt a rolling rewrite of CDBaby's frontend and backend both (the backend is large, because of inter-label and digital distribution stuff) in Rails.

At this time, Derek had no experience with the following things:

* any language other than PHP
* systems integration and interoperability
* Rails
* object-orientation
* the MVC pattern
* managing a development team

Project fails. All right. As he has learned in #2, legacy compatibility trumps everything. Also, ship early and often.

As you can see in Derek's post about MySQL encodings, he's not always the clearest thinker. Even above he says that REST means POST-only destruction, which misses the point entirely.

His team was fine (mostly just Jeremy, until another developer was hired in the last months). Rails was fine. But there were a lot of things wrong with the project plan ("rewrite everything, eventually") and with the project leader, who was convinced he had found a silver bullet.

No framework saves you from your own inexperience.

Out.

So who knows? Make your own decision.

At any rate, the thing you have to remember about Rails is that it is a framework. Frameworks are designed to allow programmers to build things quickly using the same background of assets. You've seen thousands of Movable Type, Wordpress, etc diaries, yes? You can think of those as mini-frameworks to build journals. They all look the same because they, in a small part, are frameworks themselves.

Frameworks are rigid. Some frameworks allow a great deal of flexibility, others don't. Rails allows you to override a lot of things, and build plugins from scratch if A) it doesn't allow it or B) the main Rails developers think it's a bad idea to put into the trunk. If it doesn't work the way you like, /contribute to it in some way/.

That being said, I am not a /strong/ programmer, although that is my background. You have to pick the tool that gets your work done efficiently - financially and expeditiously. If Rails works for you, great! If it doesn't, then either contribute to it, or find something else that will work for you.

I don't like PHP. Type "PHP sucks" into Google and you'll see why. Function declaration inconsistencies (think "needle, haystack" vs "haystack, needle") and the fact that OOP paradigm was bolted on as a gross after-thought. And this is coming from someone who got into PHP when PHP3 was /becoming/ the new guy in town. Now, I've never built an enterprise-grade ERP with dozens of table joins, temporary tables, HTML cache problems etc, so take the previous with a grain of salt. The design of the language just grated on me and I've since attempted to learn something different.

I have rebuilt my journal from PHP into Rails. Not having to worry about SQL injection, sessions, writing queries by hand and templating has really sped up the development of this little project. Again, it's nothing enterprise-grade (and I have no idea if it will scale, but it plays nicely so far!), however, it has really impressed me so far.

I would love to see any Rails projects built by anyone here. If anyone wants to trade tips, advice, or whatever, I'd be glad to help. Spill it - what do you like about Rails, hate about Rails (or other frameworks) and what cool things have you built?

[Halx]

I've looked at a lot of documentation for ruby. I've seen tons of examples that claim to explain what it is. They all use the same damn terminology that doesn't help me at all. WHAT THE FUCK IS RUBY ON RAILS?!?

[ratbastid]

It's rough, Hal, because until you get into an MVC framework and start messing with it, it's REALLY hard to explain. I decided to up and buy the Rails bible ("Agile Web Development with Rails") and leap in with both feet, and I've found it to be a VERY flexible and FAST-to-develop-with framework. MUCH faster than PHP or Perl, both of which I've acquired some expertise with in the last eight years.

Originally Posted by trache

I don't like PHP. Type "PHP sucks" into Google and you'll see why. Function declaration inconsistencies (think "needle, haystack" vs "haystack, needle")

Oh My God, you've so hit what I hate about PHP. Literally, unless you've go the docs right there with you, you can forget coding anything--because this string function might be spelled "string_doaction" or "strfdoaction" or "strDoAction".... God help us all. After working exclusively in PHP every day for over three years, I still only have memorized the proper spelling of a few dozen functions.

[trache]

Hal:

Ruby is just another programming language, like Perl or BASIC. It can do anything you put your mind to.

Rails, itself, is a totally separate package. With this package it allows you to create an application and separate the applications you develop into three distinct parts (let's focus on web applications):

- Model - think of this as "an object per table" (when using SQL). So you have a model, and you load it. What did you just do? You ran a SELECT query on that table to grab every attribute and store it in a OOP class. So you can do things like User.firstname = 'trache' and then user.save and boom, you've just run an UPDATE query on the table itself.

This also includes anything "business logic". Usernames not supposed to be greater than 20 characters? This stuff goes here. This ensures data integrity... up to a point.

- Views - These are templates. Think of PHP, only the Way It Was Meant To Be(tm). You know, when you're "supposed" to have an HTML file with HTML code, and then opening and closing PHP tags to print variables out when you want to?

- Controller - This is where all the action occurs. You hit a controller and it loads data (models). Then, once you've done your action (displayed a form, gathered input from the web and acted on it) you then work on your output. The controller spits out a view with the template you want using the data you want to put into it.

Wipe hands on pants.

Well, that's a simple way of me attempting to explain it. I know it gets complicated, and it may not be correct, but hopefully you get the gist.

Originally Posted by ratbastid

Oh My God, you've so hit what I hate about PHP. Literally, unless you've go the docs right there with you, you can forget coding anything--because this string function might be spelled "string_doaction" or "strfdoaction" or "strDoAction".... God help us all. After working exclusively in PHP every day for over three years, I still only have memorized the proper spelling of a few dozen functions.

Let's not forget to mention that the documentation that is supplied on php.net is a moving target. You would think that people would branch the documentation and LOCK it so no one can change it with each version. But, they change the way things work, break compatibility, and you're left to experiment to see what values you get returned to you when all you want to do is code your damned application.

Oh, and the fact that the code that is left by "programmers" underneath all the function documentation is very, very poor.

Oh my. Now I'm pissed off. Please, someone offer some Ruby advice/code/tutorials/sites/anything to make me calm down and get off my soap box.

[trib767]

Great posts Trache! Good to see this discussion heating up.

I've done the PHP thing, written apps got bogged down in SQL, etc. I've "played" with Rails and have a site in the development stages that is far in advance than my PHP efforts and in a fraction of the time.

And I truly believe what I have so far will be reusable. I can't say that for my PHP code.

I got into Rails by way of the Agile book and I followed the tutorial chapters to the letter. A great introduction and very fast. I then stepped off into my own ground as I tried to write my first app. This was a challenge - constantly in the index of the books, or on Google with questions. But I slowly came around to the Ruby language and the Rails way and I feel I am turning a corner. I will persevere with the app I am writing and see how I get on. But I have to say that, so far, Rails has been able to handle everything I have thrown at it. And so elegantly!

I'm all up for sharing hints and tips here

[trache]

I haven't written one SQL call and I've been able to create/update/delete data with templates that I like looking at.

I've been able to create a user system that I can take to other sites.

I would really like to make something larger than a journal/content management system, but I'm not sure what. A torrent tracker? I should see how well Rails would scale. :-)

[Halx]

Got any resources I can look at to try installing ruby/rails on a box and creating a few simple web applications?

[ratbastid]

I know you're like me, Halx--not a dead-tree kinda guy. But I've got to say, Agile Web Development with Rails is really the place to start. There's a tutorial that walks you through setting up a simple ecommerce site, then a very thorough walkthrough of every piece of rails functionality. "Agile" is to Rails as the Camel Book is to Perl.

It's here: http://www.amazon.com/Agile-Web-Deve...0816149&sr=8-1

As for learning Ruby itself, there are some good online intros (see http://www.poignantguide.com for the most amusing of them) You'll likely pick it up from the examples in "Agile". Ruby's funny because it almost looks more like configuration than code. The syntax is really simple. The hardest thing about it for me was remembering not to end lines with semicolons.

[trache]

Hal:

Please be aware that the Agile Web Development book may be slightly out of date. Having said that, if you do not want to purchase the book (which was good), go here:

http://wiki.awebfactory.com.ar/awebf...RailsTutorials

The author has created a wiki that follows the book, creating each chapter of the book with code step by step.

The only problem I had starting to code with Rails (despite the book) is to figure out what "controller" and "action" I wanted to start at (or in addition, have by default if none are defined on the URL). Do you have a "Home" controller that provides miscellaneous things like a splash page with an action of "index"?

Then you could have a "user" controller with the actions "signup", "login", "logout", "forgotpassword". Anyway, controllers are where its at (I think) to start getting down to actually making something people can navigate.

It takes a little bit of getting used to, but after the initial WTF, you'll fly.

I would suggest using the Aptana IDE (a large addon to the Eclipse IDE) found at http://www.aptana.com/ to edit your code. Make sure to also install Subclipse support to version your code. :-)

Now... if you want an environment to install to RUN the applications, you can try it out with an all-in-one package called InstantRails that will install Apache, Ruby, Rails and MySQL onto a Windows machine. it can be found at http://instantrails.rubyforge.org/wiki/wiki.pl .

[trib767]

You could also try Netbeans 6 which includes good support for Rails as well as Subversion.

Another nice thing about rails are the myriad of plugins and code generators that you can get to do a lot of the "framwork" coding for you.

After spending a while (my learning curve) writing a portal, I cam across "Goldberg" http://goldberg.240gl.org/. This looks cool, but I have not had time to try it yet. Now I've written my own portal I'll probably stick with it because I know how it works but for someone starting out Goldberg may give you the head-start...

Another useful thing I've found is ActiveScaffold http://activescaffold.com/ which also looks very useful.

[trache]

What is Goldberg? How does it help?

[trib767]

It looks to me like a generator that gives you the website infrastructure - user control, permissioning, admin, layout etc. I have not tried it yet but it seemed interesting from looking at the web site.

[avernus]

Anyone know Groovy on Grails? Don't know much about it yet but I'm going on a course on Monday... it seems to be a Ruby on Rails copy that compiles to Java bytecode. Is that a fair description?

[trib767]

So Avernus, how was the course? What is Groovy on Grails then?

[ratbastid]

Originally Posted by avernus

Anyone know Groovy on Grails? Don't know much about it yet but I'm going on a course on Monday... it seems to be a Ruby on Rails copy that compiles to Java bytecode. Is that a fair description?

I've never heard of Groovy on Grails, but that's an accurate description of the Jruby project.