Fixed few typos in en.yml

_i18n/en.yml

@@ -342,7 +342,7 @@ pages:
     behavioral:
       title: "Behavioral patterns"
       description: "In software engineering, behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication."
-      chain_of_responsobility:
+      chain_of_responsibility:
         title: "Chain of responsibility pattern"
         description: "In object-oriented design, the chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain."
       command:
@@ -421,7 +421,7 @@ pages:
       title: "Don't quote me on this, but..."
       description: "String interpolation (including special chars like <span class=\"code-inline\">\\n</span>) fails with <span class=\"code-inline\">'single'</span> quotes - it requires <span class=\"code-inline\">\"double\"</span> quotes. Just like in most languages with string interpolation. To avoid it use doubles whenever practical."
     twue:
-      title: "It's twue! It's twue!"
+      title: "It's true! It's true!"
       description: "Only two things are false: <span class=\"code-inline\">false</span> and <span class=\"code-inline\">nil</span>. Everything else is truthy, even <span class=\"code-inline\">0</span> (false in C), <span class=\"code-inline\">\"\"</span> (false in JS), <span class=\"code-inline\">[]</span>, etc. Trips up people from C, JS, etc. where some of these are false."
     symbols_and_strings:
       title: "Hang him in effigy or String him up, symbolically."
@@ -536,7 +536,7 @@ pages:
     description: "In computer programming, SOLID (single responsibility, Open-closed, Liskov substitution, interface segregation, and dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the \"First Five Principles\" named by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented programming and design. The intention is that these principles, when applied together, will make it more likely that a programmer will create a system that is easy to maintain and extend over time. The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible. It is part of an overall strategy of agile and Adaptive Software Development."
     single:
       title: "Single Responsibility Principle"
-      description: "The Single Responsibility Principle is the most abstract of the bunch. It helps keep classes and methods small and maintainable. In addition to keeping classes small and focused it also makes them easier to understand.An example of this might be adding support for sending an email summary of a specific person’s commissions after marking a deal processed. The fact that we can identify multiple reasons to change signals a violation of the Single Responsibility Principle."
+      description: "The Single Responsibility Principle is the most abstract of the bunch. It helps keep classes and methods small and maintainable. In addition to keeping classes small and focused it also makes them easier to understand. An example of this might be adding support for sending an email summary of a specific person’s commissions after marking a deal processed. The fact that we can identify multiple reasons to change signals a violation of the Single Responsibility Principle."
     open_close:
       title: "Open / Closed Principle"
       description: "The Open / Closed Principle states that classes or methods should be open for extension, but closed for modification. This tells us we should strive for modular designs that make it possible for us to change the behavior of the system without making modifications to the classes themselves. This is generally achieved through the use of patterns such as the strategy pattern."
@@ -561,20 +561,20 @@ pages:
       description: "Ruby 1.9 replaced green threads with native threads. However, the GIL is still preventing parallelism. That being said, concurrency has been improved through better scheduling. The new schedule makes context-switch decisions more efficient, by essentially moving them to a separate native thread, known as the timer thread."
     gil:
       title: "GIL - Global Interpreter Lock"
-      description: "MRI has a global interpreter lock (GIL). It's a lock around the execution of Ruby code. This means that in a multi-threaded context, only one thread can execute Ruby code at any one time.So if you have 8 threads busily working on an 8-core machine, only one thread and one core will be busy at any given time. The GIL exists to protect Ruby internals from race conditions that could corrupt data. There are caveats and optimizations, but this is the gist."
+      description: "MRI has a global interpreter lock (GIL). It's a lock around the execution of Ruby code. This means that in a multi-threaded context, only one thread can execute Ruby code at any one time. So if you have 8 threads busily working on an 8-core machine, only one thread and one core will be busy at any given time. The GIL exists to protect Ruby internals from race conditions that could corrupt data. There are caveats and optimizations, but this is the gist."
       example: "This simple fact is what makes threads so powerful, and also what makes them difficult to work with. I've already given you an idea of why threads are good; here's a simple program to illustrate their difficulty. Here you can see that we have <span class=\"code-inline\">10 * 10000</span> elements in array. Note that different ruby can show a different result. GIL exist only in MRI ruby."
     mutex:
       title: "Mutex - Mutual Execution"
-      description: "Mutexes provide a mechanism for multiple threads to synchronize access to a critical portion of code. In other words, they help bring some order, and some guarantees, to the world of multi-threaded chaos.The name 'mutex' is shorthand for 'mutual exclusion.' If you wrap some section of your code with a mutex, you guarantee that no two threads can enter that section at the same time. Mutexes provide a mechanism for multiple threads to synchronize access to a critical portion of code. It helps bring some order and some guaranty to the world of multi-threaded chaos."
+      description: "Mutexes provide a mechanism for multiple threads to synchronize access to a critical portion of code. In other words, they help bring some order, and some guarantees, to the world of multi-threaded chaos. The name 'mutex' is shorthand for 'mutual exclusion.' If you wrap some section of your code with a mutex, you guarantee that no two threads can enter that section at the same time. Mutexes provide a mechanism for multiple threads to synchronize access to a critical portion of code. It helps bring some order and some guaranty to the world of multi-threaded chaos."
       example: "In this program, since any thread has to lock the mutex before it can push to the Array, there's a guarantee that no two threads will be performing this operation at the same time. In other words, this operation can no longer be interrupted before it's completed. Once one thread begins pushing to the Array, no other threads will be able to enter that portion of code until the first thread is finished. This operation is now thread-safe. Here you can see that we have <span class=\"code-inline\">10 * 10000</span> elements in array. Now all are same, because of the mutex. The mutex sets up the same boundaries for the thread. The first thread that hits this bit of code will lock the mutex. it then becomes the owner of that mutex. Until the owning thread unlocks the mutex, no other thread can lock it."
     fibers:
       title: "Fibers"
-      description: "Fibers are primitives for implementing light weight cooperative concurrency in Ruby. Basically, they are a means of creating code blocks that can be paused and resumed, much like threads. The main difference is that they are never preempted and that the scheduling must be done by the programmer and not the VM. As opposed to other stackless lightweight concurrency models, each fiber comes with a small 4KB stack. This enables the fiber to be paused from deeply nested function calls within the fiber block."
+      description: "Fibers are primitives for implementing light weight cooperative concurrency in Ruby. Basically, they are a means of creating code blocks that can be paused and resumed, much like threads. The main difference is that they are never pre-empted and that the scheduling must be done by the programmer and not the VM. As opposed to other stackless lightweight concurrency models, each fiber comes with a small 4KB stack. This enables the fiber to be paused from deeply nested function calls within the fiber block."
     rails:
       title: "Rails thread-safety"
       description: "The problem with this is that there is no simple way to say with absolute certainty whether an app as a whole is thread-safe. "
       global_variables: "Global variables are global. This means that they are shared between threads. If you weren’t convinced about not using global variables by now, here’s another reason to never touch them. If you really want to share something globally across an app, you are more than likely better served by a constant (but see below), anyway."
-      class_variables: "Class variables. For the purpose of a discussion about threads, class variables are not much different from global variables. They are shared across threads just the same way.The problem isn’t so much about using class variables, but about mutating them. And if you are not going to mutate a class variable, in many cases a constant is again a better choice."
+      class_variables: "Class variables. For the purpose of a discussion about threads, class variables are not much different from global variables. They are shared across threads just the same way. The problem isn’t so much about using class variables, but about mutating them. And if you are not going to mutate a class variable, in many cases a constant is again a better choice."
       instance_variables: "Class instance variables. But maybe you’ve read that you should always use class instance variables instead of class variables in Ruby. Well, maybe you should, but they are just as problematic for threaded programs as class variables."
       memoization: "Memoization by itself is not a thread safety issue. It is often used to store data in class variables or class instance variables (see the previous points). The <span class=\"code-inline\">||=</span> operator is, in fact, two operations, so there is a potential context switch happening in the middle of it, causing a race condition between threads. So even though you would only be using instance variables, you might end up with race conditions with memoization. Don’t memoize to class variables or class instance variables. If you need to memoize something on the class level, use thread local variables (<span class=\"code-inline\">Thread.current[:baz]</span>) instead. Be aware, though, that it is still kind of a global variable."
     config:
@@ -608,7 +608,7 @@ pages:
           title: "Structure and Interpretation of Computer Programs"
           description: "Structure and Interpretation of Computer Programs have had a dramatic impact on computer science curricula over the past decade. This long-awaited revision contains changes throughout the text. There are new implementations of most of the major programming systems in the book, including the interpreters and compilers, and the authors have incorporated many small changes that reflect their experience teaching the course at MIT since the first edition was published. A new theme has been introduced that emphasizes the central role played by different approaches to dealing with time in computational models: objects with state, concurrent programming, functional programming, and lazy evaluation, and nondeterministic programming."
           link: "https://www.amazon.com/gp/product/0262510871/ref=as_li_tl?ie=UTF8&tag=khusnetdinov-20&camp=1789&creative=9325&linkCode=as2&creativeASIN=0262510871&linkId=6e3898deeebdc0194f4f3604c09e84c4"
-        - name: "design_programms"
+        - name: "design_programs"
           title: "How to Design Programs: An Introduction to Programming and Computing"
           description: "This introduction to programming places computer science in the core of a liberal arts education. Unlike other introductory books, it focuses on the program design process. This approach fosters a variety of skills―critical reading, analytical thinking, creative synthesis, and attention to detail―that are important for everyone, not just future computer programmers. The book exposes readers to two fundamentally new ideas. First, it presents program design guidelines that show the reader how to analyze a problem statement; how to formulate concise goals; how to make up examples; how to develop an outline of the solution, based on the analysis; how to finish the program; and how to test."
           link: "https://www.amazon.com/gp/product/0262062186/ref=as_li_tl?ie=UTF8&tag=khusnetdinov-20&camp=1789&creative=9325&linkCode=as2&creativeASIN=0262062186&linkId=1fa435d64a33dfa781508818d2579677"