Rails - May 2009 - Overwhelmed with choices concerning Rails "best practices"

As someone who has repeatedly tried to sit down and really pick up
Ruby on Rails, the one deterrent I continually find is that the best
way of doing things seem to change on a daily basis, and half the time
nobody can agree with it.  Since my programming background is largely
self-taught and without any formal CS education, I like to make a list
of the "right" way to develop applications in a particular language/
framework so I know that I''m going to be starting off on the right
foot; this is in direct opposition to something like picking up a book
on PHP, say, and cranking out junk sites and learning bad practices.

In effect my problem is that whenever I sit down to really learn Rails
(and I have almost a dozen books on it I''ve gathered over the past
year, although a lot are from the prior edition - I have:  AWDWR 3rd
Edition, Programming Ruby 2nd edition, The Ruby Way, The Rails Way,
O''Reilly''s Learning Rails, Ajax on Rails, Enterprise Rails,
Apress
Social Networking Sites with Rails, and RailsSpace) the community
seems to have charged forward and changed its best practices, so it''s
just added a whole bunch of things I need to learn as well.

For instance, the new thing seems to be BDD and RSpec, so I have to
learn RSpec in addition to Rails and Ruby.  Git is used for version
control, so that''s something else.  RJS is out and unobtrusive stuff
is in, so that means jQuery.  Hosting is now typically done with
Phusion Passenger, so I have to learn Apache and that.  Finally with
the Rails+Merb merger things are going to get shaken up even more so.
I really want to learn Rails but the community seems to just keep
jumping from one bandwagon to another without staying put long enough
for somebody who didn''t come aboard in 2005-2006 to ever get to
speed.  Like I said I like to follow best practices because I come
from .NET and I''ve seen what just slapping together code can do, and
it''s not pretty, so I feel like if I''m going to learn Rails, I
need to
learn it right from the start, not learn the "obsolete" way of writing
it and then upgrade.

Can somebody knock some sense into me in this regard?  I''ve been
trying to learn Rails for over a year now and this is the main reason
why I can never get more than basic tutorial-style stuff going on.

<…>
> the community
> seems to have charged forward and changed its best practices, so
it''s
> just added a whole bunch of things I need to learn as well.
Welcome to the web development :) You list a bunch of technologies
which have some alternative tools for the work to be done.
Learn the principles common to those tools and you won''t be scared
anymore.
> For instance, the new thing seems to be BDD and RSpec, so I have to
> learn RSpec in addition to Rails and Ruby.
Actually this is the only thing more or less directly related to RoR.
>  Git is used for version
> control, so that''s something else.
It is about time to move on from Subversion to some DCVS.
Git is very good choice, but maybe with the steeper learning curve
than others. I have no doubt that in some point of your developer''s
live you will meet bazaar, mercurial too.
>  RJS is out and unobtrusive stuff
> is in, so that means jQuery.
jQuery is just one of the available Javascript frameworks for DOM
manipulation and AJAXing. Once you know a bit about that
be it Prototype, jQuery, YUI, mootools, dojokit, etc. won''t scare you.
>  Hosting is now typically done with
> Phusion Passenger, so I have to learn Apache and that.
That''s another layer, but learning a bit of apache won''t hurt
for sure.
>  Finally with
> the Rails+Merb merger things are going to get shaken up even more so.
> I really want to learn Rails but the community seems to just keep
> jumping from one bandwagon to another without staying put long enough
> for somebody who didn''t come aboard in 2005-2006 to ever get to
> speed.  Like I said I like to follow best practices because I come
> from .NET and I''ve seen what just slapping together code can do,
and
> it''s not pretty, so I feel like if I''m going to learn
Rails, I need to
> learn it right from the start, not learn the "obsolete" way of
writing
> it and then upgrade.
Rails if only part of the whole picture. Learn the parts what make that
picture, learn common principles behind those parts and you may
begin to see the light. Yes, there is a lot to learn—server side, client
side, developer''s tools, deployment''s tools, etc. but it is
fun too!


Regards,
Rimantas
--
http://rimantas.com/

On Sunday 17 May 2009, Wayne Molina wrote:
> As someone who has repeatedly tried to sit down and really pick up
> Ruby on Rails, the one deterrent I continually find is that the best
> way of doing things seem to change on a daily basis, and half the
> time nobody can agree with it.  Since my programming background is
> largely self-taught and without any formal CS education, I like to
> make a list of the "right" way to develop applications in a
> particular language/ framework so I know that I''m going to be
> starting off on the right foot; this is in direct opposition to
> something like picking up a book on PHP, say, and cranking out junk
> sites and learning bad practices.
[...]
> Can somebody knock some sense into me in this regard?  I''ve been
> trying to learn Rails for over a year now and this is the main reason
> why I can never get more than basic tutorial-style stuff going on.
You''re serious about learning to develop software and expect to do it 
some time? Then it is really worthwhile to learn the fundamentals 
instead of the technology of the day. As you''ve discovered, the later 
tends to change quickly, if not literally daily.

Here are just three suggestions

Matthias Felleisen et al.
How to Design Programs: An Introduction to Programming and Computing	
MIT Press 2001
http://www.htdp.org

Robert C. Martin
Agile Software Development, Principles, Patterns, and Practices
Prentice-Hall 2002
http://www.objectmentor.com/resources/books.html

Graeme Simsion; Graham Witt
Data Modeling Essentials
Morgan Kaufman 2004

Michael

-- 
Michael Schuerig
mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org
http://www.schuerig.de/michael/

Wayne Molina wrote:
> ...the community
> seems to have charged forward and changed its best practices, so
it''s
> just added a whole bunch of things I need to learn as well.
The more things change, the more they stay the same.
> For instance, the new thing seems to be BDD and RSpec, so I have to
> learn RSpec in addition to Rails and Ruby.
What''s 10-years-old about that is "test-first". Write a test
that fails before
writing _any_ line of code. Don''t just use those things as toys, and
don''t just
write tests on the sitting duck targets that are easy to test. If a given 
feature requires 20 minutes of coding, but requires 2 hours of writing the test 
first, write the test first anyway. This is how a project sustains itself at 
scaling time. Further tests will _not_ require those 2 hours again!

Also, while RSpec is in a growth phase, I suspect most Rails tests are in 
Test::Unit. Learn it.

 >  Git is used for version
> control, so that''s something else. 
Ideally, put either git or svn into your lib/tasks/project.rake, and then run 
short rake commands.

 > RJS is out and unobtrusive stuff
> is in, so that means jQuery.
Hardly; JavaScript is still JavaScript.

The good news there is the libraries are more pluggable, and as Rails converges 
with Merb they will only get more-so.

 > Hosting is now typically done with
> Phusion Passenger, so I have to learn Apache and that. 
The story there is, for whatever reason, Ruby for the longest time had no module
that plugged into the great A-Patchy server. When it arrived, the committee 
renamed it to Passenger.
> Finally with
> the Rails+Merb merger things are going to get shaken up even more so.
Merb has a better core.
> I really want to learn Rails but the community seems to just keep
> jumping from one bandwagon to another without staying put long enough
> for somebody who didn''t come aboard in 2005-2006 to ever get to
> speed. 
Doing Rails requires good skills with El Goog, including codesearch, including 
remembering to always check the date on some blog entry offering some critical 
tidbit of information.

Any Rails book, plus that skill, will keep you in the loop.

And the other good news is as Rails matures, gains converts, and becomes stable,
the committee won''t be able to make all these changes so often. That is
the
intent of the Rails-Merb merger.

 > Like I said I like to follow best practices because I
come
> from .NET and I''ve seen what just slapping together code can do,
and
> it''s not pretty, so I feel like if I''m going to learn
Rails, I need to
> learn it right from the start, not learn the "obsolete" way of
writing
> it and then upgrade.
Why does .NET impede "just slapping code together"? BTW that is _not_
what we do
here - refer back to the "test-first" verbiage above!

Oh, I remember! .NET is closed source over all of its stack, meaning
it''s
software that attempts to control its programmers, and keep them locked in to 
one vendor.

We don''t do that. Anyone who invents a better Rails wins, so the
competition
keeps us honest, even as we invent conflicting libraries and systems.
> Can somebody knock some sense into me in this regard?  I''ve been
> trying to learn Rails for over a year now and this is the main reason
> why I can never get more than basic tutorial-style stuff going on.
Do you have a client with feature requests? That helps. Also, you might then 
notice that most of our code _is_ tutorial level. That is the point of Lean and 
Agile development with such a light framework...

-- 
   Phlip
   http://flea.sourceforge.net/resume.html

Phlip wrote:
> Wayne Molina wrote:
> 
>> ...the community
>> seems to have charged forward and changed its best practices, so
it''s
>> just added a whole bunch of things I need to learn as well.
> 
> The more things change, the more they stay the same.
As usual, Phlip has some excellent advice here.  I thought I''d just 
amplify a few points.
> 
>> For instance, the new thing seems to be BDD and RSpec, so I have to
>> learn RSpec in addition to Rails and Ruby.
> 
> What''s 10-years-old about that is "test-first". Write a
test that fails
> before
> writing _any_ line of code.
Yup.  And that''s not a Rails-specific thing either.

[...]
> Also, while RSpec is in a growth phase, I suspect most Rails tests are 
> in
> Test::Unit.
I suspect you''re wrong.  I know that you don''t like RSpec (for
reasons I
cannot fathom), but it seems to me that most Rails code I look at these 
days uses it.
> Learn it.
Er...why, other than for completeness'' sake?  Last time I looked at 
Test::Unit, it just seemed so *clunky* compared to RSpec, although your 
assert2 module seems to help.
> 
>  >  Git is used for version
>> control, so that''s something else. 
> 
> Ideally, put either git or svn into your lib/tasks/project.rake, and 
> then run
> short rake commands.
Maybe.  I liked that approach with Rubinius, when I was a newbie to Git, 
but these days, I think I use Git in so many different ways that writing 
Rake tasks wouldn''t really reduce any complexity.  I *can* think of one
or two exceptions, though.  YMMV.
> 
>  > RJS is out and unobtrusive stuff
>> is in, so that means jQuery.
> 
> Hardly; JavaScript is still JavaScript.
Indeed.  You can be unobtrusive with any JS library, or with none. 
jQuery is hardly implied by unobtrusive JS.
> 
> The good news there is the libraries are more pluggable, and as Rails 
> converges
> with Merb they will only get more-so.
I have a suspicion that Rails will jump the shark when it merges with 
Merb, but I would be extremely happy to be wrong about that.
> 
>  > Hosting is now typically done with
>> Phusion Passenger, so I have to learn Apache and that. 
> 
> The story there is, for whatever reason, Ruby for the longest time had 
> no module
> that plugged into the great A-Patchy server. 
Actually, mod_ruby has been around for a long time, but its 
single-threaded nature made it unsuitable for Rails.
> When it arrived, the 
> committee
> renamed it to Passenger.
I don''t think that name came from the Apache committee...did they even 
have anything to do with Passenger?
> 
>> Finally with
>> the Rails+Merb merger things are going to get shaken up even more so.
> 
> Merb has a better core.
Good to know.
> 
>> I really want to learn Rails but the community seems to just keep
>> jumping from one bandwagon to another 
Yes, parts of the Rails community are very faddish.  It''s up to you to 
decide which fads are worthwhile. :)
> without staying put long enough
>> for somebody who didn''t come aboard in 2005-2006 to ever get
to
>> speed. 
> 
> Doing Rails requires good skills with El Goog, including codesearch, 
> including
> remembering to always check the date on some blog entry offering some 
> critical
> tidbit of information.
Yup.  Rails core development moves quite fast.
> 
> Any Rails book, plus that skill, will keep you in the loop.
Seems to me that Rails books are generally out of date as soon as 
they''re printed.
> 
> And the other good news is as Rails matures, gains converts, and becomes 
> stable,
> the committee won''t be able to make all these changes so often.
That is
> the
> intent of the Rails-Merb merger.
Do you really think that DHH will be able to resist the lure of further 
opportunities for intellectual masturbation by tinkering with the Rails 
core?  I sure don''t.
[...]
> Anyone who invents a better Rails wins, so the 
> competition
> keeps us honest, even as we invent conflicting libraries and systems.
We''ll see.  3.0 may be a better Rails, or it may not.
> 
> --
>    Phlip
>    http://flea.sourceforge.net/resume.html
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.

Quoting Wayne Molina
<wayne.molina-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
[snip]
As someone who has been programming for over 35 years, my advice is learn how
to learn.  Actually, learn how YOU learn.  Because you are going to need it.
Programming is like science.  Good observation finds things that aren''t
like
it "should" be.  So a hypothesis is proposed, tested, debated, and if
there is
no conflicting data, slowly transformed into "law", received truth. 
There are
many hypotheses about how it should be, what might improve things.  Some will
show their value, others won''t.  Some will be useful for years, some
for only
a short bit of space and time.  Practices that make sense for large stable
problem spaces may not make any sense in small problems in rapidly changing
areas.  And many "best practices" are overkill and oversold.  The core
idea is
good, but it has hardened into dogma, accumulated too much overhead and
isn''t
worth the amount of time required.  It is a very good idea to spend some time
up front thinking about the design, both user interaction and implementation
strategies.  Few projects will see a decent Return On Investment (ROI) of a 50
pound design document.

My suggestion is to learn incrementally.  You can do most of your development
with Webrick or Mongrel.  Learn Apache and Phusion Passenger when you are
ready to deploy the production system.  Automated testing is extremely
helpful.  TDD, BDD, or whatever.  There are good reasons for testing as early
as possible, but start with just the low hanging fruit.  If you aren''t
sure
what the system is supposed to do, don''t invest a lot of time testing
for what
is likely to change.

Expectations change, socially acceptable costs change, technology costs
change.  For example, I remember when if you wanted seatbelts in your car, you
went to a small airport to buy them and installed them yourself.  These were
the 2 point, metal to fabric, lap belts.  Same as on commerical aircraft of
the day.  Then came metal to metal lap belts available as an option.  Nowdays,
three point, lap and shoulder belts are standard and most jurisdictions in the
US legally require that you use them.  Airbags are following the same route.
However, 5 point belts are required in racing cars.  Safer than 3 point belts,
but the hassle/cost is considered too high for the benefits.

I like Alistair Cockburn''s work on programming process.  One he focuses
on
what has a track record of working in practice, not on what "should"
work
according to some guru sitting in an ivory tower somewhere far from the front
lines of actual programming (not all ivory towers are in academia).  Also he
makes a point of differing levels of process depending on how many people and
how critical the system is.  The level of rigor, paperwork, documentation,
etc. appropriate for a 2 person project making an entertaining widget is
different from a 50 person project making a life-critical application
(e.g. X-ray machines, heart-lung pumps).

Advice from a human potential trainer many years ago I still find helpful.  If
you decide today to be a vegetarian, do not expect to be 100% vegetarian
tomorrow.  You don''t have the recipes, the ingredients in your kitchen,
the
nutritional information, or habits necessary.  Start with one or two
improvements, when they are second nature, and another.  And know that better
is a moving target, not a destination.

HTH,
  Jeffrey

Hi Wayne,

I think you''re too anxious. Software development best practices are
not so specific to RoR, you can follow well established patterns
independent of the language/platform of choice. Regarding new
technologies and Rails-specific techniques, I just tend to ignore them
if they are not particularly useful/necessary to the project at any
given moment.

Cheers, Sazima

On May 17, 8:45 am, Wayne Molina
<wayne.mol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> As someone who has repeatedly tried to sit down and really pick up
> Ruby on Rails, the one deterrent I continually find is that the best
> way of doing things seem to change on a daily basis, and half the time
> nobody can agree with it.  Since my programming background is largely
> self-taught and without any formal CS education, I like to make a list
> of the "right" way to develop applications in a particular
language/
> framework so I know that I''m going to be starting off on the right
> foot; this is in direct opposition to something like picking up a book
> on PHP, say, and cranking out junk sites and learning bad practices.
>
> In effect my problem is that whenever I sit down to really learn Rails
> (and I have almost a dozen books on it I''ve gathered over the past
> year, although a lot are from the prior edition - I have:  AWDWR 3rd
> Edition, Programming Ruby 2nd edition, The Ruby Way, The Rails Way,
> O''Reilly''s Learning Rails, Ajax on Rails, Enterprise
Rails, Apress
> Social Networking Sites with Rails, and RailsSpace) the community
> seems to have charged forward and changed its best practices, so
it''s
> just added a whole bunch of things I need to learn as well.
>
> For instance, the new thing seems to be BDD and RSpec, so I have to
> learn RSpec in addition to Rails and Ruby.  Git is used for version
> control, so that''s something else.  RJS is out and unobtrusive
stuff
> is in, so that means jQuery.  Hosting is now typically done with
> Phusion Passenger, so I have to learn Apache and that.  Finally with
> the Rails+Merb merger things are going to get shaken up even more so.
> I really want to learn Rails but the community seems to just keep
> jumping from one bandwagon to another without staying put long enough
> for somebody who didn''t come aboard in 2005-2006 to ever get to
> speed.  Like I said I like to follow best practices because I come
> from .NET and I''ve seen what just slapping together code can do,
and
> it''s not pretty, so I feel like if I''m going to learn
Rails, I need to
> learn it right from the start, not learn the "obsolete" way of
writing
> it and then upgrade.
>
> Can somebody knock some sense into me in this regard?  I''ve been
> trying to learn Rails for over a year now and this is the main reason
> why I can never get more than basic tutorial-style stuff going on.

Sazima''s exactly right.  When you''re getting your "sea
legs", ignore what the cool kids are doing and just learn the basics of the
platform.  Get yourself a book, install the version of rails it covers, dig in
& write an application or two.

Once you''ve got some experience under your belt you''ll know
what seems like unnecessary pain to you, and can start to explore the different
tweaks and add-ons.

That''s my plan anyway. ;-)

-----Original Message-----
From: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
[mailto:rubyonrails-talk@googlegroups.com] On Behalf Of Sazima
Sent: Monday, May 18, 2009 8:01 AM
To: Ruby on Rails: Talk
Subject: [Rails] Re: Overwhelmed with choices concerning Rails "best
practices"


Hi Wayne,

I think you''re too anxious. Software development best practices are not
so specific to RoR, you can follow well established patterns independent of the
language/platform of choice. Regarding new technologies and Rails-specific
techniques, I just tend to ignore them if they are not particularly
useful/necessary to the project at any given moment.

Cheers, Sazima

On May 17, 8:45 am, Wayne Molina
<wayne.mol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> As someone who has repeatedly tried to sit down and really pick up
> Ruby on Rails, the one deterrent I continually find is that the best
> way of doing things seem to change on a daily basis, and half the time
> nobody can agree with it.  Since my programming background is largely
> self-taught and without any formal CS education, I like to make a list
> of the "right" way to develop applications in a particular
language/
> framework so I know that I''m going to be starting off on the right
> foot; this is in direct opposition to something like picking up a book
> on PHP, say, and cranking out junk sites and learning bad practices.
>
> In effect my problem is that whenever I sit down to really learn Rails
> (and I have almost a dozen books on it I''ve gathered over the past
> year, although a lot are from the prior edition - I have:  AWDWR 3rd
> Edition, Programming Ruby 2nd edition, The Ruby Way, The Rails Way,
> O''Reilly''s Learning Rails, Ajax on Rails, Enterprise
Rails, Apress
> Social Networking Sites with Rails, and RailsSpace) the community
> seems to have charged forward and changed its best practices, so
it''s
> just added a whole bunch of things I need to learn as well.
>
> For instance, the new thing seems to be BDD and RSpec, so I have to
> learn RSpec in addition to Rails and Ruby.  Git is used for version
> control, so that''s something else.  RJS is out and unobtrusive
stuff
> is in, so that means jQuery.  Hosting is now typically done with
> Phusion Passenger, so I have to learn Apache and that.  Finally with
> the Rails+Merb merger things are going to get shaken up even more so.
> I really want to learn Rails but the community seems to just keep
> jumping from one bandwagon to another without staying put long enough
> for somebody who didn''t come aboard in 2005-2006 to ever get to
speed.
> Like I said I like to follow best practices because I come from .NET
> and I''ve seen what just slapping together code can do, and
it''s not
> pretty, so I feel like if I''m going to learn Rails, I need to
learn it
> right from the start, not learn the "obsolete" way of writing it
and
> then upgrade.
>
> Can somebody knock some sense into me in this regard?  I''ve been
> trying to learn Rails for over a year now and this is the main reason
> why I can never get more than basic tutorial-style stuff going on.

GHC Confidentiality Statement

This message and any attached files might contain confidential information
protected by federal and state law. The information is intended only for the use
of the individual(s) or entities originally named as addressees. The improper
disclosure of such information may be subject to civil or criminal penalties. If
this message reached you in error, please contact the sender and destroy this
message. Disclosing, copying, forwarding, or distributing the information by
unauthorized individuals or entities is strictly prohibited by law.

Roy Pardee wrote:
> Sazima''s exactly right.  When you''re getting your
"sea legs", ignore
> what the cool kids are doing and just learn the basics of the platform. 
Sure.  OTOH, don''t take this as license to not learn the usual idioms
in
the field.
> Get yourself a book, install the version of rails it covers, dig in & 
> write an application or two.
I *really* am not sure that Rails books are worth it, since the 
framework changes so fast.  (But there''s always the guides.)
> 
> Once you''ve got some experience under your belt you''ll
know what seems
> like unnecessary pain to you, and can start to explore the different 
> tweaks and add-ons.
Yes.  Rails generally makes it very clear when you shouldn''t be doing 
something.
> 
> That''s my plan anyway. ;-)
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
marnen-sbuyVjPbboAdnm+yROfE0A@public.gmane.org
-- 
Posted via http://www.ruby-forum.com/.