Live data from Hacker News

Rails has Two Default Stacks

words.steveklabnik.com

71–80 of 93 posts

Re: Rails has Two Default Stacks

#71
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…

Stupid Sexy Flanders!

Re: Rails has Two Default Stacks

#72
The prime stack is going to have some real problems as Rails 4 goes threadsafe by default, as haml isn't threadsafe. I guess this won't be a problem for those on process-based servers, but it's going to be an issue for those embracing multi-threaded app servers.

Re: Rails has Two Default Stacks

#73
post #49

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…

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!

Re: Rails has Two Default Stacks

#74

The prime stack is going to have some real problems as Rails 4 goes threadsafe by default, as haml isn't threadsafe. I guess this won't be a problem for those on process-based servers, but it's going to be an issue for those embracing multi-threaded app servers.

> ...haml isn't threadsafe.

Could you elaborate on this, please?

Re: Rails has Two Default Stacks

#75
As a fairly new programmer (I started learning testing using rspec. Now I'm starting a new job where they use test unit for testing. The transition has not been too difficult because the difference between the two are too crazy.

If you pick one route and learn the basics, you shouldn't have too much trouble switching over to the other.

Re: Rails has Two Default Stacks

#76

The prime stack is going to have some real problems as Rails 4 goes threadsafe by default, as haml isn't threadsafe. I guess this won't be a problem for those on process-based servers, but it's going to be an issue for those embracing multi-threaded app servers.

> ...haml isn't threadsafe. Could you elaborate on this, please?

It appears to swap out $stderr with a StringIO and StringIO isn't threadsafe and then doesn't wrap it in a lock. It's been tripping up people in the #jruby channel.

This is a gist from one earlier today: https://gist.github.com/be34c0a5666db0c83629

Re: Rails has Two Default Stacks

#77

Earlier quoted context omitted.

One of the things that got me thinking about this was the recent security issues. I was helping people on Skype upgrade their apps, because they were new, and they got into Gem Version Hell. Only pulling in fancy gems when you need it helps when you _really_ need to upgrade, and you're not stuck figuring out why twitter-bootstrap-rails, therubyracer, and libv8 (in this example, obviously, it could be any combination…

That says to me that understanding bundler is REALLY important. If someone understood how bundler worked, there is NO reason therubyracer, twitter-bootstrap-rails, libv8, or any other gem should get in the way of upgrading (say for example) from Rails 3.2.5 to 3.2.11. `bundle update rails`, then check in your new Gemfile.lock That should change nothing but Rails and rails' own upstream dependencies (not any of the on…

> But to apply a security release, when you are on a maintained minor release (3.0, 3.1 or 3.2)? If you understand how bundler works, you are HIGHLY unlikely to have any troubles.

Right, but it DID happen. Updating the Rails version updated the versions of other gems too. I know what you're saying, but the reality was different.

Re: Rails has Two Default Stacks

#78
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…

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

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.
Post reply on HN