Types of apps to use Rails for?

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!!

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.

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

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…

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

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.

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.

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.

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

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?

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

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!