Speaker 1: Welcome to another episode of React Round Up. My name
Speaker 1: is TJ. Bentol, and I'm flying solo here on the
Speaker 1: panel today, but that is all right because I have
Speaker 1: James Smith with me today. James, why don't you go
Speaker 1: ahead and introduce yourself? Tell everybody a bit of why
Speaker 1: you're famous.
Speaker 2: Thanks DJ.
Speaker 3: Yeah, I'm James Smith. I the CEO and co founder
Speaker 3: of a company called Bugsnack and Bugsnack detect when software breaks.
Speaker 3: But prior to running a company and being a founder,
Speaker 3: I built software in the web or mobile applications in
Speaker 3: various industries for quite a while. I like to think
Speaker 3: of myself these days as a retired software engineer and just.
Speaker 1: Enough to be dangerous awesome. So bug managing software. So
Speaker 1: I'm going to start with like the like a softball,
Speaker 1: an easy question, but like why do you why do
Speaker 1: developers need bug managing software? Like why isn't it enough
Speaker 1: to just throw it out there and rely on like
Speaker 1: you know, user reports and QA and that sort of
Speaker 1: stuff to find these bugs.
Speaker 3: Were a surprising number of companies that we work with
Speaker 3: still do that, and they're coming to us to rehabilitate.
Speaker 3: But I think that modern software development has changed hugely.
Speaker 3: I joke a lot about how you know, twenty five
Speaker 3: thirty years ago, when you develop delivered software, you printed
Speaker 3: it onto a CD or floppy discs and that software
Speaker 3: was done. And these days most software is running in
Speaker 3: an environment where it can be updated and fixed and patched.
Speaker 3: And also I think that people adopted more principles like
Speaker 3: agile and lean, where sometimes you're going to build something
Speaker 3: that's not ready intentionally and you're going to say, look,
Speaker 3: we're going to release this to customers early because we
Speaker 3: don't even know if customers are going to like this yet.
Speaker 3: And so the concept of keeping and working on something
Speaker 3: after its shipped to the customers is now the default
Speaker 3: in most companies. In most cases, so you can't have
Speaker 3: this like perfect five month QA process, print it to
Speaker 3: gold Master and CD and shipping out to Best Buy.
Speaker 2: When it's done.
Speaker 3: You now have this living, breathing piece of so I
Speaker 3: think that's the main thing that's caused this evolution. I
Speaker 3: think that most people have now taken to squishing down
Speaker 3: that QA period and replacing it from both the left
Speaker 3: hand side and the right hand side. Probably almost everyone
Speaker 3: from the left hand side is adding in really nice
Speaker 3: automated testing, unit testing, integration testing, linting, and things like that.
Speaker 3: And from the right hand side, QA is getting pushed
Speaker 3: down by production awareness and production monitoring, where things like
Speaker 3: folks like error monitoring products are are key there.
Speaker 1: Yeah, it's interesting stuff, and I think maybe the next
Speaker 1: thing could you just paint me a picture of Like
Speaker 1: when you talk about like bug managoring or being reporting software, like,
Speaker 1: what does that actually look like?
Speaker 2: Like?
Speaker 1: So suppose I'm working at a big company, I've got
Speaker 1: a giant React app. Maybe I've also got to React
Speaker 1: like mobile app. What is my steps? Like, what is
Speaker 1: my experience actually like? Like how do I install this?
Speaker 1: And then what sort of thing am I looking at
Speaker 1: like once the deployer sab out to production.
Speaker 2: Yes, it depends on the type of software you're running.
Speaker 3: But yeah, in a React application or a web app stack,
Speaker 3: for example, you want to be able to monitor run
Speaker 3: time errors and bugs that are affecting your your end users,
Speaker 3: your customers out in the wild. And in order to
Speaker 3: do that, the way that our product works is we
Speaker 3: have SDKs or libraries that you install your package manager,
Speaker 3: so actually our software runs as part of your code,
Speaker 3: is linked in as part of your code, rather than
Speaker 3: being something that ingestslog.
Speaker 2: Files or anything like that.
Speaker 3: And so yeah, you're writing and React at you can
Speaker 3: just NPN or yarn install bugsnack. If you've got a
Speaker 3: Rails API powering your back end, you added to your
Speaker 3: gem file and do buddle install.
Speaker 2: And the same is true of pretty much every single
Speaker 2: platform that we run in.
Speaker 3: So once you've installed that SDK, you set an apike
Speaker 3: in code or configuration spending on the platform, and then
Speaker 3: bugs basically sits in the background, taking up almost zero
Speaker 3: resources until we detect a problem. As a curtain a
Speaker 3: problem differs on each platform, and then React app for example,
Speaker 3: we will detect any exception that bundles up to the
Speaker 3: window error handler on the browser, we will detect any
Speaker 3: on handled promise rejections, and then React specifically. We'll look
Speaker 3: into React error boundaries as well. So you could use
Speaker 3: any bugstag provided error boundary and wrap your parts of
Speaker 3: your code base in a bugsnag wrapper and will then
Speaker 3: automatically report them off to bugsnags dot com and send
Speaker 3: diagnostics alongside with it. But the process is pretty similar
Speaker 3: on every platform mobile, desktop, web browser, just with slight
Speaker 3: differences of the types of the era that we catch.
Speaker 1: Yeah, it's interesting. I know we were talking before that.
Speaker 1: The last time I use some sort of air reporting
Speaker 1: software was quite a few years ago, and I remember
Speaker 1: the first time I did it, I was absolutely astonished
Speaker 1: at what it was spitting out. Because you have this
Speaker 1: like I think when you work on a big piece
Speaker 1: of software, like you know there are some bugs out there, right,
Speaker 1: like you've got some gear tickets that have been opened
Speaker 1: for a while. You're like, yeah, yeah, yeah, we'll get
Speaker 1: to that. That's sort of a hard problem to solve.
Speaker 1: But I remember actually putting this stuff in and like
Speaker 1: you get stuff that like you had absolutely no clue
Speaker 1: what it meant. And I guess one thing. I'm curious
Speaker 1: because actually my one problem with using is and this
Speaker 1: was years ago when these things were probably a lot
Speaker 1: less refined, but it got hard to like make sense
Speaker 1: of all the ears because it almost became like there
Speaker 1: was just this like a huge mess of airs. So
Speaker 1: I'm curious like the sort of things you do. I
Speaker 1: imagine you have like some sort of like aggregation algorithms
Speaker 1: that tries to make sense of like well, okay, well
Speaker 1: these bugs are all the same, or like do you
Speaker 1: help try to help developers like get at like the
Speaker 1: root cause like maybe this is like browser specific or
Speaker 1: that sort of thing.
Speaker 3: Yeah, it's funny when I remember as been chucking out
Speaker 3: log files for ages, and a lot of the time
Speaker 3: you don't think actively to look at log files and
Speaker 3: you just go in there when you absolutely have to,
Speaker 3: and they're generating gigabytes and gigabytes of data that maybe
Speaker 3: you never look at.
Speaker 2: And then there was this leap from reactive.
Speaker 3: Error monitoring to productive aeroor monitoring, and there was really
Speaker 3: early players in the space. There was a product called
Speaker 3: hop toad, which rebranded to something else, which was super
Speaker 3: early in the rail space, and people were like, wow,
Speaker 3: this is really cool, but holy moly, do I have
Speaker 3: a lot of stuff coming in. And I think the
Speaker 3: leap that products like hotted initially made and then we've
Speaker 3: kind of refined over the years is aggregation number one.
Speaker 3: As you say, first off, can we say that, Look,
Speaker 3: we've had ten thousand bugs, ten thousand exceptions or crashes,
Speaker 3: but actually all of these ten thousand exceptions or crashes
Speaker 3: came from the exact same bug, the underlying the same
Speaker 3: line of code, and so at the most basic level.
Speaker 2: We have these grouping algorithms.
Speaker 3: We've born on grouping agorithms that look at the line
Speaker 3: of code where the bug originated, and it differs depending
Speaker 3: on the platform. We can be a lot more sophisticated
Speaker 3: in some areas where we'll look at how similar the
Speaker 3: code is, will take a snapshot of like seven lines
Speaker 3: before and after where the crash happened and look at
Speaker 3: code similarity heuristics, and in other platforms we keep it
Speaker 3: very simple. We don't have to do that level of
Speaker 3: complexity where we'll say this was this type of exception,
Speaker 3: so runtime error on line fifty nine of user dot Java,
Speaker 3: and that's enough for us to say with pretty high
Speaker 3: confidence that this is a unique bug to this version
Speaker 3: for example. Yeah, that getting that aggregation and grouping in
Speaker 3: place is the step one. But even then, you said earlier,
Speaker 3: how do people move from customer reports and customer feedback
Speaker 3: to having a proactive system like this? Well, not all
Speaker 3: bugs that we have a T shirt with this, and
Speaker 3: not all bugs are created equal. And if you just
Speaker 3: went through this list and said I'm going to fix
Speaker 3: every single bug that my bugsnog tool is reporting to me,
Speaker 3: then you're going to waste your life away. You're going
Speaker 3: to be spending time on stuff that really doesn't matter,
Speaker 3: especially in the clients side, especially when it comes to
Speaker 3: JavaScript and React applications, because it's the wild West. You've
Speaker 3: got browsers all over the different places, You've got Chrome
Speaker 3: extensions that causing problems and injecting content into the dom.
Speaker 3: And so the next layer on top of that aggregation
Speaker 3: is then sophisticated prioritization tool, so figuring out things like, well,
Speaker 3: which one affected the most customers, which one affected customers
Speaker 3: that are paying us the most money if you're going
Speaker 3: to keep it straightforward, or which one affected customers that
Speaker 3: are in key states or key flows like a log
Speaker 3: in or sign up flow for example. And so we
Speaker 3: try to capture as much information as we can at
Speaker 3: run time and then allow you to create filters, bookmarks
Speaker 3: and prioritization rules inside of bugsname.
Speaker 1: It's funny, I didn't even really think about that, but
Speaker 1: you're right, because someone could be just using some garbage
Speaker 1: Chrome extension, or like maybe they're even like developing their
Speaker 1: own Chrome extension. That's just like, you know, totally screwing
Speaker 1: things up. And if you try to debug that, my god,
Speaker 1: like you s going to be spending days and weeks.
Speaker 1: Can you even know, like, for example, anyway you can
Speaker 1: tell how bad it affected the user? Right? Like is
Speaker 1: this like is there a way of knowing like this
Speaker 1: is just an error, but it didn't actually affect the
Speaker 1: user experience versus like this is actually I don't know,
Speaker 1: like forcing the UI to be unresponsive or maybe even
Speaker 1: like crashing the tab or something. Is there are ways
Speaker 1: that you can even tell on that level of detail, Yeah.
Speaker 3: It's the most The simplest way to do that is
Speaker 3: to look at what we call the error handler, And
Speaker 3: so I kind of mentioned this. We use jobscripts as
Speaker 3: an example, or React as an example here. There's various
Speaker 3: ways that we automatically detect that a bug has happen,
Speaker 3: and some of them, for example, we wrap event handlers,
Speaker 3: so we wrap the callbacks to the event handlers. So
Speaker 3: if an exception happens in an event handler, and that
Speaker 3: doesn't necessarily always bubble up to your window dot on error,
Speaker 3: it might just mean that your click failed to do
Speaker 3: what you expected your click to do because the callback
Speaker 3: crashed halfway through. That is almost always less bad than
Speaker 3: a bug that bubbles up. Still bad, it's less bad
Speaker 3: than a bugue that bubbles all the way up to
Speaker 3: window on error, which basically means no JavaScript is executing
Speaker 3: in their scriptag anymore, and especially because most people are
Speaker 3: using bundlers these days and bundling all their jobs script
Speaker 3: up into applications on to JS. If your JavaScript stops
Speaker 3: executing in that scriptag, you're boned.
Speaker 2: That's it.
Speaker 3: The whole page stops responding. There's other things as well,
Speaker 3: like a promise rejection handler. Again, if it's in a
Speaker 3: promise it happened a synchronously, it's probably not the.
Speaker 2: End of the world.
Speaker 3: So that's the most straightforward way to look at it,
Speaker 3: and to say, look, if it was a click event,
Speaker 3: that's bad, but not as bad as if the entire
Speaker 3: page locked up. In terms of the performance aspects, though
Speaker 3: they're a lot more subtle. We have a all code
Speaker 3: snippets to detect certain things like freezes, and my favorite
Speaker 3: one is our frustration detection snippet, so it detects rage clicks.
Speaker 2: So if you, i said earlier, if you've got code that.
Speaker 3: Made a non click handler fail, fine, but how can
Speaker 3: you detect if your developers forgot to hook up on
Speaker 3: click at all to a button? So you've just got
Speaker 3: a button that looks like it's clickable, but there's literally nothing.
Speaker 3: And so we've got some snippets so you can drop
Speaker 3: in that will detect things like when you click on
Speaker 3: the same domb element multiple times within a particular time window,
Speaker 3: and then it will send a message to bugsnack saying
Speaker 3: someone's rage clicking this button.
Speaker 2: And so things like.
Speaker 3: That are still as frustrating, maybe more frustrating than a
Speaker 3: full page freeze, but it's kind of up to the
Speaker 3: developer to decide, Yeah, this is the one that's that's
Speaker 3: causing customers the most pain.
Speaker 1: Yeah, because you said snippet, so is your model. They're
Speaker 1: basically there's some default handling and then there's extra things
Speaker 1: you can add on that you may not want to
Speaker 1: give everybody because they were I'm assuming it works attended
Speaker 1: to the vent handler, so there's like some small performance here,
Speaker 1: so you might now want to go nuts with it
Speaker 1: sort of thing.
Speaker 2: Yeah, it's more.
Speaker 3: It's more that we have an opinion that our product
Speaker 3: is opinionated yet extensible, and so pretty much all of
Speaker 3: our SDKs are plug in based, I mean our JavaScript one.
Speaker 3: We just released a new version of this two days ago.
Speaker 3: The whole thing's built around plugins, even internally, so things
Speaker 3: start off as snippets sometimes and then graduate into official
Speaker 3: plugins that we put as default inside of the application.
Speaker 2: Some of them, like the rage click.
Speaker 3: One, they're more interesting than actionable in a lot of cases,
Speaker 3: and so if we ever evolve that to be one
Speaker 3: of these ones where it's like we are confident that
Speaker 3: something is going wrong based on these rage clicks, then
Speaker 3: we'll put it as a default plug in inside of
Speaker 3: our JavaScript SDK. But actually it's one of those things
Speaker 3: that people want to tune. How many clicks is a
Speaker 3: rage click? What time period should I measure? And all
Speaker 3: that kind of stuff. So the stuff that's on by default,
Speaker 3: the opinion of this stuff is what we think are
Speaker 3: the most important negative signals inside of your Apple cation typically.
Speaker 3: But yeah, it's all plug in base, and we try
Speaker 3: to expose as much as possible in terms of API
Speaker 3: so that you can hook in your own plugins and
Speaker 3: do your own stuff. Like even I said earlier about
Speaker 3: reporting handled versus unhandled exceptions, sometimes you've got your try
Speaker 3: catch and my favorite piece of code to read ever
Speaker 3: is when it says try catch, and all there is
Speaker 3: in the catch is a comment that so should never
Speaker 3: get here, and inevitably it's going to get there.
Speaker 2: So a lot of our customers do.
Speaker 3: Most of our customers do is they'll put a bugsnag, dot,
Speaker 3: notified brackets, E error, whatever it is, and so that
Speaker 3: way you know if it's got there, and then you
Speaker 3: can decide if that's a problem or not. But yeah,
Speaker 3: we try to be opinionated the accentsible as our produp philosophy.
Speaker 1: I kind of like that for the catch black because
Speaker 1: I've totally been that person that you go into the
Speaker 1: catch and you think to yourself, like, I don't even
Speaker 1: know how in the world this would happen, but like
Speaker 1: I feel like I can't just leave this empty, right,
Speaker 1: so I have to put something and it.
Speaker 2: Will it will happen.
Speaker 3: The ones that crack me up all the time, I
Speaker 3: think this is because I'm getting across the old program
Speaker 3: and now, but try catch blocks where the catch block
Speaker 3: has just a comment and nothing else in it, and
Speaker 3: then switch case statements where the default case says should
Speaker 3: never get here.
Speaker 2: It's just like cool, let's make sure it doesn't.
Speaker 1: What's funny too, because the part of my life I
Speaker 1: did Java code and Java like had I think it
Speaker 1: was like a cert false or something like that. There's
Speaker 1: some way that you could put in your code that
Speaker 1: like if almost like at the compiler level, that if
Speaker 1: this code ever executed, it would have a way of
Speaker 1: like informing you, right whereas in JavaScript, outside of some tool,
Speaker 1: like you're saying that, there's no built in way of
Speaker 1: doing that, right, Like, there's no way of saying, hey,
Speaker 1: just let me know if this code ever runs, Javas
Speaker 1: will just merely go ahead, ignore that comment and go
Speaker 1: right on its way, and who knows what's going to happen.
Speaker 3: Well, people, I've seen people put to throw their own
Speaker 3: custom exceptions in those cases. But would you rather kill
Speaker 3: JavaScript execution completely and completely screw your up if it
Speaker 3: ends up in that case or have it run and
Speaker 3: then know about it because maybe it was okay that
Speaker 3: it hit that case. And I think that in jabscript
Speaker 3: land and client Sideline in particular, you don't have the
Speaker 3: luxury of being in a controlled environment. You can't just
Speaker 3: open the log file. The logs are on someone else's machine,
Speaker 3: and that machine is that environment is completely out of
Speaker 3: your control. So yeah, there's so many like you said,
Speaker 3: when you add these solutions in sometimes you're surprised at
Speaker 3: how many bugs appear. I mean, maybe that's because a
Speaker 3: lot of people don't think about it during development, and
Speaker 3: then when they do turn something on eventually they're like, oh, oh,
Speaker 3: look at all these educases that happened to loads of customers.
Speaker 1: Yeah, it's actually in a way of testament to JavaScript
Speaker 1: because they like in a way when I think back
Speaker 1: to job and saying, well, the code would completely stap
Speaker 1: if this happened. But no way, that's kind of a
Speaker 1: bad thing too, right, because if a customer hits it
Speaker 1: and then the app just totally says like oh compiler
Speaker 1: you know, or runtime air and just totally just dies.
Speaker 1: It's kind of nice in JavaScript that some of these
Speaker 1: areas can exist and things are mostly okay, right, like
Speaker 1: it like you still want to know about it, but
Speaker 1: maybe some they're still able to do. The user might
Speaker 1: still be able to do the task they they are
Speaker 1: able to do, so you don't necessarily want to just
Speaker 1: completely crash in these situations. So I kind of like
Speaker 1: the notification approach.
Speaker 3: It's good, it's good and bad you end up with
Speaker 3: a world that you know is almost a dirty word
Speaker 3: these days.
Speaker 2: Actually, it's having a bit of a renaissance.
Speaker 3: But in PHP, in original PHP, not cool new PHP,
Speaker 3: you could have an error and then the code would
Speaker 3: keep executing. It would say, oh, we had an error, Okay,
Speaker 3: let's just keep keep going. Let's keep going. So you
Speaker 3: end up sometimes having you know, twenty compounding errors on
Speaker 3: a page because this one variable wasn't initialized, and then
Speaker 3: it just kept on trying all the way down the page.
Speaker 3: And I think that we found pretty quickly that resilience
Speaker 3: was not helpful in that case. You ended up with
Speaker 3: with this getting into worse and worse situations as the
Speaker 3: code kept on trying to execute down the page. I
Speaker 3: think that the trade off is, you know, I think
Speaker 3: it's okay to have like click handle a fail in
Speaker 3: some particular case, but the rest of the app continues
Speaker 3: to work. But I think that it's much harder to
Speaker 3: diagnose and debug and reproduce problems, and so you end
Speaker 3: up with, you know, you're getting a from a customer
Speaker 3: saying I got into this state. Then how the heck
Speaker 3: is the developer or the support person going to reproduce
Speaker 3: that to get back into that state. That's the hard
Speaker 3: part with allowing code to continue to execute.
Speaker 1: For sure, I want to turn the conversation here in
Speaker 1: a second over to mobile because I know that's that
Speaker 1: opens a whole another can of worms. But do you
Speaker 1: have I think one last question on the website, are there,
Speaker 1: since you're sort of the aggregator of the aggregator of
Speaker 1: bugs in a sense, are there any like really common
Speaker 1: things that you find people do, or like things that
Speaker 1: your average developer should be aware of, like common mistakes
Speaker 1: that people overlook that to just look out for and
Speaker 1: sort of be cognizant of.
Speaker 3: Yeah, and it's it sounds so obvious, but it's just
Speaker 3: by far and away the highest order of magnitude type
Speaker 3: of bug.
Speaker 2: That we see, and that is uninitialized variables.
Speaker 3: Still in twenty twenty, null pointer exceptions, uninitialized variables are
Speaker 3: the number one cause of bugs. And there's no surprise
Speaker 3: that languages like like Swift try to come in and say, right,
Speaker 3: let's let's force things not to be null or uninitialized
Speaker 3: when the pile level. The other thing I think we
Speaker 3: see all the time in jovscript especially, and again no
Speaker 3: surprises here is type errors and problems caused by unclear
Speaker 3: typing or coercion of typing. And so a lot of
Speaker 3: these things I think can be solved by having really
Speaker 3: nice linting in place or using a typed variant of JavaScript.
Speaker 3: We use all of our new code box nexts React
Speaker 3: app is now in typescript and we have a ton
Speaker 3: of linting in place. I think we use Airbnb's e
Speaker 3: clint rules off the bat, But it's we're trying to
Speaker 3: keep things very tight before they even.
Speaker 2: Get merged in a PR. But because we see all
Speaker 2: these problems that come up.
Speaker 3: But yeah, no points are exceptions unlessitized variables type errors
Speaker 3: still in twenty twenty, the biggest problems.
Speaker 1: Yeah, it's funny. It's amazing how like simple linting tools
Speaker 1: can catch so much of these things. I'm curious when
Speaker 1: you say uninitialized variable, like like what the specific scenario
Speaker 1: is like, so I get to clear variable I don't
Speaker 1: know X right that I'm going to use. How is
Speaker 1: this an area that's not like cut by the developer
Speaker 1: during test. Is it that it's like like a different
Speaker 1: scenario like some if check or something that like there's
Speaker 1: some case that they're not accounting for or yeah.
Speaker 3: It's almost it's almost always when one of the things
Speaker 3: is when we see all these bugs coming in and
Speaker 3: but we can't see the full source code of our customers.
Speaker 3: We don't, you know, it's a sensitive error. We don't
Speaker 3: want them to have give us access to that, so
Speaker 3: we keep it isolated. But what we see in our code,
Speaker 3: and what I've seen in my career at least, is yeah,
Speaker 3: when the developer has over confidence in the order or
Speaker 3: structure of code execution, and so you're like, well, it's
Speaker 3: going to go off into this function over here, it's
Speaker 3: going to fill in all these this data and then
Speaker 3: we'll run.
Speaker 2: The next thing.
Speaker 3: But there are about fifty ways that that function that's
Speaker 3: meant to fill in all these variables could fail. And
Speaker 3: I mean this is a really I think are really
Speaker 3: straightforward one. All right, blog posts about years ago. But
Speaker 3: one of the most common bugs that we've seen in
Speaker 3: JavaScript land is for legacy applications is jQuery is not defined,
Speaker 3: and jQuery is not defined as a bug because most
Speaker 3: people history would put in jQuery from a CDM and
Speaker 3: then they would run their code afterwards, so they would
Speaker 3: expect jQuery or the dollar symbol to be defined. But
Speaker 3: because of the way that the job script engines run,
Speaker 3: if one script tag fails, the next script tag will
Speaker 3: continue to run and try to run. So if your
Speaker 3: next script tag, the whole thing relies on there being
Speaker 3: a dollar symbol jQuery defined, but it's not, you're kind
Speaker 3: of bunned. And so if you're using some kind of
Speaker 3: module system or buddle system that has interdependencies, that can
Speaker 3: be the case as well. But it's true of any
Speaker 3: code that expects something else to be available and to
Speaker 3: set up. If that fails, you're out of luck. So yeah,
Speaker 3: it's really just being overconfident about code paths running and
Speaker 3: not failing.
Speaker 1: Who would do that though, Luckily I'm that guilty of that,
Speaker 1: So we're good to go. So I do want to
Speaker 1: get into mobile because this seems like even more of
Speaker 1: a hairy territory. So I imagine, like from the web perspective,
Speaker 1: your code is still going to run for like the
Speaker 1: mobile web, and so the very similar sort of workflow
Speaker 1: and sich but you were with reacting native as well
Speaker 1: as they're correct.
Speaker 2: That's right. Yeah, it's mobile.
Speaker 3: Is I talk about clients like being the wide Wild West,
Speaker 3: and people who are jobs developers for the browser know
Speaker 3: that the browser environment differences are contentpated the But now
Speaker 3: I think if you think it's a paint in the
Speaker 3: bum developing for three four different major browsers. There are
Speaker 3: twenty to forty thousand different Android devices out there in
Speaker 3: the wild, and every single manufacturer of Android device is
Speaker 3: LG Samsung whoever puts their own lot of flavor and
Speaker 3: spice on Android. And what I mean by that is
Speaker 3: they can do things such as actually edit the core
Speaker 3: operating system of Android. There was really crazy bugs back
Speaker 3: in the day on Android when it was a bit
Speaker 3: more uncontrolled, before Google stepped in and said, hey, stop
Speaker 3: messing with this. I forget who it was now, so
Speaker 3: I didn't want to shame the wrong vendor, but a
Speaker 3: manufacturer of Android devices edited Jason Parsing code in core
Speaker 3: Android to do something different. So if you're an Android
Speaker 3: developer expecting Jason to be passed and handled in a
Speaker 3: particular way, it would work absolutely fine on every vendor
Speaker 3: apart from this one, and then your code wouldn't work.
Speaker 3: And if you didn't have some if you didn't have
Speaker 3: that in your test farm of devices, or you didn't
Speaker 3: have something like a bug stagg in production, you wouldn't
Speaker 3: know about it apart from someone saying, hey, I've got
Speaker 3: LG phone or whatever. It is and it's not working.
Speaker 3: Your app isn't working. And so yeah, it's not as
Speaker 3: easy as spinning up a couple of VMS. You can't
Speaker 3: have all twenty to forty thousand Android devices out at
Speaker 3: your desk from all these different vendors. So mobile is hairy,
Speaker 3: and the more hairy the environment is, the harder it
Speaker 3: is to build really good, high quality SDKs to these platforms.
Speaker 3: But yeah, we do support React native and we have
Speaker 3: to do with that, plus all the other layers of reacnative.
Speaker 1: And what's the actual like like high level implementation look like,
Speaker 1: because then the way I imagine like like this is
Speaker 1: over trivializing, but it's like a window at an ear
Speaker 1: handler and then a load of logic around that. And
Speaker 1: native does react native provide like hooks into this or
Speaker 1: is do you have of like native code that gets
Speaker 1: into this and finds all the years or how does
Speaker 1: that work?
Speaker 3: The latter there's a React native is one of these
Speaker 3: environments where I actually think that when when reat native
Speaker 3: first came out, people were like, oh great, this is right.
Speaker 3: Once deploy modible places, this is going to be awesome.
Speaker 3: But in reality, I mean that's what kind of expos
Speaker 3: for these days. But I think in reality a lot
Speaker 3: of people are using React native to do retrofit work.
Speaker 3: They're taking existing Native applications and they're putting in replacing
Speaker 3: some chumps in it or some components of it with
Speaker 3: React native. Now, because there is jobscript code and there
Speaker 3: is iOS and Android code running inside of most of
Speaker 3: these applications, we need to make sure that we catch
Speaker 3: bugs in every single layer. So a layer cake at
Speaker 3: the top, you've got the JavaScript runtime, even that you've
Speaker 3: got different types of JavaScript runtime running because you've got
Speaker 3: JS core versus whatever else is.
Speaker 2: Being distributed, So you've got that JS runtime difference.
Speaker 3: I then you've got the operating system iOS or androids
Speaker 3: layer differences, and we have to capture objective C errors
Speaker 3: and Swift errors and all sorts of stuff with iOS,
Speaker 3: and then.
Speaker 2: JVM errors on the Android side.
Speaker 3: And then one layer down you've got things like ndk
Speaker 3: R C and C plus plus errors happening in Android
Speaker 3: and then the same equivalent happening on iOS.
Speaker 2: So tons of layers they will have to communicate.
Speaker 3: Recently, React Native actually don't know how recently it was,
Speaker 3: but reacnative now supports React error handlers, which is great
Speaker 3: air boundaries. Sorry, And so that's something that bugs nice
Speaker 3: always supported and now you can use those in React Native.
Speaker 2: But effectively, what we have to do is we have to.
Speaker 3: Be able to capture bugs at every single layer and
Speaker 3: reliably report them. And sometimes we have to be able
Speaker 3: to report bugs before the React native engine has even initialized,
Speaker 3: because there might be some Android code that ran before
Speaker 3: the React native code initialized.
Speaker 2: So yeah, we just recently.
Speaker 3: Released a new major version of our React native notifier
Speaker 3: and put it all under one mono refone bugs JS
Speaker 3: to make sure that this initialization logic is buttoned up.
Speaker 1: Yeah, yeah, that's crazy. I have some background in native script,
Speaker 1: so like similar technology to React Native, like JavaScript running
Speaker 1: on mobile, And I remember one thing we struggled with
Speaker 1: is getting really good JavaScript stack traces. Are you able
Speaker 1: to when you catch the air on like native land,
Speaker 1: like give people the like this is the line of
Speaker 1: code where there was a problem. I just really And
Speaker 1: that's something like React Native exposes for you, or do
Speaker 1: you have to do some like magic to try to
Speaker 1: access that.
Speaker 3: As a lot of magic in every layer, the stack
Speaker 3: traces are almost certainly obfuscated in some way, either intentionally
Speaker 3: or unintentionally. In the JavaScript layer, we rely on the
Speaker 3: source maps standard, which isn't as standard as you think.
Speaker 3: It's very wildly differently implemented on each platform. But what
Speaker 3: we do is if we have an obfiscated JavaScript stack trace,
Speaker 3: we're not going to get that to the development instid
Speaker 3: of going to be like, what the heck.
Speaker 2: Is you know function x Y two not what I wrote.
Speaker 3: We want to show people the line of code that
Speaker 3: they wrote rather than what it ended up being obfscated into.
Speaker 3: So we automatically ingest and apply source maps to the
Speaker 3: JavaScript layer so that we can present the original stack
Speaker 3: trace to the developer.
Speaker 2: But like as I.
Speaker 3: Said, because it's a multi layer system, we also have
Speaker 3: to do that in iOS and Android. And Android a
Speaker 3: lot of people use something called pro guard, and progard
Speaker 3: obfiscates the Java stack traces. We have to then reapply
Speaker 3: to get the original stack traces back, and then the
Speaker 3: same is true.
Speaker 2: iOS.
Speaker 3: iOS is almost even worse because it's effectively just not
Speaker 3: offending iOS developers here, but it's like it's c it's
Speaker 3: low level, and so if a crash happens, what we
Speaker 3: get is a memory address. It looks more like a
Speaker 3: classic core dump and so we have to take that
Speaker 3: memory address and then reapply something called a decent file
Speaker 3: to it to produce an original stack trace.
Speaker 2: So yeah, magic all layers of the stack.
Speaker 1: Yeah, I didn't even think about the programmed thing I had. Actually,
Speaker 1: I've run across this with Magnaita script experience as well,
Speaker 1: because a lot of people don't think about the fact
Speaker 1: that when you think of iOS and Android apps, you
Speaker 1: think the source code is like compiled and obfuscated and
Speaker 1: you can't just download and use it. But since with
Speaker 1: React Native you're running with JavaScript code, if you don't
Speaker 1: take any additional steps, your JavaScript code is just hanging
Speaker 1: out there right in your bundle, and to a lot
Speaker 1: of people, especially like I don't know, people dealing with
Speaker 1: sensitive work or company data, they don't want to expose that,
Speaker 1: so they do some basically additional obfuscation on top of
Speaker 1: what you'd normally do on the webs. You end up
Speaker 1: with some absolutely garbled nonsense. I'm actually pretty impressed that
Speaker 1: you're able to like sort of undo, because that's like
Speaker 1: unreversed reverse engineering in a sense, to get at the
Speaker 1: parts you're interested in.
Speaker 3: I'm glad that there are somewhat standards here, and we've
Speaker 3: been of evolving the source map standard as well a
Speaker 3: little bit.
Speaker 2: But I'm glad there's somewhat standards here.
Speaker 3: Because there's a bit of a first engineering required, but
Speaker 3: mostly we're just trying to follow the rules almost and say, right,
Speaker 3: let's pick this back apart. But yeah, without the aggregation
Speaker 3: and grouping and without the dealfiscation work with you to
Speaker 3: provide original source maps, I think that a product like
Speaker 3: bugsnack would be a lot less.
Speaker 1: Valuable for sure. The other thing I want to get
Speaker 1: into is, I know one of the key things you
Speaker 1: do is help protect against like I think you say,
Speaker 1: I Reddick GUESDKS writer or other SDKs you use, And
Speaker 1: I know you were telling me a story of Facebook
Speaker 1: their SDK sort of going down, So why don't you
Speaker 1: share like what I guess what I'm talking about right
Speaker 1: in terms of third party SDKs and a React native
Speaker 1: world and sort of what you can do about that.
Speaker 3: Well, I was joking about jquer is not defined earlier
Speaker 3: and things like that, but you know, modern software, you
Speaker 3: don't write the whole thing yourself from scratch. You're relying
Speaker 3: on other people's open source packages and SDKs and for
Speaker 3: anyone who is a React native or iOS developer recently
Speaker 3: that uses the Facebook SDK, you'll be very familiar with
Speaker 3: the fact that there were two outages within two and
Speaker 3: a half months on the Facebook SDK that caused eye
Speaker 3: applications to crash at boots if they were using Facebook's
Speaker 3: authentication platform. And this is super frustrating because so first off,
Speaker 3: I like to say, I don't want to anger the
Speaker 3: ops gods, and so you know, Facebook had this issue.
Speaker 2: You know, it sucks, but like you know, I give
Speaker 2: them a break a little bit.
Speaker 3: It's a tricky one to deal with, but in reality
Speaker 3: it's a really difficult one for developers to deal with
Speaker 3: as well. If you ask Spotify, you use the Facebook
Speaker 3: SDK to allow people to authenticate one day without any
Speaker 3: code changes happening at all on your side, suddenly your
Speaker 3: app stops working and you get a ton of bug
Speaker 3: snaggs or whatever you're using for air monitoring coming in.
Speaker 3: And what happened was, in this particular case, Facebook's SDK
Speaker 3: reaches out to Facebook's API to say, hey, tell me
Speaker 3: information about how I should initialize. Facebook's API responded differently
Speaker 3: to how the SDK was expecting, so it came back
Speaker 3: and said instead of giving a structure a dictionary, it
Speaker 3: came back with a boollion. And so the code that
Speaker 3: was reading that Jason Payload basically just wet.
Speaker 2: The bend, just like what do I do here?
Speaker 3: So it kind of sucks because normally developers think about
Speaker 3: bugs that are introduced as part of a code change,
Speaker 3: but in this case, it wasn't a code change. The
Speaker 3: data changed, and it was data that wasn't even part
Speaker 3: of my application.
Speaker 2: It was data was part of a third party SDK.
Speaker 3: And so yeah, holy moly, we had all of these
Speaker 3: apps that use the Facebook SDKA, which is almost every
Speaker 3: consumer mobile application completely die on boot. Some of them didn't,
Speaker 3: and we found that quite interesting. And so because we're
Speaker 3: a crash monitoring solution and error monitoring solution, we saw
Speaker 3: all of the crashes coming in from all of these
Speaker 3: major consumer mobile.
Speaker 2: Applications that use our products. So we had a bit
Speaker 2: of a deluge.
Speaker 3: And luckily my infrastructure teams built an architecture that was
Speaker 3: almost scaling and we barely noticed the blip, which is fantastic,
Speaker 3: but yeah, we were like, well, why does this app
Speaker 3: have this volume of crashes? With this app's fine in reality,
Speaker 3: it's really sensible defensive programming that some developers had taken
Speaker 3: and others hadn't. So one of them was wrapping the
Speaker 3: SDK in their own error hooks, so if this crash happened,
Speaker 3: it could bubble up to the top and crash the application.
Speaker 3: That one's pretty straightforward, easier said than done, though, because
Speaker 3: a lot of asynchronous work was happening in that SDK.
Speaker 3: The other one, which is a bit more aggresive, which
Speaker 3: actually think is a really good best practice in general
Speaker 3: for anyone using SDKs, is wrapping the SDK initialization in
Speaker 3: a feature flag. So we saw some shapes of error
Speaker 3: chart coming in that were like, well, there's tons of crashes,
Speaker 3: and then immediately went down to zero because these customers
Speaker 3: of ours were able to turn off Facebook's SDK by
Speaker 3: updating a feature flag remotely.
Speaker 2: That was then did not initialize that code for their
Speaker 2: for their customer base.
Speaker 3: I wish I could tell you which customers, because there's
Speaker 3: I give them shout out, but obviously.
Speaker 2: Obviously private stuff.
Speaker 3: But you know, there's all these ways that now, if
Speaker 3: you're relying on third party code, you have to be
Speaker 3: super aware of all the is that that code could
Speaker 3: change based on external dependencies and protect against that.
Speaker 1: Yeah, I'm actually quite amazed that some people actually were
Speaker 1: that proactive to account for this, because I think in
Speaker 1: the NATA script apps I wrote, I never once made
Speaker 1: an assumption. I mean, okay, so it's one thing if
Speaker 1: like you call it to a third party like API
Speaker 1: or something, right like, those are the situations. Usually you
Speaker 1: would have some are handling. Like I'm building a mapping
Speaker 1: app and I need to get like locations to show
Speaker 1: on markers, and I call some service. Well, I'm gonna
Speaker 1: have some are handling for that because this is a call.
Speaker 1: But I never I had never accounted the service itself, right,
Speaker 1: because almost all of these things a native have like
Speaker 1: some sort of a NIT call, right, you pass it
Speaker 1: in API key so you initialize it, and usually those
Speaker 1: things don't even have air handling hooks, right, like, at
Speaker 1: least in an experience, is always right like it It's
Speaker 1: not like you call like Facebook, Dot, SDK dot and
Speaker 1: knit and you have to pass it and on air handler.
Speaker 1: It's just assumed you do it right, and like normally,
Speaker 1: then later on in your code you just have to
Speaker 1: like make sure it's their sort of thing. But you know,
Speaker 1: you never account for BacT that, like what if it
Speaker 1: did like something erroneous or something that I totally didn't expect.
Speaker 1: So I'm absolutely amazed because I would definitely find the
Speaker 1: camp of people that like hard crash for sure and
Speaker 1: this sort of situation because I sort of assume these
Speaker 1: things are always going to be there.
Speaker 3: I've got to believe that the people who did that
Speaker 3: either have been bitten by this problem in the past
Speaker 3: and in their post mortem retrospective they were like, let's
Speaker 3: do this, or they were used to working.
Speaker 2: In an environment where SDKs are less reliable.
Speaker 3: One of those is in my former life, I used
Speaker 3: to work for a company that they gaming SDKs, mobile
Speaker 3: gaming SDKs, and notoriously add provider SDKs were the crashiest SDKs.
Speaker 3: Because you've got these companies where they're experts in monetization,
Speaker 3: they're experts at building relationships with developers and publishers, but
Speaker 3: maybe their SDKs on't the hottest SDKs around and people
Speaker 3: are swapping them in and out all the time to
Speaker 3: get the best deal. The business team is saying, right,
Speaker 3: we need to swap out to use this ad provider
Speaker 3: because they're giving us a better deal. But no one's saying,
Speaker 3: are they well known developers and they have a good,
Speaker 3: high quality SDK.
Speaker 2: So I know, at least in the gaming space mobile
Speaker 2: gaming space, people.
Speaker 3: Were very wary about adding in you ad SDKs and
Speaker 3: therefore probably more likely to protect against problems.
Speaker 1: Yeah. And the other thing too, is that in native
Speaker 1: land it's really hard, if not in some cases impossible,
Speaker 1: to actually fix these problems on the fly like there.
Speaker 1: I mean, there are some things you can do, like
Speaker 1: in a React native world to like hot swap production code,
Speaker 1: but it gets wonky at times. So I'd imagine too
Speaker 1: like a lot of these would require full like app
Speaker 1: updates through the app Store, Google Play and such they
Speaker 1: actually fixed too, So like, yeah, like a fairly significant
Speaker 1: business last I imagined for some of these people.
Speaker 2: Yeah.
Speaker 3: I wouldn't even want to think about the actual dollar
Speaker 3: amount of that because it woul stressed me out too much.
Speaker 3: But I know that it was very rare that people
Speaker 3: use feature flags and turn these things off. It's very
Speaker 3: rare that people using code push or something like that
Speaker 3: to hot patch these things. I know from looking at
Speaker 3: the data that a lot of our customers that solve
Speaker 3: these problems effectively just rode the wave and waited for
Speaker 3: Facebook because they couldn't do anything else. They had to
Speaker 3: wait for Facebook to fix it because this is a
Speaker 3: multiple ow issue.
Speaker 1: But yeah, Facebook's going to fix it faster than they're
Speaker 1: going to be exactly.
Speaker 3: Yeah, And in the end, that's just think that Facebook
Speaker 3: rolled back the co changes on their side that made
Speaker 3: the data structure change.
Speaker 1: Gotcha. So one of the things I want to get
Speaker 1: into is like workflow from a company perspective and like
Speaker 1: sort of any recommendations you might have, So like, if
Speaker 1: we take this example, what is like what would you
Speaker 1: I guess, what's the ideal like developer experience because obviously,
Speaker 1: like you don't want to be notified every time like
Speaker 1: somebody gets jQuery is not defined on your page, but
Speaker 1: you might want to know if your entire iOS and
Speaker 1: Android user base is suddenly hard crashing instantly. So what
Speaker 1: are like, I guess what sort of systems you support
Speaker 1: and what do you maybe recommend for notifications? Like are
Speaker 1: are like people getting emails for this? Or like how
Speaker 1: how quickly are people getting notified and able to resc
Speaker 1: span when something like this happens.
Speaker 3: So the way we've built bugsnag at least is that
Speaker 3: we fit. We try to fit into existing workflows. So
Speaker 3: if you are using Jira or any other project management
Speaker 3: or issue tracking tool, we support that, and we don't
Speaker 3: just support it as a creative issue in that tool.
Speaker 3: We typically have what we call a two way synchronization.
Speaker 3: So if you send a link of bugsnag, bugget a
Speaker 3: Dura and someone marks it as fixed in Dura or
Speaker 3: whatever we're using, that will market is fixed inside of bugsnag.
Speaker 3: And so we support pretty much every major issue tracker
Speaker 3: and project management tool, and we try to have a two.
Speaker 2: Way sync on all of those platforms.
Speaker 3: We even do things like if you've marked its fixed
Speaker 3: in your dur at, AOL or whatever it is, and
Speaker 3: then bugsnag detext it's still happening in a later release,
Speaker 3: will automatically reopen.
Speaker 2: It and market as a regression.
Speaker 3: So we don't want to be a product that comes
Speaker 3: in and says you have to completely change the way
Speaker 3: you're doing things. We want to be a little nudge
Speaker 3: in the right direction. So integrations with the project management
Speaker 3: tools is a key way that we do that. We
Speaker 3: also integrate with a learning in chat tools, and so
Speaker 3: most people use in slack. These days or vers teams
Speaker 3: or something like that you can configure on an application
Speaker 3: by application basis.
Speaker 2: I want these types of errors to go into these
Speaker 2: types of chatterings.
Speaker 3: So if you are a govership developer, you might want
Speaker 3: to see all new errors that we haven't seen before
Speaker 3: pop up as a message. We recently launched something about
Speaker 3: a month ago, month and a half ago that we
Speaker 3: call the alerting and a worklow engine, and this is
Speaker 3: basically a more sophisticated way of routing those things. So
Speaker 3: you can say, look, I work on the payments platform
Speaker 3: in the React application, and that is defined as living
Speaker 3: under these URLs or having this package name in the copath.
Speaker 3: So you can now set up alerts to that match
Speaker 3: those patterns, to go into a particular Slack channel, or
Speaker 3: to alert to a higher frequency because Zechy copaths. So
Speaker 3: I've said this a couple times now, But the client
Speaker 3: side is the wild West. It's a little bit insane
Speaker 3: to turn on error alerts for every new error. Some
Speaker 3: we have the option to bug sit to turn on
Speaker 3: alerts for every occurrence of each error. That makes sense
Speaker 3: again if you've honed it down to say I want
Speaker 3: to see on my rails application every time a credit
Speaker 3: card fails to pass through because.
Speaker 2: Of a problem on our side.
Speaker 3: But the web, your code is running on so many
Speaker 3: different devices in so many different environments that it's a bit.
Speaker 2: Much to have all of those coming in.
Speaker 3: So really the default that we have is alertly on
Speaker 3: any new type of bug that hasn't happened before. And
Speaker 3: then you can go in and again opinionated yet extensive.
Speaker 3: We can go in and then fine tune exactly what
Speaker 3: you want to see. We also integrate with everything else,
Speaker 3: and like page duty, we integrate with web hops.
Speaker 2: When to go splunk, you name it, we've got a
Speaker 2: connection to it.
Speaker 1: Actually, yeah, that makes sense. I didn't even think about
Speaker 1: that angle, But I could totally see when I'm setting
Speaker 1: this up saying like, well, if something goes on here,
Speaker 1: like I want to like, I want it lug, but
Speaker 1: I don't necessarily want to know about it. But if
Speaker 1: a payment fails or if like a user registration something
Speaker 1: like highly valuable knows, I might mind to ping someone
Speaker 1: like immediately and cool. Yeah, I could see like the
Speaker 1: Slack bit of it being pretty nice.
Speaker 3: So you want to build trust in in Slack. You
Speaker 3: don't want to be one of those tools, those products.
Speaker 3: It's a noisy bot, and so what we technically do
Speaker 3: is we tune it down by default. And the other
Speaker 3: thing we do is spike detection. So if we detect
Speaker 3: it there's an unusual increase in in errors on a project,
Speaker 3: that will ping into Slack by default. But also that's
Speaker 3: the sort of thing that people hook up to page,
Speaker 3: you do to your ops geny or whatever you're on
Speaker 3: call system. It's so we're seeing more and more development
Speaker 3: teams rather than just operations, and for teams having on
Speaker 3: call rotors so you get worken up at four in
Speaker 3: the morning if there's an unusual spiking activity, if that
Speaker 3: Facebook bug happened, for example, in the middle of the night.
Speaker 1: Yeah, yeah, because that's like the one situation where you
Speaker 1: actually probably would want to be woke up at four
Speaker 1: in the morning. That's something it's worth looking into for sure.
Speaker 1: This this has been sort of fascinating to me. Is
Speaker 1: there any topics that we have yet to cover that
Speaker 1: you'd like to get into or do you have any
Speaker 1: other advice you'd like to give out There two people
Speaker 1: who have decent size react audience that they should know
Speaker 1: just about bug reporting in general.
Speaker 3: I feel like the the obvious one is like, if
Speaker 3: you're not using some kind of production awareness production error monitoring.
Speaker 2: You absolutely have to these days.
Speaker 3: Just it feels like people who aren't doing it these
Speaker 3: days are just sticking their fingers.
Speaker 2: And there isn't hoping for the best.
Speaker 3: And so I think most of the audience is already
Speaker 3: using something, even if they've homegrown their own thing that's
Speaker 3: a window not on error and send an email or
Speaker 3: something like that. So that's the kind of first thing.
Speaker 3: But I also think that, like you said before, that
Speaker 3: error monitoring, instability management's come a really long way in
Speaker 3: the past five ten years, and you don't need to
Speaker 3: declare bug bankruptcy anymore.
Speaker 2: You don't need to just turn on as all we
Speaker 2: are it's too much.
Speaker 3: We just give up if you and your One thing
Speaker 3: I talk about all the time is that engineering and
Speaker 3: product teams actually should be really really aligned on what
Speaker 3: a bad bug is and the definition of when is
Speaker 3: the right time to work on bug fixes versus.
Speaker 2: Getting that new feature live.
Speaker 3: So have a tool that monitors is in production, and
Speaker 3: then have alignment inside your development team that says we
Speaker 3: are going to fix bugs that pass this threshold and
Speaker 3: we're going to stop on new product development if our
Speaker 3: stability drops below a particular percentage. So I genuinely think
Speaker 3: if you align between products and engineering, or some people
Speaker 3: call it business and engineering, but those two teams need
Speaker 3: to have alignment in order for you guys to know
Speaker 3: when the right time is to fix barks and clean
Speaker 3: up technical debts. And there are two things that I've evangelize.
Speaker 1: Well, yeah, and I definitely agree with that with my
Speaker 1: experiences as well. Like it's I think, like you said,
Speaker 1: it's still far too common for i mean, really huge
Speaker 1: organizations in some sense, they're really important apps to just
Speaker 1: be totally flying by right, this is just not doing anything.
Speaker 1: So it's a good note. I think it's a good
Speaker 1: note to end on. So why don't we go ahead
Speaker 1: and move into the picks? So I have just one
Speaker 1: pick today. I've gotten into I don't even remember, like
Speaker 1: the weird way the internet works what gots me into this?
Speaker 1: But there's this guy. Have you ever heard of the
Speaker 1: guy named wim Hoff. He's oh, yeah, like this. I
Speaker 1: think he's this Dutch guy that's like famous for going outside,
Speaker 1: like shirtless and like climbing mountains in the snow sort
Speaker 1: of thing. And for some reason this just fascinated me.
Speaker 1: So I've got a book on him called What Doesn't
Speaker 1: Kill Us, and I'm a few few chapters into it.
Speaker 1: I've been just listening to the audio book and it's
Speaker 1: it's sort of fascinating. It talks through the science of
Speaker 1: like is it just this dude's genetic makeup that's that
Speaker 1: allows him to do it? Or is it just training, right,
Speaker 1: like getting getting more accustomed to this? And the answer
Speaker 1: seems to be a little bit of both. But it's
Speaker 1: it's interesting because it definitely takes more of like a
Speaker 1: scientific perspective on like how in the heck is this possible?
Speaker 1: So I'd recommend it if you're at all curious about that.
Speaker 1: I check that out.
Speaker 2: So Pick is not the guy who can mentally control
Speaker 2: his body temperature?
Speaker 1: Well, yeah, that's that's where it gets. Yeah, that's where
Speaker 1: it gets into like a little bit of craziness because
Speaker 1: like you find yourself as you read through this going
Speaker 1: back and forth between like this guy is just looney
Speaker 1: Tunes crazy a little bit, But at the same time,
Speaker 1: he subjects to himself to like scientific studies a lot, right, Like,
Speaker 1: unlike a lot of these people that are like your
Speaker 1: clerics and crazy like sort of nutcases. He actually submits
Speaker 1: himself to scientific studies a lot, Like he's been put
Speaker 1: through all sorts of rigorous tests and such as well,
Speaker 1: so like some of what he claims has actually been proven.
Speaker 1: But then they're part of like he's controlling this with
Speaker 1: his mind. That's the stuff that's sort of like. But
Speaker 1: it's interesting. It's interesting nevertheless, I guess.
Speaker 2: Yeah, on my picks.
Speaker 3: The thing that I've been playing with a lot recently
Speaker 3: is this new game that just came out just a
Speaker 3: few days ago called Fall Guys.
Speaker 2: I don't know if you've heard of this.
Speaker 3: The it's on Steam and it's the PlayStation game of
Speaker 3: the Month pre game of the Month, and it is ridiculous.
Speaker 3: It's like a Battle Royale game but cross with like
Speaker 3: Mario Party mini games, and it brings out the best
Speaker 3: and worst in people.
Speaker 2: But it's insane.
Speaker 3: It's so much fun, and it's a relatively small developer
Speaker 3: that's built it, and I imagine that their servers are
Speaker 3: getting hammered right now. But it's an insanely fun game.
Speaker 3: But yeah, apart from that, I don't get much time
Speaker 3: to do hobbies and side things at the moment. But
Speaker 3: my fun pick at the moment is this weird scene
Speaker 3: called the console portabilizing scene. And if you're I come
Speaker 3: from a gaming background, I'm a big gamer. But there's
Speaker 3: this huge scene of people who take games consoles and
Speaker 3: then chop them up and make them portable. And so
Speaker 3: my little side hobby has been taking Nintendo Wheeze, chopping
Speaker 3: them up and making them into like game Boy form
Speaker 3: factor and things like that.
Speaker 2: So that's my other little pig little side hobby.
Speaker 1: That could be a lot of fun I've wanted before,
Speaker 1: because like the virtual console type stuff is, it's it's fun,
Speaker 1: but it's not quite the same as like holding the
Speaker 1: actual thing in your hand. Like there you get a
Speaker 1: nostalgia over time of like, man, I really like there's
Speaker 1: something that kicks in when you just hold like an
Speaker 1: old Sega Genesis or Super Nintendo or any s controller.
Speaker 1: It's just like I don't know if it's just nostalgia
Speaker 1: or what it is, but it's it's different than just
Speaker 1: playing it virtually. So it's pretty cool.
Speaker 3: Yeah, you want to sit down and actually complete the
Speaker 3: games rather than just like I found with emulators and things,
Speaker 3: you'd pull them up and just go through ten games
Speaker 3: and say, oh, that was interesting, next game, rather than
Speaker 3: sitting down and having that arch experience.
Speaker 1: Yeah yeah, Well James, this has been a great chat.
Speaker 1: I think my last question for you is where can
Speaker 1: people find you if they want to, you know, ask
Speaker 1: any further questions follow all of what you do.
Speaker 3: I'm on Twitter at loop j l OOPJ. I'm not
Speaker 3: super active on there. I'm trying to get back into it,
Speaker 3: and then I'm kind of relatively active on the conference
Speaker 3: and speaking scene as well, So catch check out my
Speaker 3: Twitter or bugs next Twitter to see which conference I'm
Speaker 3: that next. But I do talk a lot about technical
Speaker 3: debt on the conference scene, So if you're around and
Speaker 3: you see me, drop in and I'll say.
Speaker 1: Hi, awesome. Well, thanks again for joining us. It's been
Speaker 1: another episode of React round It, so have a good
Speaker 1: run everyone.
Speaker 2: THANKSDJ.