Hacker News Reader

We've taught hundreds of beginners new to Rails, and we've found that beginners want to learn about all the alternatives - it's like they have to survey the entire landscape before starting. No matter if we're teaching TestUnit or Rspec, someone will ask about the alternative. It's so easy to get side-tracked into evaluating alternatives and just get overwhelmed with the options.

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.

When I learned Rails, I was also learning Ruby. (This was 6 months ago.) (As a matter of fact I was learning what programming really was...)

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

would end up looking for the User class because of the way it was written. (I believe Rspec does something like this as well but because it deviates from Ruby...it's harder to explain.)

I should mention that in our 3-course program, we teach Ruby first. See http://www.gotealeaf.com

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

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

This is a huge problem, and it's even worse because of the great point Klabnick makes about the vocal maybe-minority. When somebody says "nobody actually does it that way", they may mean that nobody who writes blog posts actually does it that way. It's very difficult to tell the difference between things nobody is doing and things nobody is bothering to talk about doing.

My point is that it doesn't matter much which stack you pick. The default stack is not failing. The fail is being overwhelmed by choice, when it doesn't matter in the beginning. What matters most is having a good teacher, who choses a stack for you to learn with.

Once you develop your own taste, then you can refine the specifics. But don't get stuck with analysis paralysis in the beginning.

Exactly.

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.

I am a relative newcomer to rails (1 year) and web programming in general. I stumbled across Michael Hartl's excellent tutorial and fell in love with ruby and rails right away, and shortly thereafter developed a deep-rooted hatred (well, strong dislike) of rspec. All of the fun I gained by using ruby was sucked out of me by rspec. Months later I decided to try testunit and in retrospect I wish I hadn't waited so long. After an hour or so of toying with it I knew it was the way forward as I am someone who wants to write test code that is just ruby.

I still recommend Michael's tutorial to anyone new to rails, but a '37 signals' stack version would be great.

Out of curiosity, what do you dislike about rspec?

While I have more than a few complaints about Rails, rspec certainly has never been one of them.

I don't like the dsl. While admittedly it is entirely a question of preference, I find it more natural to write some ruby code and then assert(something). As an example, from Hartl's tutorial we have a test dealing with microposts:

    subject { @micropost }
    it { should respond_to(:content) }

I prefer writing:

    assert @micropost.respond_to?(:content)

I haven't looked at rspec in a while and in the rspec example I don't remember how long the subject stays in scope nor would I remember to put braces between 'it' and 'should'. In the testunit example, it's all ruby, there isn't anything more I need to know.

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?

rspec has some redeeming qualities that were luckily ported to minispec, especially the let-syntax. Once you grok how it works, its a very nice way to setup complex test data that has minor differences.

assert, in my opinion, has the distinct advantage of being immediately recognizable as a special thing while should reads kind of informal.

Wouldn't say `let` is so much better than `def setup` as a newcomer. `def setup` is simple and powerful enough and after a while you begin to wonder whether something like `let` exists.

It's worth noting that rspec gives you lots of options.

    @micropost.should respond_to(:content)

is perfectly valid, and IMO, much cleaner.

But that's the thing.

    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?

The testunit It's Just Ruby examples end up looking like the syntactic sugar!

That rspec example looks like some sort of misguided language skeuomorphism. "If I name this method 'it' and this one 'should' and this one 'subject', I get something that sort of looks like English if you read it out loud while skipping the symbols! Isn't that neat?"

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.

Thank you for explaining my immediate visceral discomfort on being introduced to rspec and cucumber more eloquently than I could.

Fair. I can definitely appreciate the DSL argument. Rails has a rickety enough learning curve as it is, and introducing rspec at the outset is certainly debatable.

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.

I disagree that using Rails Tutorial as a beginner resource is the way to go.

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.

Interesting. I might be persuaded to recommend something else. What alternatives do you think are better?

I haven't found a good starting point. The two main contenders I've read in non sequential order:

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.

Consider "Rails for Zombies"[0].

[0] I teach/tutor Rails programming, and my students have found this resource particularly helpful.

Consider "Rails for Zombies"[0].

[0] I teach/tutor Rails, and my students have found this resource particularly helpful.

1 to 3 are useful because you'll be doing them so frequently you can't ignore them.

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.

Micheal's Rails Tutorial was my first step in to Rails. I took Micheal's suggestion in the tutorial and spent a few days getting the basics of Ruby.

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.

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!

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 you, which is the reason why I think PHP is still way more popular than Rails. Cut-and-pasting scripts from Google searches is a terrible way to make code, but it works and it's a lot easier.

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 think the fact that the starting point for php is an html page is a big deal. Whether or not its a good thing to replicate that (and things like that) is debatable but its not just about cutting and pasting from Google.

That's an important point, that Rails presumes database backing, and dynamic sites are inherently more complicated that static pages.

I think the point is that you can ease in to that with PHP - you can be as dynamic or not as you want. Many (many!) people started with PHP just to add a contact form to a site, or make a dynamic copyright date in a footer (or just to do common footers with include()). Rails/Grails/Play/CF/etc assume you want to do a lot more, and force you to do things their way - integrating a tech in to an existing site is really problematic outside of PHP, because most other webdev tech is 'full stack'.

We don't disagree.

You can write PHP-style "the file is the html page" code in Ruby with .erb files and mod_ruby. It's no harder to set up than PHP (granted though, most people who abuse PHP like that can't/don't do their own server configuration).

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.

Of course, and that starting point encapsulates much that is good (easy to extend HTML by mixing in some code, quick to get started, zero deployment hassles) and bad (easy to mix content and code, easy to start without thinking about the bigger picture or planning your app, easy to make mistakes like exposing your db password to the world because of a permissions issue say) about PHP.

> which is the reason why I think PHP is still way more popular than Rails.

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.

> Sure would like to help someone create one.

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.

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

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)

Stupid Sexy Flanders!