Fix typos

Author: lex111

1-js/09-classes/04-private-protected-properties-methods/article.md

@@ -171,7 +171,7 @@ class CoffeeMachine {
 new CoffeeMachine().setWaterAmount(100);
 ```
 
-That looks a bit longer, but functions are more flexible. They can accept multiple arguments (even if we don't need them right now). So, for the future, just in case we need to refactor something, functions are a safer choise.
+That looks a bit longer, but functions are more flexible. They can accept multiple arguments (even if we don't need them right now). So, for the future, just in case we need to refactor something, functions are a safer choice.
 
 Surely, there's a tradeoff. On the other hand, get/set syntax is shorter, so ultimately there's no strict rule, it's up to you to decide.
 ````

1-js/09-classes/06-instanceof/article.md

@@ -182,7 +182,7 @@ alert( {}.toString.call(user) ); // [object User]
 For most environment-specific objects, there is such a property. Here are few browser specific examples:
 
 ```js run
-// toStringTag for the envinronment-specific object and class:
+// toStringTag for the environment-specific object and class:
 alert( window[Symbol.toStringTag]); // window
 alert( XMLHttpRequest.prototype[Symbol.toStringTag] ); // XMLHttpRequest
 

1-js/10-error-handling/1-try-catch/article.md

@@ -68,7 +68,7 @@ Let's see more examples.
 
     } catch(err) {
 
-      alert(`Error has occured!`); // *!*(3) <--*/!*
+      alert(`Error has occurred!`); // *!*(3) <--*/!*
 
     }
 

1-js/11-async/02-promise-basics/article.md

@@ -148,7 +148,7 @@ The second argument of `.then` is a function that:
 1. runs when the Promise is rejected, and
 2. receives the error.
 
-For instance, here's a reaction to a successfuly resolved promise:
+For instance, here's a reaction to a successfully resolved promise:
 
 ```js run
 let promise = new Promise(function(resolve, reject) {

1-js/11-async/07-microtask-queue/article.md

@@ -167,7 +167,7 @@ setTimeout(() => promise.catch(err => alert('caught')));
 window.addEventListener('unhandledrejection', event => alert(event.reason));
 ```
 
-Now the unhandled rejction appears again. Why? Because `unhandledrejection` triggers when the microtask queue is complete. The engine examines promises and, if any of them is in "rejected" state, then the event is generated.
+Now the unhandled rejection appears again. Why? Because `unhandledrejection` triggers when the microtask queue is complete. The engine examines promises and, if any of them is in "rejected" state, then the event is generated.
 
 In the example, the `.catch` added by `setTimeout` triggers too, of course it does, but later, after `unhandledrejection` has already occurred.