Download the PHP package zumba/swivel without Composer
On this page you can find all versions of the php package zumba/swivel. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package swivel
Zumba Swivel
Swivel is a fresh spin on an old idea: Feature Flags (toggles, bits, switches, etc.).
Typical Feature Flags are all or nothing: either the feature is on for everyone, or it is off for everyone.
Typical Feature Flags are based on boolean conditionals with few abstractions (if this, then that). Although powerful in their simplicity, this typically leads to increased cyclomatic complexity and eventual technical debt.
Swivel is Different
Swivel is fundamentally different from Typical Feature Flags in two ways:
- Features can be enabled for a subset of an application's users.
- Features are not simple conditionals; a developer defines one or more strategies (behaviors) and Swivel takes care of determining which strategy to use.
Buckets
With Swivel, users are separated into one of ten "buckets," allowing a feature to be enabled for a subset of users. The advantages of this approach are clear:
- Deploying a new feature to 10% of users enables developers to catch unforeseen bugs/problems with new code without negatively affecting all users. These kind of deployments are called Canary Releases. As soon as it is determined that new code is safe, roll out the new feature to more users in increments (30%, 50%, etc.); eventually the feature can enabled for all users, safely.
- A/B testing becomes a breeze. Imagine running up to 9 versions of a new feature with one group kept in reserve as a control. Is feature "A" negatively affecting revenue metrics for 10% of your users? No problem: turn it off and go with version "B" instead. This is easy to do with Swivel.
Behaviors
Agile code needs to be simple and easy to change. Typical Feature Flags allow developers to quickly iterate when business rules change or new features are implemented, but this can often lead to complex, under engineered, brittle blocks of code.
Swivel encourages the developer to implement changes to business logic as independent, high level strategies rather than simple, low level deviations.
Example: Quick Look
Getting Started
The first thing you'll want to do is generate a random number between 1 and 10 for each user in your application. We call this the user's "bucket" index. This is what is used by Swivel to determine which features are enabled for that user.
Note: As a best practice, once a user is assigned to a bucket they should remain in that bucket forever. You'll want to store this value in a session or cookie like you would other basic user info.
Next, you'll need to create a map of features. This map indicates which buckets should have certain features enabled. Here is an example of a simple feature map:
When your application starts, configure Swivel and create a new manager instance:
Way to go! Swivel is now ready to use.
Using Strategies
Now that you have a new Swivel manager created, you can start using it in your application. To use Swivel you need to define behaviors for features of your code; Swivel will decide which behavior to execute based on the current user's bucket and the feature map you loaded in the configuration step.
Strategy Example
Say you have coded a new search algorithm for your website. The Search feature of your site is integral to your business, so you only want to roll out the new algorithm to 10% of your users at first. You decide to only enable the algorithm for users in bucket 5. You configure Swivel and register it with your application:
In your code to search the site, you define two distinct strategies, and tell Swivel about them:
Now, when you call search, Swivel will execute awesomeSearch for users in bucket 5, and normalSearch for all other users.
Swivel API
Zumba\Swivel\Config
constructor($map, $index, $logger)
Used to configure your Swivel Manager instance.
| Param | Type | Details |
|---|---|---|
| $map (optional) |
mixed | Can be one of the following:
|
| $index (optional) |
integer | The user's predefined bucket index. A number between 1 and 10. |
| $logger (optional) |
LoggerInterface |
An optional logger that implements \Psr\Log\LoggerInterface |
Examples
Zumba\Swivel\Manager
constructor($config)
This is the primary Swivel object that you will use in your app.
| Param | Type | Details |
|---|---|---|
| $config | Config |
A \Zumba\Swivel\Config instance. |
Examples
forFeature($slug)
Create a point of deviation in your code. Returns a new Zumba\Swivel\Builder that accepts multiple behaviors, default behaviors, and executes the appropriate code for the user's bucket.
| Param | Type | Details |
|---|---|---|
| $slug | string | The first section of a feature map slug. i.e., for the feature slug "Test.Version.Two", the $slug would be "Test" |
Examples
invoke($slug, $a, $b)
Shorthand syntactic sugar for invoking a simple feature behavior. Useful for ternary style code.
| Param | Type | Details |
|---|---|---|
| $slug | string | The first section of a feature map slug. i.e., for the feature slug "Test.Version.Two", the $slug would be "Test" |
| $a | callable | The strategy to execute if the $slug is enabled for the user's bucket. |
| $b (optional) |
callable | The strategy to execute if the $slug is not enabled for the user's bucket. If omitted, invoke will return null if the feature slug is not enabled. |
Examples
returnValue($slug, $a, $b)
Shorthand syntactic sugar for invoking a simple feature behavior using Builder::addValue. Useful for ternary style code.
| Param | Type | Details |
|---|---|---|
| $slug | string | The first section of a feature map slug. i.e., for the feature slug "Test.Version.Two", the $slug would be "Test" |
| $a | mixed | The value to return if the $slug is enabled for the user's bucket. |
| $b (optional) |
mixed | The value to return if the $slug is not enabled for the user's bucket. If omitted, returnValue will return null if the feature slug is not enabled. |
Examples
Zumba\Swivel\Builder
The Builder API is the primary way that you will write Swivel code. You get a new instance of the Builder when you call Manager::forFeature.
addBehavior($slug, $strategy, $args)
Lazily adds a behavior to this feature that will only be executed if the feature is enabled for the user's bucket.
| Param | Type | Details |
|---|---|---|
| $slug | string | The second section of a feature map slug. i.e., for the feature slug "Test.Version.Two", the $slug here would be "Version.Two" |
| $strategy | callable | The strategy to execute if the $slug is enabled for the user's bucket. Since version 2.0.0 $strategy must be a callable. If you want to return a simple value, use Builder::addValue instead. |
| $args (optional) |
array | Parameters to pass to the $strategy callable if it is executed. |
Examples
addValue($slug, $value)
Lazily adds a behavior to this feature that will return the value provided. It will only be executed if the feature is enabled for the user's bucket.
| Param | Type | Details |
|---|---|---|
| $slug | string | The second section of a feature map slug. i.e., for the feature slug "Test.Version.Two", the $slug here would be "Version.Two" |
| $value | mixed | The value to return if the $slug is enabled for the user's bucket. If $value is a callable it will not be executed. If you want Swivel to execute a callable, use Builder::addBehavior instead. |
Examples
defaultBehavior($strategy, $args)
Lazily adds a behavior to this feature that will only be executed if no other feature behaviors are enabled for the user's bucket.
| Param | Type | Details |
|---|---|---|
| $strategy | callable | The strategy to execute if no other feature behaviors are enabled for the user's bucket. Since version 2.0.0 $strategy must be a callable. If you want to return a simple value, use Builder::defaultValue instead. |
| $args (optional) |
array | Parameters to pass to the $strategy callable if it is executed. |
Examples
defaultValue($value)
Lazily adds a behavior to this feature that will return the provided value. It will only be executed if no other feature behaviors are enabled for the user's bucket.
| Param | Type | Details |
|---|---|---|
| $value | mixed | The value to return if no other feature behaviors are enabled for the user's bucket. If you want Swivel to execute a callable, use Builder::defaultBehavior instead. |
Examples
execute()
Executes the appropriate behavior strategy based on the user's bucket.
Examples
noDefault()
If you do not need to define a default behavior to be executed when a feature is not enabled for a user's bucket, call noDefault on the Builder. Swivel will throw a \LogicException if you neglect to define a default behavior and do not call noDefault. Likewise, Swivel will throw a \LogicException if you call both noDefault and defaultBehavior on the same Builder instance.
