 until it doesn't. If Michael's here, it always works. Yes, okay, excellent. Okay, yeah, I'll just like speak, explain a lot or something. Okay, hi people, hi. Today we're going to talk about debugging JavaScript, which is something that for some reason people don't really talk about, so we're going to talk about it. My name is Sherman. I am called Sherman, not sure, or like Charmin. I don't know why, sometimes that happens. I do not be fooled by this accent. It sounds Singaporean, but it's not. It's actually Malaysian. Yeah, and I work in sunny Singapore as a front-end web engineer at Vicky. I don't know if any of you have heard of Vicky, but we are here. And I'm also a request center alumni, and the reason I met why I mentioned these two communities slash companies is because there are two communities that I really love. So if you want to talk about any of that, you can come talk to me about it. But today we're not here to talk about that. We are going to be talking about debugging. And in programming world, whenever someone mentions debugging, it usually refers to the process that you take to fix defects in your code. So something may not be working right, it may be throwing an error. And debugging is like the steps that you take to figure out what's wrong and how to fix it. So yeah, who loves debugging? Anybody? Yeah, all three of you, literally one, two, three. So debugging can be kind of painful. Like, is this thing like, this is a bug, gotta fix it. And I'm just gonna, before we start, I want to get a quick survey of like, you know, okay, how many people here write front-end JavaScript? Okay, majority, great because this talk is for you. How many of you use console.log to, you know, print out stuff when you debug? Yeah, keep your hands up. How many of you also use the Chrome debugger tools? And by the Chrome debugger tools, I'm talking about this guy over here. Okay, good, good, quite a good number. So that's good. I'm gonna, in that case, since we have like half the room who have used this before, we're gonna talk, by debug, I mean like specific like debugging tools over here, this specific tab here. Yeah, can you just get a quick show of hands on who actually uses that. Okay, all right, good. Excellent. So we're gonna be talking about that a little bit more today and how to get a little bit better. Today's not so much about like talking about tools, but more on like the workflow for debugging. I did a little quick poll thingy on Twitter and like 30 people answered it, which is like not bad. But like most people, like half the people actually don't use the debugger tools for debugging, I realize. Quite a number of people still prefer like just using console.log. And I was like, I wonder why? Is it because like it's hard to use or I don't know, maybe it's just a different process. So I'm going to run through today some of the things that I found kind of useful or helpful to like, you know, up your debugging game. And this is more for people who are beginner intermediate programmers who have done quite a bit of debugging and want to get better at it. So if you're like a super advanced JavaScript debugger person thingy, then sorry, this is not for you. But if you have tips or tricks, or if you want to shout out like stuff, you can. And hopefully this talk will help you like explain how to use debugger tools better to the more junior programmers in your team. So hopefully that's useful. And we're going to be talking mostly about debugging in Chrome slash Firefox DevTools. So sorry, this is mostly for front end people, but most of you do front end, so that's great. A lot of things that we'll be doing today will be on the Chrome DevTools, but I tested it on Firefox and they are like analogous tools to do it too. So very good. Sorry, I don't know much about debugger tools on H, but if anybody has tips, that would be fantastic. Just want to point out you can use Chrome to debug Node.js. Yes, cool stuff. If you have time, maybe we can talk about that too. So let's talk about regular debugging that you do on a day to day basis. Maybe if you're a new programmer, this is a process that you go through quite often. And I'm going to just run through what it might look like when you encounter a bug. And this is specific to when you're inheriting code that you're not familiar with. So, example. All right. So I have an app and the app does something. And I'm told that this app is supposed to take in a list of numbers. Let's say one, two, three and sum it up for you. So it's fairly simple. And it should print out the result. But when I receive this app, I'm like, ah, no, it doesn't work. We don't know why. So what is the first thing that you do? Assuming that you have the source code. Let's see. Oh, where did my code go? Not this one. All right. All right. Oh, I'm on Flux, yes. I am on Flux. Disable for an hour. All right. All nice and bright. So, okay, you have an app. And because I wrote this, and it's intentionally a little bit buggy, so, you know, don't do what I'm doing here. And I'm going to sort of go through very quickly like the different parts of it. So it's just a form that takes in that when you submit a form, it gets a user input. So like a list of numbers, for example. And then it takes the numbers and gets a sum and it displays it. So there are three parts here where something could have gone wrong. So when you're looking at this and you don't know what each part of the code does, like the very natural thing is to be like, okay, well, let me just make sure that, you know, it's doing what we think it's doing. And the functions that do all those three things up here, but don't worry about details. So a very common thing to do would be like, okay, I'm going to do this correct. That's all the log, numbers. Oh, no, all the complete. And then I'll be like, oh, is the result correct? I don't know. Let's find out and we'll see where, you know, where things go wrong. And then I have like, like, I'm going to do that. And you check out your console thing. Yeah. So I'll be like, okay, let's see this works. And I'm like, okay, great. My numbers are correct. But like something went wrong when I was summing things up, right? And I'm like, okay, well, something's wrong and I get some and then you go to get some and then maybe you will like console.log each number there or something and then figure it out. I don't know. Some of you might see the bug already. But yeah, so it's a very common like workflow. You just go and put console logs, see what's wrong, and then like, you know, finding a problem. So this, this has something to, there are some like benefits to doing this. For one is that it's quite beginner friendly. All you need is like console.log and straightforward. You just like, dump things out where you want to check what the values are to make sure they're okay. So how many people like, you know, have done this at some point in their life, you know, like, yeah, let's console all the things. But it's both pain points here because like you had to go back and forth and edit that browser. So it's like a little bit of a disconnect there. And at least console.log everywhere, like who has shipped code with console.log in it. Yeah, I admit it, the shame. It's okay, everyone does that. Unless you have tools, like there are some tools now that you can integrate with webpack to like, get rid of console.logs for you. So that's very nice. But, you know, ideally you shouldn't have to pollute your code to all these like logs. And it's not like you have to output format. You don't know like, oh, where did this like, you know, numbers come from? Is it like the first time or the second time? And then you have to like, oh, first time, second time, like this came from this function. And yeah, it's a mess. So I was like, okay, there must be a better way to debug. And I saw this, like when a friend of mine like use the Chrome debugger tools and I was just like, what is this? That's awesome. So this is what it would look like if you're using like Chrome debugger tools. So I'm going to show, not tell. I'm going to get rid of all the console.logs here. So just get rid of that, get it back to its original state. Don't mind the subline text. Please pay up message. And okay, so I'm back to my state here. I'm like, all right, great. Things are not working. And the first thing that I would do is go to the sources tab and look for my main.gs. And this is the same code that you saw just now. Right. It's all the same stuff. And if you are new to using debugger tools, the easiest way to start is to replace each console.log. So wherever you usually put console.log, just add a breakpoint. And if you're not use breakpoints at all, what breakpoints are are basically like, hey, pause your code here. I want to look into it. So you put your breakpoints in. In this case, I want to see what happens when I get numbers, what happens when I get results. And I run my code again. And breakpoints do what they do. They pause your code so you can look around. And the nice part is that you can see what your variables are in your random codes running. So you can either see them in line here, or you can see them in your scope. You can see numbers and results are defined because we haven't run that line of code yet. We haven't gotten our numbers. And what you can do is when you're in a pause state is you can run the code, which will run until it hits a nice breakpoint. Or you can step through the code line by line. And this is what I use most of the time. So it's a lot going on here, but you can just focus on where the code is and also these controls over here. We will be talking mostly about that and also this part here with the scope. Yeah. All right. So you step into the line 48. You get your numbers. That looks good. Awesome. And then you run the next line of code, which is to get some. And you see, oh, well, here's a problem. Results returning not a number. Something's wrong there. So what do you do? And so what I would do is I'll just like, okay, here I'm running it. You'll finish running that particular input. And then I run it again. And this time round, I'll just like run the first one because I know it's not a problem there. I can remove the breakpoint. Instead of running this line and going like straight over to the next line, I'm just going to step into the next function call. So this is like the third function, the third thing that you can do when you're in the pause state. And what stepping into is that does is that it jumps into to get some function itself so you can run your code line by line. And here I can see that numbers is currently past it. And result and now I'm still like undefined because you haven't done stuff yet. So I'm just going to step into it, step into it, and then step into the for loop. And then you can see how num updates. So you're looking at the first number. And I'm going to step over and you can see here in your blog as well what iteration you're on. And I'm going to step over again and immediately I see what the problem is. Like result is undefined and you plus one to it and becomes like not a number. And you can verify this by doing like undefined plus one in your console just to be sure. And you're like, yes, that does not work. That's terrible. Okay. And the cool part here is that now that you know where the problem is, what you can do is just to change your code like in line here. And you can save it. It doesn't actually persist the changes to disk, but you can just do it for this round. And you can see that it actually works now plus 60. I don't know what that is, but I'm going to guess it's correct. Yeah. You can add this file, you get to your workspace. I've tried it, it works. And that way you kind of use Chrome as your IDE, which is really nice. So yeah, it makes it really easy to debug and fix and find things out when you don't have access to the source code itself sometimes. So yeah, that's pretty, I don't know, when I first saw this, I was just like, that's amazing. You know, that's super cool. Like, especially in line values that was really, really useful. So yeah, I don't know, is that new to anyone? No, some people. Yeah. Okay. Good. It means that people are using the various tools. Some other cool stuff that you can do are conditional breakpoints. So you can add a breakpoint, but you can also set it so that it only runs if a certain condition happens. So this was, if let's say result, if result is not a number, this is how we check it results, not a number. And if you want to run it, and in this case, I'm just going to put in the, I was going to save that so it still like hits it. And then when I run it, if it's not a number, it's going to, it's going to break. If not, if it's already fixed, then it, yeah, if it's already fixed and now it's running fine, yeah, it shouldn't, yeah, it shouldn't run it. Oh wait, let me try that again. That wasn't, yeah, it wouldn't run the breakpoint. So that's super useful. And if you're using, let's say a third party library and you have error that's running in it and you want to fix it. For example, let's say I have jQuery. I don't know if people use jQuery. And you want to debug it because it's drawing an error and you can't figure out why. What you can do is that you can pretty print it. So you can look into it. And this is also super useful when you're looking into obfuscated code and you're trying to figure out what's going on. So those two, those two things I really like. Yeah, there's also an option to pause on exceptions. So let's say there is an exception that occurs. Let's say it throws an error somewhere, you can automatically break it there. So you don't have to like search for it line by line. So that's also useful. So the general workflow that happens when you're using debugger tools goes something like this. Like first you reproduce your problem, just to make sure it's actually a problem. Sometimes it isn't. And then you find a line or lines where the problem could potentially occur. And then you start break points where interesting things happen. You run a code again. And when it hits the break points, it stops, it pauses, and you just like step through the code line by line to make sure what it's doing is expected. You can step into functions if necessary, just to make sure that functions are behaving the way you expect them to. Look at the relevant variables either like in line or in the scope using the command. And you can use the command line to verify what you think is really happening. And hopefully identify the root problem. So in this really trivial example, it's just like a simple technical error. But sometimes the root problem comes from a design decision, so that might take a little bit more time to figure out. And I actually adapted this from an article by Elizabeth Hart. If you work in points, you don't really have to switch between windows. You don't need to log anything to console. You don't have to change your console log tab to your console tab just to see what the outputs are. It gives you a code theme, so normal shipping console.logs, yay. And you can even debug things without access to your source code. So there was an actual example where only on production for some reason, like there was an error that was like crashing the Viki homepage. And we were like, what's going on? Because it's from a third party library and we had no idea what is there. You can't console the log in it. So what we did is to do the unoff you skate the code and to set a breakpoint and just like step through it until we figured out that it was just like reading in something it wasn't supposed to and it was badly formatted. So it gets pretty useful in that sense. Especially when you are also debugging code that you're not familiar with, like someone else might have written it so you don't know how it flows. So yeah, there were a couple of resources that I found that were quite interesting. There was one by a list of part from 2009 and like in a list of like debuggers, it didn't mention Chrome because Chrome debugger doesn't exist back then. But it has a little challenge where it gives you a buggy app and you're supposed to like fix or like discover the causes of a list of bugs. So it's like a murder mystery thing. That was pretty interesting. There's some that a little bit that don't quite work because this is from 2009, but do check it out. And also like this is an article about like Chrome debugger tips. I learned about the conditional breakpoints from here. So check that out. That's pretty cool. And so yeah, that's it. Thank you for listening. You can tweet at me if you found it useful or if you have questions or if you want to like add on to like whatever discussion we may have. And yeah, we're hiring so Vicky is like some of the best engineers I've worked with. So you know, yeah, you might want to think about that. So yeah, stuff, stuff, stuff. And I think you have time for questions or like tips if people have like things that they want to talk about. Yes. Yes. Thank you. I totally forgot to mention that. That might sound like some like. Yeah. So this is equivalent to this is equivalent to ending a breakpoint. If you don't want to like go into sources tab and I look for a particular line, this will also like break it. So that's useful. Any other like debugging tips? Because I'm also like still learning this stuff. And any like tricks will be useful. Yes. Put it on the back. Yes. Tech traces are really useful, especially when you have like a bunch of things running and you don't know like where the error is coming from, like who triggered it. Triggered it like the sector is also really good to go up and like figure out who's calling that function. So that's good. What? A couple of them here. Yes. With evaluating on the console, you can evaluate things in your current scope, which is quite useful. Yes. Actually, yeah, that's true. I've heard of that, but I've actually never tried it. So let's say if I stuck here, like can I, I can just do like numbers and it should give me that even though it's not in scope generally. Oh yeah, you're right. That's awesome. Yes. Any more? Yes. Breaking on events can be very useful when you're dealing with the front library. So when I used to write stuff on Agile, and I didn't know in that huge course where something was triggering. So I would sometimes use a break point on click, for example. Yes. And that would take me deep inside the first part where Agile first listens for that click and starts working with it and work back on it. That's also really useful. So I think like, for example, if I want to like listen on click events, I want to know what happens when I click, right? So if I click on something, you'll like give me, oh well. Deep inside. Apparently, jQuery is listening for you. I don't know why I wasn't using jQuery in this. So yeah, useful things to know jQuery listens to your clicks, regardless of whether you want it to or not. Anyway, let's see if it listens to other clicks too. Okay, cool. That's also a really good one. Any other, you had one? There's plug-in available if you use Angular for your problem, which actually knows the bug log, like the various constructs in Angular and then helps you, okay, this is in the control, this is in your model. So it becomes much, much clearer because you jump into any average Angular stuff you go, what? Yeah, that's a good one. So it's both available for Firebuckets as well as for Chrome debugger tools. So the general tip is go to the Chrome store and look for extensions to the debugging tools that are a few around that make your life easier. And specifically, like I said, when you're in Angular, Angular 2, they have plugins for the 2.0. Awesome. Yeah, there's also React debugger tools. You're doing React and don't have React debugger tools. They definitely get on it, same for Angular as well. So good stuff. I think there was another hand somewhere, no? Another one? Yes, yes. You can actually modify your code on the source code file and then see if your assumptions of what a fix would be works. Oh yeah, like how I demoed just now, are you referring to that? Yeah, you just type out whatever you feel like is the right answer and then you say and then the code will run and then you can see what your fix, whether it works, right on Chrome stuff. Right, cool. I think I had a demo on that too, so yeah, that's awesome. Yeah, if there are no other questions and stuff, do we see our time? Yeah, what was it? Escape. You get a little console at the bottom. Oh yeah, I usually don't use this one much, but oh that's cool, actually. I didn't know you could do that. Nice. So you don't have to let me change paths all the time, right? Yeah, yeah. All right, cool. Thank you.