Various notes, links, and information about the Ruby programming language.
There are a variety of gems which implement features flags in various ways:
Sources and Discussion
Invariants and Assertions
Software Assertions are statements in a routine which should always be true. There statements may or may not be disabled in production.
A simple version of this could be implemented just by raising exceptions. However there are gems which allow for better control and make the difference between exceptions and assertions more clear.
Guidelines for building/maintaining gem projects
- manage with bundler
- choose a license
- setup support services and add badges to README
- gems to use by default:
- sign the published gems
- publish the project code and related information
- code of conduct
- contribution guidelines
When setting up TravisCI and CodeClimate, for a gem supporting Ruby 2.0 and up, the following .travis.yml can be used:
language: ruby os: - linux - osx sudo: false rvm: - 2.0 - 2.1 - 2.2 - 2.3 - 2.4 - 2.5 - ruby-head matrix: allow_failures: - rvm: ruby-head - rvm: 2.0 os: osx - rvm: 2.4 os: osx after_success: - bundle exec codeclimate-test-reporter
You will also need to add the CODECLIMATE_REPO_TOKEN to the TravisCI environment variables, getting the value from the Code Climate repository Settings > Test Coverage.
Deprecating a project
Once a gem is no-longer maintained, it should be clearly marked as such. Depending upon where the repository is hosted you should set as many of these points as possible.
- update the title in the README.md to
# :no_entry: DEPRECATED project name
- add the tags
- mark the repository as archived
- shields.io a service for generating more README shields
- How I Start - Let's Build a Gem Together! (Book Edition) by Steve Klabnik
- Standard way of marking a github organization or repository as deprecated?