We were already doing so by duplicating the code; now we're doing it
explicitly.
This is going to help because we're going to do a few changes in the
environment files, and this way we don't have to do everything twice.
Note that, after we're finished with these changes, the staging and
production environments will be mostly identical and we could simply
require the production environment configuration in the `staging.rb`
file. We aren't doing so because some Consul installations might have
customized these files and it'd be hard for them to deal with all these
changes at once. So, for now, they'll only have to deal with the
possible differences between their staging and preproduction
environments.
Changes to the preproduction environment that won't be applied to the
staging environment can be added like this:
require Rails.root.join("config", "environments", "staging")
Rails.application.configure do
config.log_level = :warn
end
We're not adding the rule because it would apply the current line length
rule of 110 characters per line. We still haven't decided whether we'll
keep that rule or make lines shorter so they're easier to read,
particularly when vertically splitting the editor window.
So, for now, I'm applying the rule to lines which are about 90
characters long.
`dalli_store` is deprecated since dalli 2.7.11.
We can now enable cache_versioning. We didn't enable it when upgrading
to Rails 5.2 because of possible incompatibility with `dalli_store` [1],
even though apparently some the issues were fixed in dalli 2.7.9 and
dalli 2.7.10 [2].
Since using cache versioning makes cache expiration more efficient, and
I'm not sure whether the options we were passing to the dalli store are
valid with memcache store (documentation here is a bit lacking), I'm
just removing the option we used to double the default cache size on
production.
[1] https://www.schneems.com/2018/10/17/cache-invalidation-complexity-rails-52-and-dalli-cache-store
[2] https://github.com/petergoldstein/dalli/blob/master/History.md
While debugging JavaScript is certainly useful, enabling it generates
about 100 extra HTTP requests because we include about 100 JavaScript
files (including external dependencies and files written by us).
Depending on the browser configuration, this might make the browser take
a very long time processing these requests.
On my machine, with these changes, refreshing a page on Firefox takes
about 1 second, while previously it took about 6-8 seconds. With
Chromium, there doesn't seem to be much difference.
Developers are encouraged to temporarily turn debugging while debugging
JavaScript (which is a task I personally do about once a month) if that
makes debugging easier for them.
This change doesn't affect our CSS files, since for CSS we use Sass
instead of the asset pipeline. Sass already compiles all CSS files into
one in the development environment.
All the code in the `bin/` and the `config/` folder has been generated
running `rake app:update`, except the `escape_javascript_fix` file,
which we've removed since the code there is already included in Rails
5.2.
This option was added by Rails 4 new application generator. However, the
`assets.digest` option is set to true by default, and recent Rails
versions don't even add this option to the environment files.
In commit 574133a5 we configured the development to use Dalli to cache
pages. However, cache is usually disabled in the development
environment.
When we upgraded to Rails 5 in commit eb36b7e2, we configured the
development environment to enable caching (using a memory store) when a
certain file is present, and to disable it when it's not. This
configuration makes more sense IMHO, and it was being overwritten by the
one previously mentioned.
After this change, using memcached is no longer required in the
development environment and the `DalliError: No server available` error
message is gone.
this is usually configured in the production.rb file (which is under
version control), the natural place to configure it is the secrets.yml
file.
Until now we were using the capistrano shared folder, but that's a bit
inconvenient since changes we've done to the production.rb file (like
changing eager_load_paths when we upgraded to Rails 5) won't take effect
after a deployment.
Since SMTP passwords should not be in a file under version control, and
they're usually configured in the production.rb file (which is under
version control), the natural place to configure it is the secrets.yml
file.
Until now we were using the capistrano shared folder, but that's a bit
inconvenient since changes we've done to the production.rb file (like
changing eager_load_paths when we upgraded to Rails 5) won't take effect
after a deployment.
We were very inconsistent regarding these rules.
Personally I prefer no empty lines around blocks, clases, etc... as
recommended by the Ruby style guide [1], and they're the default values
in rubocop, so those are the settings I'm applying.
The exception is the `private` access modifier, since we were leaving
empty lines around it most of the time. That's the default rubocop rule
as well. Personally I don't have a strong preference about this one.
[1] https://rubystyle.guide/#empty-lines-around-bodies
Metrics/LineLength: Line is too long.
RSpec/InstanceVariable: Use let instead of an instance variable.
Layout/TrailingBlankLines: Final newline missing.
Style/StringLiterals: Prefer double-quoted strings.
Keep a blank line before and after private
Keep a blank line before and after protected
Remove extra empty line at class body end
Remove extra blank line
Add final newline
Use 2 (not 3) spaces for indentation
Use 2 (not 4) spaces for indentation
Remove space before comma
Add space after comma
Remove trailing whitespaces
Remove unnecessary spacing
Use snake_case for variable names
Do not use then for multi-line if
Remove unused block argument - i
Use the new Ruby 1.9 hash syntax
Remove unused assignment to variable
Indent when as deep as case
Align attributes
Align end with def
The logs are always stored in log/bullet.log
If you run the specs with `BULLET=true bin/rspec`:
* Any feature test which makes bullet angry will fail
If you run rails with `BULLET=true bin/rails s`:
* It will print the bullet logs in both the rails log and the bullet log
* It will show a footer on each page with the N+1 queries etc.
