diff --git a/docs/scenarios/ci.rst b/docs/scenarios/ci.rst
index 43b4220..aa8d196 100644
--- a/docs/scenarios/ci.rst
+++ b/docs/scenarios/ci.rst
@@ -31,17 +31,6 @@ Buildbot
 automate the compile/test cycle to validate code changes.
 
 
-Mule
------
-
-`Mule <http://www.mulesoft.org/documentation/display/current/Mule+Fundamentals>`_
-is a lightweight integration platform that enables you to connect anything,
-anywhere. You can use Mule to intelligently manage message routing, data
-mapping, orchestration, reliability, security and scalability between nodes.
-Plug other systems and applications into Mule and let it handle all the
-communication between systems, enabling you to track and monitor everything
-that happens.
-
 
 Tox
 ---
diff --git a/docs/scenarios/web.rst b/docs/scenarios/web.rst
index 19cddec..9dd3928 100644
--- a/docs/scenarios/web.rst
+++ b/docs/scenarios/web.rst
@@ -102,9 +102,9 @@ I do not recommend using Tornado unless you think you need it.
 Pyramid
 --------
 
-`Pyramid <http://www.pylonsproject.org/>`_ is a lot like Django, except
-with a heavier focus on modularity. It comes with a smaller number of
-libraries ("batteries") built-in, and encourages users to extend its
+`Pyramid <http://www.pylonsproject.org/>`_ is a very flexible
+framework with a heavy focus on modularity. It comes with a small number
+of libraries ("batteries") built-in, and encourages users to extend its
 base functionality.
 
 Pyramid does not have a large user base, unlike Django and Flask. It's a
diff --git a/docs/starting/install/osx.rst b/docs/starting/install/osx.rst
index 549b806..ae3f10a 100644
--- a/docs/starting/install/osx.rst
+++ b/docs/starting/install/osx.rst
@@ -48,7 +48,7 @@ your favorite OSX terminal emulator and run
 
 .. code-block:: console
 
-    $ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
+    $ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
 
 The script will explain what changes it will make and prompt you before the
 installation begins.
diff --git a/docs/writing/structure.rst b/docs/writing/structure.rst
index 7cde9da..6448dba 100644
--- a/docs/writing/structure.rst
+++ b/docs/writing/structure.rst
@@ -658,8 +658,10 @@ And now the generator approach using Python's own
     @contextmanager
     def custom_open(filename):
         f = open(filename)
-        yield f
-        f.close()
+        try:
+            yield f
+        finally:
+            f.close()
 
     with custom_open('file') as f:
         contents = f.read()
@@ -667,7 +669,9 @@ And now the generator approach using Python's own
 This works in exactly the same way as the class example above, albeit it's
 more terse. The ``custom_open`` function executes until it reaches the ``yield``
 statement. It then gives control back to the ``with`` statement, which assigns
-whatever was ``yield``'ed to `f` in the ``as f`` portion.
+whatever was ``yield``'ed to `f` in the ``as f`` portion. The ``finally`` clause
+ensures that ``close()`` is called whether or not there was an exception inside
+the ``with``.
 
 Since the two approaches appear the same, we should follow the Zen of Python
 to decide when to use which. The class approach might be better if there's
diff --git a/docs/writing/tests.rst b/docs/writing/tests.rst
index f014bfd..84e5d27 100644
--- a/docs/writing/tests.rst
+++ b/docs/writing/tests.rst
@@ -116,7 +116,7 @@ A simple doctest in a function:
 .. code-block:: python
 
     def square(x):
-        """Squares x.
+        """Return the square of x.
 
         >>> square(2)
         4