Also https://audioread.com/. I love that you can forward emails to audioread and they'll be transcribed into podcasts. Thank you AI-voiced Matt Levine!
Thanks for sharing those. We're currently testing out the release of personalised podcasts, as the combination of LLMs and the realistic text-to-speech can lead to a solution of a quality level that has not been available until now.
I occasionally ponder on how frustrating it is that the deceased don't get to hear their eulogies. It would have been amazing for Bram to have been able to experience all the outpouring of support and love from people he is interacted with during his life. Especially in a context where the speakers aren't considering him as an audience -- they're sharing their deep and true feelings.
No one can really be sure how their acquaintances feel about them. Eulogies are the closest we get. Imagine if he were able to hear all these great things said about him... It would be such a joy.
This is why I always make it a point to tell people how much I appreciate them and why (when I do, I mean). It can be awkward at first, but I’ve developed a good self-deprecation that lets me excuse myself for being gushy (“I might start crying; I’m a crier!”), and that disarms people for the most part. I think it’s really important that we let people know how much we value them and why we honor/respect them when we do. Because most of us do wander through life in a cloud of unknowing and uncertainty.
Off topic but your comment makes me think of Nick Drake. He died at 26, before even knowing he'd achieved anything, his music barely listened to, probably feeling a failure. Posthumously he's one of the world's most acclaimed recording artists.
RIP Bram.
At least in one of the Van Gogh movies, he says something like 'one day, people will understand'. To me, that suggests that he knew the value of his work whereas OP suggests that Nick Drake didn't know that he created something that people will value.
Larry David had the same thought, and it was the theme of the episode "The Covid Hoarder" in Curb Your Enthusiasm wherein Albert Brooks stages a funeral for his non-deceased self.
tig is great for a read only operations. Looking at the tree, peeking at diffs, finding specific commits. It's quicker to get in and out of. I reach for it instead of `git log`.
lazygit makes it super easy to make modifications. Reorder commits, revert specific hunks from commits. I find it easier to use if I need to look at a really big diff. I reach for it instead of `git rebase -i`, and it can do things no native tool can do easily (such as revert or extract specific hunks from commit earlier in the tree.
I use both multiple times per day. tig if I just want to look at stuff (fewer keystrokes to look at diffs in the tui!) and lazygit if I want to modify stuff (more powerful!).
I find marking files, hunks and single lines to commit extremely comfortable in tig. And also reverting is as easy as selecting a file or hunk and pressing Shift+1. But yes, more complex operations are not supported or rather you have to define an external command and thus use an external tool for those.
Not if it was done well, unfortunately... I suppose there's always sending a text to a friend saying "I'll leave the money in a blue bag on the corner of 4th ave at 10am tomorrow" and hiding in the bushes (but sadly we'd expect an attacker who was halfway across the world, not across town). I am pretending everything is fine until I can't.
RDS Proxy is very specific with which versions it supports. If it says it doesn't support it, it doesn't support it.
Postgres 14 is supposed to have built-in connection pooling. If you're on it, do you still feel the need for RDS Proxy? We're using pgbouncer and can't decide if we should switch to RDS Proxy or upgrade to Postgres 14 and drop the external connection pooler.
It's useful when you want to edit some input text before passing it to a different function. For example, if I want to delete many of my git branches (but not all my git branches):
$ git branch | vipe | xargs git branch -D
`vipe` will let me remove some of the branch names from the list, before they get passed to the delete command.
I mostly rely on fzf for stuff like this nowadays.
You can replace vipe with fzf —multi for example and get non-inverted behavior with fuzzy search.
More to it, not in a pipe (because of poor ^C behavior), but using a hokey in zsh to bring up git branch | fzf, select any number of branches I need and put them on command line, this is extremely composable.
I vaguely recall in ~2010 coming across a Plan 9 manpage(?) that seemed to imply that Emacs could work that way in a pipe (in reference to complex/bloated tools on non-Plan 9 systems), but that wasn't true of any version of Emacs I'd ever used.
And what if you decide mid-vipe "oh crap I don't want to do this anymore"? In the case of branches to delete you could just delete every line. In other cases maybe not?
Actually, it doesn’t. ZQ is the same as :q! which quits without saving with a 0 exit code. So all of your git branches get deleted in this example, since you left the file as it was. You definitely want :cq here.
To be fair, that scenario would be just as bad or worse without vipe.
Also, you can construct your pipeline so that a blank file (or some sentinel value) returned from vipe means “abort”. A good example of this is when git opens your editor for interactive merging — deleting all lines cancels the whole thing.
Yeah you could just as well say "oh crap I didn't mean to do that" after finishing a non-interactive command. However, at least knowing my own lazy tendencies, I could imagine feeling comfortable hitting <enter> on this command without a final careful review, because part of me thinks that I can still back out, since the interactive part isn't finished yet.
But maybe not. I haven't tried it yet (and it does seem really useful).
It will depend on the commands in question. The entire unix pipeline is instantiated in parallel, so the commands following vipe will already be running and waiting on stdin.
You could kill them before exiting the editor, if that's what you want. Or you could do something else.
The other commands in the pipeline are run by the parent shell, not vipe, so handling this would not be vipe specific.
I learned to use a piece of paper to cover up what I have already read to avoid the eyes to ‘backtrack’. For reading on paper that is. I find highlighting on screen a little similar …
This was on a speed reading class I attended in the 90’ies
