351–360 of 362 posts
Earlier quoted context omitted.
> Is there really an initial environment where rm * ; rm * ; does something different than rm * once? if * expands to the rm binary itself, maybe.
How is the system different after the first and after the second call?
# rm rm
rm: command not found
> but at the time the code seemed completely correct to me It always does. > Well, it teaches me to do more diverse tests when doing destructive operations. Or add some logging and do a dry run and check the results, literally simple prints statements: print("-----") print("Downloading videos ids from url: {url}") print(list of ids) ... ... ... # delete() dangerous action commented out until I'm sure it's right print…
Another technique that I've used with good success is to write a script that dumps out bash commands to delete files individually. I can visually inspect the file, analyze it with other tools, etc and then when I'm happy it's correct just "bash file_full_of_rms.sh" and be confident that it did the right thing.
Over-simplified example:
1. Copy stuff from A to B
2. Delete stuff from A
(Obviously you wouldn't do it like that, but just for illustration purposes.) It's all fine, but (2) assumes that (1) succeeded. If it didn't, maybe no space left, maybe missing permissions on B, whatnot, then (2) should not be executed. In this simple example you could tie them with `&&` or so (or just use an atomic move), but let's say these are many many commands and things are more complex.
Not everyone is an innate rockstar developer who provisions k8s clusters for breakfasts and delivers features for lunch!
Being a developer is a really hard job and there are endless complexities and difficulties along the way and when we are more seasoned already.
Don't let any negative feedback deter you from keeping doing what you're doing: learning from your mistakes and improving along the way!
Earlier quoted context omitted.
I heard of this technique, but unfortunately I don't see how it can be easily applied in software engineering/devops. Also, I now realized that aviation checklists seem to tend to be done similarly with gestures - at least from what I saw on YouTube, not sure if that's representative or only used during education (?)
Spelling out loudly the command you are about to execute and explaining the reasoning behind it can help a lot too.
I'm honestly trying to think of the way how I could approach this for myself, just I don't see a clear solution yet that wouldn't require me to spell out everything I type in my terminal window.
Earlier quoted context omitted.
Don't use a shell script.
Do you mean, always pass the list directly to the next script via function calls, without writing it to an intermediate file / pipeline?
If you _absolutely_ must use a shell script:
0. Use shellcheck, which will warn you about many of the below issues: https://www.shellcheck.net/
1. understand how quoting and word splitting work: https://mywiki.wooledge.org/Quotes
2. if piping files to other programs, using `-print0` or equivalent (or even better, if using something like find, its built in execution options): https://mywiki.wooledge.org/UsingFind
3. Beware the pitfalls (especially something like parsing `ls`): https://mywiki.wooledge.org/BashPitfalls
(warning: the community around that wiki can be pretty toxic, just keep that in mind when foraying into it.)
Earlier quoted context omitted.
>The root of this particular issue was Vimeo's failure to do this migration for their customers. Yes and No. At the end of the day, you as a business have to insulate yourself from your infrastructure provider.
Vimeo is the only infrastructure provider providing that service. It is impossible to insulate a business from it.
Earlier quoted context omitted.
He doesn't talk bad about his employer. He talks bad about his employers client.
Tech is like any other human endeavor. People talk. People change jobs and still like the people in the place they left.
Nowhere is perfect. If people can't be honest about the flaws then they're useless.
> but at the time the code seemed completely correct to me It always does. > Well, it teaches me to do more diverse tests when doing destructive operations. Or add some logging and do a dry run and check the results, literally simple prints statements: print("-----") print("Downloading videos ids from url: {url}") print(list of ids) ... ... ... # delete() dangerous action commented out until I'm sure it's right print…
During buildup of the our_id list: assert (vimeoId not in our_ids).
After creating the list: assert len(set(our_ids)) > 10000 and assert len(set(our_ids)) == len(our_ids)
Before each final deletion: assert id not in hardcoded_list_of_golden_samples.
Depending on the speed required you could hit the api again here as an extra check.
Earlier quoted context omitted.
Yes and? Make a snapshot on live. Again, never touch data before snapshot.
At risk of sounding snarky, you do understand how video hosting platforms work? Customers, even enterprise ones, don’t have shell access let alone control over what file system is used. There are a hundred ways this problem could have been prevented but ZFS isn’t one of them.
No, no i don't.
Earlier quoted context omitted.
Yes and? Make a snapshot on live. Again, never touch data before snapshot.
This reminds of some IRC threads. You post a question and someone's answer assumes you are going to rip out and replace your existing prod setup just so you can use their pet tool.