These logs are rarely checked, and can take up a lot of disk space.
I wanted to reduce the dev log level too, but then realised it also affects the dev server stdout. So now the other suggestions seem like a good idea.. (eg link development.log to /dev/null)
Oh well, this change will at least reduce one source of unnecessary disk usage in a default installation, so I think worth doing.
The hiredis client was praised as being faster parsing bulk responses
but it seems to have multiple issues now:
- The redis release 5.0 moved hiredis support to another gem.
- I tried the hiredis-client gem and it raised errors.
- There are claims of worse performance of hiredis [1].
- Maintenance responsiveness has been questioned [2].
Using the default redis driver seems to work fine though.
[1]: https://discuss.rubyonrails.org/t/hiredis-does-not-support-ssl-action-cable/75945
[2]: https://github.com/redis/hiredis/issues/655
+ Add stimulus reflex in the admin section
+ log stimulusreflex
+ Create channel and connection
+ Some logging options
+ Create application_controller each stimulus reflex controller should inherits from this one
In Staging and Production we have two Redis instances running on two different ports. In dev that probably won't be set up, and Redis will be on port 6379 by default. These defaults mean it will work nicely out of the box.
- Via `view_component_storybook` : https://github.com/jonspalmer/view_component_storybook
- Configure both `view_component_storybook` and `storybook`
- Add two addons: `@storybook/addon-docs` and `@storybook/addon-controls`
Update config comment for clarity
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.
