little tweaks

src/Unit-1/lesson1/README.md

@@ -56,6 +56,7 @@ In Unit 1 all of your actors will inherit from [`UntypedActor`](http://getakka.n
 
 ### How do you make an actor?
 There are 2 key things to know about creating an actor:
+
 1. All actors are created within a certain context. That is, they are "actor of" a context.
 1. Actors need `Props` to be created. A `Props` object is just an object that encapsulates the formula for making a given kind of actor.
 

src/Unit-1/lesson2/README.md

@@ -137,15 +137,15 @@ public const string StartCommand = "start";
 
 Update the `Main` method to use `ConsoleReaderActor.StartCommand`:
 
-Replace
+Replace this:
 
 ```csharp
 // in Program.cs
 // tell console reader to begin
 consoleReaderActor.Tell("start");
 ```
 
-with
+with this:
 
 ```csharp
 // in Program.cs

src/Unit-1/lesson3/README.md

@@ -71,7 +71,9 @@ That said, **the best practice is to name your actors**. Why? Because the name o
 #### Are there different types of `ActorRef`s?
 Actually, yes. The most common, by far, is just a plain-old `ActorRef` or handle to an actor, as above.
 
-However, there are also some other `ActorRef`s available to you within the context of an actor. As we said, all actors have a context. That context holds metadata, which includes information  about the current message being processed. That information includes things like the `Parent` or `Children` of the current actor, as well as the `Sender` of the current message. These are all `ActorRef`s that you can use.
+However, there are also some other `ActorRef`s available to you within the context of an actor. As we said, all actors have a context. That context holds metadata, which includes information  about the current message being processed. That information includes things like the `Parent` or `Children` of the current actor, as well as the `Sender` of the current message.
+
+`Parent`, `Children`, and `Sender` all provide `ActorRef`s that you can use.
 
 ### Props
 #### What are `Props`?
@@ -196,8 +198,8 @@ Okay, now we can get to the good stuff! We are going to use what we've learned a
 
 Again, we do not recommend using the `typeof` syntax. For practice, use both of the lambda and generic syntax!
 
-> **Remember**: do NOT try to create `Props` by calling `new Props(...)`. 
-> 
+> **Remember**: do NOT try to create `Props` by calling `new Props(...)`.
+>
 > When you do that, kittens die, unicorns vanish, Mordor wins and all manner of badness happens. Let's just not.
 
 In this section, we're going to split out the `Props` objects onto their own lines for easier reading. In practice, we usually inline them into the call to `ActorOf`.
@@ -294,7 +296,7 @@ You may not have noticed it, but we actually are using a special `ActorRef` now:
 Sender.Tell(new Messages.ContinueProcessing());
 ```
 
-This is the special `Sender` handle that is made available within an actors context when it is processing a message. The `ActorContext` always makes this reference available, along with some other metadata (more on that later).
+This is the special `Sender` handle that is made available within an actors `Context` when it is processing a message. The `Context` always makes this reference available, along with some other metadata (more on that later).
 
 ### Phase 4: A bit of cleanup
 Just a bit of cleanup since we've changed our class structure. Then we can run our app again!
@@ -395,7 +397,7 @@ Since we harped on it earlier, let's illustrate the risk of using the `typeof` `
 
 We've left a little landmine as a demonstration. You should blow it up just to see what happens.
 
-1. Open up [WinTail.sln](Completed/WinTail.sln).
+1. Open up [Completed/WinTail.sln](Completed/WinTail.sln).
 1. Find the lines containing `fakeActorProps` and `fakeActor` (should be around line 18).
 2. Uncomment these lines.
 	- Look at what we're doing here—intentionally substituting a non-actor class into a `Props` object! Ridiculous! Terrible!

src/Unit-1/lesson5/README.md

@@ -92,7 +92,7 @@ But what if, as part of processing a message, you need to send a message to anot
 #### Reporting to multiple endpoints at once
 Another common case is that you may have some piece of information you want to report to multiple other actors, that perhaps each run a stats service. Using `ActorSelection`, you could send the same piece of data as a message to all of those services at once, if they shared a similar well-known naming scheme. This is one good use case for a wildcard `ActorSelection`.
 
-### Caution: Don't pass `ActorSelections` around
+### Caution: Don't pass `ActorSelection`s around
 We encourage you NOT to pass around `ActorSelection`s as pararmeters, the way you do `ActorRef`s. The reason for this is that `ActorSelection`s can be relative instead of absolute, in which case it wouldn't produce the intended effects when passed to an actor with a different location in the hierarchy.
 
 ### How do I make an `ActorSelection`?