mirror of
/repos/dotTiddlywiki.git
synced 2025-12-30 07:31:33 +01:00
76 lines
2.4 KiB
Plaintext
76 lines
2.4 KiB
Plaintext
created: 20151008155934019
|
|
creator: user
|
|
modified: 20151009082314453
|
|
modifier: user
|
|
tags:
|
|
title: Programming
|
|
type: text/vnd.tiddlywiki
|
|
|
|
; 12 factor app
|
|
: http://12factor.net
|
|
|
|
; I. Codebase
|
|
: One codebase tracked in revision control, many deploys
|
|
; II. Dependencies
|
|
: Explicitly declare and isolate dependencies
|
|
; III. Config
|
|
: Store config in the environment
|
|
; IV. Backing Services
|
|
: Treat backing services as attached resources
|
|
; V. Build, release, run
|
|
: Strictly separate build and run stages
|
|
; VI. Processes
|
|
: Execute the app as one or more stateless processes
|
|
; VII. Port binding
|
|
: Export services via port binding
|
|
; VIII. Concurrency
|
|
: Scale out via the process model
|
|
; IX. Disposability
|
|
: Maximize robustness with fast startup and graceful shutdown
|
|
; X. Dev/prod parity
|
|
: Keep development, staging, and production as similar as possible
|
|
; XI. Logs
|
|
: Treat logs as event streams
|
|
; XII. Admin processes
|
|
: Run admin/management tasks as one-off processes
|
|
|
|
---
|
|
; The Art of Unix Programming
|
|
: http://catb.org/esr/writings/taoup/html/
|
|
|
|
; Rule of Modularity
|
|
: Write simple parts connected by clean interfaces.
|
|
; Rule of Clarity
|
|
: Clarity is better than cleverness.
|
|
; Rule of Composition
|
|
: Design programs to be connected with other programs.
|
|
; Rule of Separation
|
|
: Separate policy from mechanism; separate interfaces from engines.
|
|
; Rule of Simplicity
|
|
: Design for simplicity; add complexity only where you must.
|
|
; Rule of Parsimony
|
|
: Write a big program only when it is clear by demonstration that nothing else will do.
|
|
; Rule of Transparency
|
|
: Design for visibility to make inspection and debugging easier.
|
|
; Rule of Robustness
|
|
: Robustness is the child of transparency and simplicity.
|
|
; Rule of Representation
|
|
: Fold knowledge into data, so program logic can be stupid and robust.
|
|
; Rule of Least Surprise
|
|
: In interface design, always do the least surprising thing.
|
|
; Rule of Silence
|
|
: When a program has nothing surprising to say, it should say nothing.
|
|
; Rule of Repair
|
|
: Repair what you can — but when you must fail, fail noisily and as soon as possible.
|
|
; Rule of Economy
|
|
: Programmer time is expensive; conserve it in preference to machine time.
|
|
; Rule of Generation
|
|
: Avoid hand-hacking; write programs to write programs when you can.
|
|
; Rule of Optimization
|
|
: Prototype before polishing. Get it working before you optimize it.
|
|
; Rule of Diversity
|
|
: Distrust all claims for one true way.
|
|
; Rule of Extensibility
|
|
: Design for the future, because it will be here sooner than you think.
|
|
|