TIL

The ‘shake’ is an important React Native feature; it opens the In-App Developer Menu. This menu lets you reload, open the inspector, monitor performance, and more. To ‘shake’ your simulated device, press ^ ⌘ Z. An alternative hotkey is ⌘ D.

When you push an iOS build to TestFlight, what’s the experience for your testers? Do they need to opt-in to test the latest build? Speaking anecdotally as person who has pushed a build and plans to test it today, when you add that build to your test group, it is automatically downloaded as the default for each of your testers, replacing the previous build. You can visit the TestFlight app on your phone to see the apps you can test. The latest build (build number, an integer, not the SemVer version) should be automatically downloaded to your device.

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/