my rails stack: - erb for view templates - postgresql for database - rspec/cucumber for testing - skinny models, controllers, and a service layer
Out of curiosity, why do you like rspec over minitest/minispec?
Rails has Two Default Stacks
31–40 of 93 posts
Re: Rails has Two Default Stacks
#32How 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.
I suppose there are different types of beginners to Rails. I can appreciate that I'm not the standard beginner -- I come from a web development background, so certain aspects of learning Rails were frustrating to me because I just wanted to see what was going on under the hood.
Re: Rails has Two Default Stacks
#33How 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.
>beginners get waaay more excited and engaged by Getting Something Up There
Yes! That's why...
require sinatra
get '/hi' do
"Hello World!"
end
Even the file structure of rails is a bit too much for begineers. Everything in one file is so much simpler for trivial beginner "get excited" apps.
Introducing someone to rails, they have to learn MVC, a templating system, an ORM, and more.
Re: Rails has Two Default Stacks
#34Earlier quoted context omitted.
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.
>beginners get waaay more excited and engaged by Getting Something Up There Yes! That's why... require sinatra get '/hi' do "Hello World!" end ...is so amazing for newcomers. Even the file structure of rails is a bit too much for begineers. Everything in one file is so much simpler for trivial beginner "get excited" apps. Introducing someone to rails, they have to learn MVC, a templating system, an ORM, and more.
This breaks down as soon as you have a form, which is basically the next step. While the 'hello world' might be smaller, you outgrow it immediately. Whereas
$ rails new my_app
$ rails g scaffold post title:string body:text
Re: Rails has Two Default Stacks
#35Earlier quoted context omitted.
>beginners get waaay more excited and engaged by Getting Something Up There Yes! That's why... require sinatra get '/hi' do "Hello World!" end ...is so amazing for newcomers. Even the file structure of rails is a bit too much for begineers. Everything in one file is so much simpler for trivial beginner "get excited" apps. Introducing someone to rails, they have to learn MVC, a templating system, an ORM, and more.
This breaks down as soon as you have a form, which is basically the next step. While the 'hello world' might be smaller, you outgrow it immediately. Whereas $ rails new my_app $ rails g scaffold post title:string body:text is still easy to copy/paste/type from a screen, and gives you a lot more to start with.
> gives you a lot more to start with.
I realize there are differences in opinion, but I started programming seriously about 6 or 7 years ago, and I started with ruby/Rails.
For me the scaffolding generated too much to easily digest. And separating everything into models/controllers/views is fantastic for a production app, but almost incomprehensible for a newbie. Veteren developers still argue about whether something should go in a model/controller or some other layer, how is a newb supposed to handle it?
In addition you can build sinatra apps without even talking about hooking up a database.
If you're trying to jump in on the deep end and build an MVP, rails is probably the way to go. However, if I really wanted to teach someone to understand what they were doing without being intimated, I'd start with sinatra.
Re: Rails has Two Default Stacks
#36Coming from a web development background with experience using MVC in Java and Python, I found Michael's Rails Tutorial was basically all I needed to get started, even though I only came to Rails around the time of 3.0. I'm personally really happy to have skipped over ERB entirely and gone straight to HAML. But if I were teaching a web dev newbie, I might use ERB, since it still looks like HTML. Better to keep a few things familiar while someone is learning.
Perhaps Michael's book fills this space, but there may be an opportunity to write an e-book on the Prime Stack, or at least fill in some things the Rails Tutorial leaves out.
Re: Rails has Two Default Stacks
#37Earlier quoted context omitted.
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'.
Re: Rails has Two Default Stacks
#38This is such a clean mental model that I was skeptical. I started scrutinizing it and found myself thinking about how it omits some deployment choices. I realized that this is a good thing, because the development and deployment choices have one big difference: development choices require rewriting when you change them. http://benatkin.com/2013/01/14/steve-klabnik-on-rails-stacks... Thanks for this article, Steve.
> This is such a clean mental model that I was skeptical. This is a great compliment, thank you. I mostly left deployment out because that's not part of Rails' domain: Rack lets us not care about that when building things.
I think it was a good choice to include PostgreSQL even though you can make an app DB-agnostic with rails. It's one of the defining differences between the stacks. I would really like to switch to PostgreSQL on a project I'm working on for future development even though MySQL is working fine now, and this makes me feel more confident about bringing it up to my team.
Re: Rails has Two Default Stacks
#39Earlier quoted context omitted.
This breaks down as soon as you have a form, which is basically the next step. While the 'hello world' might be smaller, you outgrow it immediately. Whereas $ rails new my_app $ rails g scaffold post title:string body:text is still easy to copy/paste/type from a screen, and gives you a lot more to start with.
> gives you a lot more to start with. I realize there are differences in opinion, but I started programming seriously about 6 or 7 years ago, and I started with ruby/Rails. For me the scaffolding generated too much to easily digest. And separating everything into models/controllers/views is fantastic for a production app, but almost incomprehensible for a newbie. Veteren developers still argue about whether something…
It's all about the amount of time you have.
If I'm doing a 3 day engagement, we don't mention scaffolds until after they've hand-built all the code. If you're doing a 8-hour introduction, then yes, you need to use the scaffold.
Re: Rails has Two Default Stacks
#40Earlier quoted context omitted.
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…
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) }
assert @micropost.respond_to?(:content)
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?