mirror of
https://github.com/dwmkerr/hacker-laws.git
synced 2025-12-17 20:55:02 +01:00
Merge branch 'staging' into patch-1
This commit is contained in:
2
.github/workflows/build-on-pull-request.yaml
vendored
2
.github/workflows/build-on-pull-request.yaml
vendored
@@ -36,7 +36,7 @@ jobs:
|
||||
name: hacker-laws.pdf
|
||||
path: hacker-laws.pdf
|
||||
|
||||
- name: Publish Intermiediate Markdown Artifact
|
||||
- name: Publish Intermediate Markdown Artifact
|
||||
uses: actions/upload-artifact@master
|
||||
with:
|
||||
name: hacker-laws.md
|
||||
|
||||
218
README.md
218
README.md
@@ -10,75 +10,79 @@ Like this project? Please considering [sponsoring me](https://github.com/sponsor
|
||||
|
||||
<!-- vim-markdown-toc GFM -->
|
||||
|
||||
* [Introduction](#introduction)
|
||||
* [Laws](#laws)
|
||||
* [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
|
||||
* [Ninety–Ninety Rule](#ninetyninety-rule)
|
||||
* [Amdahl's Law](#amdahls-law)
|
||||
* [The Broken Windows Theory](#the-broken-windows-theory)
|
||||
* [Brooks' Law](#brooks-law)
|
||||
* [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
|
||||
* [Conway's Law](#conways-law)
|
||||
* [Cunningham's Law](#cunninghams-law)
|
||||
* [Dunbar's Number](#dunbars-number)
|
||||
* [The Dunning-Kruger Effect](#the-dunning-kruger-effect)
|
||||
* [Fitts' Law](#fitts-law)
|
||||
* [Gall's Law](#galls-law)
|
||||
* [Goodhart's Law](#goodharts-law)
|
||||
* [Hanlon's Razor](#hanlons-razor)
|
||||
* [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
|
||||
* [Hofstadter's Law](#hofstadters-law)
|
||||
* [Hutber's Law](#hutbers-law)
|
||||
* [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
|
||||
* [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
|
||||
* [Kernighan's Law](#kernighans-law)
|
||||
* [Linus's Law](#linuss-law)
|
||||
* [Metcalfe's Law](#metcalfes-law)
|
||||
* [Moore's Law](#moores-law)
|
||||
* [Murphy's Law / Sod's Law](#murphys-law--sods-law)
|
||||
* [Occam's Razor](#occams-razor)
|
||||
* [Parkinson's Law](#parkinsons-law)
|
||||
* [Premature Optimization Effect](#premature-optimization-effect)
|
||||
* [Putt's Law](#putts-law)
|
||||
* [Reed's Law](#reeds-law)
|
||||
* [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
|
||||
* [The Law of Demeter](#the-law-of-demeter)
|
||||
* [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
|
||||
* [The Law of the Instrument](#the-law-of-the-instrument)
|
||||
* [The Law of Triviality](#the-law-of-triviality)
|
||||
* [The Unix Philosophy](#the-unix-philosophy)
|
||||
* [The Scout Rule](#the-scout-rule)
|
||||
* [The Spotify Model](#the-spotify-model)
|
||||
* [The Two Pizza Rule](#the-two-pizza-rule)
|
||||
* [Wadler's Law](#wadlers-law)
|
||||
* [Wheaton's Law](#wheatons-law)
|
||||
* [Principles](#principles)
|
||||
* [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
|
||||
* [Chesterton's Fence](#chestertons-fence)
|
||||
* [The Dead Sea Effect](#the-dead-sea-effect)
|
||||
* [The Dilbert Principle](#the-dilbert-principle)
|
||||
* [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
|
||||
* [The Shirky Principle](#the-shirky-principle)
|
||||
* [The Peter Principle](#the-peter-principle)
|
||||
* [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
|
||||
* [SOLID](#solid)
|
||||
* [The Single Responsibility Principle](#the-single-responsibility-principle)
|
||||
* [The Open/Closed Principle](#the-openclosed-principle)
|
||||
* [The Liskov Substitution Principle](#the-liskov-substitution-principle)
|
||||
* [The Interface Segregation Principle](#the-interface-segregation-principle)
|
||||
* [The Dependency Inversion Principle](#the-dependency-inversion-principle)
|
||||
* [The DRY Principle](#the-dry-principle)
|
||||
* [The KISS principle](#the-kiss-principle)
|
||||
* [YAGNI](#yagni)
|
||||
* [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
|
||||
* [Reading List](#reading-list)
|
||||
* [Online Resources](#online-resources)
|
||||
* [PDF eBook](#pdf-ebook)
|
||||
* [Podcast](#podcast)
|
||||
* [Translations](#translations)
|
||||
* [Related Projects](#related-projects)
|
||||
* [Contributing](#contributing)
|
||||
* [TODO](#todo)
|
||||
- [Introduction](#introduction)
|
||||
- [Laws](#laws)
|
||||
- [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
|
||||
- [Amdahl's Law](#amdahls-law)
|
||||
- [The Broken Windows Theory](#the-broken-windows-theory)
|
||||
- [Brooks' Law](#brooks-law)
|
||||
- [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
|
||||
- [Clarke's three laws](#clarkes-three-laws)
|
||||
- [Conway's Law](#conways-law)
|
||||
- [Cunningham's Law](#cunninghams-law)
|
||||
- [Dunbar's Number](#dunbars-number)
|
||||
- [The Dunning-Kruger Effect](#the-dunning-kruger-effect)
|
||||
- [Fitts' Law](#fitts-law)
|
||||
- [Gall's Law](#galls-law)
|
||||
- [Goodhart's Law](#goodharts-law)
|
||||
- [Hanlon's Razor](#hanlons-razor)
|
||||
- [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
|
||||
- [Hofstadter's Law](#hofstadters-law)
|
||||
- [Hutber's Law](#hutbers-law)
|
||||
- [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
|
||||
- [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
|
||||
- [Input-Process-Output (IPO)](#input-process-output-ipo)
|
||||
- [Kernighan's Law](#kernighans-law)
|
||||
- [Linus's Law](#linuss-law)
|
||||
- [Metcalfe's Law](#metcalfes-law)
|
||||
- [Moore's Law](#moores-law)
|
||||
- [Murphy's Law / Sod's Law](#murphys-law--sods-law)
|
||||
- [Occam's Razor](#occams-razor)
|
||||
- [Parkinson's Law](#parkinsons-law)
|
||||
- [Premature Optimization Effect](#premature-optimization-effect)
|
||||
- [Putt's Law](#putts-law)
|
||||
- [Reed's Law](#reeds-law)
|
||||
- [The Ringelmann Effect](#the-ringelmann-effect)
|
||||
- [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
|
||||
- [The Law of Demeter](#the-law-of-demeter)
|
||||
- [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
|
||||
- [The Law of the Instrument](#the-law-of-the-instrument)
|
||||
- [The Law of Triviality](#the-law-of-triviality)
|
||||
- [The Unix Philosophy](#the-unix-philosophy)
|
||||
- [The Scout Rule](#the-scout-rule)
|
||||
- [The Spotify Model](#the-spotify-model)
|
||||
- [The Two Pizza Rule](#the-two-pizza-rule)
|
||||
- [Twyman's law](#twymans-law)
|
||||
- [Wadler's Law](#wadlers-law)
|
||||
- [Wheaton's Law](#wheatons-law)
|
||||
- [Principles](#principles)
|
||||
- [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
|
||||
- [Chesterton's Fence](#chestertons-fence)
|
||||
- [The Dead Sea Effect](#the-dead-sea-effect)
|
||||
- [The Dilbert Principle](#the-dilbert-principle)
|
||||
- [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
|
||||
- [The Shirky Principle](#the-shirky-principle)
|
||||
- [The Peter Principle](#the-peter-principle)
|
||||
- [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
|
||||
- [SOLID](#solid)
|
||||
- [The Single Responsibility Principle](#the-single-responsibility-principle)
|
||||
- [The Open/Closed Principle](#the-openclosed-principle)
|
||||
- [The Liskov Substitution Principle](#the-liskov-substitution-principle)
|
||||
- [The Interface Segregation Principle](#the-interface-segregation-principle)
|
||||
- [The Dependency Inversion Principle](#the-dependency-inversion-principle)
|
||||
- [The DRY Principle](#the-dry-principle)
|
||||
- [The KISS principle](#the-kiss-principle)
|
||||
- [YAGNI](#yagni)
|
||||
- [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
|
||||
- [The Principle of Least Astonishment](#the-principle-of-least-astonishment)
|
||||
- [Reading List](#reading-list)
|
||||
- [Online Resources](#online-resources)
|
||||
- [PDF eBook](#pdf-ebook)
|
||||
- [Podcast](#podcast)
|
||||
- [Translations](#translations)
|
||||
- [Related Projects](#related-projects)
|
||||
- [Contributing](#contributing)
|
||||
- [TODO](#todo)
|
||||
|
||||
<!-- vim-markdown-toc -->
|
||||
|
||||
@@ -197,6 +201,18 @@ See also:
|
||||
- [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
|
||||
- [PACELC](#TODO)
|
||||
|
||||
### Clarke's three laws
|
||||
|
||||
[Clarke's three laws on Wikipedia](https://en.wikipedia.org/wiki/Clarke's_three_laws)
|
||||
|
||||
Arthur C. Clarke, an british science fiction writer, formulated three adages that are known as Clarke's three laws. The third law is the best known and most widely cited.
|
||||
|
||||
These so-called laws are:
|
||||
- When a distinguished but elderly scientist states that something is possible, they are almost certainly right. When they state that something is impossible, they are very probably wrong.
|
||||
- The only way of discovering the limits of the possible is to venture a little way past them into the impossible.
|
||||
- Any sufficiently advanced technology is indistinguishable from magic.
|
||||
|
||||
|
||||
### Conway's Law
|
||||
|
||||
[Conway's Law on Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)
|
||||
@@ -403,6 +419,24 @@ See also:
|
||||
- [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
|
||||
- [XKCD 1172](https://xkcd.com/1172/)
|
||||
|
||||
### Input-Process-Output (IPO)
|
||||
|
||||
[Input–Process–Output on Wikipedia](https://en.wikipedia.org/wiki/IPO_model)
|
||||
|
||||
Systems can be incredibly complex, but can typically be broken down into smaller parts that follow a simple pattern:
|
||||
|
||||
1. Input is provided
|
||||
2. Some kind of processing or transformation is performed
|
||||
3. Output is returned
|
||||
|
||||
A sort function in a programming language or system could be a classic example of the IPO pattern; where arbitrary input is sorted based on a predicate and returned back. A web server could be modelled as an IPO system, where HTTP requests are transformed into HTTP responses. A highly complex Generative AI system could likewise be modelled in this way, with user input being passed through a complex model and a response being generated.
|
||||
|
||||
The IPO pattern is present in different forms across almost all technological domains, from [functional programming](https://en.wikipedia.org/wiki/Functional_programming) languages that explicitly follow IPO patterns to [The Unix Philosophy](#the-unix-philosophy), which suggests that highly complex systems can be built by chaining together many simple IPO programs.
|
||||
|
||||
See also:
|
||||
|
||||
- [The Unix Philosophy](#the-unix-philosophy)
|
||||
|
||||
### Kernighan's Law
|
||||
|
||||
> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
|
||||
@@ -513,7 +547,7 @@ See also:
|
||||
|
||||
### Premature Optimization Effect
|
||||
|
||||
[Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
|
||||
[Premature Optimization on WikiWeb](http://wiki.c2.com/?PrematureOptimization)
|
||||
|
||||
> Premature optimization is the root of all evil.
|
||||
>
|
||||
@@ -554,6 +588,15 @@ See also:
|
||||
- [Metcalfe's Law](#metcalfes-law)
|
||||
- [Dunbar's Number](#dunbars-number)
|
||||
|
||||
### The Ringelmann Effect
|
||||
|
||||
[The Ringelmann effect on Wikipedia](https://en.wikipedia.org/wiki/Ringelmann_effect)
|
||||
|
||||
The Ringelmann Effect is the tendency of an individual to become increasingly inefficient as more and more people are involved in a task. In other words, as more individuals are added to a team, the more the average individual performance decreases. Multiple causes are believed to be at work, including loss of motivation ("[social loafing](https://en.wikipedia.org/wiki/Social_loafing)") and challenges related to coordination.
|
||||
|
||||
See also:
|
||||
- [Brooks' Law](#brooks-law)
|
||||
|
||||
### The Law of Conservation of Complexity (Tesler's Law)
|
||||
|
||||
[The Law of Conservation of Complexity on Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
|
||||
@@ -679,6 +722,18 @@ The number of links between people can be expressed as `n(n-1)/2` where n = numb
|
||||
|
||||
<img width="200px" alt="Complete graph; Links between people" src="./images/complete_graph.png" />
|
||||
|
||||
### Twyman's law
|
||||
|
||||
[Twyman's Law on Wikipedia](https://en.wikipedia.org/wiki/Twyman%27s_law)
|
||||
|
||||
> The more unusual or interesting the data, the more likely they are to have been the result of an error of one kind or another.
|
||||
|
||||
This law suggests that when there are particularly unusual data points, it is more likely that they are the result of errors or manipulation. For example, if a dataset of long-jump results from a sporting event showed a maximum value of 20 meters (more than twice the world record), it is more likely to be due to an error (such as recording a value in feet rather than meters) than due to an unusually long jump. It is also more likely in this case that the results could have been manipulated.
|
||||
|
||||
See also:
|
||||
|
||||
- [Sagan Standard](#TODO)
|
||||
|
||||
### Wadler's Law
|
||||
|
||||
[Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
|
||||
@@ -841,7 +896,6 @@ See Also:
|
||||
|
||||
- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
|
||||
|
||||
|
||||
### SOLID
|
||||
|
||||
This is an acronym, which refers to:
|
||||
@@ -947,7 +1001,7 @@ See also:
|
||||
|
||||
> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
|
||||
|
||||
DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
|
||||
DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
|
||||
|
||||
> The opposite of DRY would be _WET_ (Write Everything Twice or We Enjoy Typing).
|
||||
|
||||
@@ -955,7 +1009,7 @@ In practice, if you have the same piece of information in two (or more) differen
|
||||
|
||||
See also:
|
||||
|
||||
- [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
|
||||
- [The Pragmatic Programmer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
|
||||
|
||||
### The KISS principle
|
||||
|
||||
@@ -1015,6 +1069,22 @@ See also:
|
||||
- [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi
|
||||
on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
|
||||
|
||||
### The Principle of Least Astonishment
|
||||
|
||||
[The Principle of Least Astonishment on Wikipedia](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)
|
||||
|
||||
> People are part of the system. The design should match the user's experience, expectations, and mental models.
|
||||
>
|
||||
> Frans Kaashoek
|
||||
|
||||
This principle proposes that systems and interfaces should be designed in a way that features and functionality is easily discovered and matches users expectations. Features that 'surprise' users should be discouraged in favour of features that can be intuitively reasoned about based on existing patterns and practices.
|
||||
|
||||
Many examples are present in user interfaces, such as a 'pull down' gesture on a mobile appliation to refresh content. Another example would be command line tools, where many standards exist for how parameters are named, common parameters that should be available and so on.
|
||||
|
||||
See also:
|
||||
|
||||
- [Convention Over Configuration](#todo)
|
||||
|
||||
## Reading List
|
||||
|
||||
If you have found these concepts interesting, you may enjoy the following books.
|
||||
@@ -1052,6 +1122,7 @@ Thanks to a number of wonderful contributors, Hacker Laws is available in a numb
|
||||
|
||||
| Language | Moderator | Status |
|
||||
|----------|-----------|--------|
|
||||
| [AR Arabic / Arabic](./translations/ar-AR.md) | [Abdurrahman Rajab - a0m0rajab](https://github.com/a0m0rajab) | . |
|
||||
| [🇮🇩 Bahasa Indonesia / Indonesian](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [](https://gitlocalize.com/repo/2513/id?utm_source=badge) |
|
||||
| [🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn), [Leonardo Costa](https://github.com/leofc97) | [](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) |
|
||||
| [🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partially complete |
|
||||
@@ -1062,6 +1133,7 @@ Thanks to a number of wonderful contributors, Hacker Laws is available in a numb
|
||||
| [🇯🇵 JP 日本語 / Japanese](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)| [](https://gitlocalize.com/repo/2513/ja?utm_source=badge) |
|
||||
| [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partially complete |
|
||||
| [🇱🇻 Latviešu Valoda / Latvian](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [](https://gitlocalize.com/repo/2513/lv?utm_source=badge) |
|
||||
| [🇮🇷 فارسی / Persian](./translations/fa.md) | [MohammadErfan Gooneh](https://github.com/MEgooneh) | . |
|
||||
| [🇵🇱 Polski / Polish](./translations/pl.md) | [Mariusz Kogen](https://github.com/k0gen) | [](https://gitlocalize.com/repo/2513/pl?utm_source=badge) |
|
||||
| [🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partially complete |
|
||||
| [🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partially complete |
|
||||
|
||||
@@ -1,42 +1,32 @@
|
||||
#!/usr/bin/env bash
|
||||
# This script prepares a `hacker-laws.md` file which is in a format ready to be
|
||||
# exported to PDF or other formats for an e-book.
|
||||
# This script prepares a `hacker-laws.md` file for export to PDF or e-book format.
|
||||
|
||||
# Require that we provide the version number and get a date.
|
||||
# Require a version number and get the current date.
|
||||
version=$1
|
||||
date=$(date "+%Y-%m-%d")
|
||||
|
||||
if [ -z $version ]; then
|
||||
echo "version must be specified: ./prepare-markdown-for-ebook.sh <version>"
|
||||
if [ -z "$version" ]; then
|
||||
echo "Usage: $0 <version>"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Create the frontmatter.
|
||||
cat << EOF > frontmatter.md
|
||||
# Create `hacker-laws.md` with frontmatter and README content in one step.
|
||||
cat << EOF > hacker-laws.md
|
||||
---
|
||||
title: "Hacker Laws"
|
||||
author: "Dave Kerr, github.com/dwmkerr/hacker-laws"
|
||||
subtitle: "Laws, Theories, Principles and Patterns that developers will find useful. ${version}, ${date}."
|
||||
subtitle: "Laws, Theories, Principles, and Patterns that developers will find useful. ${version}, ${date}."
|
||||
---
|
||||
|
||||
EOF
|
||||
cat README.md >> hacker-laws.md
|
||||
|
||||
# Combine the frontmatter and the laws.
|
||||
cat frontmatter.md README.md >> hacker-laws.md
|
||||
# Use a single `sed` command to clean up unwanted lines and emojis in one pass.
|
||||
sed -i'' -e '/💻📖.*/d' \
|
||||
-e 's/❗/Warning/g' \
|
||||
-e '/^\[Translations.*/d' \
|
||||
-e '/\*.*/d' \
|
||||
-e '/ \*.*/d' \
|
||||
-e '/## Translations/,$d' hacker-laws.md
|
||||
|
||||
# Remove the title - we have it in the front-matter of the doc, so it will
|
||||
# automatically be added to the PDF.
|
||||
sed -i'' '/💻📖.*/d' hacker-laws.md
|
||||
|
||||
# We can't have emojis in the final content with the PDF generator we're using.
|
||||
sed -i'' 's/❗/Warning/' hacker-laws.md
|
||||
|
||||
# Now rip out the translations line.
|
||||
sed -i'' '/^\[Translations.*/d' hacker-laws.md
|
||||
|
||||
# # Now rip out any table of contents items.
|
||||
sed -i'' '/\*.*/d' hacker-laws.md
|
||||
sed -i'' '/ \*.*/d' hacker-laws.md
|
||||
|
||||
# Delete everything from 'Translations' onwards (we don't need the translations
|
||||
# lists, related projects, etc).
|
||||
sed -i'' '/## Translations/,$d' hacker-laws.md
|
||||
echo "hacker-laws.md prepared successfully."
|
||||
|
||||
@@ -499,7 +499,7 @@ Les principes sont généralement des lignes directrices liés à la conception.
|
||||
> Les entreprises tendent à promouvoir systématiquement les employés incompétents afin de les sortir du workflow.
|
||||
> *Scott Adams*
|
||||
|
||||
Un concept de gestion inventé par Scott Adams (créateur du comic strip Dilbert) inspiré par le [principe de Peter](#principe-de-peter). Suivant le principe de Dilbert, les employés qui n'ont jamais montré de compétence dans leur travail sont promus à des postes de management afin de limité les dommages qu'ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et élabora le concept dans son livre de 1996: [The Dilbert Principle](#a-lire).
|
||||
Un concept de gestion inventé par Scott Adams (créateur du comic strip Dilbert) inspiré par le [principe de Peter](#principe-de-peter). Suivant le principe de Dilbert, les employés qui n'ont jamais montré de compétence dans leur travail sont promus à des postes de management afin de limiter les dommages qu'ils peuvent causer. Adams expliqua initialement le principe dans un article du Wall Street Journal datant de 1995, et élabora le concept dans son livre de 1996: [The Dilbert Principle](#a-lire).
|
||||
|
||||
Voir aussi :
|
||||
|
||||
|
||||
@@ -10,73 +10,73 @@ Podoba Ci się ten projekt? Proszę rozważyć [sponsorowanie mnie](https://gith
|
||||
|
||||
<!-- vim-markdown-toc GFM -->
|
||||
|
||||
- [Wstęp](#introduction)
|
||||
- [Prawa](#laws)
|
||||
- [Wstęp](#wstęp)
|
||||
- [Prawa](#prawa)
|
||||
- [Zasada 90-9-1 (zasada 1%)](#zasada-90-9-1-zasada-1)
|
||||
- [Prawo Amdahla](#amdahls-law)
|
||||
- [Teoria zepsutych okien](#the-broken-windows-theory)
|
||||
- [Prawo Brooksa](#brooks-law)
|
||||
- [Twierdzenie CAP (Twierdzenie Brewera)](#cap-theorem-brewers-theorem)
|
||||
- [Prawo Conwaya](#conways-law)
|
||||
- [Prawo Cunninghama](#cunninghams-law)
|
||||
- [Numer Dunbara](#dunbars-number)
|
||||
- [Efekt Dunninga-Krugera](#the-dunning-kruger-effect)
|
||||
- [Prawo Fittsa](#fitts-law)
|
||||
- [Prawo Galla](#galls-law)
|
||||
- [Prawo Goodharta](#goodharts-law)
|
||||
- [Brzytwa Hanlona](#hanlons-razor)
|
||||
- [Prawo Hicka (Prawo Hicka-Hymana)](#hicks-law-hick-hyman-law)
|
||||
- [Prawo Hofstadtera](#hofstadters-law)
|
||||
- [Prawo Hutbera](#hutbers-law)
|
||||
- [Cykl szumu i prawo Amary](#the-hype-cycle--amaras-law)
|
||||
- [Prawo Hyruma (prawo niejawnych interfejsów)](#hyrums-law-the-law-of-implicit-interfaces)
|
||||
- [Prawo Kernighana](#kernighans-law)
|
||||
- [Prawo Linusa](#linuss-law)
|
||||
- [Prawo Metcalfego](#metcalfes-law)
|
||||
- [prawo Moore'a](#moores-law)
|
||||
- [Prawo Murphy'ego / Prawo Soda](#murphys-law--sods-law)
|
||||
- [Brzytwa Ockhama](#occams-razor)
|
||||
- [Prawo Parkinsona](#parkinsons-law)
|
||||
- [Przedwczesny efekt optymalizacji](#premature-optimization-effect)
|
||||
- [Prawo Putta](#putts-law)
|
||||
- [Prawo Reeda](#reeds-law)
|
||||
- [Prawo zachowania złożoności (prawo Teslera)](#the-law-of-conservation-of-complexity-teslers-law)
|
||||
- [Prawo Demeter](#the-law-of-demeter)
|
||||
- [Prawo nieszczelnych abstrakcji](#the-law-of-leaky-abstractions)
|
||||
- [Prawo trywialności](#the-law-of-triviality)
|
||||
- [Filozofia Uniksa](#the-unix-philosophy)
|
||||
- [Zasada Skauta](#the-scout-rule)
|
||||
- [Model Spotify](#the-spotify-model)
|
||||
- [Zasada dwóch pizzy](#the-two-pizza-rule)
|
||||
- [Prawo Wadlera](#wadlers-law)
|
||||
- [Prawo Wheatona](#wheatons-law)
|
||||
- [Zasady](#principles)
|
||||
- [Wszystkie modele są błędne (prawo George'a Boxa)](#all-models-are-wrong-george-boxs-law)
|
||||
- [Płot Chestertona](#chestertons-fence)
|
||||
- [Efekt Morza Martwego](#the-dead-sea-effect)
|
||||
- [Zasada Dilberta](#the-dilbert-principle)
|
||||
- [Zasada Pareto (Zasada 80/20)](#the-pareto-principle-the-8020-rule)
|
||||
- [Zasada Shirky](#the-shirky-principle)
|
||||
- [Zasada Piotra](#the-peter-principle)
|
||||
- [Zasada solidności (prawo Postela)](#the-robustness-principle-postels-law)
|
||||
- [SOLIDNY](#solid)
|
||||
- [Zasada pojedynczej odpowiedzialności](#the-single-responsibility-principle)
|
||||
- [Zasada otwarcia/zamknięcia](#the-openclosed-principle)
|
||||
- [Zasada substytucji Liskov](#the-liskov-substitution-principle)
|
||||
- [Zasada segregacji interfejsów](#the-interface-segregation-principle)
|
||||
- [Zasada odwrócenia zależności](#the-dependency-inversion-principle)
|
||||
- [Zasada SUSZENIA](#the-dry-principle)
|
||||
- [Zasada KISS](#the-kiss-principle)
|
||||
- [Prawo Amdahla](#prawo-amdahla)
|
||||
- [Teoria zepsutych okien](#teoria-zepsutych-okien)
|
||||
- [Prawo Brooksa](#prawo-brooksa)
|
||||
- [Twierdzenie CAP (Twierdzenie Brewera)](#twierdzenie-cap-twierdzenie-brewera)
|
||||
- [Prawo Conwaya](#prawo-conwaya)
|
||||
- [Prawo Cunninghama](#prawo-cunninghama)
|
||||
- [Numer Dunbara](#numer-dunbara)
|
||||
- [Efekt Dunninga-Krugera](#efekt-dunninga-krugera)
|
||||
- [Prawo Fittsa](#prawo-fittsa)
|
||||
- [Prawo Galla](#prawo-galla)
|
||||
- [Prawo Goodharta](#prawo-goodharta)
|
||||
- [Brzytwa Hanlona](#brzytwa-hanlona)
|
||||
- [Prawo Hicka (Prawo Hicka-Hymana)](#prawo-hicka-prawo-hicka-hymana)
|
||||
- [Prawo Hofstadtera](#prawo-hofstadtera)
|
||||
- [Prawo Hutbera](#prawo-hutbera)
|
||||
- [Cykl szumu i prawo Amary](#cykl-szumu-i-prawo-amary)
|
||||
- [Prawo Hyruma (prawo niejawnych interfejsów)](#prawo-hyruma-prawo-niejawnych-interfejsów)
|
||||
- [Prawo Kernighana](#prawo-kernighana)
|
||||
- [Prawo Linusa](#prawo-linusa)
|
||||
- [Prawo Metcalfego](#prawo-metcalfego)
|
||||
- [prawo Moore'a](#prawo-moorea)
|
||||
- [Prawo Murphy'ego / Prawo Soda](#prawo-murphyego--prawo-soda)
|
||||
- [Brzytwa Ockhama](#brzytwa-ockohama)
|
||||
- [Prawo Parkinsona](#prawo-parkinsona)
|
||||
- [Przedwczesny efekt optymalizacji](#przedwczesny-efekt-optymalizacji)
|
||||
- [Prawo Putta](#prawo-putta)
|
||||
- [Prawo Reeda](#prawo-reeda)
|
||||
- [Prawo zachowania złożoności (prawo Teslera)](#prawo-zachowania-złożoności-prawo-teslera)
|
||||
- [Prawo Demeter](#prawo-demeter)
|
||||
- [Prawo nieszczelnych abstrakcji](#prawo-nieszczelnych-abstrakcji)
|
||||
- [Prawo trywialności](#prawo-trywialności)
|
||||
- [Filozofia Uniksa](#filozofia-uniksa)
|
||||
- [Zasada Skauta](#zasada-skauta)
|
||||
- [Model Spotify](#model-spotify)
|
||||
- [Zasada dwóch pizzy](#zasada-dwóch-pizzy)
|
||||
- [Prawo Wadlera](#prawo-wadlera)
|
||||
- [Prawo Wheatona](#prawo-wheatona)
|
||||
- [Zasady](#zasady)
|
||||
- [Wszystkie modele są błędne (prawo George'a Boxa)](#wszystkie-modele-są-błędne-prawo-georgea-boxa)
|
||||
- [Płot Chestertona](#płot-chestertona)
|
||||
- [Efekt Morza Martwego](#efekt-morza-martwego)
|
||||
- [Zasada Dilberta](#zasada-dilberta)
|
||||
- [Zasada Pareto (Zasada 80/20)](#zasada-pareto-zasada-8020)
|
||||
- [Zasada Shirky](#zasada-shirky)
|
||||
- [Zasada Piotra](#zasada-piotra)
|
||||
- [Zasada solidności (prawo Postela)](#zasada-solidarności-prawo-postela)
|
||||
- [SOLID](#solid)
|
||||
- [Zasada pojedynczej odpowiedzialności](#zasada-pojedynczej-odpowiedzialności)
|
||||
- [Zasada otwarcia/zamknięcia](#zasada-otwarcia-zamknięcia)
|
||||
- [Zasada substytucji Liskov](#zasada-substytucji-liskov)
|
||||
- [Zasada segregacji interfejsów](#zasada-segregacji-interfejsów)
|
||||
- [Zasada odwrócenia zależności](#zasada-odwrócenia-zależności)
|
||||
- [Zasada DRY](#zasada-dry)
|
||||
- [Zasada KISS](#zasada-kiss)
|
||||
- [YAGNI](#yagni)
|
||||
- [Błędy przetwarzania rozproszonego](#the-fallacies-of-distributed-computing)
|
||||
- [Lista rzeczy do przeczytania](#reading-list)
|
||||
- [Zasoby online](#online-resources)
|
||||
- [eBook w formacie PDF](#pdf-ebook)
|
||||
- [Błędy przetwarzania rozproszonego](#błędy-przetwarzania-rozproszonego)
|
||||
- [Lista rzeczy do przeczytania](#lista-rzeczy-do-przeczytania)
|
||||
- [Zasoby online](#zasoby-online)
|
||||
- [eBook w formacie PDF](#ebook-w-formacie-pdf)
|
||||
- [Podcast](#podcast)
|
||||
- [Tłumaczenia](#translations)
|
||||
- [Powiązane projekty](#related-projects)
|
||||
- [Przyczynianie się](#contributing)
|
||||
- [DO ZROBIENIA](#todo)
|
||||
- [Tłumaczenia](#tłumaczenia)
|
||||
- [Powiązane projekty](#powiązane-projekty)
|
||||
- [Przyczynianie się](#przyczynianie-się)
|
||||
- [DO ZROBIENIA](#do-zrobienia)
|
||||
|
||||
<!-- vim-markdown-toc -->
|
||||
|
||||
@@ -812,7 +812,7 @@ Zobacz też:
|
||||
|
||||
- [Prawo Hyruma](#hyrums-law-the-law-of-implicit-interfaces)
|
||||
|
||||
### SOLIDNY
|
||||
### SOLID
|
||||
|
||||
To jest akronim, który odnosi się do:
|
||||
|
||||
@@ -837,7 +837,7 @@ Teoretycznie powinno to sprawić, że kod będzie bardziej niezawodny i łatwiej
|
||||
Zobacz też:
|
||||
|
||||
- [Programowanie obiektowe](#todo)
|
||||
- [SOLIDNY](#solid)
|
||||
- [SOLID](#solid)
|
||||
|
||||
### Zasada otwarcia/zamknięcia
|
||||
|
||||
@@ -854,7 +854,7 @@ Ta zasada ma szczególne znaczenie w przypadku programowania obiektowego, w któ
|
||||
Zobacz też:
|
||||
|
||||
- [Programowanie obiektowe](#todo)
|
||||
- [SOLIDNY](#solid)
|
||||
- [SOLID](#solid)
|
||||
|
||||
### Zasada substytucji Liskov
|
||||
|
||||
@@ -871,7 +871,7 @@ Zasada ta ma szczególne znaczenie w przypadku programowania obiektowego, w któ
|
||||
Zobacz też:
|
||||
|
||||
- [Programowanie obiektowe](#todo)
|
||||
- [SOLIDNY](#solid)
|
||||
- [SOLID](#solid)
|
||||
|
||||
### Zasada segregacji interfejsów
|
||||
|
||||
@@ -888,7 +888,7 @@ Zasada ta ma szczególne znaczenie dla programowania obiektowego, w którym inte
|
||||
Zobacz też:
|
||||
|
||||
- [Programowanie obiektowe](#todo)
|
||||
- [SOLIDNY](#solid)
|
||||
- [SOLID](#solid)
|
||||
- [Pisanie kaczki](#todo)
|
||||
- [Oddzielenie](#todo)
|
||||
|
||||
@@ -907,11 +907,11 @@ Ta zasada jest złożona, ponieważ może się wydawać, że „odwraca” oczek
|
||||
Zobacz też:
|
||||
|
||||
- [Programowanie obiektowe](#todo)
|
||||
- [SOLIDNY](#solid)
|
||||
- [SOLID](#solid)
|
||||
- [Odwrócenie sterowania](#todo)
|
||||
- [Wstrzykiwanie zależności](#todo)
|
||||
|
||||
### Zasada SUSZENIA
|
||||
### Zasada DRY
|
||||
|
||||
[Zasada DRY na Wikipedii](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
|
||||
|
||||
|
||||
@@ -167,10 +167,10 @@ Xem thêm:
|
||||
Định lý CAP (do Eric Brewer định nghĩa) tuyên bố rằng đối với một kho lưu trữ dữ liệu phân tán, chỉ có thể thực hiện hai trong ba bảo đảm sau (nhiều nhất):
|
||||
|
||||
- Tính đồng bộ (Consistency): khi đọc dữ liệu, mọi yêu cầu đều nhận được _dữ liệu gần đây nhất_ hoặc lỗi được trả về
|
||||
- Tính sẫn sàng (Availability): khi đọc dữ liệu, mọi yêu cầu đều nhận được _phản hồi không lỗi_ , mà không cần đảm bảo rằng đó là dữ liệu _mới nhất_
|
||||
- Tính sẵn sàng (Availability): khi đọc dữ liệu, mọi yêu cầu đều nhận được _phản hồi không lỗi_ , mà không cần đảm bảo rằng đó là dữ liệu _mới nhất_
|
||||
- Chịu lỗi(P-Partition Tolerance): khi một số lượng tùy ý yêu cầu mạng giữa các nút không thành công, hệ thống tiếp tục hoạt động như thiết kế.
|
||||
|
||||
Cốt lõi của lý do là như sau. Không thể đảm bảo sai biệt cục bộ không xảy ra (xem [Sự sụp đổ của Máy tính Phân tán](#the-fallacies-of-distributed-computing) ). Do đó, trong trường hợp sai biệt cục bộ, chúng ta có thể hoặc ngưng công việc (tăng tính đồng bộ và giảm tính sẫn sàng) hoặc tiếp tục công việc (tăng tính sẫn sàng nhưng giảm tính đồng bộ).
|
||||
Cốt lõi của lý do là như sau. Không thể đảm bảo sai biệt cục bộ không xảy ra (xem [Sự sụp đổ của Máy tính Phân tán](#the-fallacies-of-distributed-computing) ). Do đó, trong trường hợp sai biệt cục bộ, chúng ta có thể hoặc ngưng công việc (tăng tính đồng bộ và giảm tính sẵn sàng) hoặc tiếp tục công việc (tăng tính sẵn sàng nhưng giảm tính đồng bộ).
|
||||
|
||||
Tên gọi xuất phát từ các chữ cái đầu tiên (Consistency, Availability, Partition Tolerance). Lưu ý rằng điều rất quan trọng cần lưu ý là điều này _không_ liên quan đến [_ACID_](#TODO) , có định nghĩa khác về tính đồng bộ. Gần đây hơn, [định lý PACELC](#TODO) đã được phát triển để bổ sung các ràng buộc về độ trễ và tính đồng bộ khi mạng _không bị_ sai biệt cục bộ (tức là khi hệ thống đang hoạt động như mong đợi).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user