/Best Practices

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

Build It Yourself

- Armin Ronacher tl;dr: “But there is a simpler path. You write code yourself. Sure, it's more work up front, but once it's written, it's done. No new crates, no waiting for upsteam authors to fix that edge case. If it's broken for you, you fix it yourself. Code that works doesn't necessarily need the maintenance treadmill. Your code has a corner case? Who cares. This is that vibe shift we need in the Rust world: celebrating fewer dependencies rather than more.”

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

Six Ways To Shoot Yourself In The Foot With Healthchecks

- Phil Booth tl;dr: (1) Aggregate other services into your app’s healthcheck. (2) Set a short timeout on healthcheck requests. (3) Set a long timeout on healthcheck requests. (4) Leave a long delay before starting healthchecks on new instances. (5) Set a low threshold on consecutive failures before turning unhealthy. (6) Set a high threshold on consecutive successes before turning health.

featured in #573

How We Choose Technologies

- Ian Vanagas tl;dr: “Our solution is trust and feedback over process and letting product teams own the process from beginning to end. We can't tell you what technologies to use, or the perfect way to pick them, but this is how our company of ~60, remote and async people does it.”

featured in #568

How To Fork: Best Practices And Guide

- Joaquim Rocha tl;dr: “Over the years, my work did sometimes involve maintaining forks of various open-source projects. That’s not the case with my job now, but when a colleague reached out for help with a fork that hadn’t been rebased in ages, it got me thinking that the steps I follow might be useful for other developers too. Hence this article.”

featured in #560

Writing System Software: Code Comments

- Salvatore Sanfilippo tl;dr: “In this post I analyze Redis comments, trying to categorize them. Along the way I try to show why, in my opinion, writing comments is of paramount importance in order to produce good code, that is maintainable in the long run and understandable by others and by the authors during modifications and debugging activities.”

featured in #560

Responsible Engineering Prevents Costly Failures In A Scaling World

- Dr. Panos Patros tl;dr: Dr. Panos Patros, VP of Engineering at Raygun and a seasoned expert in the engineering field, recently wrote an article about the importance of building robust, scalable software by prioritizing quality. 

featured in #558

An Engineer’s Checklist Of Logging Best Practices

- Rox Williams tl;dr: (1) Structure your logs. (2) Consolidate your logs at creation time. (3) Use unique identifiers. (4) Standardize log field names and types on your structured logs. (5) Avoid logging sensitive data. (6) Treat your logs as data. (7) Use a centralized logging management system. (8) Configure log retention. (9) Set up alerts. (10) Document log formats and practices. 

featured in #558

Use Data That Looks Like Data

- Thorsten Ball tl;dr: “Time for me to pass on something I've been practicing for years but haven't found written down somewhere. It's a simple thing. A practical thing. Forged in the trenches. It won't win any contests in which the audience gasps and says "oh, now that is clever." But it’s easy. Simple even. And it can save a lot of time and tears and, at the end of the day, isn't that some of the best stuff? When debugging or testing your program, do not use data that looks like a variable or type name.”

featured in #557