I haven't gone to a movie for decades. Even back then it was overpriced, the lineups were insane, getting decent seats for the popular movies was almost impossible and the drinks/snacks were grossly overpriced. I wait until the video hits the stores and pick it up then. I can then play it at my leisure at home. No distractions, no commercials, full control on start/pause/replay and all the breaks I want when I have to get more snacks or 'return' the products I 'rented' to the sewage treatment plant. For screen size if I am downstairs watching it with family it is on a 65 inch screen. If I am in my office it is playing on a 32 inch monitor about 3 feet away and either is more than big enough to enjoy and the sound systems attached to both are more than good enough.

I use it on my old netbook running Linux. It works well on an older machine and does everything I want it to do without the extra 'fluff'.

I only check my work emails when on call and getting paid for it. Prior client demanded my cell phone number and home email as they wanted to reach me anywhere and at any time. They were told no, if they needed me they could pay me and then use the work email address to reach me. When I am at home on my time it is MY TIME to relax.

Maybe a laminated stake through the hear (wood & silver soaked in garlic and holy water). Then stuffed in a coffin placed in a double hulled container, the container gap is filled with holy water and garlic juice. Put into a rocket and launched into an orbit near the sun. Even then I would be willing to bet it would get out and return.

Yep, but, they should test to see if the variable has a value. I remember vaguely that I tested for something like that by appending a value to the end saving it to a new variable and then testing both the original and new and if the same it was null.

Really? Really doing a delete and you don't check the existence of the folder before you start? I am not a Unix/Linux scripting expert (just a very dangerous amateur), but, I always test to see if the directory is there before I even start my scripts. If the folder isn't there the script screams, rants and raves to the console and then stops before it even starts processing. Common code I do for most Z/OS BASH scripts at the start before I even run the rest of the script:

1. Is the folder(s) there that I need.
2. Do I have the proper access to the folder(s)/file(s).

If either two fail I dump to the console full information on what happened and what I think should be done to fix the problem.

It is a common set I use ->

Directory test:

if test -d $1
then
    exit ;
else
    uExit=128
fi;

File existence check:

if test -f $1
then
    exit ;
else
    uExit=128
fi;

Can I read the file:

if test -r $1
then
    exit ;
else
    uExit=128
fi;

Not pretty, probably can be coded better, but, this works for me and saved my ass a few times.

1. A lot of the movies that are showing are crap (and that is being kind).
2. The cost of my going to a movie and wife along with some munchies, well, I can buy the DVD in a few months for less money.
3. We can pause the movie at any time and take a break or grab some munchies (and not the over-priced crap in the theatre).
4. Did I mention most of the movies are crap?
5. We can skip the various 'ads' at the start of the movie. I want to see the movie, not pay to see advertising.
6. I don't have to put up with people talking about the 'good stuff' coming up and spoiling it for me.
7. I don't have to put up with the cell phones going off.
8. Did I mention most of the movies are crap?

We have very comfortable chairs at home and there is no line up to get food, drinks or when we go to the bathroom.

I wait a few months until the DVDs or Blue Ray versions come out. I then wait until friends and family give their feedback and then I may buy a copy, but, I usually wait a few more months and the video store discounts the movie. I have hundreds of videos, but, over 95% I have not paid more than $10 for. There are exceptions, but, they are for movies in a series that I (or my wife) love and want to see the next one quickly.

Again, did I mention most of the movies are crap?

Should read 'big red button'... Sigh, one of these days I will learn to spell.

First words out of Little Kim's mouth when he visited the site that connects to the real world.

Where I work developers do not have any access to production. We have a process and it tries to ensure that what gets to production has been tested by the dev team, reviewed by the support team, and finally tested by the client before it even gets near the production machine. The devellopment team defines what is to be added/changed/deleted (specs). The support team and client approves the changes before we start. The code is then tested and signed off by everyone. Once that code is ready the development team writes the installation document that defines every change required to release to production (and must match the modules in the specs) and the computer operations team follows that list of instructions. The list is also then checked against the change list and only the changes identified get released, anything else will not be released unless authorized by the support team and the client.

There are exceptions for emergencies, but, all code releases for any reason has to be signed off by the support team and client before it even hits the production machine.

The upside of this is that every change made has been documented and verified. All code released to the production machine has been documented and an audit trail is available for review. This way a developer will have a very tough time trying to sneak in code that should not be in a production machine (it still can happen, but, it is very hard).

Do the fight, at least if there is a paper trail your ass is covered. If your company has auditors, buy them a coffee and see if they can help you explain to senior management why root access for everyone is a bad thing. I needed it years ago as the support person, but, when I moved back to development they kept my access. They gave me very strange looks when I asked for access to be revoked, but, when they got audited they didn't get nailed by the auditor for having developers full access to the prod machines.

As a compromise see if you can get a 'SYSTEST' area defined where an image of prod data is stored and the new code that is to be promoted can be staged. That way developers can put up their code and prove it works with prod data and if it gets signed off by management you can 'promote' the code to the prod servers.

Been there with failing backups. We do a disaster recover exercise on a regular basis. The first time doing a disaster recovery test many years ago our backup tapes failed and we had to revert to another set of backups to finish the exercise. It drove home to senior management about the importance of backing up and just as importantly ensuring that those backups will work when they are needed!

You will probably be getting a large number of suggestions. I have done both support and development on mainframes and servers so here is some input:

1. Let management know at a high level the state of the machine(s) and get permission to spend part of your time documenting the system. When you get permission ask them for how often they need updates and how much detail. Keeping them in the loop seems to make them happy and feel important.

2. Document the current state and highlight areas of concern. Put down what the concerns are, the risks and the potential costs to the company if it fails.

3. Go through the document and organize it by risks. Try to figure out the size of the risk and how much work it will take to fix it and what is needed to fix the problem.

4. Automate as much of your process as possible. Any task you have to do on a regular basis (in my humble opinion if you do it more than once then automate it) should be automated. Dedicate time to document what you did.

5. Senior management is probably not wanting to see details. When you present, keep it simple and short. Point out the costs of failure and if you need software to help put that forward as an 'investment in infrastructure'.

6. If the company has an internal auditor make friends with him/her. Getting them on your side to present to management will help. Having the auditor explain to them the financial costs will help your cause a lot.

7. When you do things take the time to document what you are doing, WHY you are doing it, how you did it and where to go for the programs/scripts/data.

8. Pick the brains as much as possible of all the people there. Offering to buy coffee and donuts seems to make them more receptive to an informal
session and the amount of information they have could help you.

Part of every project we do now is dedicated to documentation and the client now knows the importance of that documentation and is happy to pay for it. The current system is over 25 years old and a lot of business knowledge has been lost due to people retiring or leaving. When we find things we put them into a document. The hardest thing to find is the 'WHY', but, once you get that the rest of the information starts to make more sense. Our most popular section is the 'HOW TO DO' as this is the short cut for every other document in the system.

When you do your documentation try to keep the documents as open as possible. Try to avoid proprietary packages as much as possible. We had an old flow chart program that we didn't have the program for and it took me a week to find an open source package that could read and export the files.

And document every step of the way. What you did, how you did it, where you did it and WHY! I did support for three years on a legacy mainframe app and a lot was never documented, especially the WHY. Half the time I put into fixing the outage was documentation.

Don't forget to verify that the restore process using the backups works too.