Types of apps to use Rails for?

rubyonrails-talk
1

I am a web developer using PHP and very limited JavaScript. I keep hearing about RoR and am interested in learning it, but before I make the jump I'd like to hear about the types of applications I should be using it for.

On all the tutorials you see big apps like stores, social networking, shopping carts, etc. I don't have any immediate plans to be building something that complex. Here are some examples of apps I *do* use on my sites:

-- Having a menu display on a restaurant website

-- On a band website, allowing members to make schedule adds/changes

-- Also on a band website, displaying a song list and allowing users to sort it

-- Interactive contact forms and "Request a Quote" forms

-- On an artist's site, displaying a portfolio or slideshow of work

I don't currently make real use of any OO language, but I feel that to be a well-rounded and respected web developer, I should learn one. In a previous job I was forced to learn .NET, and I disliked it so much that I don't want to ever see it again. I've also tried out Flex but I find the costs associated with owning and maintaining the software to be prohibitive right now.

All that in mind, can anyone point me in some direction as to whether it's worth it to me to learn Ruby vs. sticking to some PHP framework? Greatly appreciate any opinions!!

2

Sara Me wrote:

-- Having a menu display on a restaurant website

-- On a band website, allowing members to make schedule adds/changes

-- Also on a band website, displaying a song list and allowing users to sort it

-- Interactive contact forms and "Request a Quote" forms

-- On an artist's site, displaying a portfolio or slideshow of work

Any RoR developer here could write those sites in 30% of the time and 10% of the source code as anyone using a .NET or Java system.

PhP is probably the close second there, with MVC systems now available...

Next, because we use super-lean code and wall-to-wall unit tests, our projects do not "decay" over time. Attempting to rapidly develop in .NET, for example, will lead to tangled code that's hard to improve. Eventually new features get more and more expensive to add. Agile projects such as Rails hold their value indefinitely.

3

Sara,

First let me say that you've come to the right place. Any list of this nature has it's pros and cons, but overall I've had a great experience with this group.

Now a little bit about me. I've run the gambit of development projects from small local clients to large, dare I say HUGE, multi-year, enterprise applications using the heaviest sledge-hammer development toolkits you'd ever hope to find.

In fact I'm currently waist deep in Oracle ADF/FACES. If you're not familiar with that, think .NET x 10 in complexity and size. Apparently Oracle couldn't decide what camp to go with: Struts, Spring, Hibernate, Java Server FACES, etc, etc... So they just decided to throw all of those into their environment, along with their own framework they call ADF (their implementation of FACES components).

Here is my personal take on Oracle ADF: If you could imagine a group of relational database system engineers that set out to build a development environment with the goal of supporting the development workflow of systems like Oracle FORMS. That is what ADF is.

Now take ActiveRecord (Rails model object). A common thing you might want to do with a database table would be to find all the records in it right? So how do you do that with ActiveRecord? Ok say you have a Person class. Since this would be a sub-class of ActiveRecord. You could do the following:

@people = Person.find(:all)

But, there's NO WAY it can be that simple right? Well actually it is that simple in Rails.

So how does that compare to Oracle ADF. Well first of all, don't even think about sending a find message to a single object and have it do the logical thing of returning you the rows of the database table. First you would need to get an instance of the ApplicationModule that connects to your database. With that object in hand you can search within that module to get an instance of a ViewObject, which acts very much like a database view. This in turn has an XML configuration file that links things back to an EntityObject, which represents a database table, again configured using another XML configuration file used to map object attributes to database columns.

Ok after all this setup you can then ask the ViewObject to get the rows of the table right? Wrong! You also need a DBTransaction object, a ResultSet object, a ResultSetIterator object so you can walk though and collect objects from the ResultSet. I may be leaving out a few steps here (read "a lot of steps"), but you get the general idea.

Then don't forget to release your ApplicationModule or things get really screwed up. Now keep in mind that you get to repeat this entire process every time you want something from the database.

But, what if you don't want all of the records in the table? In Rails you would do the logical thing, as follows:

@people = Person.find(:all, :conditions => { "fist_name = ? and age < ?", [ "Bob", 18 ] }) // find all the under age 18 Bobs

And now for the Oracle ADF version...... Hell, let's not even go there! But, it has something to do with ViewCriteria objects..... AHHG! @!

P.S. In case you only wanted the first under 18 Bob. Just do this:

@person = Person.find(:first, conditions => { "fist_name = ? and age < ?", [ "Bob", 18 ] }) // find the first under age 18 Bob

This is only a tiny, tiny morsel of what Rails is all about, but I hope it wets you appetite for more.

All that in mind, can anyone point me in some direction as to whether it's worth it to me to learn Ruby vs. sticking to some PHP framework?

P.P.S. As a developer you don't even need to ask this question. The more you know, the more valuable you are, and the more choices you have. Studying how other tools solve really tough problems will give you insight into everything you do. As a developer you need to be a sponge. Soak up every last bit of knowledge your brain can hold. I've been a practicing software developer for 15+ years professionally and close to 25 years personally. I learn something new every day. What I've come to really appreciate is the younger people just getting into programming. These guys, and gals, amaze me. I think that's because they haven't been corrupted by years of programming. Someone new to the game will try anything. Since they don't realize that it's impossible, they just go ahead and do it!

My current favorite comment to a blog post I read recently: "You less-code fanatics! Soon you will be writing so much less code that it will converge on 0 lines proving that your so-called productivity is an illusion. It takes lots of code to implement proper BPEL/WS-*/EJB/MVC/J2EE/*** applications that leverage every pattern in the book! That's the goal. If you happen to produce a working application as a side effect, you can always re-factor it out."

Enterprisey Architecty, May 9, 2006 12:33 AM

4

I second that.

I was in your shoes about few months ago. Coming from a PHP background, a PHP framework was the logical choice, so I explored CakePHP and CodeIgniter.

Now I’m looking into RoR.

I suggest you don’t choose one…The PHP frameworks are still young, so you can take your pick of which to learn (enter CakePHP plug here). But RoR is something every web developer should have a grasp of.

There are pros and cons to each. Just be versitile, then you can decide which you like and which you’d want to specialize in.

But bottom line, “select * from person where blach = ‘blah’” is sooooooo 1999…

5

Baz wrote:

There are pros and cons to each. Just be versitile, then you can decide which you like and which you'd want to specialize in.

But bottom line, "select * from person where blach = 'blah'" is sooooooo 1999..

Just be aware that Rails is a Highly opinionated framework. It plays best with MySQL, albeit SQLite3 is now the default datastore. Working with other DB backends works well in most instances but you are constrained by the features of MySQl insofar as the framework is concerned. To get access to many advanced features of say "postgresql" you are going to drop into execute "SQL STATEMENT HERE".

6

James Byrne wrote:

Just be aware that Rails is a Highly opinionated framework. It plays best with MySQL, albeit SQLite3 is now the default datastore. Working with other DB backends works well in most instances but you are constrained by the features of MySQl insofar as the framework is concerned. To get access to many advanced features of say "postgresql" you are going to drop into execute "SQL STATEMENT HERE".

To get less opinion and more plugability, learn merb. Even if you stay with Rails for production websites, merb is good to learn where RoR should be going. merb is essentially a Rails rewrite on a clean slate, with lots of the coupling (ActiveRecord, CGI, the MVC structure) decoupled into optional plugable modules.

7

But bottom line, "select * from person where blach = 'blah'" is sooooooo 1999..

it may be soooo 1999 but SQL will be around for long time and developers will be required to know how to use it without a framework. ROR is pretty much tied to mySql which is a huge limitation. interpreted languages like ruby lead to some very complex and sometimes unsupportable code. compiled languages like java are more predictable. the level of documentation and support for ROR is very limited and seeking help can be frustrating and time consuming. certainly there is still buggy code in the ROR framework. the practice of arbitrarily deprecating methods leads to painful upgrades when the code no longer runs with a new version. proceed at your own risk IMHO.

8

Why is all of this attached to my comment? lol…

Sorry if I gave the impression that one doesn’t need to know SQL, that was not my intention. I was just trying to point out the benefit of a framework such as Ruby on Rails.

9

it seemed as good as any. i was trying to point out the problems with the ruby on rails framework ...

10

it may be soooo 1999 but SQL will be around for long time and developers will be required to know how to use it without a framework. ROR is pretty much tied to mySql which is a huge limitation.

This is factually untrue. MySQL was the _default_ db for versions of the framework prior to 2.0.2, but it's now sqlLite. That alone should be enough to demonstrate that it's DB adapters are pretty easy to swap out. There are large sites running on Postgres and Oracle while IBM has been very active in producing and supporting a DB2 adapter for their platforms.

interpreted languages like ruby lead to some very complex and sometimes unsupportable code.

Please, give an example. This is, I believe, simply an assertion on your part. What most developers who have tried Ruby understand is that the code tends to be _less_ complex and require fewer LOC to accomplish the same task. Just ask the folks at YellowPages.com, who reduced their 220K lines of java by 45%. Can you honestly argue that 220K of static code is "very complex and unsupportable"? Isn't it just as possible to create "complex and unsupportable" code in any language? This is more a reflection of the developer than the language.

compiled languages like java are more predictable.

In what way?

the level of documentation and support for ROR is very limited and seeking help can be frustrating and time consuming.

The level of documentation for the framework is somewhat limited. However, I would argue that the level of support in forums such as this makes finding answers fairly easy. In fact, when comparing this community to others with which I have been involved I've found the Ruby/Rails community to be much more helpful. The experts and insiders are often found here posting solutions and are generally fairly available. I've been in other communities where the certified insiders take the time only to post replies such as "What a stupid question" and sneer at those not at there level.

If you honestly need to find some answers there are a few books that I'd recommend as key texts: Agile Web Development on Rails (2nd ed), The Rails Way, Ruby for Rails, and The Ruby Way. Armed with those four books i doubt there's much you can't do.

certainly there is still buggy code in the ROR framework.

First, baseless assertions like this are not accomplishing your stated goal of "pointing out the problems with the ruby on rails framework." If you have tried it and found it buggy, point out a specific instance. Otherwise it sounds as though you're parroting lines you've heard and things that cannot be verified.

I won't deny that there is "buggy" code. Most software contains bugs. Rails has an incredible test suite, though, so it's possible that perceived bugs are a problem of perception rather than functionality. That is you _think_ method x is supposed to work one way when it actually does something slightly different. I've usually found that "errors" like this lie more in my understanding.

the practice of arbitrarily deprecating methods leads to painful upgrades when the code no longer runs with a new version. proceed at your own risk IMHO.

I don't know of anything that has been "arbitrarily deprecat[ed]". Care to provide examples?

There certainly have been many deprecations in the framework. Most of them were early methods that were seldom used. Many were ones that developers had long since been warned to avoid. The practice of deprecating cruft from a framework is something that would help many other frameworks really 'swing'. Regardless, the upgrade path was quite well documented. In the move from 1.2.3 and earlier, the community was repeatedly alerted that there were deprecations coming (you could even hit a url that listed them specifically). When the deprecations hit, you could upgrade to a version of the framework that would use the integrated logger to post deprecation warnings in your log. As the deprecations were refined new releases provided better coverage of the deprecations. In the end, if you bothered to try to take a 1.2.x application directly to 2.x without first checking whether all the deprecations were addressed, that was your own fault.

The framework becomes smaller and more targetted. The code base is reduced and easier to maintain with minimal impact on the majority of users. Why is this bad?

11

AndyV wrote:

The framework becomes smaller and more targetted. The code base is reduced and easier to maintain with minimal impact on the majority of users. Why is this bad?

Andy,

You have been around long enough to see this pattern of poster and frankly you should know better! :slight_smile: It's almost pointless to attempt to change someone's mind once it's made up.

I have deployed numerous C++/Java apps and the maintainability of the Ruby apps far surpassed the others but trying to convince someone of that prior to them experiencing it for themselves is next to pointless. My guess is that he had a bad experience and is venting a little so just let him. Please don't get caught up in the hate as it will detract from your enjoyment of this great message board and I for one like having you around.. :slight_smile:

ilan

12

Gone Sail wrote:

But bottom line, "select * from person where blach = 'blah'" is sooooooo 1999..

it may be soooo 1999 but...

...WikiPedia sez SQL was invented in the early 1970s. So it's been "here to stay" for quite a while, by now...

I remember (late 1980s) thinking "dang! you mean I don't need to query single variables out of all these different dBase tables myself and then glom them together manually, over and over again??"

DSLs to the rescue!