4 ms·

I find most things by jumping into pry at a break point and inspecting it. Works really well, but isn’t something that’s common in other languages so people don

by jshen 4y ago

I find most things by jumping into pry at a break point and inspecting it. Works really well, but isn’t something that’s common in other languages so people don’t think to do it.

itake 4y ago
Debugging with pry is annoying for complex inputs (api param with lots of Json or lots of state). You end up making a complex scratch page notes trying to collect all of the inputs to just test the function call. When the code causing issues is within a gem (and outside of your VSCode project directory) it’s also annoying to find the gem path and source code. Solvable, but time consuming.
- izietto 4y ago
  bundle show gem-name bundle open gem-name Fix the last one
  - itake 4y ago
    yep, gotta run a bunch of terminal commands to get to the file path. And then have to modify the gem's source code to add debugging lines. When you're done, you gotta re-install the gem in case you didn't revert all of your debug tweaks.
    - jshen 4y ago
      Isn’t that more or less true when looking for a bug in a third part library in any language?
- rco8786 4y ago
  > Debugging with pry is annoying for complex inputs Debugging for complex inputs is always hard, but I’ve yet to see a language do it better than Ruby/pry. Write a test that sets up your complex input, slap a pry in it, use the repl to debug/explore/iterate, then leave the test in place when you’re done.
  - itake 4y ago
    Go forces you to use dependency injection, which makes it much easier to have simple structs (objects). With Ruby (and specifically Rails), so much state is tacked onto ActiveRecord that its difficult to mock/debug apis. For example, calling `#find()` creates a new object or trying to stub out `User::ActiveRecord_Relation` in tests is frustrating.
    - rco8786 4y ago
      Ah yea, ActiveRecord has some cruft like that for sure. That’s probably why it’s so common to use an actual database for testing and mocking data. Which has its own set of benefits/drawbacks.

by jshen 4y ago

I find most things by jumping into pry at a break point and inspecting it. Works really well, but isn’t something that’s common in other languages so people don’t think to do it.

itake 4y ago

Debugging with pry is annoying for complex inputs (api param with lots of Json or lots of state). You end up making a complex scratch page notes trying to collect all of the inputs to just test the function call. When the code causing issues is within a gem (and outside of your VSCode project directory) it’s also annoying to find the gem path and source code. Solvable, but time consuming.

izietto 4y ago
bundle show gem-name bundle open gem-name Fix the last one
- itake 4y ago
  yep, gotta run a bunch of terminal commands to get to the file path. And then have to modify the gem's source code to add debugging lines. When you're done, you gotta re-install the gem in case you didn't revert all of your debug tweaks.
  - jshen 4y ago
    Isn’t that more or less true when looking for a bug in a third part library in any language?
rco8786 4y ago
> Debugging with pry is annoying for complex inputs Debugging for complex inputs is always hard, but I’ve yet to see a language do it better than Ruby/pry. Write a test that sets up your complex input, slap a pry in it, use the repl to debug/explore/iterate, then leave the test in place when you’re done.
- itake 4y ago
  Go forces you to use dependency injection, which makes it much easier to have simple structs (objects). With Ruby (and specifically Rails), so much state is tacked onto ActiveRecord that its difficult to mock/debug apis. For example, calling `#find()` creates a new object or trying to stub out `User::ActiveRecord_Relation` in tests is frustrating.
  - rco8786 4y ago
    Ah yea, ActiveRecord has some cruft like that for sure. That’s probably why it’s so common to use an actual database for testing and mocking data. Which has its own set of benefits/drawbacks.