Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:19):
No matter how long you've been a developer, no matter how much you learn and how much you know, pretty much every day you'll run into something that stumps you. Maybe for a minute, maybe for an hour.

Aaron Saray (00:34):
I mean, not some of us. I've never been stumped. As soon as I was born I was a really good programmer so I don't think this episode has anything to do with me.

Joel Clermont (00:46):
Except for you, put yourself in their shoes. You're very empathetic, so you can put yourself in the shoes of a normal, mortal developer. What would you do, hypothetically, if your code was not doing what you expected it to do and you didn't immediately know what the problem was? What is your thought process?

Aaron Saray (01:06):
Well, I think... And obviously this is actually real and not hypothetical.

Joel Clermont (01:11):
Okay.

Aaron Saray (01:11):
Really one of the challenges that I've seen developers and myself struggle with too is when you have a full process and something's going wrong, how do you troubleshoot a little bit of something right in the middle of it? And I always say, "The best thing to do is to simplify." Simplify, simplify. Pull out just that little piece of code or that little action and try to run that by itself. For example, let's just say you had a really just intricate designed HTML page, and maybe you put a little bit more CSS in there, and for some reason that input box or something you just styled is now weird. It's got an underline and you just can't seem to track it down. Well, the first thing I'd say is, "Go and remove basically everything up until the body tag and just have your little section there," and see is it still doing that styling? If it is, then it's the CSS. Remove half the CSS, remove half of it again or just kind of start from scratch. And really break that down because, one, I know you're a current developer so you're going to be using Git.

Joel Clermont (02:20):
Yeah.

Aaron Saray (02:20):
So anything you do, you can just reset right away. Then once you get the simplest thing, you can just start stepping through in trying to figure out, "How is this thing working?" Or, "How is it getting this little bit of style?" And maybe after you removed everything, it's fine. So you start adding on things and as you add on things, that's when you start to notice what's maybe affecting this. I'm telling you, this is really hard to do because you're almost done for the day, you got this one little last line and you're like, "Oh, come on. I'm sure I can figure this out." And you've died and dumped in your PHP code, you've var_dumped, you console.log. And you're just like, "Oh, if I just keep doing the same thing over and over, somehow I'm going to figure it out," right?

Joel Clermont (03:07):
Yeah.

Aaron Saray (03:07):
Hey man, it takes a lot of discipline to do that. But I think that's the key thing. First of all, when we're talking about troubleshooting stuff is break it into smallest little part.

Joel Clermont (03:18):
Yeah, that's a general process, if you will, for how to simplify it. Now, in the example you gave, if I was following you, you're saying you had some rendered output that was different than what you expected, either visually or structurally, or whatever. Are there any tools you reach for? I mean, obviously we're in a browser, so the browser itself has developer tools. But to kind of help you narrow that down, are there any intermediate steps or do you have any recommendations or opinions on that?

Aaron Saray (03:59):
Well, I think one of the things I really lucked out was years ago I worked with some guys that did programming on the AS/400 or System i, and they opened up their editor and immediately started stepping through the code with a debugger. I was just a young hotshot developer and I was like, "Oh, I don't need to do that kind of stuff. How slow, ignorant." Now as the years go on, I am always installing Xdebug or Zend Debugger back in the day, DBG. Any of those debugger tools to start stepping through your code in PHP, in Laravel, for example. So configuring your IDE, a lot of them now can do that pretty easily and pretty quickly to step through your code. As well as the same thing as in those developer tools on a browser. You can put break points in your JavaScript code, you can make that easier when you compile your code enabling JavaScript maps. Or if you want to do the equivalent of a var_dump or something, or DD in Laravel. In JavaScript, you can just write the term debugger and that'll stop the code and pop up the debugger right at that line. That's super easy, you don't even need to track it down then. You can just kind of say, "I want to stop right here," and use the browser to step through.

Joel Clermont (05:28):
All good advice, I only have one nitpick. Because you mentioned AS/400, we now have a mature rating on this podcast because of how old that is. Sorry. Yeah, those are good techniques. I guess I've seen some developers resist Xdebug because maybe on the surface it seems complicated or maybe they tried setting it up like four years ago and they could never get it working, so "I'm not trying that again." But I agree with you, the tooling has gotten better. Once you've done it on one project, doing it on other projects isn't that hard. Even if it's not the first thing you reach for, having that as a tool is incredibly useful in certain scenarios. A little bit off topic, but I've even recommended it as a learning tool to just step through a Hello World in your framework and see everything it's doing line by line and it's very eye-opening for many developers, myself included. When I did it the first time to just see how many layers there are, how all the things are resolving and what's going on?

Aaron Saray (06:38):
Right. Now, I'm pretty familiar with the local development and troubleshooting tools there. I know you focus a lot on deploying software as well. Are there any tools or processes once we get past our local desktop or laptop when something is either in staging or in production? Any tools or processes to do any troubleshooting there?

Joel Clermont (07:03):
Yeah. I guess the first thing I think of is just knowing when there's a problem. There's some common tools that will catch an unhandled exception and report it, BugSnag, Sentry, things like that. And those will often collect a lot of information for you. You'll get a full stack trace, you'll likely get even lines of code where things happen, a snapshot of the request that triggered the issue. If it's a user thing, like what browser they're on, what operating system they're on. All sorts of things that might contribute to it. Ideally, it will also give you a way of reproducing it. I know BugSnag is one I like and you can right-click the request and run it as a curl against your local environment. And a lot of times that doesn't always work, you have to sort of set some things up to make that work properly. But just having a way to quickly try to reproduce it locally. I will not fall into your trap and say anything about debugging in production because I know that you would yell at me. But by having a clear workflow to maybe grab a sanitized snapshot of production to run it locally, play around with it. But, yeah, to just know something happened in the first place, but then get some context from it that will help you go a step further.

Aaron Saray (08:22):
I want to be real about debugging in production too because we talk about all these things, but sometimes you just get some just rusty old junk of a project and you're like, "I just don't have the time," or "Something's breaking now I need to understand what variable is happening," or something like that. Right?

Joel Clermont (08:42):
Yeah.

Aaron Saray (08:43):
And every once in a while you'll come across something like that too in the live world. Where you go to a page, click through something else and all of a sudden you see someone's outputted some variable to the screen. You're like, "Wait, what?" Refresh the page and it's gone, and you're like, "Oh, there's a developer working on that." I mean, I understand that happens sometimes but there's still... We can't be perfectly in the situation about hiding that but we really should try. So instead of var_dumping it to the screen, write it to a temporary file. I get my variable and file_put_contents into a file in temp, and look at that. Or, if you really can't do that either, at least, at the very least, put the output inside of HMTL comments so that people can't really necessarily get a hint that you're doing something. Again, these are not great things.

Joel Clermont (09:31):
These are tools of last resort.

Aaron Saray (09:33):
Yeah. But if you have to don't just put it out on a screen because there's always people out there looking at stuff.

Joel Clermont (09:40):
Yeah, there are. I was logged into my American Express bank statement the other day and I saw something. I'm like, "Yeah, somebody's messing around on this site right now." And what you just said happened, where it went away in a couple minutes. So, fun times.

Aaron Saray (09:57):
Another thing we got to make sure we don't forget when we're troubleshooting, debugging is the database performance too. What kind of experience have you had with that? Troubleshooting stuff, maybe the database performance, or the database tools? What have you used?

Joel Clermont (10:15):
Well, I recently tried out a tool called Scout APM and it had some useful metrics and reporting around performance in general, but even about database performance. Where it might detect that this particular query was higher than the 95th percentile of what it normally runs at. And it would alert you to that. That can be okay, the problem is sometimes things are noisy and you end up turning those notifications off. But just like if you're using MySQL, there's a slow query log. Like, just understand what that is, turn it on, even set it at a relatively high threshold, and then periodically check it. That in itself that's free, doesn't cost anything. And it's a useful way to find things that are running more than a few seconds that you want to isolate and dig into further.

Aaron Saray (11:08):
Right. And you can use something like DESCRIBE to look at how that's performing. Good idea.

Joel Clermont (11:16):
One, maybe final, comment on debugging that's not directly related to the process of debugging. But if you're like me in the steps of trying to solve a problem, you will search on the internet for somebody else that has had that problem. Maybe you will even type in a specific error code or message that you're getting, and frequently you'll end up in something like Stack Overflow or places like that.

Aaron Saray (11:46):
What's Stack Overflow?

Joel Clermont (11:49):
It's all .net. No, it's built in .net. Anyways, the reason this is coming to mind, this happened to me last week. And I found somebody that had the same problem as me, unfortunately there were no replies other than one guy saying, "Hey, did you ever figure this out?" and the original post was from two years ago. I'm only mentioning this because while that was disappointing, I did persevere and I figured it out. But then I took five extra minutes and I replied to that poor fellow that had posted it two years ago to just make the internet a better place. How do you feel about that, Aaron?

Aaron Saray (12:26):
I mean, that's a way that you give back. Because in open source and a lot of the stuff we're doing, we learn from other people, we use other people's projects and products. And maybe you don't have the time to program something yourself and give back or something like that, but you can answer a question. And for every single time that you think, "Oh, that was silly. No one's going to have that same question," remember that was you, you had that question. And there's other people that are just like you, a year later they're going to be traveling that same path so answer those questions and try to give back.

Joel Clermont (12:58):
Yeah, that's your good deed for the day.

Aaron Saray (13:07):
So there's one big difference between men and women that I've noticed.

Joel Clermont (13:14):
Oh, boy.

Aaron Saray (13:14):
It's, when women say, "Smell this," it usually smells nice.

Joel Clermont (13:21):
Okay. All right, I'm thinking.

Aaron Saray (13:22):
When's the last time you're hanging out with your bud and you're like, "Smell this?" "It's great." No, it's usually something horrible. But that really gets me thinking and question, what are your thoughts on this? I know you've done it because you're human, we're all human. When something's horrible or tastes bad, you're like, "Oh, this is horrible," and then you offer it to someone. They're like, "Oh, this is bad. Try this." Why do we do that?

Joel Clermont (13:50):
We don't want to suffer alone. Sometimes there is the shock value of, "I can't believe how bad this is, you have to experience it." So it's an act of kindness.

Aaron Saray (14:03):
Kindness. All right, yeah, that makes sense. I don't know, it's like when people say... When you're going through a bad time and someone says, "If it makes you feel any better, I just stubbed my toe," and you're like, "No, I'm not a monster. Now I feel bad about my own stuff and I feel bad for you in your pain. How would that make me feel better? Now there's two of us in pain."

Joel Clermont (14:24):
But you're in pain together, that's the point.

Aaron Saray (14:27):
Yeah, misery loves company.

Joel Clermont (14:29):
Yeah. But the point about the difference is I could totally relate to that. Because, I can't remember the specifics, but I do remember there was something fairly recently that I asked my wife to smell and it was a good smell. And she's like, "No, way," because normally it would not be. So you called that one, Aaron. I think it's just because we're nastier, but that's just my take on things.

Aaron Saray (14:55):
Are you not sure where to start with your debugging?

Joel Clermont (14:58):
We can help. Get in touch for a free consultation at our website nocompromises.io.