Re: [Rails-core] Re: Please, keep changing!
On Domingo 04 Marzo 2012 20:36:12 Michael Schuerig escribió: On Thursday 01 March 2012, Consu wrote: What will it cost in real money, to upgrade a bigger Rails App? For the past few weeks I've been working on Rails app that has grown over about 3 years to around 25kloc. The app was stuck at Rails 2.1.2, uses quite a few gems/plugins and had a fair number of monkey patches to Rails itself and the plugins. It took me 20 to 30 days to convert this app to Rails 3.2.2; the exact amount of days is hard to pinpoint as I did a lot of other cleanup and things that weren't strictly necessary, such as rewrite queries in the new style. Simply put, the effort I spent on this task is utterly negligible compared to the programming effort in the life of that application so far. Even more so when the whole project is considered. What made this update possible at all was the solid test coverage. I agree with you, Michael. When a developer says you know things will break, you just don’t know what, when and how., it seems to me that there is a lack of solid test coverage that would show up those failures. I join to thank the core-team members and the community for all the great work of these years. We love you! 3 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: Please, keep changing!
Em 08-03-2012 05:31, Antonio Tapiador del Dujo escreveu: On Domingo 04 Marzo 2012 20:36:12 Michael Schuerig escribió: On Thursday 01 March 2012, Consu wrote: What will it cost in real money, to upgrade a bigger Rails App? For the past few weeks I've been working on Rails app that has grown over about 3 years to around 25kloc. The app was stuck at Rails 2.1.2, uses quite a few gems/plugins and had a fair number of monkey patches to Rails itself and the plugins. It took me 20 to 30 days to convert this app to Rails 3.2.2; the exact amount of days is hard to pinpoint as I did a lot of other cleanup and things that weren't strictly necessary, such as rewrite queries in the new style. Simply put, the effort I spent on this task is utterly negligible compared to the programming effort in the life of that application so far. Even more so when the whole project is considered. What made this update possible at all was the solid test coverage. I agree with you, Michael. When a developer says you know things will break, you just don’t know what, when and how., it seems to me that there is a lack of solid test coverage that would show up those failures. I kind of understand this feeling. I don't write tests for my views, for example. So, you'd have to manually check all your views to see if some Rails changes in the view layer broke your application... I'm curious... How many of you are really testing the output of your views? I'm not talking about integration tests where you use only a few parts of the view to test some specific behavior. Cheers, Rodrigo. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] Scaffold Generator Woes
Hello friends, It's been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they're doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. I think that we can fix this problem in one of two ways, the latter more extreme than the first one. The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the correct way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the real world. The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn't even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the sanctioned way to create controllers. Thoughts? -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
I would be in favor of either of these two options. I imagine extracting and gem-ifying the controllers would be a hassle, but then the default path for setting up a new view and controller action would require the user to think about what they are doing rather than just observe the magic. Unfortunately, I think that even if we were to extract out to a gem that every non-official tutorial and book would just tell users to add rails_controller_generators to their gemfile as the first step, and the intended goal of this work would be completely bypassed. On Thu, Mar 8, 2012 at 1:30 PM, Ryan Bigg radarliste...@gmail.com wrote: Hello friends, It's been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they're doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. I think that we can fix this problem in one of two ways, the latter more extreme than the first one. The first way is that we *completely change the Getting Started Guide to simply *mention* the scaffold generator*, but then show people the correct way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the real world. The second way, and sorry if this sounds a little extreme, is to *completely remove the scaffold generator from the core of Rails* itself. This means that there wouldn't even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the sanctioned way to create controllers. Thoughts? -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
Every time I use that generator, I always regret it. It's just so easy, so tempting... That said, it's something that Rails has had since the beginning of time, and was an original selling point. That said, you could _still_ do the fifteen minute blog video, you'd just run three commands instead of one. It would _also_ probably cause another internet shitstorm. I can see zillions of blog posts now. There's no such thing as bad press... A big 4.0 release means a time to rethink old sacred cows. Changing the guide would help new people, but removing it entirely would be better. I like it. :) -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
On Thu, Mar 8, 2012 at 4:38 PM, Geoff Harcourt geoff.harco...@gmail.com wrote: I would be in favor of either of these two options. I imagine extracting and gem-ifying the controllers would be a hassle, but then the default path for setting up a new view and controller action would require the user to think about what they are doing rather than just observe the magic. Unfortunately, I think that even if we were to extract out to a gem that every non-official tutorial and book would just tell users to add rails_controller_generators to their gemfile as the first step, and the intended goal of this work would be completely bypassed. Pretty much this. Also, everyone using old books/tutorials (pre 4.0) will run into trouble. Don't get me wrong, I'm wholly in favor of killing it. Repeatedly. And violently. But truth is, it's hard do kill something that has been around this long, and that is included in pretty much all tutorials for rails that have existed since The Beginning of Time. Not sure what the best approach is. -foca On Thu, Mar 8, 2012 at 1:30 PM, Ryan Bigg radarliste...@gmail.com wrote: Hello friends, It's been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they're doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. I think that we can fix this problem in one of two ways, the latter more extreme than the first one. The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the correct way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the real world. The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn't even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the sanctioned way to create controllers. Thoughts? -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
On Thursday, 8 March 2012 at 10:58 AM, Nicolás Sanguinetti wrote: On Thu, Mar 8, 2012 at 4:38 PM, Geoff Harcourt geoff.harco...@gmail.com (mailto:geoff.harco...@gmail.com) wrote: I would be in favor of either of these two options. I imagine extracting and gem-ifying the controllers would be a hassle, but then the default path for setting up a new view and controller action would require the user to think about what they are doing rather than just observe the magic. Unfortunately, I think that even if we were to extract out to a gem that every non-official tutorial and book would just tell users to add rails_controller_generators to their gemfile as the first step, and the intended goal of this work would be completely bypassed. Pretty much this. Also, everyone using old books/tutorials (pre 4.0) will run into trouble. Don't get me wrong, I'm wholly in favor of killing it. Repeatedly. And violently. But truth is, it's hard do kill something that has been around this long, and that is included in pretty much all tutorials for rails that have existed since The Beginning of Time. Not sure what the best approach is. -foca In Rails 2 there was the removal of the scaffold method from the controllers. A major version then was the perfect time for that, and over time tutorials adjusted. If it was removed here, the same thing would occur. On Thu, Mar 8, 2012 at 1:30 PM, Ryan Bigg radarliste...@gmail.com (mailto:radarliste...@gmail.com) wrote: Hello friends, It's been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they're doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. I think that we can fix this problem in one of two ways, the latter more extreme than the first one. The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the correct way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the real world. The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn't even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the sanctioned way to create controllers. Thoughts? -- 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). For more
[Rails-core] Re: Scaffold Generator Woes
Anecdotally I can remember a few times I was glad, scaffolds existed like when teaching Rails classes to beginners, and having them excited to get started so quickly. I can also remember more than a few times I regretted using a scaffold after having to heavily remove or modify most of the code it generated. Rather than lean on either of these sets of experiences, is there some way we can test and validate that this would make using rails for beginners easier in the long run? Serious question. I'll be happy to A/B test-teach this to a group of students if we could come up with some reliable way of measuring success. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: Scaffold Generator Woes
IMO, the best value of scaffolds is writing custom ones for common tasks in your own application. I've done this on a number of occasions. It's easy and I think it's a quite under-utilized feature of rails. While basic CRUD is probably better delegated to engine's now. the core concept in scaffolds seems to be that setting up an app quickly and taking the busy work out of building common things that need to be hand customized. Even an engine for admin UIs will have boilerplate. So why not combine these two approaches? TL;DR Don't throw the baby out with the bathwater. Chris Eppstein On Thu, Mar 8, 2012 at 11:09 AM, richard schneeman richard.schnee...@gmail.com wrote: Anecdotally I can remember a few times I was glad, scaffolds existed like when teaching Rails classes to beginners, and having them excited to get started so quickly. I can also remember more than a few times I regretted using a scaffold after having to heavily remove or modify most of the code it generated. Rather than lean on either of these sets of experiences, is there some way we can test and validate that this would make using rails for beginners easier in the long run? Serious question. I'll be happy to A/B test-teach this to a group of students if we could come up with some reliable way of measuring success. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
I spent 4 years using Rails as a teaching language both inside and outside a local University. We stopped telling students that scaffolding even existed after two semesters. It wash't that, as you might except, we had a problem with generating code instead of doing work by hand. Instead we saw that encountering scaffolding as an early Rails concept led many students to develop a totally bonkers mental model about the framework and web applications. Scaffolding set them up to fail. My general feeling after seeing it in action: A: You're not doing a beginner any favors. This holds true for a number of other things that I'd love to see demonstrated long-form in the guides before the shortcuts are introduced. `resource`-style routes and form helpers are awesome time/LOC-savers when you know what they're doing. When you don't, they're dark and mysterious magic words that you dare not examine too closely. When we teach student the Rails-style REST pattern conceptually, show them how to connect routes, controllers, and models themselves, then show them the handy time-savers provided by the framework they perform better and appreciate the niceties more. B: the advantages of Rails in 2012 aren't the same as the advantages of Rails in 2005. In 2005 relatively few people writing web apps separated concerns into different types of objects, followed any particular organization pattern, wrote tests, or any of the the practices that made Rails seem like such a breath of fresh air. Now basically every app framework – regardless of language – follows these as best practices. Routing, MVC, tests, are all important to highlight but they're par for the course. Scaffolding may have had some use in 2005 – it showed you how to properly write Rails before there was a body of well-written apps to examine – but there are better solutions to this problem now. The advantages in Rails today have to do with large, enthusiastic (although sometimes overly curt) developer community, the ecosystem of well written and tested Rails-compatible libraries, the collection of good instructional material both in the project itself (Guides) and from 3rd parties, and the fact that Rails is still one of the places were smart people are experimenting with different (hopefully better) ways of making applications. These are the things I'd miss if I was working with other tools and I think it's what we should focus on highlighting and improving. - @trek On Thursday, March 8, 2012 at 1:39 PM, Steve Klabnik wrote: Every time I use that generator, I always regret it. It's just so easy, so tempting... That said, it's something that Rails has had since the beginning of time, and was an original selling point. That said, you could _still_ do the fifteen minute blog video, you'd just run three commands instead of one. It would _also_ probably cause another internet shitstorm. I can see zillions of blog posts now. There's no such thing as bad press... A big 4.0 release means a time to rethink old sacred cows. Changing the guide would help new people, but removing it entirely would be better. I like it. :) -- 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
On Friday, 9 March 2012 at 7:30 AM, Ryan Bigg wrote: Hello friends, It's been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they're doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. I think that we can fix this problem in one of two ways, the latter more extreme than the first one. The problem here is that none of us are the target audience for the scaffold generator, so we're a terrible group to make decisions on its long-term utility. It isn't, and never has been, intended as a way to create controllers which you just commit and ship, it's a tool for giving an example controller and set of views which let's a new user get a feel for how it all hangs together. Without something like this you start with a two line controller file and have *no* idea how anything works. Sure it's great if everyone reads all the documentation and learns all the details of how actions and views interact before they write a single line of code, but the reality is people don't do that. The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the correct way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the real world. Changing the guides to use the scaffold generator only as an example seems like the best bet. Simply generate a controller, walk the user through how it works, show how to add an action and test, then never return to the scaffolding at all. The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn't even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the sanctioned way to create controllers. This is a step too far in my book, there's valuable functionality here for newcomers and moving it to a plugin means it's no longer available to them but *is* available to the rest of us. WTF would the point of that be ;) Thoughts? -- 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. -- Cheers, Koz -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
I agree with pretty much everything everyone has said in terms of the scaffold
being a detriment in setting up the wrong mental model for newbies. It has also
been a long time since I've used the scaffold generators.
However, I try not to forget what my mindset was back then, before I knew what
I was doing. I remember really liking scaffolding back in the Rails 1 days when
it was a macro rather than a generator. And I also remember how much more I
liked it when it changed to being a generator, in terms of being less magical
and more logical.
Perhaps we can keep moving in the right direction without a dramatic change.
I'll throw out a couple ideas that aren't quite as dramatic as what has been
mentioned…
What if we kept the scaffolding generators, but changed the command to be more
explicit, making the user think about what's happening? For example, instead of
just blindly setting up all the CRUD actions and routes, what if you had to
pass in the names of the methods you want and the REST methods they use? E.g.
rails generate scaffold Article name:string title:string content:text
index:get show:get edit:get create:post update:put
Notice in the above, I don't have any destroy action being created, since I
didn't specify it. This could raise awareness of the controller actions and
routes that are being set up.
Then we could populate the controller actions with suggestions rather than
actual running code. So for example, the generated #create action could look
something like this:
# POST /article
# POST /article.xml
def create
# This is your #create action, accessed via a POST request to the /article
relative URL
# (which can be customized in config/routes.rb).
# Below is some boilerplate code you can uncomment to get going.
# Be sure to edit and customize the code as needed by your application.
#@article = Article.new(params[:article])
#
#respond_to do |format|
# if @article.save
#format.html { redirect_to(@article, :notice = 'Article was
successfully created.') }
#format.xml { render :xml = @article, :status = :created, :location
= @article }
# else
#format.html { render :action = new }
#format.xml { render :xml = @article.errors, :status =
:unprocessable_entity }
# end
#end
end
In the above example, I think just making people uncomment code for it to work
would make them give some thought to what they're doing, and make it clear that
this code is just a suggestion to get started, which needs customization.
-- Steve Schwartz
On Thursday, March 8, 2012 at 2:20 PM, Trek Glowacki wrote:
I spent 4 years using Rails as a teaching language both inside and outside a
local University. We stopped telling students that scaffolding even existed
after two semesters. It wash't that, as you might except, we had a problem
with generating code instead of doing work by hand. Instead we saw that
encountering scaffolding as an early Rails concept led many students to
develop a totally bonkers mental model about the framework and web
applications. Scaffolding set them up to fail.
My general feeling after seeing it in action:
A: You're not doing a beginner any favors. This holds true for a number of
other things that I'd love to see demonstrated long-form in the guides before
the shortcuts are introduced. `resource`-style routes and form helpers are
awesome time/LOC-savers when you know what they're doing. When you don't,
they're dark and mysterious magic words that you dare not examine too closely.
When we teach student the Rails-style REST pattern conceptually, show them
how to connect routes, controllers, and models themselves, then show them the
handy time-savers provided by the framework they perform better and
appreciate the niceties more.
B: the advantages of Rails in 2012 aren't the same as the advantages of Rails
in 2005. In 2005 relatively few people writing web apps separated concerns
into different types of objects, followed any particular organization
pattern, wrote tests, or any of the the practices that made Rails seem like
such a breath of fresh air. Now basically every app framework – regardless of
language – follows these as best practices. Routing, MVC, tests, are all
important to highlight but they're par for the course. Scaffolding may have
had some use in 2005 – it showed you how to properly write Rails before there
was a body of well-written apps to examine – but there are better solutions
to this problem now.
The advantages in Rails today have to do with large, enthusiastic (although
sometimes overly curt) developer community, the ecosystem of well written and
tested Rails-compatible libraries, the collection of good instructional
material both in the project itself (Guides) and from 3rd parties, and the
fact that Rails is still one of the places were smart people are
experimenting with different
Re: [Rails-core] Scaffold Generator Woes
I don't really get it. I've been using the scaffold for a while, never knew it wasn't the sanctioned way of doing things. Many times all I need is a CRUD. The amount of customization I have to do is minimized by having project specific templates in lib/templates, and scaffold saves me quite some time. Even if I have to rewrite some or most of the generated code, I still think it's pretty useful. I agree, thought, that you really shouldn't use the scaffold if you're a beginner and doesn't know what's going on. When I'm teaching Rails I use the scaffold for a 15-minute WOW factor, but then I jump straight to doing it piece by piece. Once one knows what the scaffold does, how you can customize it, and how you'd do it all without the scaffold, I don't really see all the evilness in it. Can anyone please elaborate on the disadvantages of using the scaffold? :) On Thu, Mar 8, 2012 at 4:01 PM, Ryan Bigg radarliste...@gmail.com wrote: On Thursday, 8 March 2012 at 10:58 AM, Nicolás Sanguinetti wrote: On Thu, Mar 8, 2012 at 4:38 PM, Geoff Harcourt geoff.harco...@gmail.com wrote: I would be in favor of either of these two options. I imagine extracting and gem-ifying the controllers would be a hassle, but then the default path for setting up a new view and controller action would require the user to think about what they are doing rather than just observe the magic. Unfortunately, I think that even if we were to extract out to a gem that every non-official tutorial and book would just tell users to add rails_controller_generators to their gemfile as the first step, and the intended goal of this work would be completely bypassed. Pretty much this. Also, everyone using old books/tutorials (pre 4.0) will run into trouble. Don't get me wrong, I'm wholly in favor of killing it. Repeatedly. And violently. But truth is, it's hard do kill something that has been around this long, and that is included in pretty much all tutorials for rails that have existed since The Beginning of Time. Not sure what the best approach is. -foca In Rails 2 there was the removal of the scaffold method from the controllers. A major version then was the perfect time for that, and over time tutorials adjusted. If it was removed here, the same thing would occur. On Thu, Mar 8, 2012 at 1:30 PM, Ryan Bigg radarliste...@gmail.com wrote: Hello friends, It's been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they're doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. I think that we can fix this problem in one of two ways, the latter more extreme than the first one. The first way is that we completely change the Getting Started Guide to simply *mention* the scaffold generator, but then show people the correct way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the real world. The second way, and sorry if this sounds a little extreme, is to completely remove the scaffold generator from the core of Rails itself. This means that there wouldn't even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the sanctioned way to create controllers. Thoughts? -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this
Re: [Rails-core] Scaffold Generator Woes
On Thursday, 8 March 2012 at 11:30 AM, Elomar Souza wrote: Can anyone please elaborate on the disadvantages of using the scaffold? :) This helpful Stack Overflow question should display why teaching noobs scaffold first off is a bad thing: http://stackoverflow.com/revisions/9622251/1. He's shown way too much code, and if you take a look at his routes he has a whole bunch of actions that probably don't need to be there. He has no idea what the controller provides to the view or how that even works. We should teach them this *first* (create a controller, actions, etc.) and then show them the shortcut to doing it (scaffold generator). Teaching them scaffold first is wrong. It's a cheap trick that needs to die. I think that extracting it out into a gem and educating people on how Rails should be taught would have the best impact. The people who still want to use scaffolding for rapid prototyping can do that. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Re: Scaffold Generator Woes
is there some way we can test and validate that this would make using rails for beginners easier in the long run? Serious question. I'll be happy to A/B test-teach this to a group of students if we could come up with some reliable way of measuring success. Jumpstart Lab's intro to Rails class teaches without scaffolding, and it's really fantastic, actually. At the end, the big reveal of 'What you've done over the last day or two is just one command' blows people's minds, but we've had some of them say I'm really glad you didn't show us that first. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
This helpful Stack Overflow question should display why teaching noobs scaffold first off is a bad thing: http://stackoverflow.com/revisions/9622251/1. He's shown way too much code, and if you take a look at his routes he has a whole bunch of actions that probably don't need to be there. He has no idea what the controller provides to the view or how that even works. This guy has no idea what he's doing, I don't think that citing his case is at all useful. People can get confused no matter what you show them. We should teach them this *first* (create a controller, actions, etc.) and then show them the shortcut to doing it (scaffold generator). Teaching them scaffold first is wrong. It's a cheap trick that needs to die. I think that extracting it out into a gem and educating people on how Rails should be taught would have the best impact. The people who still want to use scaffolding for rapid prototyping can do that. Once you know how the rest of it works, there's no purpose to having the scaffold generator. You're thinking about this thing completely backwards. After you know, using it is a cheap trick, before then it's a useful way to get an example and dig in. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
Oh, I should have provided a link, as an example: http://tutorials.jumpstartlab.com/projects/jsblogger.html -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
On Thu, March 8, 2012 14:30, Elomar Souza wrote: I don't really get it. I've been using the scaffold for a while, never knew it wasn't the sanctioned way of doing things. . . . Can anyone please elaborate on the disadvantages of using the scaffold? :) There is really only one disadvantage to the scaffold generators: They have to be maintained. Every time Rails goes through one of its periodic syntax/structure paroxysms the generators are immediately placed out of date. A scaffold generator rewrite requires some detailed knowledge of the new ways of the Rails world otherwise the code they produce is worse than useless as exemplars. Unfortunately this knowledge is often limited in distribution around the time the changes are introduced. Further, those that do possess the requisite skills not infrequently have no wish to spend their limited time on something that they do not use themselves and perhaps believe is 'morally' suspect from a professional point of view. I rather suspect that arguments about the benefits of building RoR apps 'from the ground up' and potential confusion for Rails newcomers that might arise from using scaffolding is quite beside the point. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] Re: Scaffold Generator Woes
I am not going into the discussion of how scaffold affect new comers but my personal experience is: I spend the first 15 minutes of each project customizing scaffold to do exactly what I want. I remove helpers generation, update the views to fit the layout, add responders and so on. Then I rely a lot on scaffold. I rely 10 times more when building the application's backend (the admin section). So in this aspect, I wouldn't like to see scaffold going anywhere. Besides, the scaffold generator and structure is fairly easy to maintain. -- 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/-/iirZVNNVTvMJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Possible bug in Rails 2.3.14, controller tests always seem to rescue action with handler
It seems like it would be beneficial to have a page for rails similar to Ubuntu's wiki page for releases, which includes the release date and end of life date for each release (https://wiki.ubuntu.com/Releases). -- Steve Schwartz On Tuesday, March 6, 2012 at 5:07 PM, Anthony Richardson wrote: Hi, I would like to be able to direct the pointy haired bosses at a url to show them the support status of rails 2.3 (so I can argue for an upgrade path). Currently this url http://rubyonrails.org/security still refers to 2.3 as being supported with security patches. Fixes are prepared for all releases which are still under maintenance (at present 2.2.x, 2.3.x, master). Would be good tt get this updated (maybe a generic statement about what versions are supported without specific version numbers). Also is there another location on the website that explicitly states the supported versions or policy? Cheers, Anthony Richardson On Wed, Mar 7, 2012 at 7:59 AM, Michael Koziarski mich...@koziarski.com (mailto:mich...@koziarski.com) wrote: Is anyone still integrating fixes for 2.3? No, 2.3. is out of maintenance and out of security support too. There may be 3rd party patches tracked somewhere, but it's a dead branch from our POV sorry. -- Cheers, Koz -- 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
Well, I agree with those that think that Rails is not for beginners. Having said that, if we're targeting beginners, you'll get a framework that is beginners-friendly but may not be that nice for experienced users. And, in fact, I do think that scaffolds are actually more useful to experienced developers, specially if you have to often create lots of classes. It is so easy to override the default scaffold templates that every experienced developer could take advantage of the scaffold idea. The Model/Migration generators are specially useful for avoiding writing so much boilerplate code... So, I don't really think we should be worried that much about beginners but write a framework that is useful for us. Cheers, Rodrigo. Em 08-03-2012 15:30, Ryan Bigg escreveu: Hello friends, It's been fun having the scaffold generator exist as a part of Rails since The Beginning Of Time, but I think its time is now up. It has been abused time and time again, and most often leads to confusion amongst people who are new to Rails. This confusion happens when a user first generates a scaffold and sees that it is good. They can perform CRUD actions on a resource using one command?! WOW! Then they try to modify the scaffold and run into problems. First of all: how do they add an action to the controller? Do they need to run another command? How do they then define a route for that action? A template? If they were to *not* use the scaffold generator from the beginning, I believe they would have less confusion. They would know how to add another action to the controller and a template for that action because this would be how they're doing it from the start. Learning how to define a route for a new action in the controller is something easily learnable by reading the routing guide. I think that we can fix this problem in one of two ways, the latter more extreme than the first one. The first way is that we *completely change the Getting Started Guide to simply *mention* the scaffold generator*, but then show people the correct way of generating a controller (rails g controller) and adding actions to it one by one, adding a model as its needed, and using similar practices to how you would do it in the real world. The second way, and sorry if this sounds a little extreme, is to *completely remove the scaffold generator from the core of Rails* itself. This means that there wouldn't even be the option to run the scaffold generator for newbies. You could then extract this out into a gem if you *really* wanted people to have the option for it. However, if this path was taken it should be made clear that this is not the sanctioned way to create controllers. Thoughts? -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
Agreeing with José, I work on a University, and we try to keep all our systems follow a pattern, so clients get used to our layout and design and our developers get standard comment tips about how to name and describe methods. For this, we rely strongly on scaffold customization. I also agree that this should not be put as an advantage for beginners on tutorials and books, showing them how to not write code. Even a warning message could appear on scaffolding generation, or making the generators a little less automagic (and maybe a little more dumb also), forcing people to customize scaffolds before getting something usable. I believe that with this aproach, we can change the maintenance cost of keeping the scaffold generators up to date from the core developers who would not need to firstly update generators, to the experienced developers who contribute to rails on every realease candidate. -- Att, Everton -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Possible bug in Rails 2.3.14, controller tests always seem to rescue action with handler
I'll see if I can get that page updated. The short version is that we support the most recent release for bug fixes, and N-1 for security fixes. Everything else is out of maintenance. -- Cheers, Koz On Friday, 9 March 2012 at 10:49 AM, Steve Schwartz wrote: It seems like it would be beneficial to have a page for rails similar to Ubuntu's wiki page for releases, which includes the release date and end of life date for each release (https://wiki.ubuntu.com/Releases). -- Steve Schwartz On Tuesday, March 6, 2012 at 5:07 PM, Anthony Richardson wrote: Hi, I would like to be able to direct the pointy haired bosses at a url to show them the support status of rails 2.3 (so I can argue for an upgrade path). Currently this url http://rubyonrails.org/security still refers to 2.3 as being supported with security patches. Fixes are prepared for all releases which are still under maintenance (at present 2.2.x, 2.3.x, master). Would be good tt get this updated (maybe a generic statement about what versions are supported without specific version numbers). Also is there another location on the website that explicitly states the supported versions or policy? Cheers, Anthony Richardson On Wed, Mar 7, 2012 at 7:59 AM, Michael Koziarski mich...@koziarski.com (mailto:mich...@koziarski.com) wrote: Is anyone still integrating fixes for 2.3? No, 2.3. is out of maintenance and out of security support too. There may be 3rd party patches tracked somewhere, but it's a dead branch from our POV sorry. -- Cheers, Koz -- 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Possible bug in Rails 2.3.14, controller tests always seem to rescue action with handler
Just to clarify for everyone, N and N-1 refer to the minor version number, right? As in, currently 3.2 for bug fixes and 3.1 for security fixes. -- Steve Schwartz On Thursday, March 8, 2012 at 5:34 PM, Michael Koziarski wrote: I'll see if I can get that page updated. The short version is that we support the most recent release for bug fixes, and N-1 for security fixes. Everything else is out of maintenance. -- Cheers, Koz On Friday, 9 March 2012 at 10:49 AM, Steve Schwartz wrote: It seems like it would be beneficial to have a page for rails similar to Ubuntu's wiki page for releases, which includes the release date and end of life date for each release (https://wiki.ubuntu.com/Releases). -- Steve Schwartz On Tuesday, March 6, 2012 at 5:07 PM, Anthony Richardson wrote: Hi, I would like to be able to direct the pointy haired bosses at a url to show them the support status of rails 2.3 (so I can argue for an upgrade path). Currently this url http://rubyonrails.org/security still refers to 2.3 as being supported with security patches. Fixes are prepared for all releases which are still under maintenance (at present 2.2.x, 2.3.x, master). Would be good tt get this updated (maybe a generic statement about what versions are supported without specific version numbers). Also is there another location on the website that explicitly states the supported versions or policy? Cheers, Anthony Richardson On Wed, Mar 7, 2012 at 7:59 AM, Michael Koziarski mich...@koziarski.com (mailto:mich...@koziarski.com) wrote: Is anyone still integrating fixes for 2.3? No, 2.3. is out of maintenance and out of security support too. There may be 3rd party patches tracked somewhere, but it's a dead branch from our POV sorry. -- Cheers, Koz -- 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core%2bunsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com (mailto:rubyonrails-core+unsubscr...@googlegroups.com). 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Possible bug in Rails 2.3.14, controller tests always seem to rescue action with handler
On Friday, 9 March 2012 at 11:38 AM, Steve Schwartz wrote: Just to clarify for everyone, N and N-1 refer to the minor version number, right? As in, currently 3.2 for bug fixes and 3.1 for security fixes. -- Steve Schwartz Exactly -- Cheers, Koz -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
On Mar 8, 2012, at 5:25 PM, Everton Moreth wrote: Agreeing with José, I work on a University, and we try to keep all our systems follow a pattern, so clients get used to our layout and design and our developers get standard comment tips about how to name and describe methods. For this, we rely strongly on scaffold customization. I also agree that this should not be put as an advantage for beginners on tutorials and books, showing them how to not write code. Even a warning message could appear on scaffolding generation, or making the generators a little less automagic (and maybe a little more dumb also), forcing people to customize scaffolds before getting something usable. WAT. No, seriously - this is like a group of Ikea craftsmen deciding to no longer use pre-cut wood, since making customers cut it for themselves will teach them carpentry more quickly. Dumbing down the generator is them trying to split the difference by cutting to shape but not drilling holes; both approaches ignore that the EAT UR VEGGIES NAOW method only works if you've got customers that can't choose an alternative. To me, it seems easier to imagine the counterfactual: imagine Rails *without* a similar generator, and then imagine the responses to a proposed generator that would automatically create reasonably clean, idiomatic code that a new developer could quickly see results from. Such a thing would likely be popular... --Matt Jones -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Possible bug in Rails 2.3.14, controller tests always seem to rescue action with handler
so no security fixes for 3.0.x ? that comes at a big surprise and feels like being in the rains. regards, Kristian On Fri, Mar 9, 2012 at 4:09 AM, Michael Koziarski mich...@koziarski.com wrote: On Friday, 9 March 2012 at 11:38 AM, Steve Schwartz wrote: Just to clarify for everyone, N and N-1 refer to the minor version number, right? As in, currently 3.2 for bug fixes and 3.1 for security fixes. -- Steve Schwartz Exactly -- Cheers, Koz -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Possible bug in Rails 2.3.14, controller tests always seem to rescue action with handler
On Friday, 9 March 2012 at 4:11 PM, kristian wrote: so no security fixes for 3.0.x ? that comes at a big surprise and feels like being in the rains. Depending on the issue, we generally try and ship a backported patch, and given the similarity between 3.0 and 3.1 it's pretty unlikely that it won't be able to be backported. However we can't guarantee that, you should upgrade to 3.1 to reduce the risk for your application. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[Rails-core] Re: Scaffold Generator Woes
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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Scaffold Generator Woes
There is really only one disadvantage to the scaffold generators: They have to be maintained. I think this is a great feature of the scaffold generator. Through the years, whenever there is a major release, I can scaffold generate deleteme and get a quick overview of some of the newness. No...it's not as good as checking the source or guides, but it's a very easy way to be introduced to what the current way is. Is that by itself enough to keep it around? I dunno...but I do like having them. Also, if maintaining the scaffold has been a problem, I'm willing to help...not that I presume to know all that's required to do that right now, but I'm serious about the offer. (Just read José's email and it may not actually be a problem.) On Thu, Mar 8, 2012 at 3:29 PM, James B. Byrne byrn...@harte-lyne.cawrote: On Thu, March 8, 2012 14:30, Elomar Souza wrote: I don't really get it. I've been using the scaffold for a while, never knew it wasn't the sanctioned way of doing things. . . . Can anyone please elaborate on the disadvantages of using the scaffold? :) There is really only one disadvantage to the scaffold generators: They have to be maintained. Every time Rails goes through one of its periodic syntax/structure paroxysms the generators are immediately placed out of date. A scaffold generator rewrite requires some detailed knowledge of the new ways of the Rails world otherwise the code they produce is worse than useless as exemplars. Unfortunately this knowledge is often limited in distribution around the time the changes are introduced. Further, those that do possess the requisite skills not infrequently have no wish to spend their limited time on something that they do not use themselves and perhaps believe is 'morally' suspect from a professional point of view. I rather suspect that arguments about the benefits of building RoR apps 'from the ground up' and potential confusion for Rails newcomers that might arise from using scaffolding is quite beside the point. -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca Harte Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Possible bug in Rails 2.3.14, controller tests always seem to rescue action with handler
Hi! Just to clarify for everyone, N and N-1 refer to the minor version number, right? As in, currently 3.2 for bug fixes and 3.1 for security fixes. -- Steve Schwartz Exactly So that means 3.0.12, released March 1, 2012 is out of maintenance, is that right? (no pun intended, I'm trying to ensure I can advise my clients accordingly). -- Thibaut -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Possible bug in Rails 2.3.14, controller tests always seem to rescue action with handler
On Friday, 9 March 2012 at 11:45 AM, Thibaut Barrère wrote: Hi! Just to clarify for everyone, N and N-1 refer to the minor version number, right? As in, currently 3.2 for bug fixes and 3.1 for security fixes. -- Steve Schwartz Exactly So that means 3.0.12, released March 1, 2012 is out of maintenance, is that right? (no pun intended, I'm trying to ensure I can advise my clients accordingly). In that case the back port was really easy, and so we did it. The next time a vulnerability comes up it may be just that simple, however you shouldn't be relying on that. Fundamentally we're not going to refuse to spend 10 minutes with git cherry-pick in order to 'stick with policy'. However if it's something hairy, we're not staking our reputation on it. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
