README.md in permisi-0.1.2 vs README.md in permisi-0.1.3

@@ -1,6 +1,6 @@
-If you're viewing this at https://github.com/ukazap/permisi, you're reading the documentation for the main branch. [Go to specific version.](https://github.com/ukazap/permisi/tags)
+If you're viewing this at https://github.com/ukazap/permisi, you're reading the documentation for the main branch. [Go to specific version.](https://github.com/ukazap/permisi/blob/main/CHANGELOG.md)
 
 <table>
   <tr>
     <th>
       <a href="https://commons.wikimedia.org/wiki/File:Female_Chinese_Lion_Statue.jpg">
@@ -140,16 +140,16 @@
     edit: true
   }
 })
 
 # Ask specific role permission
-admin_role.allows? "books.delete" # == false
+admin_role.allows?("books.delete") # == false
 
 # Update existing role
-admin.permissions[:books].merge!({ delete: true })
-admin.save
-admin_role.allows? "books.delete" # == true
+admin_role.permissions[:books].merge!({ delete: true })
+admin_role.save
+admin_role.allows?("books.delete") # == true
 ```
 
 ## Configuring actors
 
 You can then give or take multiple roles to an actor which will allow or prevent them to perform certain actions in a flexible manner. But before you can do that, you have to wire up your user model with Permisi using via `Permisi::Actable` mixin.
@@ -171,24 +171,24 @@
 ```ruby
 user = User.find_by_email "[e-mail]"
 user.permisi # => instance of Actor
 
 admin_role = Permisi.roles.find_by_slug(:admin)
-admin_role.allows? "books.delete" # == true
+admin_role.allows?("books.delete") # == true
 
 user.permisi.roles << admin_role
 
-user.permisi.role? :admin # == true
-user.permisi.has_role? :admin # == user.permisi.role? :admin
+user.permisi.role?(:admin) # == true
+user.permisi.has_role?(:admin) # == user.permisi.role? :admin
 
-user.permisi.may_i? "books.delete" # == true
-user.permisi.may? "books.delete" # == user.permisi.may_i? "books.delete"
+user.permisi.may_i?("books.delete") # == true
+user.permisi.may?("books.delete") # == user.permisi.may_i? "books.delete"
 
 user.permisi.roles.destroy(admin_role)
 
-user.permisi.role? :admin # == false
-user.permisi.may_i? "books.delete" # == false
+user.permisi.role?(:admin) # == false
+user.permisi.may_i?("books.delete") # == false
 ```
 
 ## Caching
 
 Permisi has several optimizations out of the box: actor roles eager loading, actor permissions memoization, and the optional actor permissions caching.
@@ -197,28 +197,28 @@
 
 Although checking whether an actor has a role goes against a good RBAC practice, it is still possible on Permisi. Calling `role?` multiple times will only make one call to the database:
 
 ```ruby
 user = User.find_by_email "[e-mail]"
-user.role? :admin # eager loads roles
-user.role? :admin # uses the eager-loaded roles
-user.has_role? :admin # uses the eager-loaded roles
+user.permisi.role?(:admin) # eager loads roles
+user.permisi.role?(:admin) # uses the eager-loaded roles
+user.permisi.has_role?(:admin) # uses the eager-loaded roles
 ```
 
 ### Actor permissions memoization
 
 To check whether or not an actor is allowed to perform a specific action (`#may_i?`), Permisi will check on the actor's permissions which is constructed in the following steps:
 
-- get all roles an actor have (this will make a database call)
+- load all the roles an actor have from the database
 - initialize an empty aggregate hash
-- for each roles, merge its permissions hash to the aggregate hash
+- for each role, merge its permissions hash to the aggregate hash
 
 Deserializing the hashes from the database and deeply-merging them into an aggregate hash can be expensive, so it will only happen to an instance of actor only once through memoization.
 
 ### Actor permissions caching
 
-Although memoization helps, the permission hash construction will still occur everytime a actor is initialized. To alleviate this, we can introduce a caching layer so that we can skip the hash construction for fresh actors. You must configure a cache store to use caching:
+Although memoization helps, the permission hash construction will still occur every time an actor is initialized. To alleviate this, we can introduce a caching layer so that we can skip the hash construction for fresh actors. You must configure a cache store to use caching:
 
 ```ruby
 # config/initializers/permisi.rb
 
 Permisi.init do |config|
@@ -237,10 +237,10 @@
 
 The following will trigger actor's permissions cache/memo invalidation:
 
 - adding roles to the actor
 - removing roles from the actor
-- editing roles that belongs to an actor
+- editing roles that belongs to the actor
 
 ## Contributing
 
 For development and how to submit improvements, please refer to the [contribution guide](https://github.com/ukazap/permisi/blob/main/CONTRIBUTING.md).