1 2 3 4 |
|
I know I must've seen this before, but I guess it never stuck with me. Thanks to @alindeman, @pete_higgins, and @samphippen for straightening me out.
Is it better to be thought a fool than to open your mouth and remove all doubt? I dunno, but this fool learned the RIGHT answer to the problem as well as a dose of humility. I suppose that's worth something!
]]>If you ever find yourself writing initialization for ruby hash values that looks something like this:
1 2 3 4 5 |
|
You can save yourself the ||=
statement by initializing your hash with a default value.
1 2 3 4 |
|
One small caveat is that accessing a hash at an unknown key will return
the exact instance that you gave to your Hash
initializer. If it's a mutable object
such as the Array
in this example, then mutating the object for an unknown key
will change the value for ALL unknown keys.
1 2 3 4 5 |
|
So go forth and use default hash values! Just be mindful to avoid changes to the default value object.
I was reminded by @samphippen and @pete_higgins that there is a way to prevent mutations from affecting the default value, and that is to initialize your hash with a block:
1 2 3 4 5 6 7 8 9 10 |
|
As you can see there is still a potential bug lurking above where we never actually assign a value to the hash key, however instead of returning a mutated instance for missing values what you get is the result of evaluating the block that is passed into the hash initializer.
In the scheme of things this is a better solution for initializing a hash with a default value since the default will never get polluted by accidental mutations on the default object.
]]>convert
and identify
commands.
This seemed entirely unnecessary to me in a test environment, so I came up with this small monkeypatch to bypass Dragonfly's typical calls out to ImageMagick:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
YMMV, but this resulted in a pretty significant speed increase in my image-centric application - on the order of 2x faster! Good times.
]]>1 2 3 |
|
I tracked it down to the fact that Dragonfly's default configuration adds rack-cache to your middleware stack configured with verbose logging enabled.
My solution was to add a block in my Dragonfly initializer to remove that noisy rack-cache and insert my own quiet version.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
|
Now my testing serenity is unperturbed by extra logging noise.
]]>Capybara.javascript_driver = :poltergeist
Unfortunately I discovered that after this simple substitution some of my features
involving asynchronous requests began to fail intermittently. By
taking screenshots
of the points of failure I discovered that calls to find(selector).click
did not
always appear to trigger JavaScript click events.
I cannot say whether the root cause has to do with element visibility, CSS
animations, or the JavaScript callbacks not being registered in time for the clicks
to trigger them, however I -did- find that switching to
find(selector).trigger('click')
solved my problem.
Somewhat annoying considering this behavior "just worked" in capybara-webkit, but I suppose I'll have to live with it for now.
For posterity here are the versions I hit this issue with:
Fear not, there is a way!
If you can look past a contrived example, let's say you've got models for
Organization
and Customer
, and each of them refer to a ContactInfo
.
The unnested way to use Rails i18n would be something like this:
1 2 3 4 5 |
|
1
|
|
To show different strings for Organization and Customer, the yaml syntax
has a slight twist - rather than nesting contact_info
inside of
organization
or naming they key organization.contact_info
the nested attribute should be separated with a /
character.
1 2 3 4 5 6 7 |
|
Despite the yaml syntax, the new call for a nested attribute with
human_attribute_name
is dot-separated. Feels a little weird since
the yaml uses slashes, but there you have it.
1 2 |
|
I had a hard time tracking down this syntax through the documentation or google, and it appears that this worked differently pre-3.2. This seems like it would be a good candidate for a Rails documentation contribution.
]]>