On a tangent, I was paranoid enough in one position to have all my production terminal windows have a red background with yellow text. That brought the proper, serious attitude towards my work.
I liked the green / white text theme the most with blue being my second favorite to write code in so those got the ones I would use the most. I was never a lover of the old amber terminals and red is just plain painful to write on. I guess the more pain your terminal causes you, the more dangerous the environment.
It's hideous, of course. But it works very well for me, and I don't suppose I'd be averse, if interest becomes evident, to sharing it somewhere for others to benefit from and/or peruse in horrified fascination.
https://gist.github.com/anonymous/8ec128e88dac85d93ed58fb518...
Outside GNU coreutils, the only dependencies are mysql(1) (of course) and jq(1), which is more or less "awk for JSON" and which I strongly recommend to anyone who regularly deals with that file format.
Share and Enjoy!
[0] https://biology.stackexchange.com/questions/3871/which-shade...
I was at a site when a truck hit the power main and the UPS (diesel if I recall) for the server room failed to work. The new people were in the "It shouldn't take too long to reboot the servers" where the experienced people were "this is going to be a very long day". The later group was rewarded with a 36 hour day.
export PS1=$(tput bold; tput setaf 1;)'(production)'$(tput sgr0)' \u@\h: \W $ '
and get something a little more lively! (For many more things you might be able to do with "tput", refer to "man 5 terminfo" on your local Linux machine.)I had a job where we would often sudo as other users and ssh into other boxes. I kept trying and trying to find a way to change the terminal when sudoed as someone else because occasionally I would execute something in the first terminal I could grab. At the time I couldn't find anything or think of a way.
Indeed. To capitalize on a meme in current circulation, "One does not simply 'accidentally destroy' a production database."
When things like this happen, they happen because someone who almost certainly did, in fact, know better -- at some point made a conscious decision to allow them to happen, by consciously cutting corners in certain matters of due diligence that we all know about. Things like backup systems, database roles, and hiring the right people to set up and maintain these things.
Not because of something a junior dev did.
As a first-day developer, he shouldn't really have had the ability to make a mistake with any consequences beyond lost time.
Better yet, prod should be in a different "cloud universe" (root account, etc) from dev.
> The company/CTO made the huge mistakes.
Absolutely.