6 ms·

Using Steve's definitions from the article, the tutorial I usually point people to is Michael Hartl's Rails Tutorial http://ruby.railstutorial.org/ http://ruby.

by milesf 14y ago

Using Steve's definitions from the article, the tutorial I usually point people to is Michael Hartl's Rails Tutorial http://ruby.railstutorial.org/ http://ruby.railstutorial.org/ which uses the "Prime" stack. I believe I read somewhere that Michael was going to come out with a "37 signals" stack version as well. 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.

steveklabnik 14y ago
> 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.
smacktoward 14y ago
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.
- milesf 14y ago
  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-railsconf-2012-on-progress 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.
  - netcan 14y ago
    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.
    - rhizome 14y ago
      That's an important point, that Rails presumes database backing, and dynamic sites are inherently more complicated that static pages.
      - mgkimsal 14y ago
        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'.
        rhizome 14y ago
        We don't disagree.
walls 14y ago
> 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)
natejenkins 14y ago
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.
- doktrin 14y ago
  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.
  - natejenkins 14y ago
    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?
    - Argorak 14y ago
      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.
cglee 14y ago
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.
- lazyGeneral 14y ago
  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.)
  - cglee 14y ago
    I should mention that in our 3-course program, we teach Ruby first. See http://www.gotealeaf.com http://www.gotealeaf.com
sergiotapia 14y ago
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.
- milesf 14y ago
  Interesting. I might be persuaded to recommend something else. What alternatives do you think are better?
  - sergiotapia 14y ago
    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.
  - LiveTheDream 14y ago
    Consider "Rails for Zombies"[0]. [0] I teach/tutor Rails programming, and my students have found this resource particularly helpful.
  - LiveTheDream 14y ago
    Consider "Rails for Zombies"[0]. [0] I teach/tutor Rails, and my students have found this resource particularly helpful.
tenderlove 14y ago
Stupid Sexy Flanders!

by milesf 14y ago

steveklabnik 14y ago

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

smacktoward 14y ago

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.

milesf 14y ago
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-railsconf-2012-on-progress 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.
- netcan 14y ago
  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.
  - rhizome 14y ago
    That's an important point, that Rails presumes database backing, and dynamic sites are inherently more complicated that static pages.
    - mgkimsal 14y ago
      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'.
      - rhizome 14y ago
        We don't disagree.

walls 14y ago

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

natejenkins 14y ago

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.

doktrin 14y ago
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.
- natejenkins 14y ago
  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?
  - Argorak 14y ago
    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.

cglee 14y ago

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.

lazyGeneral 14y ago
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.)
- cglee 14y ago
  I should mention that in our 3-course program, we teach Ruby first. See http://www.gotealeaf.com http://www.gotealeaf.com

sergiotapia 14y ago

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.

milesf 14y ago
Interesting. I might be persuaded to recommend something else. What alternatives do you think are better?
- sergiotapia 14y ago
  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.
- LiveTheDream 14y ago
  Consider "Rails for Zombies"[0]. [0] I teach/tutor Rails programming, and my students have found this resource particularly helpful.
- LiveTheDream 14y ago
  Consider "Rails for Zombies"[0]. [0] I teach/tutor Rails, and my students have found this resource particularly helpful.

tenderlove 14y ago

Stupid Sexy Flanders!