Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rails has Two Default Stacks

words.steveklabnik.com

Post reply on HN
Print view View original

41–50 of 93 posts

Re: Rails has Two Default Stacks

#41

Post by Argorak »

steveklabnik wrote: post #30
natural219 wrote: post #29

How do these two options stack up to just not using Rails and using something like Sinatra instead for beginners? When I started with Rails, I spent 2 days figuring out the standard web framework functions / workflow, and then I gave up. When I picked up Sinatra, the pieces were small enough that I could learn them individually, master them, and learn how they were put together. Then, when I came back to Rails, I had…

With Sinatra you have absolutely no guidance as to what's good and what's not: there's no stack at all. I, too, am a bottom-up learner, but most people (in my professional experience) are not. Look at the success of Rails Girls, for example: beginners get waaay more excited and engaged by Getting Something Up There than they do learning the intricate details of HTTP.

There is no stack for sinatra, but there are certainly stacks on top of sinatra that don't take the Omakase-approach[1]. This has several benefits: they expect users to make decisions early on and to get informed about the components they use. With Rails, you generate a default stack and have to find your way around and then - potentially - have to learn the replacements. The upgrade from "basic" to "prime" is costly and often - just for that reason - is avoided.

This is much to the harm of components that might be a better fit for a project: I still believe that Sequel is a much better ORM for people that care about their SQL database and I frankly find it underused in the Rails world. Outside of Rails, its actually rather common, because it has a lot of merits.

I found teaching Padrino strictly better than teaching Rails (I do both), because you can teach it component by component and the missing "standard" stack is one of the reasons. Its much easier to teach it "the hard way".

[1]: Obvious, shameless plug: http://padrinorb.com , now with more development speed.

Re: Rails has Two Default Stacks

#42

Post by somlor »

programminggeek wrote: post #20

What would help Rails the most is probably some example projects. They could be anything ranging from simple twitter clones to maybe full on e-commerce stores or something. Build them using the "golden path" and maybe someone else could build the same thing using the "prime" stack. When I started the Obvious architecture, writing an example app made it concrete and makes it a lot easier to explain particular details…

These example Rails app tutorials look promising: http://railsapps.github.com

I'm still working through Michael Hartl's tutorial, but plan to work through each of these afterwards.

Re: Rails has Two Default Stacks

#43

Post by stevewilhelm »

Which stack is better for more complex user interfaces?

We have a dashboard app that must integrate data from several models into a single display that allow users manipulate the parameters to each specific model independently.

Re: Rails has Two Default Stacks

#44

Post by cglee »

milesf wrote: post #3

Using Steve's definitions from the article, the tutorial I usually point people to is Michael Hartl's Rails Tutorial 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 an…

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.

Re: Rails has Two Default Stacks

#45

Post by Argorak »

natejenkins wrote: post #40
doktrin wrote: post #28

Earlier quoted context omitted.

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 re…

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.

Re: Rails has Two Default Stacks

#47

Post by lazyGeneral »

cglee wrote: post #44
milesf wrote: post #3

Using Steve's definitions from the article, the tutorial I usually point people to is Michael Hartl's Rails Tutorial 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 an…

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

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

Re: Rails has Two Default Stacks

#48

Post by lazyGeneral »

Argorak wrote: post #45
natejenkins wrote: post #40

Earlier quoted context omitted.

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 re…

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.

Re: Rails has Two Default Stacks

#49

Post by cheald »

natejenkins wrote: post #40
doktrin wrote: post #28

Earlier quoted context omitted.

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 re…

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

    @micropost.should respond_to(:content)
is perfectly valid, and IMO, much cleaner.

Re: Rails has Two Default Stacks

#50

Post by cglee »

lazyGeneral wrote: post #47
cglee wrote: post #44

Earlier quoted context omitted.

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

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 Te…

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