This replaces boilerplate in the “benchmark your code” section of the
contributors’ guide with an executable template. I also amended the text
to encourage best practices and codified it in the template.
For now this is only good for relatively self-contained changes that can
be inlined into a simple script. In the future, this can be expanded to
cover how to measure the difference between two commits.
The output looks like this:
```
==================================== Empty =====================================
Warming up --------------------------------------
blank? 225.963k i/100ms
fast_blank? 238.147k i/100ms
Calculating -------------------------------------
blank? 8.825M (± 6.4%) i/s - 44.063M in 5.014824s
fast_blank? 9.311M (± 6.3%) i/s - 46.439M in 5.009153s
Comparison:
fast_blank?: 9310694.8 i/s
blank?: 8824801.7 i/s - same-ish: difference falls within error
================================= Single Space =================================
Warming up --------------------------------------
blank? 56.581k i/100ms
fast_blank? 232.774k i/100ms
Calculating -------------------------------------
blank? 813.985k (±16.7%) i/s - 4.017M in 5.076576s
fast_blank? 9.547M (± 5.2%) i/s - 47.719M in 5.013204s
Comparison:
fast_blank?: 9547414.0 i/s
blank?: 813985.0 i/s - 11.73x slower
================================== Two Spaces ==================================
Warming up --------------------------------------
blank? 58.265k i/100ms
fast_blank? 244.056k i/100ms
Calculating -------------------------------------
blank? 823.343k (±16.2%) i/s - 4.020M in 5.014213s
fast_blank? 9.484M (± 4.9%) i/s - 47.347M in 5.005339s
Comparison:
fast_blank?: 9484021.6 i/s
blank?: 823343.1 i/s - 11.52x slower
=============================== Mixed Whitspaces ===============================
Warming up --------------------------------------
blank? 53.919k i/100ms
fast_blank? 237.103k i/100ms
Calculating -------------------------------------
blank? 763.435k (±16.8%) i/s - 3.720M in 5.018029s
fast_blank? 9.672M (± 5.8%) i/s - 48.369M in 5.019356s
Comparison:
fast_blank?: 9672467.2 i/s
blank?: 763435.4 i/s - 12.67x slower
=============================== Very Long String ===============================
Warming up --------------------------------------
blank? 34.037k i/100ms
fast_blank? 240.366k i/100ms
Calculating -------------------------------------
blank? 409.731k (± 8.9%) i/s - 2.042M in 5.028235s
fast_blank? 9.794M (± 4.3%) i/s - 49.035M in 5.016328s
Comparison:
fast_blank?: 9794225.2 i/s
blank?: 409731.4 i/s - 23.90x slower
```
The master branch is required Ruby 2.2.2+, for the Ruby 2.2 is bundled Minitest 5.4.3,
I think backward compatibility code for Minitest 4 is unnecessary.
Tests on Rails [are currently failing](https://travis-ci.org/rails/rails/jobs/78255666).
The reason is the dependency of Rails master from gems that are currently on
GitHub (not on RubyGems) and should be explicitly referenced in the Guides
test files.
The bug report templates are now executed from the `ci/travis.rb` when
`GEM` contains `guides`.
I started by creating a `test` task in `guides/Rakefile` to handle this,
but since inline `gemfile` must not be executed with `bundle exec`, that
rake task would not be consistent with others. So I went back by
executing them directly from `Build`.
Use inline Gemfile dependency when reporting gem bugs
- Generally we have to run the bug templates multiple times to get them
right and it always complains because the posts and comments tables
already exist due to earlier runs.
- Using force: true will eliminate this issue.
- Right now master is 5.0.0. Latest gem release is 4.2.0 for which we
are accepting bug reports. So lets use it in bug report templates.
- 5.0.0 is not installable as it's not available on Rubygems yet. So the
gem bug templates are not usable without editing the version. Using
4.2.0 will make them usable again.
- `secrets.secret_token` is now used in all places `config.secret_token` was
- `secrets.secret_token`, when not present in `config/secrets.yml`,
now falls back to the value of `config.secret_token`
- when `secrets.secret_token` is set, it over-writes
`config.secret_token` so they are the same (for backwards-compatibility)
- Update docs to reference app.secrets in all places
- Remove references to `config.secret_token`, `config.secret_key_base`
- Warn that missing secret_key_base is deprecated
- Add tests for secret_token, key_generator, and message_verifier
- the legacy key generator is used with the message verifier when
secrets.secret_key_base is blank and secret_token is set
- app.key_generator raises when neither secrets.secret_key_base nor
secret_token are set
- app.env_config raises when neither secrets.secret_key_base nor
secret_token are set
- Add changelog
Run focused tests via
ruby -w -Itest test/application/configuration_test.rb -n '/secret_|key_/'
Define Minitest::Test in case we are running the gist under Minitest 4
and avoid relying on MiniTest::Unit::TestCase to avoid displaying
warning on version five.
[ci skip]
