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.
tl;dr:“One of my stock interview questions goes: "When picking between dependencies to use in production, what factors contribute to your decision?" I'm surprised by how often I receive an answer along the lines of "Github stars" and not much else. I happen to think Github stars is a terrible metric for selecting production code, so this post sets out my idea of a healthier framework to evaluate dependencies.”
tl;dr:(1) Keep the default value for work\_mem. (2) Push application logic into Postgres functions and procedures. (3) Use lots of triggers. (4) Use NOTIFY heavily. And more.
tl;dr:These steps are not specific to a particular language or paradigm, Phil's explains each of the following debugging steps: (1) Reproduce the bug. (2) Reproduce it again. (3) Don't reproduce it. (4) Understand the code. (5) Observe state. (6) Write down what you (think you) know. (7) Rule things out. (8) Walk the dog. (9) Rewrite a component. (10) Write a failing test case. (11) Fix it.