Stripped whitespace

QUICKLINKS

@@ -1,12 +1,11 @@
 = Quick Links
 
 * Setup and Configuration - DataMapper
-* Finders and CRUD - 
+* Finders and CRUD -
 * Properties - DataMapper::Property
 * FAQ[link:/files/FAQ.html]
 * Contact Us
   * Website - http://www.datamapper.org
   * Bug Reports - http://wm.lighthouseapp.com/projects/4819-datamapper/overview
   * IRC Channel - <tt>##datamapper</tt> on irc.freenode.net
   * Mailing List - http://groups.google.com/group/datamapper/
-

SPECS

@@ -2,14 +2,14 @@ Reading Specs
 =============
 
   Blah blah blah...
-  
+
 Writing Specs
 =============
 
   Here are some general dos and don'ts
-  
+
   = DO:
-  
+
   * Write more specs for error conditions than clean conditions.
   * Write specs with readability in mind. Somebody knew to DataMapper should be
     able to read specs to learn how something works.
@@ -18,14 +18,14 @@ Writing Specs
   * Limit a describe block to 10 - 15 examples.
   * Group specs by method being tested. (See the 'Ordering Specs' section)
   * Use custom matchers.
-  
+
   = DON'T:
-  
+
   * Spec more than one unit of functionality in an example. An example should be
     as short as possible (while still remaining readable).
   * Spec implementation. Refactoring code should not break specs.
   * Declare models in the spec file.
-  
+
   And a final do: Do go against the guidelines if your best judgement tells you
   to. These are just guidelines and are obviously not fast rules.
 
@@ -39,7 +39,7 @@ Models
   few simple metaphors, such as a zoo, a blog implementation, etc... Following
   metaphors makes it easier for a reader to guess what is going on with respect
   to the models.
-  
+
   The second reason is to allow the spec environment to be as pristine as
   possible going into an example. Models being loaded from the model directory
   are tracked and reloaded before each example. Any changes that might be made
@@ -51,13 +51,12 @@ Mocks and Stubs
   Obviously, mocks and stubs are a powerful feature when it comes to BDD;
   however, remember that you are writing specs for behavior and NOT
   implementation.
-  
+
 Ordering Specs
 ==============
 
   Specs aren't much use if nobody can find where anything is, so keeping specs
   well organized is critical. Currently, we are trying out the following
   structure:
-  
+
     * List guidelines here...
-