images to svg

Author: iliakan

Diff for: 1-js/01-getting-started/1-intro/article.md

@@ -75,7 +75,7 @@ Examples of such restrictions include:
     This limitation is, again, for the user's safety. A page from `http://anysite.com` which a user has opened must not be able to access another browser tab with the URL `http://gmail.com` and steal information from there.
 - JavaScript can easily communicate over the net to the server where the current page came from. But its ability to receive data from other sites/domains is crippled. Though possible, it requires explicit agreement (expressed in HTTP headers) from the remote side. Once again, that's a safety limitation.
 
-![](limitations.png)
+![](limitations.svg)
 
 Such limits do not exist if JavaScript is used outside of the browser, for example on a server. Modern browsers also allow plugin/extensions which may ask for extended permissions.
 

Diff for: 1-js/01-getting-started/1-intro/limitations.png

@@ -99,7 +99,7 @@ We can easily grasp the concept of a "variable" if we imagine it as a "box" for
 
 For instance, the variable `message` can be imagined as a box labeled `"message"` with the value `"Hello!"` in it:
 
-![](variable.png)
+![](variable.svg)
 
 We can put any value in the box.
 
@@ -116,7 +116,7 @@ alert(message);
 
 When the value is changed, the old data is removed from the variable:
 
-![](variable-change.png)
+![](variable-change.svg)
 
 We can also declare two variables and copy data from one into the other.
 

Diff for: 1-js/01-getting-started/1-intro/limitations.svg

@@ -22,7 +22,7 @@ The toggler button <span class="devtools" style="background-position:-168px -76p
 
 Let's click it and select `hello.js` in the tree view. Here's what should show up:
 
-![](chrome-tabs.png)
+![](chrome-tabs.svg)
 
 Here we can see three zones:
 
@@ -40,7 +40,7 @@ After a statement is executed, its result is shown below.
 
 For example, here `1+2` results in `3`, and `hello("debugger")` returns nothing, so the result is `undefined`:
 
-![](chrome-sources-console.png)
+![](chrome-sources-console.svg)
 
 ## Breakpoints
 

Diff for: 1-js/01-getting-started/1-intro/limitations@2x.png

@@ -4,7 +4,7 @@ As we know from the chapter <info:structure>, comments can be single-line: start
 
 We normally use them to describe how and why the code works.
 
-At first sight, commenting might be obvious, but novices in programming usually get it wrong.
+At first sight, commenting might be obvious, but novices in programming often use them wrongly.
 
 ## Bad comments
 
@@ -120,9 +120,9 @@ In reality, we can't totally avoid "explanatory" comments. There are complex alg
 So, explanatory comments are usually bad. Which comments are good?
 
 Describe the architecture
-: Provide a high-level overview of components, how they interact, what's the control flow in various situations... In short -- the bird's eye view of the code. There's a special diagram language [UML](http://wikipedia.org/wiki/Unified_Modeling_Language) for high-level architecture diagrams. Definitely worth studying.
+: Provide a high-level overview of components, how they interact, what's the control flow in various situations... In short -- the bird's eye view of the code. There's a special language [UML](http://wikipedia.org/wiki/Unified_Modeling_Language) to build high-level architecture diagrams explaining the code. Definitely worth studying.
 
-Document a function usage
+Document function parameters and usage
 : There's a special syntax [JSDoc](http://en.wikipedia.org/wiki/JSDoc) to document a function: usage, parameters, returned value.
 
     For instance:

Diff for: 1-js/02-first-steps/04-variables/article.md

@@ -18,15 +18,15 @@ For instance, we're creating a function `f`. Wrote some code, testing: `f(1)` wo
 
 That's very typical. When we develop something, we keep a lot of possible use cases in mind. But it's hard to expect a programmer to check all of them manually after every change. So it becomes easy to fix one thing and break another one.
 
-**Automated testing means that tests are written separately, in addition to the code. They can be executed automatically and check all the main use cases.**
+**Automated testing means that tests are written separately, in addition to the code. They run our functions in various ways and compare results with the expected.**
 
 ## Behavior Driven Development (BDD)
 
-Let's use a technique named [Behavior Driven Development](http://en.wikipedia.org/wiki/Behavior-driven_development) or, in short, BDD. That approach is used among many projects. BDD is not just about testing. That's more.
+Let's start with a technique named [Behavior Driven Development](http://en.wikipedia.org/wiki/Behavior-driven_development) or, in short, BDD.
 
 **BDD is three things in one: tests AND documentation AND examples.**
 
-Let's see the example.
+To understand BDD, we'll examine a practical case of development.
 
 ## Development of "pow": the spec
 
@@ -36,7 +36,7 @@ That task is just an example: there's the `**` operator in JavaScript that can d
 
 Before creating the code of `pow`, we can imagine what the function should do and describe it.
 
-Such description is called a *specification* or, in short, a spec, and looks like this:
+Such description is called a *specification* or, in short, a spec, and contains descriptions of use cases together with tests for them, like this:
 
 ```js
 describe("pow", function() {
@@ -51,17 +51,17 @@ describe("pow", function() {
 A spec has three main building blocks that you can see above:
 
 `describe("title", function() { ... })`
-: What functionality we're describing. Uses to group "workers" -- the `it` blocks. In our case we're describing the function `pow`.
+: What functionality we're describing. In our case we're describing the function `pow`. Used to group "workers" -- the `it` blocks.
 
 `it("use case description", function() { ... })`
 : In the title of `it` we *in a human-readable way* describe the particular use case, and the second argument is a function that tests it.
 
 `assert.equal(value1, value2)`
 : The code inside `it` block, if the implementation is correct, should execute without errors.
 
-    Functions `assert.*` are used to check whether `pow` works as expected. Right here we're using one of them -- `assert.equal`, it compares arguments and yields an error if they are not equal. Here it checks that the result of `pow(2, 3)` equals `8`.
+    Functions `assert.*` are used to check whether `pow` works as expected. Right here we're using one of them -- `assert.equal`, it compares arguments and yields an error if they are not equal. Here it checks that the result of `pow(2, 3)` equals `8`. There are other types of comparisons and checks, that we'll add later.
 
-    There are other types of comparisons and checks that we'll see further.
+The specification can be executed, and it will run the test specified in `it` block. We'll see that later.
 
 ## The development flow
 
@@ -79,7 +79,7 @@ So, the development is *iterative*. We write the spec, implement it, make sure t
 
 Let's see this development flow in our practical case.
 
-The first step is complete: we have an initial spec for `pow`. Now, before making the implementaton, let's use few JavaScript libraries to run the tests, just to see that they are working (they will all fail).
+The first step is already complete: we have an initial spec for `pow`. Now, before making the implementaton, let's use few JavaScript libraries to run the tests, just to see that they are working (they will all fail).
 
 ## The spec in action
 
@@ -336,10 +336,9 @@ The result with new tests:
 The newly added tests fail, because our implementation does not support them. That's how BDD is done: first we write failing tests, and then make an implementation for them.
 
 ```smart header="Other assertions"
-
 Please note the assertion `assert.isNaN`: it checks for `NaN`.
 
-There are other assertions in Chai as well, for instance:
+There are other assertions in [Chai](http://chaijs.com) as well, for instance:
 
 - `assert.equal(value1, value2)` -- checks the equality  `value1 == value2`.
 - `assert.strictEqual(value1, value2)` -- checks the strict equality `value1 === value2`.
@@ -380,9 +379,9 @@ In BDD, the spec goes first, followed by implementation. At the end we have both
 
 The spec can be used in three ways:
 
-1. **Tests** guarantee that the code works correctly.
-2. **Docs** -- the titles of `describe` and `it` tell what the function does.
-3. **Examples** -- the tests are actually working examples showing how a function can be used.
+1. As **Tests** - they guarantee that the code works correctly.
+2. As **Docs** -- the titles of `describe` and `it` tell what the function does.
+3. As **Examples** -- the tests are actually working examples showing how a function can be used.
 
 With the spec, we can safely improve, change, even rewrite the function from scratch and make sure it still works right.
 

Diff for: 1-js/02-first-steps/04-variables/variable-change.png

@@ -29,8 +29,8 @@ Actually, there are two parts in Babel:
     A script that updates/adds new functions is called "polyfill". It "fills in" the gap and adds missing implementations.
 
     Two interesting polyfills are:
-    - [babel polyfill](https://babeljs.io/docs/usage/polyfill/) that supports a lot, but is big.
-    - [polyfill.io](http://polyfill.io) service that allows to load/construct polyfills on-demand, depending on the features we need.
+    - [core js](https://github.com/zloirock/core-js) that supports a lot, allows to include only needed features.
+    - [polyfill.io](http://polyfill.io) service that provides a script with polyfills, depending on the features and user's browser.
 
 So, if we're going to use modern language features, a transpiler and a polyfill are necessary.