fix: more docs

docs/sdks/dot_net.md

@@ -27,7 +27,7 @@ var settings = new UnleashSettings()
   UnleashApi = new Uri("API URL"),
   CustomHttpHeaders = new Dictionary()
   {
-    {"Authorization","API secret" }
+    {"Authorization","API token" }
   }
 };
 
@@ -36,7 +36,7 @@ IUnleash unleash = new DefaultUnleash(settings);
 
 In your app you typically just want one instance of Unleash, and inject that where you need it.
 
-You should change the URL and the Authorization header (API secret) with the correct values for your instance, which you may locate under “Instance admin” in the menu.
+You should change the URL and the Authorization header (API token) with the correct values for your instance, which you may locate under “Instance admin” in the menu.
 
 ## Step 3: Use the feature toggle
 

docs/sdks/java.md

@@ -29,7 +29,7 @@ UnleashConfig unleashConfig = UnleashConfig.builder()
         .instanceId("your-instance-1")
         .environment(System.getenv("APP_ENV"))
         .unleashAPI("API URL")
-        .customHttpHeader("Authorization", "API Secret")
+        .customHttpHeader("Authorization", "API token")
         .build();
 
 Unleash unleash = new DefaultUnleash(config);
@@ -37,7 +37,7 @@ Unleash unleash = new DefaultUnleash(config);
 
 In your app you typically just want one instance of Unleash, and inject that where you need it. You will typically use a dependency injection frameworks such as Spring or Guice to manage this.
 
-You should change the URL and the Authorization header (API secret) with the correct values for your instance, which you may locate under “Instance admin” in the menu.
+You should change the URL and the Authorization header (API token) with the correct values for your instance, which you may locate under “Instance admin” in the menu.
 
 ## Step 3: Use the feature toggle
 

docs/sdks/node.md

@@ -38,7 +38,7 @@ Please also pay attention to the “environment” option. Setting this will all
 
 Now that we have initialized the client SDK in our application we can start using feature toggles defined in Unleash in our application. To achieve this we have the “isEnabled” method available, which will allow us to check the value of a feature toggle. This method will return **true** or **false** based on whether the feature should be enabled or disabled for the current request.
 
-```js
+```javascript
 setInterval(() => {
   if (unleash.isEnabled('DemoToggle')) {
     console.log('Toggle enabled');
@@ -60,11 +60,12 @@ An activation strategy is an implementation of rules based on data, which you pr
 
 You provide the Unleash context as part of the second argument to the isEnabled call:
 
-```sh
-    const context = {
-        userId: '123',
-        sessionId: '123123-123-123,
-        remoteAddress: '127.0.0.1',
-    };
-    const enabled = isEnabled('app.demo', context);
+```javascript
+const context = {
+  userId: '123',
+  sessionId: '123123-123-123',
+  remoteAddress: '127.0.0.1',
+};
+
+const enabled = isEnabled('app.demo', context);
 ```

docs/sdks/python.md

@@ -18,4 +18,58 @@ from UnleashClient import UnleashClient
     client.is_enabled("unleash.beta.variants")
 ```
 
+### Checking if a feature is enabled
+
+A check of a simple toggle:
+
+```Python
+client.is_enabled("My Toggle")
+```
+
+Specifying a default value:
+
+```Python
+client.is_enabled("My Toggle", default_value=True)
+```
+
+Supplying application context:
+
+```Python
+app_context = {"userId": "test@email.com"}
+client.is_enabled("User ID Toggle", app_context)
+```
+
+Supplying a fallback function:
+
+```Python
+def custom_fallback(feature_name: str, context: dict) -> bool:
+    return True
+
+client.is_enabled("My Toggle", fallback_function=custom_fallback)
+```
+
+- Must accept the fature name and context as an argument.
+- Client will evaluate the fallback function only if exception occurs when calling the `is_enabled()` method i.e. feature flag not found or other general exception.
+- If both a `default_value` and `fallback_function` are supplied, client will define the default value by `OR`ing the default value and the output of the fallback function.
+
+### Getting a variant
+
+Checking for a variant:
+
+```python
+context = {'userId': '2'}  # Context must have userId, sessionId, or remoteAddr.  If none are present, distribution will be random.
+
+variant = client.get_variant("MyvariantToggle", context)
+
+print(variant)
+> {
+>    "name": "variant1",
+>    "payload": {
+>        "type": "string",
+>        "value": "val1"
+>        },
+>    "enabled": True
+> }
+```
+
 Read more at [github.com/Unleash/unleash-client-python](https://github.com/Unleash/unleash-client-python)

docs/sdks/ruby.md

@@ -15,4 +15,52 @@ title: Ruby SDK
     )
 ```
 
+### Sample usage
+
+To evaluate a feature toggle, you can use:
+
+```ruby
+if @unleash.is_enabled? "AwesomeFeature", @unleash_context
+  puts "AwesomeFeature is enabled"
+end
+```
+
+If the feature is not found in the server, it will by default return false. However you can override that by setting the default return value to `true`:
+
+```ruby
+if @unleash.is_enabled? "AwesomeFeature", @unleash_context, true
+  puts "AwesomeFeature is enabled by default"
+end
+```
+
+Alternatively by using `if_enabled` you can send a code block to be executed as a parameter:
+
+```ruby
+@unleash.if_enabled "AwesomeFeature", @unleash_context, true do
+  puts "AwesomeFeature is enabled by default"
+end
+```
+
+### Variations
+
+If no variant is found in the server, use the fallback variant.
+
+```ruby
+fallback_variant = Unleash::Variant.new(name: 'default', enabled: true, payload: {"color" => "blue"})
+variant = @unleash.get_variant "ColorVariants", @unleash_context, fallback_variant
+
+puts "variant color is: #{variant.payload.fetch('color')}"
+```
+
+## Client methods
+
+| Method Name | Description | Return Type |
+| --- | --- | --- |
+| `is_enabled?` | Check if feature toggle is to be enabled or not. | Boolean |
+| `enabled?` | Alias to the `is_enabled?` method. But more ruby idiomatic. | Boolean |
+| `if_enabled` | Run a code block, if a feature is enabled. | `yield` |
+| `get_variant` | Get variant for a given feature | `Unleash::Variant` |
+| `shutdown` | Save metrics to disk, flush metrics to server, and then kill ToggleFetcher and MetricsReporter threads. A safe shutdown. Not really useful in long running applications, like web applications. | nil |
+| `shutdown!` | Kill ToggleFetcher and MetricsReporter threads immediately. | nil |
+
 Read more at [github.com/Unleash/unleash-client-ruby](https://github.com/Unleash/unleash-client-ruby)

docs/user_guide/unleash-context.md

@@ -3,19 +3,24 @@ id: unleash_context
 title: Unleash Context
 ---
 
-To standardise a few activation strategies, we also needed to standardise the Unleash context, which contains fields that vary per request, required to implement the activation strategies.
+To standardize a few activation strategies, we also needed to standardize the Unleash context, which contains fields that vary per request, required to implement the activation strategies.
 
-The unleash context is defined by these fields:
+The Unleash context is compromised by a set of predefined fields. The static fields does not change in the life-time of your application, while dynamic fields can change per feature toggle evaluation.
+
+**Static context fields**
+
+- appName: String
+- environment: String
+
+**Dynamic context fields**
 
 - userId: String,
 - sessionId: String,
 - remoteAddress: String,
 - properties: Map<String, String>
-- appName: String
-- environment: String
 
-All fields are optional, but if they are not set you will not be able to use certain activation strategies.
-
-E.g., the `userWithId` strategy obviously depends on the `userId` field.
+All fields are optional, but if they are not set you will not be able to use certain activation strategies. E.g., the `userWithId` strategy obviously depends on the `userId` field.
 
 The `properties` field is more generic and can be used to provide more arbitrary data to strategies. Typical usage is to add more metadata. For instance, the `betaUser` strategy may read a field from `properties` to check whether the current user is a beta user.
+
+In Unleash Enterprise you may also pre-configure all you customer context fields (`properties`) and use them together with [strategy constraints](../advanced/strategy_constraints) to compose any target rules you need.