4 ms·

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

by rmchugh 10y ago

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.

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

by 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.