TIL

Ruby’s ‘principle of least surprise’ strikes me again. From the docs: Equality— Two hashes are equal if they each contain the same number of keys and if each key-value pair is equal to (according to Object#==) the corresponding elements in the other hash. An example: hash = { 7 => 35, "c" => 2, "a" => 1 } doppelganger = { "a" => 1, "c" => 2, 7 => 35 } hash == doppelganger #=> true

Today I was investigating a Ruby Proc created in a gem, and I wanted to know how it was defined. Other than reading source code, there doesn’t seem to be a good way to do this! Prove me wrong. We can get close by using Ruby’s #source_location function on Proc: some_proc.source_location => ["/gems/2.4.0/bundler/gems/spree/core/app/models/spree/order.rb", 34] This command shows us the line where Proc is defined. Go there to continue source-diving.

Yesterday I wrote about Chrome Flags; today I’ll explain why. Chrome is currently rolling out sweeping changes to how it handles cookies. I learned a lot about it this week. To summarize, cookies that don’t specify a SameSite attribute will be treated as SameSite=Lax by Chrome starting with version 91. Ask for those cookies from a different URL, and Chrome won’t share them. This means that cookies intended for third-party or cross-site sharing must specify SameSite=None and Secure. You can opt into this behavior today with the aforementioned flags. ...

Chrome is making changes all time time; ignore them at your peril. Today I discovered Chrome’s Flags menu, which lets you opt-in early to features that may soon be the default. Explore it at: chrome://flags/

The HTML date input tag allows you to request dates in a web form. <input type="date"> This tag is more semantic for date input than text, and provides a side benefit: Google Chrome will automatically display a calendar selector on the page.

Vim’s filetype auto-detection is great for effortless syntax highlighting, but what if a certain kind of file (i.e. Ruby) contains lots of another kind of code (i.e. SQL)? The Ruby code will be highlighted and readable, the SQL a large monochrome blob. Hard to read and reason about. We can do better! Override the automatic assignment with: :set ft=sql This command with no assignment returns the current setting: :set ft filetype=lua We can easily revert to the auto-detected extension as needed. ...

Cucumber step definitions are useful for explaining in detail the actions a user might take on your site. But after a while, they become repetitive. Certain sequences of steps, like a user signing in, happen frequently in a robust test suite. We should not have to repeat them all every time we build a feature. One solution is calling several steps from within another step: Given 'I am a signed in developer' do steps %Q{ Given I am a developer with credentials And I see the homepage When I click sign in Then I see the signin page When I enter my credentials And I click the sign in button Then I see my username in the upper right } end When you assert the topmost Given, all steps in the block will be interpolated and called. You still get the confidence of a rigorous test, but with a more concise declaration.

You can move the cursor without arrow keys. Here is the keyboard equivalent for each. Up (‘previous’): CTRL + P Down (’next’): CTRL + N Left (‘back’): CTRL + B Right (‘forward’): CTRL + F Mapping caps lock to CTRL makes these combinations very accessible.

After writing the other day about why you might not want to use simple getters, I decided that I wanted to eliminate all such methods from a project. Here is the regex I wrote to isolate the pattern: ag 'def (\w+);?\s+@\1;?\s+end' The semicolon catches one-line getter methods as well as the more common three-line.

The command md5 <file> generates a unique 32-digit hexadecimal number. This can serve as a signature for a file in its particular state, letting you know when it has changed. Example usage: $ touch test.txt $ md5 test.txt MD5 (test.txt) = d41d8cd98f00b204e9800998ecf8427e $ echo 'some content' > test.txt $ md5 test.txt MD5 (test.txt) = eb9c2bf0eb63f3a7bc0ea37ef18aeba5