I took this from a recent newsletter I read. Sometimes replication
performance issues locally is actually slower than production due to dev
mode settings (code reloading, etc.), heavy de-only gems and the asset
pipeline.
The PROFILE env var switches these settings all at the same time,
giving us an environment closer to production, essential for reliable
profiling. Then, rack-mini-profiler is going to be more accurate.
Apparently it's something
[RubyGems](b026df86ae/config/environments/development.rb (L72-L92))
and
[CodeTriage](a3c957647d)
both use.
I don't know why but `Rails.logger` is still nil when evaluated from
`configure` block in `config/environments/development.rb`. The only way
I found to make ActiveSupport's cache to use the default logger is from
an initializer.
Note that `ActiveSupport::Cache::Store` uses `debug` level and so we
need to set the dev logger in that same level to see its messages. If
you want to debug in staging as well, you'll need to modify the log
level manually.
This way we don't need to touch the class implementation to enable the
products cache in development. Just change the default value in
`app/models/spree/app_configuration_decorator.rb`.
Why:
* Starting the environment, even with just `bundle exec rake`, results
in the following error:
```sh
Value assigned to config.time_zone not recognized.Run "rake -D time"
for a list of tasks for finding appropriate time zone names.
```
This change addresses the issue by:
* Adding the time zone setting to environment specific configurations,
defaulting to UTC in development, and using Melbourne in tests.
Since `en` is considered as the main fallback for all locales
ensure that it is present in all environments.
Note: Setting `config.i18n.fallbacks` to `true` means use the default locale
which means that if a particular instance is not using an `en` based locale
(the parent `en` locale is automatically derived as a fallback) then `en` will
not be available as a fallback.
