Ruby: Mini Epic - Update and improve debugging content

[ChargrilledChook]

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.

• Introduces basics concepts, such as puts / p debugging
• Introduces basic REPL debugging with irb
• Introduces basic interactive debugging with CLI rdbg
• Splits content into smaller, more digestible chunks and places where appropriate

Core Content

Beta Give feedback

1. Ruby: Debugging Lesson: replace pry with binding.irb in ruby debugging lesson #25276
   Content: Ruby +1
   
2. Ruby: Restructure debugging lessons
3. Ruby: Rework existing debugging lesson to use binding.irb #25914
   Content: Ruby Status: Stale +2
   
4. Update Ruby Cersion of Debugging Command on Odin-bot
5. Ruby: Add interactive debugging basics lesson #25915
   Content: Ruby Status: Stale +2
   

Milestone 2: More content and polish

• High value additions that are not as critical
• Many people really enjoy the VSCode integration for rdbg, but many struggle signifcantly to set it up. Improving both configuration instructions as well as some basic usage could provide a lot of value
• The computer science could be a great candidate to introduce intermediate debugging, such as stack / frame navigation and more granular debugger control (such as the differences between step in / over / out)
• This would be useful both to teach these skills, as well as introduce them in a spot where the would be really useful

Future Content

Beta Give feedback

1. Add a new intermediate debugging lesson
2. Add a lesson or content section teaching GUI debugging

Future discussions: Nice to haves

• Generally useful content that would need discussion to determine value
• As well as people to people to work on them

Nice to Haves

Beta Give feedback

1. A section on advanced debugging
2. A debugging playground / exercise repo
3. A lesson or content section on more general debugging concepts - approaches, styles, techniques
4. A lesson or content setion on common types + classes of errors

[ChargrilledChook]

cc @TheOdinProject/rails-path

[github-actions]

This issue is stale because it has had no activity for the last 30 days.

[CouchofTomato]

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.

[github-actions]

This issue is stale because it has had no activity for the last 30 days.

[JoshDevHub]

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.

[ChargrilledChook]

@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

[JoshDevHub]

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

[ChargrilledChook]

@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

[JoshDevHub]

@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:

  • Conditional breakpoints: I didn't know about this for a while but I think it's very helpful to be able to say things like binding.b if @ivar == some_value
  • catch <ErrorName> which can be used to break when some error is raised.
  • Ways to quickly examine local context (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.

[KevinMulhern]

Hey @ChargrilledChook, @JoshDevHub, can we close this related issue now that we're moving ahead with this different approach?

[ChargrilledChook]

@KevinMulhern Good call mate, sorted 👍

@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 😅 ) 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.

[crespire]

I would be happy to help out on the increased scope playground idea once it's ready for work.

[JoshDevHub]

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

[ChargrilledChook]

@JoshDevHub Yep, perfect 👌

[github-actions]

This issue is stale because it has had no activity for the last 30 days.

[github-actions]

This issue is stale because it has had no activity for the last 30 days.

[radanskoric]

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 #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: #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?

[github-actions]

This issue is stale because it has had no activity for the last 30 days.