# Overwhelmed with choices concerning Rails "best practices"

**URL:** <https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166>\
**Category:** Rails\
**Created:** [May 17, 2009, 1:45pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166 "2009-05-17T13:45:44Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 17, 2009, 1:45pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/1 "2009-05-17T13:45:44Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 17, 2009, 2:16pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/2 "2009-05-17T14:16:10Z")

</div>

\<â€¦\>

> 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/](http://rimantas.com/)

---

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 17, 2009, 4:37pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/3 "2009-05-17T16:37:22Z")

</div>

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](http://www.htdp.org)

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

Graeme Simsion; Graham Witt  
Data Modeling Essentials  
Morgan Kaufman 2004

Michael

–  
Michael S.  
[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
[http://www.schuerig.de/michael/](http://www.schuerig.de/michael/)

---

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 17, 2009, 4:37pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/4 "2009-05-17T16:37:57Z")

</div>

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](http://flea.sourceforge.net/resume.html)

---

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 17, 2009, 5:11pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/5 "2009-05-17T17:11:05Z")

</div>

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

> 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](http://flea.sourceforge.net/resume.html)

## Best,

Marnen Laibow-Koser  
[http://www.marnen.org](http://www.marnen.org)  
removed\_email\_address@domain.invalid

---

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 17, 2009, 7:28pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/6 "2009-05-17T19:28:37Z")

</div>

Quoting Wayne M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):  
[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

---

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 20, 2009, 5:13pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/7 "2009-05-20T17:13:13Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 18, 2009, 5:02pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/8 "2009-05-18T17:02:18Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![wemagor](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/w/8edcca/32.png) [@wemagor](https://www.ruby-forum.com/u/wemagor)\
**Post date:** [May 20, 2009, 5:35pm UTC](https://www.ruby-forum.com/t/overwhelmed-with-choices-concerning-rails-best-practices/168166/9 "2009-05-20T17:35:43Z")

</div>

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

## Best,

Marnen Laibow-Koser  
[http://www.marnen.org](http://www.marnen.org)  
removed\_email\_address@domain.invalid
