Isolating Errors

[00:00:00]
>> Moving on to how to isolate errors faster, I think the core idea here is simplicity. How do you keep your app as simple as possible? And when I think about the applications that I've worked with that I think of as simple, because simple is such a hard thing to actually define objectively.

[00:00:21]
I tend to think about this paradox of duplication of code and concepts, versus abstraction. A lot of times I create code that I would regard as not simple, because I'm trying to build an abstraction on top of something. jQuery, for example, built all kinds of abstractions on top of dealing with network transmissions.

[00:00:46]
And dealing with finding elements that he thought users didn't have to handle. He wanted to create a abstraction with an easier to understand interface, but the underlying code inside of it is anything but simple. There's tons of archaic things that need to deal with to solve browsers, and lots of duplication of concepts that had to be repeated to solve individual browser quirks.

[00:01:19]
Now, in your code, you're faced with these decisions all the time. When I worked as a consultant, I think I would have this fight with somebody at least once a month. Where you would do something, you would solve problem x, and you'd be really happy with your solution to problem x.

[00:01:35]
And then you would see problem x again, in another part of the codebase. And somebody on your team would be, let's generalize that, we just needed problem x factory somewhere in the code and we can solve anytime problem x occurs ever. But that brings in, its building an abstraction To reduce the duplication of code, but it is damaging the simplicity of your code.

[00:02:06]
It is harder to understand it. A rule that has always served me really, really well, it was first introduced by Martin Fowler in the book Refactoring, is the rule of 3. And so whether you're dealing with a problem, a concept in your code, something you're trying to do, the first time you run into a problem, solve it.

[00:02:26]
The second time you run into the problem, and you're tempted to build an abstraction, don't. Copy and paste your solution and implement it again. The third time you run into the problem, now, you can think about an abstraction. By creating an abstraction for anytime something has happened twice, you're creating a lot of overhead in your code, a lot of unnecessary abstractions, and you're damaging your simplicity.

[00:02:52]
And so this is something that I have always followed in the applications that I've built. Probably a more practical tactical solution, is designing your application for test which is a hardware concept. Has anybody done any hardware work? Designing circuit boards and that sort of stuff? When you're designing a circuit board, you're gonna get it wrong a lot.

[00:03:16]
It's gonna break in all kinds of weird ways with different resistors will burn out or whatever. And so you're gonna need ways on how to test what part broke, you're gonna need access points to know, is my data getting through this thing? Is power going through this correctly?

[00:03:34]
I like taking this concept and using it for software, and I think a good parody is a debug mode. We do all kinds of things about smashing our code together and removing all kinds of access points for the sake of the architecture and security, and performance of the code.

[00:03:51]
But those things all kind of hurt debug-ability at the same time. And so, for many apps that I build, I usually like doing it as this where you can hang like a particular query string off of the URL. The server will use that to serve the debug version of code.

[00:04:08]
Maybe it will serve unmodified assets, maybe it'll serve an additional thing that is a logger that prints out everything that is happening. It depends on what your context is. But think about what are the kind of things that you wish you knew, when you're debugging the kind of problems that your app has?

[00:04:27]
And can you produce a test a debug mode that tells you those sort of things, in a way to optionally turn them on in your application? I tend to think this is one of the things that is well worth its investment, for apps that are going to live more than a year.

[00:04:49]
There's lots of tools out there to help you isolate bugs. We spent a lot of time today in Chrome, Chrome in my opinion has the best JavaScript debugger today. But, you won't have the luxury of being able to spend all your time in Chrome. There will be bugs that you'll run into that will be Firefox specific, or Edge specific, or Safari specific, or Opera specific or whatever.

[00:05:13]
And you're going to need to use the debug tools in those browsers as well. Most of them have the same capabilities presented in slightly different ways, but the more you use them the more adapt you'll get at them. It is tideous to have all of those browsers on your machine and in an operable form all at once.

[00:05:33]
Especially if you have a Mac and you support users that use old version of Internet Explorer. For that, I have a service that I highly recommend called Sauce Labs. Sauce Labs is a remote Selenium testing stack, so if you wanna do real browser testing they provide those services.

[00:05:51]
But you can also spin up machines with arbitrary operating system in browser combinations, really fast. I no longer have virtual machines for different Internet Explorer images on my computer. Because when I have an Internet Explorer bug, I go out to my Sauce Labs account and I spin one up.

[00:06:11]
Super easy, I could probably do one right now if we want. Infact, we will, just because a bunch of people seem kind of perked up and interested. So Sauce Labs, the primary thing that I use Sauce Labs for is automated testing for the track JS JavaScript library. But as part of that you also get automation, so I can create a new automation session that says I want to go to, HTTP on what is wwwfrontendmasters.com.

[00:06:53]
I wanna go to, I guess it's just HTTP, frontendmasters.com. And I wanna do it on, [CROSSTALK]
>> It's HTTPS.
>> Is it?
>> There's no HTTP here.
>> Okay, good, good for you. And I wanna do Internet Explorer 9 with Windows 7, and Start. And this should take just a few minutes, not even a minute.

[00:07:15]
I like that it has some fun messages in there for number three it's hacking the Gibson.
>> BrowserStack is much faster.
>> BrowserStack UI is a lot nicer. I found their virtual machines to be a lot less reliable, which probably doesn't matter for this thing that we're doing right here.

[00:07:35]
It doesn't really matter for these manual testing instances that we're doing right here. But if you're trying to spin up automated, reliable virtual machines for a test suite, it is not so good. We abandoned BrowserStack maybe two years ago. So maybe it's gotten better since then, but my preferred at the moment to Sauce Labs.

[00:07:56]
So here we go, it is about two minutes or so, I was able to spin up an environment. Here I have a fully interactive Internet Explorer 9, with all its horrendous debugging capabilities. I can pop open the DevTools.
>> Are we were doing this when we launch our big sale, all right?

[00:08:16]
Because I could not reproduce the issue, but Brent was having an issue, so we went to BrowserStack.
>> Yep.
>> And the issue was there, it was indeed there to fix it.
>> So Sauce Labs is really helpful for getting access to browsers that you might not have on hand.

[00:08:38]
We played a little bit with Charles Proxy, which is very useful for either debugging live in production, when you want to make changes without really making changes. Or if you just want to intercept a complex system of requests, and make your own changes to it. And then finally, Track JS shows you a bunch of information about how did a bug come to occur.

[00:08:58]
And so it can help point you at which browsers, how many users, what pages is something happening on? Yeah.