after.dev

Week 19, 2019 Imaginary Problems

May 12, 2019

Imaginary Problems Are the Root of Bad Software

When problems are dumb, intelligent individuals will find a way of coping. But imaginary problems aren’t just the result of bored developers.

But imaginary problems aren’t just the result of bored developers. They’re also the result of long chains of communication.

But everyone needs to keep solving the imaginary problems, because if they stop creating and solving these problems, if they start focusing on the real problems, they might realize the whole system is broken. 1

APT not use HTTPS

Accessing mirrors over HTTPS would not prevent a compromised mirror tampering with packages, so APT already has other mechanisms to guard against this. Files obtained by APT are accompanied by their own signature which allows your system to check they originated from your distribution. These signatures are checked against a small set of trusted keys already stored on your computer. 2

我为什么讨厌 Java

因為它太容易了。它用優異的語言特性和工具生態,把門檻設置得無可再低。 我還是把自己當成一個手藝人,所以我討厭Java. 3

The Twelve-Factor App

  1. One codebase tracked in revision control, many deploys
  2. Explicitly declare and isolate dependencies
  3. Store config in the environment
  4. Treat backing services as attached resources
  5. Strictly separate build and run stages
  6. Execute the app as one or more stateless processes
  7. Export services via port binding
  8. Scale out via the process model
  9. Maximize robustness with fast startup and graceful shutdown
  10. Keep development, staging, and production as similar as possible
  11. Treat logs as event streams
  12. Run admin/management tasks as one-off processes 4

Nesting resources

Rule of thumb: resources should never be nested more than 1 level deep. A collection may need to be scoped by its parent, but a specific member can always be accessed directly by an id, and shouldn’t need scoping (unless the id is not unique, for some reason). 5