Overwhelmed with choices concerning Rails "best practices"

Rails
1

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.

2

<…>

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 :slight_smile: 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/

3

On Sunday 17 May 2009, Wayne M. 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 S.
mailto:[email protected]
http://www.schuerig.de/michael/

4

Wayne M. 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

5

Phlip wrote:

Wayne M. 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. :slight_smile:

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
[email protected]

6

Quoting Wayne M. [email protected]:
[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

7

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. :wink:

8

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

9

Roy P. 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. :wink:

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]