/Phil Booth

Some Useful, Non-Obvious Postgres Patterns tl;dr: Several PostgreSQL patterns that might not be immediately obvious to many developers including: (1) Always define explicit ON DELETE semantics. (2) If in doubt, use ON DELETE SET NULL. (3) Mutually exclusive columns. (4) Prohibit hidden nulls in jsonb columns. (5) Declare your updated\_at columns NOT NULL to make sorting easier.

featured in #446

Four Ways To Shoot Yourself In The Foot With Redis tl;dr: Phil shares lessons learned from production outages caused by misusing Redis. They highlight the importance of handling concurrency by sharding data across multiple instances, avoiding long-running operations in scripts, setting memory usage alerts, and using the appropriate Redis abstractions. Serializing objects to JSON for storage is discouraged, and understanding tradeoffs between data structures can prevent future issues.

featured in #435

Six Ways To Shoot Yourself In The Foot With Healthchecks 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 #419

How To Evaluate Dependencies 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.”

featured in #417

Nine Ways To Shoot Yourself In The Foot With PostgreSQL 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.

featured in #409

How To Debug 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.

featured in #384