What Is Device Fingerprinting And How Does It Work?
- Zack Proser tl;dr: “Every time a device connects to your server, it broadcasts a wealth of information through its browser. Some of these signals are obvious, while others are subtle technical artifacts of how browsers and hardware work together.” Zack breaks down what servers can see and how to mitigate bad actors.featured in #592
Patterns For Building Realtime Features
- Zak Knill tl;dr: “These patterns rely on a connection between the client and the server, where the server can notify the client of some data. This connection could be websockets, sse, event-streams, or polling (long or short). The connection just needs to allow the server to send data to the client without the client knowing that there is new data.”featured in #590
Summarizing Our Recommendations For Software Documentation
- Nicole Tietz-Sokolskaya tl;dr: A software engineer and anthropologist conducted a case study on engineering documentation practices. Their key recommendations include starting with high-level docs, implementing design reviews, considering audience needs, maintaining docs as part of workflow, and documenting test plans. The study involved literature review and engineer interviews, revealing how documentation practices reflect and reinforce company values.featured in #589
featured in #588
How To (And How Not To) Design REST APIs
- Jeff Schnitzer tl;dr: "In my career, I have consumed hundreds of REST APIs and produced dozens. Since I often see the same mistakes repeated in API design, I thought it might be nice to write down a set of best practices. And poke fun at a couple widely-used APIs. Much of this may be "duh", but there might be a few rules you haven't considered yet."featured in #588
How To Write A Good Design Document
- Grant Slatton tl;dr: “Think of a design document like a proof in mathematics. The goal of a proof is to convince the reader that the theorem is true. The goal of a design document is to convince the reader the design is optimal given the situation. The most important person to convince is the author. The act of writing a design document helps to add rigor to what are otherwise vague intuitions. Writing reveals how sloppy your thinking was.”featured in #587
Don't Make These Feature Flag Mistakes
- Ian Vanagas tl;dr: As I’ll reveal shortly, badly managed flags have caused huge outages, a mountain of tech debt and, on one infamous occasion, almost bankrupted a company. Typically, this happens because: (1) Complexity creates confusion. Embedded and interlinked flags create many potential states that can quickly become untestable and unpredictable. (2) Poor maintainability creates tech debt. Old “zombie” flags get reused in unintended ways, or negatively react with new changes. Ian shares how you can avoid these problems.featured in #587
How To (And How Not To) Design REST APIs
- Jeff Schnitzer tl;dr: "In my career, I have consumed hundreds of REST APIs and produced dozens. Since I often see the same mistakes repeated in API design, I thought it might be nice to write down a set of best practices. And poke fun at a couple widely-used APIs. Much of this may be "duh", but there might be a few rules you haven't considered yet."featured in #587
featured in #585
Logging, The Sensible Defaults
- Daniel Gerlach tl;dr: “I often encounter codebases with lousy logging practices. This manifests itself in useless logging missing context or in over-logging thereby bringing down the whole system. People often forget that logging is expensive. In the following I want to list the most important logging traits for modern cloud native applications.”featured in #577