Developing for a Hostile Environment

[00:00:00]
>> So let's move on to our last section designed for debug ability. This is a little bit of me restating some of the things about how to fix bugs, And some of my opinions on how to do things. So feel free to argue with me and let's have a debate.

[00:00:18]
This is one of my favorite quotes. The web is the most hostile software engineering environment imaginable By, I guess, fellow front end masters teacher, that's weird. He's one of your first teachers, right? Anyway, I've seen multiple videos of him saying this, so I can attribute it to them.

[00:00:44]
The web is the most hostile software engineering environment imaginable. We're writing code in this language that was, frankly and admittedly cobbled together and we keep bolting new things on to it. And we don't just have a single runtime of JavaScript, we have dozens of runtimes of JavaScript. Triton and IE, was it ice monkey, ice weasel, ice something in Mozilla and blink inside of Chrome.

[00:01:15]
The actual pieces of technology inside of the browsers that's executing the JavaScript is different in a different browser and has different quirks and different performance and reliability aspects. And so we're building an application once in a not always ideal language, and shipping it to run in multiple different versions of the runtime that we have no control over which users do it.

[00:01:37]
And they're all doing it across networks that tend to meddle in how things are shipped. And it's obviously incredibly hostile compared to writing towards the developer. Compared to writing in other languages, other languages that might have a more consistent way of thinking and have predictable ways of deploying.

[00:02:00]
And so, this is a core thing that is really frustrating to debugging a lot of JavaScript applications. And so, I think it's important for all applications but especially JavaScript to think about what are some things we can do as we're building our applications to make them easier to understand when something is going wrong and easier to diagnose them because things will go wrong.

[00:02:28]
They'll go wrong in everybody's application, I've never used, I've never worked with a piece of software that I would describe as bug free. It's just whether or not you found them yet. So, I'm gonna kind of break this into the same structure that I did at the beginning.

[00:02:44]
So some ideas on how to better identify, how to better isolate, how to better resolve, and then how to better prevent errors through the design of your application. I started the day with this, which I actually think about this concept a lot is that the earlier you find the bug, the cheaper, and easier, and better it is for everybody involved.

[00:03:08]
So how do you find bugs sooner. How do you make sure that the developer can find the bug first. And that kinda comes with just your own, as you grow up as a developer cuz you become more aware that you're writing bugs all the time. And you only catch some of them.

[00:03:31]
How reliable do you test, do you have monitoring and hopefully you never have to deal with user reports. Monitoring is really the only tool based thing there. Development and testing is about the maturity of you, and your team, and your software development process. But the only tool you can really buy to stick in here is a monitoring, and some of these that you will build, and some of these you will buy.

[00:04:01]
And it depends on what your application is and what your stack does. If you're looking to buy something, I run something that you might be interested in called Track:js, which can help you capture the errors on the front end. But you'll probably want to pair that up with some monitoring that looks at your API performance, and your back ends, and who's doing things.

[00:04:25]
In a really powerful set of tools that has been developed in the last couple of years is from Elastic, their Elastic Search tool, the cabana, reporting engine, and tons and tons of stuff on that where you can build basically an infinitely complex amount of logging tools into their stack and it's relatively easy to report off of it.

[00:04:45]
Track:js itself is actually built on top of elastic search. Getting these tools in place lets you fill that really important gap, that gap between your own maturity, and having an angry customer. Having somebody quit, having somebody ask for a refund, having somebody complain about Twitter about you. Complain on Twitter about you.

[00:05:10]
Monitoring is that last boundary that says even if your processes broke down and you don't, you let a bug slip into production, that you can be the one to know about it first. Once you have something that monitors, you can do all kinds of interesting things. You can instrument for your own priorities.

[00:05:32]
Here's an example. Maybe you want to instrument for how long your page takes to load. Here's how you could do it. Here's a little snippet of code that you would just drop into your page somewhere that says hey, start a timer for 10 seconds, 10 seconds being an arbitrary limit of when you think something bad has happened.

[00:05:53]
After 10 seconds, check some condition if the page is loaded. Is your widget visible? Can the user see their first tweet? Can the user do something? Whatever your app is an indication that they have load it, and if they haven't, track an error, record something that says, here's how many times how many users, an unacceptable level of performance has happened.

[00:06:18]
You can do these with all kinds of different things that can help you understand the critical factors that your users taking your applications.