Fix typos

source/guides/actions/http-caching.md

@@ -4,7 +4,7 @@ title: Lotus - Guides - Action HTTP Caching
 
 # HTTP Caching
 
-We refer to HTTP caching as the set of techiniques for HTTP 1.1 and implemented by browser vendors in order to make faster interactions with the server.
+We refer to HTTP caching as the set of techniques for HTTP 1.1 and implemented by browser vendors in order to make faster interactions with the server.
 There are a few headers that, if sent, will enable these HTTP caching mechanisms.
 
 Because these are advanced features, they must be enabled via `http_caching true` in our application settings (`apps/web/application.rb`).
@@ -102,7 +102,7 @@ end
 The second way is to use a timestamp via `fresh last_modified:`.
 
 If the given timestamp does NOT match `If-Modified-Since` request header, it will return a `200` and set the `Last-Modified` response header with the timestamp value.
-If the timestamp does matche, the action will be halted and a `304` will be returned.
+If the timestamp does match, the action will be halted and a `304` will be returned.
 
 ```ruby
 # apps/web/controllers/users/show.rb

source/guides/actions/parameters.md

@@ -88,7 +88,7 @@ That table has a boolean column `admin` to indicate whether a person has adminis
 
 A malicious user can exploit this scenario by sending this extra parameter to our application, thereby making themselves an administrator.
 
-We can easily fix this problem by filtering the allowed parameterss that are permitted inside our application.
+We can easily fix this problem by filtering the allowed parameters that are permitted inside our application.
 Please always remember that **params represent untrusted input**.
 
 We use `.params` to map the structure of the (nested) parameters.

source/guides/actions/request-and-response.md

@@ -18,7 +18,7 @@ module Web::Controllers::Dashboard
       puts request.request_method # => "GET"
       puts request.get?           # => true
       puts request.post?          # => false
-      puts request.xht?           # => false
+      puts request.xhr?           # => false
       puts request.referer        # => "http://example.com/"
       puts request.user_agent     # => "Mozilla/5.0 Macintosh; ..."
       puts request.ip             # => "127.0.0.1"

source/guides/actions/sessions.md

@@ -29,12 +29,12 @@ The name of the session adapter is the underscored version of the class name und
 Example: <code>:cookie</code> for <code>Rack::Session::Cookie</code>.
 </p>
 
-We can use different a storage compatible with Rack sessions.
+We can use a different storage compatible with Rack sessions.
 Let's say we want to use Redis. We should bundle `redis-rack` and specify the name of the adapter: `:redis`.
 Lotus is able to autoload the adapter and use it when the application is started.
 
 <p class="convention">
-Custom storage technologies are autoloaded via <code>require "rack/session#{ adapter_name }"</code>.
+Custom storage technologies are autoloaded via <code>require "rack/session/#{ adapter_name }"</code>.
 </p>
 
 The second argument passed to `sessions` is a Hash of options that are **passed to the adapter**.

source/guides/actions/testing.md

@@ -217,7 +217,7 @@ Please be careful using doubles in unit tests. Always verify that the mocks are
 
 ## Requests Tests
 
-Unit tests are a great tool to assert that low level interfaces works as expected.
+Unit tests are a great tool to assert that low level interfaces work as expected.
 We always advise combining them with integration tests.
 
 In the case of Lotus web applications, we can write features (aka acceptance tests) with Capybara, but what do we use when we are building HTTP APIs?

source/guides/command-line/database.md

@@ -69,11 +69,11 @@ For instance, if we want to **rollback** the changes from `20150613165900_create
 
 Prepares database for the current environment. This command can't be run in the production environment.
 
-When we run db prepare it:
+When we run `db prepare` it:
 
   * Creates the database
-  * Load SQL dump (if any, see `db apply`)
-  * Run pending migrations
+  * Loads SQL dump (if any, see `db apply`)
+  * Runs pending migrations
 
 ```shell
 % bundle exec lotus db prepare

source/guides/helpers/html5.md

@@ -4,7 +4,7 @@ title: Lotus - Guides - HTML5 Helpers
 
 ## HTML5 Helpers
 
-This helper makes available an HTML5 generator that is **template engine indepentent**.
+This helper makes available an HTML5 generator that is **template engine independent**.
 It's a **private method for views and layouts** called `#html`.
 
 ## Usage

source/guides/helpers/links.md

@@ -10,7 +10,7 @@ It's a **public method** called `#link_to`, that can be used both in **views** a
 ## Usage
 
 It accepts two mandatory and one optional arguments.
-The first is the content of the tag, the second is the path, an the third is a Hash that represent a set of HTML attributes that we may want to specify.
+The first is the content of the tag, the second is the path, an the third is a Hash that represents a set of HTML attributes that we may want to specify.
 
 ```erb
 <%= link_to 'Home', '/' %>

source/guides/mailers/basic-usage.md

@@ -9,7 +9,7 @@ In the [previous section](/guides/mailers/overview), we generated a mailer, let'
 ## Informations
 
 Firstly, we need to specify sender and recipient(s) and the subject of the email.
-For this purpose a mailer expose three methods: `.from`, `.to` and `.subject`.
+For this purpose a mailer exposes three methods: `.from`, `.to` and `.subject`.
 
 They all accept a string, but `.to` can also accept an array of strings in order to set multiple recipients.
 
@@ -33,7 +33,7 @@ end
 
 You may have noticed that have a hardcoded value can be useful to set the sender, but it doesn't work well for the rest of the details.
 
-If pass a **symbol as argument**, it will interpreted as a **method** that we want to use for that information.
+If pass a **symbol as argument**, it will be interpreted as a **method** that we want to use for that information.
 
 
 ```ruby

source/guides/mailers/delivery.md

@@ -7,7 +7,7 @@ title: Lotus - Guides - Mailers Delivery
 ## Multipart Delivery
 
 By default a mailer delivers a multipart email, that has a HTML and a text part.
-This is the reason why the generators creates two templates.
+This is the reason why the generator creates two templates.
 
 To render both the templates and deliver them as a multipart message, we simply do:
 
@@ -28,13 +28,13 @@ Mailers::Welcome.deliver(format: :html)
 Mailers::Welcome.deliver(format: :txt)
 ```
 
-By using only one format, it will render and delivery only the specified template.
+By using only one format, it will render and deliver only the specified template.
 
 ## Remove Templates
 
-If in our application, we want only to delivery HTML templates, we can **safely** remove textual templates (`.txt` extension) and every time we will do `Mailers::Welcome.deliver` it will only send the HTML message.
+If in our application, we want only to deliver HTML templates, we can **safely** remove textual templates (`.txt` extension) and every time we will do `Mailers::Welcome.deliver` it will only send the HTML message.
 
-The same priciple applies if we want only to send textual emails, just remove HTML templates (`.html` extension).
+The same principle applies if we want only to send textual emails, just remove HTML templates (`.html` extension).
 
 <p class="warning">
   At the delivery time, a mailer MUST have at least one template available.

source/guides/mailers/share-code.md

@@ -11,7 +11,7 @@ When a mailer includes the `Lotus::Mailer` module, that block code is yielded wi
 This is heavily inspired by Ruby Module and its `included` hook.
 
 Imagine we want to set a default sender for all the mailers.
-Instead of specify it for each mailer, we can use a DRY approach.
+Instead of specifying it for each mailer, we can use a DRY approach.
 
 We create a module:
 

source/guides/migrations/alter-table.md

@@ -23,7 +23,7 @@ The following methods are available for table alterations:
   * `#set_column_allow_null` (accepts the **name** of the column)
   * `#set_column_not_null` (accepts the **name** of the column)
 
-Those methods accepts the **name of the target table as first argument**, then the other args.
+Those methods accept the **name of the target table as first argument**, then the other args.
 There is a convenient shortcut for this: `#alter_table`. It accepts the **name of the table** and a **block** that describes the alterations.
 
 The following syntaxes are **equivalent**.

source/guides/migrations/create-table.md

@@ -17,7 +17,7 @@ Force operation can be performed via `#create_table!`. It drops the existing tab
 To define a column we use `#column`, followed by the **name**, the **type** and **options**.
 The name must be a unique identifier within the table.
 
-The type can be a Ruby type (e.g. `String`), a symbol that represent a Ruby type (e.g. `:string`)  , or a string that represents the raw database type (e.g. `"varchar(255)"`).
+The type can be a Ruby type (e.g. `String`), a symbol that represents a Ruby type (e.g. `:string`)  , or a string that represents the raw database type (e.g. `"varchar(255)"`).
 
 ##### Type Definition
 
@@ -95,7 +95,7 @@ create_table :stores do
   column :code, Integer, null: false
   column :lat, Float
   column :lng, Float
-  
+
   index :code, unique: true
   index [:lat, :lng], name: :stores_coords_index
 end
@@ -136,14 +136,14 @@ end
 
 #### Checks
 
-Checks are similar to constraints, but they accept an **anoymous block** or a **SQL raw string**.
+Checks are similar to constraints, but they accept an **anonymous block** or a **SQL raw string**.
 
 ```ruby
 create_table :users do
   # ...
   column :age, Integer
   column :role, String
-  
+
   check { age > 18 }
   check %(role IN("contributor", "manager", "owner"))
 end

source/guides/migrations/overview.md

@@ -40,9 +40,9 @@ The first argument is the name of the local column (`books.author_id`), while th
 
 Then we have three lines for columns.
 The first argument that we pass to `#column` is the name, then the type.
-The type can be a **Ruby type** such as `String` or `Integer` or a string that represent the **native database type** (eg. `"varchar(32)"` or `"text[]"`).
+The type can be a **Ruby type** such as `String` or `Integer` or a string that represents the **native database type** (eg. `"varchar(32)"` or `"text[]"`).
 
-As a last optional argument there is a Hash that specify some extra details for the column. For instance NULL or uniqueness constraints, the size (for strings) or the default value.
+As a last optional argument there is a Hash that specifies some extra details for the column. For instance NULL or uniqueness constraints, the size (for strings) or the default value.
 
 The final line defines a database **check** to ensure that price will always be greater than zero.
 

source/guides/models/overview.md

@@ -5,7 +5,7 @@ title: Lotus - Guides - Models Overview
 # Models
 
 Lotus' model domain is implemented in a way that separates the behavior that we want to express (entities) from that persistence layer (repositories and database).
-This design helps to keep the inteface of our objects really small and, by consequence, fast and reusable.
+This design helps to keep the interface of our objects really small and, by consequence, fast and reusable.
 
 ## Soft Dependency
 

source/guides/routing/basic-usage.md

@@ -70,7 +70,7 @@ get '/files/*', to: 'files#show'
 
 ## Named Routes
 
-We can specify a unique name for each route, in order to generates paths from the router or to test them.
+We can specify a unique name for each route, in order to generate paths from the router or to test them.
 
 ```ruby
 get '/hello',     to: 'greet#index', as: :greeting

source/guides/views/basic-usage.md

@@ -48,7 +48,7 @@ module Web::Views::Dashboard
 end
 ```
 
-The view now respond to `#title` by implementing it as a concrete method.
+The view now responds to `#title` by implementing it as a concrete method.
 We still see `<h1>Dashboard</h1>` when we visit `/dashboard`.
 
 ### Exposures

source/guides/views/custom-error-pages.md

@@ -7,7 +7,7 @@ title: Lotus - Guides - Custom Error Pages
 When a non successful request is returned, there are some special pages that an application presents to users.
 They have a generic graphic and some basic informations like the HTTP status code and the message.
 
-Lotus allow to customize them on an application basis.
+Lotus allows to customize them on an application basis.
 We need to create a template with the corresponding HTTP code as filename (eg. `apps/web/templates/500.html.erb`).
 
 Since now on, all the side errors will be presented using that template.

source/guides/views/layouts.md

@@ -49,7 +49,7 @@ end
 ```
 
 <p class="convention">
-Lotus transform layout name in application's configuration, by appending the <code>Layout</code> suffix. Eg. <code>:application</code> for <code>Web::Views::ApplicationLayout</code>.
+Lotus transforms layout name in application's configuration, by appending the <code>Layout</code> suffix. Eg. <code>:application</code> for <code>Web::Views::ApplicationLayout</code>.
 </p>
 
 If we want to disable a layout for a view, we can use a DSL for that.
@@ -111,4 +111,4 @@ end
 ```
 
 The first view doesn't respond to `#javascripts`, so it safely ignores it.
-Our second object (`Web::Views::Books::Show`) respond to that method, so the result will be included in the final markup.
+Our second object (`Web::Views::Books::Show`) responds to that method, so the result will be included in the final markup.

source/guides/views/mime-types.md

@@ -4,7 +4,7 @@ title: Lotus - Guides - MIME Types
 
 # MIME Types
 
-A view can handle several MIME Types. Before to dive into this subject, please consider to read how action handle [MIME Types](/guides/actions/mime-types).
+A view can handle several MIME Types. Before to dive into this subject, please consider to read how actions handle [MIME Types](/guides/actions/mime-types).
 
 It's important to highlight the correlation between the _format_ and template name.
 For a given MIME Type, Rack (and then Lotus) associate a _format_ for it.
@@ -52,7 +52,7 @@ Lotus::View::MissingTemplateError: Can't find template "dashboard/index" for "xm
 This scenario works well if the presentational logic of a view can be applied for all the format templates that it handles.
 What if we want to have a [custom rendering](/guides/views/basic-usage) or different presentational logic?
 
-We can inherit from our view and declare that our subclass only handle a specific format.
+We can inherit from our view and declare that our subclass only handles a specific format.
 
 ```ruby
 # apps/web/views/dashboard/json_index.rb
@@ -75,4 +75,4 @@ JSON requests for `/dashboard`, will be handled by our `JsonIndex`.
 There is NO convention between the handled format and the class name. The important part is <code>format :json</code>.
 </p>
 
-With the example above we took advantadge of custom rendering to not use the template and let our serializer to return JSON for us.
+With the example above we took advantage of custom rendering to not use the template and let our serializer to return JSON for us.

source/guides/views/share-code.md

@@ -6,7 +6,7 @@ title: Lotus - Guides - View Share Code
 
 ## Prepare
 
-In our settings (`apps/web/application.rb`), there is code block that allows to share the code for **all the views** of our application.
+In our settings (`apps/web/application.rb`), there is a code block that allows to share the code for **all the views** of our application.
 When a view includes the `Web::View` module, that block code is yielded within the context of that class.
 This is heavily inspired by Ruby Module and its `included` hook.