Open ChargrilledChook opened 1 year ago
cc @TheOdinProject/rails-path
This issue is stale because it has had no activity for the last 30 days.
Hey @ChargrilledChook
Is this something you're waiting for feedback on? Sorry for the delay mate. It's been a hectic start to the year.
This issue is stale because it has had no activity for the last 30 days.
I'm a bit curious about the status of this one. Is it being actively worked on?
The current lesson tends to cause a lot of confusion, at least judging from the amount of questions it brings up in the discord help chats. I agree with Chook that moving exclusively to rdbg
would be very helpful, and I also think it's a good idea to split the CLI / vscode GUI into different lessons.
I'd be glad to offer any help with this if help is wanted for it.
@JoshDevHub I wrote a decent amount of (draft) content but had to put it down. If you're interested I would love to have your help on this one; I can share what I've done so far and you can use it (or not) depending on your thoughts.
I agree this is probably the lesson most in need of fixing at the moment because I continually see people having technical issues
@ChargrilledChook Yeah I'd be interested in working on it. Also definitely interested in seeing your draft, I feel like you have a lot of good knowledge with debugging.
@JoshDevHub sounds great, I'll dig up my drafts (they're in a random branch somewhere).
Do you have thoughts on my suggestions / discussion points in the body of the issue? I have some strong opinions but there's a lot of different ways we could approach it
@ChargrilledChook I agree with basically every point in the issue body I think. Some of my thoughts:
Moving away from pry
is a good idea with rdbg
in standard lib. I think one of the justifications for still teaching pry
was that people might get in a job on an older version of ruby, but the debug gem has compatibility all the way back to 2.6. And so long as we're still showing how to use it in the terminal (which I think is still a good idea as well), it's not like it's some ultra challenge to move between rdbg
via CLI and pry
anyway. It'll definitely streamline the lesson(s) a ton to just show one tool.
Strongly agree that step-in, step-out, and step-over should be covered. I'm a bit surprised they're not currently mentioned. Some other stuff that'd be useful I think:
binding.b if @ivar == some_value
catch <ErrorName>
which can be used to break when some error is raised.info
command, using the vscode UI's side panels, etc.)Of course this stuff can get super deep, and I'd rather not overwhelm people. It's probably important to keep in mind that this lesson is happening before learners have even done Tic-Tac-Toe. But I do find myself using the above things pretty often.
I agree that binding.irb
is probably a good way to ease people in to interactive debugging.
Also agree that there's room for two lessons here. There's just a lot going on between introducing the callstack, p/puts
debugging, interactive debugging, setting up vscode debugger etc. Setting up vscode debugging definitely deserves more real estate than it currently has. It's a very powerful tool, and learners are still at the stage of being a bit intimidated by things like the whole launch.json
setup. I get the feeling that some people never get it working and just stick with pry
, which is a bit of a shame I think.
Hey @ChargrilledChook, @JoshDevHub, can we close this related issue now that we're moving ahead with this different approach?
@KevinMulhern Good call mate, sorted :+1:
@JoshDevHub great write up, I think we're very much aligned here.
As a way of breaking this up a bit (and letting me find those drafts :sweat_smile: ) would you able to take on part one of the suggested approach and streamline the first lesson?
If you want to do a straight one to one swap (removing references to pry and the VSCode debugger) that would be ok, but if you wanted to expand on some of the more conceptual points that could be useful too.
This could be a section that would really benefit from having its own RSpec style playground repo, although that might be blowing the scope out of this particular issue a little - but happy to discuss how that might look.
I would be happy to help out on the increased scope playground idea once it's ready for work.
@ChargrilledChook Yeah, I can get started on that. Would it be okay if I replaced the current pry
content with binding.irb
? There's only one example given that shows any stepping, so I figure I can just alter that example and convert that section of the lesson over to binding.irb
.
@JoshDevHub Yep, perfect :ok_hand:
This issue is stale because it has had no activity for the last 30 days.
This issue is stale because it has had no activity for the last 30 days.
Hi, I was wondering what is the state of this ticket as I would like to contribute.
I was browsing Ruby content and noticed on the debugging lesson that it still has just byebug content and doesn't mention the new debug gem. Since I have experience with both, I thought I would contribute to the article, update it to be about the debug gem instead of pry-byebug.
Then I checked PRs and found https://github.com/TheOdinProject/curriculum/pull/25276 which lead me to this issue.
I was thinking of writing a section about the debug gem that would on top of the changes from the linked PR but I'm not entirely sure if tha fits within the overarching plan of this ticket?
What would be the best way forward for me to contribute to the debugging lesson?
EDIT: I wrote too soon, I've now noticed: https://github.com/TheOdinProject/curriculum/pull/25916 Which is basically more or less what I was thinking on writing. :) While I'm here, is there something I could do to help finish those changes?
This issue is stale because it has had no activity for the last 30 days.
Mini Epic: Improving Ruby Debugging Content
Debugging is a foundational skill and an important one to teach well and early, but our current content leaves a lot to be desired. It has been tacked onto somewhat over time and has become disjointed and complex.
We can streamline these lessons by focusing on smaller blocks of content, as well as paring back to use the Ruby core library. We can also adopt a progressive enhancement approach for this topic, and gradually improve / add to the content instead of doing everything in a single go.
Milestone 1: Updates to core content.