Latest / The Laravel Podcast / Debugging and Monitoring, with Jonty Behr

Transcript

Debugging and Monitoring, with Jonty Behr · The Laravel Podcast

• Matt Stauffer: Welcome back to the Laravel Podcast season four. Today we're talking to Jonty Behr, the founder of Mettle, Understand.io, and Laravel Live UK about monitoring and debugging. Stay tuned. All right. Welcome back to Laravel Podcast season four where every single episode is about a specific topic, and our topic for this episode is debugging and monitoring. If you're unfamiliar with those topics, debugging when I'm talking about that, what I'm primarily meaning is when there's a bug in your application, whether it's a bug as you're programming it, or it's a bug that happens in production as the users are using it, how do you figure out where the bug came from and how to fix it? Matt Stauffer: And then in monitoring, it is more about when your application is running and you're not thinking about it, how do you know how it's going? Monitoring is relevant both for bugs, so there's exception handling and tracking, that kind of stuff, but also non-bugs like resource usage and logs, and all that kind of stuff. I'm bringing on the... Let me get my words right. The founder or co-founder, you'll have to tell me, of Mettle, which is a consultancy working in Laravel. And then we've got Understand.io which is an exception handling, and I think log tracking service, although I'll let you tell me when I'm right there for Laravel. I think it was the original Laravel focused exception tracking service. Matt Stauffer: And then also the organizer and founder of Laravel Live UK, which is a Laravel Live conference. If anybody doesn't know, the Laravel Live conferences are the regional, not sponsored by Taylor, but officially sanctioned by Taylor conferences that happen in India and in London and some other places. He runs Laravel Live UK. And there's probably 10,000 other things. I know you've had other products and other companies. But we met through Laravel Live UK, and I thought you'd be a perfect person to bring on because you run Understand.io, so you understand monitoring. So even though I just talked a lot about what you do, could you introduce yourself and talk about what do you do, and also what's your history working with debugging and monitoring? Jonty Behr: Yep. Thanks very much for having me on. I think probably it might be a good idea just to take two minutes and say my background actually isn't in programming or development at all. I came to this relatively late in my life and was in a completely different career in corporate finance and banking. And that's what I had studied for eight years or so. I only came into programming probably about 11 or 12 years ago. Matt Stauffer: Okay. Jonty Behr: At that time CodeIgniter was the framework to be using for small products. Zend was around, and Symfony was starting. Due to a change in personal circumstances, I found my way into the programming development world, started a project on CodeIgniter. In fact that project is still running- Matt Stauffer: Nice. Jonty Behr: ... partly CodeIgniter, partly Laravel. It's a kind of mix of the two. I came across Taylor who came into CodeIgniter at the same time on the CodeIgniter forums, and was aware of Laravel right from version one when he released it. That's my introduction to Laravel from there. I think I actually had a application in production on Laravel 2. Matt Stauffer: Oh, that's impressive. Jonty Behr: It wasn't for a long time because Laravel 3 came out quite shortly after that. But it was definitely in 2, and I remember having to upgrade it to Laravel 3, which is relatively easy in those days. I think partly because I was involved in the community from those early days, it naturally grew into a consulting side business. At the same time I was writing a SaaS company. That's how Mettle was founded. It's grown a little bit over the years. We've got a couple of employees now. I'm the sole founder of it, 100% remote company. We've got employees in four countries I think. Matt Stauffer: Cool. Jonty Behr: And so, basically, what I do now is, Mettle runs a couple of our own SaaS companies, and then we do consulting work as well. They compliment each other. Matt Stauffer: Got it. Jonty Behr: The consulting is the bigger part of our business, but we're hoping to grow product slowly but surely over time. There's no rush to make a big bash or anything. It's just, we grow our SaaS products, and time over time it compounds. How I got into the debugging and monitoring part was one of the guys that works with me, Ivers, has a strong Elasticsearch background. He came to me with a proof of concept pretty early on. He said, "I've built this tool, which is a log tracking tool." Jonty Behr: At that time it wasn't specific to Laravel at all. It was just a generic, you send an HTTP post to an end point, and it stores it in Elasticsearch, and it indexes it, and then you can do a free tech search on your log files. He said, "Well, don't you think this would be awesome for something like Laravel?" There wasn't a lot of Laravel specific product at the time. I think Papertrail had an agent, a Laravel agent. But most of the others weren't Laravel specific. That's essentially how Understand.io was born. At that time it was purely a log tracking tool. It didn't have anything to do with exceptions... Matt Stauffer: Oh, interesting. Jonty Behr: ... or bugs. It was purely logs. We launched it on that basis, that it was a log tracking tool. It had a few features tied into exceptions where you could set alerts and all the rest of it. Slowly over time we pivoted away from being purely logs to being a more exception and bug tracking tool because I think that's what people were mostly interested in. Yes, logs are interesting, and yes you can search through your logs if you're looking for something specific. But really, what people want to know is, is there something going wrong? Are my users hitting a specific error? And if they are, I want to be alerted about that straight away. And so, just sending raw log data, totally fine. It still works, and we have some customers that are sending us in the order of a million log entries a day. But for most customers they want the pure exception tracking. Matt Stauffer: Yeah. Jonty Behr: It's a Laravel specific tool, but we did introduce on top of that as well, JavaScript tracking and exception tracking. Matt Stauffer: Oh cool. Jonty Behr: When was that? About six months ago or so. That's just another tool in the arsenal to help with it. That's really how Understand.io was born, and has grown over time. Matt Stauffer: Okay. You got into it as a function of need. For anybody who doesn't know, in the early days of Laravel, there's a lot of softwares and service applications that we all rely on today that didn't have any PHP and/or Laravel integrations whatsoever. And so, one of the things we all had to do in those early days is either build our own adapters or build our own rudimentary versions of the same things like Jonty's talking about here. Sometimes we also had to campaign those people and say, "Hey, we're a growing market, you should consider actually building adapters for all these, our things and potentially docks." Matt Stauffer: Even for the longest time, and some of them still, the PHP and/or Laravel docks are just completely substandard compared to their normal markets like Ruby and JavaScript and stuff like that. The idea that you had to build your own log management doesn't surprise me at all because I do remember when Papertrail first really built integration for Laravel, it was this big moment of joy for us. It took a while to find. We tried a whole bunch of different Ruby exception trackers trying to match PHP and Laravel to them until I think, Bugsnag was the first one we used that was a full on exception tracker. Matt Stauffer: I think we're getting a little ahead of ourselves because we haven't even introduced the concepts we're talking about here. I've got three ideas here. Two of which I prepped you for, and one of them which I haven't. I'm going to ask you for each of these ideas, if you had to describe this word, this topic to a five year old, how would you describe it? The first one is debugging. What is debugging in the programming context? Jonty Behr: From my perspective, debugging, it contains the key word of bug. A bug is when something goes wrong. How do you find out what has gone wrong? You need to be an investigator, and there's a few different ways that you can approach it depending on what the bug is, how you go about that. Matt Stauffer: All right. The next one is what is monitoring? In this context. Jonty Behr: Monitoring I would define as making sure you keep an eye on your services to ensure that they're running in the best possible way. That may be a bit difficult for me to explain to a five year old. But it's just making sure that everything's running smoothly and that nothing unexpected is happening to your program. Matt Stauffer: Yeah. That's great. The last one is hard to explain to anybody, and I didn't prepare you. No worries if not, but what is observability? Jonty Behr: I think probably, the two previous ones fit into observability in some way. Because you need a way to surface the bugs that you find, or the monitoring that's taking place, and present it in a way that's observable, visible, easy to understand, and hopefully easy to rectify at the end of the day. Matt Stauffer: All right. When it comes down to all three of these things, as you can see they're all kind of related. They're understanding what's going on, and some are more explicitly focused on when things are going wrong, for example debugging. But some of them are about whether it's wrong or right. That was one of the things that Jonty is saying here is that monitoring is about not just knowing whether there's exceptions, but it's also just knowing, what's the server load? Or whatever else ends up being... It's having an understanding of how things are going. If you've been programming for a little while, you probably have had experiences where you push something up and you assume it's working fine, and then something breaks and you don't know why it's breaking. And then you have to start looking at the smells, right? Jonty Behr: Yep. Matt Stauffer: One of the smells that I've often seen happen for people early in the days is, "Well, we're getting this particular error and now we get a white screen." And then they say, "Well, let's go Google that error." And then that error tells you, you're out of storage space, or you're out of inodes, but you didn't know that pre-actively, right? Jonty Behr: Yeah. Matt Stauffer: When you're talking monitoring and observability, you're in this world where you say, "What are the things we need to be on top of so we don't hit the error, but we fix the problem before the error happens." In that particular circumstance you'd say, "Well, we need to at any given moment know how close we are to 100% of inode usage, and 100% of disk usage. So that when we hit 80% we are aware, and we make a change so we never actually hit that error." Jonty Behr: Absolutely. Matt Stauffer: I think those are really fantastic descriptions for that. Again, we're targeting both people who have been programming for 20 years, and are programming pros. We also are targeting people who have been programming for 20 years who don't have a good handling on monitoring and observability. But then we're also targeting people who are just getting started. Let's talk to the people who are just getting started for a little bit. What's the most common circumstance when you're programming and you find a bug where some sort of debugging tool or process is helpful for you in your local development? Can you give me just an example of some time recently where you're programming and you just found a bug, and it wasn't immediately apparent what was going on, and what tool did you use to help you figure out what the bug was? Jonty Behr: Yeah. I think probably it would be interesting to just touch on for a minute is to describe the process now versus when I started 10 or 12 years ago. Because in those days I was programming on Windows. I think it may have been XP in those days with that XAMPP installation, which runs PHP and MySQL for you as a service on Windows. This is back in CodeIgniter 2 days. If there was an error, it took you a lot of time to try and find out what caused the error, where did it come from? Because typically it was just like a generic PHP error message. Jonty Behr: There were no stack traces. There was nothing along those lines as to give you some clue of where to look or where to find it. If you compare that now to the kind of tools we've got now, if an error is thrown on your local environment, well, you're going to get an awesome error screen showing you nine times out of 10, exactly where the error has come from, a whole stack trace, and all the debug information. It's a much, much easier task these days than it was five or 10 years ago to find out what's gone wrong. Matt Stauffer: Yeah. Jonty Behr: I think historically, and I actually remember getting this running on XAMPP. I actually used debug to step through the code step by step, if there was an error. You could really inspect all the variables at run time, and go through it step by step until you found out exactly on which line it was erroring, and what the state of your request was at that point in time. I think the need for doing that kind of debugging these days is not as great because of the state of the tooling that's available now. And so, most of the time, either you get an exception thrown through your program or you can just do a simple DD, and I'd say 99 times out of 100 that will give you enough information on how to debug further. Jonty Behr: If you're a new programmer, you might need to do a bit more investigation to find out how to fix it. I think for me being able to debug an error is one of the key critical skills of probably moving from a beginner to somebody of a more senior level. The only thing that can help you with that is experience. You can't go read a manual to learn. You can read books, or websites, or watch videos. But when an error or an exception is thrown, the ability to fix that and fix it quickly is an experience based thing. That's something which will come over time, and is usually the thing that separates somebody who's just starting off from somebody who's more experienced. Matt Stauffer: I love that. That's a great point. It's interesting. I don't know if you're familiar with this tool, but I'm building this tool called Onramp that- Jonty Behr: Yep. Matt Stauffer: One of the things we've realized is that there's technical skills you need to teach people, but there's also process skills. I realized we need a whole section about how to debug. Because the number of times when I've been teaching somebody who's new, who's read all the documentation, they've read the books, but what they don't know how to do is figure out how to solve a problem when it happens. That's actually I think the best thing that's come out of my live streams is that I break stuff all the time in my live streams, and people watch what my process is for fixing things. They either A, learn, or B, are validated that, "Oh, Matt breaks stuff all the time too, and he uses the same tools that I use to fix them too." Jonty Behr: Yeah. Absolutely. I think there's two points there. One is, there's nothing wrong with an error on exception being thrown when you're working locally. It's almost, if there isn't an error in exception then I think something's wrong rather than something's right. It's definitely an opportunity to learn. I think you made a good point there as well about how do you teach somebody to debug? One of the clients that we used to work with, we used to do all the back end infrastructure for them. In fact, we still do. They had a very small team that we used to compliment. We had to write a semi manual on how to fix certain things if a bug happened in production. Because our time zones were completely different and we weren't always available to investigate or fix something. Jonty Behr: We would write out as you said, smells. These are the smells. If this happens, these are the steps you need to take, and we would list five steps. Most of the time it would be like, "Okay, this will get you to the right end point if you follow these five steps." But if there was a small that they hadn't encountered or that we hadn't described to them before or written down, it would take them two or three hours or whatever to fix it. In the end, they may ping us in the middle of the night and say, "Hey, our server's falling over, how do we fix it?" And it would be a five minute job for us because we've seen it before. Matt Stauffer: Yeah. I love that, and I love the idea of providing people with that level of tooling. It's like you're giving the client not just the ability for everything to hopefully work, but also ways for them to have that ability. It's like give a man a fish versus teach a man to fish type of thing. I love that. Jonty Behr: Absolutely. Actually, sorry, just to add on to that. One of the learning tools that we use internally as a company is, if something goes wrong in one of our servers, I won't give it to the best guy in the company who I know will fix it in two minutes. I'll give it to one of our other guys and say, "Hey, it has this error, can you go fix it?" If it's not something critical. I'll put one of the more experienced guys with him just to watch him silently that he's not going to break anything or that he's moving along the right path. That's what gives him experience. Because fixing bugs in production is a different story to doing it on local host. You've got the added pressure. You've got maybe the server is down, and it's like you feel this weight on your shoulders like, "I need to fix this as quickly as possible." And that's a great learning experience. That's a great environment to learn in. Matt Stauffer: Yeah. That was actually a perfect transition. My next question was, what's the last time you remember catching a bug via an exception tracker? It's funny because actually, one just popped up, a little notification in the corner of my window. I'll actually share that one really quickly. I just had a bug pop up on a project that we released at the beginning of the week, and it says... Let me see what this error says. It says, "Unhandled error, error call to member function runs on null." Just for anybody who's never worked with an exception tracker like Understand.io or Bugsnag, whatever else is. And then it says, "Location. It's in app/http/middleware/themiddleware.php:75." Matt Stauffer: I know exactly what file the problem is in. I know what the error is. If it says, "Call to number function runs per ends on a null." I bet you, runs is a relationship on an eloquent object. So, it's like, "Oh my gosh, I know exactly what the problem is, I know how to fix it, and somebody else is going to go fix it." That level of knowledge versus the client just saying, "Hey the screen is white, what's going on?" It's exactly what you said, right? It's seeing that exception is a win. Because it means that, I'm terrified of the thing breaking and there's not an exception, that's the worst thing for me. Jonty Behr: Yeah. Again, just to contrast that with 10 years ago in CodeIgniter, something for having CodeIgniter in production, and you get a client saying, "I'm doing this, and it's just a white screen." There was no way that you could easily surface what that error was other than saying, "Hey, could you give me the steps that you did before that." And then you would log into the application and try to replicate the steps. Sometimes you'd even say, "Hey can we login in your account, could we masquerade and see if we can do it. It was difficult. I remember spending days on what would probably be a really simple fix with the tuning that we have nowadays. So, yeah, fun times. Matt Stauffer: We also, at Titan we run a software as a service that until maybe a month ago was CodeIgniter and Laravel. We originally wrote it in CodeIgniter, and I introduced the first Laravel components right before my first talk at Laracon EU, but I don't remember when that was. At least six years ago, I think. And we've been slowly transitioning it. One of the hardest parts we had was that we eventually got to the point recently where Laravel's running the whole thing, and there was just some CodeIgniter routes. Bugsnag was around the whole thing. Matt Stauffer: But when errors happen in the CodeIgniter world, they would still often... something would swallow the stack trace. That's a note that I want to have everybody listen to, what he just said. When exception happens, what that really means is that something exceptional happened, right? And exceptional means it was not intended to happen. When you have an exception happen in a small piece of code and then you've got to try catch, block above it, what that means is, well, it's not actually that exceptional, we kind of knew it was going to break. But when the exception makes it all the way up to the top of the application with nothing catching it, that means that we as programmers never expected this thing to happen. Matt Stauffer: And so, getting information about those things is wonderful because that means someone was able to trigger a state that you never expected to happen. And the system's going to tell you and you can... They're going to tell you where that state happened and where there was or wasn't a catch, or whatever. It wasn't a guard, or whatever it is. And then you just get to go fix it. It's magical. So, yeah. Jonty Behr: Absolutely. Matt Stauffer: When people are trying to get debugging, or monitoring, or logging, or observability set up, what do you think the biggest difficulties that people run into? Whether it's learning how to do it, learning how it works, or getting it set up. What is the thing that gets people stuck the most? Jonty Behr: Oh, that's a good question. I think with the tooling nowadays it's relatively easy to get set up for application exceptions. Because it's usually just a Composer install. So, Composer install Understand, or Composer install Bugsnag, whatever it is, which is relatively easy. I think if you're talking about server monitoring then you're moving on to a whole different aspect because you need to have some knowledge of command line, or Bash, to be able to set it into your server, and install an agent, and set it up. Maybe add some keys or API keys to it. I think DevOps as a whole requires a completely different skill set to application programming. Jonty Behr: If your day job in and out is writing programs, or developing in Laravel, or working with a database and writing queries, then I think the job of debugging that is going to be relatively okay and easy, and you'll learn to do it. But I think the job of debugging something going wrong with your server is a completely different ball game, and that's a whole other skill set which you have to learn over time. What happens when the server runs out of memory or runs out of disk space? What are the smells that you're going to get, and how you're going to surface that? Jonty Behr: Yes, you can install a server monitoring tool, and there are plenty of open source ones which work totally fine. You'll need to set it up and set up all the alerts, and all the rest of it. Again, it's just a time consuming thing. I think it really depends on whether you're talking about application or server monitoring. Because I think from an application monitoring point of view, just to go back to your original question, super easy to get up. And over time you'll learn how to debug. Server monitoring, more difficult to set up, and I think even more difficult to debug. Matt Stauffer: Yeah. Do you have a preferred stack that you use for server monitoring? Jonty Behr: This is a good question. We run two stacks at the moment, and all of our services filter into them. The one is just a simple... Not a simple, because it's not simple. But it's an ELK stack. For those who don't know, it's Elasticsearch Kibana, and basically you install an agent on each of your servers, and it feeds the metrics back into a centralized server that you'd run. And then you can set up alerts for each of the servers that you're monitoring. The second one that we use is called a TICK stack. I don't know if you're familiar with this Matt Stauffer: I've never heard of that before. Jonty Behr: ... but it's based on Influx. So, Influx DB is a time series database. It's open source, and they have a monitoring agent which you can install. They've got a alerting agent, and they've got a charting agent. And so, you set up the agents on all your separate servers. It works exactly like the ELK stack. Then you have a centralized server which is running Influx, and they all push data into the Influx database and you could then generate charts and graphs and alerts based on that. Matt Stauffer: Oh, cool. That's really nice. Jonty Behr: We've worked quite a bit with time series, which is how we came across Influx, and then we thought, "Hey, they've got a whole stack, it's 100% open source, let's give it a Bash." And it worked really nicely. I can't say I really prefer ELK over TICK stack. They both do the job relatively well. The charts look a bit different. They both give you the same kind of information. Jonty Behr: This brings me on to another point, which is we've been considering this whole side of Laravel for the last while, in terms of server monitoring. What options are there available for a Laravel specific product. Actually while there's nothing really specific to Laravel, yes, you can install, I think Skeleton's is a pretty good option. You can install ELK if you want, or TICK stack, or whatever. But we've been working on an option which is a Composer install, and a call monitor, 95% of your server and application metrics for you. Matt Stauffer: Really? Okay. Jonty Behr: There's very little overhead to it. We've done a lot of work on fine tuning the back end xDS. It still runs a PHP process, but you'll be able to push a lot of metrics into a system and have it report it for you automatically. That's something fun to look forward to. Matt Stauffer: Does it have a name that you can share yet, or no? Jonty Behr: It does have a name, but I'm going to keep it quiet for now. Matt Stauffer: All right. Jonty Behr: It's actually the first time that I've purchased a domain. Matt Stauffer: Was that the one that I had seen you had tweeted recently about? Jonty Behr: Like I said, purchasing a second hand domain. Yeah. Matt Stauffer: Very cool. Well, I'm super excited because I had no idea. Y'all, I invited him on because I thought he was the right person for this not because I knew that this was coming. But we at Titan have danced around with different options. We've been looking at some open source ones. We know about ELK stack. And just have been feeling like there should be an easier options for Laravel programmers. I'm very much looking forward to it, and we'll just kind of leave it there. And for those who are listening a couple of weeks or a couple of months after release, when it gets launched I'll do my best to remember to come back and add it to the show notes here. Matt Stauffer: But of course you can also follow Jonty or me, and we'll make sure that you know about it. We'll put all the notes about how to follow us on Twitter and everything like that at the end of the episode. But going back really quickly, you talked about server monitoring there. Let's talk about application monitoring again for a little bit. You talked about application monitoring in production. What do you think is the most difficult or likely to get people stuck aspect of learning or setting up a debugging process on local dev? Jonty Behr: What is the most difficult step in getting debug setup on your local host? Matt Stauffer: Either set up, or learning it, whichever. Just basically when somebody goes from, "I can't debug," to, "I can debug locally." What do you think is the most likely thing to trip them up? Jonty Behr: I think in terms of setting it up, it's very out the box, right? You set your debug to true in your .evn file, and it's there by default. I think in terms of getting it set up, it's really super simple these days. What is the hardest thing to learn out of that? I think probably some of the more esoteric things to come out of it is probably related to the database. Because most code things you can figure out and see where you've gone wrong. And either it trips you up at run time or if you're running it on test data, something will come out of it. But if it's something related to the database, I think that again, that's another skill set that you have to learn in conjunction with just doing programming and development. Maybe it's a foreign key that hasn't been set correctly or maybe a relationship hasn't been loaded correctly in Laravel. Jonty Behr: I think on some of the slack channels that I... For Quint, or on Stack Overflow I think probably the DB questions are the ones that seem to come up the most because it's usually quite specific to your project. Most application errors, in other words, ones that just happen in your code, most of the time they are not specific to your product. Somebody's seen it before 99 times out of 100. But with a database, you've got your own unique database structure, with your own relationships, with your own foreign keys, your own indices. And that's something specific to your project, you need to understand how it all fits together in order to debug that. Matt Stauffer: I think that's a great point. I do agree a lot. I think the number one thing that gets people stuck as they are learning how to do that is just trying to understand both the unique aspects of their application, and then also sometimes it helps a little bit to understand how your tools or your framework works. One of the things that I've often had to teach people is what it looks like to... Let's assume that if you're new, you're probably not new in using Vim. Let's assume you're new and you're using at least VS code or PhpStorm. You have the ability to click through to methods when you're calling things. Matt Stauffer: One of the first things I do is well, do that dump and die where you're finding your problem. Look at your stack trace, or whatever else it ends up being. The context you should get for free, whether based it on having set debug to true, which is what Jonty mentioned. Or doing a dump and die, a DD somewhere. Regardless, you should get a stack trace. If anybody's not familiar, stack trace is something that basically says, from the initial request and public/index.php, what did that call, then what did that call, and then what did that call. And from there, you're going to go through obviously a lot of middle ware, and a lot of Laravel application code eventually you're going to get to your code. Matt Stauffer: And so, figure out where in that stack did something do something other than what you wanted. Usually that's just enough. But if not you then go open your code or other files, and you click through and you often can command click or Ctrl click on a method name that you're calling, and then that takes you to where that method is defined. You can click through your call stack and figure out what's actually happening here. The timing of this is very interesting because just two days ago there was a big public drama around Xdebug where the founder of Xdebug said, "Anybody who doesn't use Xdebug is an armature." I just want to say it publicly, it's a very untrue statement. I've talked with him, and he has since recanted. What the note there was, Xdebug is this whole separate world that is very difficult to set up, but it brings all these things we're talking about us having to do a little bit more manually into a single environment where you actually can step through each of those aspects of the stack trace. Jonty Behr: Exactly. Matt Stauffer: I would say if you're just getting started, don't worry about Xdebug right now. Know it is a useful tool that is very difficult to set up right now, and we as a community are trying to get it to be easier to set up over the next months. Right now, don't worry about it. Know that it's great, but right just get that stack trace somehow. If you can see a stack trace, good. And if you got an error without a stack trace in your local development then you should change your local development environment. First thing being, go to you .env file and set app_debug to true, right? Jonty Behr: Yeah. Again, I think in the early days when I was using CodeIgniter and there wasn't a great exception tracker, I think the use of Xdebug, I found super helpful at that point in time. Yes, I remember spending hours and hours, maybe days on getting it set up. I think I was using NetBeans at that time if anybody even remembers that far back. Matt Stauffer: Yeah. Jonty Behr: I think you made a very good point. If you're just getting started in programming now, don't bother with getting Xdebug set up to start off with. It's something that you can add to your tool set later, but for most cases just using the exception that's thrown in Laravel is totally fine. Matt Stauffer: Yeah. I agree. Obviously, I could talk to you for hours, but we're already 40 minutes in. Or at least 40 minutes into my recording. What else have we not covered? If you were trying to work with somebody who's just getting started programming right now, what should they know or learn, or what do you want to trigger them to go think about to really have a good handle on debugging and monitoring both in the application server space, such that it's just going to get them to the next step. Maybe not 100% there. What's the next step for everybody? Jonty Behr: Yeah. I think there's probably two things to mention here is one, an exception on error is not something to be avoided, it's something to be welcomed because it's a learning opportunity. Every single time your application throws an exception, that's an opportunity for you to learn, one, how to do it better the next time around, and two, how to actually fix it if something similar happens in the future. Don't be afraid of exceptions. I think the second thing, and a lot of credit must go to Taylor in the early days is the Laravel community as a whole is very welcoming generally. There's some great Slack channels. In the early days it was IRC. I remember being on that IRC channel in the early days. Jonty Behr: There's some great Slack channels where very helpful people. They will help you find out what the issue is, help you debug it. There's one in the... It's kind of a UK specific one, UK Laravel Slack chat. But anybody from around the world is welcome to join. There's a help needed channel. If somebody posts a question, there will be 10 people offering you their help on how to fix it. Again, that's just a learning opportunity. It's always great to learn from people that have been down that road before, and can maybe elucidate and explain a little bit more on the topic. Matt Stauffer: The Laravel Slack actually officially moved to Laravel Discord now. Jonty Behr: Oh, all right. Matt Stauffer: In the show notes I'll link out the Laravel Discord, and then the Laravel UK Slack channel as well if anybody wants to join those. Google and Stack Overflow, they're good tools in a developer's arsenal as well. Between all of those, there's a lot we have available too, to help us understand what's going. I would say that the biggest goal for someone learning about debugging is moving from seeing an error and not understanding it and Googling that error or ask other people what that error means, and going to the point where they see an error and they can understand what it means. Because if you understand what the error means, then you have so much more capacity to be able to figure out, where is it coming from, why is it happening, and how do I fix it? Without having to look for somebody. Matt Stauffer: And sometimes errors are esoteric. They say something that doesn't make sense, and learning just means realizing that, that thing that makes sense, the last time it happened it meant this thing. In some ways you can't get smart enough to know what every error means. It's just that's what this particular system throws when that other thing happens. No human could ever parse it. But many of the types of errors we run into every day, you can infer what's going on just by learning a little bit about the systems that are throwing the error. Jonty Behr: Yeah. It's weird because it's almost exactly the same as learning a new language. In that, when you learn a new language and somebody says a word that you don't understand, you literally don't understand what it means, and you need to go off and find out, what does that mean? Or look in a dictionary, or look it up on the internet. It's the exact same thing when you're starting programming and an exception happens, what does this mean? I don't know, and you need to go off and research. But the next time you hear that word in a foreign language, it may take you a few seconds to remember it, and the time after that it will take you three seconds, and the time after that you'll know instantly. It's the exact same thing with trying to debug your application in that, each time you encounter it, it will become more and more familiar until you understand exactly what it means straight away when it happens. Matt Stauffer: Yeah. Absolutely. I love that. Since we're wrapping up, are there any learning resources that you would turn people to? Are there blog posts, or articles, video series, where you think this is actually doing a great job of teaching people how to do application monitoring, or debugging, or server monitoring, or anything like that? Jonty Behr: There aren't any off the top of my head, but I think the usual suspects in the community offer a lot of good advice just about learning more in general. There aren't any specific blog posts or articles that I know specifically handling monitoring, and how to find it out. Matt Stauffer: I'll add one really quickly. I actually don't know anybody who's teaching about monitoring and debugging either. But I do know that in terms of observability, which is a little bit of like the 2.0 version of this conversation, Charity Majors is really well known for teaching a lot about observability. She runs a company called Honeycomb, but she's also done a podcast about the basics of observability, and I will link those in the show notes. Matt Stauffer: There are good learning resources for observability. But I'm with you I can't actually say who teaches you how to debug and who teaches you how to monitor. In some ways, because teaching you how to monitor is just saying go install X tool, and use it. Teaching how to debug, I really agree with you. I think a lot of learning about debugging is just doing it, seeing the errors, making sure you have your debug enabled, and Laravel is really going to set you up pretty well to have everything you need to just go do it, and once you go do it, that's how you learn. Jonty Behr: Yep. Matt Stauffer: I think it's a great point. All right. Last thing is a personal fun moment. I'm going to make a jump that could be entirely wrong. So, I hope I'm not entirely wrong. But I know both from our personal history of conversations, and from your accent, that you're not originally from the UK. And so, because I know that you're South African, I want to ask, are you a rugby fan? Jonty Behr: Well, there aren't many South Africans that aren't rugby fans. That is slightly rhetorical. Matt Stauffer: Before I assumed, I wanted to make sure. I know basically nothing about rugby, other than you've got this big thick ball, and it's this weird... It's not weird. It's this aggressive combination of soccer, American soccer, so football, and then American football, in my perception as an American. Can you tell me... Either give me the real quick rundown of how rugby works, or tell me what you like the most about rugby, just inform me as an ignorant American. Tell me something about rugby. Jonty Behr: Okay. A rugby team is made up of 15 players. Typically, they'll stay on for the whole match, although you are allowed, I think up to five substitutions throughout the whole match. Matt Stauffer: Okay. Jonty Behr: Okay. The team is split generally into two different sections. One is called the forwards and one is called the backs. The forwards tend to be bigger, taller, stronger, and they will more often fight over... I'm using the word fight, but it's not really a fight. They will often tussle over the ball. The backs are generally faster, and quicker. Matt Stauffer: Oh, got it. Jonty Behr: You can only pass the ball backwards in rugby, but you can kick it forwards. Matt Stauffer: You can kick it forwards but you can throw it forwards? Jonty Behr: You can't throw it forwards, correct. Matt Stauffer: Oh, interesting. Jonty Behr: Every time you pass to another player... Pass, in American accent. It has to go backwards. Matt Stauffer: Interesting. Jonty Behr: The only time play stops is if the ball goes out of bounds or if there's an infringement of some form. Play can continue for five minutes non stop as long as the ball doesn't go out, or there's no infringement. There are three ways to score points. The first way is to run over the end goal area, which is called the try line, and touch the ball down on the ground in which case you get five points. Matt Stauffer: Okay. Jonty Behr: Once you've done that, you get a free kick in between the posts, and it's in line with where you touch the ball at the try line. Matt Stauffer: Oh, interesting. Jonty Behr: And that is worth two points. If the other team infringes, you get a penalty. You're allowed to kick for posts if you want. In other words, try kick it between the posts. Matt Stauffer: From where the penalty was though? Jonty Behr: And that is worth three points, and that's the game of rugby. Matt Stauffer: I love it. So, I have... Jonty Behr: So, I actually- Matt Stauffer: Go ahead. Jonty Behr: Sorry. When I went to school in South Africa, in my school it was compulsory for every year eight and nine boy to play rugby unless you had a medical exemption. It was completely compulsory. We had in our year group, I think seven or eight teams of 15 players in each team, and then there were six years. So it was a huge cultural thing in South Africa to play rugby, huge cultural thing. Matt Stauffer: I've never heard of compulsory sports in my life, that's fascinating. I've got two more questions for you. Number one, my mental image of rugby is... I don't know if I would use the word violent, but I would think of more tussling is the word you used. More physical bumping, grabbing, pushing, shoving is allowed in rugby than in other sports that are similar like football and American football. Is that right? Jonty Behr: Yeah. I heard somebody describe rugby not as a contact sport, but as a collision sport, which probably is quite accurate. I think the collisions in American football are probably harder, but you've got helmets and body armor. Matt Stauffer: Yeah, helmets and pads. Jonty Behr: Whereas there's nothing in rugby. Honestly, I do not understand how these guys get through a match every single time... Not every single time, but without being more badly injured. The average rugby player is probably 110 kilograms, which is 250 pounds, six foot two. Some of the forwards will be even bigger than that, they'll be maybe 300 pounds, six foot seven, six foot nine. Matt Stauffer: Wow. Jonty Behr: And so, you have these guys running at full tilt and literally crashing into each other and getting up and then carrying on. I do not understand. It is insane. As far as a spectator sport goes, if you understand the rules, I haven't found a game that is a better game to watch. Matt Stauffer: I love it. That's a perfect segue to my next question which is, who is the best team? Jonty Behr: Well, thank you for asking because currently the Springboks are the world champions. The Springboks is the South African national team. There's a World Cup every four year. The last World Cup was last year, and the South Africans won. And so, they'll have every major rugby playing nation in the world at every Rugby World Cup. I'm sure I'll get a little bit of stick from my Kiwi, which is New Zealand friends. Because typically New Zealand is the strongest team, and they were kind of a shoe horn to win this Rugby World Cup for the third time running, or something. But it didn't happen for them this time around. Anyway... Matt Stauffer: I definitely asked it that way on purpose because I know that each person's going to answer it differently, so I totally understand. I was actually also going to ask, what are the big countries that do it, but I think you probably don't have time to sit and list all of them. But I did know that New Zealand and South Africa are the two biggest ones that I know of. Jonty Behr: Yeah. I think that probably the two other big ones are England and Australia, and then Whales, France, Ireland, are probably on the next tier. Something like that. Matt Stauffer: Very cool. Some of my neighbors are South African, so at very strange hours of the day you'll just hear them screaming. Jonty Behr: Yeah. Matt Stauffer: Because they're watching it live through some kind of satellite hook up or something. So, very cool. All right. Jonty Behr: No, sorry, go on. Matt Stauffer: That was it for today. What we're going to do is, I want to give you a chance to know how people can follow you, give you money, whatever else. I'll make sure I put all of this in the show notes. Where should they follow you? What are your products? What does it look like to work with you? All that kind of stuff. Jonty Behr: Okay. My Twitter handle is Jonty Behr B-E-H-R. I don't tweet that much, but I'm always there or there about. The company which I run is Mettle, that is M-E-T-T-L-E.io. Our main SaaS product in the Laravel sphere is Understand.io, which is as Matt said, an exception log tracking tool. We recently launched a open source email newsletter tool, which is 100% open source and free. That's available on GitHub, and that is available at SendPortal.io. As I mentioned, we've got another tool coming out very shortly, which will help on the application metrics side. Matt Stauffer: Love it. I can't wait to see that. I'm going to be your first user. Well, Jonty, thank you so much for your time. Thank you for providing all the packages and the organization and the tooling that you do to Laravel world, and yeah, just thanks for hanging out with me today. Jonty Behr: Thanks very much for having me on. I really enjoyed it. Matt Stauffer: All right, see y'all next time.