Merge pull request #1 from disouzam/disouzam/pt-BR/thing_01

Minor fixes in translation of thing_01 and change suggestion in credit to Seb Rose

LANGS.md

@@ -1,2 +1,4 @@
 * [English](en)
 * [русский язык](ru)
+* [Türkçe](tr)
+* [Persian(فارسی)](fa)

en/thing_01/README.md

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

en/thing_09/README.md

@@ -11,12 +11,12 @@ Assuming the tools are widely used, mature, and employed in various technology s
 Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; explain it to someone else; look out for stack corruption and variable type mismatches; try the code on different machines and different build configurations, such as debug and release.
 
 Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor.
-When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They maybe doing something you never thought of or are doing something in a different order.
+When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They may be doing something you never thought of or are doing something in a different order.
 
 As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler, then it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around.
 
 Multi-threaded problems are another source of bugs to turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.
 
 So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."
 
-By [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly)
+By [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly)

en/thing_15/README.md

@@ -8,7 +8,7 @@ A section should be chosen so that at each endpoint the *state of the program* (
 
 Many of the coding practices that are well known (although perhaps less well followed) and considered 'good' make reasoning easier. Hence, just by intending to reason about your code, you already start thinking toward a better style and structure. Unsurprisingly, most of these practices can be checked by static code analyzers:
 
-1. Avoid using goto statements, as they make remote sections highly interdependent.
+- Avoid using goto statements, as they make remote sections highly interdependent.
 - Avoid using modifiable global variables, as they make all sections that use them dependent.
 - Each variable should have the smallest possible scope. For example, a local object can be declared right before its first usage.
 - Make objects *immutable* whenever relevant.
@@ -22,4 +22,4 @@ Many of the coding practices that are well known (although perhaps less well fol
 
 As well as reasoning about its correctness, arguing about your code gives you understanding of it. Communicate the insights you gain for everyone's benefit.
 
-By [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi)
+By [Yechiel Kimchi](http://programmer.97things.oreilly.com/wiki/index.php/Yechiel_Kimchi)

en/thing_20/README.md

@@ -8,8 +8,8 @@ Starting your project with an installation process will give you time to evolve
 
 Putting deployment last means that the deployment process may need to be more complicated to work around assumptions in the code. What seemed a great idea in an IDE, where you have full control over an environment, might make for a much more complicated deployment process. It is better to know all the trade-offs sooner rather than later.
 
-While "being able to deploy" doesn't seem to have a lot of business value early on as compared to seeing an application run on a developer's laptop, the simple truth is that until you can demonstrate you application on the target environment, there is a lot of work to do before you can deliver business value. If your rationale for putting off a deployment process is that it is trivial, then do it anyway since it is low cost. If it's too complicated, or if there are too many uncertainties, do what you would do with application code: experiment, evaluate, and refactor the deployment process as you go.
+While "being able to deploy" doesn't seem to have a lot of business value early on as compared to seeing an application run on a developer's laptop, the simple truth is that until you can demonstrate your application on the target environment, there is a lot of work to do before you can deliver business value. If your rationale for putting off a deployment process is that it is trivial, then do it anyway since it is low cost. If it's too complicated, or if there are too many uncertainties, do what you would do with application code: experiment, evaluate, and refactor the deployment process as you go.
 
 The installation/deployment process is essential to the productivity of your customers or your professional services team, so you should be testing and refactoring this process as you go. We test and refactor the source code throughout a project. The deployment deserves no less.
 
-By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk)
+By [Steve Berczuk](http://programmer.97things.oreilly.com/wiki/index.php/Steve_Berczuk)

en/thing_26/README.md

@@ -33,7 +33,7 @@ Not handling errors leads to:
 
 - **Brittle code.** Code that's filled with exciting, hard-to-find bugs.
 - **Insecure code.** Crackers often exploit poor error handling to break into software systems.
-- **Poor structure.** If there are errors from your code that are tedious to deal with continually, you have probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous.
+- **Poor structure.** If there are errors from your code that are tedious to deal with continually, you probably have a poor interface. Express it so that the errors are less intrusive and the their handling is less onerous.
 
 Just as you should check all potential errors in your code, you need to expose all potentially erroneous conditions in your interfaces. Do not hide them, pretending that your services will always work.
 
@@ -44,4 +44,4 @@ Why don't we check for errors? There are a number of common excuses. Which of th
 - I know that this function call will *never* return an error (printf always works, malloc always returns new memory — if it fails we have bigger problems...).
 - It's only a toy program, and needn't be written to a production-worthy level.
 
-By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe)
+By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe)

en/thing_53/README.md

@@ -3,13 +3,13 @@
 Depressingly often (happened to me again just before I wrote this), the view many programmers have of the process of going from source code to a statically linked executable in a compiled language is:
 
 1. Edit source code
-- Compile source code into object files
-- Something magical happens
-- Run executable
+2. Compile source code into object files
+3. Something magical happens
+4. Run executable
 
 Step 3 is, of course, the linking step. Why would I say such an outrageous thing? I've been doing tech support for decades, and I get the following questions again and again:
 
-1. The linker says def is defined more than once.
+- The linker says def is defined more than once.
 - The linker says abc is an unresolved symbol.
 - Why is my executable so large?
 
@@ -49,4 +49,4 @@ To determine why an executable is the size it is, take a look at the map file th
 
 Although it is not always immediately obvious why you get a particular linker message, there is nothing magical about linkers. The mechanics are straightforward; it's the details you have to figure out in each case.
 
-By [Walter Bright](http://creativecommons.org/licenses/by/3.0/us/)
+By [Walter Bright](http://creativecommons.org/licenses/by/3.0/us/)

en/thing_54/README.md

@@ -19,15 +19,15 @@ The answer depends on your project, and on your personal stake in the production
 So what can we do if we see a problem?
 
 1. Avoid creating an interim solution in the first place.
-- Change the forces that influence the decision of the project manager.
-- Leave it as is.
+2. Change the forces that influence the decision of the project manager.
+3. Leave it as is.
 
 Let's examine these options more closely:
 
 1. Avoidance does not work in most places. There is an actual problem to solve, and the standards have turned out to be too restrictive. You might spend some energy trying to change the standards. An honorable albeit tedious endeavor... and that change will not be effective in time for your problem at hand.
-- The forces are rooted in the project culture, which resists volitional change. It could be successful in very small projects — especially if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
-- The status quo automatically applies if the previous option does not.
+2. The forces are rooted in the project culture, which resists volitional change. It could be successful in very small projects — especially if it's just you — and you just happen to clean the mess without asking in advance. It could also be successful if the project is such a mess that it is visibly stalled and some time for cleaning up is commonly accepted.
+3. The status quo automatically applies if the previous option does not.
 
 You will create many solutions, some of them will be interim, most of them will be useful. The best way to overcome interim solutions is to make them superfluous, to provide a more elegant and useful solution. May you be granted the [serenity](http://en.wikipedia.org/wiki/Serenity_prayer) to accept the things you cannot change, courage to change the things you can, and wisdom to know the difference.
 
-By [Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt)
+By [Klaus Marquardt](http://programmer.97things.oreilly.com/wiki/index.php/Klaus_Marquardt)

en/thing_65/README.md

@@ -20,12 +20,12 @@ Some_Number:= Distance + Velocity; -- Will be caught by the compiler as a type e
 
 Developers in less demanding domains might also benefit from applying more domain-specific typing, where they might otherwise continue to use the primitive data types offered by the language and its libraries, such as strings and floats. In Java, C++, Python, and other modern languages the abstract data type is known as class. Using classes such as `Velocity_In_Knots` and `Distance_In_Nautical_Miles` adds a lot of value with respect to code quality:
 
-1. The code becomes more readable as it expresses concepts of a domain, not just Float or String.
+- The code becomes more readable as it expresses concepts of a domain, not just Float or String.
 - The code becomes more testable as the code encapsulates behavior that is easily testable.
 - The code facilitates reuse across applications and systems.
 
 The approach is equally valid for users of both statically and dynamically typed languages. The only difference is that developers using statically typed languages get some help from the compiler while those embracing dynamically typed languages are more likely to rely on their unit tests. The style of checking may be different, but the motivation and style of expression is not.
 
 The moral is to start exploring domain-specific types for the purpose of developing quality software.
 
-By [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre)
+By [Einar Landre](http://programmer.97things.oreilly.com/wiki/index.php/Einar_Landre)

en/thing_76/README.md

@@ -36,6 +36,6 @@ The simple partitioning shown above resolves the issues. Each of these classes c
 
 The astute reader will see that there are still dependencies in the above solution. That `Employee` is still depended upon by the other classes. So if `Employee` is modified, the other classes will likely have to be recompiled and redeployed. Thus, `Employee` cannot be modified and then independently deployed. However, the other classes can be modified and independently deployed. No modification of one of them can force any of the others to be recompiled or redeployed. Even `Employee` could be independently deployed through a careful use of the *Dependency Inversion Principle* (DIP), but that's a topic for a [different book](http://www.amazon.com/dp/0135974445/).
 
-Careful application of the SRP, separating things that change for different reasons, is one if the keys to creating designs that have an independently deployable component structure.
+Careful application of the SRP, separating things that change for different reasons, is one of the keys to creating designs that have an independently deployable component structure.
 
-by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob)
+by [Uncle Bob](http://programmer.97things.oreilly.com/wiki/index.php/Uncle_Bob)

en/thing_83/README.md

@@ -6,6 +6,6 @@ Compared to "hard" engineering, the software development world is at about the s
 
 Testing "hard" things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We've developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software developers, we should embrace testing as the primary (but not the only) verification mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us "We don't have time to test." A bridge builder would never hear from their boss "Don't bother doing structural analysis on that building — we have a tight deadline." The recognition that testing is indeed the path to reproducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.
 
-Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing * **is** * the engineering rigor of software development.
+Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It's time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn't sufficient, but it is necessary. Testing *is* the engineering rigor of software development.
 
-By [Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford)
+By [Neal Ford](http://programmer.97things.oreilly.com/wiki/index.php/Neal_Ford)

en/thing_95/README.md

@@ -5,11 +5,11 @@ You are writing automated tests for some or all of your production code. Congrat
 Good tests act as documentation for the code they are testing. They describe how the code works. For each usage scenario the test(s):
 
 1. Describe the context, starting point, or preconditions that must be satisfied
-- Illustrate how the software is invoked
-- Describe the expected results or postconditions to be verified
+2. Illustrate how the software is invoked
+3. Describe the expected results or postconditions to be verified
 
 Different usage scenarios will have slightly different versions of each of these. The person trying to understand your code should be able to look at a few tests and by comparing these three parts of the tests in question, be able to see what causes the software to behave differently. Each test should clearly illustrate the cause and effect relationship between these three parts. This implies that what isn't visible in the test is just as important as what is visible. Too much code in the test distracts the reader with unimportant trivia. Whenever possible hide such trivia behind meaningful method calls — the Extract Method refactoring is your best friend. And make sure you give each test a meaningful name that describes the particular usage scenario so the test reader doesn't have to reverse engineer each test to understand what the various scenarios are. Between them, the names of the test class and class method should include at least the starting point and how the software is being invoked. This allows the test coverage to be verified via a quick scan of the method names. It can also be useful to include the expected results in the test method names as long as this doesn't cause the names to be too long to see or read.
 
 It is also a good idea to test your tests. You can verify they detect the errors you think they detect by inserting those errors into the production code (your own private copy that you'll throw away, of course). Make sure they report errors in a helpful and meaningful way. You should also verify that your tests speak clearly to a person trying to understand your code. The only way to do this is to have someone who isn't familiar with your code read your tests and tell you what they learned. Listen carefully to what they say. If they didn't understand something clearly it probably isn't because they aren't very bright. It is more likely that you weren't very clear. (Go ahead and reverse the roles by reading their tests!)
 
-by [Gerard Meszaros](http://programmer.97things.oreilly.com/wiki/index.php/Gerard_Meszaros)
+by [Gerard Meszaros](http://programmer.97things.oreilly.com/wiki/index.php/Gerard_Meszaros)

en/thing_96/README.md

@@ -1,4 +1,4 @@
-# You Gotta Care about the Code
+# You Gotta Care About the Code
 
 It doesn't take Sherlock Holmes to work out that good programmers write good code. Bad programmers... don't. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer.
 
@@ -20,4 +20,4 @@ You want to write good code. You want to be a good programmer. So, you care abou
 
 Fortunately, you're reading this collection of advice because you do care about code. It interests you. It's your passion. Have fun programming. Enjoy cutting code to solve tricky problems. Produce software that makes you proud.
 
-By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe)
+By [Pete Goodliffe](http://programmer.97things.oreilly.com/wiki/index.php/Pete_Goodliffe)