A JavaScript VM in the kernel is inevitable.
A JavaScript VM in the kernel is inevitable.
not by any means modern, but I used to really like pal
I highly recommend installing fzf, and its shell integration. Makes your Ctrl + r magnitudes more pleasant to use!
More than that, your editor doesn’t run with root permissions, which reduces the risk of accidentally overwriting something you didn’t mean to.
it feels to me, like they’re less looking for new people to start doing this “work”, but more to connect with people who already happen to be enthusiastically going to events and showing off their laptops.
This is up there with left-pad now!
Are you using PersistentVolumes? If your storage class supports it, looks like there’s a volume snapshot concept you can use, have you looked into that?
Not sure what you’re doing, but if we’re talking about a bog standard service backed by a db, I don’t think having automated reverts of that data is the best idea. you might lose something! That said, triggering a snapshot of your db as a step before deployment is a pretty reasonable idea.
Reverting a service back to a previous version should be straightforward enough, and any dedicated ci/cd tool should have an API to get you information from the last successful deploy, whether that is the actual artifact you’re deploying, or a reference to a registry.
As you’re probably entirely unsurprised by, there are a ton of ways to skin this cat. you might consider investing in preventative measures, testing your data migration in a lower environment, splitting out db change commits from service logic commits, doing some sort of blue/green or canary deployment.
I get fairly nerd-sniped when it comes to build pipelines so happy to talk more concretely if you’d like to provide some more details!
I use these two vim plugins for the same functionality without leaving $EDITOR:
I’ve also started dabbling with using fzf in scripts for the team to use. Don’t sleep on the --query
and --select-1
flags!
is that more or less cursed than cat image.img > /dev/whatever
?
dd if=image.img of=/dev/disk/flashdrive
is usually all you need
Definitely not what you’re talking about, but still: https://www.destroyallsoftware.com/talks/a-whole-new-world
The two factors at an ATM are possession of your bank card + knowledge of your pin. (it also takes your photo, for good measure)
GitHub will happily accept a smart card or whatever, if an extra plastic rectangle jives with you more than an OTP generator.
Your two factors shift to possession of your password vault + knowledge of the password to it. You’re okay IMO.
You also still get the anti-replay benefits of the OTPs, though that might be a bit moot with TLS everywhere.
just to give you the term to search for, these types of applications are called snippet managers. for example, https://snibox.github.io/
there’s a ton of them around. I don’t have a particular one that I recommend, since it’s not something I use in my workflow.
I can’t believe they didn’t with go with BatShIt. it’s right there! they were SO close!
grep -r
exists and is even more faster and doesn’t require passing around file names.
grep -r --include='*.txt' 'somename' .
I just started using this at $jorb. Check out their “ui-mode” is all I’m going to say about that.
Better than that, git config supports conditional includes, based on a repo URL or path on disk. So you can have a gitconfig per organization or whatever, which specifies an sshCommand and thus an ssh key.
… but
cd
is a built-in