From f423817c47465c6fa24595243de19a22c41b07e4 Mon Sep 17 00:00:00 2001 From: Rich Morin Date: Mon, 17 Feb 2020 09:01:04 -0800 Subject: [PATCH 1/5] fix a few copy errors Also note that DRY is strongly related to SSOT (Single Source Of Truth): https://en.wikipedia.org/wiki/Single_source_of_truth --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 43fad2b..49a11ae 100644 --- a/README.md +++ b/README.md @@ -182,7 +182,7 @@ See also: Gall's Law implies that attempts to _design_ highly complex systems are likely to fail. Highly complex systems are rarely built in one go, but evolve instead from more simple systems. -The classic example is the world-wide-web. In it's current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time. +The classic example is the world-wide-web. In its current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time. See also: @@ -205,7 +205,7 @@ Also commonly referenced as: The law states that the measure-driven optimizations could lead to devaluation of the measurement outcome itself. Overly selective set of measures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) blindly applied to a process results in distorted effect. People tend to optimize locally by "gaming" the system in order to satisfy particular metrics instead of paying attention to holistic outcome of their actions. Real-world examples: -- Assert-free tests satisfy the code coverage expectation, despite the metric intent was to create well-tested software. +- Assert-free tests satisfy the code coverage expectation, despite the fact that the metric intent was to create well-tested software. - Developer performance score indicated by the number of lines committed leads to unjustifiably bloated codebase. See also: @@ -544,7 +544,7 @@ The Pareto Principle suggests that in some cases, the majority of results come f In the 1940s American-Romanian engineer Dr. Joseph Juran, who is widely credited with being the father of quality control, [began to apply the Pareto principle to quality issues](https://en.wikipedia.org/wiki/Joseph_M._Juran). -This principle is also known as: The 80/20 Rule, The Law of the Vital Few and The Principle of Factor Sparsity. +This principle is also known as: The 80/20 Rule, The Law of the Vital Few, and The Principle of Factor Sparsity. Real-world examples: @@ -619,7 +619,7 @@ See also: The second of the '[SOLID](#solid)' principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behaviour _extended_, but that their _existing_ behaviour should not be able to be modified. -As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that how existing Markdown features are handled, then it would be _closed_ for modification. +As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed Markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that now existing Markdown features are handled, then it would be _closed_ for modification. This principle has particular relevance for object-oriented programming, where we may design objects to be easily extended, but would avoid designing objects which can have their existing behaviour changed in unexpected ways. From c9b56ed16cb36dab845c60318485a12fe2e5973d Mon Sep 17 00:00:00 2001 From: "James A. Bednar" Date: Mon, 17 Feb 2020 13:54:50 -0600 Subject: [PATCH 2/5] Fixed typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 43fad2b..ea7a63c 100644 --- a/README.md +++ b/README.md @@ -573,7 +573,7 @@ See Also: > Be conservative in what you do, be liberal in what you accept from others. -Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should be aim to allow non-conformant input if it can be processed. +Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should aim to allow non-conformant input if it can be processed. The goal of this principle is to build systems which are robust, as they can handle poorly formed input if the intent can still be understood. However, there are potentially security implications of accepting malformed input, particularly if the processing of such input is not well tested. From 892801c719cb95d18587bb55874865fa2707ff80 Mon Sep 17 00:00:00 2001 From: Feller Ailton Date: Tue, 18 Feb 2020 14:38:16 -0300 Subject: [PATCH 3/5] fix existing pt-BR.md Fixed some typos and grammatical errors. --- translations/pt-BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translations/pt-BR.md b/translations/pt-BR.md index 42cda37..401a4b1 100644 --- a/translations/pt-BR.md +++ b/translations/pt-BR.md @@ -157,7 +157,7 @@ O Ciclo Hype é uma representação visual da empolgação e desenvolvimento da *(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* -Em curto prazo, o cilco sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impácto em potencial. Equipes geralmente entram juntas nessas tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivos. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo". +Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerca de uma nova tecnologia e seu impacto em potencial. Equipes geralmente entram juntas nessas tecnlogias de forma rápida e em alguns casos ficam desapontados com os resutados. Uma das possíveis causas para isso é o fato da tecnologia em questão não ser madura o suficiente, ou aplicações do mundo real que não estão totalmente prontas. Depois de um certo tempo, a capacidade da tecnologia aumenta e oportunidades práticas para uso dela aumentam, as equipes finalmente podem ser produtivas. A citação de Amara resume isso de forma sucinta - "Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo". ### Lei de Hyrum (A lei de interfaces implicitas) @@ -172,7 +172,7 @@ Em curto prazo, o cilco sugere que acontece uma explosão de empolgação a cerc > > (Hyrum Wright) -A lei de Hyrum sugere que quando voce tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API(mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão dependender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários. +A lei de Hyrum sugere que quando você tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API (mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão dependender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários. Veja Também: From 4d5ad3c0c0a9305545eb2573eb71d0e4efd61087 Mon Sep 17 00:00:00 2001 From: Douglas Naphas Date: Tue, 18 Feb 2020 16:41:41 -0500 Subject: [PATCH 4/5] Add nuance to the reference to Yak Shaving Yak Shaving refers to not just a distracting activity, but one that is part of a chain of activities that need to be done before the task at hand can be done. So the activity serving as the distraction is required and is not necessarily trivial, distinguishing it from Bike Shedding. Some references emphasizing the chain-of-prerequisites aspect of Yak Shaving: https://en.wiktionary.org/wiki/yak_shaving https://www.youtube.com/watch?v=NrVbNNOTNus http://projects.csail.mit.edu/gsb/old-archive/gsb-archive/gsb2000-02-11.html I heard, but could not find on recollection, a talk on YouTube from either a Dev Ops conference or a Terraform conference where a parable like the following was related to explain the definition: > You need to change a light bulb. But you don't have a ladder. Your neighbor certainly has one. But they will never lend you their ladder until you return the yak wool sweater that you borrowed from them. Which you lost. But you have a yak in your backyard. So you go out and shave your yak, so you can knit a replacement sweater, so you can borrow a ladder, so you can change a lightbulb. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index ea7a63c..d1828b7 100644 --- a/README.md +++ b/README.md @@ -460,7 +460,7 @@ This law suggests that groups will give far more time and attention to trivial o The common fictional example used is that of a committee approving plans for nuclear power plant, who spend the majority of their time discussing the structure of the bike shed, rather than the far more important design for the power plant itself. It can be difficult to give valuable input on discussions about very large, complex topics without a high degree of subject matter expertise or preparation. However, people want to be seen to be contributing valuable input. Hence a tendency to focus too much time on small details, which can be reasoned about easily, but are not necessarily of particular importance. -The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details. An alternative term is 'Yak Shaving'. +The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details. A related term is '[Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving),' which connotes a seemingly irrelevant activity that is part of a long chain of prerequisites to the main task. ### The Unix Philosophy From 69fe45e96d38a03e1a219298338e85c8890b8c10 Mon Sep 17 00:00:00 2001 From: German Gamboa Gonzalez Date: Wed, 19 Feb 2020 13:38:10 -0500 Subject: [PATCH 5/5] Fixed wrong url on link The current link for the Italian version takes you to the wrong location. This PR fixes that. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 3d35b3a..c230304 100644 --- a/README.md +++ b/README.md @@ -5,7 +5,7 @@ Laws, Theories, Principles and Patterns that developers will find useful. - 🇨🇳 [中文 / Chinese Version](https://github.com/nusr/hacker-laws-zh) - thanks [Steve Xu](https://github.com/nusr)! -- 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)! +- 🇮🇹 [Traduzione in Italiano](https://github.com/dwmkerr/hacker-laws/blob/master/translations/it-IT.md) - grazie [Claudio Sparpaglione](https://github.com/csparpa)! - 🇰🇷 [한국어 / Korean Version](https://github.com/codeanddonuts/hacker-laws-kr) - thanks [Doughnut](https://github.com/codeanddonuts)! - 🇷🇺 [Русская версия / Russian Version](https://github.com/solarrust/hacker-laws) - thanks [Alena Batitskaya](https://github.com/solarrust)! - 🇹🇷 [Türkçe / Turkish Version](https://github.com/umutphp/hacker-laws-tr) - thanks [Umut Işık](https://github.com/umutphp)