changed several spelling/grammar errors

_includes/mc_vs_ed/10.html

@@ -1,4 +1,4 @@
 <div id="main">
-  <p>So, separate collections are good if you need to select individual documents, need more control over querying or have huge documents.</p>
+  <p>So, separate collections are good if you need to select individual documents, need more control over querying, or have huge documents.</p>
   <p>Embedded documents are good when you want the entire document, the document with a $slice of comments, or with no comments at all.</p>
 </div>

_includes/mc_vs_ed/7.html

@@ -1,7 +1,7 @@
 <div id="main">Separate collections require more work</div>
 
 <pre>
-  // finding a post + its comments is two queries and require extra work
+  // finding a post + its comments is two queries and requires extra work
   // in your code to make it all pretty (or your ODM might do it for you)
   db.posts.find({_id: 9001});
   db.comments.find({post_id: 9001})

_posts/2011-10-12-Speedig-Up-Queries-Understanding-Query-Plans.html

@@ -62,7 +62,7 @@ <h3>Field Order</h3>
     <div class="text">
       <p>The order of the fields used to create your index is critical. The good news is that, if you get the order wrong, the index won't be used at all, so it'll be easy to spot with <code>explain</code>.</p>
       <p>The queries on the right are two different queries. What's important though is that the first query cannot use the index because <code>cat</code> is defined first in our index. You should think of compound indexes as having the field values concatenated together. So, an "index value" of "book405" (cat + qty) can only be used to find something by cat <strong>or</strong> cat and qty.</p>
-      <p>The two queries return around the same number of documents, but the second, index-powered query, has to scan a significant smaller number of objects. This is due to the logrithmic nature of B-trees, which Mongo indexes use.</p>
+      <p>The two queries return around the same number of documents, but the second, index-powered query, has to scan a significant smaller number of objects. This is due to the logarithmic nature of B-trees, which Mongo indexes use.</p>
     </div>
     <pre>db.products.createIndex({cat: 1, qty: 1})
 db.products.find({qty: {$gt: 400}}).explain()

_posts/2011-10-15-ObjectIds-Are-Predictable.html

@@ -11,6 +11,6 @@ <h1>{{ page.title }}</h1>
 <ul>
   <li>Do not treat ObjectIds as secure.</li>
   <li>For example, don't use them as password-reset tokens.
-  <li>Treat ObjectIds are you would an auto-incrementing integer.</li>
+  <li>Treat ObjectIds as you would an auto-incrementing integer.</li>
   <li>This is not a design flaw of ObjectId.</li>
-</ul>
+</ul>

_posts/2011-10-16-Demystifying-Write-Durability.html

@@ -10,7 +10,7 @@ <h1>{{ page.title }}</h1>
 <p>Much has been said about MongoDB's write durability. Some of it true, some of it not, and some of it was once true but no longer is. This can lead to confusion about a topic where no confusion should exist.</p>
 
 <h2>History</h2>
-<p>There was a time when an insert or update happened in memory with no options available to developers. The data files would get synched periodically (configurable, but defaulting to 60 second). This meant that, should the server crash, up to 60 seconds of writes would be lost. At the time, the answer to this was to run replica pairs (which were later replaced with replica sets). As the number of machines in your replica set grows, the chances of data loss decreases.</p>
+<p>There was a time when an insert or update happened in memory with no options available to developers. The data files would get synced periodically (configurable, but defaulting to 60 second). This meant that, should the server crash, up to 60 seconds of writes would be lost. At the time, the answer to this was to run replica pairs (which were later replaced with replica sets). As the number of machines in your replica set grows, the chances of data loss decreases.</p>
 
 <p>But replication is asynchronous, meaning the master could crash before replicating your data. Under this circumstance, the loss-of-data window was much smaller than 60 seconds, but it was still a concern. It therefore became possible, by calling <code>getLastError</code> with <code>{w:N}</code> after a write, to specify the number (N) of servers the write must be replicated to before returning.</p>
 
@@ -19,7 +19,7 @@ <h2>History</h2>
 <p>Then 1.8 added journaling and 2.0 enabled it by default. This largely addressed any concern about MongoDB write durability, especially for single-server setups.</p>
 
 <h2>Current State</h2>
-<p>Although journaling is now enabled by default, it's important to know that it does group commits. That means, writes are still done in memory. The difference though is that the journal file is synched every 100ms (configurable down to 2ms), while the data files continue to sync every 60 seconds. So, there's still a window of possible data loss, though it's much smaller. If you are wondering why it's ok to sync one often (100ms) and the other not (60s), it's because journaling uses an append-only file, which is much faster to write to.</p>
+<p>Although journaling is now enabled by default, it's important to know that it does group commits. That means, writes are still done in memory. The difference though is that the journal file is synced every 100ms (configurable down to 2ms), while the data files continue to sync every 60 seconds. So, there's still a window of possible data loss, though it's much smaller. If you are wondering why it's ok to sync one often (100ms) and the other not (60s), it's because journaling uses an append-only file, which is much faster to write to.</p>
 
 <p>There are two things developers can do to eliminate the remaining gap, both using <code>getLastError</code>. You can use either one, or both. First, the <code>{w:N}</code> option remains available. Secondly, you can specify <code>{j: true}</code>, which won't return until the journal data is committed to disk. (to specify both, you use <code>{j: true, w:N}</code>)</p>
 

_posts/2012-01-07-Does-My-Replica-Set-Need-An-Arbiter.html

@@ -23,7 +23,7 @@ <h2>Network Splits and Ties</h2>
 
 <p>You see, when you think of servers crashing, it's reasonable to expect any remaining server to be elected - even without a majority. Instead of servers going down, consider what would happen if the servers all remain operational but can't see each other. Let's look at an example</p>
 
-<p>Pretend we have 4 servers - representing a [evil] even number of votes: A, B, C and D. AB are in one data center (or availability zone) while CD are in another. Now, the link between the two datacenter dies. What would happen? Each group thinks the other is down and could both elect their own primary. This would cause data conflicts (two servers would be accepting writes).</p>
+<p>Pretend we have 4 servers - representing a [evil] even number of votes: A, B, C and D. AB are in one data center (or availability zone) while CD are in another. Now, the link between the two data-centers dies. What would happen? Each group thinks the other is down and could both elect their own primary. This would cause data conflicts (two servers would be accepting writes).</p>
 
 <p>So let's introduce an arbiter (E) and with it, an uneven number of votes. Now each servers knows that the set is made up of 5 votes, and thus 3 votes are required to elect a new primary. Whatever group E ends up with (either ABE or CDE) a primary will be elected, and, more importantly, whatever group E doesn't end up with won't be able to elect a primary.</p>