Very cool, Ryan. You sure covered a lot of territory here ... kind of like one of those cooking shows where all the vegetables and ingredients are prepared in advance, and the food has already baked in advance :-)
So this gets to the core of the main steps of making a contribution. For the more timid amongst us, do you have any pointers on some of the "pre-show" work that should go into making a patch?
For example, you mentioned in passing that it was a good idea to make sure the functionality wasn't already implemented. Now being about 9 months into RoR I am still learning a lot of things I just didn't know existed. Any tips on knowing what a good candidate is for a patch?
@Tom, excellent questions. As mentioned at the end of the episode, I think subscribing to the Rails Core google group is the best way to get started. Keep up with the tickets coming in, try them out, and give feedback. Sometimes there will be tickets which don't have a patch, or just include a failing test. These you can try contributing a patch to.
As for coming up with patches from scratch, that's kind of hard to do on the spot. The best thing to do is to work on a Rails application and look for possible patches that will aid your app. This will lead to patches which have a real world use case and will more likely be useful to others.
As for your second question, I've ran into that a number of times, where I thought of making a patch for something and, after a little digging, realized it was already implemented in Rails.
Usually you can tell if it's already implemented by reading the Rails source code. If you don't see it, go ahead and submit a patch and others will point you to the existing functionality if it's already implemented. If it's a larger patch, it's probably best to ask in the google group before attempting to implement it, to see if others would find it useful and if they have any ideas on the implementation.
@Mike, you would still need to call "conditions!" on a scope object. In your code it's just being called on "self" which is the search model.
I always add a step right after the git pull followed by rebasing my branch, and that is to rerun the tests to make sure that they still work should any changes pulled down affect them.
thanks for this screencast. I installed git and followed your screencast to submitted a patch - only to find later that my changes to files were in the patch, but the new file I had created wasn't included. I spent a bit of time this morning trying to figure out how to get that file included in the patch, but haven't had much luck yet. Is there a good resource for learning this stuff somewhere? A walk through for first timers?
Ryan, Thank you. I didn't have the mocha gem installed. Got a lot of "NoMethodError: undefined method `expects'/`stubs' for ...". But once I installed it, all the tests passed. - Mike
Ryan, Thank you. I didn't have the mocha gem installed. Got a lot of "NoMethodError: undefined method `expects'/`stubs' for ...". But once I installed it, all the tests passed. - Mike
my web page <a href="http://www.jwebtasarim.com" >web tasarım</a>
For example, you mentioned in passing that it was a good idea to make sure the functionality wasn't already implemented. Now being about 9 months into RoR I am still learning a lot of things I just didn't know existed.
If you don't see it, go ahead and submit a patch and others will point you to the existing functionality if it's already implemented. If it's a larger patch, it's probably best to ask in the google group before attempting to implement it, to see if others would find it useful and if they have any ideas on the implementation.
Awesome topic, thanks Ryan :)
Now people wont one less excuse for not contributing back to rails :)
Very cool, Ryan. You sure covered a lot of territory here ... kind of like one of those cooking shows where all the vegetables and ingredients are prepared in advance, and the food has already baked in advance :-)
So this gets to the core of the main steps of making a contribution. For the more timid amongst us, do you have any pointers on some of the "pre-show" work that should go into making a patch?
For example, you mentioned in passing that it was a good idea to make sure the functionality wasn't already implemented. Now being about 9 months into RoR I am still learning a lot of things I just didn't know existed. Any tips on knowing what a good candidate is for a patch?
Thanks for all you do.
Tom
Nice walk through on contributing. With the patch you wrote couldn't you have re-written your method as:
def find_products
returning Product.scoped({}) do |conditions|
conditions! ...
conditions! ...
conditions! ...
conditions! ...
end
end
@Tom, excellent questions. As mentioned at the end of the episode, I think subscribing to the Rails Core google group is the best way to get started. Keep up with the tickets coming in, try them out, and give feedback. Sometimes there will be tickets which don't have a patch, or just include a failing test. These you can try contributing a patch to.
As for coming up with patches from scratch, that's kind of hard to do on the spot. The best thing to do is to work on a Rails application and look for possible patches that will aid your app. This will lead to patches which have a real world use case and will more likely be useful to others.
As for your second question, I've ran into that a number of times, where I thought of making a patch for something and, after a little digging, realized it was already implemented in Rails.
Usually you can tell if it's already implemented by reading the Rails source code. If you don't see it, go ahead and submit a patch and others will point you to the existing functionality if it's already implemented. If it's a larger patch, it's probably best to ask in the google group before attempting to implement it, to see if others would find it useful and if they have any ideas on the implementation.
@Mike, you would still need to call "conditions!" on a scope object. In your code it's just being called on "self" which is the search model.
Ryan,
I always add a step right after the git pull followed by rebasing my branch, and that is to rerun the tests to make sure that they still work should any changes pulled down affect them.
Hey Ryan,
thanks for this screencast. I installed git and followed your screencast to submitted a patch - only to find later that my changes to files were in the patch, but the new file I had created wasn't included. I spent a bit of time this morning trying to figure out how to get that file included in the patch, but haven't had much luck yet. Is there a good resource for learning this stuff somewhere? A walk through for first timers?
cheers, Loving your work as always.
Tim.
@Ryan,
You seem to have mispelled 'activerecord_unittest2' in the code that appears at the top of this page (just below 'Resources'), so:
create database activerecord_unittes2;
should actually read:
create database activerecord_unittest2;
Also, I believe you missed the -b flag in:
git checkout named_scope_with_bang
so it should read:
git checkout -b named_scope_with_bang
@Cassiano, Thanks for pointing these problems out! Fixed.
Ryan, Thank you. I didn't have the mocha gem installed. Got a lot of "NoMethodError: undefined method `expects'/`stubs' for ...". But once I installed it, all the tests passed. - Mike
Ryan, Thank you. I didn't have the mocha gem installed. Got a lot of "NoMethodError: undefined method `expects'/`stubs' for ...". But once I installed it, all the tests passed. - Mike
my web page <a href="http://www.jwebtasarim.com" >web tasarım</a>
For example, you mentioned in passing that it was a good idea to make sure the functionality wasn't already implemented. Now being about 9 months into RoR I am still learning a lot of things I just didn't know existed.
Now being about 9 months into RoR I am still learning a lot of things I just didn't know existed.
If you don't see it, go ahead and submit a patch and others will point you to the existing functionality if it's already implemented. If it's a larger patch, it's probably best to ask in the google group before attempting to implement it, to see if others would find it useful and if they have any ideas on the implementation.
@ Russ Jones - Yeah I do agree with you this certainly is worth to have a look at
It was fun to watch the video.
Thanks for sharing!