Merge pull request #2 from lex111/various-improvements

Various improvements

Author: madeindjs

en/chapter01-introduction.adoc

@@ -74,8 +74,8 @@ $ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/inst
 
 We will be using Git a lot, and you should use it too not just for the purpose of this tutorial but for every single project.
 
-* sous Mac OS: `$ brew install git`
-* sous Linux: `$ sudo apt-get install git`
+* on Mac OS: `$ brew install git`
+* on Linux: `$ sudo apt-get install git`
 
 === Ruby
 
@@ -350,15 +350,15 @@ The next step is to ignore some files that we don’t want to track, so your `.g
 /config/master.key
 ----
 
-After modifiying the `.gitignore` file we just need to add the files and commit the changes, the commands necessary are shown below:
+After modifying the `.gitignore` file we just need to add the files and commit the changes, the commands necessary are shown below:
 
 [source,bash]
 ----
 $ git add .
 $ git commit -m "Initial commit"
 ----
 
-TIP: I have encounter that commiting with a message starting with a present tense verb, describes what the commit does and not what it did, this way when you are exploring the history of the project it is more natural to read and understand(or at least for me). I’ll follow this practice until the end of the tutorial.
+TIP: I have encounter that committing with a message starting with a present tense verb, describes what the commit does and not what it did, this way when you are exploring the history of the project it is more natural to read and understand(or at least for me). I’ll follow this practice until the end of the tutorial.
 
 Lastly and as an optional step we setup the GitHub (I’m not going through that in here) project and push our code to the remote server: We first add the remote:
 

en/chapter02-api.adoc

@@ -162,7 +162,7 @@ Time to commit:
 [source,bash]
 ----
 $ git add config/routes.rb
-$ git commit -m "Set the routes contraints for the api"
+$ git commit -m "Set the routes constraints for the api"
 ----
 
 All right take a deep breath, drink some water, and let’s get going.

en/chapter03-presenting-users.adoc

@@ -594,7 +594,7 @@ RSpec.describe Api::V1::UsersController, type: :controller do
        expect(user_response).to have_key(:errors)
      end
 
-     it "renders the json errors on whye the user could not be created" do
+     it "renders the json errors on why the user could not be created" do
        user_response = JSON.parse(response.body, symbolize_names: true)
        expect(user_response[:errors][:email]).to include "is invalid"
      end

en/chapter04-refactoring-tests.adoc

@@ -105,7 +105,7 @@ RSpec.describe Api::V1::UsersController, type: :controller do
        expect(user_response).to have_key(:errors)
      end
 
-     it "renders the json errors on whye the user could not be created" do
+     it "renders the json errors on why the user could not be created" do
        user_response = JSON.parse(response.body, symbolize_names: true)
        expect(user_response[:errors][:email]).to include "is invalid"
      end

en/chapter05-athentification.adoc

@@ -19,7 +19,7 @@ First things first (and as usual when starting a new chapter) we will create a n
 $ git checkout -b chapter5
 ----
 
-== Session sans état
+== Stateless session
 
 Before we go any further, something must be clear: *an API does not handle sessions*. If you don’t have experience building these kind of applications it might sound a little crazy but stay with me. An API should be stateless which means by definition _is one that provides a response after your request, and then requires no further attention._. Which means no previous or future state is required for the system to work.
 

en/chapter06-user-products.adoc

@@ -530,7 +530,7 @@ RSpec.describe Api::V1::ProductsController, type: :controller do
         expect(product_response).to have_key(:errors)
       end
 
-      it 'renders the json errors on whye the user could not be created' do
+      it 'renders the json errors on why the user could not be created' do
         product_response = json_response
         expect(product_response[:errors][:price]).to include 'is not a number'
       end
@@ -671,7 +671,7 @@ RSpec.describe Api::V1::ProductsController, type: :controller do
         expect(product_response).to have_key(:errors)
       end
 
-      it 'renders the json errors on whye the user could not be created' do
+      it 'renders the json errors on why the user could not be created' do
         product_response = json_response
         expect(product_response[:errors][:price]).to include 'is not a number'
       end
@@ -875,6 +875,6 @@ $ git commit -m "Updates test environment factory gems to work on development"
 
 == Conclusion
 
-On the next chapter we will focus on customizing the output from the `user` and `product` models using the active model serializers gem. It will help us to easily filter attributes to display (or handle associations as embebed objects for example).
+On the next chapter we will focus on customizing the output from the `user` and `product` models using the active model serializers gem. It will help us to easily filter attributes to display (or handle associations as embedded objects for example).
 
 I hope you have enjoyed this chapter. It is a long one but the code we put together is an excellent base for the core app.

en/chapter07-improve-json.adoc

@@ -247,7 +247,7 @@ So we’ll be embedding the user object into the product. Let’s start by addin
 RSpec.describe Api::V1::ProductsController, type: :controller do
   describe 'GET #show' do
     # ...
-    it 'has the user as a embeded object' do
+    it 'has the user as a embedded object' do
       expect(json_response[:user][:email]).to eql @product.user.email
     end
   end
@@ -301,7 +301,7 @@ First we make sure the `product_ids` it is part of the user serialized object:
 RSpec.describe Api::V1::UsersController, type: :controller do
   describe 'GET #show' do
     # ...
-    it 'has the product ids as an embeded object' do
+    it 'has the product ids as an embedded object' do
       expect(json_response[:product_ids]).to eql []
     end
   end

en/chapter08-placing-orders.adoc

@@ -975,7 +975,7 @@ Finished in 1.82 seconds (files took 0.78532 seconds to load)
 98 examples, 0 failures
 ----
 
-Let’s finish this section by commiting this:
+Let’s finish this section by committing this:
 
 [source,bash]
 ----

en/chapter09-improve-orders.adoc

@@ -125,7 +125,7 @@ Finished in 0.33759 seconds (files took 3.54 seconds to load)
 8 examples, 0 failures
 ----
 
-The `build_placements_with_product_ids_and_quantities` will build the placement objects and once we trigger the `save` method for the order everything will be inserted into the database. One last step before commiting this is to update the `orders_controller_spec` along with its implementation.
+The `build_placements_with_product_ids_and_quantities` will build the placement objects and once we trigger the `save` method for the order everything will be inserted into the database. One last step before committing this is to update the `orders_controller_spec` along with its implementation.
 
 First we update the `orders_controller_spec` file:
 

en/chapter10-optimization.adoc

@@ -29,13 +29,13 @@ As I have been telling you since the beginning of this book, an important and di
 
 One of the most applied conventions is most certainly https://jsonapi.org/[JSON:API]. This convention will allow us to approach pagination more serenely in the next section.
 
-So https://jsonapi.org/format/#document-structure[documentation de JSON:API] gives us some rules to follow concerning JSON presentation.
+So https://jsonapi.org/format/#document-structure[documentation JSON:API] gives us some rules to follow concerning JSON presentation.
 
 So our *document* must follow theses rules:
 
 * `data`: which must contains the data we send back
 * `errors` which must contains a table of errors that have occurred
-* `meta` which contains https://jsonapi.org/format/#document-meta[objet meta]
+* `meta` which contains https://jsonapi.org/format/#document-meta[object meta]
 
 NOTE: The `data` and `errors` keys must not be present at the same time and this makes sense since if an error occurs we should not be able to make data correct.
 
@@ -62,7 +62,7 @@ RSpec.describe Api::V1::UsersController, type: :controller do
       expect(json_response[:email]).to eql @user.email
     end
 
-    it 'has the product ids as an embeded object' do
+    it 'has the product ids as an embedded object' do
       expect(json_response[:product_ids]).to eql []
     end
   end
@@ -83,7 +83,7 @@ RSpec.describe Api::V1::UsersController, type: :controller do
       expect(json_response[:data][:attributes][:email]).to eql @user.email
     end
 
-    it 'has the product ids as an embeded object' do
+    it 'has the product ids as an embedded object' do
       expect(json_response[:data][:attributes][:'product-ids']).to eql []
     end
   end
@@ -154,7 +154,7 @@ RSpec.describe Api::V1::ProductsController, type: :controller do
       expect(json_response[:data][:attributes][:title]).to eql @product.title
     end
 
-    it 'has the user as a embeded object' do
+    it 'has the user as a embedded object' do
       puts json_response.inspect
       expect(json_response[:data][:relationships][:user][:attributes][:email]).to eql @product.user.email
     end
@@ -228,7 +228,7 @@ RSpec.describe Api::V1::ProductsController, type: :controller do
       expect(json_response[:data][:attributes][:title]).to eql @product.title
     end
 
-    it 'has the user as a embeded object' do
+    it 'has the user as a embedded object' do
       expect(json_response[:data][:relationships][:user][:attributes][:email]).to eql @product.user.email
     end
   end
@@ -270,7 +270,7 @@ RSpec.describe Api::V1::ProductsController, type: :controller do
 
     context 'when is not created' do
       # ...
-      it 'renders the json errors on whye the user could not be created' do
+      it 'renders the json errors on why the user could not be created' do
         product_response = json_response
         expect(product_response[:errors][:price]).to include 'is not a number'
       end
@@ -344,7 +344,7 @@ $ rspec spec
 
 Failures:
 
-  1) Api::V1::ProductsController GET #show has the user as a embeded object
+  1) Api::V1::ProductsController GET #show has the user as a embedded object
      Failure/Error: expect(json_response[:data][:relationships][:user][:attributes][:email]).to eql @product.user.email
      ...
 
@@ -371,7 +371,7 @@ So let’s update our test:
 RSpec.describe Api::V1::ProductsController, type: :controller do
   describe 'GET #show' do
     # ...
-    it 'has the user as a embeded object' do
+    it 'has the user as a embedded object' do
       expect(json_response[:included].first[:attributes][:email]).to eql @product.user.email
     end
   end