Well, on the first part, it's a difference between "I don't know", or giving a mostly right answer from memory. If you have to go to Google to find out what program to use to view interface stats (for a SysAdmin), or look up the syntax for say "include" for C, then that's not exactly the candidate you want. Partially or mostly correct answers are good answers. Completely and utterly wrong answers are... well... wrong.
Some obscure things aren't fair game for interviews. How do you change an interface configuration on a Cisco 2980G? That's a trick question unless the person really knows Cisco.
And of course, asking for definitions of internal use abbreviations and internal policy is just impossible. One place I was at had an acronym for almost everything, and there were other internally used codes, and none of them were documented. Well, pretty much nothing was documented. It took a couple weeks to find out what most the internal use acronyms were. It took the first week to find all the servers, and another month to find out what their purpose was, and even longer to actually get access to them so I could work on them. It was my job to work on them.
For the sake of the scenario, the machine is in a datacenter, in a rack with everything labeled, and you are sitting at a desk where you have both any tools required on your desktop, as well as nearby access to the physical machines. I used variations of that one frequently, but it was tailored for the persons claimed skills and the job role they were applying for. It's silly to ask a DBA or web programmer to debug a networking issue.:)
Actually, I never had anyone walk out. Since it was presented as roleplay of a real world situation, and I'd explain the details of the situation calmly and clearly, it was evident that it was an extreme example.
But hey, if you can't handle an environment with occasional high stress, I wouldn't want you there. That's the last thing I'd ever want is a stressful situation to come up, and an employee walking out because it was "too hard".
As I've found, there's always some degree of yelling in high dollar production environments, especially where a few minutes of outage can be the difference between a highly profitable day, or a huge loss. Hell, people freak out when a Windows file share stops working, or Outlook eats their mail. I've never seen a warm fuzzy workplace that involved a production environment and/or deadlines, that didn't have the occasional loud emotional moments.
When I've interviewed, the yelling is only a small part, during the roleplay part. The rest of it was a fun conversation with plenty of joking around. If they can't laugh at my jokes, they won't be very entertaining to work with.:)
The last place I worked at, it was unfortunately an every day occurrence. It was always something, which sometimes included outages at tier 1 providers that we were not directly connected to.
"Oh my god, this guy in [insert random city] called saying he can't reach us! Fix it now!"
[traceroute to see where the problem may be]
"There's an outage on [insert another provider]. We'll have to wait for them to fix it."
"No, call them now! Get it fixed!"
"We're not their customer, I can't call them. They'd just hang up on me."
"Do it anyways, I don't care, get it fixed!"
[calls 3rd party provider, and gets hung up on]
"They hung up on me."
"Call [some sales minion] at [our provider]! He'll get it fixed."
[calls sales minion, gets told he can't do anything]
You see where this goes. About 30 minutes of people running around like idiots, and suddenly like a freakin' miracle the 3rd party provider fixes their problem and the world is saved yet again. Of course, they always want a written report explaining in detail why the outage occurred, and how could we avoid it in the future, and of course the report would need to be read in a lengthy meeting. Multihoming and putting our own network on a better provider with better peering agreements were always shot down, so this whole thing was repeated every few weeks. I liked the options of not answering the phone any more, and investigating the problems after they were already resolved. It made life a lot simpler.:)
Interspersed throughout should be questions that judge how well they'll fit into your company culture and how easily they can learn new things or deal with new and unexpected situations. For these, concentrate on asking about past experiences of that type rather than asking canned hypotheticals that everyone has already seen on the Internet and knows how to answer.
I love the canned questions. They're always funny. I've been interviewed by nontechnical people, who have a few random questions written down to ask. They're always thrown when I don't just give the canned answer, but a quick speech on the topic.
Question: "What is BGP?"
The right answer: "Border Gateway Protocol".
My answer: "The Border Gateway Protocol, which us used most frequently by internet routers, and can be used to a client site for multihomed environments. It is the standard for Internet connectivity providers. Problems with BGP include route oscillation, also known as route flapping; sub-optimal routing; and extended outages during routing table convergence."
They usually just say something like "ummm, ya, border gateway protocol, that's right.":)
I wish they wouldn't waste my time interviewing with a non-technical person. Then again as an interviewer, I didn't like interviewing non-technical people who hadn't been filtered by someone else first.
Actually, avoiding someone because they have a cert is a bad idea. When I've been in a position which included hiring decisions, practical experience weighed a lot. Certs, regardless if they're a Brainbench cert, all the way to a college diploma, weigh absolutely nothing in my decision making process. They can't weigh negatively. Some good people have gone and gotten a fist full of certs, either because a previous employer sponsored it, or they were feeling independently wealthy and got them on their own. You definitely can't let them weigh positively though, a lot of idiots have managed their way through various schools, and can't answer simple real world questions, because they only learned enough from the book to pass the test.
On certs, unfortunately I have to bring up a car analogy. My girlfriend worked as a service manager for a few auto manufacturers. One was being pissy about requiring ASE certifications for their mechanics. To show what kind of joke the certs are, she studied for the braking system test, and got her ASE certification in that. She's never turned a wrench in her life, and can't actually do the work.
I was signing up with a head hunter. The manager was being a dick during the interview, basically saying I knew nothing and my resume was a lie. Finally he said I had to score "Master" level with Brainbench on at least two of three areas of knowledge that they required. He told me over 90% of the candidates were immediately disqualified because they couldn't even get a good score. I took two of the test, and scored master, and he wouldn't give me the third one. Even still, they never found me a job.
I went on with the Brainbench tests, taking them whenever I was bored. I scored "Master" level on 11 tests, and got 4 "Certified Job Roles". I took the Solaris one, and figured I'd fail miserably. I hadn't touched a Sun box in years. I got 4.01 of 5 which put me in the 98th percentile, and was enough to score me in the "Master" level. I guess I remember some stuff after years of not touching a Solaris box.:)
The world of certs would be great if it were to take experienced people, and test them to verify that they are competent in their field. Unfortunately, there's an entire industry built on training people to pass the test. Rarely is the knowledge retained much beyond that, except for the people who are really interested in the field, and practice well beyond the testing.
In the past, I've asked people to send me sample code. Some was protected by various agreements, so they sent me snippets that were enough for me to review their coding style, without giving away the details of their work.
The clincher is always the interview. I don't just sit down and talk with someone about what they know, and let them brag without anything supporting it. Ask real world questions. Have them write a few lines of code to do something on a piece of paper or whiteboard. It doesn't have to be syntactically perfect, but it has to be close.
My interviews were more for sysadmin stuff, so having them describe what they'd do for a task can be very revealing. Like a question like this:
"The COO has come to you, because no one else is available. The CEO is flipping out. There's a server on the network running some common variety of Linux. Transfer rates from it to any other machine are very slow, regardless of the protocol. i.e., http, ftp, rsync, samba are all slow. What do you do?"
I'll have established what the real fault is in my head, and give them appropriate answers to what they say to do.
It's a pretty simple one to solve, or at least bring to a point where authorized assistance is needed. I've gotten all kinds of answers to that one. Some answer "call someone else for assistance", which I tell them the someone else is unavailable. Some just reboot it, which isn't a valid answer as a first step. I tell them "No, it's a production machine. You can't." Some actually start pinging, checking ifconfig for errors on the interface, and check the interface duplex. Obviously, the last set of answers is the right one.
Adding extra stress is always useful, if they don't get it right off. A little yelling and table pounding is enough for that. "The COO is demanding an answer now! [pounding on table] We're losing money! If you don't get this fixed, it's your job on the line!" Some people do fine. Some just stare at you dumbfounded without a clue if they don't have Google in front of them.
When it's my interview, and my decision (it's not always both), I evaluate how good the answers were, even if they were wrong. Did the guy show a competent level of knowledge, or does he just think he can do the job and has no clue. A few will float to the top, and quite a few get put to the bottom of the list.
Take all of them. Some will give you wild hallucinations about an impossible future and extreme paranoia. Some will make you passive and very compliant to the reality you are in. What could possibly go wrong with that combination?
Well, the decision to jump wouldn't be all that hard. Eventually the balloon will pop. Do you want to come down in a controlled manner, or wrapped up in the debris that was your ascent vehicle?
Myself, I like to fly. I can't see myself stepping out of a perfectly good aircraft. More importantly, I wouldn't step into one that goes straight up and is designed to have a catastrophic failure just after I leave it.:)
Speed of sound at sea level, on a standard day, at standard pressure, is 1125 ft/s or 767 miles per hour.
According to this calculator, the speed of sound would be 684mph. Lacking the pressure to create a sonic boom, it was survivable in an atmospheric suit, so he could tolerate the lack of pressure and oxygen. I've watched the original video quite a few times, and that suit didn't appear to be constructed for much more than to provide pressure, oxygen, and temperature protection. Well, except for his leaking glove.
NASA had already looked into the possibility of reentry from a geosynchronous orbit in little more than a padded bag with a parachute. That was back in the late 1960's or early 1970's, if I recall correctly. From what I read on that, the idea was dropped due to the duration of the fall. It would take nerves of steel and blind faith the whole way down, which would take a long time.
There are several problems with astronauts coming back down in such a manner. First, they'd need 0 ground speed, or at least very close to it. The ISS has an orbital velocity of roughly 17,087 mph. The US Space Shuttle has/had an orbital velocity of roughly 17,500 mph.
Anything hitting the atmosphere at those kinds of speeds will induce a huge amount of heat. If it were possible to bleed off the ground speed first, it could be possible. Otherwise, the returning astronaut would be little more than a short lived shooting star.
Astronauts don't have the luxury of falling over their own nation, or more importantly, a populated area where they could be recovered quickly. A drop in a random location somewhere on the planet could take days or weeks before a rescue team could be there to pick them up. So in an emergency, they may not die in space, but they could die on the ground for dehydration, starvation, drowning, or expiration due to the elements (how long can you live in just a pressure suit in the Antarctic or the Sahara?)
I didn't say it was a smart move. Well, unless they hoped that IBM would give in and just pay, rather than keeping a small percentage of their legal team tied up on a stupid case.
Not that it's remotely close, but I was in a very minor car accident, where the other guy was clearly at fault. The police ticketed him. My insurance company agreed. He didn't have insurance. He threatened to sue for $300. His real damages were about $10. Rather than bother with the legal paperwork, they just paid him to go away. The insurance adjuster said it wouldn't count against me in any way (and it didn't). The guy had a history of getting into minor accidents and threatening to sue. Apparently he did it for a living.
That's a common strategy in court. You drag things on as long as possible, hoping the other side will just settle rather than pay the legal expenses. It becomes a cost benefit review. Is it cheaper to just pay, or pay the lawyers and risk losing in court. It's a dirty game, but a very popular one.
That's why they invented roller bags. When I'm traveling, the laptop goes everywhere with me, or is safely locked away. Leaving your laptop in a car isn't the best idea. It (obviously) looked like a good target, and was therefore stolen.
People will break into cars for almost anything that they consider of value. Someone busted out the window of my car once, to steal about $3 in loose change, and the $75 radio. My auto insurance covered both the window and the radio, but wouldn't pay for the loose change. That taught me to park where lots of people can see my car, versus the nice spot in the shade where my car wouldn't turn into an oven while I was working.
This was the first time I had a chance to see any of their "evidence". How exactly did this make it all the way to court? Oh ya, some greedy patent trolls. Well, now my lack of interest is complete, I can go on being bored with this topic.
Cash may be outdated, but it's really hard for someone to duplicate your cash and make it disappear from your pocket. Credit cards on the other hand, are trivial to duplicate, and if you know the mark is traveling, it's easy to get away with charges for days before they find out there is any fraudulent activity.
Cash is hard to lose, if you maintain proper control over it. If you aren't advertising that you carry large amounts of cash, random people won't know you have it. The physical risk of being liberated of the cash is then just as good as the physical risk of being liberated of your credit cards. And of course we shouldn't forget about the evidence trail that using credit cards exclusively gives. Using a card on a regular basis lets the issuing bank know what your purchasing trends are. It may require a warrant for law enforcement to acquire the evidence, but the banks are more than happy to take advantage of the information for their own purposes.
You should make friends with some good DB folks.:) I know my early database work was rough, but it improved over time, both through my own mistakes, and learning everything I could from others.
I mentioned above (which you may not have noticed) to go pick up some O'Reilly books. They're a good reference, and have some very good information in them.
With practice, you'll see what works, and what doesn't. And some things we just screw up. Slashdot had an error several years ago, where an auto-incrementing number exceeded the size for the column. I believe it was the column for the comment id was too small.
People sometimes look at me like I'm nuts when I use a bigint for an auto-incrementing column. Will it hurt anything to do it? Not really. Will it matter if the application doesn't get a lot of use? Nope. Will it save my ass if the application becomes really big? Definitely. I worked for a big site for a while, so it wasn't unreasonable for pesky things like comments to end up having millions of records. Sometimes they did. Sometimes they didn't. Sometimes I'd have to fix or tweak stuff down the line. Sometimes it's something as stupid as "what do you mean there's no index on that?":)
Actually, that's rarely the case. Even as Director, or even VP, you usually can't just say "I want to hire someone", and then go do it. Does your budget allow for hiring another employee? Would another employee on staff change the company position for taxes, insurance, or regulatory concerns?
A decision such as that usually goes up to the COO or CEO (depending on the company structure). Upon tentative approval, it would go to accounting to ensure the budget is available to sustain the prospective employee, and then over to human resources.
It can be that a Director or VP already has the authorization to add employees, which simply means it's already gone through the other steps, and then he or she can hire as needed. It would be very reasonable to believe that a Director or VP would have authorization to hire X employees as needed.
Maybe your company works in such a loose manner that the brass can hire and fire at will, but a well run organization will actually plan for such changes.
O'Reilly books are your friend. The "... in a Nutshell" books are a good place to start, and then proceed into the more advanced books. They have 25 titles related to MySQL and 53 titles related to Microsoft SQL. There are usually a few to browse through at the large chain book stores.
I'll pick on anyone, I'm an equal opportunity offender. I'll pick on fat people because they are fat. There are genetic reasons to be overweight, but for the majority of people, it is not a genetic disorder. It is a decision. They decide to eat more than they can burn, and the excess is stored. If you're overweight, and eat like you aren't, you will find that your weight will drop. It's as simple as that. The part that isn't easy is that modern society makes food readily available to us, and we have the luxury of not needing o be physically active to replenish our food supply.
I was really skinny working in a computer repair shop. I didn't sit all day, because I was walking between at least 3 repair stations constantly, to the parts room, and to the front desk to talk to customers. When I got a desk job, my walking was reduced to almost nothing in comparison. My diet remained the same, and I gained weight. I changed my eating habits. I exercised more, before a car accident that has left me with chronic pain. Even still, I remain active. Friends tell me not to do things because I'll hurt myself (i.e., lifting heavy things), and I tell them that I won't stop doing things until I hurt too much to do it.
Even chronic pain isn't an excuse to not be active. Last weekend, I sent to a friends place to fix the brakes on his car. I only brought hand tools and my floor jack (no air tools). When I was finishing up, I hurt my back again tightening down the lug nuts on the last wheel, but I still worked through and cleaned up. The floor jack weighs 75 pounds, but I still got it into the back of my car to take home. Of course, I ended up laying on his living room floor for about an hour before the meds kicked in (prescribed as-needed). So I'll be in pain for a few days, and then I'll get back into doing physical work. Until then, I'm comfortably propped up in bed, not eating very much, and getting computer work done.
Both IMDB and Wikipedia list him to be 6'2". While Wikipedia can be questionable, IMDB is pretty accurate with their information, often maintained by the celebrity (or their agent).
I agree. If you need substantial content, like to fill what should be news story bodies, Lorem Ipsum is perfect.
When I'm testing things, and I'm looking at functionality over volume of filler, I'll use some informative yet useless information. For example a news story may read "This is a test title" and "This is the test body". No harm, no foul, and when something gets left behind for the bosses (or general public) to see,it won't result in finding yourself unemployed.
A lot of times, when I'm working on someone's web site, and they haven't given me content for say their front page, I'll just put "Put something warm and friendly here." Occasionally (very occasionally) I'll put something funny in, but not so much that it'd cost me a job. I worked at a place, way back in the beginning of the popularity of the Internet. The programmers for the billing system had an impossible to reach if statement which said something like "You'll never fucking see this." Well, after a while, it was seen. Customers were less than happy, and were more than happy to contact the CEO directly. Heads rolled on that one.
I expect that my customers will look at my work in progress. I encourage it, so I can get their feedback as it goes. It's much better to find out they don't like something in the beginning, rather than when you've worked on the project for months and are complete. If they see "you should have stuff here about your company", that's much better than nothing at all. For the sake of filling the space, Lorem Ipsum is much better.
What a novel idea. Too bad there isn't a well established system for taking your ideas and protecting them from being stolen by others for use in their own products.
Slashdot Mirror
Well, on the first part, it's a difference between "I don't know", or giving a mostly right answer from memory. If you have to go to Google to find out what program to use to view interface stats (for a SysAdmin), or look up the syntax for say "include" for C, then that's not exactly the candidate you want. Partially or mostly correct answers are good answers. Completely and utterly wrong answers are ... well ... wrong.
Some obscure things aren't fair game for interviews. How do you change an interface configuration on a Cisco 2980G? That's a trick question unless the person really knows Cisco.
And of course, asking for definitions of internal use abbreviations and internal policy is just impossible. One place I was at had an acronym for almost everything, and there were other internally used codes, and none of them were documented. Well, pretty much nothing was documented. It took a couple weeks to find out what most the internal use acronyms were. It took the first week to find all the servers, and another month to find out what their purpose was, and even longer to actually get access to them so I could work on them. It was my job to work on them.
For the sake of the scenario, the machine is in a datacenter, in a rack with everything labeled, and you are sitting at a desk where you have both any tools required on your desktop, as well as nearby access to the physical machines. I used variations of that one frequently, but it was tailored for the persons claimed skills and the job role they were applying for. It's silly to ask a DBA or web programmer to debug a networking issue. :)
Actually, I never had anyone walk out. Since it was presented as roleplay of a real world situation, and I'd explain the details of the situation calmly and clearly, it was evident that it was an extreme example.
But hey, if you can't handle an environment with occasional high stress, I wouldn't want you there. That's the last thing I'd ever want is a stressful situation to come up, and an employee walking out because it was "too hard".
As I've found, there's always some degree of yelling in high dollar production environments, especially where a few minutes of outage can be the difference between a highly profitable day, or a huge loss. Hell, people freak out when a Windows file share stops working, or Outlook eats their mail. I've never seen a warm fuzzy workplace that involved a production environment and/or deadlines, that didn't have the occasional loud emotional moments.
When I've interviewed, the yelling is only a small part, during the roleplay part. The rest of it was a fun conversation with plenty of joking around. If they can't laugh at my jokes, they won't be very entertaining to work with. :)
The last place I worked at, it was unfortunately an every day occurrence. It was always something, which sometimes included outages at tier 1 providers that we were not directly connected to.
"Oh my god, this guy in [insert random city] called saying he can't reach us! Fix it now!"
[traceroute to see where the problem may be]
"There's an outage on [insert another provider]. We'll have to wait for them to fix it."
"No, call them now! Get it fixed!"
"We're not their customer, I can't call them. They'd just hang up on me."
"Do it anyways, I don't care, get it fixed!"
[calls 3rd party provider, and gets hung up on]
"They hung up on me."
"Call [some sales minion] at [our provider]! He'll get it fixed."
[calls sales minion, gets told he can't do anything]
You see where this goes. About 30 minutes of people running around like idiots, and suddenly like a freakin' miracle the 3rd party provider fixes their problem and the world is saved yet again. Of course, they always want a written report explaining in detail why the outage occurred, and how could we avoid it in the future, and of course the report would need to be read in a lengthy meeting. Multihoming and putting our own network on a better provider with better peering agreements were always shot down, so this whole thing was repeated every few weeks. I liked the options of not answering the phone any more, and investigating the problems after they were already resolved. It made life a lot simpler. :)
I love the canned questions. They're always funny. I've been interviewed by nontechnical people, who have a few random questions written down to ask. They're always thrown when I don't just give the canned answer, but a quick speech on the topic.
Question: "What is BGP?"
The right answer: "Border Gateway Protocol".
My answer: "The Border Gateway Protocol, which us used most frequently by internet routers, and can be used to a client site for multihomed environments. It is the standard for Internet connectivity providers. Problems with BGP include route oscillation, also known as route flapping; sub-optimal routing; and extended outages during routing table convergence."
They usually just say something like "ummm, ya, border gateway protocol, that's right." :)
I wish they wouldn't waste my time interviewing with a non-technical person. Then again as an interviewer, I didn't like interviewing non-technical people who hadn't been filtered by someone else first.
Actually, avoiding someone because they have a cert is a bad idea. When I've been in a position which included hiring decisions, practical experience weighed a lot. Certs, regardless if they're a Brainbench cert, all the way to a college diploma, weigh absolutely nothing in my decision making process. They can't weigh negatively. Some good people have gone and gotten a fist full of certs, either because a previous employer sponsored it, or they were feeling independently wealthy and got them on their own. You definitely can't let them weigh positively though, a lot of idiots have managed their way through various schools, and can't answer simple real world questions, because they only learned enough from the book to pass the test.
On certs, unfortunately I have to bring up a car analogy. My girlfriend worked as a service manager for a few auto manufacturers. One was being pissy about requiring ASE certifications for their mechanics. To show what kind of joke the certs are, she studied for the braking system test, and got her ASE certification in that. She's never turned a wrench in her life, and can't actually do the work.
I was signing up with a head hunter. The manager was being a dick during the interview, basically saying I knew nothing and my resume was a lie. Finally he said I had to score "Master" level with Brainbench on at least two of three areas of knowledge that they required. He told me over 90% of the candidates were immediately disqualified because they couldn't even get a good score. I took two of the test, and scored master, and he wouldn't give me the third one. Even still, they never found me a job.
I went on with the Brainbench tests, taking them whenever I was bored. I scored "Master" level on 11 tests, and got 4 "Certified Job Roles". I took the Solaris one, and figured I'd fail miserably. I hadn't touched a Sun box in years. I got 4.01 of 5 which put me in the 98th percentile, and was enough to score me in the "Master" level. I guess I remember some stuff after years of not touching a Solaris box. :)
The world of certs would be great if it were to take experienced people, and test them to verify that they are competent in their field. Unfortunately, there's an entire industry built on training people to pass the test. Rarely is the knowledge retained much beyond that, except for the people who are really interested in the field, and practice well beyond the testing.
In the past, I've asked people to send me sample code. Some was protected by various agreements, so they sent me snippets that were enough for me to review their coding style, without giving away the details of their work.
The clincher is always the interview. I don't just sit down and talk with someone about what they know, and let them brag without anything supporting it. Ask real world questions. Have them write a few lines of code to do something on a piece of paper or whiteboard. It doesn't have to be syntactically perfect, but it has to be close.
My interviews were more for sysadmin stuff, so having them describe what they'd do for a task can be very revealing. Like a question like this:
"The COO has come to you, because no one else is available. The CEO is flipping out. There's a server on the network running some common variety of Linux. Transfer rates from it to any other machine are very slow, regardless of the protocol. i.e., http, ftp, rsync, samba are all slow. What do you do?"
I'll have established what the real fault is in my head, and give them appropriate answers to what they say to do.
It's a pretty simple one to solve, or at least bring to a point where authorized assistance is needed. I've gotten all kinds of answers to that one. Some answer "call someone else for assistance", which I tell them the someone else is unavailable. Some just reboot it, which isn't a valid answer as a first step. I tell them "No, it's a production machine. You can't." Some actually start pinging, checking ifconfig for errors on the interface, and check the interface duplex. Obviously, the last set of answers is the right one.
Adding extra stress is always useful, if they don't get it right off. A little yelling and table pounding is enough for that. "The COO is demanding an answer now! [pounding on table] We're losing money! If you don't get this fixed, it's your job on the line!" Some people do fine. Some just stare at you dumbfounded without a clue if they don't have Google in front of them.
When it's my interview, and my decision (it's not always both), I evaluate how good the answers were, even if they were wrong. Did the guy show a competent level of knowledge, or does he just think he can do the job and has no clue. A few will float to the top, and quite a few get put to the bottom of the list.
Take all of them. Some will give you wild hallucinations about an impossible future and extreme paranoia. Some will make you passive and very compliant to the reality you are in. What could possibly go wrong with that combination?
[/me takes a fist full from the pill jar]
Well, the decision to jump wouldn't be all that hard. Eventually the balloon will pop. Do you want to come down in a controlled manner, or wrapped up in the debris that was your ascent vehicle?
Myself, I like to fly. I can't see myself stepping out of a perfectly good aircraft. More importantly, I wouldn't step into one that goes straight up and is designed to have a catastrophic failure just after I leave it. :)
To reply out of order....
Speed of sound at sea level, on a standard day, at standard pressure, is 1125 ft/s or 767 miles per hour.
According to this calculator, the speed of sound would be 684mph. Lacking the pressure to create a sonic boom, it was survivable in an atmospheric suit, so he could tolerate the lack of pressure and oxygen. I've watched the original video quite a few times, and that suit didn't appear to be constructed for much more than to provide pressure, oxygen, and temperature protection. Well, except for his leaking glove.
NASA had already looked into the possibility of reentry from a geosynchronous orbit in little more than a padded bag with a parachute. That was back in the late 1960's or early 1970's, if I recall correctly. From what I read on that, the idea was dropped due to the duration of the fall. It would take nerves of steel and blind faith the whole way down, which would take a long time.
There are several problems with astronauts coming back down in such a manner. First, they'd need 0 ground speed, or at least very close to it. The ISS has an orbital velocity of roughly 17,087 mph. The US Space Shuttle has/had an orbital velocity of roughly 17,500 mph.
Anything hitting the atmosphere at those kinds of speeds will induce a huge amount of heat. If it were possible to bleed off the ground speed first, it could be possible. Otherwise, the returning astronaut would be little more than a short lived shooting star.
Astronauts don't have the luxury of falling over their own nation, or more importantly, a populated area where they could be recovered quickly. A drop in a random location somewhere on the planet could take days or weeks before a rescue team could be there to pick them up. So in an emergency, they may not die in space, but they could die on the ground for dehydration, starvation, drowning, or expiration due to the elements (how long can you live in just a pressure suit in the Antarctic or the Sahara?)
I didn't say it was a smart move. Well, unless they hoped that IBM would give in and just pay, rather than keeping a small percentage of their legal team tied up on a stupid case.
Not that it's remotely close, but I was in a very minor car accident, where the other guy was clearly at fault. The police ticketed him. My insurance company agreed. He didn't have insurance. He threatened to sue for $300. His real damages were about $10. Rather than bother with the legal paperwork, they just paid him to go away. The insurance adjuster said it wouldn't count against me in any way (and it didn't). The guy had a history of getting into minor accidents and threatening to sue. Apparently he did it for a living.
That's a common strategy in court. You drag things on as long as possible, hoping the other side will just settle rather than pay the legal expenses. It becomes a cost benefit review. Is it cheaper to just pay, or pay the lawyers and risk losing in court. It's a dirty game, but a very popular one.
They're not hard to find, if you look around a little.
That's why they invented roller bags. When I'm traveling, the laptop goes everywhere with me, or is safely locked away. Leaving your laptop in a car isn't the best idea. It (obviously) looked like a good target, and was therefore stolen.
People will break into cars for almost anything that they consider of value. Someone busted out the window of my car once, to steal about $3 in loose change, and the $75 radio. My auto insurance covered both the window and the radio, but wouldn't pay for the loose change. That taught me to park where lots of people can see my car, versus the nice spot in the shade where my car wouldn't turn into an oven while I was working.
Slashdot tends to eat anything that looks like an HTML tag. I'm sure when he put it in, it said:
This was the first time I had a chance to see any of their "evidence". How exactly did this make it all the way to court? Oh ya, some greedy patent trolls. Well, now my lack of interest is complete, I can go on being bored with this topic.
I've found cash works a lot better for gray market purchases too. :)
Cash may be outdated, but it's really hard for someone to duplicate your cash and make it disappear from your pocket. Credit cards on the other hand, are trivial to duplicate, and if you know the mark is traveling, it's easy to get away with charges for days before they find out there is any fraudulent activity.
Cash is hard to lose, if you maintain proper control over it. If you aren't advertising that you carry large amounts of cash, random people won't know you have it. The physical risk of being liberated of the cash is then just as good as the physical risk of being liberated of your credit cards. And of course we shouldn't forget about the evidence trail that using credit cards exclusively gives. Using a card on a regular basis lets the issuing bank know what your purchasing trends are. It may require a warrant for law enforcement to acquire the evidence, but the banks are more than happy to take advantage of the information for their own purposes.
You should make friends with some good DB folks. :) I know my early database work was rough, but it improved over time, both through my own mistakes, and learning everything I could from others.
I mentioned above (which you may not have noticed) to go pick up some O'Reilly books. They're a good reference, and have some very good information in them.
With practice, you'll see what works, and what doesn't. And some things we just screw up. Slashdot had an error several years ago, where an auto-incrementing number exceeded the size for the column. I believe it was the column for the comment id was too small.
People sometimes look at me like I'm nuts when I use a bigint for an auto-incrementing column. Will it hurt anything to do it? Not really. Will it matter if the application doesn't get a lot of use? Nope. Will it save my ass if the application becomes really big? Definitely. I worked for a big site for a while, so it wasn't unreasonable for pesky things like comments to end up having millions of records. Sometimes they did. Sometimes they didn't. Sometimes I'd have to fix or tweak stuff down the line. Sometimes it's something as stupid as "what do you mean there's no index on that?" :)
Actually, that's rarely the case. Even as Director, or even VP, you usually can't just say "I want to hire someone", and then go do it. Does your budget allow for hiring another employee? Would another employee on staff change the company position for taxes, insurance, or regulatory concerns?
A decision such as that usually goes up to the COO or CEO (depending on the company structure). Upon tentative approval, it would go to accounting to ensure the budget is available to sustain the prospective employee, and then over to human resources.
It can be that a Director or VP already has the authorization to add employees, which simply means it's already gone through the other steps, and then he or she can hire as needed. It would be very reasonable to believe that a Director or VP would have authorization to hire X employees as needed.
Maybe your company works in such a loose manner that the brass can hire and fire at will, but a well run organization will actually plan for such changes.
O'Reilly books are your friend. The "... in a Nutshell" books are a good place to start, and then proceed into the more advanced books. They have 25 titles related to MySQL and 53 titles related to Microsoft SQL. There are usually a few to browse through at the large chain book stores.
I'll pick on anyone, I'm an equal opportunity offender. I'll pick on fat people because they are fat. There are genetic reasons to be overweight, but for the majority of people, it is not a genetic disorder. It is a decision. They decide to eat more than they can burn, and the excess is stored. If you're overweight, and eat like you aren't, you will find that your weight will drop. It's as simple as that. The part that isn't easy is that modern society makes food readily available to us, and we have the luxury of not needing o be physically active to replenish our food supply.
I was really skinny working in a computer repair shop. I didn't sit all day, because I was walking between at least 3 repair stations constantly, to the parts room, and to the front desk to talk to customers. When I got a desk job, my walking was reduced to almost nothing in comparison. My diet remained the same, and I gained weight. I changed my eating habits. I exercised more, before a car accident that has left me with chronic pain. Even still, I remain active. Friends tell me not to do things because I'll hurt myself (i.e., lifting heavy things), and I tell them that I won't stop doing things until I hurt too much to do it.
Even chronic pain isn't an excuse to not be active. Last weekend, I sent to a friends place to fix the brakes on his car. I only brought hand tools and my floor jack (no air tools). When I was finishing up, I hurt my back again tightening down the lug nuts on the last wheel, but I still worked through and cleaned up. The floor jack weighs 75 pounds, but I still got it into the back of my car to take home. Of course, I ended up laying on his living room floor for about an hour before the meds kicked in (prescribed as-needed). So I'll be in pain for a few days, and then I'll get back into doing physical work. Until then, I'm comfortably propped up in bed, not eating very much, and getting computer work done.
Both IMDB and Wikipedia list him to be 6'2". While Wikipedia can be questionable, IMDB is pretty accurate with their information, often maintained by the celebrity (or their agent).
I agree. If you need substantial content, like to fill what should be news story bodies, Lorem Ipsum is perfect.
When I'm testing things, and I'm looking at functionality over volume of filler, I'll use some informative yet useless information. For example a news story may read "This is a test title" and "This is the test body". No harm, no foul, and when something gets left behind for the bosses (or general public) to see,it won't result in finding yourself unemployed.
A lot of times, when I'm working on someone's web site, and they haven't given me content for say their front page, I'll just put "Put something warm and friendly here." Occasionally (very occasionally) I'll put something funny in, but not so much that it'd cost me a job. I worked at a place, way back in the beginning of the popularity of the Internet. The programmers for the billing system had an impossible to reach if statement which said something like "You'll never fucking see this." Well, after a while, it was seen. Customers were less than happy, and were more than happy to contact the CEO directly. Heads rolled on that one.
I expect that my customers will look at my work in progress. I encourage it, so I can get their feedback as it goes. It's much better to find out they don't like something in the beginning, rather than when you've worked on the project for months and are complete. If they see "you should have stuff here about your company", that's much better than nothing at all. For the sake of filling the space, Lorem Ipsum is much better.
What a novel idea. Too bad there isn't a well established system for taking your ideas and protecting them from being stolen by others for use in their own products.