What we've found works is this:
1. Beginners need a curated stack by someone they trust. "Here, this is the stack to learn from; stop wasting time evaluating and get started."
2. Learn about the people, personalities, and community that make the tools. Understand the reasons for their creation; keep up with the conversations.
#1 from above gets beginners unstuck, while #2 will allow them to slowly evaluate different pieces of the stack over time. It's important to understand the "why", not only the "how".
For our courses, we use a mix of the two stacks. For our intro to Rails course, we use: erb, sqlite in dev and postgres in production, fat models and skinny controllers. For our intermediate course, we use haml, rspec, postgres. And finally, for our advanced course, we use "outside in" BDD with Cucumber and introduce the concept of service layers.
We've found this to be a great approach to introducing newbies to the "37 Signal stack" and growing them into the "Prime stack". The goal is to let them figure out their own preferred stack over time, and be productive no matter which stack is in front of them.
That's supposed to be what Rails itself IS, right? Isn't that the point of it being "opinionated", it's supposed to BE the curated stack from someone you trust.
If it's failing, that's a problem.
It certainly is frustrating when you're trying to get the actual Rails stack to work and can't figure out why it seems so hard and someone tells you "Oh yeah, despite the Rails documentation telling you to do it that way, nobody actually does it that way."
Personally, I find the default Rails stack is completely fine for everything I need. I'd not even heard of half of these options in the "alternative stacks" in TFA and the comments here until today. OK, I'd heard of HAML and the other unit testing frameworks, but that's it.
I don't think there's really a big issue here. People could just as easily get distracted by all the different npms in node.js, or the different technologies in the enterprise Java world.
Once you develop your own taste, then you can refine the specifics. But don't get stuck with analysis paralysis in the beginning.
Learning MiniTest/Test::Unit first I would say is a much better approach because you get to focus on the language, which is at the end of the day, the reason Rails is so special.
I read somewhere that someone decided to teach Rspec because it had "less" metaprogramming than a Test::Unit definition.
But in retrospect, it may have been really easy to begin grokking metaprogramming if we had explained that naming something:
class UserTest < TestUnit::TestCase
I still recommend Michael's tutorial to anyone new to rails, but a '37 signals' stack version would be great.
While I have more than a few complaints about Rails, rspec certainly has never been one of them.
subject { @micropost }
it { should respond_to(:content) }
assert @micropost.respond_to?(:content)
It sounds strange, but even though the rspec example reads more like english, I find the assert more readable. Maybe it has something to do with the braces.
As a beginner, there are so many choices you have to make and so many things you have to learn. Rspec adds another item to that list. I would have preferred to learn to write tests with testunit and fixtures and then be presented with rspec, cucumber, factories, etc., a little later.
Have you used both rspec and testunit or just the former?
Well, no, it's a horrible idea, because in English those words would imply a certain syntax tree, while the actual syntax tree in your DSL is completely different, and those words have completely different roles from the ones they have in English. So you have something that superficially looks like English if you take care to arrange it just right, but in fact works in a completely different way from how you know English to work.
It's like having a picture of a sliding knob in your application, except instead of sliding it you're supposed to click it, and it's actually used as a tab switcher. And you put a denim texture on it.
@micropost.should respond_to(:content)
rspec: @micropost.should respond_to(:context)
testunit: assert @micropost.respond_to?(:context)
rspec: @micropost.should be_valid
testunit: assert @micropost.valid?
rspec: @micropost.should_not be_valid
testunit: refute @micropost.valid?
For what it's worth, I would definitely not consider the rspec syntax in that Hartl snippet to be a particularly legible example. The code provided in another comment is a much better representation of good style, IMHO.
assert, in my opinion, has the distinct advantage of being immediately recognizable as a special thing while should reads kind of informal.
In fact, I used that as my first resource for learning Rails! Here are some problems I found with it:
1. It teaches you Git along with Rails. Who cares about source control at this point? Remember: This is for a newcomer to Rails that just wants to learn how to create websites using rails; don't confuse me even more.
2. It teaches you how to deploy to Heroku. Again, don't care at this point.
3. It teaches you how to deploy your code to Github. Once again, NEEDLESS INFORMATION AT THIS POINT! :P
4. Unit testing; Ugh, I'm 100 pages in and I barely have a grasp of what I'm doing, and I'm STILL barely 1 controller with 2 actions in.
---
There are other alternatives that I think are better for a newbie.
I will concede that Michael's tutorial IS GOOD, but just not good for someone brand new to ruby and rails. I find myself re-reading Rails Tutorial and The Pragprog Agile Rails book every couple of weeks, discovering new things I missed.
That's the way to learn, keep reviewing things.
Getting code to a working public server was a point of revelation for me as a new rails developer. It was hard, but rewarding.
4 can be safely skipped until you're ready for it.
What Micheal focuses on is teaching you a few things he considers essential to the Rails ecosystem - git, Heroku and RSpec ( He mention the Test::Unit alternative too). I have learnt a lot from his tutorial and this is where I point others new to Rails to go to.
Also, it is better to get acquainted with git while working on a (dummy) project than trying its commands in a vacuum where one doesn't understand its power.
1. Micheal Heartl's Rails Tutorial. 2. Pragmatic Programmers Bookshelf - Agile Rails 3.2 (4th Edition)
Both are a good start but delve far too much into unit testing with the horrific RSpec. When you're learning something new, you don't want to muddle with learning a DSL on top of things.
[0] I teach/tutor Rails programming, and my students have found this resource particularly helpful.
[0] I teach/tutor Rails, and my students have found this resource particularly helpful.
But if you care about Rails uptake, aren't those bad things?
People don't like being confused. People don't like feeling stupid. If their initial impression of a system is "this is confusing" or "this makes me feel stupid," many if not most will simply go look for an alternative that isn't confusing and doesn't make them feel stupid, even if that alternative is inferior in other ways that aren't immediately apparent to the newbie.
I agree with DHH that Rails shouldn't be dumbed down (see his Railsconf 2012 talk https://37signals.com/svn/posts/3171-keynote-by-david-from-r...). Cooking with Rails is like cooking with a real oven, not an easy bake where the end product tastes terrible. Somehow new people need to know that Rails is a real framework that can burn you if you're not careful.
I can't think of anyone though that promotes that method of building websites anymore though, even PHP proponents advocate some flavor of web framework. It just happens to be an easy entry point for using PHP, and once a new developer has built some project momentum for the first time, they're reluctant to start over with something new.
language being more popular than a framework! sure :)
bring one framework that is more popular then rails?
google trends proof: http://www.google.nl/trends/explore#q=ruby%20rails,%20symfon... (many people make searches w/o the 'ruby' search term, so rails wins by a larger margin)
some proof here that php is a lot more popular then ruby:
http://www.google.nl/trends/explore#q=ruby%20tutorial,%20rub...
and java more popular then php... and WOW FLASH!
http://www.google.nl/trends/explore#q=php%20tutorial,%20php%...
we a should all use flash, it is the most popular, more so the java!
gosh.. im trying to prove you're comparing apples with bananas and now i find out i should be coding in Adobe Flash (tm).
</joke>
anyway.. i believe php is only marginally more popular then rails, for stuff that involves "web app development". that's what rails made is for. php is used a lot for ftp-ing scripts to cheap webhosting, something is done a lot less with rails.
Something like this would be very appropriate for a Rails Guide. We already have an introductory one, an 'intermediate' and 'advanced' one would be helpful.
Why is that normal?
I can say with some certainty that when I was deciding between Django and Rails, (and, subsequently Python/Ruby) there was a clear and obvious superior choice. (Hint: not Rails)
One message I'd like people to understand when they're starting out with Rails is that it really is confusing, and that being confused and maybe even feeling stupid is normal! I remember hearing people talk about how easy developing Rails applications was back in 2006, but what I didn't know was it was easy relative to other web frameworks at the time. It's still hard.
By analogy, if you're an intermediate skiier and you visit a well-groomed mountain with great, powdery snow you could say "this mountain is easy to ski on". But if you're just learning to ski, and you follow everyone else up the lift to the top of a blue run, it's a terrifying experience trying to get down the slope without breaking your neck. To add insult to injury, it's discouraging to see everyone else gliding down the slope while you're shimmying down on your butt because when you try to stand you lose control, go way too fast, then crash. New skiiers need bunny hills, then green runs, then blue runs.
I still don't think there's an established "bunny hill" and "green run" track for learning Rails. Sure would like to help someone create one.