I don't "enforce" this but I do aim for it, and yes, I do partial squashing throughout my workday.
As I work on a feature branch, I'll check in WIP commits as checkpoints, especially at EOD. I don't expect these to pass the full CI suite.
But as the code starts to shape up, I'll unstage all those WIPs and start to group the changes into logical commits. As work progresses, I'll use `git add --patch` to split new lines of code into those existing logical commits. Sometimes I'll split one up, sometimes I'll group two together; it's still flexible and amorphous at this point.
By the time I'm ready to merge upstream, these commits tend to be neat, focused, and functional, and I do check to make sure they pass the relevant tests (though I don't enforce a full CI build here).
Then a rebase from master, push to CI, and then a no-ff merge commit into master to retain both the low-level commits and the ability to easily revert the whole lot.
It might seem like a ton of busywork, but I find that staging atomic commits like this doubles as an excellent line-by-line review of the code I've written. It also forces that review step to happen throughout the process rather than all the way at the end when I've forgotten all that deep context.
Yeah code folding works for the visual scrub, but it's the "search within" feature that's missing.
An example of my common use case is digging through a Bosh manifest file for a resource with a particular name, then finding, say, the VM type associated with that resource. The name and vm_type fields may be separated by hundreds of lines (it's a machine-generated file that does not retain element order), but they're siblings of each other.
In vim, I could land on the first { and then hit:
v% (extend selection to matching delimiter)
/\%Vvmtype: (to search for "vmtype:" within the selection).
In IntelliJ I could similarly extend a selection between delimiters and then search within it.
It's absolutely correct that this is a tooling problem. You could imagine a YML plugin for IntelliJ or vim smart enough to offer a motion for "select all the children of this block," but AFAICT no such tool exists.
I'm working with a 12k-line YML file with lots of sub-trees right now, and let me tell you, it's a gigantic pain in the butt.
If it were JSON, I could navigate within a subtree by selecting & searching the text between the `{}` delimiters. But instead, I have to gently scroll downwards, keeping a careful eye on the indentation, to see whether I've moved into the adjacent subtree.
Digital Foundry's initial analysis mostly bears this claim out.
They found FPS increases of between 160-190% for a bunch of recent games featuring both RTX/traditional rendering, and about a fixed 190% in Quake RTX (which is exclusively RTX rendering).
Choosing an obscure language with little community support imposes real-world development costs: it's harder to find or ramp up new developers, there are fewer eyes identifying bugs in the implementation, tooling support can be subpar, documentation and blog posts are harder to find, etc.
(btw I know nothing about ATS so I'm not saying this is a good description of that language in particular.)
Agree. Dashes alone are worth the price of a MacBook Pro: <minus> for a hyphen, <option-minus> for an en-dash, <shift-option-minus> for an em-dash. Trivial to remember.
Just as good is the way Apple handles diacritics. You type a prefix keystroke for the diacritic, then follow it with the letter that's being modified: ö is <option-u, o>, ï is <option-u, i>, è is <option-grave, e>.
Most of the prefixes have easy-to-remember mnemonics: umlaut is <option-u>, grave is <option-grave>, tilde is <option-n> (for eñe, I suppose), but even hunting down these prefixes is fairly discoverable. After typing the prefix, a placeholder character is displayed in the text box showing the mark you've just entered, something like: ̲̈.
Then:
- <escape> or moving the cursor with an arrow key enters the diacritic as standalone character (e.g. ¨ is <option-u, escape>).
- <backspace> deletes the diacritic.
- A character that takes the diacritic enters the modified character.
- A character that does not usually take the diacritic enters the diacritic and the unmodified character (e.g. <option-n, 5> yields ˜5).
Are these screen recordings with narration or video recordings from a webcam?
Personal preference of course, but I'd be less able to express myself in a video recording than in an audio recording or written document, out of pure self-consciousness.
For me, the cost/benefit ratio of cell phones far exceeds that of Alexa/Google Assistant/etc.
Also, there's a well-established framework of laws governing under what conditions and by whom your telephone conversations can be monitored. For Alexa/GA, you're at the mercy of the TOS.
https://youtu.be/FtgUSUHnzLI