WEBVTT 1 00:00:06.679 --> 00:00:09.039 Welcome to another episode of React Round Up. My name 2 00:00:09.080 --> 00:00:11.839 is TJ. Bentol, and I'm flying solo here on the 3 00:00:11.839 --> 00:00:14.119 panel today, but that is all right because I have 4 00:00:14.279 --> 00:00:16.640 James Smith with me today. James, why don't you go 5 00:00:16.679 --> 00:00:19.480 ahead and introduce yourself? Tell everybody a bit of why 6 00:00:19.480 --> 00:00:20.120 you're famous. 7 00:00:20.960 --> 00:00:21.480 Thanks DJ. 8 00:00:21.800 --> 00:00:25.079 Yeah, I'm James Smith. I the CEO and co founder 9 00:00:25.120 --> 00:00:29.800 of a company called Bugsnack and Bugsnack detect when software breaks. 10 00:00:30.120 --> 00:00:32.759 But prior to running a company and being a founder, 11 00:00:33.240 --> 00:00:37.679 I built software in the web or mobile applications in 12 00:00:37.759 --> 00:00:40.079 various industries for quite a while. I like to think 13 00:00:40.119 --> 00:00:43.359 of myself these days as a retired software engineer and just. 14 00:00:43.399 --> 00:00:46.840 Enough to be dangerous awesome. So bug managing software. So 15 00:00:46.880 --> 00:00:48.840 I'm going to start with like the like a softball, 16 00:00:48.840 --> 00:00:51.359 an easy question, but like why do you why do 17 00:00:51.439 --> 00:00:54.079 developers need bug managing software? Like why isn't it enough 18 00:00:54.119 --> 00:00:55.880 to just throw it out there and rely on like 19 00:00:56.159 --> 00:00:58.479 you know, user reports and QA and that sort of 20 00:00:58.520 --> 00:00:59.600 stuff to find these bugs. 21 00:01:00.079 --> 00:01:02.960 Were a surprising number of companies that we work with 22 00:01:03.399 --> 00:01:06.519 still do that, and they're coming to us to rehabilitate. 23 00:01:06.920 --> 00:01:10.640 But I think that modern software development has changed hugely. 24 00:01:10.719 --> 00:01:13.680 I joke a lot about how you know, twenty five 25 00:01:13.840 --> 00:01:17.040 thirty years ago, when you develop delivered software, you printed 26 00:01:17.079 --> 00:01:19.159 it onto a CD or floppy discs and that software 27 00:01:19.280 --> 00:01:23.480 was done. And these days most software is running in 28 00:01:23.519 --> 00:01:26.280 an environment where it can be updated and fixed and patched. 29 00:01:26.719 --> 00:01:29.840 And also I think that people adopted more principles like 30 00:01:29.879 --> 00:01:32.879 agile and lean, where sometimes you're going to build something 31 00:01:32.879 --> 00:01:35.680 that's not ready intentionally and you're going to say, look, 32 00:01:35.719 --> 00:01:37.920 we're going to release this to customers early because we 33 00:01:37.959 --> 00:01:40.040 don't even know if customers are going to like this yet. 34 00:01:40.560 --> 00:01:44.000 And so the concept of keeping and working on something 35 00:01:44.120 --> 00:01:46.719 after its shipped to the customers is now the default 36 00:01:46.760 --> 00:01:50.480 in most companies. In most cases, so you can't have 37 00:01:50.599 --> 00:01:53.840 this like perfect five month QA process, print it to 38 00:01:53.879 --> 00:01:56.799 gold Master and CD and shipping out to Best Buy. 39 00:01:57.079 --> 00:01:57.879 When it's done. 40 00:01:58.120 --> 00:02:01.000 You now have this living, breathing piece of so I 41 00:02:01.040 --> 00:02:04.239 think that's the main thing that's caused this evolution. I 42 00:02:04.280 --> 00:02:07.480 think that most people have now taken to squishing down 43 00:02:07.519 --> 00:02:10.439 that QA period and replacing it from both the left 44 00:02:10.439 --> 00:02:13.439 hand side and the right hand side. Probably almost everyone 45 00:02:13.479 --> 00:02:16.280 from the left hand side is adding in really nice 46 00:02:16.439 --> 00:02:21.319 automated testing, unit testing, integration testing, linting, and things like that. 47 00:02:21.360 --> 00:02:23.719 And from the right hand side, QA is getting pushed 48 00:02:23.719 --> 00:02:27.159 down by production awareness and production monitoring, where things like 49 00:02:27.199 --> 00:02:29.400 folks like error monitoring products are are key there. 50 00:02:29.639 --> 00:02:32.719 Yeah, it's interesting stuff, and I think maybe the next 51 00:02:32.719 --> 00:02:34.879 thing could you just paint me a picture of Like 52 00:02:34.960 --> 00:02:38.080 when you talk about like bug managoring or being reporting software, like, 53 00:02:38.120 --> 00:02:39.159 what does that actually look like? 54 00:02:39.159 --> 00:02:39.280 Like? 55 00:02:39.400 --> 00:02:41.759 So suppose I'm working at a big company, I've got 56 00:02:41.800 --> 00:02:44.360 a giant React app. Maybe I've also got to React 57 00:02:44.439 --> 00:02:46.919 like mobile app. What is my steps? Like, what is 58 00:02:46.919 --> 00:02:49.240 my experience actually like? Like how do I install this? 59 00:02:49.479 --> 00:02:51.479 And then what sort of thing am I looking at 60 00:02:51.560 --> 00:02:53.319 like once the deployer sab out to production. 61 00:02:53.680 --> 00:02:55.520 Yes, it depends on the type of software you're running. 62 00:02:55.560 --> 00:02:58.439 But yeah, in a React application or a web app stack, 63 00:02:58.520 --> 00:03:02.280 for example, you want to be able to monitor run 64 00:03:02.319 --> 00:03:06.120 time errors and bugs that are affecting your your end users, 65 00:03:06.159 --> 00:03:09.039 your customers out in the wild. And in order to 66 00:03:09.080 --> 00:03:11.319 do that, the way that our product works is we 67 00:03:11.360 --> 00:03:14.919 have SDKs or libraries that you install your package manager, 68 00:03:15.000 --> 00:03:17.879 so actually our software runs as part of your code, 69 00:03:18.000 --> 00:03:20.520 is linked in as part of your code, rather than 70 00:03:20.520 --> 00:03:22.599 being something that ingestslog. 71 00:03:21.960 --> 00:03:23.120 Files or anything like that. 72 00:03:23.280 --> 00:03:25.680 And so yeah, you're writing and React at you can 73 00:03:25.759 --> 00:03:28.599 just NPN or yarn install bugsnack. If you've got a 74 00:03:28.879 --> 00:03:31.960 Rails API powering your back end, you added to your 75 00:03:32.080 --> 00:03:33.520 gem file and do buddle install. 76 00:03:33.800 --> 00:03:35.520 And the same is true of pretty much every single 77 00:03:35.560 --> 00:03:36.520 platform that we run in. 78 00:03:36.759 --> 00:03:39.840 So once you've installed that SDK, you set an apike 79 00:03:40.240 --> 00:03:43.639 in code or configuration spending on the platform, and then 80 00:03:43.879 --> 00:03:47.039 bugs basically sits in the background, taking up almost zero 81 00:03:47.199 --> 00:03:50.199 resources until we detect a problem. As a curtain a 82 00:03:50.280 --> 00:03:53.759 problem differs on each platform, and then React app for example, 83 00:03:54.280 --> 00:03:57.240 we will detect any exception that bundles up to the 84 00:03:57.280 --> 00:04:00.840 window error handler on the browser, we will detect any 85 00:04:01.000 --> 00:04:05.199 on handled promise rejections, and then React specifically. We'll look 86 00:04:05.199 --> 00:04:08.520 into React error boundaries as well. So you could use 87 00:04:08.520 --> 00:04:11.639 any bugstag provided error boundary and wrap your parts of 88 00:04:11.719 --> 00:04:14.360 your code base in a bugsnag wrapper and will then 89 00:04:14.400 --> 00:04:18.240 automatically report them off to bugsnags dot com and send 90 00:04:18.240 --> 00:04:21.120 diagnostics alongside with it. But the process is pretty similar 91 00:04:21.120 --> 00:04:24.240 on every platform mobile, desktop, web browser, just with slight 92 00:04:24.279 --> 00:04:26.040 differences of the types of the era that we catch. 93 00:04:26.160 --> 00:04:28.600 Yeah, it's interesting. I know we were talking before that. 94 00:04:28.800 --> 00:04:31.360 The last time I use some sort of air reporting 95 00:04:31.519 --> 00:04:34.600 software was quite a few years ago, and I remember 96 00:04:34.639 --> 00:04:37.399 the first time I did it, I was absolutely astonished 97 00:04:37.439 --> 00:04:40.480 at what it was spitting out. Because you have this 98 00:04:40.639 --> 00:04:42.560 like I think when you work on a big piece 99 00:04:42.600 --> 00:04:45.079 of software, like you know there are some bugs out there, right, 100 00:04:45.120 --> 00:04:46.959 like you've got some gear tickets that have been opened 101 00:04:47.000 --> 00:04:48.879 for a while. You're like, yeah, yeah, yeah, we'll get 102 00:04:48.920 --> 00:04:50.439 to that. That's sort of a hard problem to solve. 103 00:04:50.600 --> 00:04:52.879 But I remember actually putting this stuff in and like 104 00:04:53.120 --> 00:04:56.839 you get stuff that like you had absolutely no clue 105 00:04:57.399 --> 00:05:00.000 what it meant. And I guess one thing. I'm curious 106 00:05:00.120 --> 00:05:02.399 because actually my one problem with using is and this 107 00:05:02.519 --> 00:05:04.839 was years ago when these things were probably a lot 108 00:05:04.920 --> 00:05:07.319 less refined, but it got hard to like make sense 109 00:05:07.360 --> 00:05:10.120 of all the ears because it almost became like there 110 00:05:10.240 --> 00:05:13.759 was just this like a huge mess of airs. So 111 00:05:13.759 --> 00:05:15.560 I'm curious like the sort of things you do. I 112 00:05:15.560 --> 00:05:19.399 imagine you have like some sort of like aggregation algorithms 113 00:05:19.399 --> 00:05:21.040 that tries to make sense of like well, okay, well 114 00:05:21.079 --> 00:05:23.000 these bugs are all the same, or like do you 115 00:05:23.240 --> 00:05:25.519 help try to help developers like get at like the 116 00:05:25.600 --> 00:05:27.920 root cause like maybe this is like browser specific or 117 00:05:27.920 --> 00:05:28.600 that sort of thing. 118 00:05:28.920 --> 00:05:32.519 Yeah, it's funny when I remember as been chucking out 119 00:05:32.519 --> 00:05:35.560 log files for ages, and a lot of the time 120 00:05:35.600 --> 00:05:37.680 you don't think actively to look at log files and 121 00:05:37.720 --> 00:05:39.480 you just go in there when you absolutely have to, 122 00:05:40.120 --> 00:05:42.959 and they're generating gigabytes and gigabytes of data that maybe 123 00:05:42.959 --> 00:05:43.759 you never look at. 124 00:05:44.079 --> 00:05:47.279 And then there was this leap from reactive. 125 00:05:46.920 --> 00:05:49.560 Error monitoring to productive aeroor monitoring, and there was really 126 00:05:49.560 --> 00:05:51.639 early players in the space. There was a product called 127 00:05:51.639 --> 00:05:55.040 hop toad, which rebranded to something else, which was super 128 00:05:55.079 --> 00:05:57.120 early in the rail space, and people were like, wow, 129 00:05:57.160 --> 00:05:58.959 this is really cool, but holy moly, do I have 130 00:05:59.000 --> 00:06:00.879 a lot of stuff coming in. And I think the 131 00:06:01.000 --> 00:06:04.439 leap that products like hotted initially made and then we've 132 00:06:04.639 --> 00:06:08.120 kind of refined over the years is aggregation number one. 133 00:06:08.160 --> 00:06:11.160 As you say, first off, can we say that, Look, 134 00:06:11.240 --> 00:06:14.680 we've had ten thousand bugs, ten thousand exceptions or crashes, 135 00:06:15.000 --> 00:06:17.480 but actually all of these ten thousand exceptions or crashes 136 00:06:17.480 --> 00:06:19.600 came from the exact same bug, the underlying the same 137 00:06:19.639 --> 00:06:23.680 line of code, and so at the most basic level. 138 00:06:23.680 --> 00:06:24.920 We have these grouping algorithms. 139 00:06:24.959 --> 00:06:27.839 We've born on grouping agorithms that look at the line 140 00:06:27.879 --> 00:06:31.120 of code where the bug originated, and it differs depending 141 00:06:31.120 --> 00:06:34.399 on the platform. We can be a lot more sophisticated 142 00:06:34.399 --> 00:06:36.639 in some areas where we'll look at how similar the 143 00:06:36.680 --> 00:06:38.639 code is, will take a snapshot of like seven lines 144 00:06:38.680 --> 00:06:40.519 before and after where the crash happened and look at 145 00:06:40.720 --> 00:06:43.759 code similarity heuristics, and in other platforms we keep it 146 00:06:43.839 --> 00:06:45.600 very simple. We don't have to do that level of 147 00:06:45.600 --> 00:06:48.839 complexity where we'll say this was this type of exception, 148 00:06:48.959 --> 00:06:53.920 so runtime error on line fifty nine of user dot Java, 149 00:06:54.120 --> 00:06:55.959 and that's enough for us to say with pretty high 150 00:06:56.000 --> 00:06:59.079 confidence that this is a unique bug to this version 151 00:06:59.079 --> 00:07:01.879 for example. Yeah, that getting that aggregation and grouping in 152 00:07:01.920 --> 00:07:06.079 place is the step one. But even then, you said earlier, 153 00:07:06.120 --> 00:07:09.000 how do people move from customer reports and customer feedback 154 00:07:09.040 --> 00:07:12.000 to having a proactive system like this? Well, not all 155 00:07:12.040 --> 00:07:13.720 bugs that we have a T shirt with this, and 156 00:07:13.800 --> 00:07:16.079 not all bugs are created equal. And if you just 157 00:07:16.120 --> 00:07:19.000 went through this list and said I'm going to fix 158 00:07:19.040 --> 00:07:21.920 every single bug that my bugsnog tool is reporting to me, 159 00:07:22.519 --> 00:07:25.040 then you're going to waste your life away. You're going 160 00:07:25.040 --> 00:07:26.959 to be spending time on stuff that really doesn't matter, 161 00:07:27.360 --> 00:07:29.360 especially in the clients side, especially when it comes to 162 00:07:29.439 --> 00:07:32.240 JavaScript and React applications, because it's the wild West. You've 163 00:07:32.279 --> 00:07:35.639 got browsers all over the different places, You've got Chrome 164 00:07:35.720 --> 00:07:39.120 extensions that causing problems and injecting content into the dom. 165 00:07:39.639 --> 00:07:42.480 And so the next layer on top of that aggregation 166 00:07:43.079 --> 00:07:47.240 is then sophisticated prioritization tool, so figuring out things like, well, 167 00:07:47.279 --> 00:07:50.360 which one affected the most customers, which one affected customers 168 00:07:50.399 --> 00:07:52.319 that are paying us the most money if you're going 169 00:07:52.399 --> 00:07:54.600 to keep it straightforward, or which one affected customers that 170 00:07:54.600 --> 00:07:56.680 are in key states or key flows like a log 171 00:07:56.720 --> 00:07:59.199 in or sign up flow for example. And so we 172 00:07:59.319 --> 00:08:01.800 try to capture as much information as we can at 173 00:08:01.839 --> 00:08:04.839 run time and then allow you to create filters, bookmarks 174 00:08:05.000 --> 00:08:07.360 and prioritization rules inside of bugsname. 175 00:08:07.759 --> 00:08:09.959 It's funny, I didn't even really think about that, but 176 00:08:10.360 --> 00:08:13.720 you're right, because someone could be just using some garbage 177 00:08:13.800 --> 00:08:16.519 Chrome extension, or like maybe they're even like developing their 178 00:08:16.519 --> 00:08:19.399 own Chrome extension. That's just like, you know, totally screwing 179 00:08:19.519 --> 00:08:21.800 things up. And if you try to debug that, my god, 180 00:08:21.879 --> 00:08:25.360 like you s going to be spending days and weeks. 181 00:08:25.600 --> 00:08:29.199 Can you even know, like, for example, anyway you can 182 00:08:29.240 --> 00:08:31.600 tell how bad it affected the user? Right? Like is 183 00:08:31.639 --> 00:08:33.919 this like is there a way of knowing like this 184 00:08:34.000 --> 00:08:35.879 is just an error, but it didn't actually affect the 185 00:08:35.960 --> 00:08:39.039 user experience versus like this is actually I don't know, 186 00:08:39.120 --> 00:08:41.240 like forcing the UI to be unresponsive or maybe even 187 00:08:41.279 --> 00:08:43.360 like crashing the tab or something. Is there are ways 188 00:08:43.360 --> 00:08:46.200 that you can even tell on that level of detail, Yeah. 189 00:08:46.240 --> 00:08:49.120 It's the most The simplest way to do that is 190 00:08:49.159 --> 00:08:51.440 to look at what we call the error handler, And 191 00:08:51.480 --> 00:08:53.200 so I kind of mentioned this. We use jobscripts as 192 00:08:53.240 --> 00:08:56.360 an example, or React as an example here. There's various 193 00:08:56.360 --> 00:08:58.600 ways that we automatically detect that a bug has happen, 194 00:08:59.240 --> 00:09:02.720 and some of them, for example, we wrap event handlers, 195 00:09:02.759 --> 00:09:04.679 so we wrap the callbacks to the event handlers. So 196 00:09:05.080 --> 00:09:07.200 if an exception happens in an event handler, and that 197 00:09:07.240 --> 00:09:10.120 doesn't necessarily always bubble up to your window dot on error, 198 00:09:10.360 --> 00:09:12.840 it might just mean that your click failed to do 199 00:09:12.919 --> 00:09:15.240 what you expected your click to do because the callback 200 00:09:15.320 --> 00:09:19.679 crashed halfway through. That is almost always less bad than 201 00:09:19.960 --> 00:09:22.320 a bug that bubbles up. Still bad, it's less bad 202 00:09:22.360 --> 00:09:23.919 than a bugue that bubbles all the way up to 203 00:09:24.000 --> 00:09:27.039 window on error, which basically means no JavaScript is executing 204 00:09:27.080 --> 00:09:29.919 in their scriptag anymore, and especially because most people are 205 00:09:30.000 --> 00:09:32.440 using bundlers these days and bundling all their jobs script 206 00:09:32.519 --> 00:09:36.399 up into applications on to JS. If your JavaScript stops 207 00:09:36.399 --> 00:09:38.320 executing in that scriptag, you're boned. 208 00:09:38.399 --> 00:09:38.759 That's it. 209 00:09:39.240 --> 00:09:42.000 The whole page stops responding. There's other things as well, 210 00:09:42.039 --> 00:09:45.600 like a promise rejection handler. Again, if it's in a 211 00:09:45.639 --> 00:09:48.200 promise it happened a synchronously, it's probably not the. 212 00:09:48.240 --> 00:09:48.919 End of the world. 213 00:09:49.279 --> 00:09:51.360 So that's the most straightforward way to look at it, 214 00:09:51.399 --> 00:09:52.919 and to say, look, if it was a click event, 215 00:09:53.279 --> 00:09:55.080 that's bad, but not as bad as if the entire 216 00:09:55.120 --> 00:09:57.879 page locked up. In terms of the performance aspects, though 217 00:09:58.000 --> 00:10:00.879 they're a lot more subtle. We have a all code 218 00:10:00.879 --> 00:10:04.759 snippets to detect certain things like freezes, and my favorite 219 00:10:04.759 --> 00:10:10.080 one is our frustration detection snippet, so it detects rage clicks. 220 00:10:10.360 --> 00:10:13.360 So if you, i said earlier, if you've got code that. 221 00:10:13.320 --> 00:10:17.200 Made a non click handler fail, fine, but how can 222 00:10:17.240 --> 00:10:20.120 you detect if your developers forgot to hook up on 223 00:10:20.200 --> 00:10:22.519 click at all to a button? So you've just got 224 00:10:22.559 --> 00:10:24.919 a button that looks like it's clickable, but there's literally nothing. 225 00:10:25.360 --> 00:10:27.200 And so we've got some snippets so you can drop 226 00:10:27.279 --> 00:10:29.480 in that will detect things like when you click on 227 00:10:29.519 --> 00:10:32.720 the same domb element multiple times within a particular time window, 228 00:10:33.000 --> 00:10:35.320 and then it will send a message to bugsnack saying 229 00:10:35.360 --> 00:10:36.799 someone's rage clicking this button. 230 00:10:37.039 --> 00:10:37.840 And so things like. 231 00:10:37.799 --> 00:10:41.759 That are still as frustrating, maybe more frustrating than a 232 00:10:41.879 --> 00:10:44.279 full page freeze, but it's kind of up to the 233 00:10:44.320 --> 00:10:46.799 developer to decide, Yeah, this is the one that's that's 234 00:10:46.840 --> 00:10:48.039 causing customers the most pain. 235 00:10:48.559 --> 00:10:51.039 Yeah, because you said snippet, so is your model. They're 236 00:10:51.080 --> 00:10:54.120 basically there's some default handling and then there's extra things 237 00:10:54.120 --> 00:10:55.840 you can add on that you may not want to 238 00:10:55.840 --> 00:10:58.679 give everybody because they were I'm assuming it works attended 239 00:10:58.759 --> 00:11:01.679 to the vent handler, so there's like some small performance here, 240 00:11:01.720 --> 00:11:03.399 so you might now want to go nuts with it 241 00:11:03.480 --> 00:11:03.960 sort of thing. 242 00:11:04.360 --> 00:11:05.440 Yeah, it's more. 243 00:11:05.720 --> 00:11:09.039 It's more that we have an opinion that our product 244 00:11:09.159 --> 00:11:13.039 is opinionated yet extensible, and so pretty much all of 245 00:11:13.080 --> 00:11:16.440 our SDKs are plug in based, I mean our JavaScript one. 246 00:11:16.600 --> 00:11:19.080 We just released a new version of this two days ago. 247 00:11:19.639 --> 00:11:22.799 The whole thing's built around plugins, even internally, so things 248 00:11:22.840 --> 00:11:26.600 start off as snippets sometimes and then graduate into official 249 00:11:26.600 --> 00:11:29.240 plugins that we put as default inside of the application. 250 00:11:29.559 --> 00:11:30.960 Some of them, like the rage click. 251 00:11:30.759 --> 00:11:35.440 One, they're more interesting than actionable in a lot of cases, 252 00:11:35.519 --> 00:11:37.559 and so if we ever evolve that to be one 253 00:11:37.600 --> 00:11:39.879 of these ones where it's like we are confident that 254 00:11:39.960 --> 00:11:42.000 something is going wrong based on these rage clicks, then 255 00:11:42.000 --> 00:11:43.840 we'll put it as a default plug in inside of 256 00:11:43.879 --> 00:11:47.039 our JavaScript SDK. But actually it's one of those things 257 00:11:47.039 --> 00:11:49.200 that people want to tune. How many clicks is a 258 00:11:49.320 --> 00:11:51.519 rage click? What time period should I measure? And all 259 00:11:51.519 --> 00:11:54.080 that kind of stuff. So the stuff that's on by default, 260 00:11:54.120 --> 00:11:56.600 the opinion of this stuff is what we think are 261 00:11:56.679 --> 00:12:00.919 the most important negative signals inside of your Apple cation typically. 262 00:12:01.159 --> 00:12:03.440 But yeah, it's all plug in base, and we try 263 00:12:03.480 --> 00:12:07.159 to expose as much as possible in terms of API 264 00:12:07.279 --> 00:12:08.960 so that you can hook in your own plugins and 265 00:12:09.000 --> 00:12:11.080 do your own stuff. Like even I said earlier about 266 00:12:11.279 --> 00:12:15.720 reporting handled versus unhandled exceptions, sometimes you've got your try 267 00:12:15.759 --> 00:12:18.279 catch and my favorite piece of code to read ever 268 00:12:18.559 --> 00:12:21.919 is when it says try catch, and all there is 269 00:12:21.919 --> 00:12:23.759 in the catch is a comment that so should never 270 00:12:23.799 --> 00:12:27.120 get here, and inevitably it's going to get there. 271 00:12:27.480 --> 00:12:29.320 So a lot of our customers do. 272 00:12:29.399 --> 00:12:31.519 Most of our customers do is they'll put a bugsnag, dot, 273 00:12:31.519 --> 00:12:35.279 notified brackets, E error, whatever it is, and so that 274 00:12:35.399 --> 00:12:37.240 way you know if it's got there, and then you 275 00:12:37.240 --> 00:12:39.480 can decide if that's a problem or not. But yeah, 276 00:12:39.519 --> 00:12:42.519 we try to be opinionated the accentsible as our produp philosophy. 277 00:12:42.639 --> 00:12:44.720 I kind of like that for the catch black because 278 00:12:44.879 --> 00:12:47.080 I've totally been that person that you go into the 279 00:12:47.120 --> 00:12:48.919 catch and you think to yourself, like, I don't even 280 00:12:49.000 --> 00:12:51.039 know how in the world this would happen, but like 281 00:12:51.120 --> 00:12:52.919 I feel like I can't just leave this empty, right, 282 00:12:52.960 --> 00:12:54.440 so I have to put something and it. 283 00:12:54.440 --> 00:12:55.679 Will it will happen. 284 00:12:57.720 --> 00:12:59.759 The ones that crack me up all the time, I 285 00:12:59.759 --> 00:13:01.960 think this is because I'm getting across the old program 286 00:13:01.960 --> 00:13:04.559 and now, but try catch blocks where the catch block 287 00:13:04.799 --> 00:13:07.039 has just a comment and nothing else in it, and 288 00:13:07.080 --> 00:13:11.000 then switch case statements where the default case says should 289 00:13:11.000 --> 00:13:11.600 never get here. 290 00:13:12.360 --> 00:13:15.039 It's just like cool, let's make sure it doesn't. 291 00:13:15.399 --> 00:13:17.759 What's funny too, because the part of my life I 292 00:13:17.799 --> 00:13:20.879 did Java code and Java like had I think it 293 00:13:20.919 --> 00:13:22.720 was like a cert false or something like that. There's 294 00:13:22.759 --> 00:13:24.120 some way that you could put in your code that 295 00:13:24.240 --> 00:13:26.559 like if almost like at the compiler level, that if 296 00:13:26.559 --> 00:13:29.320 this code ever executed, it would have a way of 297 00:13:29.360 --> 00:13:32.720 like informing you, right whereas in JavaScript, outside of some tool, 298 00:13:32.799 --> 00:13:34.919 like you're saying that, there's no built in way of 299 00:13:35.000 --> 00:13:38.159 doing that, right, Like, there's no way of saying, hey, 300 00:13:38.279 --> 00:13:40.080 just let me know if this code ever runs, Javas 301 00:13:40.200 --> 00:13:43.120 will just merely go ahead, ignore that comment and go 302 00:13:43.240 --> 00:13:45.519 right on its way, and who knows what's going to happen. 303 00:13:45.600 --> 00:13:48.919 Well, people, I've seen people put to throw their own 304 00:13:48.919 --> 00:13:52.480 custom exceptions in those cases. But would you rather kill 305 00:13:52.679 --> 00:13:56.000 JavaScript execution completely and completely screw your up if it 306 00:13:56.039 --> 00:13:58.879 ends up in that case or have it run and 307 00:13:58.879 --> 00:14:01.039 then know about it because maybe it was okay that 308 00:14:01.080 --> 00:14:03.919 it hit that case. And I think that in jabscript 309 00:14:03.960 --> 00:14:06.399 land and client Sideline in particular, you don't have the 310 00:14:06.519 --> 00:14:09.480 luxury of being in a controlled environment. You can't just 311 00:14:09.600 --> 00:14:12.679 open the log file. The logs are on someone else's machine, 312 00:14:12.919 --> 00:14:15.000 and that machine is that environment is completely out of 313 00:14:15.080 --> 00:14:17.879 your control. So yeah, there's so many like you said, 314 00:14:18.080 --> 00:14:20.639 when you add these solutions in sometimes you're surprised at 315 00:14:20.639 --> 00:14:23.679 how many bugs appear. I mean, maybe that's because a 316 00:14:23.720 --> 00:14:25.679 lot of people don't think about it during development, and 317 00:14:25.679 --> 00:14:28.000 then when they do turn something on eventually they're like, oh, oh, 318 00:14:28.080 --> 00:14:31.360 look at all these educases that happened to loads of customers. 319 00:14:31.720 --> 00:14:34.279 Yeah, it's actually in a way of testament to JavaScript 320 00:14:34.440 --> 00:14:36.799 because they like in a way when I think back 321 00:14:36.799 --> 00:14:38.759 to job and saying, well, the code would completely stap 322 00:14:38.799 --> 00:14:40.679 if this happened. But no way, that's kind of a 323 00:14:40.679 --> 00:14:42.840 bad thing too, right, because if a customer hits it 324 00:14:43.159 --> 00:14:45.440 and then the app just totally says like oh compiler 325 00:14:45.679 --> 00:14:48.879 you know, or runtime air and just totally just dies. 326 00:14:49.000 --> 00:14:51.159 It's kind of nice in JavaScript that some of these 327 00:14:51.200 --> 00:14:54.279 areas can exist and things are mostly okay, right, like 328 00:14:54.320 --> 00:14:56.279 it like you still want to know about it, but 329 00:14:56.320 --> 00:14:58.679 maybe some they're still able to do. The user might 330 00:14:58.679 --> 00:15:00.799 still be able to do the task they they are 331 00:15:00.840 --> 00:15:03.039 able to do, so you don't necessarily want to just 332 00:15:03.120 --> 00:15:05.799 completely crash in these situations. So I kind of like 333 00:15:05.879 --> 00:15:07.600 the notification approach. 334 00:15:07.759 --> 00:15:10.080 It's good, it's good and bad you end up with 335 00:15:10.279 --> 00:15:12.559 a world that you know is almost a dirty word 336 00:15:12.600 --> 00:15:13.000 these days. 337 00:15:13.000 --> 00:15:14.399 Actually, it's having a bit of a renaissance. 338 00:15:14.399 --> 00:15:18.200 But in PHP, in original PHP, not cool new PHP, 339 00:15:18.879 --> 00:15:20.679 you could have an error and then the code would 340 00:15:20.720 --> 00:15:23.120 keep executing. It would say, oh, we had an error, Okay, 341 00:15:23.159 --> 00:15:24.960 let's just keep keep going. Let's keep going. So you 342 00:15:25.000 --> 00:15:28.240 end up sometimes having you know, twenty compounding errors on 343 00:15:28.279 --> 00:15:30.600 a page because this one variable wasn't initialized, and then 344 00:15:30.639 --> 00:15:32.960 it just kept on trying all the way down the page. 345 00:15:33.159 --> 00:15:36.639 And I think that we found pretty quickly that resilience 346 00:15:36.759 --> 00:15:39.320 was not helpful in that case. You ended up with 347 00:15:39.320 --> 00:15:42.759 with this getting into worse and worse situations as the 348 00:15:42.759 --> 00:15:45.200 code kept on trying to execute down the page. I 349 00:15:45.240 --> 00:15:47.879 think that the trade off is, you know, I think 350 00:15:47.879 --> 00:15:49.840 it's okay to have like click handle a fail in 351 00:15:49.879 --> 00:15:52.279 some particular case, but the rest of the app continues 352 00:15:52.320 --> 00:15:55.320 to work. But I think that it's much harder to 353 00:15:55.360 --> 00:15:58.720 diagnose and debug and reproduce problems, and so you end 354 00:15:58.799 --> 00:16:00.759 up with, you know, you're getting a from a customer 355 00:16:00.799 --> 00:16:03.080 saying I got into this state. Then how the heck 356 00:16:03.159 --> 00:16:05.840 is the developer or the support person going to reproduce 357 00:16:05.919 --> 00:16:07.799 that to get back into that state. That's the hard 358 00:16:07.799 --> 00:16:10.120 part with allowing code to continue to execute. 359 00:16:10.200 --> 00:16:12.399 For sure, I want to turn the conversation here in 360 00:16:12.399 --> 00:16:14.440 a second over to mobile because I know that's that 361 00:16:14.600 --> 00:16:16.720 opens a whole another can of worms. But do you 362 00:16:16.759 --> 00:16:19.240 have I think one last question on the website, are there, 363 00:16:19.279 --> 00:16:22.159 since you're sort of the aggregator of the aggregator of 364 00:16:22.200 --> 00:16:25.440 bugs in a sense, are there any like really common 365 00:16:25.440 --> 00:16:28.120 things that you find people do, or like things that 366 00:16:28.120 --> 00:16:31.559 your average developer should be aware of, like common mistakes 367 00:16:31.799 --> 00:16:34.799 that people overlook that to just look out for and 368 00:16:34.840 --> 00:16:35.879 sort of be cognizant of. 369 00:16:36.279 --> 00:16:39.720 Yeah, and it's it sounds so obvious, but it's just 370 00:16:39.759 --> 00:16:42.159 by far and away the highest order of magnitude type 371 00:16:42.159 --> 00:16:42.799 of bug. 372 00:16:42.600 --> 00:16:45.600 That we see, and that is uninitialized variables. 373 00:16:45.639 --> 00:16:49.840 Still in twenty twenty, null pointer exceptions, uninitialized variables are 374 00:16:49.879 --> 00:16:52.120 the number one cause of bugs. And there's no surprise 375 00:16:52.200 --> 00:16:56.039 that languages like like Swift try to come in and say, right, 376 00:16:56.120 --> 00:16:59.080 let's let's force things not to be null or uninitialized 377 00:16:59.120 --> 00:17:01.919 when the pile level. The other thing I think we 378 00:17:01.960 --> 00:17:04.440 see all the time in jovscript especially, and again no 379 00:17:04.559 --> 00:17:09.200 surprises here is type errors and problems caused by unclear 380 00:17:09.279 --> 00:17:12.880 typing or coercion of typing. And so a lot of 381 00:17:12.920 --> 00:17:15.640 these things I think can be solved by having really 382 00:17:15.720 --> 00:17:20.160 nice linting in place or using a typed variant of JavaScript. 383 00:17:20.599 --> 00:17:23.000 We use all of our new code box nexts React 384 00:17:23.079 --> 00:17:25.519 app is now in typescript and we have a ton 385 00:17:25.559 --> 00:17:28.480 of linting in place. I think we use Airbnb's e 386 00:17:28.680 --> 00:17:31.480 clint rules off the bat, But it's we're trying to 387 00:17:31.519 --> 00:17:33.519 keep things very tight before they even. 388 00:17:33.319 --> 00:17:36.559 Get merged in a PR. But because we see all 389 00:17:36.640 --> 00:17:37.480 these problems that come up. 390 00:17:37.480 --> 00:17:40.480 But yeah, no points are exceptions unlessitized variables type errors 391 00:17:40.519 --> 00:17:42.640 still in twenty twenty, the biggest problems. 392 00:17:43.119 --> 00:17:45.920 Yeah, it's funny. It's amazing how like simple linting tools 393 00:17:45.920 --> 00:17:49.279 can catch so much of these things. I'm curious when 394 00:17:49.319 --> 00:17:52.799 you say uninitialized variable, like like what the specific scenario 395 00:17:52.880 --> 00:17:54.920 is like, so I get to clear variable I don't 396 00:17:54.960 --> 00:17:57.400 know X right that I'm going to use. How is 397 00:17:57.400 --> 00:17:59.440 this an area that's not like cut by the developer 398 00:17:59.559 --> 00:18:02.440 during test. Is it that it's like like a different 399 00:18:02.440 --> 00:18:05.359 scenario like some if check or something that like there's 400 00:18:05.400 --> 00:18:08.079 some case that they're not accounting for or yeah. 401 00:18:08.200 --> 00:18:11.119