Debugging Tools/Strategies

[hackling]

No one writes foolproof code. Eventually you're going to have to debug.

I thought it might be a good exercise to show case off some strategies and tools, especially for the beginners out there.

No one should have to do ALL their rails debugging in the view (like I did 😒 when I first started).

[ridget]

@hackling you're trying to tell me raise, puts and p arent valid debugging strategies? Would love to see this 👍

[hackling]

I think this would be good if other people could bring their own tips to the party.

I was going to explain:

• using raise to get information at a certain point
• IRB
• Rails Console
• binding.pry (Gem)

[hackling]

@hackling you're trying to tell me raise, puts and p arent valid debugging strategies?

@ridget Actually, I'm going to tell you that they are. But beginners, especially those straight from Rails Girls, would have no idea about any of them.

[ridget]

@hackling m8 now i just feel bad. not sure if youre including it, or someone else will bring to the party but remote-pry is also a++

[hackling]

@ridget You should demo remote-pry :D

Personally, rather than me waffling on for 30 minutes, I'd love to see this as more of a collective of lightning talks that all share a similar topic/ theme.

Everyone debugs differently, and I'm sure many people will probably think how I do it could be improved.

[patrickgordon]

Awesome - think if this is aimed at beginner this would be great.

👍

[SorchaAbel]

yep definitely, great topic :)

On 31 July 2015 at 11:01, Patrick notifications@github.com wrote:

Awesome - think if this is aimed at beginner this would be great.

[image: 👍]

—
Reply to this email directly or view it on GitHub
#107 (comment).

Sorcha Abel
IT Software Developer

T 07 3319 4430
E sorcha.abel@htw.com.au

Level 1, 811 Gympie Road, Chermside, QLD, 4032
PO Box 61, Chermside South, QLD, 4032

HERRON TODD WHITE | www.htw.com.au

Please consider the impact on the environment before you print this email

The information contained in this e-mail and any attachments are strictly
private and confidential. This e-mail should only be read by the intended
addressee. If you are not the intended addressee, you are strictly
prohibited from using, reproducing, disclosing, or distributing the
information contained herein and any attached files and/or documents.
Unless stated otherwise, this email represents only the views of the sender
and not the views of Herron Todd White. Before opening or using any files
and/or attachments, we recommend you run your own virus protection, as
although we will not knowingly transmit a virus, Herron Todd White accepts
no liability for virus transmission. Liability limited by a scheme approved
under Professional Standards Legislation. The scheme does not apply within
Tasmania.

[ghiculescu]

Throw https://github.com/deivid-rodriguez/byebug into the mix too

[michael-harrison]

First apologies to the bash purists but it might be worth showing how it's done in RubyMine with the ruby-debug-ide gem. Would be happy to help out.

[hackling]

Just to clarify, for those people saying "showcase X, cover Y, etc". If you know about it, and I'm not covering it in the few things I've mentioned above, I'm inviting you to do a bit about in the same talk.

[hackling]

First apologies to the bash purists but it might be worth showing how it's done in RubyMine with the ruby-debug-ide gem. Would be happy to help out.

If someone knew how to do something similar to this, but in Sublime, that would be great too, as I suspect this is the tool that most newbies use.

[michael-harrison]

There is a debugger for Sublime: https://packagecontrol.io/packages/Ruby%20Debugger. Will have a look at it over the next couple of weeks. It's been a long time since I used Sublime but I believe I can get it working.

[michael-harrison]

@hackling if you like you I'll do the IDE / Editor part of the talk

[nigelr]

@hackling I will put this on the list for the next BrisRuby (25th)... Can you please head it up and pick your area experts (eg. IDE, Pry etc).. I could be definitely done like a Panel of experts...

[michael-harrison]

Hi all, I'm happy to do the RubyMine section. I can possibly do Sublime but I'm by no means a regular user (anybody out there?).

In general I think it would be good to have a common set of code that we're debugging and common set of aspects in debugging that we'll be covering. This will allow the audience to get a feel for how each approach works without having to understand a new set of code and aspects for each debugging tool. Let me know what you think.

[patrickgordon]

That's a really good idea!
Looking forward to the RubyMine demo
On 2 Aug 2015 10:48 am, "Michael Harrison" notifications@github.com wrote:

Hi all, I'm happy to do the RubyMine section. I can possibly do Sublime
but I'm by no means a regular user (anybody out there?).

In general I think it would be good to have a common set of code that
we're debugging and common set of aspects in debugging that we'll be
covering. This will allow the audience to get a feel for how each approach
works without having to understand a new set of code and aspects for each
debugging tool. Let me know what you think.

—
Reply to this email directly or view it on GitHub
#107 (comment).

[davekinkead]

+1

[hackling]

@nigelr Sadly I won't be in town August 25th as I'm expecting to be in Melbourne for about a month. I'm happy for someone else to take this topic and run with it in my absence.

[hackling]

I'm in town this month! Shall we revisit this talk?

[nigelr]

That would be great!

[patrickgordon]

Keen! 👍

[michael-harrison]

Sorry guys I'll be in Perth :(

[hackling]

@ridget Can you still demo remote-pry?
Does anyone want to cover Sublime, or Ruby-Mine (seeing as @michael-harrison will be away)

[ridget]

@hackling would love to, but unlikely I'm going to be leaving the house any time soon, I'm going to dob in @geoffreyd for remote-pry though, as he's pretty switched on with it.

[hackling]

I've suggested to @nigelr that we put this off until we have a few more participants ready to do this. Hopefully @michael-harrison and @ridget are back in town/ up to the task next month.

[nigelr]

Thinking of headlining with this next month, can all those involved confirm if they can make it
@hackling, @michael-harrison, @ridget, @ghiculescu and anyone else who wants to join this panel..

[ridget]

@nigelr yep, count me in

[ridget]

@michael-harrison will you still be in perth for meetup next week? @hackling is trying to tie this together and we cant reach you on slack

[hackling]

To be honest, if michael can't make it, it's all good. I think I under-estimated how much content I have.

[patrickgordon]

Woo! Looking forward to this guys 👍

[michael-harrison]

Hey guys. I can most likely do next week. Just working out kiddy care now.

[michael-harrison]

Did we end up getting a common code base for comparisons between the different options?

[michael-harrison]

@hackling & @ridget Ok, I'm in. Since this is a shared presentation here's what I'm thinking about covering:

• why / when should we use a debugger
• starting ruby script debugging
• starting rails script debugging
• basic break points
• conditional break points
• inspection of variables & utilisation of logs
• combination of rspec and debugger
• limitations for debugging

I thought about doing remote debugging (i.e. debugging an application on a remote server) but this is fairly advanced and you could do a whole talk just on that.

Let me know what you think :)

[hackling]

@michael-harrison We invited you to a conversation on the Brisbane slack where we've been discussing it all.