README.md in super_settings-1.0.1 vs README.md in super_settings-1.0.2
- old
+ new
@@ -1,10 +1,11 @@
# SuperSettings
[](https://github.com/bdurand/super_settings/actions/workflows/continuous_integration.yml)
[](https://github.com/bdurand/super_settings/actions/workflows/regression_test.yml)
[](https://github.com/testdouble/standard)
+[](https://badge.fury.io/rb/super_settings)
This gem provides a framework for maintaining runtime application settings. Settings are persisted in a database but cached in memory for quick, efficient access. The settings are designed so they can be updated dynamically without requiring code deployment or restarting processes. The code scales very well and can easily handle very high throughput environments.
As applications grow, they tend to accumulate many configuration options. Often these end up in environment variables, hard coded in YAML files, or sprinkled through various data models as additional columns. All of these methods of configuration have their place and are completely appropriate for different purposes (i.e. for storing application secrets, configuration required during application startup, etc.).
@@ -99,9 +100,19 @@
if SuperSettings.integer("threshold") > 0
do_something(SuperSettings.integer("threshold"))
end
end
```
+
+You can also use the `SuperSettings.rand` method inside a context block to return a consistent random number. This can be useful for things like feature flags that you want to turn on for only a percentage of requests:
+
+```ruby
+def enabled?
+ SuperSettings.float("feature_rollout_percent") <= SuperSettings.rand
+end
+```
+
+Now the value of `enabled?` will always return the same value inside of a context block. It will still be random if it is enabled for each context block.
It's a good idea to add a `context` block around your main unit of work:
- Rack application: add `SuperSettings::Context::RackMiddleware` to your middleware stack
- Sidekiq: add `SuperSettings::Context::SidekiqMiddleware` to your server middleware