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.
The default was being ignored in our new logging configuration, and the actual log output was way too high. This was causing serious disk space issues.
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.
For some reason running `bundle exec rake db:migrate RAILS_ENV=staging`
fails with:
```
rake aborted!
NameError: uninitialized constant Spree::Config
```
Running `bundle exec rails server` for instance, does not. There must be
a difference on the way a rake task and the rails commands load the app.
Moving this configuration to an initializer, at the end of the
initialization process, fixes it. The constant `Spree::Config` is
already loaded.
**This is preventing the release v1.22.0 from being staged and tested**
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.
Otherwise, there are no log lines for any request, which makes it
impossible to find out anything about the app in production.
Obviously this increases the size of the log files but this has to be
dealt with log rotation. The data is our most important asset.
