Translate to Portuguese - Brazil

en/thing_01/README.md

@@ -12,4 +12,4 @@ If you schedule repayment of the debt in the next iteration, the cost will be mi
 
 Pay off technical debt as soon as possible. It would be imprudent to do otherwise.
 
-By [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose)
+By [Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose)

en/thing_33/README.md

@@ -8,7 +8,7 @@ IEEE floating-point numbers are fixed-precision numbers based on base-two scient
 
 Knowing the spacing in the neighborhood of a floating-point number can help you avoid classic numerical blunders. For example, if you're performing an iterative calculation, such as searching for the root of an equation, there's no sense in asking for greater precision than the number system can give in the neighborhood of the answer. Make sure that the tolerance you request is no smaller than the spacing there; otherwise you'll loop forever.
 
-Since floating-point numbers are approximations of real numbers, there is inevitably a little error present. This error, called *roundoff*, can lead to surprising results. When you subtract nearly equal numbers, for example, the most significant digits cancel each other out, so what was the least significant digit (where the roundoff error resides) gets promoted to the most significant position in the floating-point result, essentially contaminating any further related computations (a phenomenon known as *smearing*). You need to look closely at your algorithms to prevent such *catastrophic cancellation*. To illustrate, consider solving the equation *x<sup>2</sup> - 100000x + 1 = 0* with the quadratic formula. Since the operands in the expression *-b + sqrt(b<sup>2</sup> - 4)* are nearly equal in magnitude, you can instead compute the root *r<sub>1</sub> = -b + sqrt(b<sup>2</sup> - 4)*, and then obtain *r<sub>2</sub> = 1/r<sub>1</sub>*, since for any quadratic equation, ax2 + bx + c = 0, the roots satisfy *r<sub>1</sub>r<sub>2</sub> = c/a*.
+Since floating-point numbers are approximations of real numbers, there is inevitably a little error present. This error, called *roundoff*, can lead to surprising results. When you subtract nearly equal numbers, for example, the most significant digits cancel each other out, so what was the least significant digit (where the roundoff error resides) gets promoted to the most significant position in the floating-point result, essentially contaminating any further related computations (a phenomenon known as *smearing*). You need to look closely at your algorithms to prevent such *catastrophic cancellation*. To illustrate, consider solving the equation *x<sup>2</sup> - 100000x + 1 = 0* with the quadratic formula. Since the operands in the expression *-b + sqrt(b<sup>2</sup> - 4)* are nearly equal in magnitude, you can instead compute the root *r<sub>1</sub> = -b + sqrt(b<sup>2</sup> - 4)*, and then obtain *r<sub>2</sub> = 1/r<sub>1</sub>*, since for any quadratic equation, ax<sup>2</sup> + bx + c = 0, the roots satisfy *r<sub>1</sub>r<sub>2</sub> = c/a*.
 
 Smearing can occur in even more subtle ways. Suppose a library naively computes *e<sup>x</sup>* by the formula *1 + x + x<sup>2</sup>/2 + x<sup>3</sup>/3! + ...*. This works fine for positive *x*, but consider what happens when *x* is a large negative number. The even-powered terms result in large positive numbers, and subtracting the odd-powered magnitudes will not even affect the result. The problem here is that the roundoff in the large, positive terms is in a digit position of much greater significance than the true answer. The answer diverges toward positive infinity! The solution here is also simple: for negative *x*, compute *e<sup>x</sup> = 1/e<sup>|x|</sup>*.
 

pt_br/README.md

@@ -0,0 +1,11 @@
+97 Coisas que todo programador deveria saber
+======
+
+*Pérolas de sabedoria para programadores coletadas pelos principais praticantes.*
+
+
+Este é uma versão [GitBook](https://www.gitbook.io) do projeto ['97 Things Every Programmer Should Know'](http://programmer.97things.oreilly.com/wiki/index.php/97_Things_Every_Programmer_Should_Know).
+
+Todo o conteúdo é licenciado sob a licença [Creative Commons Attribution-NonCommercial-ShareAlike 3.0](http://creativecommons.org/licenses/by-nc-sa/3.0/). Versões impressas do livro estão disponíveis em [Amazon.com](http://www.amazon.com/Things-Every-Programmer-Should-Know/dp/0596809484).
+
+Se você encontrar qualquer erro ou tiver alguma sugstão, você pode [criar uma issue](https://github.com/97-things/97-things-every-programmer-should-know/issues) ou [criar um pull request](https://github.com/97-things/97-things-every-programmer-should-know/pulls) no [repositório](https://github.com/97-things/97-things-every-programmer-should-know).

pt_br/SUMMARY.md

@@ -0,0 +1,100 @@
+# Summary
+
+* [Introdução](README.md)
+1. [Aja com Prudência](thing_01/README.md)
+1. [Aplique princípios de programação funcional](thing_02/README.md)
+1. [Pergunte-se "O que o usuário faria?" (Você não é o usuário)](thing_03/README.md)
+1. [Automatize seu padrão de código](thing_04/README.md)
+1. [A beleza está na simplicidade](thing_05/README.md)
+1. [Antes que você refatore](thing_06/README.md)
+1. [Esteja ciente da sua parte no todo](thing_07/README.md)
+1. [A regra do escoteiro](thing_08/README.md)
+1. [Confira seu próprio código antes de acusar os outros](thing_09/README.md)
+1. [Escolha suas ferramentas com cuidado](thing_10/README.md)
+1. [Desenvolva usando a linguagem do domínio de negócios](thing_11/README.md)
+1. [Código é Design](thing_12/README.md)
+1. [O layout do código é importante](thing_13/README.md)
+1. [Revisão de código](thing_14/README.md)
+1. [Programando com um motivo](thing_15/README.md)
+1. [Um comentário sobre os comentários](thing_16/README.md)
+1. [Comente somente o que o código não diz](thing_17/README.md)
+1. [Aprendizado contínuo](thing_18/README.md)
+1. [Conveniência não é uma qualidade](thing_19/README.md)
+1. [Implemente cedo e frequentemente](thing_20/README.md)
+1. [Faça distinção entre exceções de negócio e exceções técnicas](thing_21/README.md)
+1. [Pratique deliberadamente](thing_22/README.md)
+1. [Linguagens de programação para domínios especializados](thing_23/README.md)
+1. [Não tenha medo de quebrar coisas](thing_24/README.md)
+1. [Não tenha vergonha dos seus dados de teste](thing_25/README.md)
+1. [Não ignore aquele erro!](thing_26/README.md)
+1. [Não aprenda apenas a linguagem, conheça a cultura dela](thing_27/README.md)
+1. [Não bata no seu programa na posição errada](thing_28/README.md)
+1. [Não dependa da "Mágica que acontece aqui"](thing_29/README.md)
+1. [Não se repita](thing_30/README.md)
+1. [Não mexa nesse código!](thing_31/README.md)
+1. [Encapsule comportamentos, não apenas estado](thing_32/README.md)
+1. [Números de ponto flutuante não são reais](thing_33/README.md)
+1. [Satisfaça suas ambições com open source](thing_34/README.md)
+1. [A regra de ouro do projeto de APIs](thing_35/README.md)
+1. [The Guru Myth](thing_36/README.md)
+1. [Hard Work Does not Pay Off](thing_37/README.md)
+1. [How to Use a Bug Tracker](thing_38/README.md)
+1. [Improve Code by Removing It](thing_39/README.md)
+1. [Install Me](thing_40/README.md)
+1. [Inter-Process Communication Affects Application Response Time](thing_41/README.md)
+1. [Keep the Build Clean](thing_42/README.md)
+1. [Know How to Use Command-line Tools](thing_43/README.md)
+1. [Know Well More than Two Programming Languages](thing_44/README.md)
+1. [Know Your IDE](thing_45/README.md)
+1. [Know Your Limits](thing_46/README.md)
+1. [Know Your Next Commit](thing_47/README.md)
+1. [Large Interconnected Data Belongs to a Database](thing_48/README.md)
+1. [Learn Foreign Languages](thing_49/README.md)
+1. [Learn to Estimate](thing_50/README.md)
+1. [Learn to Say "Hello, World"](thing_51/README.md)
+1. [Let Your Project Speak for Itself](thing_52/README.md)
+1. [The Linker Is not a Magical Program](thing_53/README.md)
+1. [The Longevity of Interim Solutions](thing_54/README.md)
+1. [Make Interfaces Easy to Use Correctly and Hard to Use Incorrectly](thing_55/README.md)
+1. [Make the Invisible More Visible](thing_56/README.md)
+1. [Message Passing Leads to Better Scalability in Parallel Systems](thing_57/README.md)
+1. [A Message to the Future](thing_58/README.md)
+1. [Missing Opportunities for Polymorphism](thing_59/README.md)
+1. [News of the Weird: Testers Are Your Friends](thing_60/README.md)
+1. [One Binary](thing_61/README.md)
+1. [Only the Code Tells the Truth](thing_62/README.md)
+1. [Own (and Refactor) the Build](thing_63/README.md)
+1. [Pair Program and Feel the Flow](thing_64/README.md)
+1. [Prefer Domain-Specific Types to Primitive Types](thing_65/README.md)
+1. [Prevent Errors](thing_66/README.md)
+1. [The Professional Programmer](thing_67/README.md)
+1. [Put Everything Under Version Control](thing_68/README.md)
+1. [Put the Mouse Down and Step Away from the Keyboard](thing_69/README.md)
+1. [Read Code](thing_70/README.md)
+1. [Read the Humanities](thing_71/README.md)
+1. [Reinvent the Wheel Often](thing_72/README.md)
+1. [Resist the Temptation of the Singleton Pattern](thing_73/README.md)
+1. [The Road to Performance Is Littered with Dirty Code Bombs](thing_74/README.md)
+1. [Simplicity Comes from Reduction](thing_75/README.md)
+1. [The Single Responsibility Principle](thing_76/README.md)
+1. [Start from Yes](thing_77/README.md)
+1. [Step Back and Automate, Automate, Automate](thing_78/README.md)
+1. [Take Advantage of Code Analysis Tools](thing_79/README.md)
+1. [Test for Required Behavior, not Incidental Behavior](thing_80/README.md)
+1. [Test Precisely and Concretely](thing_81/README.md)
+1. [Test While You Sleep (and over Weekends)](thing_82/README.md)
+1. [Testing Is the Engineering Rigor of Software Development](thing_83/README.md)
+1. [Thinking in States](thing_84/README.md)
+1. [Two Heads Are Often Better than One](thing_85/README.md)
+1. [Two Wrongs Can Make a Right (and Are Difficult to Fix)](thing_86/README.md)
+1. [Ubuntu Coding for Your Friends](thing_87/README.md)
+1. [The Unix Tools Are Your Friends](thing_88/README.md)
+1. [Use the Right Algorithm and Data Structure](thing_89/README.md)
+1. [Verbose Logging Will Disturb Your Sleep](thing_90/README.md)
+1. [WET Dilutes Performance Bottlenecks](thing_91/README.md)
+1. [When Programmers and Testers Collaborate](thing_92/README.md)
+1. [Write Code as If You Had to Support It for the Rest of Your Life](thing_93/README.md)
+1. [Write Small Functions Using Examples](thing_94/README.md)
+1. [Write Tests for People](thing_95/README.md)
+1. [You Gotta Care about the Code](thing_96/README.md)
+1. [Your Customers Do not Mean What They Say](thing_97/README.md)

pt_br/thing_01/README.md

@@ -0,0 +1,17 @@
+# Aja com Prudência
+
+> *"O que quer que você empreenda, aja com prudência e considere as consequências" Anon*
+
+Não importa o quão confortável um cronograma pareça no início de uma iteração, você não pode evitar estar sob pressão algumas vezes. Se você se encontrar tendo que escolher entre "fazer certo" e "fazer rápido" geralmente é mais atraente "fazer rápido" sob o entendimento de que você vai voltar e consertar mais tarde. Quando você faz essa promessa para você mesmo, seu time, e seu cliente, é isso mesmo que você quer dizer. Mas muitas vezes a próxima iteração trás novos problemas e você acaba focando neles. Esse tipo de trabalho adiado é conhecido como débito técnico e não é seu amigo. Especificamente, Martin Fowler chama isso de débito técnico deliberado em sua [taxonomia de débito técnico](http://martinfowler.com/bliki/TechnicalDebtQuadrant.html), que não deve ser confundido com débito técnico inadvertido.
+
+Débito técnico é como um empréstimo: Você se beneficia disso no curto prazo, mas você tem que pagar juros sobre ele até que esteja totalmente pago. Atalhos no código tornam difícil de adicionar _features_ ou refatorar seu código. Eles são criadouros para defeitos e testes que falham com frequência. Quanto mais tempo você o mantiver, pior fica. No momento que você começa a realizar a correção original pode haver uma pilha inteira de decisões de design "não muito corretas" em camadas sobre o problema original, tornando o código muito mais difícil de refatorar e corrigir. De fato, muitas vezes apenas quando as coisas ficam tão ruins que você deve consertá-las, é que você realmente volta para consertar. E, então, muitas vezes é tão difícil corrigir que você realmente não pode pagar pelo tempo ou pelo risco.
+
+Existem momentos que você deve criar débito técnico para cumprir um prazo ou implementar parte de uma _feature_. Tente não estar nessa posição, mas se a situação absolutamente demandar isso, vá em frente. Mas (e isso deve ser um grande MAS) você deve mapear o débito técnico e pagá-lo rapidamente ou as coisas irão rapidamente ladeira abaixo. Assim que você decidir se comprometer, escreva um cartão de tarefa ou registre isso no seu sistema de mapeamento de _issues_ para garantir que não seja esquecido.
+
+Se você programar o pagamento do débito na próxima iteração, o custo será mínimo. Não resolver o débito vai gerar um acúmulo de juros e esses juros devem ser mapeados para tornar o custo visível. Isso enfatizará o efeito sobre o valor de negócio do débito técnico do projeto e permitirá a priorização adequada do pagamento. A escolha de como calcular e mapear os juros vai depender do projeto em particular, mas você deve mapeá-lo.
+
+Resolva o débito técnico assim que possível. Seria imprudente fazer o contrário.
+
+Por [Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose)
+
+https://www.oreilly.com/library/view/97-things-every/9780596809515/ch01.html

pt_br/thing_02/README.md

@@ -0,0 +1,19 @@
+# Aplique princípios de programação funcional
+
+Programação funcional tem desfrutado de um novo interesse da comunidade de programação "mainstream". Parte da razão é devido às "propriedades emergentes" do paradigma funcional estarem preparadas para resolver os desafios colocados pela mudança da nossa indústria em direção ao uso de processadores de múltiplos núcleos. Entretanto, enquanto esse é um uso certamente importante da programação funcional, não é a razão que esse texto tenta te oferecer para conhecer programação funcional.
+
+O domínio do paradigma da programação funcional pode melhorar significativamente a qualidade do código que você escreve em outros contextos. Se você entender profundamentamente e aplicar esse paradigma, seus projetos irão exibir um elevado grau de *transparência referential*.
+
+Transparência referencial é uma propriedade bastante desejável: ela implica que funções produzem consistentemente os mesmos resultados para a mesma entrada, independente de quando e onde essas funções são invocadas. Ou seja, a função depende menos - idealmente não depende - dos efeitos colaterais de um estado mutável.
+
+Uma causa importante de defeitos em código imperativo é atribuída às variáveis mutáveis. O leitor desse texto já deve ter investigado porque algum valor não é o mesmo que o esperado numa dada situação. A semântica de visibilidade pode ajudar a miticar esses defeitos traiçoeiros, ou pelo menos restringir severamente sua localização, mas a verdadeira culpa reside no fato de design de código que aplicam mutabilidade indiscriminada.
+
+E nós certamente não recebemos muita ajuda da indústria nesse aspecto. Introduções à orientação à objetos promovem tacitamente tais designs, porque elas geralmente mostram exemplos compostos por grafos de objetos de vidade relativamente longa que ativam métodos que causam mutações mútuas, que podem ser perigosas. Entretanto, com um design cuidadoso de código dirigido por testes, particularmente quando a regra de mockar papéis e não objetos é seguida ["Mock Roles, not Objects"](http://www.jmock.org/oopsla2004.pdf), a mutabilidade desnecessária é eliminada.
+
+O resultado líquido é um projeto que tipicamente possui melhor responsabilidade nas alocações com mais numerosas e menores funções que atuam nos argumentos passados para elas, ao invés de referenciar variáveis membro mutáveis. Existirão menos defeitos, e estes serão geralmente mais simples de depurar, porque é mais fácil de localizar onde um valor incorreto foi introduzido nesses designs de código do que deduzir o contexto particular que resultou na atribuição de valor errônea. Isso se soma a um grau mais elevado de transparência referencial, e nada é melhor para te ensinar essas ideias que aprender uma linguagem de programação funcional, onde esse modelo de computação é o padrão.
+
+É claro que essa abordagem não é ótima para todas as situações. Por exemplo, em sistemas orientados a objeto, esse estilo geralmente produz melhores resultados quado acoplado ao desenvolvimento do modelo de domínio (ou seja, quando as colaborações servem para reduzir a complexidade das regras de negócio). O mesmo não se observa no desenvolvimento de interfaces de usuário.
+
+Domine o paradigma da programação funcional de forma que você seja capaz de aplicar cuidadosamente as lições aprendidas em outros domínios. Seus sistemas de objetos irão ressoar com boa transparência referencial e serãos mais próximos aos seus pares funcionais do que muitos te farão acreditar. De fato, alguns afirmam que o ápice da programação funcional e da orientação a objetos são meramente um reflexo um do outro, uma forma computacional de yin e yang.
+
+Por [Edward Garson](http://programmer.97things.oreilly.com/wiki/index.php/Edward_Garson)