Rails - Mar 2008 - 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!!
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

-- 
   Phlip


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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

On Mar 6, 8:44 pm, Phlip
<phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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.
>
> --
>    Phlip
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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..
--
Kevin Lloyd
3HN Designs
http://www.3HNDesigns.com/

On Thu, Mar 6, 2008 at 11:57 PM, Robert Walker
<r0b3rt4723-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> 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
>
> On Mar 6, 8:44 pm, Phlip
<phlip2...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > 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.
> >
> > --
> >    Phlip
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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".
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

--
  Phlip
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Phlip wrote:
> James Byrne wrote:
> 
> 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.
> 
> --
>   Phlip
Ok.. then to carry on your argument further, you should learn Waves 
which even has less coupling than merb.. :)  There are now more ruby 
frameworks than ruby framework coders, I am starting to develop 
conspiracy theories as to where they are all coming from.. (I am leaning 
towards bored space aliens bent on world domination)

ilan
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

>> 
>> 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.
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

On Mon, Mar 10, 2008 at 11:33 AM, Gone Sail <
rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> wrote:
>
> >>
> >> 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.
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

it seemed as good as any. i was trying to point out the problems with 
the ruby on rails framework ...
-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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!  :)  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.. :)

ilan

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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!

-- 
   Phlip
   http://assert2.rubyforge.org/


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---