Nat  Grady

Nat Grady


Assertr: Assertive Programming for R analysis Pipelines


Assertive Programming for R analysis Pipelines.

What is it?

The assertr package supplies a suite of functions designed to verify assumptions about data early in an analysis pipeline so that data errors are spotted early and can be addressed quickly.

This package does not need to be used with the magrittr/dplyr piping mechanism but the examples in this README use them for clarity.


You can install the latest version on CRAN like this


or you can install the bleeding-edge development version like this:


What does it look like?

This package offers five assertion functions, assert, verify, insist, assert_rows, and insist_rows, that are designed to be used shortly after data-loading in an analysis pipeline...

Let’s say, for example, that the R’s built-in car dataset, mtcars, was not built-in but rather procured from an external source that was known for making errors in data entry or coding. Pretend we wanted to find the average miles per gallon for each number of engine cylinders. We might want to first, confirm

  • that it has the columns "mpg", "vs", and "am"
  • that the dataset contains more than 10 observations
  • that the column for 'miles per gallon' (mpg) is a positive number
  • that the column for ‘miles per gallon’ (mpg) does not contain a datum that is outside 4 standard deviations from its mean, and
  • that the am and vs columns (automatic/manual and v/straight engine, respectively) contain 0s and 1s only
  • each row contains at most 2 NAs
  • each row is unique jointly between the "mpg", "am", and "wt" columns
  • each row's mahalanobis distance is within 10 median absolute deviations of all the distances (for outlier detection)

This could be written (in order) using assertr like this:


    mtcars %>%
      verify(has_all_names("mpg", "vs", "am", "wt")) %>%
      verify(nrow(.) > 10) %>%
      verify(mpg > 0) %>%
      insist(within_n_sds(4), mpg) %>%
      assert(in_set(0,1), am, vs) %>%
      assert_rows(num_row_NAs, within_bounds(0,2), everything()) %>%
      assert_rows(col_concat, is_uniq, mpg, am, wt) %>%
      insist_rows(maha_dist, within_n_mads(10), everything()) %>%
      group_by(cyl) %>%

If any of these assertions were violated, an error would have been raised and the pipeline would have been terminated early.

Let's see what the error message look like when you chain a bunch of failing assertions together.

    > mtcars %>%
    +   chain_start %>%
    +   assert(in_set(1, 2, 3, 4), carb) %>%
    +   assert_rows(rowMeans, within_bounds(0,5), gear:carb) %>%
    +   verify(nrow(.)==10) %>%
    +   verify(mpg < 32) %>%
    +   chain_end
    There are 7 errors across 4 verbs:
             verb redux_fn           predicate     column index value
    1      assert     <NA>  in_set(1, 2, 3, 4)       carb    30   6.0
    2      assert     <NA>  in_set(1, 2, 3, 4)       carb    31   8.0
    3 assert_rows rowMeans within_bounds(0, 5) ~gear:carb    30   5.5
    4 assert_rows rowMeans within_bounds(0, 5) ~gear:carb    31   6.5
    5      verify     <NA>       nrow(.) == 10       <NA>     1    NA
    6      verify     <NA>            mpg < 32       <NA>    18    NA
    7      verify     <NA>            mpg < 32       <NA>    20    NA

    Error: assertr stopped execution

What does assertr give me?

verify - takes a data frame (its first argument is provided by the %>% operator above), and a logical (boolean) expression. Then, verify evaluates that expression using the scope of the provided data frame. If any of the logical values of the expression's result are FALSE, verify will raise an error that terminates any further processing of the pipeline.

assert - takes a data frame, a predicate function, and an arbitrary number of columns to apply the predicate function to. The predicate function (a function that returns a logical/boolean value) is then applied to every element of the columns selected, and will raise an error if it finds any violations. Internally, the assert function uses dplyr's select function to extract the columns to test the predicate function on.

insist - takes a data frame, a predicate-generating function, and an arbitrary number of columns. For each column, the the predicate-generating function is applied, returning a predicate. The predicate is then applied to every element of the columns selected, and will raise an error if it finds any violations. The reason for using a predicate-generating function to return a predicate to use against each value in each of the selected rows is so that, for example, bounds can be dynamically generated based on what the data look like; this the only way to, say, create bounds that check if each datum is within x z-scores, since the standard deviation isn't known a priori. Internally, the insist function uses dplyr's select function to extract the columns to test the predicate function on.

assert_rows - takes a data frame, a row reduction function, a predicate function, and an arbitrary number of columns to apply the predicate function to. The row reduction function is applied to the data frame, and returns a value for each row. The predicate function is then applied to every element of vector returned from the row reduction function, and will raise an error if it finds any violations. This functionality is useful, for example, in conjunction with the num_row_NAs() function to ensure that there is below a certain number of missing values in each row. Internally, the assert_rows function uses dplyr'sselect function to extract the columns to test the predicate function on.

insist_rows - takes a data frame, a row reduction function, a predicate-generating function, and an arbitrary number of columns to apply the predicate function to. The row reduction function is applied to the data frame, and returns a value for each row. The predicate-generating function is then applied to the vector returned from the row reduction function and the resultant predicate is applied to each element of that vector. It will raise an error if it finds any violations. This functionality is useful, for example, in conjunction with the maha_dist() function to ensure that there are no flagrant outliers. Internally, the assert_rows function uses dplyr'sselect function to extract the columns to test the predicate function on.

assertr also offers four (so far) predicate functions designed to be used with the assert and assert_rows functions:

  • not_na - that checks if an element is not NA
  • within_bounds - that returns a predicate function that checks if a numeric value falls within the bounds supplied, and
  • in_set - that returns a predicate function that checks if an element is a member of the set supplied. (also allows inverse for "not in set")
  • is_uniq - that checks to see if each element appears only once

and predicate generators designed to be used with the insist and insist_rows functions:

  • within_n_sds - used to dynamically create bounds to check vector elements with based on standard z-scores
  • within_n_mads - better method for dynamically creating bounds to check vector elements with based on 'robust' z-scores (using median absolute deviation)

and the following row reduction functions designed to be used with assert_rows and insist_rows:

  • num_row_NAs - counts number of missing values in each row
  • maha_dist - computes the mahalanobis distance of each row (for outlier detection). It will coerce categorical variables into numerics if it needs to.
  • col_concat - concatenates all rows into strings
  • duplicated_across_cols - checking if a row contains a duplicated value across columns

and, finally, some other utilities for use with verify

  • has_all_names - check if the data frame or list has all supplied names
  • has_only_names - check that a data frame or list have only the names requested
  • has_class - checks if passed data has a particular class

More info

For more info, check out the assertr vignette

    > vignette("assertr")

Or read it here


Download Details:

Author: ropensci
Source Code: 
License: View license

#r #assertion #rstats #functions 

Assertr: Assertive Programming for R analysis Pipelines

OAuth2: A Ruby Wrapper for The OAuth 2.0 Protocol.


OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. This is a RubyGem for implementing OAuth 2.0 clients and servers in Ruby applications. See the sibling oauth gem for OAuth 1.0 implementations in Ruby.

Release Documentation

Version 2.0.x

2.0.x Readmes

VersionRelease DateReadme

Older Releases

1.4.x Readmes

VersionRelease DateReadme
1.4.10Jul 1, 2022
1.4.9Feb 20, 2022
1.4.8Feb 18, 2022
1.4.7Mar 19, 2021
1.4.6Mar 19, 2021
1.4.5Mar 18, 2021
1.4.4Feb 12, 2020
1.4.3Jan 29, 2020
1.4.2Oct 1, 2019
1.4.1Oct 13, 2018
1.4.0Jun 9, 2017

1.3.x Readmes

VersionRelease DateReadme
1.3.1Mar 3, 2017
1.3.0Dec 27, 2016

≤= 1.2.x Readmes (2016 and before)

VersionRelease DateReadme
1.2.0Jun 30, 2016
1.1.0Jan 30, 2016
1.0.0May 23, 2014
< 1.0.0Find here


 Projectbundle add oauth2
1️⃣name, license, License: MIT FOSSA InchCI
2️⃣version & activityGem Version Total Downloads Download Rank Source Code Open PRs Closed PRs Next Version
3️⃣maintanence & lintingMaintainability Helpers Depfu Contributors Style Kloc Roll
4️⃣testingOpen Issues Closed Issues Supported Heads Unofficial Support MacOS Windows
5️⃣coverage & securityCodeClimate CodeCov Coveralls Security Policy CodeQL Code Coverage
6️⃣resourcesDiscussion Get help on Codementor Chat Blog Blog
7️⃣spread 💖Liberapay Patrons Sponsor Me Tweet @ Peter 🌏 👼 💻


Install the gem and add to the application's Gemfile by executing:

$ bundle add oauth2

If bundler is not being used to manage dependencies, install the gem by executing:

$ gem install oauth2

OAuth2 for Enterprise

Available as part of the Tidelift Subscription.

The maintainers of OAuth2 and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source packages you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact packages you use. Learn more.

Security contact information

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.

For more see

What is new for v2.0?

  • Officially support Ruby versions >= 2.7
  • Unofficially support Ruby versions >= 2.5
  • Incidentally support Ruby versions >= 2.2
  • Drop support for the expired MAC Draft (all versions)
  • Support IETF rfc7523 JWT Bearer Tokens
  • Support IETF rfc7231 Relative Location in Redirect
  • Support IETF rfc6749 Don't set oauth params when nil
  • Support OIDC 1.0 Private Key JWT; based on the OAuth JWT assertion specification (RFC 7523)
  • Support new formats, including from application/vdn.api+json, application/vnd.collection+json, application/hal+json, application/problem+json
  • Adds new option to OAuth2::Client#get_token:
    • :access_token_class (AccessToken); user specified class to use for all calls to get_token
  • Adds new option to OAuth2::AccessToken#initialize:
    • :expires_latency (nil); number of seconds by which AccessToken validity will be reduced to offset latency
  • By default, keys are transformed to camel case.
    • Original keys will still work as previously, in most scenarios, thanks to rash_alt gem.
    • However, this is a breaking change if you rely on response.parsed.to_h, as the keys in the result will be camel case.
    • As of version 2.0.4 you can turn key transformation off with the snaky: false option.
  • By default, the :auth_scheme is now :basic_auth (instead of :request_body)
    • Third-party strategies and gems may need to be updated if a provider was requiring client id/secret in the request body
  • ... A lot more


Targeted ruby compatibility is non-EOL versions of Ruby, currently 2.7, 3.0 and 3.1. Compatibility is further distinguished by supported and unsupported versions of Ruby. Ruby is limited to 2.2+ for 2.x releases. See 1-4-stable branch for older rubies.

Ruby Engine Compatibility Policy

This gem is tested against MRI, JRuby, and Truffleruby. Each of those has varying versions that target a specific version of MRI Ruby. This gem should work in the just-listed Ruby engines according to the targeted MRI compatibility in the table below. If you would like to add support for additional engines, first make sure Github Actions supports the engine, then submit a PR to the correct maintenance branch as according to the table below.

Ruby Version Compatibility Policy

If something doesn't work on one of these interpreters, it's a bug.

This library may inadvertently work (or seem to work) on other Ruby implementations, however support will only be provided for the versions listed above.

If you would like this library to support another Ruby version, you may volunteer to be a maintainer. Being a maintainer entails making sure all tests run and pass on that implementation. When something breaks on your implementation, you will be responsible for providing patches in a timely fashion. If critical issues for a particular implementation exist at the time of a major release, support for that Ruby version may be dropped.

 Ruby OAuth2 VersionMaintenance BranchSupported OfficiallySupported UnofficiallySupported Incidentally
1️⃣2.0.xmaster2.7, 3.0, 3.12.5, 2.62.2, 2.3, 2.4
2️⃣1.4.x1-4-stable2.5, 2.6, 2.7, 3.0, 3.12.1, 2.2, 2.3, 2.41.9, 2.0
3️⃣olderN/ABest of luck to you!Please upgrade! 

NOTE: The 1.4 series will only receive critical security updates. See

Usage Examples

authorize_url and token_url are on site root (Just Works!)

require 'oauth2'
client ='client_id', 'client_secret', site: '')
# => #<OAuth2::Client:0x00000001204c8288 @id="client_id", @secret="client_sec...
client.auth_code.authorize_url(redirect_uri: 'http://localhost:8080/oauth2/callback')
# => ""

access = client.auth_code.get_token('authorization_code_value', redirect_uri: 'http://localhost:8080/oauth2/callback', headers: {'Authorization' => 'Basic some_password'})
response = access.get('/api/resource', params: {'query_foo' => 'bar'})
# => OAuth2::Response

Relative authorize_url and token_url (Not on site root, Just Works!)

In above example, the default Authorization URL is oauth/authorize and default Access Token URL is oauth/token, and, as they are missing a leading /, both are relative.

client ='client_id', 'client_secret', site: '')
# => #<OAuth2::Client:0x00000001204c8288 @id="client_id", @secret="client_sec...
client.auth_code.authorize_url(redirect_uri: 'http://localhost:8080/oauth2/callback')
# => ""

Customize authorize_url and token_url

You can specify custom URLs for authorization and access token, and when using a leading / they will not be relative, as shown below:

client ='client_id', 'client_secret',
                            site: '',
                            authorize_url: '/jaunty/authorize/',
                            token_url: '/stirrups/access_token')
# => #<OAuth2::Client:0x00000001204c8288 @id="client_id", @secret="client_sec...
client.auth_code.authorize_url(redirect_uri: 'http://localhost:8080/oauth2/callback')
# => ""
# => OAuth2::Client

snake_case and indifferent access in Response#parsed

response = access.get('/api/resource', params: {'query_foo' => 'bar'})
# Even if the actual response is CamelCase. it will be made available as snaky:
JSON.parse(response.body)         # => {"accessToken"=>"aaaaaaaa", "additionalData"=>"additional"}
response.parsed                   # => {"access_token"=>"aaaaaaaa", "additional_data"=>"additional"}
response.parsed.access_token      # => "aaaaaaaa"
response.parsed[:access_token]    # => "aaaaaaaa"
response.parsed.additional_data   # => "additional"
response.parsed[:additional_data] # => "additional"        # => OAuth2::SnakyHash (subclass of Hashie::Mash::Rash, from `rash_alt` gem)

What if I hate snakes and/or indifference?

response = access.get('/api/resource', params: {'query_foo' => 'bar'}, snaky: false)
JSON.parse(response.body)         # => {"accessToken"=>"aaaaaaaa", "additionalData"=>"additional"}
response.parsed                   # => {"accessToken"=>"aaaaaaaa", "additionalData"=>"additional"}
response.parsed['accessToken']    # => "aaaaaaaa"
response.parsed['additionalData'] # => "additional"        # => Hash (just, regular old Hash)


Set an environment variable, however you would normally do that.

# will log both request and response, including bodies
ENV['OAUTH_DEBUG'] = 'true'

By default, debug output will go to $stdout. This can be overridden when initializing your OAuth2::Client.

require 'oauth2'
client =
  site: '',
  logger:'example.log', 'weekly')


The AccessToken methods #get, #post, #put and #delete and the generic #request will return an instance of the #OAuth2::Response class.

This instance contains a #parsed method that will parse the response body and return a Hash-like OAuth2::SnakyHash if the Content-Type is application/x-www-form-urlencoded or if the body is a JSON object. It will return an Array if the body is a JSON array. Otherwise, it will return the original body string.

The original response body, headers, and status can be accessed via their respective methods.


If you have an existing Access Token for a user, you can initialize an instance using various class methods including the standard new, from_hash (if you have a hash of the values), or from_kvform (if you have an application/x-www-form-urlencoded encoded string of the values).


On 400+ status code responses, an OAuth2::Error will be raised. If it is a standard OAuth2 error response, the body will be parsed and #code and #description will contain the values provided from the error and error_description parameters. The #response property of OAuth2::Error will always contain the OAuth2::Response instance.

If you do not want an error to be raised, you may use :raise_errors => false option on initialization of the client. In this case the OAuth2::Response instance will be returned as usual and on 400+ status code responses, the Response instance will contain the OAuth2::Error instance.

Authorization Grants

Currently the Authorization Code, Implicit, Resource Owner Password Credentials, Client Credentials, and Assertion authentication grant types have helper strategy classes that simplify client use. They are available via the #auth_code, #implicit, #password, #client_credentials, and #assertion methods respectively.

These aren't full examples, but demonstrative of the differences between usage for each strategy.

auth_url = client.auth_code.authorize_url(redirect_uri: 'http://localhost:8080/oauth/callback')
access = client.auth_code.get_token('code_value', redirect_uri: 'http://localhost:8080/oauth/callback')

auth_url = client.implicit.authorize_url(redirect_uri: 'http://localhost:8080/oauth/callback')
# get the token params in the callback and
access = OAuth2::AccessToken.from_kvform(client, query_string)

access = client.password.get_token('username', 'password')

access = client.client_credentials.get_token

# Client Assertion Strategy
# see:
claimset = {
  iss: 'http://localhost:3001',
  aud: 'http://localhost:8080/oauth2/token',
  sub: '',
  exp: + 3600,
assertion_params = [claimset, 'HS256', 'secret_key']
access = client.assertion.get_token(assertion_params)

# The `access` (i.e. access token) is then used like so:
access.token # actual access_token string, if you need it somewhere
access.get('/api/stuff') # making api calls with access token

If you want to specify additional headers to be sent out with the request, add a 'headers' hash under 'params':

access = client.auth_code.get_token('code_value', redirect_uri: 'http://localhost:8080/oauth/callback', headers: {'Some' => 'Header'})

You can always use the #request method on the OAuth2::Client instance to make requests for tokens for any Authentication grant type.


This library aims to adhere to Semantic Versioning 2.0.0. Violations of this scheme should be reported as bugs. Specifically, if a minor or patch version is released that breaks backward compatibility, a new version should be immediately released that restores compatibility. Breaking changes to the public API will only be introduced with new major versions.

As a result of this policy, you can (and should) specify a dependency on this gem using the Pessimistic Version Constraint with two digits of precision.

For example:

spec.add_dependency 'oauth2', '~> 2.0'


License: MIT

FOSSA Status


After checking out the repo, run bin/setup to install dependencies. Then, run rake spec to run the tests. You can also run bin/console for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run bundle exec rake install. To release a new version, update the version number in version.rb, and then run bundle exec rake release, which will create a git tag for the version, push git commits and tags, and push the .gem file to





Made with contributors-img.

Code of Conduct

Everyone interacting in the OAuth2 project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the code of conduct.

Author: oauth-xx
Source code:
License: MIT license

#ruby #ruby-on-rails 

OAuth2: A Ruby Wrapper for The OAuth 2.0 Protocol.
Macey  Legros

Macey Legros


Assertion in Java Example | Java Assertion Tutorial

Java assertion is an inbuilt statement that ensures the correctness of any assumptions which have been done in the program. When an assertion is executed, it is assumed to be true. If the assertion is false, the JVM will throw an Assertion error. Assertions in Java can be done with the help of the assert keyword.

Suppose there is a condition that you, as a programmer or a developer, while testing your code, want to make sure exists, such as making sure that a particular method shall  return only negative values; Java has a (relatively) new feature made available just for that.

The feature is called assertion, and wherein one can assert the existence of a particular condition. It is done with the help of the keyword assert. Assertions are generally used for testing and scarcely used in the release code. Release code is usually run with assertions disabled.

#Why to use Assertions

  1. We can make sure that an unreachable looking code is unreachable.
  2. We can make sure that assumptions written in the comments are right.
         if ((x & 1) == 1)  
         {  }
         else // x must be even 
         { assert (x % 2 == 0); }
  1. We can make sure the default switch case is not reached.
  2. We can check the object’s state.
  3. At the beginning of the method
  4. After the method invocation.

#assertion #java #assert

Assertion in Java Example | Java Assertion Tutorial