feat(pages): update index.html and pages.yaml for deployment

Updated the index.html to include a full HTML structure with Bootstrap and Google tag. Modified pages.yaml to deploy from 'build/pages' branch instead of the default branch.
Merge pull request #435 from dwmkerr/build/test-pages
2025-12-17 12:45:20 +01:00 · 2025-03-08 21:22:41 +00:00 · 2025-03-08 20:47:59 +00:00 · 2025-03-08 20:46:45 +00:00 · 2025-02-26 14:17:26 +00:00 · 2025-02-26 12:05:25 +00:00
9 changed files with 1430 additions and 184 deletions
--- a/.github/pages/index.html
+++ b/.github/pages/index.html
@@ -0,0 +1,28 @@
 <!doctype html>
 <html lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <!-- Bootstrap CSS -->
    <link href="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/css/bootstrap.min.css" rel="stylesheet" integrity="sha384-EVSTQN3/azprG1Anm3QDgpJLIm9Nao0Yz1ztcQTwFspd3yD65VohhpuuCOmLASjC" crossorigin="anonymous">
    <title>Hacker Laws</title>
    <!-- Google tag (gtag.js) -->
    <script async src="https://www.googletagmanager.com/gtag/js?id=G-RGJ5TDHWY9"></script>
    <script>
      window.dataLayer = window.dataLayer || [];
      function gtag(){dataLayer.push(arguments);}
      gtag('js', new Date());
      gtag('config', 'G-RGJ5TDHWY9');
    </script>
  </head>
  <body>
    <h1>Hacker Laws</h1>
    <!-- Bootstrap JS -->
    <script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.2/dist/js/bootstrap.min.js" integrity="sha384-cVKIPhGWiC2Al4u+LWgxfKTRIcfu0JTxR+EQDz/bgldoEyl4H0zUF0QKbrJ0EcQF" crossorigin="anonymous"></script>
  </body>
 </html>
--- a/.github/workflows/build-on-pull-request.yaml
+++ b/.github/workflows/build-on-pull-request.yaml
@@ -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
--- a/.github/workflows/pages.yaml
+++ b/.github/workflows/pages.yaml
@@ -0,0 +1,40 @@
 name: Deploy to Pages
 on:
  # Runs on pushes targeting the default branch (or runs manually).
  push:
    # branches: [$default-branch]
    branches: ['build/pages'] # we're deploying from a build branch for now.
  workflow_dispatch:
 # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
 permissions:
  contents: read
  pages: write
  id-token: write
 # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
 # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
 concurrency:
  group: "pages"
  cancel-in-progress: false
 jobs:
  # Single deploy job since we're just deploying
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-24.04
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Setup Pages
        uses: actions/configure-pages@v5
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: './.github/pages'
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4
--- a/README.md
+++ b/README.md
@@ -2,7 +2,7 @@
 Laws, Theories, Principles and Patterns that developers will find useful.
-[Translations](#translations): [🇮🇩](./translations/id.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇵🇱](./translations/pl.md) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md) [🇺🇦](./translations/uk.md)
+[Translations](#translations): [🇮🇩](./translations/id.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇵🇱](./translations/pl.md) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md) [🇺🇦](./translations/uk.md) [🇻🇳](./translations/vi.md)
 Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations). Also check out this podcast on [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403) to learn more about the project! You can also [download the latest PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf). Check the [Contributor Guide](./.github/contributing.md) if you are keen to contribute!
@@ -10,73 +10,80 @@ Like this project? Please considering [sponsoring me](https://github.com/sponsor
 <!-- vim-markdown-toc GFM -->
-* [Introduction](#introduction)
+- [Introduction](#introduction)
-* [Laws](#laws)
+- [Laws](#laws)
-    * [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
+    - [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
-    * [Amdahl's Law](#amdahls-law)
+    - [90–90 Rule](#9090-rule)
-    * [The Broken Windows Theory](#the-broken-windows-theory)
+    - [Amdahl's Law](#amdahls-law)
-    * [Brooks' Law](#brooks-law)
+    - [The Broken Windows Theory](#the-broken-windows-theory)
-    * [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
+    - [Brooks' Law](#brooks-law)
-    * [Conway's Law](#conways-law)
+    - [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
-    * [Cunningham's Law](#cunninghams-law)
+    - [Clarke's three laws](#clarkes-three-laws)
-    * [Dunbar's Number](#dunbars-number)
+    - [Conway's Law](#conways-law)
-    * [The Dunning-Kruger Effect](#the-dunning-kruger-effect)
+    - [Cunningham's Law](#cunninghams-law)
-    * [Fitts' Law](#fitts-law)
+    - [Dunbar's Number](#dunbars-number)
-    * [Gall's Law](#galls-law)
+    - [The Dunning-Kruger Effect](#the-dunning-kruger-effect)
-    * [Goodhart's Law](#goodharts-law)
+    - [Fitts' Law](#fitts-law)
-    * [Hanlon's Razor](#hanlons-razor)
+    - [Gall's Law](#galls-law)
-    * [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
+    - [Goodhart's Law](#goodharts-law)
-    * [Hofstadter's Law](#hofstadters-law)
+    - [Hanlon's Razor](#hanlons-razor)
-    * [Hutber's Law](#hutbers-law)
+    - [Hick's Law (Hick-Hyman Law)](#hicks-law-hick-hyman-law)
-    * [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
+    - [Hofstadter's Law](#hofstadters-law)
-    * [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Hutber's Law](#hutbers-law)
-    * [Kernighan's Law](#kernighans-law)
+    - [The Hype Cycle & Amara's Law](#the-hype-cycle--amaras-law)
-    * [Linus's Law](#linuss-law)
+    - [Hyrum's Law (The Law of Implicit Interfaces)](#hyrums-law-the-law-of-implicit-interfaces)
-    * [Metcalfe's Law](#metcalfes-law)
+    - [Input-Process-Output (IPO)](#input-process-output-ipo)
-    * [Moore's Law](#moores-law)
+    - [Kernighan's Law](#kernighans-law)
-    * [Murphy's Law / Sod's Law](#murphys-law--sods-law)
+    - [Linus's Law](#linuss-law)
-    * [Occam's Razor](#occams-razor)
+    - [Metcalfe's Law](#metcalfes-law)
-    * [Parkinson's Law](#parkinsons-law)
+    - [Moore's Law](#moores-law)
-    * [Premature Optimization Effect](#premature-optimization-effect)
+    - [Murphy's Law / Sod's Law](#murphys-law--sods-law)
-    * [Putt's Law](#putts-law)
+    - [Occam's Razor](#occams-razor)
-    * [Reed's Law](#reeds-law)
+    - [Parkinson's Law](#parkinsons-law)
-    * [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [Premature Optimization Effect](#premature-optimization-effect)
-    * [The Law of Demeter](#the-law-of-demeter)
+    - [Putt's Law](#putts-law)
-    * [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
+    - [Reed's Law](#reeds-law)
-    * [The Law of Triviality](#the-law-of-triviality)
+    - [The Ringelmann Effect](#the-ringelmann-effect)
-    * [The Unix Philosophy](#the-unix-philosophy)
+    - [The Law of Conservation of Complexity (Tesler's Law)](#the-law-of-conservation-of-complexity-teslers-law)
-    * [The Scout Rule](#the-scout-rule)
+    - [The Law of Demeter](#the-law-of-demeter)
-    * [The Spotify Model](#the-spotify-model)
+    - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions)
-    * [The Two Pizza Rule](#the-two-pizza-rule)
+    - [The Law of the Instrument](#the-law-of-the-instrument)
-    * [Wadler's Law](#wadlers-law)
+    - [The Law of Triviality](#the-law-of-triviality)
-    * [Wheaton's Law](#wheatons-law)
+    - [The Unix Philosophy](#the-unix-philosophy)
-* [Principles](#principles)
+    - [The Scout Rule](#the-scout-rule)
-    * [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
+    - [The Spotify Model](#the-spotify-model)
-    * [Chesterton's Fence](#chestertons-fence)
+    - [The Two Pizza Rule](#the-two-pizza-rule)
-    * [The Dead Sea Effect](#the-dead-sea-effect)
+    - [Twyman's law](#twymans-law)
-    * [The Dilbert Principle](#the-dilbert-principle)
+    - [Wadler's Law](#wadlers-law)
-    * [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
+    - [Wheaton's Law](#wheatons-law)
-    * [The Shirky Principle](#the-shirky-principle)
+- [Principles](#principles)
-    * [The Peter Principle](#the-peter-principle)
+    - [All Models Are Wrong (George Box's Law)](#all-models-are-wrong-george-boxs-law)
-    * [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
+    - [Chesterton's Fence](#chestertons-fence)
-    * [SOLID](#solid)
+    - [The Dead Sea Effect](#the-dead-sea-effect)
-    * [The Single Responsibility Principle](#the-single-responsibility-principle)
+    - [The Dilbert Principle](#the-dilbert-principle)
-    * [The Open/Closed Principle](#the-openclosed-principle)
+    - [The Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
-    * [The Liskov Substitution Principle](#the-liskov-substitution-principle)
+    - [The Shirky Principle](#the-shirky-principle)
-    * [The Interface Segregation Principle](#the-interface-segregation-principle)
+    - [The Peter Principle](#the-peter-principle)
-    * [The Dependency Inversion Principle](#the-dependency-inversion-principle)
+    - [The Robustness Principle (Postel's Law)](#the-robustness-principle-postels-law)
-    * [The DRY Principle](#the-dry-principle)
+    - [SOLID](#solid)
-    * [The KISS principle](#the-kiss-principle)
+    - [The Single Responsibility Principle](#the-single-responsibility-principle)
-    * [YAGNI](#yagni)
+    - [The Open/Closed Principle](#the-openclosed-principle)
-    * [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
+    - [The Liskov Substitution Principle](#the-liskov-substitution-principle)
-* [Reading List](#reading-list)
+    - [The Interface Segregation Principle](#the-interface-segregation-principle)
-* [Online Resources](#online-resources)
+    - [The Dependency Inversion Principle](#the-dependency-inversion-principle)
-* [PDF eBook](#pdf-ebook)
+    - [The DRY Principle](#the-dry-principle)
-* [Podcast](#podcast)
+    - [The KISS principle](#the-kiss-principle)
-* [Translations](#translations)
+    - [YAGNI](#yagni)
-* [Related Projects](#related-projects)
+    - [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
-* [Contributing](#contributing)
+    - [The Principle of Least Astonishment](#the-principle-of-least-astonishment)
-* [TODO](#todo)
+- [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 -->
@@ -90,6 +97,7 @@ There are lots of laws which people discuss when talking about development. This
 And here we go!
 ### 90–9–1 Principle (1% Rule)
 [1% Rule on Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
@@ -104,6 +112,19 @@ See Also:
 - [Pareto principle](#the-pareto-principle-the-8020-rule)
 ### 90–90 Rule
 [90-90 Rule on Wikipedia](https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule)
 > The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
 A wry reinterpretation of the [Pareto Principe (or 80-20 rule)](#the-pareto-principle-the-8020-rule) that highlights the real-world challenges of completing engineering work. This sentiment is also echoed in [Hofstadter's Law](#hofstadters-law).
 See also:
 - [Hofstadter's Law](#hofstadters-law)
 - [The Pareto Principe](#the-pareto-principle-the-8020-rule)
 ### Amdahl's Law
 [Amdahl's Law on Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law)
@@ -151,7 +172,7 @@ Examples:
 > Adding human resources to a late software development project makes it later.
-This law suggests that in many cases, attempting to accelerate the delivery of a project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however, the general reasoning is that given the ramp up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower.
+This law suggests that in many cases, attempting to accelerate the delivery of a project which is already late, by adding more people, will make the delivery even later. Brooks is clear that this is an over-simplification, however, the general reasoning is that given the ramp-up time of new resources and the communication overheads, in the immediate short-term velocity decreases. Also, many tasks may not be divisible, i.e. easily distributed between more resources, meaning the potential velocity increase is also lower.
 The common phrase in delivery "Nine women can't make a baby in one month" relates to Brooks' Law, in particular, the fact that some kinds of work are not divisible or parallelisable.
@@ -186,11 +207,23 @@ 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)
-This law suggests that the technical boundaries of a system will reflect the structure of the organisation. It is commonly referred to when looking at organisation improvements, Conway's Law suggests that if an organisation is structured into many small, disconnected units, the software it produces will be. If an organisation is built more around 'verticals' which are orientated around features or services, the software systems will also reflect this.
+This law suggests that the technical boundaries of a system will reflect the structure of the organisation. It is commonly referred to when looking at organisation improvements, Conway's Law suggests that if an organisation is structured into many small, disconnected units, the software it produces will be. If an organisation is built more around 'verticals' which are oriented around features or services, the software systems will also reflect this.
 See also:
@@ -214,7 +247,7 @@ See also:
 "Dunbar's number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships— relationships in which an individual knows who each person is and how each person relates to every other person." There is some disagreement to the exact number. "... [Dunbar] proposed that humans can comfortably maintain only 150 stable relationships." He put the number into a more social context, "the number of people you would not feel embarrassed about joining uninvited for a drink if you happened to bump into them in a bar." Estimates for the number generally lay between 100 and 250.
-Like stable relationships between individuals, a developer's relationship with a codebase takes effort to maintain. When faced with large complicated projects, or ownership of many projects we lean on convention, policy, and modeled procedure to scale. Dunbar's number is not only important to keep in mind as an office grows, but also when setting the scope for team efforts or deciding when a system should invest in tooling to assist in modeling and automating logistical overhead. Putting the number into an engineering context, it is the number of projects (or normalized complexity of a single project) for which you would feel confident in joining an on-call rotation to support.
+Like stable relationships between individuals, a developer's relationship with a codebase takes effort to maintain. When faced with large complicated projects, or ownership of many projects, we lean on convention, policy, and modeled procedure to scale. Dunbar's number is not only important to keep in mind as an office grows, but also when setting the scope for team efforts or deciding when a system should invest in tooling to assist in modeling and automating logistical overhead. Putting the number into an engineering context, it is the number of projects (or normalized complexity of a single project) for which you would feel confident in joining an on-call rotation to support.
 See also:
@@ -233,7 +266,7 @@ The Dunning–Kruger effect is a theoretical cognitive bias which was described
 The Dunning-Kruger effect has sometimes been used to describe a related, but not necessarily implied effect which could be described as "The less a person understands a domain, the more they are likely to believe they can easily solve problems in that domain, as they are more likely to see the domain as _simple_". This more general effect is highly relevant in technology. It would suggest that people who are less familiar with a domain, such as non-technical team members or less experienced team members, are more likely to _underestimate_ the effort required to solve a problem in this space.
-As a person's understanding and experience in a domain grows, they may well encounter another effect, which is that they tend to _overestimate_ the ability of _others_ or _underestimate_ their own ability, as they are have become so experienced in the domain. In all cases these effects are _cognitive biases_. As with any bias, an understanding that it may be present will often be sufficient to help avoid the challenges - as when there is awareness of a bias more inputs and opinions can be included to attempt to eliminate these biases. A closely related is the bias of [Illusory superiority](https://en.wikipedia.org/wiki/Illusory_superiority).
+As a person's understanding and experience in a domain grows, they may well encounter another effect, which is that they tend to _overestimate_ the ability of _others_ or _underestimate_ their own ability, as they are have become so experienced in the domain. In all cases these effects are _cognitive biases_. As with any bias, an understanding that it may be present will often be sufficient to help avoid the challenges — as when there is awareness of a bias, more inputs and opinions can be included to attempt to eliminate these biases. A closely related bias is that of [Illusory superiority](https://en.wikipedia.org/wiki/Illusory_superiority).
 Real-world examples:
@@ -392,6 +425,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.
@@ -502,7 +553,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.
 >
@@ -543,6 +594,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)
@@ -589,6 +649,25 @@ Real-world examples:
 - [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
 ### The Law of the Instrument
 [The Law of the Instrument](https://en.wikipedia.org/wiki/Law_of_the_instrument)
 > I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding.
 >
 > _Abraham Kaplan_
 > If all you have is a hammer, everything looks like a nail.
 >
 > _Abraham Maslow_
 In the context of computer programming, this law suggests that people tend to use tools that are familiar with, rather than the best possible tool. This over-reliance on a familiar tool is an anti-pattern referred to as 'the golden hammer'.
 See also:
 - [Avoiding the law of the instrument](https://josemdev.com/avoiding-the-law-of-the-instrument/)
 - [Anti-Pattern - The Golden Hammer](https://archive.org/details/antipatternsrefa0000unse/page/111/mode/2up)
 ### The Law of Triviality
 [The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
@@ -649,6 +728,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)
@@ -788,7 +879,7 @@ See also:
 A management concept developed by Laurence J. Peter, the Peter Principle observes that people who are good at their jobs are promoted, until they reach a level where they are no longer successful (their "level of incompetence"). At this point, as they are more senior, they are less likely to be removed from the organisation (unless they perform spectacularly badly) and will continue to reside in a role which they have few intrinsic skills at, as their original skills which made them successful are not necessarily the skills required for their new jobs.
-This is of particular interest to engineers - who initially start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skills-set.
+This is of particular interest to engineers - who initially start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skill set.
 See Also:
@@ -811,7 +902,6 @@ See Also:
 - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
 ### SOLID
 This is an acronym, which refers to:
@@ -832,7 +922,7 @@ These are key principles in [Object-Oriented Programming](#todo). Design princip
 The first of the '[SOLID](#solid)' principles. This principle suggests that modules or classes should do one thing and one thing only. In more practical terms, this means that a single, small change to a feature of a program should require a change in one component only. For example, changing how a password is validated for complexity should require a change in only one part of the program.
-Theoretically, this should make the code more robust, and easier to change. Knowing that a component which is being changed has a single responsibility only means that _testing_ that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities.
+Theoretically, this should make the code more robust, and easier to change. Knowing that a component being changed has a single responsibility only means that _testing_ that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities.
 See also:
@@ -864,7 +954,7 @@ See also:
 The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is.
-As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
+As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be usable in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
 This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system.
@@ -898,7 +988,7 @@ See also:
 > High-level modules should not be dependent on low-level implementations.
-The fifth of the '[SOLID](#solid)' principles. This principle states that higher level orchestrating components should not have to know the details of their dependencies.
+The fifth of the '[SOLID](#solid)' principles. This principle states that higher-level orchestrating components should not have to know the details of their dependencies.
 As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc.
@@ -917,7 +1007,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).
@@ -925,7 +1015,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
@@ -985,6 +1075,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.
@@ -1022,6 +1128,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) | [![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)](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) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](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 |
@@ -1032,11 +1139,13 @@ 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)| [![gitlocalized ](https://gitlocalize.com/repo/2513/ja/badge.svg)](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) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](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) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pl/badge.svg)](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 |
 | [🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge) |
 | [🇺🇦 українська мова / Ukrainian](./translations/uk.md) | [Nazar](https://github.com/troyane), [Helga Lastivka](https://github.com/HelgaLastivka) | [![gitlocalized ](https://gitlocalize.com/repo/2513/uk/badge.svg)](https://gitlocalize.com/repo/2513/uk?utm_source=badge) |
 | [🇻🇳 Tiếng Việt / Vietnamese](./translations/vu.md)                      | [Nguyên](https://github.com/truonghoangnguyen), [Trương Hoàng](https://github.com/truonghoangnguyen) | [![gitlocalized ](https://gitlocalize.com/repo/2513/vi/badge.svg)](https://gitlocalize.com/repo/2513/vi?utm_source=badge) |
 If you would like to update a translation, follow the [Translators Contributor Guide](https://github.com/dwmkerr/hacker-laws/blob/main/.github/contributing.md#translations).
--- a/scripts/prepare-markdown-for-ebook.sh
+++ b/scripts/prepare-markdown-for-ebook.sh
@@ -1,42 +1,32 @@
 #!/usr/bin/env bash
-# This script prepares a `hacker-laws.md` file which is in a format ready to be
+# This script prepares a `hacker-laws.md` file for export to PDF or e-book format.
 # exported to PDF or other formats for an e-book.
-# 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
+if [ -z "$version" ]; then
-    echo "version must be specified: ./prepare-markdown-for-ebook.sh <version>"
+    echo "Usage: $0 <version>"
    exit 1
 fi
-# Create the frontmatter.
+# Create `hacker-laws.md` with frontmatter and README content in one step.
-cat << EOF > frontmatter.md
+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.
+# Use a single `sed` command to clean up unwanted lines and emojis in one pass.
-cat frontmatter.md README.md >> hacker-laws.md
+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
+echo "hacker-laws.md prepared successfully."
 # 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
--- a/translations/fr.md
+++ b/translations/fr.md
@@ -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 :
--- a/translations/jp.md
+++ b/translations/jp.md
@@ -27,6 +27,7 @@
    - [ハイプサイクルとアマラの法則](#ハイプサイクルとアマラの法則)
    - [ハイラムの法則（暗黙のインターフェースの法則）](#ハイラムの法則暗黙のインターフェースの法則)
    - [カーニガンの法則](#カーニガンの法則)
    - [リーナスの法則](#リーナスの法則)
    - [メトカーフの法則](#メトカーフの法則)
    - [ムーアの法則](#ムーアの法則)
    - [マーフィーの法則/ソッドの法則](#マーフィーの法則ソッドの法則)
@@ -301,6 +302,24 @@
 - [UNIX哲学](#unix哲学)
 - [オッカムのかみそり](#オッカムの剃刀)
 ### リーナスの法則
 [リーナスの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%81%AE%E6%B3%95%E5%89%87)
 > 十分な目ん玉があれば、全てのバグは洗い出される。
 >
 > _エリック・S・レイモンド_
 この法則は簡単に言うと、あるプログラムを見る人が多ければ多いほど、誰かがその問題を以前に見て解決している可能性が高くなる、あるいはそれに非常に近い状況になる、というものです。
 元々はプロジェクトのオープンソースモデルの価値を説明するために使われましたが、どんなソフトウェアプロジェクトにも当てはまります。プロセスにも拡大して適用できます。より多くのコードレビューや静的解析、また多角的なテストプロセスによって、問題をより可視化されて識別しやすくなります。
 より格式ばって言うと以下のようになります。
 > ベータテスターと共同開発者が十分多くいれば、ほとんど全ての問題はすぐに明確になり、似た問題に以前遭遇したことのある人によって解決されるだろう。
 この法則は、エリック・S・レイモンドの著作『[伽藍とバザール](https://ja.wikipedia.org/wiki/%E4%BC%BD%E8%97%8D%E3%81%A8%E3%83%90%E3%82%B6%E3%83%BC%E3%83%AB)』の中で、[リーナス・トーバルズ](https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%83%8A%E3%82%B9%E3%83%BB%E3%83%88%E3%83%BC%E3%83%90%E3%83%AB%E3%82%BA)に敬意を表して名付けられました。
 ### メトカーフの法則
 [メトカーフの法則-Wikipedia](https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%88%E3%82%AB%E3%83%BC%E3%83%95%E3%81%AE%E6%B3%95%E5%89%87)
@@ -608,9 +627,9 @@ Spotifyモデルとは、「Spotify」によって普及したチームと組織
 > エンティティは拡張のために開かれ、修正のために閉じられるべきです。
-「 [SOLID](#solid) 」第二原則。この原則では、エンティティー（クラス、モジュール、関数など）は動作を*拡張*ることができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。
+「 [SOLID](#solid) 」第二原則。この原則では、エンティティー（クラス、モジュール、関数など）は動作を*拡張*することができなければならないが、 *既存*の振る舞いは修正することができないべきではないということを述べています。
-仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。ジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。
+仮定としてMarkdown文書をHTMLに変換することができるモジュールを想像してください。モジュールがモジュール内部を修正することなく、新しく提案されたMarkdown機能を処理するために拡張できた場合、拡張のためにオープンになります。既存のMarkdown機能が処理されるように、モジュールが利用者によって*修正されない*場合、修正のために*クローズド*になります。
 この原則は、オブジェクト指向プログラミングに特に関連しています。簡単に拡張するオブジェクトを設計するかもしれませんが、予期しない方法で変更された既存の動作を持つことができるオブジェクトを設計することを避けます。
@@ -794,4 +813,4 @@ KISSの原則は、ほとんどのシステムは複雑にするのではなく
 こんにちは！あなたがここに来たということは、私がまだ書き上げていないトピックへのリンクをクリックしたことにですね。
-リクエストしたい場合は  [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) rをクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。
+リクエストしたい場合は  [Raise an Issue](https://github.com/dwmkerr/hacker-laws/issues) をクリックするか、トピックの定義案を提出したい場合は [Open a Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) をクリックしてください。
--- a/translations/pl.md
+++ b/translations/pl.md
@@ -10,73 +10,73 @@ Podoba Ci się ten projekt? Proszę rozważyć [sponsorowanie mnie](https://gith
 <!-- vim-markdown-toc GFM -->
- [Wstęp](#introduction)
+- [Wstęp](#wstęp)
- [Prawa](#laws)
+- [Prawa](#prawa)
-    - [Zasada 90-9-1 (zasada 1%)](#9091-principle-1-rule)
+    - [Zasada 90-9-1 (zasada 1%)](#zasada-90-9-1-zasada-1)
-    - [Prawo Amdahla](#amdahls-law)
+    - [Prawo Amdahla](#prawo-amdahla)
-    - [Teoria zepsutych okien](#the-broken-windows-theory)
+    - [Teoria zepsutych okien](#teoria-zepsutych-okien)
-    - [Prawo Brooksa](#brooks-law)
+    - [Prawo Brooksa](#prawo-brooksa)
-    - [Twierdzenie CAP (Twierdzenie Brewera)](#cap-theorem-brewers-theorem)
+    - [Twierdzenie CAP (Twierdzenie Brewera)](#twierdzenie-cap-twierdzenie-brewera)
-    - [Prawo Conwaya](#conways-law)
+    - [Prawo Conwaya](#prawo-conwaya)
-    - [Prawo Cunninghama](#cunninghams-law)
+    - [Prawo Cunninghama](#prawo-cunninghama)
-    - [Numer Dunbara](#dunbars-number)
+    - [Numer Dunbara](#numer-dunbara)
-    - [Efekt Dunninga-Krugera](#the-dunning-kruger-effect)
+    - [Efekt Dunninga-Krugera](#efekt-dunninga-krugera)
-    - [Prawo Fittsa](#fitts-law)
+    - [Prawo Fittsa](#prawo-fittsa)
-    - [Prawo Galla](#galls-law)
+    - [Prawo Galla](#prawo-galla)
-    - [Prawo Goodharta](#goodharts-law)
+    - [Prawo Goodharta](#prawo-goodharta)
-    - [Brzytwa Hanlona](#hanlons-razor)
+    - [Brzytwa Hanlona](#brzytwa-hanlona)
-    - [Prawo Hicka (Prawo Hicka-Hymana)](#hicks-law-hick-hyman-law)
+    - [Prawo Hicka (Prawo Hicka-Hymana)](#prawo-hicka-prawo-hicka-hymana)
-    - [Prawo Hofstadtera](#hofstadters-law)
+    - [Prawo Hofstadtera](#prawo-hofstadtera)
-    - [Prawo Hutbera](#hutbers-law)
+    - [Prawo Hutbera](#prawo-hutbera)
-    - [Cykl szumu i prawo Amary](#the-hype-cycle--amaras-law)
+    - [Cykl szumu i prawo Amary](#cykl-szumu-i-prawo-amary)
-    - [Prawo Hyruma (prawo niejawnych interfejsów)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Prawo Hyruma (prawo niejawnych interfejsów)](#prawo-hyruma-prawo-niejawnych-interfejsów)
-    - [Prawo Kernighana](#kernighans-law)
+    - [Prawo Kernighana](#prawo-kernighana)
-    - [Prawo Linusa](#linuss-law)
+    - [Prawo Linusa](#prawo-linusa)
-    - [Prawo Metcalfego](#metcalfes-law)
+    - [Prawo Metcalfego](#prawo-metcalfego)
-    - [prawo Moore'a](#moores-law)
+    - [prawo Moore'a](#prawo-moorea)
-    - [Prawo Murphy'ego / Prawo Soda](#murphys-law--sods-law)
+    - [Prawo Murphy'ego / Prawo Soda](#prawo-murphyego--prawo-soda)
-    - [Brzytwa Ockhama](#occams-razor)
+    - [Brzytwa Ockhama](#brzytwa-ockohama)
-    - [Prawo Parkinsona](#parkinsons-law)
+    - [Prawo Parkinsona](#prawo-parkinsona)
-    - [Przedwczesny efekt optymalizacji](#premature-optimization-effect)
+    - [Przedwczesny efekt optymalizacji](#przedwczesny-efekt-optymalizacji)
-    - [Prawo Putta](#putts-law)
+    - [Prawo Putta](#prawo-putta)
-    - [Prawo Reeda](#reeds-law)
+    - [Prawo Reeda](#prawo-reeda)
-    - [Prawo zachowania złożoności (prawo Teslera)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [Prawo zachowania złożoności (prawo Teslera)](#prawo-zachowania-złożoności-prawo-teslera)
-    - [Prawo Demeter](#the-law-of-demeter)
+    - [Prawo Demeter](#prawo-demeter)
-    - [Prawo nieszczelnych abstrakcji](#the-law-of-leaky-abstractions)
+    - [Prawo nieszczelnych abstrakcji](#prawo-nieszczelnych-abstrakcji)
-    - [Prawo trywialności](#the-law-of-triviality)
+    - [Prawo trywialności](#prawo-trywialności)
-    - [Filozofia Uniksa](#the-unix-philosophy)
+    - [Filozofia Uniksa](#filozofia-uniksa)
-    - [Zasada Skauta](#the-scout-rule)
+    - [Zasada Skauta](#zasada-skauta)
-    - [Model Spotify](#the-spotify-model)
+    - [Model Spotify](#model-spotify)
-    - [Zasada dwóch pizzy](#the-two-pizza-rule)
+    - [Zasada dwóch pizzy](#zasada-dwóch-pizzy)
-    - [Prawo Wadlera](#wadlers-law)
+    - [Prawo Wadlera](#prawo-wadlera)
-    - [Prawo Wheatona](#wheatons-law)
+    - [Prawo Wheatona](#prawo-wheatona)
- [Zasady](#principles)
+- [Zasady](#zasady)
-    - [Wszystkie modele są błędne (prawo George'a Boxa)](#all-models-are-wrong-george-boxs-law)
+    - [Wszystkie modele są błędne (prawo George'a Boxa)](#wszystkie-modele-są-błędne-prawo-georgea-boxa)
-    - [Płot Chestertona](#chestertons-fence)
+    - [Płot Chestertona](#płot-chestertona)
-    - [Efekt Morza Martwego](#the-dead-sea-effect)
+    - [Efekt Morza Martwego](#efekt-morza-martwego)
-    - [Zasada Dilberta](#the-dilbert-principle)
+    - [Zasada Dilberta](#zasada-dilberta)
-    - [Zasada Pareto (Zasada 80/20)](#the-pareto-principle-the-8020-rule)
+    - [Zasada Pareto (Zasada 80/20)](#zasada-pareto-zasada-8020)
-    - [Zasada Shirky](#the-shirky-principle)
+    - [Zasada Shirky](#zasada-shirky)
-    - [Zasada Piotra](#the-peter-principle)
+    - [Zasada Piotra](#zasada-piotra)
-    - [Zasada solidności (prawo Postela)](#the-robustness-principle-postels-law)
+    - [Zasada solidności (prawo Postela)](#zasada-solidarności-prawo-postela)
-    - [SOLIDNY](#solid)
+    - [SOLID](#solid)
-    - [Zasada pojedynczej odpowiedzialności](#the-single-responsibility-principle)
+    - [Zasada pojedynczej odpowiedzialności](#zasada-pojedynczej-odpowiedzialności)
-    - [Zasada otwarcia/zamknięcia](#the-openclosed-principle)
+    - [Zasada otwarcia/zamknięcia](#zasada-otwarcia-zamknięcia)
-    - [Zasada substytucji Liskov](#the-liskov-substitution-principle)
+    - [Zasada substytucji Liskov](#zasada-substytucji-liskov)
-    - [Zasada segregacji interfejsów](#the-interface-segregation-principle)
+    - [Zasada segregacji interfejsów](#zasada-segregacji-interfejsów)
-    - [Zasada odwrócenia zależności](#the-dependency-inversion-principle)
+    - [Zasada odwrócenia zależności](#zasada-odwrócenia-zależności)
-    - [Zasada SUSZENIA](#the-dry-principle)
+    - [Zasada DRY](#zasada-dry)
-    - [Zasada KISS](#the-kiss-principle)
+    - [Zasada KISS](#zasada-kiss)
    - [YAGNI](#yagni)
-    - [Błędy przetwarzania rozproszonego](#the-fallacies-of-distributed-computing)
+    - [Błędy przetwarzania rozproszonego](#błędy-przetwarzania-rozproszonego)
- [Lista rzeczy do przeczytania](#reading-list)
+- [Lista rzeczy do przeczytania](#lista-rzeczy-do-przeczytania)
- [Zasoby online](#online-resources)
+- [Zasoby online](#zasoby-online)
- [eBook w formacie PDF](#pdf-ebook)
+- [eBook w formacie PDF](#ebook-w-formacie-pdf)
 - [Podcast](#podcast)
- [Tłumaczenia](#translations)
+- [Tłumaczenia](#tłumaczenia)
- [Powiązane projekty](#related-projects)
+- [Powiązane projekty](#powiązane-projekty)
- [Przyczynianie się](#contributing)
+- [Przyczynianie się](#przyczynianie-się)
- [DO ZROBIENIA](#todo)
+- [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)
--- a/translations/vi.md
+++ b/translations/vi.md
Author	SHA1	Message	Date
Dave Kerr	beb3d57a6a	feat(pages): update index.html and pages.yaml for deployment Updated the index.html to include a full HTML structure with Bootstrap and Google tag. Modified pages.yaml to deploy from 'build/pages' branch instead of the default branch.	2025-03-08 21:22:41 +00:00
Dave Kerr	decfccdfbc	Merge pull request #435 from dwmkerr/build/test-pages build: test github pages	2025-03-08 20:47:59 +00:00
Dave Kerr	6d904cd9d7	build: test github pages	2025-03-08 20:46:45 +00:00
Dave Kerr	44779074ca	feat: 90-90 rule	2025-02-26 14:17:26 +00:00
Dave Kerr	593fbcbba4	Merge pull request #391 from gurjeet/patch-1 Added Ninety–Ninety Rule	2025-02-26 12:05:25 +00:00
Dave Kerr	85112d267f	Merge branch 'staging' into patch-1	2025-02-26 12:05:00 +00:00
Dave Kerr	9ff8039a43	Merge branch 'marcosValle-patch-1'	2025-02-17 16:46:26 +00:00
Dave Kerr	b9ad4c6f99	feat: twyman's law Merge branch 'patch-1' of github.com:marcosValle/hacker-laws into marcosValle-patch-1	2025-02-17 16:45:35 +00:00
Dave Kerr	4adcc2a090	docs: fix casing	2025-02-11 12:10:19 +00:00
Dave Kerr	eb34ea9a67	docs: minor tweaks to The Ringelmann Effect	2025-02-11 12:07:48 +00:00
Dave Kerr	ae17de2b67	Merge pull request #369 from hliyan/main Added Ringelmann effect	2025-02-11 12:04:01 +00:00
Dave Kerr	31d14b7deb	Merge branch 'main' into main	2025-02-11 12:03:53 +00:00
Dave Kerr	dfc978df13	docs: clean up IPO title	2025-02-04 15:05:26 +00:00
Dave Kerr	8dc1baa919	Merge pull request #432 from dwmkerr/staging staging	2025-02-04 15:03:45 +00:00
Dave Kerr	d66d8afae4	docs: input process output	2025-02-04 15:02:21 +00:00
Dave Kerr	82af717edd	Merge pull request #304 from guettli/patch-1 Added input-processing-output	2025-02-04 14:50:31 +00:00
Dave Kerr	5fd0a88927	Merge pull request #427 from MEgooneh/patch-1 Adding Persian to Translation section	2025-01-02 07:23:41 +00:00
MEGAGON	34a7131aef	Fixing order of local and global languages	2025-01-02 02:30:40 +03:30
MEGAGON	3ce9be6081	Adding Persian to Translation section	2025-01-02 02:25:01 +03:30
Dave Kerr	01402ca31d	Merge pull request #425 from JohnbelMDev/patch-1 Update prepare-markdown-for-ebook.sh	2024-11-14 20:01:29 +11:00
Johnbel Mahautiere	69856f7ab2	Update prepare-markdown-for-ebook.sh Occurrences updata	2024-11-12 10:20:01 -05:00
Dave Kerr	274c008a0a	Merge pull request #415 from emmanuelbernard/patch-1 Minor French typo	2024-01-31 13:08:25 +01:00
Emmanuel Bernard	96bf4635e5	Minor French typo	2024-01-30 16:05:54 +01:00
Dave Kerr	1d0a24e547	Merge pull request #412 from akbarali1/main-1 Fix WikiWiki web	2023-08-08 20:54:35 -07:00
Akbarali	8c3de66940	Update README.md	2023-08-06 17:15:58 +05:00
Dave Kerr	5412cfbde3	Merge pull request #408 from GGuinea/navigation_polish_translation Fix navigation for polish translation.	2023-05-28 08:00:11 -07:00
Gguinea	3adb816f30	Fix navigation for polish translation.	2023-05-27 22:58:21 +02:00
Dave Kerr	2116b5cbd6	Merge pull request #407 from GGuinea/solidny_acrocym_doesn_not_exists	2023-05-26 11:09:02 -07:00
Gguinea	560ff0d9f1	SOLID acronym cannot be translated	2023-05-26 18:17:34 +02:00
Dave Kerr	c03384f370	Merge pull request #406 from tobiasbueschel/patch-1 Update small spelling mistake in .github/workflows	2023-04-05 11:31:08 -04:00
Tobias Büschel	c0ec1b5fdb	Update small spelling mistake in .github/workflows	2023-04-05 22:10:46 +08:00
Dave Kerr	4be482731b	Merge pull request #404 from dwmkerr/feat/principle-of-least-astonishment feat: principle of least astonishment	2023-03-10 11:10:41 +08:00
Dave Kerr	9bd03d8345	Update README.md	2023-03-10 16:10:24 +13:00
Dave Kerr	e4662cbc27	feat: principle of least astonishment	2023-03-10 11:06:50 +08:00
Dave Kerr	80bea4040f	Merge pull request #402 from a0m0rajab/patch-1 Add language contributor - Arabic	2023-01-09 16:19:15 +13:00
Abdurrahman Rajab	87ec516a23	Add language contributor - Arabic	2023-01-01 13:09:15 +03:00
Dave Kerr	6f177f4b46	Merge pull request #399 from gustavothecoder/fix-the-pragmatic-programmer-typo Fix typo: "The Pragmatic Developer" to "The Pragmatic Programmer"	2022-12-05 17:19:42 +13:00
Gustavo Ribeiro	97adc7dbb1	Fix typo: The Pragmatic Developer to The Pragmatic Programmer	2022-12-03 14:47:07 -03:00
Dave Kerr	80e8ccff15	Merge pull request #398 from duongductrong/patch-1 Fix misspelling from "sẫn" to "sẵn"	2022-11-21 14:38:32 +13:00
Dương Đức Trọng	7c92a91988	Fix misspelling from "sẫn" to "sẵn" The word misspelling "sẫn", The correct word is "sẵn"	2022-11-20 23:40:50 +07:00
Dave Kerr	bf758f436a	Merge pull request #376 from thomasmerz/main Added Clarke's three laws for issues/375	2022-08-12 22:14:10 +08:00
Gurjeet Singh	722d79619c	Added Ninety–Ninety Rule	2022-05-01 08:59:35 -07:00
thomasmerz	6b4572f590	Merge branch 'dwmkerr:main' into main	2022-03-14 23:02:25 +01:00
Dave Kerr	e8acd18321	Merge pull request #387 from AmaiSaeta/patch-1 Fix a typo in Japanese translation	2022-03-07 15:54:57 +08:00
Dave Kerr	10937886b7	Merge pull request #388 from hituzi-no-sippo/fix-typo-in-JP Fix typo in JP	2022-03-07 15:54:30 +08:00
hituzi no sippo	6ec4ecf503	Fix typo in JP	2022-03-05 05:02:06 +09:00
天井冴太	c42fa2179e	Fix a typo in Japanese translation	2022-03-05 01:00:47 +09:00
Marcos Valle	f9ff7d844d	Add Twyman's rule for data analysis	2022-02-13 17:39:00 +01:00
Dave Kerr	73010181d9	Merge pull request #381 from gmw/main Minor grammar and punctuation fixes	2022-02-03 12:24:58 +08:00
Magnus Wissler	e24acac797	Minor grammar and punctuation fixes	2022-02-02 15:44:22 +01:00
Dave Kerr	adc57da407	Merge pull request #377 from ohno418/translate-linus-law-in-jp Translate Linus's Law in JP	2022-01-31 06:47:22 -07:00
ohno418	743595fee3	Translate Linus's Law in JP	2022-01-31 19:08:19 +09:00
Thomas Merz	36492867d3	Added Clarke's three laws for issues/375	2022-01-20 13:35:50 +01:00
Dave Kerr	f15e6fdb0c	Merge pull request #373 from truonghoangnguyen/vietnamese add Vietnamese language	2022-01-17 22:33:14 -07:00
guen	a45f5ba757	add Vietnamese language	2022-01-17 15:37:13 +07:00
Dave Kerr	8b280bee13	Merge pull request #372 from wppoland/patch-1 update url	2022-01-16 17:53:17 -07:00
Mariusz Szatkowski	58c08b093b	update url	2022-01-15 14:06:19 +01:00
Dave Kerr	70b03354a8	docs: update table of contents	2022-01-13 13:58:16 +08:00
Dave Kerr	847757c98d	Merge pull request #348 from puremana/law-of-the-instrument Add The Law of the Instrument	2022-01-12 22:56:50 -07:00
Hasitha N. Liyanage	ff00ccc5c3	Update README.md	2022-01-08 20:10:16 +05:30
Hasitha N. Liyanage	269991a7cf	Update README.md	2022-01-08 19:54:27 +05:30
Hasitha N. Liyanage	0baacdbdcc	Update README.md	2022-01-08 19:52:15 +05:30
puremana	619eabc9d2	Add references for quotes	2021-10-05 12:59:16 +13:00
puremana	9baa224340	Add The Law of the Instrument	2021-10-05 12:56:00 +13:00
Thomas Güttler	e96ae13977	Added input-processing-output	2020-08-05 17:25:13 +02:00