Rails has two default stacks

[Maurício Linhares]

Saw this on twitter yesterday from @steveklabnik ->
http://words.steveklabnik.com/rails-has-two-default-stacks

And got curious about this. Excluding HAML, which I'm pretty sure a
lot of people hate to death (while I personally love it, but that's
something else), the "prime" stack seems to be the new gold standard
everywhere, specially since Heroku, as you only get PostgreSQL for
free in there.

Most of the projects I've seen around are using RSpec for testing (in
fact, in 5 years doing Rails, I never worked on a project that used
something else for testing...), they use factory_girl (or one of the
other ones, like machinist) instead of fixtures and over this last
year more and more people are using service layers instead of just
stuffing up their models.

So, while Rails definitely decides to use those tools on the first
stack, I don't see people out there doing it. Even most tutorials will
pick tools from the "prime" stack (like Michael Hartl's using RSpec in
his book) instead of using vanilla Rails. But maybe I'm going out with
the wrong people out there and there is still a lot of projects being
done with the default stack.

What are you guys using nowadays?

-
Maurício Linhares
http://techbot.me/ - http://twitter.com/#!/mauriciojr

[Daniel Higginbotham]

This is my setup as well, though often I use mongo for the db. Even with HAML, I can't think of anyone who's learnt it and still prefers to use ERB. The only exception there being… well, me, when I'm doing angular stuff, because cramming a bunch of "ng-whatever" => "someValue" declarations on one line ends up being uglier than plain HTML.

But yeah - the "prime" stack is my default. Interestingly, spec has 6.4M downloads while minitest has 1.3M, according to rubygems.org

> --
>
>

[Michael Breen]

I've learned Haml and Slim and still prefer Erb.

> --
>
>

[Ben Tucker]

On Tue, Jan 15, 2013 at 8:06 AM, Daniel Higginbotham <dan...@flyingmachinestudios.com> wrote:
> cramming a bunch of "ng-whatever" => "someValue" declarations on  one line ends up being uglier than plain HTML

HAML actually supports using multiple lines for element attributes.   So these are both valid:

          %p{:foo => "bar",
                :baz => "foo",
                :fiz => "boo"}

          %p(foo = "bar"
               baz = "foo"
               fiz = "boo")

-Ben

[Daniel Higginbotham]

yaaaaay! thanks!

--
 
 

[Patrick Robertson]

This may be my old man 'get off my lawn' sentiment surrounding the Rails community but the 'Oh, think of the beginner' argument for changing the stack defaults for Rails got old for me about five years ago.  The bike shedding about default stack choices got old for me prior to even starting with Rails.  The happiest path is one in which we can all paint our bike shed whatever color we want.

I consider there to be two areas of learning for beginning developers: theoretical CS knowledge and vocational programming choices.  The tech stack is entirely the latter and not difficult to teach.  If your junior developer learns mini-test instead of RSpec and they cannot pick up the differences between the DSLs without too much suffering you've likely hired the wrong junior developer.  If the newbie has difficulty grasping the concepts of BDD and isolating unit tests; that's entirely different.  There is a lot of theory to teach behind Rails development that can be entirely independent of the discussion of the tools.  I am largely concerned about peoples grasp of theory.  I will always be disappointed when someone is incapable of applying said theory to a specific DSL.

I don't know of a professional Rails shop that hasn't invested the time in building some sort of repeatable Rails template since the feature was implemented.  Some shops may just opt for OSS versions of said templates instead of painting their own bike shed.  Wasting time arguing with DHH about what template engine is best for everyone is generally a pointless endeavor.

'get off my lawn' rant over.

- Patrick

--
 
 

[Daniel Choi]

Steve Klabnik's main point in this blog post seems to be that the schism between super-aggressive proponents of the "Prime" stack and the proponents of the "37 Signals default" stack is hurting beginners who are already way too overwhelmed by the mass of stuff they have to learn. As you multiply these component choices for beginners and the cognitive load for beginners goes quickly up to the breaking point. When some of us learned Rails 5+ years ago, there was no HAML vs ERB, no SCSS vs vs less vs CSS, no RVM vs rbenv, no rspec vs Test::Unit, no fixtures vs factories. We didn't have to worry about researching and making these sorts of choices, so we just focused on learning what Rails "convention" told us to do. Learning Rails was way easier 5 years ago partly for this reason. 

(If you want to learn about the serious cognitive burden that having too much choice produces, I recommend "The Paradox of Choice: Wy More is Less" by Barry Schwartz.)

Klabnik really wants to help the poor souls who are starting to learn Rails today. So he is proposing something pretty bold:

"But we’re leaving the majority in the dust. Rather than trying to push the boundaries by choosing new techniques, maybe we should be helping people get better at existing ones, too. Because we need both approaches. There’s already so much to learn when building a Rails application, adding more gems and techniques to the pile just isn’t going to help... Let’s keep pushing those boundaries, but let’s not require someone to catch up on a few hundred episodes before they can understand what’s going on."

Correct me if I'm wrong, but sounds to me that Klabnik is proposing that people who are expert at Rails and who want to help beginners should (1) know the default stack, (2) not dis the default stack in the presence of beginners, and (3) happily teach the default stack to beginners. I think that is a pretty bold proposal, and I like it.

Dan

[Patrick Robertson]

I think we're on the same page Dan.  I think a majority of the professional Rails community isn't on that page though :(.  I believe a lot of people still believe that if HAML/RSpec/JS were the default settings the beginner would be better.

- Patrick

--
 
 

[Dylan Cashman]

The way I see the problem is the most vocal developers are incredibly dogmatic over their choices, but they fail to recognize that the context and experience that allowed them to make those choices is invisible to new developers.  To a beginner, the choices seem arbitrary and it discourages them from the idea that they'll ever have a full grasp on the technical stack.  In some ways, this constant refinement of tools and the dogma needed to sustain them is the reason why open source software is always progressing.  It's hard to deny that it isn't discouraging to newcomers, though.

I think that anytime you learn something technical, you never get a full understanding of the complicated parts unless you learn the basic ones.  You need to understand why certain choices were made and those complicated solutions were reached.  So I agree with Dan's conclusion of the article.

--
 
 

--
Dylan Cashman
Annkissam - Mission Driven Systems
www.annkissam.com

One Broadway, 14th Floor
Cambridge, MA 02142
Cell (preferred): 617-999-3634
Office: 617-401-2480, ext. 708
Fax: 617-507-5922

[Maurício Linhares]

What seems fishy to be is that you still have to learn minitest, using
fixtures, ERB, rbenv or whatever, since no one was born a developer
knowing them.

What's the difference between this and learning rspec, factory_girl and rvm?

If the beginners are being told, by their peers, to use this latter
selection, why is it bad for them if it's all a matter of choice and
style?

This is what I can't grasp. It isn't that complicated to edit a
Gemfile (if it is, well, I'd concur with Patrick and say the wrong guy
was hired).

[Daniel Higginbotham]

I don't know that I agree that Rails was way easier. Remember FastCGI vs SCGI (or whatever) vs Mongrel? Or fixtures vs. foxy fixtures?

Adding to what Patrick wrote about theoretical vs. vocational knowledge, I think there's a layer in the middle encapsulating knowledge about what a web app is. Perhaps the reason why Rails v0.14 seems easier is that most of us came at it after having gotten frustrated with PHP or Struts or something like that, so when we saw Rails we already had the experience necessary to grok it. That's what lets us see HAML vs ERB as more a matter of taste; the important thing is that you're using an MVC architecture and not putting your entire app in one PHP file.

Whereas nowadays people are trying to learn Rails as their very first programming assignment. Without some background in web apps they're not able to distinguish between what's essential and what's a matter of taste.

--
 
 

[Jeremy Weiskotten]

There was an interesting Ruby Rogues podcast recently about learning from the past. I think there are some parallels to this discussion. 

http://rubyrogues.com/086-rr-learning-from-the-past-with-arlen-walker/

My takeaway was that there's value in understanding how we got to where we are now, but that there's also value in having some curated knowledge like design patterns. It would take more than a lifetime to understand every evolutionary step in CS/programming history, so at some point we need to fast forward to make newbies productive.

Similarly, it's good to have some "rules" for newbies to follow (like Law of Demeter, SRP, etc) and with experience you learn when it's OK or even beneficial to violate the rules. There's a certain amount of pain people need to experience before the lessons sink in.

In the interest of forward progress, I don't have a problem with the community experimenting to suss out the most "teachable" stack. What worked 5 years ago might not be the best option today, and I think that how you teach/learn has more influence than the subject you're teaching/learning. I do wish there were a more structure, scientific way to measure and compare different approaches.

Jeremy

--

[Michael Breen]

On Jan 15, 2013, at 10:49 AM, Maurício Linhares <mauricio...@gmail.com> wrote:

What seems fishy to be is that you still have to learn minitest, using
fixtures, ERB, rbenv or whatever, since no one was born a developer
knowing them.

What's the difference between this and learning rspec, factory_girl and rvm?

The difference is that "Rails is omakase"*. If you are just coming to Rails to need to initially accept and learn what the chef has chosen before you deviate from selected menu. 

* http://david.heinemeierhansson.com/2012/rails-is-omakase.html

[Mark Donnelly]

On Tue, Jan 15, 2013 at 10:49 AM, Maurício Linhares <mauricio...@gmail.com> wrote:

If the beginners are being told, by their peers, to use this latter
selection, why is it bad for them if it's all a matter of choice and
style?

I think that the way that it's bad is that they are being told by one set of peers to use MiniTest/rvm/ERB/..., and being told by another set of peers to use Cucumber/RSpec/rbenv/HAML/...  So, in the face of this conflicting advice, a beginner must learn enough about both sides of each of the choices to decide between them.

--Mark

[Joel Oliveira]

If I could boil down all my life decisions to the level of difficulty of which "flavor" stack of rails -- then sign me up. Why the angst? From my perspective the lesson here is to encourage people not to succumb to analysis paralysis. Pick something that looks interesting and go with it. 

Not too long ago that was me and I went with rspec, cucumber, erb and mysql. "Hey, those look just fine for me, so I'll go with that.".  I learned what I could, where I could, and never looked back. 

Am I wrong or am I hearing that there are people maintaining the thought or belief that certain people feel they have to learn everything in order to compete?  Or learn? That's the part in this that needs to be discouraged. Pick what looks good, and go. Want to be like 37 signals? Go with that stack. Want to be like thoughtbot? Go with that.

Or, maybe, are we not giving these newbies enough credit here? Can someone relatively fresh to this experience of starting with rails chime in here?

--
 
 

[Dan Pickett]

Great discussion. I'm glad someone brought this up on the list.

This all reminds me of Andy Hunt's Journey From Novice to Expert stages where he says: "Use rules for novices, intuition for experts" - (PS: Pragmatic Thinking and Learning is a must read :-))

I don't think anyone will argue that having options is a bad thing, but the #1 type of questions I get from folks learning rails are of the flavor: "Should I use test/unit or RSpec?" "Postgres or MySQL?" - I think novices don't want to go down the wrong path, and are looking for someone experienced to tell them what the 'right' choices are. The way I position it is that, if setting up a Rails environment was a standardized test, these technology questions would be much more of an open ended question than a set of multiple choice questions - there is no right answer, and you should just be able to defend your decisions based on what you know of the landscape and what your business needs.

Still, for beginners to learn fundamentals, I do think there needs to be a benevolent dictatorship/rules, and I personally would side with few of the Rails default decisions. I stopped worrying about it, though, when CoffeeScript was added as a 'reasonable default.' That's why we have rails templates.

When teaching, I think it's important to say things like "there are many options for shaving this yak, but we're using the clipper method because we think it's easiest to understand. In your free time, you should check out the buzzer and shear methods to weigh pros and cons."

Best,

Dan

--
 
 

--

=========================

Dan Pickett

Principal at LaunchWare, Inc.

launchware.com | twitter.com/dpickett | twitter.com/launchware

[Daniel Choi]

Sorry for the tangent but if anyone wants to see what a world-class Japanese "omakase" style sushi experience is like, you won't regret watching this awesome documentary:

Jiro Dreams of Sushi

[Robert Thau]

Maurício Linhares writes:
> What seems fishy to be is that you still have to learn minitest, using
> fixtures, ERB, rbenv or whatever, since no one was born a developer
> knowing them.

One possible difference, on the front end, is that ERB is a lot closer
to the syntax of the underlying HTML than HAML is. Which, in turn,
means that if you want to understand what you're seeing in Firebug (or
Chrome Developer Tools, or whatever) you have to understand a more
complicated translation. And likewise if you're trying to apply
information you got from, say, a book on HTML and CSS styling to the
templates in your app.

Now, you can see, say, ERB and HAML as alternate context syntaxes for
the same abstract syntax --- and if you understand things that way,
the translation is pretty trivial. And for an experienced developer,
the tradeoff is the extra conciseness you get from HAML vs. the
minimal effort to do the translation.

A beginner, on the other hand, has no idea what the underlying abstract
syntax is, and without that knowledge, the translation looks a lot more
like a disorganized set of arbitrary rules, which makes it a whole lot
harder to deal with.

Or at least, that would be my rationalization for not necessarily
starting beginners off on HAML and coffeescript, even if I'd use both
on a greenfield project of my own...

rst