for consistency, replacing 'Summary' with 'Review' to match first two…

… titles

async & performance/apA.md

@@ -815,7 +815,7 @@ foo( 8, 9 )
 
 There's a lot more awesome that `runner(..)` is capable of, but we'll come back to that in the next appendix.
 
-## Summary
+## Review
 
 *asynquence* is a simple abstraction -- a sequence is a series of (async) steps -- on top of promises, aimed at making working with various asynchronous patterns much easier, without any compromise in capability.
 

async & performance/apB.md

@@ -822,7 +822,7 @@ If there are any remaining values in the `ch` channel at the end of the goroutin
 
 **Note:** See many more examples of using *asynquence*-flavored CSP here (https://gist.github.com/getify/e0d04f1f5aa24b1947ae).
 
-## Summary
+## Review
 
 Promises and generators provide the foundational building blocks upon which we can build much more sophisticated and capable asynchrony.
 

async & performance/ch1.md

@@ -879,7 +879,7 @@ While JS semantics thankfully protect us from the *observable* nightmares that c
 
 Compiler statement reordering is almost a micro-metaphor for concurrency and interaction. As a general concept, such awareness can help you understand async JS code flow issues better.
 
-## Summary
+## Review
 
 A JavaScript program is (practically) always broken up into two or more chunks, where the first chunk runs *now* and the next chunk runs *later*, in response to an event. Even though the program is executed chunk-by-chunk, all of them share the same access to the program scope and state, so each modification to state is made on top of the previous state.
 

async & performance/ch2.md

@@ -588,7 +588,7 @@ That's just the story, over and over again, with callbacks. They can do pretty m
 
 You might find yourself wishing for built-in APIs or other language mechanics to address these issues. Finally ES6 has arrived on the scene with some great answers, so keep reading!
 
-## Summary
+## Review
 
 Callbacks are the fundamental unit of asynchrony in JS. But they're not enough for the evolving landscape of async programming as JS matures.
 

async & performance/ch3.md

@@ -2114,7 +2114,7 @@ Instead, you should default to using them across the code base, and then profile
 
 Promises are a little slower, but you're getting a lot of trustability, non-Zalgo predictability, and composability built-in, in exchange. So maybe the limitation is not actually their performance, but your lack of perception of their benefits?
 
-## Summary
+## Review
 
 Promises are awesome. Use them. They solve all the *inversion of control* issues that plague us with callbacks-only code.
 

async & performance/ch4.md

@@ -2294,7 +2294,7 @@ This is more work than just using a `Promise` API polyfill for pre-ES6 promises,
 
 Once you get hooked on generators, you'll never want to go back to the hell of async spaghetti callbacks!
 
-## Summary
+## Review
 
 Generators are a new ES6 function type which does not run-to-completion like normal functions. Instead, the generator can be paused in mid-completion (entirely preserving its state), and it can later be resumed from where it left off.
 

async & performance/ch5.md

@@ -390,7 +390,7 @@ The first call to `fooASM(..)` is what sets up our asm.js module with its `heap`
 
 Obviously, the nature of restrictions that make asm.js code so optimizable reduces the use cases for such code significantly. asm.js won't necessarily be a general optimization set for any general JS program. Instead, it's intended to provide an optimized way of handling specialized tasks such as intensive math operations (like those used in graphics processing in games, for instance).
 
-## Summary
+## Review
 
 The first four chapters of this book are based on the premise that async coding patterns give you the ability to write more performant code, which is generally a very important improvement. But async behavior only gets you so far, because it's still fundamentally bound to a single event loop thread.
 

async & performance/ch6.md

@@ -592,7 +592,7 @@ If the lack of TCO in the engine would just gracefully degrade to slower perform
 
 ES6 guarantees that from now on, JS developers will be able to rely on this optimization across all ES6+ compliant browsers. That's a win for JS performance!
 
-## Summary
+## Review
 
 Effectively benchmarking performance of a piece of code, especially to compare it to another option for that same code to see which approach is faster, requires careful attention to detail.
 

es6 & beyond/ch1.md

@@ -3,4 +3,4 @@
 
 // TODO
 
-## Summary
+## Review

types & grammar/apA.md

@@ -384,7 +384,7 @@ Examples of other limits known to exist:
 
 It's not very common at all to run into these limits, but you should be aware that limits can and do exist, and importantly that they vary between engines.
 
-## Summary
+## Review
 
 We know and can rely upon the fact that the JS language itself has one standard and is predictably implemented by all the modern browsers/engines. This is a very good thing!
 

types & grammar/ch1.md

@@ -286,7 +286,7 @@ function doSomethingCool(FeatureXYZ) {
 
 There's lots of options when designing such functionality. No one pattern here is "correct" or "wrong" -- there are various tradeoffs to each approach. But overall, it's nice that the `typeof` undeclared safety guard gives us more options.
 
-## Summary
+## Review
 
 JavaScript has seven built-in *types*: `null`, `undefined`,  `boolean`, `number`, `string`, `object`, `symbol`. They can be identified by the `typeof` operator.
 

types & grammar/ch2.md

@@ -971,7 +971,7 @@ Instead of using the wrapper object `Number` in this way, it's probably much bet
 
 References are quite powerful, but sometimes they get in your way, and sometimes you need them where they don't exist. The only control you have over reference vs. value-copy behavior is the type of the value itself, so you must indirectly influence the assignment/passing behavior by which value types you choose to use.
 
-## Summary
+## Review
 
 In JavaScript, `array`s are simply numerically indexed collections of any value-type. `string`s are somewhat "`array`-like", but they have distinct behaviors and care must be taken if you want to treat them as `array`s. Numbers in JavaScript include both "integers" and floating-point values.
 

types & grammar/ch3.md

@@ -477,7 +477,7 @@ Also, be very careful not to use `Array.prototype` as a default value **that wil
 
 **Note:** While we're pointing out these native prototypes and some usefulness, be cautious of relying on them and even more wary of modifying them in anyway. See Appendix A "Native Prototypes" for more discussion.
 
-## Summary
+## Review
 
 JavaScript provides object wrappers around primitive values, known as natives (`String`, `Number`, `Boolean`, etc). These object wrappers give the values access to behaviors appropriate for each object sub-type (`String#trim()` and `Array#concat(..)`).
 

types & grammar/ch4.md

@@ -1882,7 +1882,7 @@ a < b;						// false -- string comparison!
 Number( a ) < Number( b );	// true -- number comparison!
 ```
 
-## Summary
+## Review
 
 In this chapter, we turned our attention to how JavaScript type conversions happen, called **coercion**, which can be characterized as either *explicit* or *implicit*.
 

types & grammar/ch5.md

@@ -1341,7 +1341,7 @@ The way this snippet processes is that it passes through all the `case` clause m
 
 While this sort of round-about logic is clearly possible in JavaScript, there's almost no chance that it's going to make for reasonable or understandable code. Be very skeptical if you find yourself wanting to create such circular logic flow, and if you really do, make sure you include plenty of code comments to explain what you're up to!
 
-## Summary
+## Review
 
 JavaScript grammar has plenty of nuance that we as developers should spend a little more time paying closer attention to than we typically do. A little bit of effort goes a long way to solidifying your deeper knowledge of the language.
 

up & going/ch1.md

@@ -417,7 +417,7 @@ if (amount > BANK_BALANCE) {
 
 How did you do? It wouldn't hurt to try it again now that you've seen my code. And play around with changing some of the constants to see how the program runs with different values.
 
-## Summary
+## Review
 
 Learning programming doesn't have to be a complex and involved process. There are just a few basic concepts you need to wrap your head around. These act like building blocks. To build a tall tower, you start first by putting block on top of block on top of block. The same goes with programming.
 

up & going/ch2.md

@@ -715,7 +715,7 @@ The same goes with `console.log(..)`. Your browser provides such mechanisms and
 
 This book, and this whole book series, focuses on JavaScript the language. That's why you don't see any substantial coverage of these non-JavaScript JavaScript mechanisms.
 
-## Summary
+## Review
 
 The first step to learning JavaScript's flavor of programming is to get a basic understandng of its core mechanisms like values, types, function closures, `this`, and prototypes.
 

up & going/ch3.md

@@ -95,7 +95,7 @@ The latter part of the book turns attention to briefly glance at things which we
 
 The future for JavaScript is bright. Isn't it time we start learning it!?
 
-## Summary
+## Review
 
 The YDKJS series is dedicated to the proposition that all JS developers can and should learn all of the parts of this great language. No person's opinion, no framework's assumptions, no project's deadline, should be the excuse for why you never learn and deeply understand JavaScript.