 
   It is also possible to put and delete values from the application value,
   including new values that are not defined in the environment file (although
-  those should be avoided).
-
-  In the future, we plan to support configuration files which allows
+  this should be avoided).
+
+  In the future, we plan to support configuration files which allow
   developers to configure the environment of their dependencies.
 
   Keep in mind that each application is responsible for its environment.
-  Do not use the functions in this module for directly access or modify
-  the environment of other application (as it may lead to inconsistent
+  Do not use the functions in this module for directly accessing or modifying
+  the environment of other applications (as it may lead to inconsistent
   data in the application environment).
 
   ## Application module callback

        end
      end

  `start/2` most commonly returns `{:ok, pid}` or `{:ok, pid, state}` where
  `pid` identifies the supervision tree and the state is the application state.
  `args` is second element of the tuple given to the `:mod` option.

  The `type` passed into `start/2` is usually `:normal` unless in a distributed
  setup where applications takeovers and failovers are configured. This particular
  aspect of applications can be read with more detail in the OTP documentation:

    * http://www.erlang.org/doc/man/application.html
    * http://www.erlang.org/doc/design_principles/applications.html

  A developer may also implement the `stop/1` callback (automatically defined
  by `use Application`) which does any application cleanup. It receives the
  application state and can return any value. Notice that shutting down the
  supervisor is automatically handled by the VM.
  """


      end

  Our application now requires the `MyApp` module to provide an application
  callback. This can be done by invoking `use Application` in that module and
  defining a `start/2` callback, for example:

      defmodule MyApp do
        use Application
