Keep your screen from falling asleep with the Screen Wake Lock API

Modern applications increasingly interface with lots of external systems — third-party APIs, databases, message queues, etc. In some cases, we may have control over the shape of the data being transmitted, but in other cases we may be at the mercy of something else. If we're not careful, implementation details like the shape of the data and the naming of the fields can permeate throughout our code.

Fully utilizing static types, with all the safety they provide, can be a bit tricky when dealing with dynamic data — like JSON from an API call. Let's look at how to do this in TypeScript.

JavaScript Prototypes can be a mysterious thing, but once you understand them they’re not that complex. Let’s dive in to the seeming complexity and remove some of the mystery.

Destroying your development environment frequently provides a forcing function to ensure that everything is automated, works and prevents manually created state from creeping into your data stores. In this post, I'll share the cost of not doing this as well as tips and code examples to set up your own development environment.

Making HTTP calls to get resources or call APIs is a staple of software development. But if you do not properly abstract the request construction and response handling from the HTTP library that you use, it can be extremely difficult to test.

Getting the size and position of elements in React is not a great story. Each option I researched has at least one gotcha. I'll share the best options I came up with and explain pros and cons of each. First let's take a look at the basic way to get an element's size and position in React.

Favoring stateless functions and pushing I/O the edge of your application can make your code easier to test and reason about.

Node.js is a runtime for javascript that requires asynchronous thinking.

Many teams at Pluralsight use systemd for application process management. When systemd starts a process, it needs to know if the process started successfully. The most simple way to do this is for systemd to wait for a bit after starting the process (perhaps 10 seconds) and simply check that the process is still running. Since you generally can't predict exactly how long your service will take to successfully start up, this is error prone. Furthermore, this method is slow. If you are doing synchronous restarts for a rolling deploy, this adds a lot of time.