diff --git a/en/thing_01/README.md b/en/thing_01/README.md
index 3604026b..ba22a46c 100644
--- a/en/thing_01/README.md
+++ b/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)
\ No newline at end of file
+By [Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose)
\ No newline at end of file
diff --git a/en/thing_33/README.md b/en/thing_33/README.md
index 0df4f299..b7fd789a 100644
--- a/en/thing_33/README.md
+++ b/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>*.
 
diff --git a/pt_br/README.md b/pt_br/README.md
new file mode 100644
index 00000000..e123d244
--- /dev/null
+++ b/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).
diff --git a/pt_br/SUMMARY.md b/pt_br/SUMMARY.md
new file mode 100644
index 00000000..88146097
--- /dev/null
+++ b/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. [O mito do guru](thing_36/README.md)
+1. [O trabalho duro não compensa](thing_37/README.md)
+1. [Como usar um gerenciador de bugs](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)
diff --git a/pt_br/thing_01/README.md b/pt_br/thing_01/README.md
new file mode 100644
index 00000000..b1f74550
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/pt_br/thing_02/README.md b/pt_br/thing_02/README.md
new file mode 100644
index 00000000..f0df6367
--- /dev/null
+++ b/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)
\ No newline at end of file
diff --git a/pt_br/thing_03/README.md b/pt_br/thing_03/README.md
new file mode 100644
index 00000000..35cb955b
--- /dev/null
+++ b/pt_br/thing_03/README.md
@@ -0,0 +1,15 @@
+# Pergunte-se "O que o usuário faria?" (Você não é o usuário)
+
+Temos a tendência de supor que as outras pessoas pensam como nós. Mas isso não é verdade. Os psicólogos chamam isso do viés do falso consenso. Quando pessoas pensam ou agem diferente de nós, nós provavelmente as identificamos como defeituosas em alguma medida, pelo menos inconscientemente.
+
+Esse viés explica porque programadores tem dificuldade de se colocar na posição dos usuários. Usuários não pensam como programadores. Primeiro, eles tendem a gastar menos tempo usando computadores. Elea não sabem nem se importam em como um computador funciona. Isso significa que eles não dispoem de um grande número de técnicas de solução de problemas tão familiar aos programadores. Eles não reconhecem os padrões e dicas que os programadores usam para trabalhar com, através e ao redor de uma interface.
+
+A melhor forma de descobrir como os usuários pensam é observar um. Peça a um usuário para completar uma tarefa usando um software similar àquele que você está desenvolvendo. Certifique-se que a tarefa é real: "Adicione uma coluna de números" é OK; "calcule seus gastos no último mês" é ainda melhor. Evite tarefas que são muito específicas, tais como "Você consegue selecionar essas células na planilha e inserir uma fórmula de "SOMA" abaixo?" - existe uma grande pista nessa questão. Leve o usúario a comentar à medida que ele / ela progride na execução da tarefa. Mas não interrompa. Não tente ajudar. Faça perguntas a si mesmo: "Porque ele está fazendo isso?" e "Porque ela não está fazendo aquilo?"
+
+A primeira coisa que você irá notar é que os usuários fazem um conjunto de tarefas centrais de forma muito similar. Eles tentam completar as tarefas na mesma ordem - e eles cometem os mesmos erros nos mesmos pontos. Você deve projetar seu sistema ao redor daquele conjunto de tarefas padrão. Isso é bem distinto das reuniões de "design thinking", onde as pessoas tendem a perguntar "O que acontece se o usuário quiser...?" Isso conduz à funcionalidades muito elaboradas e confusão sobre aquilo que o usuário quer de fato. Observar os usuários elimina essa confusão.
+
+Você verá usuários ficando paralisados ao executar uma tarefa. Quando você se paralisa, você olha ao redor. Quando usuários ficam paralisados, eles reduzem seu foco. Torna-se difícil para eles encontrar a solução em algum outro lugar na tela. Essa é uma das razões porque textos de ajuda são soluções fracas para um design de interface de usuário deficiente. Se você inserir instruções ou texto de ajuda, posicione-os próximo à area problemática. O foco limitado de atenção do usuário é a razão que faz que dicas de ferramentas são melhores que menus de ajuda.
+
+Usuários tendem a se confundir. Eles encontrarão uma forma que funciona e não abrirão mão não importe o quão difícil seja. É melhor fornecer uma maneira realmente óbvia que dois ou três atalhos. Você irá descobrir que existe um gap entre o que os usuários dizem que querem e o que eles de fato querem. É preocupante que a forma normal de coletar requisitos de usuários seja perguntar aos usuários. A melhor forma de capturar requisitos é observar os usuários. Gastar uma hora observando seus usuários é mais informativo do que gastar um dia inteiro imaginando o que eles querem.
+
+Por [Giles Colborne](http://programmer.97things.oreilly.com/wiki/index.php/Giles_Colborne)
\ No newline at end of file
diff --git a/pt_br/thing_04/README.md b/pt_br/thing_04/README.md
new file mode 100644
index 00000000..6cdbdf23
--- /dev/null
+++ b/pt_br/thing_04/README.md
@@ -0,0 +1,20 @@
+# Automatize seus padrões de código
+
+Já aconteceu com você, eu sei. No início de um projeto, todos têm boas intenções - pode chamar de resoluções de "projeto novo". Muito frequentemente, muitas dessas resoluções são escritas em documentos. Aqueles sobre código acabam na seção de padrões de código do projeto. Durante a reunião de lançamento, o desenvolvedor líder percorre o documento e, no melhor caso, todos concordam que tentarão seguir os padrões. Uma vez que o projeto se inicia, no entanto, essas boas intenções são abandonadas, uma por vez. Quando o projeto é finalmente entregue o código parece uma bagunça, e ninguém parece entender como foi que chegou nesse ponto.
+
+Onde foi que as coisas deram errado? Provavelmente já na reunião de lançamento. Alguns membros não prestaram a devida atenção. Outros não entenderam o ponto. Ainda pior, alguns discordaram e já inciaram o planejamento da rebelião aos padrões de código. Finalmente, alguns entenderam o ponto e concordaram mas, quando a pressão no projeto subiu, eles abriram mão de algo. Código bem formatado não te confere pontos com um cliente que quer mais funcionalidade. Aliás, seguir um padrão de códigoode ser uma tarefa muito chata se não for automatizada. Tente, por exemplo, indentar manualmente uma classe bagunçada para experimentar.
+
+Mas se é um problema tão chato, porque insistimos em ter um padrão de código? Uma razão para formatar o código uniformemente é que ninguém deve possuir um pedaço de código apenas pelo estilo de formatação particular. Desejamos prevenir que desenvolvedores usem certos anti-padrões, para assim evitar certos bugs. No final, um padrão de código deve tornar o trabalho mais fácil e auxiliar na manutenção da velocidade de desenvolvimento do início ao fim do projeto. Assim, todos devem concordar com o padrão estabelecido - não contribui se um desenvolvedor usar três espaços para indentação enquanto que outro use quatro. 
+
+Existe uma grande diversidade de ferramentas que podem ser usadas para prodizir relatórios de qualidade de código e para documentar e manter o padrão de código mas essa não é a história completa. Os padrões devem ser automatizados e verificados onde possível. Aqui alguns exemplos:
+
+- Certifique-se que a formatação de código é parte do processo de compilação/ build, de forma que todos rodem automaticamente toda vez que compilação o código. 
+- Use ferramentas de análise estática de código para detectar anti-padrões indesejáveis no código. Se algum anti-padrao for encontrado, quebre o processo de compilação. 
+- Aprenda a configurar essas ferramentas de forma que você possa verificar seus anti-padrões que são particulares ao seu projeto.
+- Não meça apenas a cobertura de testes mas cheque os resultados também. Novamente, quebre o processo de compilação se a cobertura for muito baixa.
+
+Tente fazer isso para tudo aquilo que você considerar importante. Você não será capaz de automatizar tudo o que é importante. Para aqueles itens que não podem ser verificados ou marcados automaticamente, considere-os como um guia suplementar aos padrões de código automatizado mas aceite que você e seus colegas podem não seguir esses itens suplementares tão diligentemente. 
+
+Finalmente, um padrão de código deve ser dinâmico e não estático. À medida que o projeto evolui, as necessidades do projeto mudam e aquilo que parecia inteligente no início não será necessariamente uma escolha inteligente alguns meses depois.
+
+Por [Filip van Laenen](http://programmer.97things.oreilly.com/wiki/index.php/Filip_van_Laenen)
\ No newline at end of file
diff --git a/pt_br/thing_05/README.md b/pt_br/thing_05/README.md
new file mode 100644
index 00000000..d1a0acac
--- /dev/null
+++ b/pt_br/thing_05/README.md
@@ -0,0 +1,26 @@
+# A beleza está na simplicidade
+
+Há uma citação que penso ser particularmente útil que todos os desenvolvedores de software conheçam e mantenham em seus corações:
+
+> *Beleza de estilo e harmonia e graca e bom ritmo depende da simplicidade.* - Platão 
+
+Em um sentença, eu penso que isso resume os valores que nós como desenvolvedores de software devemos aspirar.
+
+Algumas coisas que desejamos ver em nossos códigos:
+
+- Legibilidade 
+- Fácil manutenção 
+- Velocidade de desenvolvimento 
+- A qualidade subjetiva da beleza 
+
+Platão nos diz que o fator habilitador para todas essas qualidades é a simplicidade.
+
+O que é um belo código? Essa é uma questão potencialmente muito subjetiva. Percepção de beleza depende largamente no histórico individual, assim como a nossa percepção de qualquer coisa depende da nossa história. Pessoas com formação em artes tem uma percepção diferente de beleza que as pessoas com formação nas ciências. Formações em artes tendem a abordar a beleza em software pela comparação com obras de arte, enquanto indivíduos com formação em ciência tendem a falar de simetria, razão de ouro, tentando reduzir as coisas a fórmulas matemáticas. Na minha experiência, simplicidade é a fundação da maioria dos argumentos de ambos os lados.
+
+Pense no código-fonte que você estudou. Se você não gastou nada do seu tempo estudando códigos de outras pessoas, pare de ler isso agora e vá buscar algum código-fonte open source pra estudar. Sério! Eu realmente quero que você faça isso! Busque na Internet códigos-fonte da sua linguagem de programação favorita, escrita por alguém conhecido e reconhecidamente um expert.
+
+Já está de volta? Muito bom. Onde estamos? Ah sim... Eu descobri que o código que me agrada e que eu considero bonito tem um número de propriedades em comum. A mais importante dessas é a simplicidade. Descobri que não importa quão complexa a aplicação ou sistema seja, as partes individuais têm que ser mantidas simples. Objetos simples com responsabilidade única contendo métodos simples e focados com métodos bem descritivos. Algumas pessoas pensam que a ideia de ter métodos curtos de cinco a dez linhas de código é uma medida extrema, e algumas linguagens tornam isso muito difícil, mas eu continuo pensando que tal brevidade é um objetivo desejável.
+
+A linha central é que código bonito é código simples. Cada parte individual é mantida simples com responsabilidades simples e relações também simples com outras partes do sistema. Dessa forma seremos capazes de manter nossos sistemas ao longo do tempo, com código limpo, simples, testável, mantendo a velocidade de desenvolvimento elevada durante toda a vida do sistema. A beleza nasce e se encontra na simplicidade.
+
+Por Jørn Ølmheim 
\ No newline at end of file
diff --git a/pt_br/thing_06/README.md b/pt_br/thing_06/README.md
new file mode 100644
index 00000000..0e89abf8
--- /dev/null
+++ b/pt_br/thing_06/README.md
@@ -0,0 +1,19 @@
+# Antes que você refatore
+
+Em algum momento da carreira todo programador precisará refatorar código existente. Mas, antes que você faça isso, por favor pense sobre os seguintes aspectos que podem te economizar um tempo significativo (e sofrimento):
+
+- *A melhor abordagem para reestruturação se inicia por entender a base de código existente e os testes escritos contra ela.* Isso irá te ajudar a entender as forças e fraquezas do código na sua forma atual, de forma que você mantenha os pontos fortes e evite os erros. Nós sempre pensamos que podemos melhorar o sistema existente... até que nós entregamos algo que não só não é melhor - ou até pior - que o código antigo porque falhamos em aprender com as falhas do sistema existente.
+
+- *Evite a tentação de reescrever tudo.* É melhor reusar a maior quantidade de código possível. Não importa quão feio o código é, ele já foi testado, revisado e etc. Jogar fora código velho - especialmente se está em produção - significa que você está jogando fora meses (ou anos) de código testado e estressado que pode ter tido certos ajustes e correções de bugs que você não está ciente deles. Se você não leva isso em conta, o novo código que você escreve pode acabar mostrando os mesmos bugs misteriosos que foram corrigidos no código velho. Isso irá desperdiçar muito tempo, esforço e conhecimento adquirido ao longo dos anos.
+
+- *Muitas mudanças incrementais são melhores que uma mudança massiva.* Mudanças incrementais permitem que você mensure o impacto no sistema mais facilmente através de feedbacks tais como testes. Não é nada agradável ver centenas de testes falhando depois de fazer uma mudança. Isso pode levar à frustração e pressão que podem se tornar em decisões ruins. Alguns testes falhando é uma situação mais fácil de lidar e fornece uma abordagem mais gerenciável.
+
+- *Após cada iteração, é importante garantir que os testes existentes passem.* Adicione novos testes se os testes existentes não forem suficientes para cobrir as mudanças que você fez. Não jogue fora os testes do código antigo sem a devida consideração. No início esses testes podem parecer que não são aplicáveis ao seu novo design, mas pode ser valioso entender profundamente as razões pelas quais um teste em particular foi adicionado.
+
+- *Preferências pessoais e ego não devem ficar no seu caminho.* Se algo não está quebrado, porquê corrigir? O estilo ou a estrutura do código não estar alinhado à sua preferência pessoal não é uma razão válida para reestruturar seu código. Pensar que você irá fazer um trabalho melhor que o programador anterior não é uma razão válida também.
+
+- *Tecnologias novas não são razão suficiente para refatorar.* Uma das piores razões para refatorar é porque o código atual está muito defasado em relação às tecnologias que são modinha atualmente, e nós acreditamos que uma nova linguagem ou framework podem fazer as coisas muito mais elegantes. Ao menos que uma análise de custo benefício mostre que uma nova linguagem irá resultar em melhorias significativas em funcionalidade, facilidade de manutenção ou produtividade, é melhor deixar como está.
+
+- *Lembre-se que humanos cometem erros.* Reestruturar o código não garante que sempre o novo código será melhor - ou mesmo tão bom quanto - que a tentativa anterior. Eu já vi e já participei de várias tentativas de reestruturação mal-sucedidas. Não é bonito mas é algo humano.
+
+Por [Rajith Attapattu](http://programmer.97things.oreilly.com/wiki/index.php/Rajith_Attapattu)
\ No newline at end of file
diff --git a/pt_br/thing_07/README.md b/pt_br/thing_07/README.md
new file mode 100644
index 00000000..1c276fae
--- /dev/null
+++ b/pt_br/thing_07/README.md
@@ -0,0 +1,20 @@
+# Esteja ciente da sua parte no todo
+
+Era meu primeiro projeto na empresa. Tinha concluído minha graduação recentemente e estava ansioso para provar meu valor e fazia horas extras todos os dias para navegar pelo código existente. À medida que eu avançava na minha primeira funcionalidade eu fui super cuidadoso em aplicar tudo aquilo que eu tinha aprendido - comentários, logging, separação de código compartilhado em bibliotecas quando possível e tudo mais. A revisão de código para qual eu me sentia tão preparado veio como um balde de água fria - o reuso era proibido!
+Como poderia ser? Durante toda a faculdade o reuso era visto como o ápice da qualidade em engenharia de software. Todos os artigos que eu li, os livros-texto, os profissionais experientes que me ensinaram. Era tudo aquilo errado?
+
+Descobri que eu estava esquecendo de algo crítico.
+
+Contexto.
+
+O fato que duas partes diferentes do sistema executavam alguma lógica da mesma forma significava menos do que eu pensava. Até o momento que eu havia extraído aquelas bibliotecas de código compartilhado, essas partes não eram co-dependentes. Cada uma evoluía independentemente. Cada parte poderia mudar sua lógica para adequar às necessidades do ambiente de negócios que dependiam daquele sistema. Aquelas quatro linhas de código similar eram acidentais - uma anomalia temporal, uma coincidência. Era, até que eu cheguei.
+
+As bibliotecas de código compartilhado que eu criei criaram acoplamento entre as diferentes partes. Passos a serem tomados por um domínio de negócios não poderiam ser feitos sem primeiro sincronizar com o outro domínio. Custos de manutenção naquelas funções independentes eram desprezíveis mas a biblioteca comum passou a exigir uma ordem de magnitude a mais de testes.
+
+Enquanto eu reduzia o número absoluto de linhas de código no sistema, eu havia aumentado o número de dependências. O contexto dessas dependências é crítico - estivessem restritas à um único local, seria justificável e teria valor positivo. Quando essas dependências não são mantidas em sincronia, seus tentáculos criam acoplamento que causam maiores preocupações ao sistema mesmo que o código por si mesmo parece correto.
+
+Esses erros são traiçoeiros pois, no fundo, eles parecem uma ótima idéia. Quando aplicados ao contexto correto, essas técnicas são valiosas. No contexto errado, elas aumentam o custo ao invés de prover valor. Hoje, quando entro em contato com uma base de código existente sem ter conhecimento do contexto em que as várias partes serão usadas, eu sou muito mais cauteloso com aquilo que deva ser compartilhado entre diferentes partes.
+
+Esteja ciente de sua parte no todo. Cheque seu contexto. Somente então prossiga. 
+
+Por [Udi Dahan](http://programmer.97things.oreilly.com/wiki/index.php/Udi_Dahan)
\ No newline at end of file
diff --git a/pt_br/thing_08/README.md b/pt_br/thing_08/README.md
new file mode 100644
index 00000000..e0b93b34
--- /dev/null
+++ b/pt_br/thing_08/README.md
@@ -0,0 +1,15 @@
+# A regra do escoteiro
+
+Os escoteiros tem uma regra: "Sempre deixe o acampamento mais limpo do que encontrou." Se você encontrar sujeira no chão, limpe independentemente de quem causou a sujeira. Você melhora o ambiente intencionalmente para o próximo grupo de pessoas que forem acampar. Na verdade a forma original dessa regra, escrita por Robert Stephenson Smyth Baden-Powell, o pai do escoterismo, era "Tente deixar esse mundo um pouco melhor do que encontrou".
+
+O que aconteceria se adotássemos uma regra similar em nossos códigos: "Sempre comite um módulo mais limpo que quando você começou a mexer." Não importa quem foi o autor original, o que aconteceria se sempre fizéssemos algum esforço, mesmo que pequeno, para melhorar o módulo. Qual seria o resultado?
+
+Penso que se todos nós seguíssemos essa regra simples, seria o fim da deterioração inevitável dos nossos sistemas de software. Pelo contrário, nossos sistemas iriam melhorar gradualmente à medida que o tempo passasse. Veríamos *times* cuidando do sistema como um todo, ao invés de apenas indíviduos se preocupando com sua pequena parte individual.
+
+Não penso que essa é uma regra muito difícil. Você não precisa fazer todo módulo perfeito antes de comitar. Você precisa apenas fazê-lo *um pouco melhor* do que quando começou. Claro, isso significa que qualquer código que *adicione* a um módulo deve ser limpo. Isso também significa que você limpará ao menos uma outra coisa antes de comitar novamente o módulo. Você pode simplesmente melhorar o nome de uma variáve, ou dividir uma grande funcão em duas funções menores. Você pode quebrar uma dependência circular, ou adicionar uma interface para desacoplar a política do detalhe.
+
+Francamente, isso parece como senso comum para mim - como lavar as mãos após usar o banheiro ou colocar o seu lixo na lixeira ao invés de jogar no chão. O ato de deixar uma bagunça no código deveria ser considerado como socialmente inaceitável assim como é o ato de *jogar lixo no chão*. Deveria ser algo que *nunca é feito*.
+
+Mas é ainda mais do que isso. Cuidar do seu próprio código é uma coisa. Cuidar do código do time é outra completamente diferente. Membros de times ajudam uns aos outros, e limpam as bagunças uns dos outros. Eles seguem a regra do escoteiro porque isso é bom para todos e não só para eles mesmos.
+
+Por [Robert C. Martin (a.k.a. Uncle Bob)](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob)
\ No newline at end of file
diff --git a/pt_br/thing_09/README.md b/pt_br/thing_09/README.md
new file mode 100644
index 00000000..353a94bd
--- /dev/null
+++ b/pt_br/thing_09/README.md
@@ -0,0 +1,22 @@
+# Confira seu próprio código antes de acusar os outros
+
+Todos nós desenvolvedores temos dificuldade em acreditar que nosso próprio código está quebrado. É tão improvável que achamos que deva ser o compilador que tem um erro.
+
+Quando na verdade é muito, muito improvável que o código está falhando por um bug no compilador, interpretador, sistema operacional, servidor de aplicação, banco de dados, gerenciador de memória ou qualquer outra peça de software. Sim, esses bugs existem, mas eles são bem menos comuns do que nós gostamos de acreditar.
+
+Tive uma vez um problema genuíno com o compilador otimizando uma variável de uma estrutura de repetição, mas eu pensei que meu compilador ou sistema operacional tinha um bug em uma frequência muito maior. Já gastei muito do meu próprio tempo, tempo da equipe de suporte e tempo da gestão no processo apenas para me sentir menos idiota cada vez que descobria que o erro era meu no final das contas.
+
+Assumir que as ferramentas são amplamente usadas, maduras e empregadas em várias stacks de tecnologia ajuda a entender que existe pouca razão para duvidar da sua qualidade. Claro, se a ferramente está nas suas versões iniciais, ou usada por poucas pessoas mundialmente, ou uma peça de software pouco baixada, versão 0.1, software de código aberto, existe boas razões para suspeitar. Igualmente uma versão alpha de um software comercial deve ser considerada suspeita. 
+
+Visto que bugs de compiladores são raros, você deve dedicar sua energia e tempo em encontrar seu próprio erro. Todos os conselhos sobre depuração se aplicação, assim, isole o problema, crie chamadas auxiliares, introduza testes; cheque as convenções de chamadas de funções, bibliotecas compartilhadas e números de versão; explique para alguém; olhe para pilha corrompida e tipos de variáveis incoerentes; teste o código em diferentes máquinas e diferentes configurações de compilação. tais como debug e release.
+
+Questione suas próprias suposições e as dos seus colegas. Ferramentas de diferentes empresas devem ter diferentes suposições ou premissas embutidas nelas - assim como diferentes ferramentas da mesma empresa. 
+Quando alguém está relatando um problema que você não pode replicar, vá e veja o que ele está fazendo. Ele pode estar fazendo algo que você nunca pensou ou fazendo algo numa ordem diferente.
+
+Como uma regra pessoal se eu tenho um bug que não consigo resolver e estou começando a pensar que é o compilador, é tempo de olhar a pilha em busca de dados corrompidos. Isso é especialmente verdade se ao adicionar código de tracing o problema muda de lugar.
+
+Problemas multi-thread são outra fonte de bugs que causam cabelos brancos e induzem desespero com o computador. Todas as recomendações para favorecer código simples são multiplicadas quando se trata de um sistema multi-thread. Depuração e testes unitários não podem ser vistos como confiáveis para encontrar esses bugs com qualquer nível de consistência, assim a simplicidade de design é essencial.
+
+Assim antes de correr para acusar o compilador, lembre-se do conselho do Sherlock Holmes: "Uma vez que eliminou o impossível, o que sobra, não importa quão improvável, deve ser a verdade" e prefira ele ao invés da versão do Dirk Gently: "Uma vez que eliminou o improvável, o que sobra, não importa quão impossível, deve ser a verdade.
+
+Por [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly)
diff --git a/pt_br/thing_10/README.md b/pt_br/thing_10/README.md
new file mode 100644
index 00000000..33c77b04
--- /dev/null
+++ b/pt_br/thing_10/README.md
@@ -0,0 +1,30 @@
+# Escolha suas ferramentas com cuidado
+
+Aplicações modernas raramente são construídas do zero. Elas são montadas usando ferramentas existentes - componentes, bibliotecas e frameworks - for um excelente número de razões:
+
+- Aplicações crescem em tamanho, complexidade e sofisticação, enquanto que o tempo disponível para desenvolvê-las reduz. Fazemos melhor uso do nosso tempo como desenvolvedores se nos concentramos mais na escrita de código do domínio de negócios do que código de infraestrutura.
+
+- Componentes muito usados e frameworks tem provavelmente menos bugs do que aqueles desenvolvidos em casa.
+
+- Existe uma grande quantidade de software de altoa qualidade disponível na internet, que significa menores custos de desenvolvimento e maior chance de encontrar desenvolvedores com o interesse e expertise necessário.
+
+- Desenvolvimento de software e sua manutenção é um trabalho humano intensivo, então comprar pode ser mais barato que construir.
+
+No entanto, escolher a combinação correta de ferramentas para sua aplicação pode ser uma tarefa complicada que exige algum pensamento. Ao fazer um escolha, existem algumas coisas que você deve ter em mente:
+
+- Ferramentas diferentes podem depender de diferentes suposições sobre o seu contexto - por exemplo, infraestrutura circundante, modelo de controle, modelo de dados, protocolos de comunicação, etc. - que podem levar à um desalinhamento arquitetural entre a aplicação e as ferramentas. Tal desalinhamento leva à hacks e atalhos que podem tornar o código mais complexo que o necessário.
+
+- Ferramentas diferentes possuem diferentes ciclos de vida, e atualizar uma delas pode se tornar uma tarefa extremamente difícil e demorada visto que as novas funcionalidades, mudanças de design ou mesmo correções de bugs podem causar incompatibilidades com outras ferramentas. Quanto maior o número de ferramentas pior o problema pode se tornar.
+
+- Algumas ferramentas requerem muita configuração, geralmente por meio de um ou mais arquivos XML, que podem sair do controle muito facilmente. A aplicação pode acabar parecendo como se tivesse sido escrita em XML mais algumas poucas linhas estranhas de código em alguma linguagem de programação. A complexidade configuracional irá tornar a aplicação difícil de manter e de evoluir.
+
+- Dependências de fornecedores ocorrem quando o código que depende fortemente de algum produto do fornecedor acaba sendo restrito por eles em várias áreas: capacidade de manutenção, performance, habilidade de evoluir, preço, etc.
+
+- Se você planeja usar software livre, você pode descobrir que ele não é de fato livre. Você pode necessitar comprar suporte comercial, que não será necessariamente barato.
+
+- Termos de licença importam, mesmo para software livre. Por exemplo, em algumas empresas não é aceitável usar software licenciado sob a licença GNU por causa da sua natureza viral - ou seja, software desenvolvido com ele deve ser distribuído junto com seu código-fonte.
+
+Minha estratégia pessoal para mitigar esse problemas é começar pequeno usando somente as ferramentas que são absolutamente necessárias. Usualmente o foco inicial é remover a necessidade de se envolver em programação de infraestrutura de baixo nível (e problemas)
+, por exemplo, usando algum middleware ao invés de usar sockets puros para aplicações distribuídas. E adicionar mais ferramentas se necessário. Eu também tendo isolar as ferramentas externas dos meus objetos do domínio de negócios por meio de interfaces e organização de camadas, de forma que eu possa mudar a ferramenta se necessário com uma pequena quantidade de problemas. Um efeito positivo dessa abordagem é que eu geralmente acabo lidando com aplicações menores que usam menos ferramentas externas que originalmente previsto.
+
+Por [Giovanni Asproni](http://programmer.97things.oreilly.com/wiki/index.php/Giovanni_Asproni)
\ No newline at end of file
diff --git a/pt_br/thing_11/README.md b/pt_br/thing_11/README.md
new file mode 100644
index 00000000..6e78eabd
--- /dev/null
+++ b/pt_br/thing_11/README.md
@@ -0,0 +1,39 @@
+# Desenvolva usando a linguagem do domínio de negócios
+
+Veja duas bases de código. Em uma delas você verá:
+
+```
+if (portfolioIdsByTraderId.get(trader.getId())
+  .containsKey(portfolio.getId())) {...}
+```
+Você irá coçar sua cabeça, se perguntando o que esse código faz. Pode parecer que está obtendo um identificador de um negociador ("trader"), usando-o para obter um mapa de, veja só, aparentemente um mapa de mapas e então verificar se outro identificador de um objeto de portfólio existe no mapa mais interno. Você irá coçar sua cabeça ainda mais. Veja a declaração do portfolioIdsByTraderId e descubra isso:
+
+```
+Map<int, Map<int, int>> portfolioIdsByTraderId;
+```
+
+Gradualmente você passa a notar que pode ser algo relacionado com a possibilidade de um negociador ter acesso a um portfólio específico. E, é claro, você irá encontrar o mesmo fragmento - ou mais provavelmente um fragmento similar mas sutilmente diferente - sempre que alguma coisa se importa sobre se um negociador tem acesso à um portfólio específico.
+
+Em outra base de código você pode se deparar com isso:
+
+```
+if (trader.canView(portfolio)) {...}
+```
+
+Nenhuma confusão mental. Você não precisa saber como o negociador sabe. Talvez exista um desses mapas de mapas embutido em algum lugar interno. Mas isso é preocupação do negociador e não sua.
+
+Qual dessas duas bases de código você preferiria trabalhar?
+
+Há muito tempo atrás tínhamos somente estruturas de dados muito básicas: bits e bytes e caracteres (na verdade apenas bytes mas nós fingimos que são letras e pontuações). Númerosdecimais eram um pouco traiçoeiros porquece nossos números de base 10 não funcionam muito bem em binário, de forma que tínhamos vários tamanhos de tipos de ponto flutuante. Então surgiram os arrays e strings (na verdade apenas arrays diferentes). Então surgiram as pilhas e filas e tabelas hash e listas ligadas e listas de alternações e várias outras esturutras de dados empolgantes que *não existem no mundo real*. "A ciência da computação" era sobre dispender muito esforço para mapear o mundo real nessas estruturas de dados restritivas. Os verdadeiros gurus podem até se lembrar como eles fizeram isso um dia.
+
+Então surgiram os tipos de dados definidos pelos usuários (ou tipos abstratos de dados)! OK, isso não é novidade, mas mudou o jogo de alguma forma. Se o seu domínio contém conceitos como negociadores e portfólios, você pode modelá-los com tipos chamados, veja só, negociadores e portfólio. Mas, mais importante do que isso, você pode modelar *relações entre eles* usando termos do domínio também.
+
+Se você não programa usando os termos do domínio você está criando um entendimento tácido (leia: secreto) que *este* int aqui significa uma forma de identificar um negociador, enquanto *aquele* int ali significa uma maneira de identificar um portfólio. (Melhor seria não misturar os dois!) E se você representa um conceito de negócio ("Alguns negociadores não são autorizados a visualizar alguns portfólios - isto é ilegal") com um bloco de código, como por exemplo uma relação em um mapa de chaves, você não está facilitando a vida dos auditores ou dos responsáveis pelo compliance.
+
+O próximo programador pode não conhecer esse segredo, então porque não torná-lo explícito? Usar uma chave como parâmetro de busca de uma outra chave que executa uma varificação de existência não é terrivelmente óbvio. Como alguém é esperado supor quando uma regra de negócio está inflingindo algum conflito de interesse está implementada?
+
+Tornar os conceitos do domínio de negócio explícitos no seu código significa que outros programadores podem coletar a *inteção* do seu código muito mais facilmente do que tentar regurgitar um algoritmo naquilo que eles entendem sobre um domínio. Também significa que quando o domínio de negócio evolui - o que acontecerá à medida que seu entendimento do domínio cresce - você estará em uma boa condição para evoluir o código. Junto com um bom encapsulamento do código, chances existem que essa regra existirá em um único local no código, e que você pode alterá-la sem que qualquer código dependente saiba.
+
+O programador que chegar alguns meses depois para trabalhar no mesmo código irá te agradecer. Esse programador pode ser você.
+
+Por [Dan North](http://programmer.97things.oreilly.com/wiki/index.php/Dan_North)
\ No newline at end of file
diff --git a/pt_br/thing_12/README.md b/pt_br/thing_12/README.md
new file mode 100644
index 00000000..94d88e0a
--- /dev/null
+++ b/pt_br/thing_12/README.md
@@ -0,0 +1,17 @@
+# Código é Design
+
+Imagine acordar amanhã e descobrir que a indústria da construção civil fez um avanço do século. Milhões de robôs baratos, incrivelmente rápidos, podem fabricar materiais a partir de nada, tem um custo de energia próximo de zero e podem se auto-reparar. E, ainda melhor: Dado um projeto arquitetônico não ambíguo, os robôs podem construir sem intervenção humana a um custo desprezível.
+
+Você pode imaginar o impacto na indústria da construção civil, mas qual é o impacto nas indústrias na porção inicial da cadeia de valor? Como o comportamento de arquitetos e designers mudará se os custos de construção forem desprezíveis? Hoje, modelos físicos e computacionais são construídos e rigorosamente testados antes de serem aplicados na construção civil. Nós nos incomodaríamos se os custos de construção fossem essentialmente gratuitos? Se um edífio colapsa, não há problema - encontre o que houve de errado e teremos nossos robôs mágicos construindo outro. Mas existem implicações adicionais. Com modelos obsoletos, designs inacabados evoluem pela construção repetitiva e pela melhoria em busca do objetivo final. Um observador ocasional pode ter dificuldade em distinguir um design inacabado de um produto final.
+
+Nossa habilidade de prever prazos irá desaparecer. Custos de construção são mais facilmente calculados que custos de design - nós sabemos aproximar o custo de instalar uma viga e quantas vigas nós precisaremos. À medida que as tarefas previsíveis são reduzidas, os tempos de design, menos previsíveis, irão dominar. Os resultados são produzidos mais rapidamente, mas prazos confiáveis não existirão mais.
+
+É claro, as pressões de uma economia competitiva ainda existirão. Com os custos de construção eliminados, uma empresa que pode completar um design rapidamente ganha uma vantagem competitiva no mercado. Obter um design rapidamente torna-se central para as empresas de engenharia. Inevitavelmente, alguém que não seja profundamente familiar com o design verá uma versão invalidada, perceberá a vantagem de entregar mais rápido e dirá "Isso está suficientemente bom".
+
+Alguns projetos de risco serão mais diligentes, mas em muitos casos os consumidores aprenderão a conviver com designs incompletos. Empresas poderão sempre enviar nosssos mágicos robôs para corrigir os edifícios e veículos defeituosos que eles comercializam. Tudo isso aponta para uma conclusão contra-intuitiva: nossa única premissa de uma redução dramática nos custos de construção com o resultado de uma *qualidade pior*.
+
+Não deveria nos surpreender que a história acima aconteceu no desenvolvimento de software. Se aceitarmos que código é design - um processo criativo e não um processo mecânico - a *crise do software* está explicada. Nós temos agora uma *crise de design*: A demanda por designs de qualidade, validados, excede nossa capacidade de criá-los. A pressão para usar designs incompletos é forte.
+
+Felizmente, esse modelo também oferece dicas sobre como podemos aperfeiçoar. Simulações físicas são mapeadas em teste automatizado; design de software não está completo até que seja validado com uma bateria brutal de testes. Fazer tais testes mais efetivos permite que exploremos o amplo espaço de estados dos sistemas grandes. Melhores linguages e práticas de design nos dão alguma esperança. Finalmente, existe um fato inevitável: Grandes designs são produzidos por grandes designers que se dedicam à maestria de sua arte. Código não é diferente disso.
+
+Por [Ryan Brush](http://programmer.97things.oreilly.com/wiki/index.php/Ryan_Brush)
\ No newline at end of file
diff --git a/pt_br/thing_13/README.md b/pt_br/thing_13/README.md
new file mode 100644
index 00000000..4fb8d69b
--- /dev/null
+++ b/pt_br/thing_13/README.md
@@ -0,0 +1,15 @@
+# O layout do código é importante
+
+Há um tempo atrás trabalhei num sistema escrito em Cobol onde o time não tinha permissão de mudar a indendação ao menos que eles tivessem uma razão para alterar o código, pode uma vez alguém causou um bug por introduzir uma linha em uma das colunas especiais no início da linha. Isso era aplicado mesmo que o layout fosse confuso, que algumas vezes era, de tal forma que tinhamos que ler o código muito atentamente porque não poderíamos confiar nele. A política tinha custado uma fortuna em tempo dos programadores.
+
+Existe pesquisa de demonstra que nós todos gastamos muito mais do nosso tempo de programação navegando e lendo código - encontrando *onde* fazer a mudança - que realmente digitando, de forma que isso é aquilo que precisamos otimizar.
+
+- *Fácil de navegar*: As pessoas são muito boas em reconhecimento de padrões visuais (um resquício dos tempos onde nós tínhamos que identificar rapidamente leões nas savanas), de forma que eu posso me ajudar através da ocultação seletiva de tudo aquilo que não é diretamente relevante ao domínio, toda a "complexidade acidental" que vem com a maioria das linguagens comerciais, padronizando. Se o código se comporta da mesma forma que ele se parece, então meu sistema perceptório irá me ajudar a detectar as diferenças. Essa é a razão de observar convenções sobre como organizar partes de uma classe dentro de uma unidade de compilação: constantes, campos, métodos públicos, métodos privados. 
+
+- *Layout expressivo*: Nós aprendemos a tirar o tempo necessário para encontrar os nomes corretos de forma que nosso código se expresse tão claramente quanto possível o que ele faz, ao invés de apenas listar os passos, certo? O layout do código é parte daquela expressividade também. Um primeiro corte é ter a concordância do time num formatador automático para as questões básicas, e então eu possa fazer os ajustes manuais entanto codifico. Ao menos que haja uma discordância ativa, um time irá rapidamente convergir num estilo comum de ajustes manuais. Um formatador pode não entender minhas intenções (Eu devo saver, eu escrevi um anteriormente), e é mais importante para mim que as qebras de linha e os agrupamentos reflitam a intenção do código, não apenas a sintaxe da linguagem (Kevin McGuire me libertou da minha forte ligação com os formatadores automáticos de código.)
+
+- *Formato compacto*: Quanto mais eu conseguir apresentar em uma única tela, mais eu posso ver sem precisar usar muito scroll ou mudança de arquivos, significando que posso manter menos estado na minha mente. Comentários longos em procedimentos e muito espaço em branco fazia sentido para os nomes de 8 caracteres e impressores de linha, mas hoje vivemos em uma IDE (integrated development environment / ambiente integrado de desenvolvimento em Português) que colore as diferentes partes da sintaxe e efetua ligação cruzada entre diferentes partes de código. Eu quero que o layout me ajude a entender o código mas não mais do que isto.
+
+Um amigo que não é programador certa vez notou que o código parece muito com poesia. Eu notei esse mesmo sentimento de códigos muito bem escrito, que tudo no texto tem um propósito e que está lá para me ajudar a entender a idéia. Infelizmente, escrever código não tem a mesma imagem romântica que escrever poesia.
+
+Por [Steve Freeman](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Freeman)
diff --git a/pt_br/thing_14/README.md b/pt_br/thing_14/README.md
new file mode 100644
index 00000000..be3ed0ce
--- /dev/null
+++ b/pt_br/thing_14/README.md
@@ -0,0 +1,15 @@
+# Revisão de código
+
+Você deve fazer revisões de código. Porquê? Porque eles *aumentam a qualidade de código* e *reduzem a taxa de defeitos*. Mas não pelas razões que você está pensando.
+
+Devido às más experiências prévias que alguns desenvolvedores tiveram com revisões de código, muitos tendem a não gostar delas. Eu já vi organizações que exigem que todos os códigos passem por um processo de revisão formal antes de serem implementados em produção. Geralmente é o arquiteto ou desenvolvedor líder que está fazendo essa revisão, uma prática que pode ser chamada de *arquiteto revisa tudo*. Isto é estabelecido em seu manual de desenvolvimento de software, e assim os desenvolvedores devem seguir. Existem algumas organizações que precisam de tais processos rígidos e formais, mas não é a maioria. Na maior parte das organizações, tais abordagens são contraprodutivas. Desenvolvedores sendo avaliados podem se sentir julgados por um comitê de liberdade condicional. Revisores precisam tanto de tempo para ler o código como de tempo para se manterem atualizados com todos os detalhes do sistema, Os revisores podem rapidamente se tornar o gargalo nesse processo, e o processo rapidamente se degenera.
+
+Ao invés de simplesmente corrigir erros no código, o propósito de revisões de código deve ser *compartilhar conhecimento* e estabelecer diretrizes comuns de programação. Compartilhar seu código com outros programadores habilita propriedade coletiva de código. Deixe um membro aleatório *percorrer através do código* com o resto do time. Ao invés de olhar os erros, você deve revisar o código tentando aprender sobre ele e compreendê-lo.
+
+Seja gentil durante revisões de código. Garanta que os comentários são *construtivos e não tóxicos*. Introduza diferente *papéis de revisão* para a reunião de revisão, para evitar ter senioridade organizacional entre os membros afetando a revisão de código. Exemplos de papéis podem incluir um revisor com foco em documentação, outro em exceções, e um terceiro olhando a funcionalidade. Essa abordagem ajuda a espalhar a carga da revisão por todo o time.
+
+Tenha um dia de *revisão de código* a cada semana. Gaste algumas horas em uma reunião de revisão. Rotacione o desenvolvedor sujeito à revisão em cada reunião num padrão de rodízio simples. Lembre de trocar os papéis entre os membros do time a cada revisão também. *Envolva os novatos* em revisões de código. Eles podem ser inexperientes, mas sua formação universitária recente pode fornecer uma perspectiva diferente. *Envolva os especialistas* pela sua experi~encia e conhecimento. Eles irão identificar código propenso a erros mais rápido e com maior acurácia. Revisões de código fluirão melhor se o time tem *convenções de código* que são checadas por ferramentas. Desta forma, formatação de código nunca será discutida durante a reunião de revisão de código.
+
+*Tornar as revisões de código divertidas* é talvez o fator que mais contribui para o seu sucesso. Revisões de código são processos que pessoas estão revisando. Se a reunião de revisão é dolorosa ou não efetiva será difícil motivar qualquer um. Torne uma *revisão de código informal* cujo propósito principal seja compartilhar conhecimento entre os membros do time. Deixe comentários sarcásticos de fora e traga um bolo ou um almoço no lugar.
+
+Por [Mattias Karlsson](http://programmer.97things.oreilly.com/wiki/index.php/Mattias_Karlsson)
\ No newline at end of file
diff --git a/pt_br/thing_15/README.md b/pt_br/thing_15/README.md
new file mode 100644
index 00000000..a17ed6f6
--- /dev/null
+++ b/pt_br/thing_15/README.md
@@ -0,0 +1,25 @@
+# Programando com um motivo
+
+Tentar argumentar sobre corretude de sofware através de resultados manuais numa prova formal que é mais lenta que o código é mais provável que contenha erros que o próprio código em si. Ferramentas automatizadas são preferíveis, mas isso não é sempre possível. O que descrevo a seguir é o caminho do meio: argumentar sobre corretude através de uma abordagem semi-formal.
+
+A abordagem fundamental é dividir todo o código sob consideração em pequenas seções - desde uma linha única, tal como uma chamada de função, a blocos de menos de 10 linhas - e investigar sua corretude. Os argumentos necessitam ser fortes o suficiente para convencer seu companheiro programador que atue como advogado do diabo.
+
+Uma seção deve ser escolhida de forma que em cada ponto o *estado do programa* (em especial, o contador do programa e todos os valores dos objetos "vivos") satisfaçam uma propriedade descrita de forma simples, e que a funcionalidade daquela seção (transformação de estado) seja fácil de descrever como uma tarefa simples - isso fará a argumentação mais simples. Tais propriedades generalizam conceitos como *pré-condições* e *pós-condições* para funções, e *invariantes* para laços de repetição e classes (com respeito às suas instâncias). Buscar atingir seções que sejam independentes umas das outras quanto possível simplifica a argumentação e é indispensável quando essas seções devam ser modificadas posteriormente.
+
+Muitas das práticas de desenvolvimento estabelecidas (embora não sejam igualmente aplicadas na prática) e consideradas 'boas' tornam a argumentação pela corretude mais fácil. Assim, uma vez que se busque verificar a corretude do código, seu pensamento ao escrever novos códigos move-se para um melhor estilo e estrutura. Não surpreendentemente, a maioria dessas práticas podem ser checadas por analisadores estáticos de código:
+
+- Evite usar instruções GO TO que geram interdependência entre partes muito distantes de código.
+- Evite usar variáveis globais mutáveis que também causam que todas as seções que as usam sejam interdependentes.
+- Toda variável deve ter o menor escopo possível. Por exemplo, um objeto local pode ser declarado imediatamente antes do seu primeiro uso.
+- Torne objetos *imutáveis* quando relevante.
+- Torne o código legível através do uso de espaçamento, tanto horizontal quanto verfical. Por exemplo, alinhando estruturas relacionadas e usando linhas em branco para separar duas seções.
+- Torne o código auto-documentável através da boa escolha de nomes descritivos para objetos, tipos e funções, etc.
+- Se precisar de uma seção aninhada, crie uma função para ela.
+- Faça que suas funções sejam curtas e focadas numa única tarefa. O limite antigo de *24 linhas* ainda se aplica. Embora o tamanho e a resolução das telas tenha se alterado, nada mudou na cognição humana desde os anos 1960.
+- Funções devem ter poucos parâmetros (quatro é um bom limite superior). Isso não restringe a comunicação de dados para funções: através do agrupamento de parâmetros relacionados em um único objeto obtém-se o benefício de *invariantes de objeto* e salva na argumentação em quesitos como sua coerência e consistência.
+- Geralmente, cada unidade de código, desde um bloco à uma biblioteca, deve ter uma *interface pequena*. Menos comunicação reduz a argumentação exigida. Isso significa que *acessores de busca de propriedade* que retornam o estado interno são um passivo - não pergunte a um objeto pela informação a ser trabalhada. Ao invés disso, peça ao objeto para fazer o trabalho com a informação que ele já possui. Em outras palavras, *encapsulamento* é tudo - e somente - sobre *interfaces pequenas*.
+- Para preservar os *invariantes* de classe, usos de "acessores de configuração de propriedade* devem ser evitados, visto que eles permitem que os invariantes sejam invalidados.
+
+A argumentação pela corretude de código traz como vantagem uma maior compreensão. Comunique os aprendizados que você adquiriu para o benefício de todos.
+
+Por [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi)
diff --git a/pt_br/thing_16/README.md b/pt_br/thing_16/README.md
new file mode 100644
index 00000000..431971e6
--- /dev/null
+++ b/pt_br/thing_16/README.md
@@ -0,0 +1,15 @@
+# Um comentário sobre os comentários
+
+Na minha primeira matéria na graduação, meu professor entregou duas folhas de papel com códigos BASIC. No quadro, a tarefa dizia "Escreva um programa para ler a entrada de 10 jogos de boliche e retorne a média." Depois disso o professor saiu da sala. Quão difícil pode ser isso? Eu não lembro da minha solução final mas estou certo que tinha um loop `FOR/NEXT' nele e não devia ser mais do que 15 linhas no total. Folhas de código - para vocês mais novos que estão lendo isso, sim, nós usávamos escrever o código à mão antes de realmente entrar com ele no computador - permitiam cerca de 70 linhas de código cada. Eu estava muito confuso sobre o porquê o professor teria nos dado duas folhas de papel. Visto que minha escrita à não sempre havia sido muito ruim, eu usei a segunda folha para reescrever meu código de forma mais organizada, na esperança de ganhar alguns pontos extras pelo estilo.
+
+Tamanha foi minha surpresa, quando recebi o trabalho de volta no início da próxima aula, eu recebi uma nota apenas um pouco maior que a mínima para aprovação. (Isso viria a ser um presságio para mim para o resto do meu tempo na graduação.) Passei o olho no topo da folha que havia reescrito o código, e tinha a pergunta "Sem comentários?"
+
+Não era suficiente que o professor e eu ambos sabíamos o que o programa deveria fazer. Parte do ponto da tarefa era me ensinar que meu código deve ser auto-explicativo para o próximo programador que viria depois de mim. Foi uma lição que eu não me esqueci.
+
+Comentários não são malignos. Eles são tão necessários para programação como as estruturas para ramificação ou de repetição. A maior parte das linguagens modernas tem uma ferramenta como o javadoc que irá processar comentários formatados apropriadamente e construir automaticamente um documento da API. Esse é um bom começo mas não suficiente. Dentro do seu código devem haver explicações sobre o código é esperado fazer. Codificar segundo um ditado antigo, "Se foi difícil para escrever, deve ser difícil para ler", faz um desserviço para seu cliente, seu empregador, seus colegas e até para você mesmo.
+
+Por outro lado, você pode ir bem longe com seus comentários. Certifique-se que seus comentários esclarecem seu código mas não tornem ele mais obscuro. Salpique seu código com comentários relevantes, explicando o que seu código é esperado fazer. Seus comentários de cabeçalho devem permitir a qualquer programador ter informação suficiente para usar seu código sem ter que lê-lo completamente, enquanto que os comentários de linha deve suportar o próximo programador a corrigir algum bug ou alterá-lo.
+
+Em um emprego que tive, eu discordei de uma decisão de design feita por aqueles acima de mim. Sentindo um tanto sarcástico, como jovens programadores geralmente se sentem, eu copiei o texto do e-mail que me instruía a usar o design proposto no comentário do cabeçalho daquele arquivo. Porém os gerentes nessa empresa em particular de fato revisaram o código que eu escrevi quando eu comitei o código. Foi minha primeira introdução ao termo "movimento limitante de carreira"
+
+Por [Cal Evans](http://programmer.97things.oreilly.com/wiki/index.php/Cal_Evans)
\ No newline at end of file
diff --git a/pt_br/thing_17/README.md b/pt_br/thing_17/README.md
new file mode 100644
index 00000000..ee6bfdc0
--- /dev/null
+++ b/pt_br/thing_17/README.md
@@ -0,0 +1,13 @@
+# Comente somente o que o código não diz
+
+A diferença entre teoria e prática é maior na prática que na teoria - uma observação que certamente se aplica aos comentários. Em teoria, a ideia geral de comentar código parece bem razoável: oferecer ao leitor detalhes, uma explicação do que está acontecendo. O que pode ser mais útil que ser útil? Na prática, entretanto, comentários geralmente se tornam uma praga. Assim como com qualquer outra forma de escrita, existe uma habilidade para escrever bons comentários. Muito da habilidade é saber quando não escrevê-los.
+
+Quando o código é mal formado, compiladores, interpretadores e outras ferramentas emitirão erros e alertas. Se o código está de alguma forma funcionalmente incorreto, revisões, análise estática, testes e o uso diário no ambiente de produção irá trazer a maior parte dos bugs à luz. E comentários? No livro *Elements of Programmaing Style*, Kernighan e Plauger notaram que "um comentário é de valor nulo ou negativo se estiver errado." E ainda tais comentários poluem o código e sobrevivem numa base de código de uma forma que erros de código nunca sobreviveriam. Eles fornecem uma fonte de distração e desinformação, um prejuízo sutil mas constante nas atividades de pensamento do programador.
+
+E se os comentários não são tecnicamente incorretos, mas não adicionam nenhum valor ao código? Tais comentários são apenas ruído. Comentários que repetem o que o código já fala (como um papagaio) não oference nada extra para o leitor - afirmar uma vez no código e outra em linguagem natural não torna a afirmação mais verdadeira ou mais real. Código comentado não é código executável, e não tem nenhum efeito útil para o leitor ou para o runtime. Também se torna desatualizado muito rápido. Comentários relativos à versão e código comentado tentam resolver as questões de versionamento e histórico. Essas questões já foram resolvidas, bem mais efetivamente, pelas ferramentas de controle de versão.
+
+Um predomínio de comentários ruidosos e comentários incorretos em uma base de código encorajam programadores a ignorarem todos os comentários, seja por apenas os evitarem ou pela tomada de medidas ativas para ocultá-los. Programadores são ricos de recursos e irão evitar a todo custo qualquer coisa percebida como danosa: colapsando comentários; alterando o esquema de cores que forma que os comentários e o fundo sejam da mesma cor; uso de scripts para filtrar os comentários. Para recuperar uma base de código de tais usos inadequados da engenhosidade dos programadores, e para reduzir o risco de evitar quaisquer comentários genuínos, comentários devem ser tratados como se fossem código. Cada comentário deve adicionar algum valor ao leitor, de outra forma é somente lixo que deve ser removido ou reescrito.
+
+O que então qualifica como valor? Comentários devem dizer algo que o código faz mas não fala explicitamente. Um comentário explicando uma parte de código deve dizer em seguida é um convite à mudar a estrutura do código ou as convenções de codificação de forma que o código fale por si mesmo. Ao invés de compensar nomes ruins de métodos ou classes, renomeie eles. Ao invés de comentar seções em funções longas, extraia menores funções cujos nomes capturem a intenção das seções originais. Tente se expressar o máximo possível através de código. Qualquer coisa que não seja possível de descrever no código é um bom candidato para um comentário útul. Comente o que o código não é capaz de dizer, não simplesmente o que ele não diz atualmente.
+
+Por [Kevlin Henney](http://programmer.97things.oreilly.com/wiki/index.php/Kevlin_Henney)
\ No newline at end of file
diff --git a/pt_br/thing_18/README.md b/pt_br/thing_18/README.md
new file mode 100644
index 00000000..7d9082c4
--- /dev/null
+++ b/pt_br/thing_18/README.md
@@ -0,0 +1,28 @@
+# Aprendizado contínuo
+
+Nós vivemos em tempos interessantes. À medida que desenvolvimento de software se torna distribuído ao redor do mundo, você descobre que existe muitas pessoas capazes de executar seu trabalho. Você precisa se manter atualizado para permanecer empregável. De outro modo, você se tornará um dinossauro, preso no mesmo trabalho até que, um dia, você não será mais necessário ou seu trabalho será terceirizado para alguma empresa mais barata.
+
+Então, o que você faria sobre isso? Alguns empregadores são generosos o suficiente para fornecer treinamento para expandir seu conjunto de habilidades. Outros podem não ser capazes de obter tempo ou dispor de dinheiro para qualquer treinamento. Para estar seguro com sua empregabilidade, você precisa assumir a responsabilidade pela sua própria educação.
+
+Aqui uma lista de formas para se manter aprendendo. Muitos desses recursos podem ser encontrados na internet gratuitamente:
+
+- Leia livros, revistas, blogs, feeds to Twitter e sites. Se desejar se aprofundar em um assunto, considere assinar uma mailing list ou um grupo de notícias.
+- Se você deseja imergir numa tecnologia, se envolva diretamente - escreva código.
+- Sempre tente trabalhar com um mentor, uma vez que ser a pessoa mais senior pode dificultar sua educação. Embora você possa aprender de qualquer pessoa, você pode aprender bem mais de alguém mais inteligente ou mais experiente que você. Se você não pode encontrar um mentor, considere uma mudança na sua carreira.
+- Use mentores virtuais. Encontre autores e desenvolvedores na web que você realmente goste e leia tudo que eles escrevem. Assine o blog deles.
+- Conheça os frameworks e bibliotecas que utiliza. Conhecer como alguma coisa funciona faz com que você a use melhor. Se forem open source, você realmente é um sortudo. Use o depurador para percorrer o código para ver o que está debaixo do capô. Você verá código escrito e revisado por pessoas realmente inteligentes.
+- Quando cometer um erro, corrigir um bug ou encontrar um problema, tente realmente entender o que aconteceu. É provável que alguém já se deparou com esse mesmo problema e postou em algum lugar na internet. O Google é realmente útil aqui.
+- Uma forma muito boa de aprender é ensinar ou falar sobre algum assunto. Quando as pessoas te ouvem ou perguntam questões a você, você será motivado a aprender. Tente um almoço com aprendizado no trabalho, um grupo de usuários ou uma conferência local.
+- Entre para um grupo de estudo ou comece um (à la comunidade de padrões) ou um grupo de usuários local de um linguagem, tecnologia ou disciplina que você estiver interessado.
+- Vá a conferências. E se não puder ir, muitas delas tem seu conteúdo disponível online, gratuitamente.
+- Longo tempo no trânsito para o trabalho? Ouça podcasts.
+- Já rodou uma ferramenta de análise estática sobre uma base de código ou olhou os alertas na sua IDE? Entenda o que está sendo relatado e porquê.
+- Siga os conselho do [The Pragmatic Programmers](http://www.pragprog.com/titles/tpp/the-pragmatic-programmer) e aprenda uma nova linguagem a cada ano. Ao menos aprenda uma nova tecnologia ou ferramenta. Abrir novos ramos de exploração te traz noovas ideias que você pode usar na sua stack de tecnologia atual.
+- Nem tudo o que você aprende deve ser sobre tecnologia. Aprenda o domínio que você está trabalhando de forma que você possa melhor entender os requisitos e ajudar a resolver os problemas do negócio. Aprenda a ser mais produtivo - como trabalhar melhor - é outra boa opção.
+- Volte para a escola.
+
+Seria leval ter a capacidade que o Neo tinha em Matrix e simplesmente baixar as informações que precisamos em nossos cérebros. Mas não temos, então é necessário um comprometimento por um tempo. Você não tem que gastar cada hora acordado aprendendo algo. Uma pequena fração de tempo, a cada semana, é melhor que nada. Existe (ou deveria existir) uma vida fora do trabalho.
+
+Tecnologia muda rápido. Não fique para trás.
+
+Por [Clint Shank](http://programmer.97things.oreilly.com/wiki/index.php/Clint_Shank)
\ No newline at end of file
diff --git a/pt_br/thing_19/README.md b/pt_br/thing_19/README.md
new file mode 100644
index 00000000..c96ad31c
--- /dev/null
+++ b/pt_br/thing_19/README.md
@@ -0,0 +1,21 @@
+# Conveniência não é uma qualidade
+
+Muito tem se falado sobre a importância e os desafios do design de boas API's. É difícil acertar da primeira vez e é ainda mais difícil mudar depois. Muito parecido com a educação dos filhos. A maioria dos programadores experientes aprendeu que uma boa API segue um nível consistente de abastração, exibe consistência e simetria, e forma o vocabulário para uma linguagem expressiva. Aliás, estar consciente dos princípios não se traduz automaticamente em comportamento apropriado. Comer doces é ruim para você.
+
+Ao invés de pregar do alto, eu quero selecionar uma estratégia de design de APIs particular, uma que eu encontro com frequência: o argumento da conveniência. Começa tipicamente com um dos 'insights' a seguir:
+
+- Eu não quero que outras classes tenham que fazer duas chamadas separadas para executar essa atividade.
+- Porque eu faria outro método se ele é quase igual ao método existente? Adicionarei apenas um 'switch'.
+- Veja, é muito fácil: se o segundo parâmetro do tipo string termina com ".txt", o método automaticamente assume que o primeiro parâmetro é um nome de arquivo, de forma que eu não preciso de dois métodos.
+
+Embora sejam bem-intencionados, tais argumentos são sujeitos a diminuir a legibilidade do código usando a API. Uma invocação de método como:
+
+```
+parser.processNodes(text, false);
+```
+
+é virtualmente sem sentido sem que se conheça a implementação ou ao menos a documentação seja consultada. Esse método foi provavelmente projetado para a conveniência do implementador em oposição à conveniência do usuário - "Eu não quero que o usuário tenha que fazer duas chamadas separadas" traduzido em "Eu não quis escrever dois métodos separados." Não existe nada fundamentalmente errado com a conveniência se ela for construída para ser o antídoto ao tédio, bagunça ou estranhamento. Entretanto, se pensarmos um pouco mais cuidadosamente, o antídodo para esses sintomas é a eficiência, consistência e elegância, não necessariamente a conveniência. Espera-se que APIs escondam a complexidade interna, de forma que podemos realisticamente esperar que bons designs de API exijam algum esforço. Um método grande pode ser certamente mais conveniente de escrever que um conjunto bem planejado de operações, mas seria mais fácil de usar?
+
+A métafora da API como uma linguagem pode nos guiar em direção à melhores decisões de projeto nessas situações. Uma API deve prover uma linguagem expressiva, que dà à próxima camada vocabulário suficiente para fazer e responder perguntas úteis. Isso não implica que ela deveria fornecer apenas um método, ou verbo, para cada questão relevante. Um vocabulário diverso permite-nos expressar sutilezas em significado. Por exemplo, nós preferimos correr ao invés de andar, mesmo que as duas possam ser vistas como a mesma operação, executadas em diferentes velocidades. Um vocabulário de API consistente e bem planejado torna o código fácil de entender e expressivo na próxima camada acima. Mais importante, um vocabulário composto permite outros programadores usarem a a API em formas que você pode não ter antecipado - uma grande conveniência para os usuários da API! Na próxima vez que você se ver tentado a mesclar várias coisas em um único método da API, lembre-se que a língua inglesa não tem uma palavra para `MakeUpYourRoomBeQuietAndDoYourHomeWork`, mesmo que isso pareça importante para tal operação frequente.
+
+Por [Gregor Hohpe](http://programmer.97things.oreilly.com/wiki/index.php/Gregor_Hohpe)
\ No newline at end of file
diff --git a/pt_br/thing_20/README.md b/pt_br/thing_20/README.md
new file mode 100644
index 00000000..c46502d5
--- /dev/null
+++ b/pt_br/thing_20/README.md
@@ -0,0 +1,15 @@
+# Implemente cedo e frequentemente
+
+Resolver problemas de implementação e da instalação é deixado geralmente para o final de um projeto.
+. Em alguns projetos, escrever as ferramentas de instalação é delegado a um engenheiro especializado em lançamentos que recebe a tarefa como um "mau necessário". Revisões e demonstrações são feitas de um ambiente cuidadosamente preparado para assegurar que tudo funciona. O resultado é que o time não absorve nenhuma experiência com o processo de implementação ou com o ambiente já implementado até que seja muito tarde para fazer mudanças.
+
+O processo de instalação / implementação é a primeira coisa que o cliente vê, e um processo simples de instalação / implementação é o primeiro passo para ter um ambiente de produção confiável ou, ao menos, fácil de depurar. O software implementado é aquilo que o cliente irá ver. Ao não garantir que a implementação da aplicação seja feita corretamente, você irá gerar questões com seu cliente antes que eles usem seu software integralmente.
+
+Começar seu projeto com um processo de instalação te dará tempo para evoluir o processo à medida que o ciclo de desenvolvmento de produto avança, e a chance de fazer mudanças no código da aplicação para tornar a instalação mais fácil. Rodar e testar o processo de instalação num ambiente limpo periodicamente também fornece uma checagem que você não assumiu premissas no código que dependenm do ambiente de desenvolvimento ou teste.
+Deixar a implementação por último significa que o processo de implementação pode se tornar mais complicado para contornar as premissas no código. O que parecia uma grande idéia numa IDE, onde você tem controle total sobre um ambiente, pode fazer um processo de implementação muito mais difícil. É melhor saber todos os prós e contras mais cedo do que no último minuto.
+
+Embora "estar apto para implementar" não pareça ter muito valor de negócio quando comparado à aplicação rodando num laptop do desenvolvedor, a verdade é que até que você possa demonstrar a aplicação no ambiente alvo, existe muito trabalho antes de entregar valor para o negócio. Se seu raciocínio para postergar a implementação porque ela é trivial, então faça a implementação de imediato visto que é de baixo custo. Se for muito complicada, ou se tiver muitas incertezas, faça o que faria com o código da aplicação: experimente, avalie, e refatore o processo de implementação à medida que for avançando.
+
+O processo de instalação/desenvolvimento é essencial para a produtividade dos seus clientes ou do seu time de serviços profissional, de forma que você deve testar e refatorar esse processo à medida que você avança. Testamos e refatoramos o código fonte ao longo do projeto. O processo de implementação merece o mesmo tratamento.
+
+Por [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk)
diff --git a/pt_br/thing_21/README.md b/pt_br/thing_21/README.md
new file mode 100644
index 00000000..df242bb4
--- /dev/null
+++ b/pt_br/thing_21/README.md
@@ -0,0 +1,17 @@
+# Faça distinção entre exceções de negócio e exceções técnicas
+
+Existem basicamente duas razões para as coisas darem errado em execução: problemas técnicos que nos impede de usar a aplicação e lógica de negócio que evita que abusemos da aplicação. A maioria das linguagens modernas, como LISP, Java, Smalltalk e C#, usam exceções para sinalizar ambas situações. Entretanto, essas duas situações são tão diferentes que elas deveriam ser cuidadosamente mantidas separadas. É fonte potencial de confusão representar ambas usando a mesma hierarquia de exceções e ainda pior se usar a mesma classe de exceção.
+
+Um problema técnico não solucionável pode acontecer quando existe um erro de programação. Por exemplo, se tentar acessar o elemento 83 de um vetor com tamanho 17, o programa estará claramente descontrolado e alguma exceção deve ser lançada. Uma versão mais sutil é chamar código de uma biblioteca com argumentos inapropriados, provocando a mesma situação dentro da biblioteca.
+
+Seria um grande erro tentar resolver essas situações auto-inflingidas. Ao invés disso, nós deixamos a exceção subir até o mais alto nível arquitetural e um mecanismo genérico de tratamento de exceção fará o necessário para garantir que o sistema está num estado seguro, tal como o roll back de uma transação, registrar log e alertar a administração e relatar a situação de volta para o usuário, de forma gentil.
+
+Uma variante dessa situação ocorre quando você está na situação da biblioteca e o chamador quebrou o contrato do seu método, e.g. passando um argumento totalmente bizarro ou não configurando um objecto dependente apropriadamente. Isso é bem parecido com o elemento 83º de um vetor com 17 elementos: o chamador deveria ter checado; não fazer a checagem é um erro do programador do lado do cliente. A resposta adequada é lançar uma exceção técnica.
+
+Uma situação diferente, mas ainda técnica, acontece quando o programa não pode avançar por causa de um problema no ambiente de execução, tal qual um banco de dados que não responde. Nessa situação você deve assumir que a infraestrutura fez o possível para resolver a situação - reparando a conexão e tentando um certo número de vezes - e então falhado definitivamente. Mesmo que a causa seja diferente, a situação para o código que está chamando é similar: existe pouco que possa ser feito sobre isso. Então, nós sinalizamos a situação através de uma exceção e deixamos ela subir a pilha até ser capturada num mecanismo de tratamento de exceção genérico.
+
+Diferente dos exemplos anteriores, nós temos a situação onde você não pode completar uma chamada devido à uma razão lógica do domínio. Nesse caso, nós encontramos uma situação que existe uma exceção, ou seja, não usual e indesejável, mas não é bizarra ou programaticamente errada. Por exemplo, se eu tentar sacar dinheiro de uma conta com fundos insuficientes. Em outras palavras, esse tipo de situação é uma parte do contrato, e lançar uma exceção é apenas um *caminho de retorno alternativo* que é parte do modelo e que o cliente deve estar ciente e preparado para tratar. Para essas situações é apropriado criar uma excepção específica ou uma hierarquia separada de exceções de forma que o cliente possa tratar da situação nos seus próprios termos.
+
+Misturar exceções técnicas e exceções de negócio na mesma hierarquia torna difusa a distinção e confunde o chamador sobre quais os contratos do método, quais condições são exigidas e quais situações são esperadas de serem tratadas. Separar os casos traz clareza e aumenta a chance que as exceções técnicas sejam tratadas pelo framework da aplicação, enquanto que as exceções do domínio de negócio são consideradas e tratadas pelo código do cliente.
+
+Por [Dan Bergh Johnsson](http://programmer.97things.oreilly.com/wiki/index.php/Dan_Bergh_Johnsson)
\ No newline at end of file
diff --git a/pt_br/thing_22/README.md b/pt_br/thing_22/README.md
new file mode 100644
index 00000000..08172757
--- /dev/null
+++ b/pt_br/thing_22/README.md
@@ -0,0 +1,25 @@
+# Pratique deliberadamente
+
+Prática deliberada não é simplesmente executar uma tarefa. Se você se perguntar "Porque estou executando essa tarefa?" e sua resposta for "para completar essa tarefa" então você não estará praticando deliberadamente.
+
+Você pratica deliberadamente para aprimorar sua habilidade de executar uma tarefa. É sobre habilidade e técnica. Prática deliberada significa repetição. Significa executar a tarefa com o objetivo de aumentar sua maestria em um ou mais aspectos da tarefa. Significa repetir a repetição. Lentamente, de novo e de novo. Até que se alcance seu nível desejado de maestria. Você pratica deliberadamente para dominar a tarefa e não para completar a tarefa.
+
+O principal objetivo do desenvolvimento remunerado é finalizar um produto enquanto que o principal objetivo da prática deliberada é melhorar sua performance. Não são objetivos iguais. Pergunte-se, quanto do seu tempo você dedica a desenvolver o produto de outra pessoa? Quanto você dedica a se desenvolver?
+
+Quanto de prática deliberada é necessário para adquirir experiência?
+
+- Peter Norvig [escreve](http://norvig.com/21-days.html) que "Pode ser que 10,000 horas [...] seja o número mágico."
+- No livro *Leading Lean Software Development* Mary Poppendieck nota que "Pessoas de alto desempenho necessitam de um mínimo de 10,000 horas de prática deliberada para se tornar um especialista."
+
+A experiência se desenvolve gradualmente ao longo do tempo - não chega toda de uma vez na 10,000-ésima hora! No entanto, 10,000 horas é bastante: cerca de 20 horas por semana por 10 anos. Dado esse nível de comprometimento você pode estar preocupado em não ser um especialista. Você é. A grandeza é majoritariamente uma questão de escolha consciente. *Sua escolha.* Pesquisa das duas últimas décadas tem apresentado que o principal fator na aquisição de experiência é o tempo gasto em práticas deliberadas. Habilidades inatas *não* são o principal fator.
+
+- Mary: "Existe amplo consenso entre os pesquisadores de alto desempenho que os talentos inatos não correspondem a um fator relevante; você precisa ter uma quantidade mínima de habilidade natural para iniciar em um esporte ou profissão. Depois disso, as pessoas que alcançam excelência são aquelas que trabalham duro."
+
+Existe pouco valor em praticar deliberadamente aquilo que você já é um especialista. Prática deliberada significa praticar algo que você ainda não é bom.
+
+- Peter: "A chave [para o desenvolvimento da experiência] é a prática deliberada: não apenas fazer repetidamente, mas se desafiar com uma tarefa que está ligeiramente acima da sua habilidade atual, tentando novamente, avaliando seu desempenho durante a execução e após ela, e corrigir qualquer erro." 
+- Mary: "Prática deliberada não significa fazer aquilo em que você é bom; significa se desafiar, fazer aquilo que você não é bom. Então não é necessariamente divertido."
+
+Prática deliberada é sobre aprendizado. Sobre aprendizados que te transformam; aprendizado que muda seu comportamento. Boa sorte.
+
+Por [Jon Jagger](http://programmer.97things.oreilly.com/wiki/index.php/Jon_Jagger)
\ No newline at end of file
diff --git a/pt_br/thing_23/README.md b/pt_br/thing_23/README.md
new file mode 100644
index 00000000..d7d1dadc
--- /dev/null
+++ b/pt_br/thing_23/README.md
@@ -0,0 +1,15 @@
+# Linguagens de programação para domínios especializados
+
+Quando ouvir uma discussão de especialistas em qualquer domínio, sejam eles enxadristas, professores do ensino infantil ou corretores de seguro, irá notar que o seu vocabulário é muito diferente da linguagem do dia a dia. Esse vocabulário é o que chamamos de linguagens de domínios especializados: um domínio específico tem um vocabulário especializado para descrever as coisas que são particulares daquele domínio.
+
+No mundo de desenvolvimento de software, DSLs (sigla do acrônimo em inglês - Domain-Specific Languages) são expressões executáveis em uma linguagem específica do domínio com vocabulário e gramática limitados que é legível, compreensível e - com sorte - redigível por especialistas do domínio. DSLs direcionadas para desenvolvedores de software ou cientistas já existem há bastante tempo. Por exemplo, as 'pequenas linguagens' do Unix encontrada nos arquivos de configuração e as linguagens criadas com o poder das macros do LISP são alguns dos exemplos mais antigos.
+
+DSLs são classificadas comumente como *internas* ou *externas*:
+
+- **DSLs internas** são escritas numa linguagem de programação de propósito geral cuja sintaxe foi forjada para parecer com linguagens naturais. Isso é mais fácil de ser feito para linguages que oference mais açucares sintátivos e habilidades de formatação (p. ex. Ruby e Scala) que para linguagens que não oferecem essas facilidades (p. ex. Java). A maior parte das DSLs internas empacota APIs existentes, bibliotecas ou código de negócio e fornece esse envelope para ser mais fácil acessar essas funcionalidades. Elas são executáveis diretamente pela simples execução delas. Dependendo da implementação e do domínio, elas são usadas para construir estruturas de dados, definir dependências, executar processos ou tarefas, comunicar com outros sistemas, ou validar entradas de usuários. A sintaxe de uma DSL interna é restringida pela linguagem hospedeira. Existem muitos padrões - p. ex. construtor de expressões, encadeamento de métodos e anotações - que podem facilitar que você forje a linguagem para a sua DSL. Se a sua linguagem não exige recompilação, uma DSL interna pode ser desenvolvida rapidamente trabalhando lado a lado com um especialista de domínio.
+
+- **DSLs externas** são expressões textuais ou gráficas da linguagem - embora DSLs textuais sejam mais predominantes que as gráficas. Expressões textuais podem ser processadas por uma cadeia de ferramentas que inclui o processador léxico, um parser, um transformador de modelo, geradores e qualquer tipo de pós-processamento. DSLs externas são lidas em modelos internos que forma a base do processamento posterior. É útil definir uma gramática (p. ex. em EBNF). Uma gramática fornece o ponto de partida para as partes geradoras da cadeira de ferramentas (p. ex. editor, visualizador, gerador do parser). Para DSLs simples, um parser feito à mão pode ser suficiente - usando por exemplo expressões regulares. Parsers customizados podem se tornar imprevisíveis se a solicitação for muito alta e então faz sentido olhar para ferramentas projetadas especificamente para trabalhar com gramáticas de linguages e DSLs - p. ex., openArchitectureWare, ANTlr, SableCC, AndroMDA. Definir DSLs externas como dialetos XML é também muito comum, embora a legibilidade é geralmente um problema - especialmente para leitores não técnicos.
+
+Você deve sempre levar em conta a audiência da sua DSL. São desenvolvedores, gerentes, clientes internos do seu negócio ou usuários finais? Você tem que adaptar o nível técnico da linguagem, as ferramentas disponíveis, ajuda sintátiva (p. ex. intellisense), validação antecipada, visualização e representação para a sua audiência pretendida. Ao ocultar os detalhes técnicos, DSLs podem empoderar usuários ao dar-lhes a habilidade de adaptar sistemas à suas necessidades sem o envolvimento direto dos desenvolvedores. Pode também acelerar o desenvolvimento por causa da distribuição potencial de trabalho depois que o framework inicial da linguagem está desenvolvido. A linguagem podem ser aprimorada gradualmente. Existem também diferentes caminhos para migração para expressões existentes e gramáticas disponíveis.
+
+Por [Michael Hunger](http://programmer.97things.oreilly.com/wiki/index.php/Michael_Hunger)
\ No newline at end of file
diff --git a/pt_br/thing_24/README.md b/pt_br/thing_24/README.md
new file mode 100644
index 00000000..e9e958ae
--- /dev/null
+++ b/pt_br/thing_24/README.md
@@ -0,0 +1,13 @@
+# Não tenha medo de quebrar coisas
+
+Todo mundo com experiência na indústria certamente trabalhou em um projeto onde a base de código era bastante precária. O sistema está mal estruturadp e mudar uma coisa sempre quebra outra funcionalidade não relacionada. Sempre que um módulo é adicionado, o desenvolvedor deve tentar mudar o mínimo possível e segurar a respiração durante toda nova versão. Esse é o equivalente no mundo de software a jogar o jogo da torre e está fadado a um desastre possível.
+
+A razão que fazer mudanças é não estressante deve-se ao sistema estar doente. Ele necessita de um médico ou então só irá piorar. Você já sabe o que está errado com seu sistema mas está com medo de quebrar os ovos para fazer uma omelete. Um cirurgião experiente sabe que os cortes são necessárias para fazer a cirurgia mas ele também sabe que os cortes são temporários e irão cicatrizar. O resultado final da operação vale a dor inicial e o paciente deve alcançar um melhor estado em relação ao momento pré-operatório.
+
+Não tenha medo do seu código. Quem se importa se alguma coisa torna-se disfuncional enquanto você move as coisas de lugar? O medo paralisante da mudança é o que causou esse estado de coisas no seu projeto. Investir tempo para refatorar irá ter vários benefícios sobre o ciclo de vida do seu projeto. Um benefício extra é que sua experiência de lidar com o sistema doente fará todo o time se tornar especialista em entender como ele *deveria* funcionar. Aplique esse conhecimento antes de se ressentir dele. Trabalhar em um sistema que você odeie não é como qualquer pessoa deveria gastar seu tempo de vida.
+
+Redefina suas interfaces internas, reestruture módulos, refatore código copiado e simplifique seu design através da redução de dependências. Você pode reduzir significativamente a complexidade do código pela eliminação dos casos extremos que geralmente resulta em funcionalidades acopladas de forma inapropriada. Migre lentamente da estrutura antiga para a nova realizando testes ao longo do caminho. Tentar uma grande refatoração irá causar problemas suficientes que farão você reconsiderar abandonar o esforço no metade, inacabado.
+
+Seja o cirurgião que não tem medo de cortar as partes doentes para criar oportunidades de cura. A atitude é contagiosa e irá inspirar outros a trabalhar nesse projetos de limpeza que eles estavam adiando por muito tempo. Mantenha uma lista de tarefas de "higienização" que o time sinta que são relevantes para o bem comum do projeto. Convença a gestão que mesmo que essas tarefas não produzam resultados visíveis, elas irão reduzir as despesas e acelerar a liberação de versões futuras. Nunca pare de cuidar da saúde geral do código.
+
+Por [Mike Lewis](http://programmer.97things.oreilly.com/wiki/index.php/Mike_Lewis)
\ No newline at end of file
diff --git a/pt_br/thing_25/README.md b/pt_br/thing_25/README.md
new file mode 100644
index 00000000..97f27ad9
--- /dev/null
+++ b/pt_br/thing_25/README.md
@@ -0,0 +1,26 @@
+# Não tenha vergonha dos seus dados de teste
+
+> *Eu estava atrasado. Coloquei algum dado esdrúxulo para testar o layoyt da página que eu estava trabalhando.*
+
+> *Apropriei o nome dos membros do The Clash para dar nomes aos usuários. Nomes de empresas? Títulos de canções do the Sex Pistols poderiam servir a esse propósito. Agora eu preciso de algumas siglas de ações - apenas quatro letras em maiúsculas.*
+
+> *Usei aquelas palavras de baixo calão.*
+
+> *Parecia inofensivo. Apenas para me divertir, e talvez também os outros desenvolvedores do dia seguinte antes que eu colocasse a fonte de dados reais.*
+
+> *No dia seguinte, o gerente de projetos obteve algumas capturas de tela para fazer uma apresentação.**
+
+A história da programação é rica de exemplos dessas histórias de guerra. Coisas que os desenvolvedores e designers pensaram que ninguém mais veria se tornaram visíveis inesperadamente.
+O tipo de vazamento pode variar mas, quando acontece, pode ser mortal para a pessoa, time ou empresa responsável. Os exemplos incluem:
+
+- Durante uma reunião de status, um cliente clica no botão que estava pendente de implementação. A mensagem de alerta dizia: "Não clique no botão novamente, seu idiota."
+- Um programador mantendo um sistema legado foi avisado para incluir uma caixa de diálogo de erro e decide usar a saída do sistema de logs interno como conteúdo. Usuários são surpreendidos com mensagens como "Santa falha de comit do banco de dados, Batman!" quando alguma coisa quebra.
+- Alguém mistura as interfaces de administração do ambiente de teste e de produção e faz algumas entradas de dados "engraçados". Os clientes visualizam um serviço de 1 milhão de dólares em desconto na loja online. O nome? Massagista pessoal com formato do Bill Gates"
+
+Citando um ditado antigo que diz que "uma mentira pode viajar ao redor do mundo enquanto a verdade ainda está calçando seus sapatos", atualmente um deslize pode viajar pelo Twitter antes que um desenvolvedor no fuso horário correto esteja acordado para fazer qualquer correção.
+
+Mesmo seu código fonte não é necessariamente livre de escrutínio. Em 2004, quando um arquivo compactado do código fonte do Windows 200 apareceu em redes de compartilhamento de arquivos, algumas pessoas vasculhou em busca de palavras profanas, insultos e [outros conteúdos engraçados](http://www.kuro5hin.org/story/2004/2/15/71552/7795). (O comentário `// TERRÍVEL HORRÍVEL NADA BOM MUITO RUM HACK` se tornou usual no meu uso ocasional desde então!)
+
+Em resumo, ao escrever qualquer texto no seu código - seja comentário, logs, caixas de diálogo ou dados de teste - sempre se pergunte como irá parecer se esse texto se tornar público. Economizará alguns vexames ao redor.
+
+Por [Rod Begbie](http://programmer.97things.oreilly.com/wiki/index.php/Rod_Begbie)
\ No newline at end of file
diff --git a/pt_br/thing_26/README.md b/pt_br/thing_26/README.md
new file mode 100644
index 00000000..47c6e8ab
--- /dev/null
+++ b/pt_br/thing_26/README.md
@@ -0,0 +1,45 @@
+# Não ignore aquele erro!
+
+> *Eu estava pela rua certa noite para encontrar alguns amigos em um bar. Não tomávamos uma cerveja juntos há algum tempo e eu estava querendo vê-los novamente. Naquela correria, eu não estava olhando para o caminho. tropecei no meio-fio e caí de cara no chão. Bem, serviu para aprender a prestar atenção, eu assumo.*
+
+> *Machucou minha perna mas eu estava atrasado para encontrar meus amigos. Então me levantei e segui o caminho. À medida que eu caminhava a dor estava ficando pior. Embora eu tivesse achado que era apenas um choque, rapidamente notei que havia algo de errado.*
+
+> *Consegui checar no bar de qualquer forma. Já estava agonizando na hora que cheguei. Não tive uma boa noite, porque fui terrivelmente distraído. Na manhã seguinte, fui ao médico e descobri que quebrei o osso da canela. Caso tivesse parado quando senti a primeira dor, teria evitado muito dano adicional que eu causei ao seguir andando. Foi, provavelmente, a pior manhã do dia seguinte da minha vida.*
+
+Muitos programadores escrevem código da mesma forma que minha noite desastrada.
+
+*Erro, que erro? Não deve ser sério. Honestamente. Posso ignorá-lo.* Essa não é uma estratégia vencedora para código robusto. No ato, isso é apenas preguiça. (O tipo errado de preguiça). Não importa quão improvável você pense que exista um erro no seu código, você deve sempre procurar por ele e sempre tratá-lo. Toda vez. Você não está economizando tempo se não fizer isso: você está armazenando problemas potenciais para o futuro.
+
+Nós relatamos erros em nosso código em um certo número de formas, incluindo:
+
+- **Códigos de retorno** podem ser usados como o valor resultante da função para indicar que "não funcionou." Códigos de erro são muito fáceis de ignorar. Você não verá nada no código para realçar o problema. Adicionalmente, tornou-se prática padrão ignorar alguns valores de retorno de funções padrão na linguagem C. Quão frequentemente você confere o valor de retorno da função printf?
+- **errno** é uma aberração curiosa de C, uma variável global separada destinada a sinalizar um erro. É fácil de ignorar, difícil de usar, e leva a toda sorte de problemas indesejáveis - por exemplo, o que acontece quando múltiplas threads chamam a mesma função? Algumas plataformas isolam você da dor aqui; outras não.
+
+- **Exceções** são uma forma mais estruturada, suportada pelas linguagens de programação, de sinalizar e manipular erros. E você não pode ignorá-las. Ou pode? Já vi muito código como esse:
+
+```
+try {
+    // ...do something...
+}
+catch (...) {} // ignore errors
+```
+
+A lição dessa construção horrível é que ela ressalta o fato que você está fazendo algo moralmente duvidoso.
+
+E você ignora um erro, fecha os olhos para ele, e finge que nada está errado, você está correndo grandes riscos. Da mesma forma que minha perna acabou em um estado pior do que seria caso tivesse parado de andar imediatamente, seguir em frente ignorando os erros de código pode levar a falhas muito complexas. Lide com os problemas na primeira oportunidade. Mantenha-os sob controle.
+Não tratar adequadamente os erros conduz a:
+
+- **Código frágil.** Código que está cheio de bugs difíceis de encontrar.
+- **Código inseguro.** Hackers geralmente exploram tratamento de erro inadequado para invadir sistemas de software.
+- **Estrutura pobre.** Se existem erros no seu código que são tediosos de lidar, você provavelmente tem uma interface pobre. Expresse-se melhor de forma que os erros sejam menos intrusivos e seu tratamento seja menos custoso.
+
+Da mesma forma que você deve checar todos os erros em potencial no seu código, você precisa expor todas as condições potencialmente errôneas nas suas interfaces. Não as esconda, fingindo que seus serviços irão sempre funcionar.
+
+Porque você não checa os erros? Existe um número de desculpas comuns. Quais dessas você concorda? Como resolver cada uma delas?
+
+- Tratamento de erro polui o fluxo do código, tornando-o mais difícil de ler e mais complicado de entender o fluxo normal de execução.
+- É trabalho extra e eu tenho um prazo apertado.
+- Sei que essa chamada de função *nunca* retornará um erro (printf sempre funciona, malloc sempre retorna nova memória - se eles falharem teremos problemas ainda maiores...) .
+- É somente uma prova de conceito e não precisa ser reescrito para implementação em produção.
+
+Por [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe)
diff --git a/pt_br/thing_27/README.md b/pt_br/thing_27/README.md
new file mode 100644
index 00000000..aa699bca
--- /dev/null
+++ b/pt_br/thing_27/README.md
@@ -0,0 +1,13 @@
+# Não aprenda apenas a linguagem, conheça a cultura dela
+
+No ensino médio, eu tive que aprender uma língua estrangeira. No momento que pensei que já estaria de bom tamanho ser bom em Inglês eu escolhi dormi por três anos nas aulas de Francês. Alguns anos depois, fui para a Tunísia de férias. Árabe é o idioma oficial lá e, sendo uma ex-colônia francesa, o Francês também é comumente usado. Inglês só é falado nas áreas mais turísticas. Devido à minha ignorância linguística, eu me deparei lendo *Finnegans Wake* à beira da piscina, uma obra de James Joyce, com toda sua força na forma e na linguagem. A mistura diversidade de Joyce de mais de quarenta idiomas era surpreendente mas ao mesmo tempo uma experiência exaustiva. Descobrir como palavras estrangeiras e frases entrelaçadas proporcionavam ao autor novas formas de se expressar é algo que guardei para mim na minha carreira de desenvolvedor.
+
+Em seu livro seminal, *The Pragmatic Programmer*, Andy Hunt e Dave Thomas nos encorajam a aprender uma nova linguagem de progração todo ano. Tentei aplicar esse conselho e ao longo dos anos eu tive a experiência de programar em várias linguagens. Minha lição mais importante das minhas aventuras poliglotas é que é preciso mais do que apenas aprender a sintaxe para aprender uma linguagem de programação: Você precisa entender sua cultura. Você pode escrever Fortran em qualquer linguagem, mas para aprender verdadeiramente uma linguagem você tem que abraçá-la. Não crie desculpas se seu código em C# é um longo método Main com a maior parte de seus métodos estáticos como Helpers mas aprender porque as classes fazem sentido. Não se intimide se foi muito difícil aprender expressões lambdas usadas em programação funcional, force-se a usá-las.
+
+Assim que você aprender os modos de funcionamento de uma nova linguagem, você se surpreenderá em como você começará a usar as linguagens que já conhece em novas formas. Eu aprendi a usar delegados em C# através da programação em Ruby, o potencial libertador dos tipos genéricos em .NET me deu ideias em como usar os tipos genéricos em Java de forma mais útil e LINQ fez aprender Scala mais leve.
+
+Você também terá uma melhor compreensão dos padrões de projeto ao caminhar entre diferentes linguagens. Os programadores que usam C descobrem que C# e Java tornaram o padrão do iterador uma commodity. Em Ruby e outras linguagens dinâmicas você pode ainda usar um visitante mas sua implementação não se parecerá com a que você viu no livro da Gangue dos Quatro.
+Alguns podem argumentar que *Finnegans Wake* é difícil de ler, enquanto outros o aplaudem por sua beleza estilística. Para tornar a leitura mais amena, existem traduções para uma única língua. Ironicamente, a primeira dessas traduções foi feita em Francês. Código é de várias formas similar. Se você escreve código *Wakese* com um pouco de Python, um pouco de Java e uma pitada de Erlan, seus projetos serão uma bagunça. Se, por outro lado, você explora novas linguagens para expandir sua mente e aprender novas ideias para solução de problemas de diferentes formas, você descobrirá que o código que escreve na sua linguagem favorita se tornará mais bonito a cada nova linguagem que você aprender.
+
+
+Por Anders Norås
\ No newline at end of file
diff --git a/pt_br/thing_28/README.md b/pt_br/thing_28/README.md
new file mode 100644
index 00000000..9a0a7001
--- /dev/null
+++ b/pt_br/thing_28/README.md
@@ -0,0 +1,20 @@
+# Não bata no seu programa na posição errada
+
+Uma vez escrevi um quiz falso de C++, no qual eu satiricamente sugeri a seguinte estratégia para tratamento de exceções:
+
+> Espalhando um número suficiente de estruturas `try...catch` através da nossa base de código, algumas vezes somos capazes de prevenir nossas aplicações de abortar. Pensamos no estado resultando como "posicionar o defundo na posição vertical".
+
+A despeito da minha leviandate, eu estava na verdade resumindo uma lissão que recebi ajoelhoado aos pés da Dama da Má Experiência.
+
+Era uma classe para uma aplicação básica, para uma biblioteca de C++ caseira. Ela sofreu de várias tentativas de diferentes programadores ao longo dos anos: Nenhuma das mãos está efetivamente limpa. Contina código para lidar com todas as exceções para todos os cenários imagináveis. Com apoio do nosso líder técnico, decidimos, ou sentimos (*decidimos* implica mais análise que a que colocamos na construção desse monstro), que uma instância dessa classe deveria viver para sempre ou morrer na tentativa.
+Para esse fim, intercalamos múltiplos tratamentos de excecão. Nós misturamos ao tratamento estruturado do Windows com o tipo nativo (lembra do `__try...__except` in C++? Eu também não). Quando as coisas se comportaram de forma insperada, tentamos chamar a mesma função ou método novamente, filtrando ainda mais os parâmetros. Em retrospectiva, gosto de pensar que ao escrever uma estrutura de tratamento de exceção `try...catch` dentro da sentença catch de um outro tratamento de exceção, algum tipo de consciência aparece para indicar que eu posso ter acidentalmente tomado uma estrada escorregadia e chegado ao nível lunático. Entretanto, isso é provavelmente sabedoria retrospectiva.
+Não preciso dizer que quando algo dá errado nas aplicações baseadas nessa classe, as evidências todas somem como vítimas da máfia em um porto, não deixando nenhum rastro de bolhas para indicar o que houve, e nem as rotinas de *dump* que se esperava registrar o desastre foram acionadas. Eventualmente, registramos o que foi feito e experimentamos uma vergonha. Substituímos a bagunça completa com um mecanismo mínimo e robusto de relatórios. Mas isso apenas após vários *crashes*.
+
+Eu não te importunaria com isso - certamente ninguém mais poderia ser tão estúpido como nós formos - mas devido a uma discussão online que tive recentemente com um rapaz cujo título acadêmico declarava que ele já devia saber.
+Estávamos discutindo um código Java em um transação a remota. Se o código falhase, ele argumentava, ele deve capturar e bloquear a exceção *in situ*. ("E então fazer o quê com ela?" Eu perguntei. "Cozinhá-la para a janta?")
+
+Ele citou a regra dos designers de interface: NUNCA DEIXE O USUÁRIO VER UM RELATÓRIO DE EXCEÇÃO, como se isso tivesse esgotado o assunto e com tudo em letras maiúsculas. Pensei que se ele pudesse ter sido responsável pelo código em um desses caixas de banco que dão tela azul e decoram posts de blogs depreciativos e tivesse sido permanentemente traumatizado.
+
+De qualquer forma, se encontrá-lo, balance a cabeça, sorria e siga adiante à medida que você desvie para a saída.
+
+Por [Verity Stob](http://programmer.97things.oreilly.com/wiki/index.php/Verity_Stob)
\ No newline at end of file
diff --git a/pt_br/thing_29/README.md b/pt_br/thing_29/README.md
new file mode 100644
index 00000000..74d44092
--- /dev/null
+++ b/pt_br/thing_29/README.md
@@ -0,0 +1,19 @@
+# Não dependa da "Mágica que acontece aqui"
+
+Se você olhar para qualquer atividade, processo ou disciplina a uma longa distância ela irá parecer simples. Gerentes sem nenhum experiência de desenvolvimento pensam que o que os programadores fazem é simples e programadores sem nenhuma experiência de gestão pensam o mesmo de seus gerentes.
+Programação é algo que algumas pessoas fazem - em parte do tmepo. E a parte difícil - o pensar - é a parte menos visível e menos apreciada pelos não iniciados. Existiram muitas tentativas de eliminar a necessidade desse pensamento qualificado nas últimas décadas. Um dos mais antigos e mais memoráveis esforços foi feito por Grace Hopper para tornar as linguagens menos crípticas - que alguns previram iria remover a necessidade de programadores especialistas. O resultado (COBOL) contribuiu com a renda de muitos programadores nas décadas subsequentes.
+A visão persistente que o desenvolvimento de software pode ser simplificado através da remoção da programação é, para os programadores que entendem o que está envolvido, obviamente ingênuo.
+
+Em qualquer projeto existem muitas atividades que um programador individual não se envolve: levantamento de requisitos de usuários, obter aprovação de orçamentos, configurar o servidor de build, implementar a aplicação nos ambientes de QA e Produção, migração de negócios de processos ou programas antigos, etc.
+
+Quando você não está ativamente envolvido nessas atividades existe uma tendência inconsciente de assumir que elas são simples e acontecem "por mágica". Enquanto a mágica continua acontecer é fantástico. Mas quando - é usualmente "quando" e não "se" - a mágica para o projeto entra em risco.
+
+Eu conheci projetos que perderam semanas de tempo do desenvolvedor porque ninguém entendia como eles dependiam na "versão correta" de uma DLL carregada. Quando as coisas começaram a falhar intermitente os membros do time procuravam em todos os lugares antes que alguém notou que "uma versão errada" da DLL estava sendo carregada.
+
+Outro departamento estava operando de forma suave - projetos entregues no prazo, nenhuma sessão de debuggin em altas horas, sem correções de emergências. Tão suave, de fato, que a alta liderança decidiu que as coisas "funcionavam sozinhas" e que elas poderiam rodar sem o gerente de projetos. Após seis meses os projetos no departamento pareciam como os demais departamentos da organização - atrasados, com bugs e sendo continuamente corrigidos.
+
+Você não tem que entender toda a mágica que faz seu projeto funcionar mas não te machuca saber parte dela - ou apreciar alguém que entende as partes que você não entende.
+
+Mais importante. certifique-se que quando a mágica parar ela possa ser reiniciada.
+
+Por [AlanGriffiths](http://programmer.97things.oreilly.com/wiki/index.php/AlanGriffiths)
\ No newline at end of file
diff --git a/pt_br/thing_30/README.md b/pt_br/thing_30/README.md
new file mode 100644
index 00000000..7959f581
--- /dev/null
+++ b/pt_br/thing_30/README.md
@@ -0,0 +1,27 @@
+# Não se repita
+
+De todos os princípios de programação, Não se repetir (DRY para a sigla em inglês - Don't Repeat yourself) talvez seja o mais fundamental. O princípio foi formulado por Andy Hunt e Dave Thomas no livro *O programador pragmático*, e serve de base de muitos outras melhores práticas de desenvolvimento de software e princípios de projeto. O desenvolvedor que aprende a reconhecer a duplicação, e entende como eliminá-la através da prática apropriada e da abstração adequada, podem produzir código muito mais limpo que aquele que injeta repetição desnecessária continuamente.
+
+Duplicação é desperdício
+---
+
+Toda linha de código que é criada para uma aplicação deve ser mantida, e é uma fonte potencial de bugs no futuro. A duplicação incha desnecessariamente a base de código, resultando em mais oportunidades para bugs e para adição de complexidade acidental para o sistema. O inchaço que a duplicação adiciona ao sistema também faz ser mais difícil para os desenvolvedores que estejam trabalhando com o sistema possam entender completamente todo o sistema, ou estarem seguros que as mudanças feitas em um local não necessitam também de serem feitas em outros locais que duplicam a lógica que está sendo alterada. DRY exige que "todo pedaço de conhecimento deve ter uma única, não ambígua e definitiva representação dentro de um sistema.
+
+A repetição em um processo é sinal para automação
+---
+
+Muitos processos em desenvolvimento de software são repetitivos e facilmente automatizados. O princípio DRI aplica-se nesse contexto bem como no código-fonte da aplicação. Teste manual é lento, sujeito a erros e difíceis de serem reptidos e então suítes de testes automatizados devem ser usadas, se possível. Integrar software pode ser demorado e sujeito a erros se feito manualmente, e então um processo de compilação deve ser executado sempre que possível, idealmente em todo o check-in. Onde processos manuais doloridos existem que possam ser automatizados, eles devem ser automatizados e padronizados. O objetivo é assegurar que exista apenas uma forma de realizar a tarefa e que seja tão pouco dolorido quanto possível.
+
+A repetição na lógica é um sinal para abstração
+---
+
+Repetição em partes lógicas pode assumir muitos formatos. Lógica *if-then* ou *switch-case* copiada é uma das mais fáceis de detectar e corrigir. Muitos padrões de projeto tem o objetivo explícito de reduzir ou eliminar a duplicação na lógica dentro de uma aplicação. Se um objeto requer tipicamente várias coisas prontas antes de ser usado, isso pode ser conseguido com uma fábrica abstrata ou um método-fábrica. Se um objeto tem muitas variações possíveis em seu comportamento, esses comportamentos podem ser injetados usando o padrão Estratégia ao invés de grandes estruturas *if-then*. De fato, a formulação desses padrões de projeto é uma tentativa de reduzir a duplicação de esforço exigido para resolver problemas comumns e discutir tais soluções. Adicionalmente, DRY pode ser aplicado para estruturas, como esquemas de bancos de dados, resultando em normalização.
+
+Questão de princípcios
+---
+
+Outros princípios de desenvolvimento de software são também relacionados ao DRY. O princípio de *Uma vez e apenas uma vez*, que se aplica apenas ao comportamento funcional do código, pode ser pensado como relacionado ao DRY. O princípio *Aberto/Fechado*, que afirma que "entidades de software devem estar abertas para extensão, mas fechadas para modificação", somente funciona na prática quando o DRY é seguido. Da mesma forma, o famoso *Princípio da Responsabilidade Única* exige que uma classe tenha "somente uma razão para mudar", depende no DRY.
+
+Quando seguido com respeito à estrutura, lógica, processo e função, o princípio DRY fornece orientação fundamental aos desenvolvedores de software e ajudam na criação de aplicações mais simples, mais fáceis de manter e de maior qualidade. Embora existam cenários onde a repetição possa ser necessária para atingir boa performance ou outros requisitos (e.g. desnormalização em um banco de dados), ela só deve ser usada quando resolve um problema real e não um problema imaginário.
+
+Por [Steve Smith](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Smith)
\ No newline at end of file
diff --git a/pt_br/thing_31/README.md b/pt_br/thing_31/README.md
new file mode 100644
index 00000000..212772ba
--- /dev/null
+++ b/pt_br/thing_31/README.md
@@ -0,0 +1,22 @@
+# Não mexa nesse código!
+
+Isso já aconteceu com todos em algum momento da vida. Seu código foi publicado no servidor de testes para ser submetido à testagem rigorosa e o gerente de testes te responde que ela encontrou um problema. Sua primeira são é "Isso é rápido, deixa que eu conserto - Eu sei o que está errado."
+
+Em alto nível, no entanto, o que está errado é que como desenvolvedor você deveria acessar o servidor de testes.
+
+Na maioria dos ambientes de desenvolvimento para a web, a arquitetura pode ser desdobrada como:
+
+- Desenvolvimento local e teste de unidade na máquina do desenvolvedor
+- Servidor de desenvolvimento onde os testes manuais ou testes de integração automatizada são executados.
+- Servidor de testes onde o time de qualidade e os usuários executam o teste de aceitação
+- Servidor de produção
+
+Sim, existem outros servidores e serviços espalhados, como controle de versão de código e sistema de tickets, mas a idéia é essa. Usando esse modelo, um desenvolvedor - mesmo um desenvolvedor sênior - nunca deveria ter acesso além do servidor de desenvolvimento. A maior parte do desenvolvimento é feita na máquina local do desenvolvedor usando sua seleção favorita de IDEs, máquinas virtuais, e uma quantidade apropriadade de magia negra espalhada por aí para conferir boa sorte.
+
+Uma vez que o código é publicado no sistema de controle de versão, automaticamente ou manualmente, ele deveria ser publicado no servidor de desenvolvimento onde ele pode ser testado e ajustado se necessário para garantir que tudo esteja funcionando. Deste ponto em diante, no entanto, o desenvolvedor é um espectador do processo.
+
+O gerente responsável pela publicação no ambiente de testes deveria compilar e publicar o código no servidor de testes para o time de qualidade. Da mesma forma que os desenvolvedores não deveriam ter acesso a qualquer coisa além do servidor de desenvolvimento, o time de qualidade e os usuários não tem necessidade de tocar em qualquer coisa no ambiente de desenvolvimento. Se estiver pronto para o teste de aceitação, compile e publique logo, não pergunte ao usuário "Olhe uma coisa rápida" aqui no ambiente de desenvolvimento. Lembre-se, exceto se você estiver desenvolvimento sozinho, outras pessoas terão código lá e esse código pode não estar pronto para o usuário ver. O gerente de releases é a única pessoa que deveria ter acesso a ambos.
+
+Sob nenhuma circunstância - nunca - um desenvolvedor deveria ter acesso ao servidor de produção. Se existe um problema, seu time de suporte deveria ou corrigir ou requisitar que você corrija. Depois a correção é publicada no sistema de controle de versão e um patch será publicado a partir de lá. Alguns dos maiores desastres de programação de que participei ocorreram porque alguém (\**cough*\*eu mesmo\**cough\**) violou essa última regra. Se estiver com problemas, o ambiente de produção não é o lugar para corrigir.
+
+Por [Cal Evans](http://programmer.97things.oreilly.com/wiki/index.php/Cal_Evans)
\ No newline at end of file
diff --git a/pt_br/thing_32/README.md b/pt_br/thing_32/README.md
new file mode 100644
index 00000000..ba9dcf11
--- /dev/null
+++ b/pt_br/thing_32/README.md
@@ -0,0 +1,15 @@
+# Encapsule comportamentos, não apenas estado
+
+Na teoria de sistemas, a contenção é uma das construções mais úteis ao lidar com estruturas de sistemas complexas e gigantescas. Na indústria de software, o valor da contenção ou encapsulamento é bem entendido. A contenção é suportada por construções da linguagem de programação como subrotinas, funções, módulos, pacotes, classes e assim por diante.
+
+Módulos e pacotes resolvem as necessidades de larga escala para encapsulamento, enquanto classes, subrotinas e funções resolvem os aspectos menores, mais detalhados desse tópico. Ao longo dos anos, descobri que as classes parecem ser as construções mais difíceis de serem entendidas corretamente pelos desenvolvedores. Não é incomum encontrar uma classe com um método principal de 300 linhas, ou uma classe contendo somente métodos *setters* e *getters* para seus atributos primitivos. Esses exemplos demonstram que os desenvolvedores enlolvidos não entenderam completamente o pensamento da orientação a objetos, falhando em obter as vantagens do poder dos objetos como construções de modelamento. Para desenvolvedores familiares com os termos POJO (Plain Old Java Object) e POCO (Plain Old C# Object ou Plain Old CLR Object), essa era a intenção ao retornar ao básico de orientação a objetos como um paradigma de modelamento - os objetos são simples mas não burros.
+
+Um objeto encapsula tanto estado como comportamento, onde o comportamento é definido pelo estado atual. Considere um objeto *porta*. Ele possui quatro estados: fechado, aberto, fechando e abrindo. Fornece duas operações: abrir e fechar. Dependendo do estado, as operações de abrir e fechar se comportarão de forma diferente. Essa propriedade inerente de um objeto torna o processo de projeto conceitualmente simples. Resume-se a duas simples tarefas: alocação e delegação de responsabilidade aos diferentes objetos incluindo os protocolos de interação entre objetos.
+
+Como isso opera na prática é melhor ilustrado por meio de um exemplo. Digamos que temos três classes: Cliente, Pedido e Item. Um objeto Cliente é o lugar natural para o limite de crédito e para as regras de validação de crédito. Um objeto Pedido sabe sobre o Cliente associado, e sua operação de adicionar Item delega a verificação de crédito presente ao chamar `cliente.validaCrédito(item.preço())`. Se a pós-condição para o método falhar, uma exceção pode ser lançada e a compra então é abortada.
+
+Desenvolvedores menos experientes podem decidir encpasular todas as regras de negócio em um objeto geralmente chamado de `GerenteDePedidos` ou `ServiçoDePedidos`. Nesses projectos, `Pedido`, `Cliente` e `Item` são tratados como meros registros. Toda a lógica é extraida dessas classes e envolvida junto em um método grande, procedural com vários elementos *if-then-else*. Esses métodos falham com frequência e são quase impossíveis de manter. A razão? O encapsulamento está quebrado!
+
+Para concluir, não quebre o encapsulamento e use o poder da sua linguagem de programação para manter ele.
+
+Por [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre)
\ No newline at end of file
diff --git a/pt_br/thing_33/README.md b/pt_br/thing_33/README.md
new file mode 100644
index 00000000..877159bf
--- /dev/null
+++ b/pt_br/thing_33/README.md
@@ -0,0 +1,17 @@
+# Números de ponto flutuante não são reais
+
+Números de ponto flutuante não são "números reais" no sentido matemático, mesmo que eles sejam chamados de *reais* em algumas linguages de programação, tais quais Pascal e Fortran. Números reais tem precisão infinita e são portanto contínuos e sem perda; números de ponto flutuante tem precisão limitada, de forma que são finitas e lembram inteiros "mau comportados", porque eles não nem mesmo distribuídos igualmente ao longo da faixa válida de valores.
+
+Para ilustrar, atribua 2147483647 (o maior inteiro de 32 bits com sinal) para uma variável de ponto flutuante de 32 bits (digamos x) e imprima ele. Você verá 2147483648. Agora imprima `x - 64`. Ainda 2147483648. Agora imprima `x - 64` e você terá 2147483520! Porquê? Porque o espaçamento entre números de ponto flutuante adjacentes nessa faixa é 128, e as operações de ponto flutuante arredondam para o número de ponto flutuante mais próximo.
+
+Números de ponto flutuante IEEE são números de precisão fixa baseados na notação científica de base 2: 1.d<sub>1</sub>d<sub>2</sub>...d<sub>p-1</sub> × 2<sup>e</sup>, onde *p* é a precisão (24 para floats, 53 para doubles). O espaçamento entre dois números consecutivos é 2<sup>1-p+e</sup>, que podem ser seguramente aproximados por ε|x|, onde ε é o *épsilon da máquina* (2<sup>1-p</sup>).
+
+Conhecer o espaçamento na vizinha de um número de ponto flutuante pode ajudar você evitar erros numéricos estúpidos. Por exemplo, se você estiver executando um cálculo iterativo, tal como a busca da raiz de uma equação, não faz sentido pedir por maior precisão que o sistema numérico pode te dar na vizinhança de uma resposta. Certifique-se que a tolerância que você solicita não é menor que o espaçamento na redondeza; de outra forma, você estará em um loop infinito.
+
+Visto que números de ponto flutuante são aproximações dos números reais, existe, inevitavelmente, um pequeno erro presente. Esse erro, chamado de *roundof*, pode levar a resultados surpreendentes. Quando você subtrai números praticamente iguais, por exemplo, os dígitos mais significantes se cancelam, tal que o que era o dígito menos significativo (onde o erro reside) é promovido à posição mais significativa no resultado de ponto flutuante, essecialmente causando contaminação em todas as operações subsequentes (um fenômeno conhecido como *smearing*). Você precisa olhar atentamente para seus algoritmos para prevenir tais *cancelamentos catastróficos*. Para ilustrar , considere resolver a equação *x<sup>2</sup> - 100000x + 1 = 0* com a fórmula quadrática. Visto que os operadores na expressão *-b + sqrt(b<sup>2</sup> - 4)* são praticamente iguais em magnitude, você pode, alternativamente, cálcular a raiz *r<sub>1</sub> = -b + sqrt(b<sup>2</sup> - 4)*, e então obter *r<sub>2</sub> = 1/r<sub>1</sub>*, visto que para qualquer equação quadrática, ax<sup>2</sup> + bx + c = 0, as raízes satisfazem *r<sub>1</sub>r<sub>2</sub> = c/a*.
+
+Smearing podem acontecer em formas ainda mais sutis. Suponha uma biblioteca calcule inocentemente *e<sup>x</sup>* através da fórmula *1 + x + x<sup>2</sup>/2 + x<sup>3</sup>/3! + ...*. Isso funciona bem para *x* com valores positivos, mas considere o que acontece quando *x* é um número negativo grande. Os termos pares resultam em grandes números positivos, e a subtração das magnitudes associadas aos índices ímpares não irá afetar o resultado. O problema aqui é que o arredondamento nos termos grandes e positivos está em uma posição de maior significância que a resposta verdadeira. A resposta diverge em direção à infinito positivo! A solução aqui é também simples: para *x* negativos, calcule *e<sup>x</sup> = 1/e<sup>|x|</sup>*.
+
+Deveria ser claro agora que você não deveria usar números de ponto flutuante para aplicações financeiras - é para isso que as classes *decimal* em linguagens como Python e C# são feitas. Números de ponto flutuantes são voltados para computação científica eficiente. Mas eficiência é inútil sem acurácia, assim lembre-se da fonte de erros de arredondamento de erros e escreva seu código respeitando isso!
+
+Por [Chuck Allison](http://programmer.97things.oreilly.com/wiki/index.php/Chuck_Allison)
\ No newline at end of file
diff --git a/pt_br/thing_34/README.md b/pt_br/thing_34/README.md
new file mode 100644
index 00000000..5251a3bb
--- /dev/null
+++ b/pt_br/thing_34/README.md
@@ -0,0 +1,11 @@
+# Satisfaça suas ambições com open source
+
+Existe grande chance de que você não esteja desenvolvendo software em seu trabalho que satisfaça seus sonhos mais ambiciosos de desenvolvimento de software. Talvez você esteja desenvolvendo software para uma grande companhia de seguros mas sonhando em trabalhar no Google, Apple, Microsoft ou iniciar sua própria start-up desenvolvendo a próxima grande descoberta tecnológica. Você nunca chegará onde quer chegar desenvolvendo software para sistemas que não importam para você.
+
+Felizmente, existe uma resposta para esse seu problema. Existem milhares de projetos open source por aí, muitos dos quais bastante ativos, que tem a capacidade de te oferecer qualquer tipo de experiência de desenvolvimento de software que você possa desejar. Se você ama a ideia de desenvolver sistemas operacionais, ajude com um dentre as dezenas de projetos de sistemas operacionais. Se você quiser trabalhar com software que processa música, software de animação, criptografia, robótica, games de computador, games online, aplicativos de celular, ou qualquer outra coisa, você certamente encontrará ao menos um projeto open source dedicado a esse seu interesse.
+Claro que não há almoço grátis. Você precisa estar disposto a doar seu tempo livre porque provavelmente não poderá trabalhar num video game open source no seu emprego - você ainda tem uma responsabilidade com seu empregador. Adicionamente, muitas pessoas ganham algum dinheiro contribuindo com projetos open source - alguns sim, mas a maioria não. Você deve ter essa disposição de doar parte do seu tempo livre (menos tempo de video games e de assistir TV não irá te matar). Quanto mais você trabalhar num projeto open source, mais rápido você irá perceber suas verdadeiras ambições como programador. É também importante considerar seu contrato de trabalho - algumas empresas podem restringir em que você pode contribuir, mesmo que no seu próprio tempo. Adicionamente, você precisa estar bem atento à violação de propriedade intelectual com copyright, patentes, marcas registradas e segredos comerciais.
+Projetos open source fornecem enormes oportunidades para o programador motivado. Primeiro, você verá como outras pessoas implementam uma solução que te interesse - você pode aprender bastante através da leitura de código-fonte de outras pessoas. Segundo, você irá contribuir com seu próprio código e ideias ao projeto - nem toda ideia brilhante que você tenha será aceita mas algumas irão e você aprenderá algo novo apenas trabalhando nas soluções e contribuindo com código. Terceiro, você encontrará grandes pessoas com a mesma paixão para o tipo de software que você se dedica - essas amizades no mundo open source podem durar uma vida inteira. Quarto, supondo que você seja um contribuidor competente, você será capaz de adicionar experiência do mundo real na tecnologia que te interessa mais.
+
+Iniciar no mundo open source é bem fácil. Existe uma infinidade de documentação sobre as ferramentas que você irá necessitar (por exemplo, gestão de versão de código-fonte, editores, linguagens de programação, sistemas de build, etc. ) Encontre o projeto que você deseja trabalhar e aprenda primeiro sobre as ferramentas usadas. A documentação no próprio projeto te guiará na maioria dos casos, mas isso talvez importe pouco porque a melhor forma de aprender é investigar o código por você mesmo. Se você deseja se envolver, você pode oferecer ajudar com a documentação. Ou pode se voluntariar a escrever códigos de testes. Enquanto isso pode não aparentar excitante em primeiro momento, a verdade é que você aprenderá muito mais rápido ao escrever testes para software de outras pessoas do que com qualquer outra atividade no software. Escreva testes, realmente bons testes. Encontre bugs, sugira correções, faça amigos, trabalhe no software que você goste e satisfaça suas ambições de desenvolvimento de software.
+
+Por [Richard Monson-Haefel](http://programmer.97things.oreilly.com/wiki/index.php/Richard_Monson-Haefel)
\ No newline at end of file
diff --git a/pt_br/thing_35/README.md b/pt_br/thing_35/README.md
new file mode 100644
index 00000000..6f82f4ff
--- /dev/null
+++ b/pt_br/thing_35/README.md
@@ -0,0 +1,11 @@
+# A regra de ouro do projeto de APIs
+
+O projeto de APIs é difícil, particulamente grandes APIs. Se você estiver projetando uma API que terá centenas ou milhares de usuários, você tem que pensar em como irá modificá-la no futuro e se suas mudanças poderão quebrar o código do seu cliente. Além disso, você tem que pensar como os usuários da sua API te afetam. Se uma de suas classes da API utiliza um de seus próprios métodos internamente, você tem que lembrar que um usuário pode derivar sua classe em uma subclasse e sobrescrever este método, e isso pode ser desastroso. Você não será capaz de mudar aquele método porque alguns usuários deram a ele um significado diferente. Suas escolhas futuras de implementação interna estarão à mercê de seus usuários.
+
+Desenvolvedores de API resolvem esse problema de diversas formas, mas a forma mais fácil é congelar a API. Se estiver trabalhando com Java pode ser tentado a tornar a maioria das suas classes e métodos como `final`. Em C#, você pode tornar suas classes e métodos como `sealed`. Independente da linguagem que estiver usando, você pode ser tentato a apresentar sua API através de um singleton ou usar métodos fábrica estáticos tais que você se proteja de sobreescrita de comportamentos e use seu código de forma que possa limitar suas escolhas futuras. Isso tudo parece razoável, mas é realmente?
+Durante a última década, nós constatamos gradualmente que os testes de unidade são parte extremamente importantes da prática de desenvolvimento de APIs, mas essa lição não permeou completamente a indústria. A evidência está ao redor de nós. Considere uma classe arbitrária testada que usa uma API de terceiros e tente escrever testes de unidades para ela. Na maior parte do tempo, você irá se deparar com problemas. Você encontrará que o código que usa a API está preso a ela como cola. Não existe forma de imitar as classes da API de forma que você possa monitorar as interações do seu código com elas, ou fornecer valores de retorno para teste.
+Ao longo do tempo, isso deve melhorar, mas somente se começarmos a ver o teste de unidade como um caso real onde projetamos APIs. Infelizmente, é mais complicado que apenas testar nosso código. Nesse ponto entra a **Regra de ouro de projeto de APIs**: *Não é suficiente escrever testes para uma API que você desenvolve; você tem que escrever testes de unidade para o código que usa sua API. Quando você faz isso, aprenderá em primeira mão as dificuldades que seus usuários terão de superar quando eles tentarem testar seu código independentemente.*
+
+Não existe uma única forma de tornar fácil para os desenvolvedores testarem o código que usa sua API. `static`, `final` e `sealed` não são naturalmente construções ruins. Podem ser úteis às vezes. Mas é importante estar ciente do problema de testes, e para isso, você tem que experimentar por conta própria. Uma vez feito, você pode abordar esse problema como faria com qualquer outro desafio de projeto.
+
+Por [Michael Feathers](http://programmer.97things.oreilly.com/wiki/index.php/Michael_Feathers)
\ No newline at end of file
diff --git a/pt_br/thing_36/README.md b/pt_br/thing_36/README.md
new file mode 100644
index 00000000..c0a33b85
--- /dev/null
+++ b/pt_br/thing_36/README.md
@@ -0,0 +1,17 @@
+# O mito do guru
+
+Qualquer um que trabalhe em desenvolvimento de software por tempo suficiente já ouviu questões como essa:
+
+> *Estou observando a exceção XYZ. Você sabe qual é o problema?*
+
+Quem faz essa pergunta raramente se importa em incluir os "stack traces", logs de erros ou qualquer contexto que leve ao aparecimento do problema. Eles parecem pensar que você opera em um plano diferente, que as soluções aparecem para você sem qualquer análise baseada em evidência. Eles pensam em você como um guru.
+
+Nós esperamos essas questões daqueles não familiares com software: para esses os sistemas podem parecer quase mágicos. O que me preocupa é ver isso na comunidade de desenvolvimento de software. Questões similares surgem no desenho de programas, tais como "Estou construindo um programa de gestão de estoques. Devo usar '*locking*' otimista?" Ironicamente, as pessoas que fazem esses questionamentos são melhor equipadas para respondê-las que quem recebe a pergunta. Os questionadores, supostamente, conhecem o contexto, conhecem os requisitos, e podem ler sobre as vantagens e desvantages de diferentes estratégias. Ainda assim esperam obter de você uma resposta inteligente sem contexto. Elas esperam mágica.
+
+Já passou da hora da indústria de desenvolvimento de software abolir esse mito do guru. "Gurus" são seres humanos. Eles aplicam lógica e analisam problemas sistematicamente como o resto de nós. Eles usam de atalhos mentais e intuição. Considere o melhor programador que você já encontrou: em algum momento essa pessoa sabia menos sobre software que você sabe agora. Se alguém se assemelha a um guru, isso se deve aos vários anos dedicados ao aprendizado e refinamento do processo de pensamento. Um "guru" é simplesmente uma pessoa inteligente com curiosidade incessante.
+
+É claro que existe uma ampla variação na habilidade natural. Muitos hackers por aí são mais inteligentes, conhecem muito mais e são mais produtivos que eu jamais fui. Ainda assim, abolir esse mito do guru tem impacto positivo. Por exemplo, quando trabalho com alguém mais inteligente que eu, eu sei que terei que fazer o meu dever de casa, para fornecer contexto suficiente para que a pessoa aplique suas habilidades de forma eficiente. Remover o mito do guru também significa remover uma barreira percebida à melhoria. Ao invés da barreira mágica, eu vejo um contínuo onde eu posso avançar.
+
+Finalmente, um dos maiores obstáculos no desenvolvimento de software são as pessoas inteligentes que intencionalmente propagam o mito do guru. Isso pode ter origem no próprio ego, ou como uma estratégia para aumentar o valor percebido pelo cliente ou pelo empregador. Ironicamente, essa atitude pode tornar as pessoas inteligentes menos valiosas, visto que elas não contribuem com o crescimento dos seus pares. Não precisamos de gurus. Precisamos de especialistas que desejam desenvolver outros especialistas em seu campo. Existe espaço para todos nós.
+
+Por [Ryan Brush](http://programmer.97things.oreilly.com/wiki/index.php/Ryan_Brush)
\ No newline at end of file
diff --git a/pt_br/thing_37/README.md b/pt_br/thing_37/README.md
new file mode 100644
index 00000000..e10d3842
--- /dev/null
+++ b/pt_br/thing_37/README.md
@@ -0,0 +1,13 @@
+# O trabalho duro não compensa
+
+Como programador, o trabalho duro geralmente não compensa. Você pode se enganar e engar outros colegas a acreditar que está contribuindo significativamente para um projeto através das longas horas no escritório. Mas a verdade é que trabalhando menos você pode atingir mais - algumas vezes muito mais. Se você está tentando estar focado e produtivo por mais de 30 horas por semana, você provavelmente está trabalhando muito. Você deveria considerar reduzir sua carga de trabalho para se tornar mais efetivo e conseguir completar mais tarefas.
+
+Essa afirmação pode parecer contraintuitiva e mesmo controversa, mas é a consequência direta do fato que programação e desenvolvimento de software em geral envolve um processo de aprendizado contínuo. À medida que você trabalha em um projeto você entenderá mais do domínio do problema e, felizmente, encontrar formas mais efetivas de atingir o objetivo. Para evitar desperdício de trabalho, você deve alocar tempo para observar os efeitos do que você estiver fazendo, refletir sobre as coisas que você vê, e mudar seu comportamento de acordo com essas observações.
+
+Desenvolvimento de software profissional não é usualmente o mesmo que correr rápido alguns poucos quilômetros, onde o objetivo pode ser visto no final de uma estrada pavimentada. A maioria dos projetos de software são mais parecidos que uma longa maratona de orientação. No escuro. E apenas um mapa rudimentar como guia. Se você definir uma direção, correr tão rápido quanto você possa, você irá impressionar alguns, mas provavelmente você não irá ser bem sucedido. Você precisa manter uma cadência sustentável e precisará ajustar seu percurso quando aprender mais sobre onde você está e para onde está indo.
+
+Adicionalmente, você sempre precisará aprender mais sobre desenvolvimento de software em geral e mais especificamente técnicas de programação. Você precisará ler livros, ir a conferências, comunicar com seus pares, experimentar novas técnicas de implementação, e aprender sobre as ferramentas que simplificam seu trabalho. Como um programador profissional, você deve se manter atualizado em seu campo de especialização - da mesma forma que neurocirurgiões e pilotos devem se manter atualizados em seus próprios campos de especialização. Você precisará gastar noites, fins de semana e feriados para estudar, portanto você não pode gastar suas noites, finais de semana e feriados fazendo hora extra para o seu projeto atual. Você realmente espera que neurocirurgiões executem cirurgias por 60 horas por semana ou um piloto voe 60 horas em uma semana? É claro que não, preparação e educação é uma parte essential de sua profissão.
+
+Esteja focado no projeto, contribua o máximo que puder através de soluções inteligentes, melhoria de suas habilidades, pela reflexão do que você está fazendo e adapte seu comportamento. Evite se constranger, e contaminar nossa profissão, agindo como um hamster em um gaiola rodando em uma roda livre. Como programador profissional você deve saber que tentar estar focado e 'produtivo' por 60 horas por semana não é algo inteligente de se fazer. Aja como um profissional: prepare, efetue, observe, reflita e muda.
+
+Por [Olve Maudal](http://programmer.97things.oreilly.com/wiki/index.php/Olve_Maudal)
\ No newline at end of file
diff --git a/pt_br/thing_38/README.md b/pt_br/thing_38/README.md
new file mode 100644
index 00000000..855fe4c0
--- /dev/null
+++ b/pt_br/thing_38/README.md
@@ -0,0 +1,23 @@
+# Como usar um gerenciador de bugs
+
+Chame você de *bugs*, *defeitos* ou mesmo *efeitos colaterais do projeto*, não existe escapatória deles. Saber como submeter um bom relatório de *bug* e também o que olhar em um relatório desses são habilidades chave para manter um projeto avançando de forma tranquila, sem sobressaltos.
+
+Um bom relatório de *bug* precisa de 3 elementos:
+
+- Como reproduzir o *bug*, o mais detalhado possível, e o quão frequente o *bug* acontece sob essas condições.
+- O que deveria ter acontecido, ao menos na sua opinião
+- O que de fato aconteceu, ou pelo menos a informação que você conseguiu registrar.
+
+A quantidade e qualidade da informação reportada em um *bug* diz tanto sobre o relatante quanto sobre o *bug* em si. Relatos irritados e curtos ("Essa função é horrível!") diz aos desenvolvedores que você teve um tempo ruim e nada mais. Já um bug com contexto detalhado para permitir reproduzir facilmente o *bug* ganha o respeito de todos, mesmo que isso interrompa uma *release*
+
+*Bugs* são como uma conversa, com toda a história justamente em frente de todos. Não acuse os outros ou negue a própria existência do *bug*. Ao invés disso, peça mais informação ou reflita sobre o que você pode ter deixado passar.
+
+Mudar o status de um *bug*, por exemplo de *Aberto* para *Fechado* é um anúncio público do que você pensa sobre o *bug*. Dedique um tempo para explicar porque você pensa que o *bug* deva ser fechado para evitar horas tediosas depois de justificativas para gerentes e clientes frustrados. Mudar a prioridade de um *bug* é um anúncio público similar e mesmo que seja trivial para você não significa que não esteja interrompendo outras pessoas de usar o produto.
+
+Não sobrecarregue os campos de um *bug* para seus próprios propósitos. Adicionar "VITAL:" em um campo do *bug* pode tornar mais fácil para você ordenar os resultados de algum relatório mas será copiado por outros e inevitavelmente digitado incorretamente ou será removido para uso em outro relatório. Use um novo valor ou um novo campo e documente como o campo deve ser usado tal que não faça que as pessoas se repitam.
+
+Certifique-se que todos sabem como encontrar os *bugs* que o time deva estar atuando. Isso pode ser feito usualmente através de uma *query* pública com um nome óbvio. Certifique-se também que todos estão usando a mesma *query* e não altere essa query sem primeiro informar o time.
+
+Finalmente, lembre-se que um *bug* não é uma unidade padrão de trabalho mais do que uma linha de código não é uma medida precisa de esforço.
+
+Por [Matt Doar](http://programmer.97things.oreilly.com/wiki/index.php/Matt_Doar)
\ No newline at end of file
diff --git a/ru/thing_02/README.md b/ru/thing_02/README.md
index d2257822..56a8f64e 100644
--- a/ru/thing_02/README.md
+++ b/ru/thing_02/README.md
@@ -13,4 +13,4 @@
 
 Оплачивайте технический долг как можно быстрее. Действовать по-другому было бы неосмотрительно.
 
-Автор оригинала - [Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose)
\ No newline at end of file
+Автор оригинала - [Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose)
\ No newline at end of file
diff --git a/ru/thing_92/README.md b/ru/thing_92/README.md
index 0339570c..8ee348c8 100644
--- a/ru/thing_92/README.md
+++ b/ru/thing_92/README.md
@@ -9,7 +9,7 @@
 
 Знание о расстоянии между числами поможет избежать классических грубых ошибок. Например, если вы делаете итеративное вычисление, например, поиск корней уравнения, то нет смысла задавать точность выше, чем это расстояние. Если вы зададите точность меньше этого, то цикл итерации будет длиться бесконечно.
 
-Поскольку числа с плавающей точкой – лишь приближение к действительным числам, то при их использовании практически всегда будет присутствовать неточность. Эта неточность, называемая ошибкой округления, может приводить к удивительным результатам. Когда вы вычитаете близкие по значению числа, то наиболее значимые цифры взаимовычтутся, а наименее значимые (те, где ошибка скрывается ошибка округления) передвинутся на более значимые позиции, «загрязняя» дальнейшие вычисления (этот эффект получил название «размазывание», «smearing»). Вам нужно следить за применяемыми алгоритмами, чтобы не допустить этого. Например, представьте решение уравнения *x<sup>2</sup> - 100000x + 1 = 0*. Поскольку один из корней требует такого вычитания *-b + sqrt(b<sup>2</sup> - 4)*, то можно вычислить сначала другой *r<sub>1</sub> = -b + sqrt(b<sup>2</sup> - 4)*, а потом найти первый по формуле *r<sub>2</sub> = 1/r<sub>1</sub>*, потому что для любого ax2 + bx + c = 0 корни удовлетворяют условию *r<sub>1</sub>r<sub>2</sub> = c/a*.
+Поскольку числа с плавающей точкой – лишь приближение к действительным числам, то при их использовании практически всегда будет присутствовать неточность. Эта неточность, называемая ошибкой округления, может приводить к удивительным результатам. Когда вы вычитаете близкие по значению числа, то наиболее значимые цифры взаимовычтутся, а наименее значимые (те, где ошибка скрывается ошибка округления) передвинутся на более значимые позиции, «загрязняя» дальнейшие вычисления (этот эффект получил название «размазывание», «smearing»). Вам нужно следить за применяемыми алгоритмами, чтобы не допустить этого. Например, представьте решение уравнения *x<sup>2</sup> - 100000x + 1 = 0*. Поскольку один из корней требует такого вычитания *-b + sqrt(b<sup>2</sup> - 4)*, то можно вычислить сначала другой *r<sub>1</sub> = -b + sqrt(b<sup>2</sup> - 4)*, а потом найти первый по формуле *r<sub>2</sub> = 1/r<sub>1</sub>*, потому что для любого ax<sup>2</sup> + bx + c = 0 корни удовлетворяют условию *r<sub>1</sub>r<sub>2</sub> = c/a*.
 
 Размазывание может случиться и в гораздо более тонких моментах. Представьте библиотеку, вычисляющую *e<sup>x</sup>* по формуле *1 + x + x<sup>2</sup>/2 + x<sup>3</sup>/3! + ...*. Это работает для положительных х, однако для больших отрицательных работать перестанет. Четные степени дадут большие положительные числа, и вычитание отрицательных вообще не окажет влияния на результат. Проблема здесь в том, что ошибка округления для больших положительных чисел оказывается значительно больше, чем правильный ответ. В результате вычисление по этой формуле даст в ответе бесконечность! Решение же очень простое – для отрицательных *х* вычислять *e<sup>x</sup> = 1/e<sup>|x|</sup>*.
 
diff --git a/tr/thing_01/README.md b/tr/thing_01/README.md
index cfd646aa..ecb145fb 100644
--- a/tr/thing_01/README.md
+++ b/tr/thing_01/README.md
@@ -12,4 +12,4 @@ Bir sonraki yinelemede borcun geri ödemesini planlarsanız, maliyet minimum ola
 
 Teknik borcu mümkün olan en kısa sürede ödeyin. Aksini yapmak tedbirsizlik olur.
 
-[Seb Rose](http://programmer.97things.oreilly.com/wiki/index.php/Seb_Rose) Tarafından
\ No newline at end of file
+[Seb Rose's GitHub profile](https://github.com/sebrose) / [Seb Rose's LinkedIn Profile](https://www.linkedin.com/in/sebrose) Tarafından
\ No newline at end of file
diff --git a/tr/thing_33/README.md b/tr/thing_33/README.md
index 91185b49..a176a8b4 100644
--- a/tr/thing_33/README.md
+++ b/tr/thing_33/README.md
@@ -8,7 +8,7 @@ IEEE kayan nokta sayıları, iki tabanlı bilimsel gösterime dayalı sabit kesi
 
 Bir kayan noktalı sayının çevresindeki boşluğu bilmek, klasik sayısal hatalardan kaçınmanıza yardımcı olabilir. Örneğin, bir denklemin kökünü aramak gibi yinelemeli bir hesaplama yapıyorsanız, cevabın komşuluğunda sayı sisteminin verebileceğinden daha fazla kesinlik istemenin bir anlamı yoktur. İstediğiniz toleransın buradaki boşluktan daha küçük olmadığından emin olun; yoksa sonsuza kadar döngü yaparsın.
 
-Kayan noktalı sayıları, gerçek sayıların yaklaşık değerleri olduğundan, kaçınılmaz olarak küçük bir hata vardır. *Yuvarlama* adı verilen bu hata şaşırtıcı sonuçlara yol açabilir. Örneğin, neredeyse eşit sayıları çıkardığınızda, en anlamlı rakamlar birbirini yok eder, bu nedenle en az anlamlı olan rakam (yuvarlama hatasının bulunduğu yer) kayan nokta sonucunda en önemli konuma yükseltilir ve esasen herhangi birini kirletir. diğer ilgili hesaplamalar (*bulaşma* olarak bilinen bir olgu). Böyle bir *felaket iptalini* önlemek için algoritmalarınıza yakından bakmanız gerekir. Örneklemek için, *x<sup>2</sup> - 100000x + 1 = 0* denklemini ikinci dereceden formülle çözmeyi düşünün. *-b + sqrt(b<sup>2</sup> - 4)* ifadesindeki işlenenlerin büyüklükleri hemen hemen eşit olduğundan, bunun yerine *r<sub>1</sub> = -b + sqrt(b<sup>2</sup> - 4)* kökünü hesaplayabilir ve ardından *r<sub>2</sub> = 1/r<sub>1</sub>* elde edebilirsiniz, çünkü herhangi bir ikinci dereceden ax2 + bx + c = 0 denklemi için kökler *r<sub>1</sub>r<sub>2</sub> = c/a*'ı sağlar.
+Kayan noktalı sayıları, gerçek sayıların yaklaşık değerleri olduğundan, kaçınılmaz olarak küçük bir hata vardır. *Yuvarlama* adı verilen bu hata şaşırtıcı sonuçlara yol açabilir. Örneğin, neredeyse eşit sayıları çıkardığınızda, en anlamlı rakamlar birbirini yok eder, bu nedenle en az anlamlı olan rakam (yuvarlama hatasının bulunduğu yer) kayan nokta sonucunda en önemli konuma yükseltilir ve esasen herhangi birini kirletir. diğer ilgili hesaplamalar (*bulaşma* olarak bilinen bir olgu). Böyle bir *felaket iptalini* önlemek için algoritmalarınıza yakından bakmanız gerekir. Örneklemek için, *x<sup>2</sup> - 100000x + 1 = 0* denklemini ikinci dereceden formülle çözmeyi düşünün. *-b + sqrt(b<sup>2</sup> - 4)* ifadesindeki işlenenlerin büyüklükleri hemen hemen eşit olduğundan, bunun yerine *r<sub>1</sub> = -b + sqrt(b<sup>2</sup> - 4)* kökünü hesaplayabilir ve ardından *r<sub>2</sub> = 1/r<sub>1</sub>* elde edebilirsiniz, çünkü herhangi bir ikinci dereceden ax<sup>2</sup> + bx + c = 0 denklemi için kökler *r<sub>1</sub>r<sub>2</sub> = c/a*'ı sağlar.
 
 Bulaşma daha da ince şekillerde ortaya çıkabilir. Bir kitaplığın *e<sup>x</sup>*'ü *1 + x + x<sup>2</sup>/2 + x<sup>3</sup>/3! + ...* formülüyle basitçe hesapladığını varsayalım. Bu, pozitif *x* için iyi çalışır, ancak *x* büyük bir negatif sayı olduğunda ne olduğunu düşünün. Çift güçlü terimler büyük pozitif sayılarla sonuçlanır ve tek güçlü büyüklüklerin çıkarılması sonucu bile etkilemez. Buradaki sorun, büyük, pozitif terimlerdeki yuvarlamanın, gerçek cevaptan çok daha önemli bir rakam konumunda olmasıdır. Cevap pozitif sonsuzluğa doğru sapıyor! Buradaki çözüm de basittir: negatif *x* için *e<sup>x</sup> = 1/e<sup>|x|</sup>*'u hesaplayın.