Replies inline. You may want to ensure you have supplies before reading this. It's a bit long.
On Friday, 9 March 2012 at 6:45 AM, Trek Glowacki wrote: > So, just to recap the flow of this conversation for myself: > > a) We, as developers *of* Rails (or at least those who lurk here), realize > that we're not the primary target of scaffolding. So, while it could be moved > to gem for pros, it would be hard on new developers if it wasn't baked in and > highlighted in guides/docs > > b) People who have spent time teaching Rails to new folks have chimed in > saying they don't tell people to about scaffolding or, if they show people it > exits, it's with a hand-wavy caveat: don't use this yet, since you don't know > what it's all doing. > > c) Folks who haven't taught Rails (or at least didn't mention it) say the > teaching folks thinking about it backwards: "After you know, using it is a > cheap trick, before then it's a useful way to get an example and dig in." > > d) Other people counter saying "no idea about the n00bs, but I use > scaffolding so much that I have custom scaffolds to match my coding style" That nicely sums it up. I think with C) it's a great way to demonstrate what Rails can provide, but it should be demonstrated with a warning sign of "This is not how we do it normally!", or something along those lines. Regarding D), I've come to recognise that getting rid of scaffolding is probably not the way to go it, since José and Everton have both shown ways that non-noobs use it to a huge advantage, which I love the idea of. > > Thoughts: > * Scaffolding is less useful to new Rails developers – at least those with a > learning resource of some kind – than we assumed > * Scaffolding is more useful to pro Rails developers – especially with > personalization – than we assumed > > Separating/keeping the scaffold generator might be a good Github ticket-based > question for the larger Rails community. Then we'd get a feel for how many > people use it and how they're using it. Good idea. I worry though that the same people that would discuss it on GitHub would also discuss it here. GitHub *does* have a prettier interface though ;) > > If the answer is "hardly anyone and many of those people use customization" > it might indicate that scaffolding generation would be a good 3rd party > project: scaffold users could give scaffolding the loving care it deserves. > The notion that it's a tool for beginners might be holding back some truly > excellent growth > > If the answer is "almost everyone and without customization" then it should > remain as part of core. I'd *still* argue it should be moved out of the > Getting Started with Rails guides I think that we could still keep it in the Getting Started Guide, just to demonstrate what Rails *can* provide you. After that quick win, we can get people into the mindset of creating what the scaffold created by running commands like "rails g controller" and "rails g model", while explaining everything along the route. > > If the answer is "never use it now, but it was invaluably helpful when I was > learning" then the suggestion of making it a more incremental generator that > can build the entire REST pattern over time by running it multiple times > would be awesome. I think this would also jive better with the TDD/BDD > threads floating through Rails. I've always found it odd to talk TDD and then > generate a hundred lines of untested code. > > Incremental scaffolding would generate only the routes, models, migrations, > controller/action, spec/test files and context/describe blocks, for the > specific thin slice of Rails you're currently developing. Running it a second > time with new arguments would slowly build a Rails app with guidance. > > e.g: > > $ rails g scaffold Person > - empty model > - migration to create table > - empty model test file > > possibly we could run tests so after generation there's a clear next step: > write tests > > > $ rails g scaffold Person new create > - model exists > - no migration changes needed > - empty resource controller > - resource controller spec create with context for new and create > - route added: "resources :people, :only => [:new, :create]" > - empty view for new, create > > running later: > $ rails g scaffold Person name:string birthdate:date > > > - model exists (although maybe attar_accessible :name, :birthdate is added > and warning about mass assignment) > - migration created to add name and birthdate attributes > - form partial gets name/birthday fields appended > > > - model test file gets new empty context/describe blocks for added attributes > - no controller or route changes > > I like the idea of an interactive tutorial (tutorails? Thank you, thank you, here all day) Maybe some command that they can run like "rails_tutorial begin" that would generate an application that has a tutorial engine mounted... by way of the gem having a file at config/routes.rb that draws the routes on Rails.application.routes. Because if you had it inside the tutorial app's routes, it may prompt the question "what is this line doing?" which is something for much further down the track. It would create the tutorial app and open their browser to http://localhost:3000/tutorial (or at least tell them what to do). The first page would explain exactly the beginning of Section 2 of Rails, as that's a perfect introduction to what Rails is. I disagree that having MVC right up front as it is in the guide is a good idea. This should be introduced after a quick win. The next part of the tutorial gets the user to generate a posts scaffold and explains what functionality it provides: "allows you to create, read, update and delete posts. This is often referred to as CRUD". Encourage the user here to play around with the scaffold (give them objectives, like to create posts, edit one, delete one) and get them familiar to the flow of how it works. The third step destroys the scaffold, explaining that it's not how things are done in the real world. Then we get the user to create a new posts controller, explaining here what controllers are. The "C" layer of MVC. Fourth: get the user to create a new action for the controller. Explain what actions are and how they work. Explain routing. Show the long form of "match 'posts/new', :to => 'posts#new'" so that they understand routing from the beginning. The new action's job is simply to provide a form to create a new post. For this, the user will need to create a model (and this is where you explain the "M" layer) and then a view (the "V" layer). That's how you've got MVC explained. You're walking them through each part of it as its needed, rather than explaining it immediately and up front. Fifth: The user makes a create action in the controller. Explain that forms that create data should use POST requests. Here would perhaps be a good place to explain REST. Add a flash notice to the create action, just like there is in the scaffold. Explain what this does. Sixth: Add a validation to the model. Show them that they can no longer save a post without a title. This would require editing of the controller action. Seven through to ???: Draw the rest of the fucking owl. (ref: http://s3-ec.buzzfed.com/static/imagebuzz/web03/2010/8/24/11/how-to-draw-an-owl-25123-1282662850-14.jpg) Point is: a tutorial that walks users through building a resource *from scratch* is so much more helpful than one that walks them through building one with scaffolding. > > - @trek > > > > On Thursday, March 8, 2012 at 8:26 PM, Mark Ratjens wrote: > > > My first gut feeling was "kill it, kill it". But then, I am the kind of > > person that tends to spring-clean then regret throwing away too much. > > > > The Wow factor is what got me into Rails in the first place, even though I > > quickly refactored the scaffold code I had generated ... and never looked > > back. Scaffolds help lower the barrier to newbies. I may not have jumped > > out of Java into Rails as quickly if that barrier was higher. But that was > > 2005 ... > > > > So I think it's an issue of education. Trainers, mentors and senior devs > > need to 'pace' newbies. > > > > 1) Show them scaffolds. Let them go 'wow.' > > 2) Develop an example to the point where scaffolds become problematic. Let > > them grok the cul-de-sac they're in. > > 3) Fix the problem by showing them how controllers are really developed. > > > > You can't go directly from step 1 to step 3, because many of them will > > still be basking in the glow of the wow. The won't be attending to what > > you're trying to show them. As some have said, their mental models could be > > distorted. > > > > Mark Ratjens > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby on Rails: Core" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/rubyonrails-core/-/MxELMN9M7OYJ. > > To post to this group, send email to [email protected] > > (mailto:[email protected]). > > To unsubscribe from this group, send email to > > [email protected] > > (mailto:[email protected]). > > For more options, visit this group at > > http://groups.google.com/group/rubyonrails-core?hl=en. > > > > > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to [email protected] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]). > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
