Welcome to my PinkLetter. A short, weekly, technology-agnostic, and pink newsletter where we cultivate timeless skills about web development.
> ⚠️ Scared of touching that piece of code?
> 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!)
After going through the entire book, you should be able to:
(Riccardo: This kicks ass. Farhan wrote handbooks for Docker and Kubernetes too!)
There’s a certain class of problems that’s hard to test:
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!)