scientist4k-http-filter

A Kotlin port of Github's Scientist library for refactoring critical code paths

License

License

GroupId

GroupId

com.github.squirrelgrip
ArtifactId

ArtifactId

scientist4k-http-filter
Last Version

Last Version

0.10.5
Release Date

Release Date

Type

Type

jar
Description

Description

scientist4k-http-filter
A Kotlin port of Github's Scientist library for refactoring critical code paths

Download scientist4k-http-filter

How to add to project

<!-- https://jarcasting.com/artifacts/com.github.squirrelgrip/scientist4k-http-filter/ -->
<dependency>
    <groupId>com.github.squirrelgrip</groupId>
    <artifactId>scientist4k-http-filter</artifactId>
    <version>0.10.5</version>
</dependency>
// https://jarcasting.com/artifacts/com.github.squirrelgrip/scientist4k-http-filter/
implementation 'com.github.squirrelgrip:scientist4k-http-filter:0.10.5'
// https://jarcasting.com/artifacts/com.github.squirrelgrip/scientist4k-http-filter/
implementation ("com.github.squirrelgrip:scientist4k-http-filter:0.10.5")
'com.github.squirrelgrip:scientist4k-http-filter:jar:0.10.5'
<dependency org="com.github.squirrelgrip" name="scientist4k-http-filter" rev="0.10.5">
  <artifact name="scientist4k-http-filter" type="jar" />
</dependency>
@Grapes(
@Grab(group='com.github.squirrelgrip', module='scientist4k-http-filter', version='0.10.5')
)
libraryDependencies += "com.github.squirrelgrip" % "scientist4k-http-filter" % "0.10.5"
[com.github.squirrelgrip/scientist4k-http-filter "0.10.5"]

Dependencies

compile (9)

Group / Artifact Type Version
com.github.squirrelgrip : cheti jar 1.1.13
com.github.squirrelgrip : extensions jar 1.1.0
com.github.squirrelgrip : scientist4k-http-core jar 0.10.5
com.google.guava : guava jar 30.1-jre
io.dropwizard.metrics5 : metrics-core Optional jar 5.0.0
io.micrometer : micrometer-core Optional jar 1.6.3
org.awaitility : awaitility jar 4.0.3
org.jetbrains.kotlin : kotlin-stdlib jar
org.springframework.boot : spring-boot-starter-jetty jar 2.4.2

provided (1)

Group / Artifact Type Version
javax.servlet : javax.servlet-api jar 4.0.1

test (5)

Group / Artifact Type Version
com.github.squirrelgrip : scientist4k-http-test jar 0.10.5
org.junit.jupiter : junit-jupiter-engine jar
org.assertj : assertj-core jar 3.19.0
org.mockito : mockito-core jar 3.7.7
org.mockito : mockito-junit-jupiter jar 3.7.7

Project Modules

There are no modules declared in this project.

Scientist4K

Maven Central Build Status

A port of Github's refactoring tool Scientist in Kotlin

Installation

<dependency>
    <groupId>com.github.squirrelgrip</groupId>
    <artifactId>scientist4k-bom</artifactId>
    <version>0.10.3</version>
</dependency>

Usage

This Kotlin port supports most of the functionality of the original Scientist library in Ruby, however its interface is a bit different.

The core component of this library is the ExperimentSummary<T> class. It's recommended to use this class as a Singleton. The main usage is as follows:

Basic Usage

You can either run a synchronous experiment or an asynchronous experiment.

For a synchronous experiment, the order in which control and candidate functions are run.

To run a synchronous experiment:

val e = ExperimentSummary("foo")
e.run(controlFunction, candidateFunction)

For an asynchronous experiment, the two functions are run asynchronously.

To run an asynchronous experiment:

val e = ExperimentSummary<Int>("foo")
e.runAsync(controlFunction, candidateFunction)

Behind the scenes the following occurs in both cases:

  • It decides whether or not to run the candidate function
  • Measures the durations of all behaviors
  • Compares the result of the two
  • Swallows (but records) any exceptions raised by the candidate
  • Publishes all this information.

Metrics

Scientist4J ships with support for two common metrics libraries—Dropwizard metrics and Micrometer. As each of these is optional, you’ll need to add your choice as an explicit dependency to your project:

<dependency>
    <groupId>io.dropwizard.metrics5</groupId>
    <artifactId>metrics-core</artifactId>
</dependency>

or

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-core</artifactId>
</dependency>

The following metrics are reported, with the form scientist.[experiment name].*:

  • duration of default (control) behavior in ns
  • duration of candidate behavior in ns
  • counter of total number of users going through the codepath
  • counter of number of mismatches
  • counter of candidate exceptions

You may also implement your own MetricsProvider, to meet your specific needs.

Optional Configuration

Users can define the following functions:

  • publish - to publish results of an experiment, if you want to supplement the MetricsProvider’s publishing mechanism
  • compareResults - by default this library just uses equals between objects for equality, but in case you want to special case equality between objects)
  • sample - add extra meta-data to each experiment execution
  • enabled - ability to turn the experiment functionality off, true by default
  • async - ability to run the experiment in synchronous or asynchronous manner, true by default

License: MIT

Releasing

Run the following to kick of a release...

mvn --batch-mode -U clean jgitflow:release-start -PgitflowStart

This will create a new release branch from the develop branch and push to origin. Travis will then kick in complete the release. If everything goes fine, you should see a new version in maven central after a few minutes and all you need to do is checkout develop again and keep developing, deleting the local release branch.

When ossTypes times out, which is occasionally does, please follow these steps...

Determine if the artifact was deployed successfully to maven central

If it has, then run the following...

mvn --batch-mode -U clean jgitflow:release-finish -DnoDeploy=true

This will update the versions accordingly, commit and push the changes, without redeploying to maven central.

If it has not, then... Checkout the release branch and fix the problem and commit the change to the release branch. This will restart the build on travis and will reattempt to build the release.

Ideas

  1. If you don't need to raiseExceptionOmMismatch you don't need a comparator.
  2. The idea of checking if the control and candidate match may not be a concern for the execution of the experiment. The observations could be recorded only when the results are being processed do they need to be compared.
  3. Allow for a percentage of comparisons. ie. 50% compared.

Versions

Version
0.10.5
0.10.3
0.10.2
0.10.1
0.10.0
0.9.3
0.9.2
0.9.1
0.8.9
0.8.8
0.8.7
0.8.6
0.8.5
0.8.4
0.8.3
0.8.2
0.8.1
0.8.0
0.7.8
0.7.7
0.7.6
0.7.5
0.7.4
0.7.3
0.7.2
0.7.1
0.7.0