Edits

Author: Sashko Stubailo

content/collections.md

@@ -249,12 +249,12 @@ Point 3. can usually be resolved by placing the hook in the *Method* that calls
 
 <h3 id="abstracting-denormalizers">Abstracting denormalizers</h3>
 
-To properly abstract the logic of a denormalizer (which may need to happen on various mutators of more than one collection), it's sensible to define the logic of the denormalizer in one place, and "hook" it into the mutator with a single line of code. The advantage of this approach is that although the logic is in a single spot rather than spread over many files, you can still examine the code for one of the collections and fully understand what happens on each update.
+Denormalization may need to happen on various mutators of several collections. Therefore, it's sensible to define the denormalization logic in one place, and hook it into each mutator with one line of code. The advantage of this approach is that the denormalization logic is one place rather than spread over many files, but you can still examine the code for each collection and fully understand what happens on each update.
 
-In the Todos example app, we build a `incompleteCountDenormalizer` to abstract the counting of incomplete todos on the lists. This code needs to run whenever a todo item is inserted, updated (it could be checked or unchecked), or removed. The code looks like:
+In the Todos example app, we build a `incompleteCountDenormalizer` to abstract the counting of incomplete todos on the lists. This code needs to run whenever a todo item is inserted, updated (checked or unchecked), or removed. The code looks like:
 
 ```js
-Todos.incompleteCountDenormalizer = {
+const incompleteCountDenormalizer = {
   _updateList(listId) {
     // Recalculate the correct incomplete count direct from MongoDB
     const incompleteCount = Todos.find({
@@ -286,22 +286,22 @@ Todos.incompleteCountDenormalizer = {
 };
 ```
 
-We are then able to wire in the denormalizer into the mutations of the `Todos` collection with code like:
+We are then able to wire in the denormalizer into the mutations of the `Todos` collection like so:
 
 ```js
 class TodosCollection extends Mongo.Collection {
   insert(doc, callback) {
     doc.createdAt = doc.createdAt || new Date();
     const result = super(doc, callback);
-    Todos.incompleteCountDenormalizer.afterInsertTodo(doc);
+    incompleteCountDenormalizer.afterInsertTodo(doc);
     return result;
   }
 }
 ```
 
-Note that we've just built the code we actually use in the application---we don't deal with all conceptual potential ways the todo count on a list could change (for instance, when you update a todo, if you changed the `listId`, it would need to change the `incompleteCount` of *two* lists---however this doesn't actually happen in the application).
+Note that we only handled the mutators we actually use in the application---we don't deal with all possible ways the todo count on a list could change. For example, if you changed the `listId` on a todo item, it would need to change the `incompleteCount` of *two* lists. However, since our application doesn't do this, we don't handle it in the denormalizer.
 
-Dealing with every possible MongoDB operator is difficult to get right, as MongoDB has a rich modifier language. Instead we focus on just dealing with the modifiers we know we'll see in our app. If even this gets too tricky, then moving the hooks for the logic into the Methods that actually make the relevant modifications could be sensible (although you need to be diligent to ensure you do it in *all* the relevant places, both now and as the app changes in the future).
+Dealing with every possible MongoDB operator is difficult to get right, as MongoDB has a rich modifier language. Instead we focus on just dealing with the modifiers we know we'll see in our app. If this gets too tricky, then moving the hooks for the logic into the Methods that actually make the relevant modifications could be sensible (although you need to be diligent to ensure you do it in *all* the relevant places, both now and as the app changes in the future).
 
 It could make sense for packages to exist to completely abstract some common denormalization techniques and actually attempt to deal with all possible modifications. If you write such a package, please let us know!
 
@@ -311,7 +311,7 @@ As we discussed above, trying to predict all future requirements of your data sc
 
 <h3 id="writing-migrations">Writing migrations</h3>
 
-A useful package for writing migrations is [`percolate:migrations`](https://atmospherejs.com/percolate/migrations), which provides a nice framework for switching between different versions of your schema. 
+A useful package for writing migrations is [`percolate:migrations`](https://atmospherejs.com/percolate/migrations), which provides a nice framework for switching between different versions of your schema.
 
 Suppose, as an example, that we wanted to add a `list.todoCount` field, and ensure that it was set for all existing lists. Then we might write the following in server-only code (e.g. `/server/migrations.js`):
 

content/deployment.md

@@ -65,7 +65,7 @@ You want to put your CDN in front of the static assets that Meteor knows about.
 
 If you are following the above approach, you may also want to manually add the CDN's hostname whenever you put an image/other asset URL in your application's code. To do this throughout your app, you can write a generic helper like `imageUrl()`.
 
-<h2 id="deploying">Deploying</h2>
+<h2 id="deployment-options">Deployment options</h2>
 
 There are many options on where to deploy your Meteor application. We'll discuss some of the most popular ones here.
 
@@ -195,7 +195,7 @@ mup deploy
 
 You can also [watch this video](https://www.youtube.com/watch?v=WLGdXtZMmiI) for a more complete walkthrough on how to do it.
 
-<h2 id="process">Deployment Process</h2>
+<h2 id="process">Deployment process</h2>
 
 Although it's much easier to deploy a web application than release most other types of software, that doesn't mean you should be cavalier with your deployment. It's important to properly QA and test your releases before you push them live, to ensure that users don't have a bad experience, or even worse, data get corrupted.
 
@@ -209,7 +209,7 @@ It's a good idea to have a release process that you follow in releasing your app
 
 Steps 2. and 5. can be quite time-consuming, especially if you are aiming to maintain a high level of quality in your application. That's why it's a great idea to develop a suite of acceptance tests (see our [Testing Article](XXX) for more on this). To take things even further, you could run a load/stress test against your staging server on every release.
 
-<h3 id="continuous-deployment">Continuous Deployment</h3>
+<h3 id="continuous-deployment">Continuous seployment</h3>
 
 Continuous deployment refers to the process of deploying an application via a continuous integration tool, usually when some condition is reached (such as a git push to the `master` branch). You can use CD to deploy to Galaxy or Meteor's free hosting, as Nate Strauser explains in a [blog post on the subject](https://medium.com/@natestrauser/migrating-meteor-apps-from-modulus-to-galaxy-with-continuous-deployment-from-codeship-aed2044cabd9#.lvio4sh4a).
 
@@ -269,7 +269,7 @@ To achieve a similar abstraction for subscriptions/publications, you may want to
 
 When you are running an app in production, it's vitally important that you keep tabs on the performance of your application and ensure it is running smoothly.
 
-<h3 id="meteor-performance">Understanding Meteor Performance</h3>
+<h3 id="meteor-performance">Understanding Meteor performance</h3>
 
 Although a host of tools exist to monitor the performance of HTTP, request-response based applications, the insights they give aren't necessarily useful for a connected client system like a Meteor application. Although it's true that slow HTTP response times would be a problem for your app, and so using a tool like [Pingdom](https://www.pingdom.com) can serve a purpose, there are many kinds of issues with your app that won't be surfaced by such tools.