PinkLetter - You Probably Have Something More Important to Do

Welcome to my PinkLetter. A short, weekly, technology-agnostic, and pink newsletter where we cultivate timeless skills about web development.

My Ramblings This Week

On Twitter, I shared a couple of questions:

> ⚠️ Scared of touching that piece of code?

and

> If no user finds that 🐞, is it still a bug?

You know, a scary piece of code or a bug are not necessarily a problem.

I’m ready to bet there’s at least one messy corner in the codebase you are working on. Not to count all the issues you are not even aware of.

Before firing up the editor to fix them, ask yourself: will I need to touch this scary code again? Or, is the cost of fixing this bug justified?

If the answer is no, then you probably have something more important to work on.

(Even if the craft master inside of you would love to spend time on making that code better!)

Elsewhere on the Web

The NGINX Handbook by Farhan Hasin Chowdhury

After going through the entire book, you should be able to:

• Understand configuration files generated by popular tools as well as those found in various documentation.
• Configure NGINX as a web server, a reverse proxy server, and a load balancer from scratch.
• Optimize NGINX to get maximum performance out of your server.

(Riccardo: This kicks ass. Farhan wrote handbooks for Docker and Kubernetes too!)

CROSS-BRANCH TESTING by Hillel Wayne

There’s a certain class of problems that’s hard to test:

1. The output isn’t obviously inferable from the input. The code isn’t just solving a human-tractable problem really quickly, it’s doing something where we don’t know the answer without running the program.
2. The output doesn’t have “mathematical” properties, like invertibility or commutativity.
3. Errors in the function can be “subtle”: there can be a bug that affects only a small subset of possible inputs, so that a set of individual test examples would still be correct.

Getting started with WebRTC

The WebRTC standard covers, on a high level, two different technologies: media capture devices and peer-to-peer connectivity.

Media capture devices includes video cameras and microphones, but also screen capturing “devices”. For cameras and microphones, we use navigator.mediaDevices.getUserMedia() to capture MediaStreams. For screen recording, we use navigator.mediaDevices.getDisplayMedia() instead.

The peer-to-peer connectivity is handled by the RTCPeerConnection interface. This is the central point for establishing and controlling the connection between two peers in WebRTC.

(Riccardo: I’m considering using WebRTC for a mini–side-project. Stay tuned!)