TIL

Rails’ fields_for helper inserts a hidden ID field into your form. This is generally helpful, because you’ll want that information when you’re updating the record. But what if you don’t? This is the scenario I encountered today: a ‘read-only’ form nested inside a fields_for helper, with no inputs. It almost worked: unfortunately, due to the default ID-inserting behavior of fields_for, there was a hidden ID input. It was getting submitted with the rest of the form and breaking things. ...

I recently delivered a form that was hidden via CSS, using the BassCSS hide class, and encountered an issue: iOS customers’ browsers were and trying to autofill this hidden form with their saved passwords. What was going on here? hide it imparts these styles on its target in my Chrome: .hide { position: absolute !important; height: 1px; width: 1px; overflow: hidden; clip: rect(1px,1px,1px,1px); } This worked visually, but it didn’t hide the form from iOS. Browsing the BassCSS docs, I learned that this is an ‘accessible’ hide, meant to visually hide an element from view but keep it available to screen readers. No wonder iOS was confused. ...

Here’s a scenario: you’re hacking on Ruby code in pry, and it’s a mess. Blocks chained on blocks, variables named a and other_one, assignments to _. You can understand it, but nobody else can, and one extra } breaks everything. The solution is the edit command. Typing edit in pry loads the current buffer into your editor of choice. Jump in there and turn those inline blocks into do/end, assign some variables, write a method: iterate on some quality code in the comfortable, predictable setting of your text editor.

When chaining commands in the terminal, you may need to do things that affect the shell’s environment, like change directories. Here’s an example: $ yarn install && cd ios && pod install && cd .. && yarn build These cd’s can clutter up a script, and they’re incidental. My solution is to use a subshell (here’s the explanation from man bash): (list) list is executed in a subshell environment (see COMMAND EXECUTION ENVIRONMENT below). Variable assignments and builtin commands that affect the shell’s environment do not remain in effect after the command completes. The return status is the exit status of list. ...

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. ...