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

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

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 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. :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    Resume for Philip C Plumlee

Best,

Quoting Wayne Molina <wayne.molina@gmail.com>: [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

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: