diff --git a/coffeescript/04_idioms.html b/coffeescript/04_idioms.html
index 9d9dd3d..5b59295 100644
--- a/coffeescript/04_idioms.html
+++ b/coffeescript/04_idioms.html
@@ -262,7 +262,7 @@ <h2>External libraries</h2>
 
 <h2>Private variables</h2>
 
-<p>The <code>do</code> keyword in CoffeeScript lets us execute functions immediately, a great way of encapsulating scope &amp; protecting variables. In the example below, we're defining a variable <code>classToType</code> in the context of an anonymous function which's immediately called by <code>do</code>. That anonymous function returns a second anonymous function, which will be ultimate value of <code>type</code>. Since <code>classToType</code> is defined in a context that no reference is kept to, it can't be accessed outside that scope.</p>
+<p>The <code>do</code> keyword in CoffeeScript lets us execute functions immediately, a great way of encapsulating scope &amp; protecting variables. In the example below, we're defining a variable <code>classToType</code> in the context of an anonymous function which is immediately called by <code>do</code>. That anonymous function returns a second anonymous function, which will be ultimate value of <code>type</code>. Since <code>classToType</code> is defined in a context that no reference is kept to, it can't be accessed outside that scope.</p>
 
 <p><span class="csscript"></span></p>
 
diff --git a/coffeescript/07_the_bad_parts.html b/coffeescript/07_the_bad_parts.html
index 7084506..b612d71 100644
--- a/coffeescript/07_the_bad_parts.html
+++ b/coffeescript/07_the_bad_parts.html
@@ -240,7 +240,7 @@ <h2>Number property lookups</h2>
 
 <h1>The un-fixed parts</h1>
 
-<p>Whilst CoffeeScript goes some length to solving some of JavaScript's design flaws, it can only go so far. As I mentioned previously, CoffeeScript's strictly limited to static analysis by design, and doesn't do any runtime checking for performance reasons. CoffeeScript uses a straight source-to-source compiler, the idea being that every CoffeeScript statement results in a equivalent JavaScript statement. CoffeeScript doesn't provide an abstraction over any of JavaScript's keywords, such as <code>typeof</code>, and as such some design flaws in JavaScript's design also apply to CoffeeScript.</p>
+<p>Whilst CoffeeScript goes some length to solving some of JavaScript's design flaws, it can only go so far. As I mentioned previously, CoffeeScript's strictly limited to static analysis by design, and doesn't do any runtime checking for performance reasons. CoffeeScript uses a straight source-to-source compiler, the idea being that every CoffeeScript statement results in an equivalent JavaScript statement. CoffeeScript doesn't provide an abstraction over any of JavaScript's keywords, such as <code>typeof</code>, and as such some design flaws in JavaScript's design also apply to CoffeeScript.</p>
 
 <p>In the previous sections we covered some design flaws in JavaScript that CoffeeScript fixes. Now let's talk about some of JavaScript's flaws that CoffeeScript can't fix.</p>
 
@@ -291,7 +291,7 @@ <h2>Using typeof</h2>
 new Object()        Object     object
 </code></pre>
 
-<p>As you can see, depending on if you define a string with quotes or with the <code>String</code> class affects the result of <code>typeof</code>. Logically <code>typeof</code> should return <code>"string"</code> for both checks, but for the latter it returns <code>"object"</code>. Unfortunately the inconstancies only get worse from there.</p>
+<p>As you can see, depending on if you define a string with quotes or with the <code>String</code> class affects the result of <code>typeof</code>. Logically <code>typeof</code> should return <code>"string"</code> for both checks, but for the latter it returns <code>"object"</code>. Unfortunately the inconsistencies only get worse from there.</p>
 
 <p>So what can we use for type checking in JavaScript? Well, luckily <code>Object.prototype.toString()</code> comes to the rescue here. If we invoke that function in the context of a particular object, it'll return the correct type. All we need to do is massage the string it returns, so we end up with the sort of string <code>typeof</code> should be returning. Here's an example implementation ported from jQuery's <code>$.type</code>:</p>
 
@@ -317,7 +317,7 @@ <h2>Using typeof</h2>
 type({})         # "object"
 </code></pre>
 
-<p>If you're checking to see if an variable has been defined, you'll still need to use <code>typeof</code> otherwise you'll get a <code>ReferenceError</code>.</p>
+<p>If you're checking to see if a variable has been defined, you'll still need to use <code>typeof</code> otherwise you'll get a <code>ReferenceError</code>.</p>
 
 <p><span class="csscript"></span></p>
 
@@ -491,7 +491,7 @@ <h3>Strict mode usage</h3>
   class window.Spine
 </code></pre>
 
-<p>Whilst I recommend enabling strict mode, but it's worth noting that script mode doesn't enable any new features that aren't ready possible in JavaScript, and will actually slow down your code a bit by having the VM do more checks at runtime. You may want to develop with strict mode, and deploy to production without it.</p>
+<p>Whilst I recommend enabling strict mode, it's worth noting that strict mode doesn't enable any new features that aren't already possible in JavaScript, and will actually slow down your code a bit by having the VM do more checks at runtime. You may want to develop with strict mode, and deploy to production without it.</p>
 
 <h2>JavaScript Lint</h2>
 
diff --git a/coffeescript/README b/coffeescript/README
index 9ffea2b..45e70ec 100644
--- a/coffeescript/README
+++ b/coffeescript/README
@@ -10,8 +10,6 @@ TODO:
 
 * "As you can see above, if the if statement is on one line, you'll need to use the then keyword" ... the "then" keyword can actually be in any place where you'd otherwise put an indented block, throughout the language.
 
-* The Max/Min trick is great, but will fail for really large arrays, which is worth mentioning. (Functions can only take so many arguments in certain browsers).
-
 
 Extras:
 
diff --git a/coffeescript/chapters/04_idioms.md b/coffeescript/chapters/04_idioms.md
index 606b0a1..99deabe 100644
--- a/coffeescript/chapters/04_idioms.md
+++ b/coffeescript/chapters/04_idioms.md
@@ -216,7 +216,7 @@ Since all of CoffeeScript's output is wrapped in an anonymous function, we can s
 
 ##Private variables
 
-The `do` keyword in CoffeeScript lets us execute functions immediately, a great way of encapsulating scope & protecting variables. In the example below, we're defining a variable `classToType` in the context of an anonymous function which's immediately called by `do`. That anonymous function returns a second anonymous function, which will be ultimate value of `type`. Since `classToType` is defined in a context that no reference is kept to, it can't be accessed outside that scope.
+The `do` keyword in CoffeeScript lets us execute functions immediately, a great way of encapsulating scope & protecting variables. In the example below, we're defining a variable `classToType` in the context of an anonymous function which is immediately called by `do`. That anonymous function returns a second anonymous function, which will be ultimate value of `type`. Since `classToType` is defined in a context that no reference is kept to, it can't be accessed outside that scope.
 
 <span class="csscript"></span>
 
diff --git a/coffeescript/chapters/07_the_bad_parts.md b/coffeescript/chapters/07_the_bad_parts.md
index c3e3ef5..f7baefb 100644
--- a/coffeescript/chapters/07_the_bad_parts.md
+++ b/coffeescript/chapters/07_the_bad_parts.md
@@ -199,7 +199,7 @@ Fortunately CoffeeScript's parsers is clever enough to deal with this issue by u
 
 #The un-fixed parts
 
-Whilst CoffeeScript goes some length to solving some of JavaScript's design flaws, it can only go so far. As I mentioned previously, CoffeeScript's strictly limited to static analysis by design, and doesn't do any runtime checking for performance reasons. CoffeeScript uses a straight source-to-source compiler, the idea being that every CoffeeScript statement results in a equivalent JavaScript statement. CoffeeScript doesn't provide an abstraction over any of JavaScript's keywords, such as `typeof`, and as such some design flaws in JavaScript's design also apply to CoffeeScript.
+Whilst CoffeeScript goes some length to solving some of JavaScript's design flaws, it can only go so far. As I mentioned previously, CoffeeScript's strictly limited to static analysis by design, and doesn't do any runtime checking for performance reasons. CoffeeScript uses a straight source-to-source compiler, the idea being that every CoffeeScript statement results in an equivalent JavaScript statement. CoffeeScript doesn't provide an abstraction over any of JavaScript's keywords, such as `typeof`, and as such some design flaws in JavaScript's design also apply to CoffeeScript.
 
 In the previous sections we covered some design flaws in JavaScript that CoffeeScript fixes. Now let's talk about some of JavaScript's flaws that CoffeeScript can't fix.
 
@@ -247,7 +247,7 @@ To illustrate the problem, here's a table taken from [JavaScript Garden](http://
     {}                  Object     object
     new Object()        Object     object
     
-As you can see, depending on if you define a string with quotes or with the `String` class affects the result of `typeof`. Logically `typeof` should return `"string"` for both checks, but for the latter it returns `"object"`. Unfortunately the inconstancies only get worse from there. 
+As you can see, depending on if you define a string with quotes or with the `String` class affects the result of `typeof`. Logically `typeof` should return `"string"` for both checks, but for the latter it returns `"object"`. Unfortunately the inconsistencies only get worse from there.
 
 So what can we use for type checking in JavaScript? Well, luckily `Object.prototype.toString()` comes to the rescue here. If we invoke that function in the context of a particular object, it'll return the correct type. All we need to do is massage the string it returns, so we end up with the sort of string `typeof` should be returning. Here's an example implementation ported from jQuery's `$.type`:
 
@@ -272,7 +272,7 @@ So what can we use for type checking in JavaScript? Well, luckily `Object.protot
     type(null)       # "null"
     type({})         # "object"
     
-If you're checking to see if an variable has been defined, you'll still need to use `typeof` otherwise you'll get a `ReferenceError`.
+If you're checking to see if a variable has been defined, you'll still need to use `typeof` otherwise you'll get a `ReferenceError`.
 
 <span class="csscript"></span>
 
@@ -423,7 +423,7 @@ The reason behind this disparity is that in strict mode `this` is `undefined`, w
       "use strict"
       class window.Spine
       
-Whilst I recommend enabling strict mode, but it's worth noting that strict mode doesn't enable any new features that aren't ready possible in JavaScript, and will actually slow down your code a bit by having the VM do more checks at runtime. You may want to develop with strict mode, and deploy to production without it.
+Whilst I recommend enabling strict mode, it's worth noting that strict mode doesn't enable any new features that aren't already possible in JavaScript, and will actually slow down your code a bit by having the VM do more checks at runtime. You may want to develop with strict mode, and deploy to production without it.
 
 ##JavaScript Lint