Debugging Django

Speaker 1: Then we are ready for the next talk. Welcome Yuis all the way from Finland. Thanks for joining us. Not for your first Evatiago Day talk, but actually for the second one. One virtual, one physical now. Um I think we should give you a warm welcome. So

Speaker 2: hi everybody. It's been such a wonderful day. Really great talks. A lot of nice discussions with amazing people. Two years ago, this was my audience when I did the talk at Jangarde Copenhagen. And not a lot has changed because I think my biggest fans are still in the front row, just like they were And it's been two years in the making. I really wanted to come here in twenty twenty to do my talk about documentation. But we all know what happened. It took a couple of years for me to to come here. But I was really drawn into by the promise of the bank. Us being in Denmark, Denmark being famous for the base

Speaker 2: cream. I didn't want to miss that for anything So this year when the world opened up I really wanted to to make the trip and this time talk about debugging And to get started I want to know a little bit about you. Here we have a

Speaker 3: Yeah it's just not it's just not updating on the internet. Can you please go here and then share stop sharing and then start sharing again. Yes please. How does that look, Mess?

Speaker 4: Try to go to the next slide. Yeah, I was

Speaker 2: Alright, that then we go there. Does it update now? So like I said, I want to know a little bit about you. So if you have ever written a book, please raise your hand. Even if it didn't make into production. Yes. To the internet viewers, everybody raise their hand. And I think that's expected as software developers. I think it's impossible, not the right box. Software is complex. Translating abstract kind of business ideas into technical details is not one-to-one mapping. It's a challenging venture.

Speaker 2: And if you've ever written a bug, or you've worked with a code base, with other people's bugs, you've probably had to do a little bit of debugging at some point. My name is Hugh Hiss and during the day I work as a developer advocate at a company called Futuris. And kind of an accidental part of my job is that I end up helping a lot of developers debug stuff. Because I couldn't do have a lot of extra time. So people come to me to kind of use me as a sounding board, figure out what kind of problems they have. I've also been teaching programming and coaching juniors for the past decade.

Speaker 2: And in both of these kind of circumstances. I've noticed a certain lack of of skill in debugging. And that's why I wanted to do this talk and and hopefully give you some tools and ideas. for how to become good at it. I also happen to be a big board game enthusiast and I'm gonna be in Copenhagen for the weekend So if somebody wants to get together tomorrow or Sunday, grab some beers, play some board games, I brought a bunch of my favorites with me, hit me up after the after the conference. So debugging is something that most people don't really like.

Speaker 2: For me, it's one of my favorite parts of software development. But it is usually a negative thing because it is associated with stress. Debugging only happens when something goes wrong. And when something goes wrong, things get stressful. And stress is almost never a good thing. And there are a couple of reasons for that. One is the deadlines. Like was mentioned in the previous talk. We live in a real world. We have deadlines. Things need to happen. And if you get a bug on Friday afternoon, maybe sitting on the back row of a conference, and you get a call, things are not working, it is stressful, you end up trying to figure something out

Speaker 2: We also have a lot of internal expectations. This industry is kind of plagued with imposter syndrome. Am I good enough? Did I write this bug because I'm not good enough? Or am I expected to solve this problem much quicker than I can? And that can be stressful. We also have external expectations from our team, our manager, the client, the end user. Everybody wants things to run smoothly, to work as intended. And that can cause a lot of stress to us. And when we deal with debugging, it is the unknown that is

Speaker 2: stressful. I don't know why my code doesn't work. Because if I knew, I would have already fixed it. So when you enter debugging, you don't know what you're doing. And you have all these other things that expect you to make things happen. So I'm gonna talk about three main things today. I'll start with the fundamentals that apply to any kind of debugging, regardless of the programming language, regardless of the software you're building. Then we're gonna take a look at some tools and techniques specific to Python and Django. And in the end, I'm gonna talk about a couple of non-technical methods.

Speaker 2: Because for me, debugging is not a technical problem per se. I don't think it can be solved even with the best tools. It's more of a mindset and an approach that makes you effective in debugging. Couple of things I'm not gonna talk about today that are kinda related are things like testing. Monitoring, logging, I think they are essential part of the entire process. But I think they happen around the discovery process that is debugging. So let's start with the fundamentals. The first and the most important thing when you encounter a bug

Speaker 2: is to stop. We have this tendency that when we get something like a bug, we want to fix it as quick as possible. Especially if it's Friday afternoon. We want to rush into it because we want this nasty negative thing called from our lives. But I think we all know deep down that rushing into things just makes more problems. You might make a hack that fixes that bug. But it might introduce a couple of others down the line. Or at least create tech depth in form of bad code. So even when things are stressful, you need to stop, take a breath, in

Speaker 2: and out, and assess the situation. It's not the end of the world. It's not the most crucial moment. And kind of collect yourself, be analytical. Be calm and approach things as you would any other part of software development And the next thing is to start from the end. And this is the thing that I see most often when I help people develop debug. They struggle with this idea. Because as software developers, the code editor is our world. That's where we live in. So it's natural for us to reach into that.

Speaker 2: Oh, I see a bug in the front end. Let me open the code editor and look at the code. And like Will said in his talk You end up putting 20 breakpoints and not figuring out like which one it is or not finding out where the problems are And that is ineffective. It slows you down immensely. So, what I like to do is to start from the end and follow the trail. For example, if you're building a web application and the bug happens in the front end, but could be related to the stuff in Django. You look at the requests. Where does this come from? Where is the entry point in the code? What is the path behind us?

Speaker 2: And you move backwards in the code from the product. into the possible source of the problem. There's this really great meme by Chen. She shared a couple of years ago on Twitter for exactly this type of thing. We have a lot of assumptions as developers about what the problems are and where do they happen. So we might end up taking a piece of code and making some changes and then nothing happened

Speaker 2: In something into the console, into the terminal Is super great because it takes me a couple of seconds to write this in the code , encounter the bug again, and see if it printed. If it did, I can move along, put some other prints. I can print out some variables, the state, to inspect if things are looking like they do. And printing is immensely powerful because a lot of the bugs are actually relatively simple and the difficulty is figuring out why it happens and where it happens. So this can save you a lot of time.

Speaker 2: But going back and forth, writing print statements, running the app, doing that again is is kind of cumbersome. So the next step is to use the debugger. In Python 3. 7 onwards, you can invoke it with the the breakpoint, and before that, with the BDB module And what it does, it allows you to stop the execution, move around your code, go through it step by step. Execute things, inspect things, and you don't need to be bouncing back and forth every time you want to see something new. It comes with a couple of commands like

Speaker 2: list that lets you see where you are. Especially handy if you have those 20 breakpoints to know which one costed. But it also gives you kind of an overview of that part of the code. What happened just before? What's gonna happen next? It has commands for moving one step forward, one step backwards, and you get a really granular kind of insights into the execution of the card. Another favorite command of mine is ARX, which prints all the arguments that your function got at that point. Because if you just look at the code, you might be able to to kind of

Speaker 2: reason that this code does what it should do. And then quite often the thing is that you might get unexpected arguments to that function. So arcs just gives you an overview on those. And then it acts as a a REPL basically. You can run any Python expressions, you can inspect variables. You can run complex functions, you can change things, see how they work, what goes on. And debugger is a really, really great tool because it gives you this kind of frozen moment in time to look into what's happening.

Speaker 2: What's the state? Where did we come from? Where are we going to? And quite often you can find the exact moment and the exact line where the bad thing happens So it helps you narrow it down. And after that, it's up to you as a software developer to use your skills to fix it. I cannot teach you how to fix the bugs, but I can help you figure out where to find them. A while back I found this really great snippet. If you're using Django with the templates , you can register a custom filter In this case called PDB.

Speaker 2: And the only thing it does is that it gets an element, it runs a breakpoint, and then it returns it. So if you have this registered in your app and then you do something like this You use the PDP filter for any kind of c any kind of data in your templates, it will stop the execution. So you don't always have to go back into the view that is generating this template. But when you work on the front end, you can figure out, okay, I just want to make sure. What this does. It's a very limited view because it only gives this

Speaker 2: function, which is basically one element But it's much faster and nicer than having to find the right view, adding it there, going back, removing it. So it simplifies your life. The next step from from the debugger. I think I counted that this is the third talk that mentions Django debug toolbar. I think it's a good sign. It's a great tool for helping people kind of investigate things on the browser. Use a couple of examples in in Joseph's talk. I just have a screenshot from the the project itself. But basically, you get

Speaker 2: all sorts of information about your request. The SQL queries that got executed, which is really handy. You can see how long things take. And it gives you a lot of information. And it lives in your browser while you use your app in development. It also you can customize it to kind of match your needs. But kind of on its default configuration, it comes with a really nice kind of block and play thing. Then there's a couple of tools that I learned recently that I haven't actually used myself, but I want to share with you so that you can maybe get some ideas and then give them a go.

Speaker 2: The first one is called Django RunDBG for run debugger. And it's basically you replace the run server with this one. And I've been hearing a lot of good about it, especially when you use an API driven development, so when you use Django Rest framework, for example. It gives you a lot of tools to kind of get into the right spot in the back end on your debugger when you execute those KP icons. And the other two Lavarned even more re Oh yeah. Sorry. You can find more about it on the CoktoBot GitHub and on their website. They're the people who who made it

Speaker 2: And then we've heard a couple of of things already today about how to kind of get the best out of your IDE, your editor. I'm the kind of developer who uses editor here and then I use that the terminal to run everything else. So I don't use a lot of IDEs and kind of integrated solutions. But I highly recommend investing time into learning your tools. Whatever tools you use This is a screenshot from PoyCharm. I've never used it, but it seems to be very popular. It allows you to do debugger and breakpoints without writing any code. There's a great talk by Luciana

Speaker 2: about debugging Django in Visual Studio Code. Making it easy to kind of debug, interact. Do those things within your editor. And very recently, today, I learned about this app called Colour. Which really got me excited. For the people maybe watching this later, you should definitely watch Wheelstock from a couple of hours ago. When he introduced colour with really co-like visualizations, helping you understand the code. And this is why I love going to conferences, always learning something new. So those were the technical things.

Speaker 2: And then a couple of non-technical methods. And I think these are really, really important, but often overlooked. Because sometimes the best solution is not to be on the computer. The first one is called brain dump And the idea with the brain dump is that our brain is rather limited by the things that we can keep in mind. We build mental models, we try to figure things out. But it gets kind of hard to keep everything in your head. So you take a pen and paper and you write down What is the problem? In terms of not the code, but kind of what happened? What is the bug? How does it manifest?

Speaker 2: Then you write down your assumptions about it. I think it happens in this view, or I think it happens in this model, or this auxiliary dueling You write down all the assumptions to get them out of your head. And you write down what you've actually tried. Not just the things that your brain is telling you that you tried, but try to make sure that you only write the things that you actually tried. Because our brain is quite magnificent, that it skips steps every now and then. It makes assumptions that, of course I did that. Of course I've tried turning it off and on again. But that should always be the first step. And the benefit of this brain dump is that we don't have to worry about remembering everything.

Speaker 2: It's somewhere written down. We can relax. We may take a break, maybe go for a walk, maybe take a nap, sleep over it overnight, go for a coffee with a colleague. And it's your subconscious work on the problem. Human mind is really good at that. I got through university mad by basically solving the homework while I was sleeping and then waking up and writing the solutions. Because I couldn't solve them with my conscious mind. But taking a break is is really effective. It distances you from the problem for a moment. It gives you something else to think about. It hopefully releases the stress. And if all else fails, you can always talk to a rubber duck.

Speaker 2: I have unfortunately forgot mine at home. I was planning to have like a collection of my ducks. As a Brockford dog. So rubber dog is equally a meme in the industry, kind of an inside joke, but it's also really effective when you explain technical problems to a dog. You force your brain to stop skipping steps. Because if you skip a step, you cannot explain it. So you force yourself to think about the problem in a very different way And that's why you often get the result before the dog answers. Then there's something non-debugging related that I want to teach you at the end of my talk.

Speaker 2: About nine years ago, I got started in developer communities with our friends from the Ruby community. And back then I learned about this concept called the Friday hug. And Friday Hug was something that the Ruby community did on their Friday conferences and workshops. You can maybe see some pictures behind the wall. And the idea is that we stand up and we do this hocking motion and I'll take a self-effort the stage. I think it's a lovely way of kind of being part of the community. And for me, it's especially part of collecting memories. From my dogs. There's Bycon Czech Republic from 2019, Bycon

Speaker 2: Estonia 2019, Jungle Girls from 2017. And now I would like to do it with you. Stop if you can assist me. It was good that we practiced Queen Bowler. I'm about to take this outfit. If you don't want to be in the picture now is the good hide behind somebody. And then when you hug the word, be careful not to punch anybody One, two, three. I think couple. If you want to get in touch

Speaker 2: after the conference, you can find me online. Twitter at Amati, my website amati. org. If you want to learn more about my employer, you can find that on futurist. com. Thanks to the organizers. Thanks to the the world getting better that I actually made it here. And I think we're all Pretty much ready for the cake. Thank you.

Speaker 1: Thanks so much, you wish. I think we should take at least a couple of questions. Yes. Um is that slide for me

Speaker 2: I know

Speaker 1: I misannounced the cake break a couple of times. Um Yes,

Speaker 2: it's the best motivator to be on time with your dog when it's just before the lunch or just before the cake.

Speaker 1: Do we have a question from the audience? Yes.

Speaker 5: You mentioned that you've been mentoring people in this kind of thing for a long, long time. Imagine that you don't know any of those tools. Not even print, not the rubber duck, none of the things you've done. Which one has your experience led you to consider the best single one in terms of value for teaching some level?

Speaker 1: So which method, the question is, is uh the uh one of the best, maybe the best uh in your experience, like very long experience, uh to teach new developers to debug

Speaker 2: Yeah, I think there's there's two sides. I think the most efficient is the duck. Just asking the questions, forcing yourself to phrase your abstract kind of incomplete idea of the problem into concrete words. But if I'm teaching somebody or or mentoring somebody, I would say always start with the print. Because it's it's the most kind of it's the easiest one to learn. It's something that pretty much every developer does at some point. It's pretty much the first thing we learn. And it is something that doesn't require you to learn complex things and understand a lot of the kind of

Speaker 2: complexities and hidden things within the code. But it just gives you an understanding of what is happening right now at this right point. And it is especially powerful, not just because we don't know. But worse, we think that we know. So we have assumptions about the state and the data, and it's super important to kind of shut them down as quickly as possible. So for me it's a rubber dog asking questions. You're giving an idea to somebody new just put a lot of print statements everywhere. And another question.

Speaker 6: Yes. And yeah, so Johannes, I've also uh for the last year I've been teaching at Python course and I also taught myself students to use the print uh you know extensively because it's easy. But apparently on TikTok there's a whole meme on like my teacher told me never to use print or console lock but uh I still did it. And and I I I wonder where that comes from. Like it's it's considered dirty or like it's uh there's something that's just you're not a real developer if you If you ever use print and I I I had a hard time explaining to my students like what why is this considered uh practice

Speaker 1: It's a really good question. So the question is, uh why is the print statement considered bad practice in debugging?

Speaker 2: Yeah, I think probably comes from this idea that the code that end up in production needs to be as clean as possible and and kind of leaving any print statements in the production code. Is this kind of considered kind of not great or or not kind of pure gold. It's not great. So I think it stems from that. And can they kind of we need to understand that there's two different cases. There's putting something in the production code and putting pro debuggers or print statements inside the code to be taken away. But I think it it also comes from like if you make a pull request and you've left the console log in JavaScript or you've left a print in Python, somebody will probably tell it

Speaker 2: You not like No, take it over like Rememb like remove this. Not maybe the other party understanding why. Um I'm not in TikTok, so I don't know about the good TikTok memes. I'm happy to to learn about that. But yeah, I think it's it's this kind of Also at the different state and the kind of level of maturity as a developer, we might use those a little bit differently. Like like for example If I'm entering a junior very early in their career, I would rather them like write comment about everything. Write a comment about what does it do and how does it do it and why does it do that

Speaker 2: But as you become more senior and you kind of understand the code, I think you should leave the comments for kind of like the why. Because the code answers what and how. So it's this kind of we need to do different things at a different stage of our careers , kind of developer journey. And I hope that us as senior developers will remember to be kind and understanding to juniors making these kind of things. And not kind of point blank say that this is bad but explaining them why you don't want certain type of things in production but it's okay to use them in development

Speaker 1: And nowadays we have Lindas pre-commits. We can actually use the print stage and not be afraid that it ends up in production. I think that will have to be the last question uh as we try to maybe gain five minutes of uh the delay. Um And and uh first of all before the cake break big hand for you is Second week before the cake break Big hand to Caroline for really, really working hard.

Speaker 1: We'll try to be back again five minutes