corrections in the guide

Author: eksperimental

_posts/2014-08-07-elixir-v0-15-0-released.markdown

@@ -16,7 +16,7 @@ If you are interested in the specific details for this release, [please check ou
 
 ## Logger
 
-Elixir now ships with a new application called logger. This application provides [the Logger module](/docs/master/logger/Logger.html), which is the main API developers will use for logging:
+Elixir now ships with a new application called logger. This application provides [the Logger module](/docs/stable/logger/Logger.html), which is the main API developers will use for logging:
 
 ```elixir
 require Logger
@@ -70,7 +70,7 @@ Function: #Function<20.90072148/0 in :erl_eval.expr/5>
 As soon as we started working on Logger, we realized we could go further than simply translating Erlang messages and provide a fully featured logger library. At this moment, Logger also supports:
 
   * 4 log levels: debug, info, warn and error
-  * Custom formatting: you can specify a format string that tells exactly how messages should be logged. The default string is: "$time $metadata[$level] $message\n" but [many attributes are supported](/docs/master/logger/Logger.Formatter.html)
+  * Custom formatting: you can specify a format string that tells exactly how messages should be logged. The default string is: "$time $metadata[$level] $message\n" but [many attributes are supported](/docs/stable/logger/Logger.Formatter.html)
   * Custom translators: so you can translate log messages coming from any Erlang application into Elixir syntax
   * Metadata: metadata allows developers to store information in the current process that will be available to all logged messages. For example, a web application can generate a `request_id`, store it as metadata, and all messages logged during that request will be properly identified with `request_id=...` in the log
 
@@ -136,7 +136,7 @@ In other words, aliases can be three different structures:
   2. An anonymous function (that is invoked passing the task arguments)
   3. A list containing strings or anonymous functions
 
-You can find more information about aliases by reading the [Mix documentation](/docs/master/mix/) (there is a section about Aliases around the middle).
+You can find more information about aliases by reading the [Mix documentation](/docs/stable/mix/) (there is a section about Aliases around the middle).
 
 We also would like to thank [Anthony Grimes](https://github.com/raynes) for the support and [Phil Halgelberg](https://github.com/technomancy) for [the work on Lein](https://github.com/technomancy/leiningen) which Mix borrows a lot from.
 

getting-started/mix-otp/genevent.markdown

@@ -62,7 +62,7 @@ There are a couple things that are important to highlight at this point:
 2. `sync_notify/2` runs event handlers synchronously to the request
 3. `notify/2` runs event handlers asynchronously
 
-Therefore, `sync_notify/2` and `notify/2` are similar to `call/2` and `cast/2` in GenServer and using `sync_notify/2` is generally recommended. It works as a backpressure mechanism in the calling process, to reduce the likelihood of messages being sent more quickly than they can be dispatched to handlers.
+Therefore, `sync_notify/2` and `notify/2` are analogous to `call/2` and `cast/2` in GenServer and using `sync_notify/2` is generally recommended. It works as a backpressure mechanism in the calling process, to reduce the likelihood of messages being sent more quickly than they can be dispatched to handlers.
 
 Be sure to check other functionality provided by GenEvent in its [module documentation](/docs/stable/elixir/GenEvent.html). For now we have enough knowledge to add an event manager to our application.
 
@@ -100,7 +100,7 @@ test "sends events on create and crash", %{registry: registry} do
 end
 ```
 
-In order to test the functionality we want to add, we first define a `Forwarder` event handler similar to the one we typed in IEx previously. On `setup`, we start the event manager, pass it as an argument to the registry and add our `Forwarder` handler to the manager so events can be sent to the test process.
+In order to test the functionality we want to add, we first define a `Forwarder` (the same one we typed in IEx previously). On `setup`, we start the event manager, pass it as an argument to the registry and add our `Forwarder` handler to the manager so events can be sent to the test process.
 
 In the test, we create and stop a bucket process and use `assert_receive` to assert we will receive both `:create` and `:exit` messages. `assert_receive` has a default timeout of 500ms which should be more than enough for our tests. Also note that `assert_receive` expects a pattern, rather than a value, that's why we have used `^bucket` to match on the bucket pid.