 
       config :APP_NAME, hello: :brand_new_world
 
-  It is also possible to configure applications dynamically via `put_env/3`.
+  Keep in mind configuration files are only useful to configure static
+  values. For example, if you need to configure your applications based
+  on the system environment, the file system or on database entries,
+  then those configurations are better placed at runtime. For example,
+  one may configure applications dynamically via `put_env/3`.
 
   Keep in mind that each application is responsible for its environment.
   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
-
-  Often times, an application defines a supervision tree that must be started
-  and stopped when the application starts and stops. For such, we need to
-  define an application module callback. The first step is to define the
-  module callback in the application definition in the `mix.exs` file:
-
-      def application do
-        [mod: {MyApp, []}]
-      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
-
-        def start(_type, _args) do
-          children = []
-          Supervisor.start_link(children, strategy: :one_for_one)
-        end
-      end
-
-  `start/2` typically returns `{:ok, pid}` or `{:ok, pid, state}` where
-  `pid` identifies the supervision tree and `state` is the application state.
-  `args` is the second element of the tuple given to the `:mod` option.
-
-  The `type` argument passed to `start/2` is usually `:normal` unless in a
-  distributed setup where application takeovers and failovers are configured.
-  Distributed applications is beyond the scope of this documentation. For those
-  interested on the topic, please access the OTP documentation:
-
-    * [`:application` module](http://www.erlang.org/doc/man/application.html)
-    * [Applications – OTP Design Principles](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. Note that shutting down the
-  supervisor is automatically handled by the VM.
-
-  An application without a supervision tree doesn't define an application
-  module callback in the application definition in `mix.exs` file. Even though
-  there is no module with application callbacks such as `start/2` and
-  `stop/1`, the application can be started and stopped the same way as an
-  application with a supervision tree.
   """
 
   @doc """

  when tools must be shared between developers and not as deployment options.
  See `mix help archive.build` and `mix help escript.build` for more detail.

  Shutting down a live system cleanly can be done by calling `System.stop/1`.
  It will shut down all applications in the opposite order they are started.
  Each application will then shutdown its top-level supervisor, if one is
  available, which then shuts down its children.

  From Erlang/OTP 19.1, a SIGTERM from the operating system will automatically
  translate to `System.stop/0`. Erlang/OTP 20 gives user more explicit control
  over OS signals via the `:os.set_signal/2` function.

  Applications also provide an "application environment", which is how
  applications are configured. The application environment can either be set
  statically, via a configuration file, or dynamically via `put_env/3` and
  friends.

  Over the next sections, we will cover the "application environment" and
  the "application module callback" in more detail.

  ## Application environment

  Once an application is started, OTP provides an application environment

  shutting down, all applications shut down their top-level supervisor, which
  terminates children in the opposite order they are started.

  Shutting down a live system cleanly can be done by calling `System.stop/1`.
  It will shut down all applications in the opposite order they are started.
  Each application will then shutdown its top-level supervisor, if one is
  available, [which then shuts down its children](Supervisor.html#module-start-and-shutdown).

  From Erlang/OTP 19.1, a SIGTERM from the operating system will automatically
  translate to `System.stop/0`. Erlang/OTP 20 gives user more explicit control
  over OS signals via the `:os.set_signal/2` function.

  ### Application module callback

  An application may start and stop a supervision tree when it boots via
  the application module callback.

  The first step is to pass the module callback in the application definition
  in the `mix.exs` file:

      def application do
        [mod: {MyApp, []}]
      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

        def start(_type, _args) do
          children = []
          Supervisor.start_link(children, strategy: :one_for_one)
        end
      end

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

  The `type` argument passed to `start/2` is usually `:normal` unless in a
  distributed setup where application takeovers and failovers are configured.
  Distributed applications is beyond the scope of this documentation. For those
  interested on the topic, please access the OTP documentation:

    * [`:application` module](http://www.erlang.org/doc/man/application.html)
    * [Applications – OTP Design Principles](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. Note that shutting down the
  supervisor is automatically handled by the VM.

  An application without a supervision tree doesn't define an application
  module callback in the application definition in `mix.exs` file. Even though
  there is no module with application callbacks such as `start/2` and
  `stop/1`, the application can be started and stopped the same way as an
  application with a supervision tree.

  ## Tooling

  The Mix build tool can also be used to start your applications. For example,
  `mix test` automatically starts your application dependencies and your application
  itself before your test runs. `mix run --no-halt` boots your current project and
  can be used to start a long running system. See `mix help run`.

  Developers can also use tools like [Distillery](https://github.com/bitwalker/distillery)
