5 ms·

You start by boiling it down to an executable test case, for which there are templates here here: http://guides.rubyonrails.org/contributing_to_ruby_on_rails.ht

You start by boiling it down to an executable test case, for which there are templates here here: http://guides.rubyonrails.org/contributing_to_ruby_on_rails.html#creating-a-bug-report http://guides.rubyonrails.org/contributing_to_ruby_on_rails.... Then you share the test case in a bug report, and collaborate to fix it. Fixing it usually involves a source code dive. With Rails's reasonably well documented and reasonably well written codebase it's usually possible to grok the source and dependencies even coming to it cold. With the possible exception of arel. Ruby's dirty tricks department (monkey-patching third-party objects) and duck typing together are a real boon to debugging.

sfilargi 10y ago
Nice, thanks. Pretty impressive documentation. Seeing the praise it gets here, I will definitely give RoR a chance for my next side-project. Thanks again.
- sandstrom 10y ago
  I think you will like it! Github, Shopify, AirBnB, Indiegogo, Kickstarter, Twitch, Zendesk and many others run on Ruby on Rails. You'll be in good company!
rmchugh 10y ago
Interesting, my experience is the opposite: liberal use of ruby's dirty tricks often makes code hard to understand and thus debug.
- epidemian 10y ago
  That's a separate statement, and they are not contradictory. Using Ruby's dirty tricks on shipped code -> hard for debugging/understanding. Using Ruby's dirty tricks while debugging -> boon. The grandparent didn't claim the former to be false, only the later to be true.
  - inopinatus 10y ago
    This is a correct reading of my remark. I happen to agree with the opinion of the followup as well, monkey-patching in production is a code stench. Still I plead guilty to having occasionally monkey-patched prod code out of urgent necessity. My recommendation is to view it like an advanced and undesirable form of configuration; for my rails apps, each such hack always goes in an initializer file named for the library it is patching. If you are replacing third-party methods (or undermining the behaviour of a third-party method) and those methods are not called very frequently then judicious use of log noise e.g. through the deprecation mechanism will help at debug time.
- jrochkind1 10y ago
  i think different areas of Rails codebase vary here, some are pretty legible, some less so.
- vinceguidry 10y ago
  Once you understand how it all works, I'll grant that that can take years, it doesn't take much time at all to debug upstream code. Just last night I was playing around with the jsonapi-resources gem, and found an issue that was keeping me from being able to dynamically generate resources. After realizing I couldn't work around the issue through more metaprogramming, I set about monkey-patching the code. It got too late so I couldn't finish the job, but once I do, I'll get it working for my project, then package it up and make a pull request so I don't have to support it myself. Ruby is definitely wizardry but it's accessible wizardry.

sfilargi 10y ago

Nice, thanks. Pretty impressive documentation. Seeing the praise it gets here, I will definitely give RoR a chance for my next side-project. Thanks again.

sandstrom 10y ago
I think you will like it! Github, Shopify, AirBnB, Indiegogo, Kickstarter, Twitch, Zendesk and many others run on Ruby on Rails. You'll be in good company!

rmchugh 10y ago

Interesting, my experience is the opposite: liberal use of ruby's dirty tricks often makes code hard to understand and thus debug.

epidemian 10y ago
That's a separate statement, and they are not contradictory. Using Ruby's dirty tricks on shipped code -> hard for debugging/understanding. Using Ruby's dirty tricks while debugging -> boon. The grandparent didn't claim the former to be false, only the later to be true.
- inopinatus 10y ago
  This is a correct reading of my remark. I happen to agree with the opinion of the followup as well, monkey-patching in production is a code stench. Still I plead guilty to having occasionally monkey-patched prod code out of urgent necessity. My recommendation is to view it like an advanced and undesirable form of configuration; for my rails apps, each such hack always goes in an initializer file named for the library it is patching. If you are replacing third-party methods (or undermining the behaviour of a third-party method) and those methods are not called very frequently then judicious use of log noise e.g. through the deprecation mechanism will help at debug time.
jrochkind1 10y ago
i think different areas of Rails codebase vary here, some are pretty legible, some less so.
vinceguidry 10y ago
Once you understand how it all works, I'll grant that that can take years, it doesn't take much time at all to debug upstream code. Just last night I was playing around with the jsonapi-resources gem, and found an issue that was keeping me from being able to dynamically generate resources. After realizing I couldn't work around the issue through more metaprogramming, I set about monkey-patching the code. It got too late so I couldn't finish the job, but once I do, I'll get it working for my project, then package it up and make a pull request so I don't have to support it myself. Ruby is definitely wizardry but it's accessible wizardry.