That's the reason you adopt the CYA approach unless you absolutely know the manager in question. If it's going to fail, email people to say it's going to fail, together with a large list of reasons and supporting evidence, and keep those emails. Even better, get co-workers to provide similar estimates, so he can't claim it's just you.
If your estimates turn out to be right and your manager's turn out to be wrong, where's his defence? The answer then is to wave those emails at him and tell him you told him so (politely, unless he stops being polite of course). If that escalates it to disciplinary, fine - walk up the layers of management until you find a manager where the buck stops. And use your right to have another person in the room with you, if you think they might try to lean on you when you're on your own. And if there genuinely is no-one in the entire company with as much morals as God gave a weasel, then you're fucked anyway, so why are you there?
On the plus side, you then have a 100% watertight case for constructive dismissal, so look on the bright side.;-)
Engineers *with experience* are good at estimation. By the time you've got that experience, chances are you've been in the business 5-10 years and you've got the seniority to not have the kind of grief the OP had.
My personal experience of myself and everyone else I've ever worked with though, for the last 7 years since uni working in embedded software, is that *everyone* sucks initially. Without exception. Until you get into a job, you're not used to 37.5 hours *and* making deadlines. Need to make a uni assignment? Work into the night, no worries, and make up the sleep the next couple of weeks. No student anywhere (unless they're some kind of freak;-) counts the hours they spend on a project.
That all kind of falls apart at work, where management frowns on employees working themselves into the ground short-term and working less productively overall. It also runs into the notorious over-optimism of young engineers, who assume that because they've solved all tasks quickly so far, that every other task they'll see in the next couple of years will be equally easy. Throw a 200-page spec at them, and expect a response of "yeah, 6-8 weeks, no worries". And finally, they forget that docs and testing are also part of the job - typically they never had to do that at uni, so they only count the coding time. The job of the manager and/or senior engineer is to inject rationality into estimates from people who can't estimate themselves.
Basically, estimating is like driving a car - the more you do it, the better you get. Initially you don't know how, and basing project quotes on estimates from a new grad is like putting a 16-year-old into an F1 car and saying "go for it" - the crash is inevitable. A smart manager will get estimates from everyone (so they all feel equally important), factor in reliability and how long *they* think it'll take (and how long their senior engineer thinks), and use those numbers instead. A *really* smart manager will monitor how long it actually took, so his team can find out what their over/under-estimating tendencies are, and improve in future. Sadly there aren't enough of the former, and even less of the latter.;-/
As you say though, the problem is managers who say "oh no, that's way too long, cut it by 75%". If they have a basis for saying that, then fine - some inexperienced engineers swing the other way and estimate months for a 2-week job. But if they've no technical understanding then they're just as inexperienced as a green engineer, and just as much of a liability.
Suppose you're spending $1billion, and you say "hey, we've developed LCDs, velcro and memory foam". But of that $1billion, maybe $100million went into each of those three. So what happened to the other $700million? Answer: used for non-novel work to get a rocket (and its occupants) up and down.
So if what you really want is the ancillary benefits, you're better to throw the whole $1billion at technologies that give you the ancillary benefits, instead of blowing it on things that don't advance knowledge.
Excuse me? Is this the same game of tennis that already has automated line calls and net calls?
All games will use technology that's proven and effective, but it always needs a human on top of it to overrule obvious errors. Football (soccer) already has video replays to check on fouls. Cricket has the "third umpire", again for video replays.
But it can't affect how the game works. In the case of tennis and baseball, I suspect the special balls to make this work will behave differently to "traditional" ones.
They'll definitely try - that's their job. Your job is to tell them that it isn't possible. And make sure that it's documented in an email that it isn't possible. If they tell you to do both, send an email back (and CC'd to boss's boss) saying that it isn't possible.
There's a difference between taking care of the customer, finding out what they want and all that, and going out and giving them freebies. Obviously the customer will love you if you give them freebies, but *your* company will crash and burn. And guess what, it's *your* company that pays you.
Estimating the amount of work is a technical decision. Allowing for contingency is a management decision. If it's a fixed-price contract (as most are) rather than time and materials, the estimate MUST include a multiplier for contingency. Most projects will come in on time, some will spill over, and none will come in in less time, so overall you lose. Hence contingency to allow for that and still let the firm make a profit.
Also remember that engineers are *notoriously* bad at estimating (see the famous estimates for MS implementing WinNT for an example). Unless an engineer has a proven track record at estimating 100% accurately *and* knows 100% of the detail about the system, doubling the estimate is not a bad plan to allow for contingency.
No it doesn't. It has a window that appears, but only the terminally incompetent would call that piece of shite an "interface", because it isn't actually possible to do anything with it. Unless they've made *major* strides in the last 3 months, of course, in which case my apologies...
I'm afraid you need more hardware experience...:-/
That's certainly fast enough to do "output = -input;". Your problem though is converting analogue voltage to "input", reading "input", writing "output" and converting "output" to analogue voltage.
The *best* soundcards currently available are 96kHz. Nyquist says that you can only reproduce a frequency of 0.5 x sample rate. But that's theoretical-only - to get a decent approximation takes you to more like 0.1 x sample rate. Which means you can accurately reproduce sounds up to 9.6kHz. Probably OK for fixed noises like motors, but not much good for white noise.
But even then, you've got another problem of time delay. The best real-time digital sound processor takes 1 sample time to read data and 1 sample time to process it. (There's also write time, but you can combine that with processing time, if we're assuming the theoretically-best system.) So you've got 2 samples delay, which is 0.02ms. That's acceptable. PCs though typically have a time delay of around 2ms in reading data (and that's on a *good* system). This means that any sound you output will be 2ms behind. Combining them gives a resultant noise at 500Hz. You can use prediction to reduce that, but the limit of the time delay means you'll never be able to noise-cancel at more than 500Hz.
In other words, using a PC for noise-cancelling is useless, and the OP is a fucking dipshit.
In retaliation, I'm tempted to post an "Ask Slashdot" for "Why can't we build space elevators today? After all, we only need a long rope, and the US wire-making industry churns out miles of steel cable every year. That should be fine, shouldn't it?";-)
Except that the producer pays for distributing physical junk mail. The kicker with spam is that the producer pays ~zilch, whereas the receiver (either the end-user if on a metered bandwidth/time system, or their ISP and then indirectly all customers if on an unmetered system) is forced to pay for stuff they don't want.
IIRC, Gimp assumes a certain mouse-over selection behaviour from your WM to work. Since that selection behaviour is optional in Linux, that means that the flaws in the Win32 port will also be present in Linux, no?
The "American abroad" thing has nothing to do with being white or male, and everything to do with country of origin. A black Westerner going to Africa will be seen as American/British/whatever by Africans.
As far as the shaved-head thing goes, are you not aware of the existence of skinheads? Since most shaven-headed whites for the last 30-40 years have been white supremacists, I don't know why you're surprised.
I remember those days too - and they're still with us now if you're doing embedded software...
As for the optimisation, as you can see from the bytecode, it depends 100% on your processor supporting instructions which speed this up. If you're on a processor that doesn't have this built in, you're screwed.
Many people consider this to be a good thing - I know I do. It does depend on personal preferences, but I know if I've got three editor open and I'm typing, I want text to keep going to the one I last selected, even if I happen to knock my mouse while I'm putting my coffee cup down.
More to the point, this is optional in Linux too, depending on your WM. If any software author says "I require WM XYZ for my software to work effectively and it'll be hamstrung on anything else", then I can point you out an author who doesn't give a shit about making something for other people to use.
and a taskbar that didn't properly ignore Gimp's dialog boxes.
This is 100% a fault of the coder, and not a fault of the Windows taskbar. This is not a difficult thing to implement, you just have to do it right.
Yes, Gimp was ported from X-Windows. These flaws indicate that the port is only at a beta stage - it works, but it's not ready for the big-time yet. Another application that isn't ready for the mass-market "Linux-on-the-desktop" aim.
But even allowing for the flaws in the port, the user interface for Gimp simply is not intuitive in the same way that commercial Windows drawing packages are.
How about thinking *inside* the box? By which I mean, how big is a mobile/PDA?
The big problem is the screen. Mobiles typically have screens about 2"x1.5". You really can't play anything more sophisticated than card games on it. Platformers are just about tolerable, but they don't really work. There simply isn't the space to make anything work. Even suppose mobiles get screens the size of a PDA, so maybe 4"x3" - you still can't do more than simple card games, puzzles or whatever.
Let's think ahead a bit now. You can't make the box physically bigger than this or it won't fit in a pocket, so a mobile *can't* be bigger than that. Let's even suppose someone invents a cunning mechanism that folds out 6 screens from inside there (each screen being 0.25" thick - a mobile more than 1.5" thick is too big to fit in a pocket, and a screen thinner than 0.25" will be too fragile to survive). Now we have found the absolute maximum screen size to be 8"x9". You could just about play reasonable games on that - you're not going to get full immersion, but modern games will stand up to that kind of thing.
But until that day comes and someone invents this mythical fold-out screen, games on mobiles will suck, and will continue to suck, simply because the display hardware is not there.
I suggest you bring that analogy up with US gun owners who are currently being asked to fit handprint recognition to guns. Ask them how practical that is, for how much extra safety.
I really don't mind people using code that has built-in error-trapping. If you're using OO code anyway, then by all means use CString and don't worry about how much array is needed underneath the OO abstraction - after all, that's why you use OO. But you're trading that off against the performance hit. And at some point you're going to run out of memory anyway (or file handles or whatever), and if you didn't know that could happen then your code is screwed.
To return to your gun analogy, you can pull the trigger as much as you want when the safety's on, but sooner or later the safety comes off. At that point you're back to square one - except that now you're not equipped to deal with the consequences. The better solution is not to get into that position in the first place. In the gun analogy, you *never* point one at a person unless you intend to kill them, even if you know it's unloaded. If you do, you're exposing yourself as being inexperienced and dangerous to be around. Similarly in the code space, you can use OO abstraction and assume that everyone else takes care of their own memory, but you *must* know what can go wrong under the OO abstraction and be ready for it. If you don't, again you're exposing yourself as someone who's inexperienced and will almost certainly write bug-ridden code. Whilst I don't mind having inexperienced people on my team (my team was a bit of a training ground over the last 2-3 years, so I'm used to training people up), I'm not going to let them loose on the code without supervision and close reviewing until I can be sure they're not going to shoot it dead.;-)
So if printf truncating could lead to an error, I check it.
Our "bug-of-the-day" intranet page contains a permanent link to "the bug from hell", where one of our most senior engineers ignored a return value (and the coding standard which mandated the check), and left himself open to a very nasty intermittent and hardware-specific bug, which took something like 4 man-weeks to find. As an object lesson in *why* you want coding standards, it serves its purpose...
The major source of security bugs in C and C++ is lazy programmers.
Our company has an in-house rule - "if it returns an error status, you check it". Why? Because most really nasty bugs arise from failure to check this. If you're lucky, this will just result in unexpected crashes. If you're unlucky, you get buffer overruns and remote code execution.
Why do programmers not check this? I'm convinced it comes down to how you're taught. I went through a good dozen C and C++ tutorials when I was learning them. I've been through a few more since, teaching other people. And I've *never* seen a textbook that includes a check on the results of a malloc() call being NULL. Yes I know the argument is "it'll make the examples harder to read". That's a fair point, in a hello-world program. But by the time you get to using malloc(), you should know enough to handle a little complexity. The books just don't cover it though. Not only do they simplify the examples, but they don't mention that they're simplifying. As a result, it's an issue that too many coders don't realise exists.
If coders get some good mentors at work, to show them how this *should* be done, then fine. But I don't think that happens either - code review is not a way of life for most companies. So they just go their merry way until their code falls over in a heap, and then wonder what to do about it.
Python is generally quicker to write than Java, and Java is generally quicker to write than C++, and C++ is generally quicker to write than C, simply because each step along the line does most of that work for you. But that generally comes at the cost of increased overhead (code size, execution time or both). And even then it's worth knowing what's happening underneath, because if you don't then it *will* bite you sometime. Neither of these is more secure than the other though, assuming the coder knows what they're doing.
What do you hope to get from here? There are three possible outcomes:-
1) You take advice from/. and someone asks where you got your info. You get canned, demoted or otherwise removed from the project when you tell them.
2) You take advice from/. and no-one asks where you got your info. Project fails. Someone asks where you got your info. You get canned or demoted when you tell them.
3) You take advice from/. and no-one asks where you got your info. Project succeeds. You get credit. This is the best outcome, but let's face it, it's incredibly unlikely since you don't have the technical know-how to make it work.
More realistically, this is *exactly* what consultants are for. If you specify at the start that flexibility to be upgraded and non-vendor-specific are key requirements, then you'll get advice based on that specification. And a consultant doesn't have to do the work - outsourcing is not compulsory. If you think you can do the work once you've been pointed in the right direction (or hire a team who can do the work), then all you need the consultant for is to provide advice on which systems and architectures to choose.
All the ones I've seen move your sighting in a predictable side-to-side way. This simulates running very well. What it *doesn't* simulate well is the behaviour of arms whilst running - I've yet to see a FPS which does anything except fire at whatever's in the centre of the screen. If it comes through the dot in the middle of the screen, bam, it's dead, regardless of how fast you're running. Except that IRL, where your eyes point != where your gun points. No game I've seen makes any allowance for this.
Trouble is that to get it right would basically need two mice (or mice and joystick), one changing how you're facing and the other for changing where you're aiming. The effect would likely be to have crosshairs that move round the screen, like the old Star Wars arcade game or like missile lock on flight sims.
Re your midair flip thing, the problem there is that no FPS takes account of recoil. Oh yes, they make your sights move a bit, but that's it. No loss of balance or anything like that, not even firing a SAW from the hip. They don't even reduce aiming accuracy whilst moving. When they get all that right, look for all those ex-leet people jumping around to die in swarms to the one guy who stays stationary with his feet on the ground whilst firing.
OK, to be clearer - redistribution of the file has to be made pointless. DRM fulfills that requirement, by making the data unuseable (assuming the DRM has been implemented in a reasonably strong way).
Another way of stopping redistribution is by making downloading the original file free/cheap. But this doesn't look likely for non-UK residents, since they're not contributing to the BBC through the TV license fee, and this will also be limited by the licensing terms under which shows are transmitted.
Download any programme, yes. However you still have to prevent it being redistributed, otherwise you *will* end up with "internet TV" sites putting these out without paying a penny, or simply ripped onto eDonkey or some other system. And most of those "internet TV" sites will inevitably be in Russia or somewhere else where rule of copyright law doesn't apply. So we're back to DRM again.
I agree that the 7-day thing is crap, but you'll still need the DRM.
Slashdot Mirror
That's the reason you adopt the CYA approach unless you absolutely know the manager in question. If it's going to fail, email people to say it's going to fail, together with a large list of reasons and supporting evidence, and keep those emails. Even better, get co-workers to provide similar estimates, so he can't claim it's just you.
;-)
If your estimates turn out to be right and your manager's turn out to be wrong, where's his defence? The answer then is to wave those emails at him and tell him you told him so (politely, unless he stops being polite of course). If that escalates it to disciplinary, fine - walk up the layers of management until you find a manager where the buck stops. And use your right to have another person in the room with you, if you think they might try to lean on you when you're on your own. And if there genuinely is no-one in the entire company with as much morals as God gave a weasel, then you're fucked anyway, so why are you there?
On the plus side, you then have a 100% watertight case for constructive dismissal, so look on the bright side.
Grab.
The real story is rather more complex than that.
;-) counts the hours they spend on a project.
;-/
Engineers *with experience* are good at estimation. By the time you've got that experience, chances are you've been in the business 5-10 years and you've got the seniority to not have the kind of grief the OP had.
My personal experience of myself and everyone else I've ever worked with though, for the last 7 years since uni working in embedded software, is that *everyone* sucks initially. Without exception. Until you get into a job, you're not used to 37.5 hours *and* making deadlines. Need to make a uni assignment? Work into the night, no worries, and make up the sleep the next couple of weeks. No student anywhere (unless they're some kind of freak
That all kind of falls apart at work, where management frowns on employees working themselves into the ground short-term and working less productively overall. It also runs into the notorious over-optimism of young engineers, who assume that because they've solved all tasks quickly so far, that every other task they'll see in the next couple of years will be equally easy. Throw a 200-page spec at them, and expect a response of "yeah, 6-8 weeks, no worries". And finally, they forget that docs and testing are also part of the job - typically they never had to do that at uni, so they only count the coding time. The job of the manager and/or senior engineer is to inject rationality into estimates from people who can't estimate themselves.
Basically, estimating is like driving a car - the more you do it, the better you get. Initially you don't know how, and basing project quotes on estimates from a new grad is like putting a 16-year-old into an F1 car and saying "go for it" - the crash is inevitable. A smart manager will get estimates from everyone (so they all feel equally important), factor in reliability and how long *they* think it'll take (and how long their senior engineer thinks), and use those numbers instead. A *really* smart manager will monitor how long it actually took, so his team can find out what their over/under-estimating tendencies are, and improve in future. Sadly there aren't enough of the former, and even less of the latter.
As you say though, the problem is managers who say "oh no, that's way too long, cut it by 75%". If they have a basis for saying that, then fine - some inexperienced engineers swing the other way and estimate months for a 2-week job. But if they've no technical understanding then they're just as inexperienced as a green engineer, and just as much of a liability.
Grab.
Suppose you're spending $1billion, and you say "hey, we've developed LCDs, velcro and memory foam". But of that $1billion, maybe $100million went into each of those three. So what happened to the other $700million? Answer: used for non-novel work to get a rocket (and its occupants) up and down.
So if what you really want is the ancillary benefits, you're better to throw the whole $1billion at technologies that give you the ancillary benefits, instead of blowing it on things that don't advance knowledge.
Grab.
Excuse me? Is this the same game of tennis that already has automated line calls and net calls?
All games will use technology that's proven and effective, but it always needs a human on top of it to overrule obvious errors. Football (soccer) already has video replays to check on fouls. Cricket has the "third umpire", again for video replays.
But it can't affect how the game works. In the case of tennis and baseball, I suspect the special balls to make this work will behave differently to "traditional" ones.
Grab.
They'll definitely try - that's their job. Your job is to tell them that it isn't possible. And make sure that it's documented in an email that it isn't possible. If they tell you to do both, send an email back (and CC'd to boss's boss) saying that it isn't possible.
Grab.
There's a difference between taking care of the customer, finding out what they want and all that, and going out and giving them freebies. Obviously the customer will love you if you give them freebies, but *your* company will crash and burn. And guess what, it's *your* company that pays you.
Grab.
Estimating the amount of work is a technical decision. Allowing for contingency is a management decision. If it's a fixed-price contract (as most are) rather than time and materials, the estimate MUST include a multiplier for contingency. Most projects will come in on time, some will spill over, and none will come in in less time, so overall you lose. Hence contingency to allow for that and still let the firm make a profit.
Also remember that engineers are *notoriously* bad at estimating (see the famous estimates for MS implementing WinNT for an example). Unless an engineer has a proven track record at estimating 100% accurately *and* knows 100% of the detail about the system, doubling the estimate is not a bad plan to allow for contingency.
Grab.
No it doesn't. It has a window that appears, but only the terminally incompetent would call that piece of shite an "interface", because it isn't actually possible to do anything with it. Unless they've made *major* strides in the last 3 months, of course, in which case my apologies...
Grab.
I'm afraid you need more hardware experience... :-/
;-)
That's certainly fast enough to do "output = -input;". Your problem though is converting analogue voltage to "input", reading "input", writing "output" and converting "output" to analogue voltage.
The *best* soundcards currently available are 96kHz. Nyquist says that you can only reproduce a frequency of 0.5 x sample rate. But that's theoretical-only - to get a decent approximation takes you to more like 0.1 x sample rate. Which means you can accurately reproduce sounds up to 9.6kHz. Probably OK for fixed noises like motors, but not much good for white noise.
But even then, you've got another problem of time delay. The best real-time digital sound processor takes 1 sample time to read data and 1 sample time to process it. (There's also write time, but you can combine that with processing time, if we're assuming the theoretically-best system.) So you've got 2 samples delay, which is 0.02ms. That's acceptable. PCs though typically have a time delay of around 2ms in reading data (and that's on a *good* system). This means that any sound you output will be 2ms behind. Combining them gives a resultant noise at 500Hz. You can use prediction to reduce that, but the limit of the time delay means you'll never be able to noise-cancel at more than 500Hz.
In other words, using a PC for noise-cancelling is useless, and the OP is a fucking dipshit.
In retaliation, I'm tempted to post an "Ask Slashdot" for "Why can't we build space elevators today? After all, we only need a long rope, and the US wire-making industry churns out miles of steel cable every year. That should be fine, shouldn't it?"
Grab.
Except that the producer pays for distributing physical junk mail. The kicker with spam is that the producer pays ~zilch, whereas the receiver (either the end-user if on a metered bandwidth/time system, or their ISP and then indirectly all customers if on an unmetered system) is forced to pay for stuff they don't want.
Grab.
IIRC, Gimp assumes a certain mouse-over selection behaviour from your WM to work. Since that selection behaviour is optional in Linux, that means that the flaws in the Win32 port will also be present in Linux, no?
Grab.
The "American abroad" thing has nothing to do with being white or male, and everything to do with country of origin. A black Westerner going to Africa will be seen as American/British/whatever by Africans.
As far as the shaved-head thing goes, are you not aware of the existence of skinheads? Since most shaven-headed whites for the last 30-40 years have been white supremacists, I don't know why you're surprised.
Grab.
I remember those days too - and they're still with us now if you're doing embedded software...
As for the optimisation, as you can see from the bytecode, it depends 100% on your processor supporting instructions which speed this up. If you're on a processor that doesn't have this built in, you're screwed.
Grab.
Oh yeah, who writes C code anymore?
Er, close to 100% of software engineers writing code for embedded systems, perhaps?
Grab.
A window manager with no Focus-on-Mouse-Over
Many people consider this to be a good thing - I know I do. It does depend on personal preferences, but I know if I've got three editor open and I'm typing, I want text to keep going to the one I last selected, even if I happen to knock my mouse while I'm putting my coffee cup down.
More to the point, this is optional in Linux too, depending on your WM. If any software author says "I require WM XYZ for my software to work effectively and it'll be hamstrung on anything else", then I can point you out an author who doesn't give a shit about making something for other people to use.
and a taskbar that didn't properly ignore Gimp's dialog boxes.
This is 100% a fault of the coder, and not a fault of the Windows taskbar. This is not a difficult thing to implement, you just have to do it right.
Yes, Gimp was ported from X-Windows. These flaws indicate that the port is only at a beta stage - it works, but it's not ready for the big-time yet. Another application that isn't ready for the mass-market "Linux-on-the-desktop" aim.
But even allowing for the flaws in the port, the user interface for Gimp simply is not intuitive in the same way that commercial Windows drawing packages are.
Grab.
See http://slashdot.org/comments.pl?sid=164835&cid=137 57515
How about thinking *inside* the box? By which I mean, how big is a mobile/PDA?
The big problem is the screen. Mobiles typically have screens about 2"x1.5". You really can't play anything more sophisticated than card games on it. Platformers are just about tolerable, but they don't really work. There simply isn't the space to make anything work. Even suppose mobiles get screens the size of a PDA, so maybe 4"x3" - you still can't do more than simple card games, puzzles or whatever.
Let's think ahead a bit now. You can't make the box physically bigger than this or it won't fit in a pocket, so a mobile *can't* be bigger than that. Let's even suppose someone invents a cunning mechanism that folds out 6 screens from inside there (each screen being 0.25" thick - a mobile more than 1.5" thick is too big to fit in a pocket, and a screen thinner than 0.25" will be too fragile to survive). Now we have found the absolute maximum screen size to be 8"x9". You could just about play reasonable games on that - you're not going to get full immersion, but modern games will stand up to that kind of thing.
But until that day comes and someone invents this mythical fold-out screen, games on mobiles will suck, and will continue to suck, simply because the display hardware is not there.
Grab.
I suggest you bring that analogy up with US gun owners who are currently being asked to fit handprint recognition to guns. Ask them how practical that is, for how much extra safety.
;-)
I really don't mind people using code that has built-in error-trapping. If you're using OO code anyway, then by all means use CString and don't worry about how much array is needed underneath the OO abstraction - after all, that's why you use OO. But you're trading that off against the performance hit. And at some point you're going to run out of memory anyway (or file handles or whatever), and if you didn't know that could happen then your code is screwed.
To return to your gun analogy, you can pull the trigger as much as you want when the safety's on, but sooner or later the safety comes off. At that point you're back to square one - except that now you're not equipped to deal with the consequences. The better solution is not to get into that position in the first place. In the gun analogy, you *never* point one at a person unless you intend to kill them, even if you know it's unloaded. If you do, you're exposing yourself as being inexperienced and dangerous to be around. Similarly in the code space, you can use OO abstraction and assume that everyone else takes care of their own memory, but you *must* know what can go wrong under the OO abstraction and be ready for it. If you don't, again you're exposing yourself as someone who's inexperienced and will almost certainly write bug-ridden code. Whilst I don't mind having inexperienced people on my team (my team was a bit of a training ground over the last 2-3 years, so I'm used to training people up), I'm not going to let them loose on the code without supervision and close reviewing until I can be sure they're not going to shoot it dead.
Grab.
if it returns an error status, you check it
So if printf truncating could lead to an error, I check it.
Our "bug-of-the-day" intranet page contains a permanent link to "the bug from hell", where one of our most senior engineers ignored a return value (and the coding standard which mandated the check), and left himself open to a very nasty intermittent and hardware-specific bug, which took something like 4 man-weeks to find. As an object lesson in *why* you want coding standards, it serves its purpose...
Grab.
The major source of security bugs in C and C++ is lazy programmers.
Our company has an in-house rule - "if it returns an error status, you check it". Why? Because most really nasty bugs arise from failure to check this. If you're lucky, this will just result in unexpected crashes. If you're unlucky, you get buffer overruns and remote code execution.
Why do programmers not check this? I'm convinced it comes down to how you're taught. I went through a good dozen C and C++ tutorials when I was learning them. I've been through a few more since, teaching other people. And I've *never* seen a textbook that includes a check on the results of a malloc() call being NULL. Yes I know the argument is "it'll make the examples harder to read". That's a fair point, in a hello-world program. But by the time you get to using malloc(), you should know enough to handle a little complexity. The books just don't cover it though. Not only do they simplify the examples, but they don't mention that they're simplifying. As a result, it's an issue that too many coders don't realise exists.
If coders get some good mentors at work, to show them how this *should* be done, then fine. But I don't think that happens either - code review is not a way of life for most companies. So they just go their merry way until their code falls over in a heap, and then wonder what to do about it.
Python is generally quicker to write than Java, and Java is generally quicker to write than C++, and C++ is generally quicker to write than C, simply because each step along the line does most of that work for you. But that generally comes at the cost of increased overhead (code size, execution time or both). And even then it's worth knowing what's happening underneath, because if you don't then it *will* bite you sometime. Neither of these is more secure than the other though, assuming the coder knows what they're doing.
Grab.
What do you hope to get from here? There are three possible outcomes:-
/. and someone asks where you got your info. You get canned, demoted or otherwise removed from the project when you tell them.
/. and no-one asks where you got your info. Project fails. Someone asks where you got your info. You get canned or demoted when you tell them.
/. and no-one asks where you got your info. Project succeeds. You get credit. This is the best outcome, but let's face it, it's incredibly unlikely since you don't have the technical know-how to make it work.
1) You take advice from
2) You take advice from
3) You take advice from
More realistically, this is *exactly* what consultants are for. If you specify at the start that flexibility to be upgraded and non-vendor-specific are key requirements, then you'll get advice based on that specification. And a consultant doesn't have to do the work - outsourcing is not compulsory. If you think you can do the work once you've been pointed in the right direction (or hire a team who can do the work), then all you need the consultant for is to provide advice on which systems and architectures to choose.
Grab.
All the ones I've seen move your sighting in a predictable side-to-side way. This simulates running very well. What it *doesn't* simulate well is the behaviour of arms whilst running - I've yet to see a FPS which does anything except fire at whatever's in the centre of the screen. If it comes through the dot in the middle of the screen, bam, it's dead, regardless of how fast you're running. Except that IRL, where your eyes point != where your gun points. No game I've seen makes any allowance for this.
Trouble is that to get it right would basically need two mice (or mice and joystick), one changing how you're facing and the other for changing where you're aiming. The effect would likely be to have crosshairs that move round the screen, like the old Star Wars arcade game or like missile lock on flight sims.
Grab.
Re your midair flip thing, the problem there is that no FPS takes account of recoil. Oh yes, they make your sights move a bit, but that's it. No loss of balance or anything like that, not even firing a SAW from the hip. They don't even reduce aiming accuracy whilst moving. When they get all that right, look for all those ex-leet people jumping around to die in swarms to the one guy who stays stationary with his feet on the ground whilst firing.
Grab.
OK, to be clearer - redistribution of the file has to be made pointless. DRM fulfills that requirement, by making the data unuseable (assuming the DRM has been implemented in a reasonably strong way).
Another way of stopping redistribution is by making downloading the original file free/cheap. But this doesn't look likely for non-UK residents, since they're not contributing to the BBC through the TV license fee, and this will also be limited by the licensing terms under which shows are transmitted.
Grab.
Download any programme, yes. However you still have to prevent it being redistributed, otherwise you *will* end up with "internet TV" sites putting these out without paying a penny, or simply ripped onto eDonkey or some other system. And most of those "internet TV" sites will inevitably be in Russia or somewhere else where rule of copyright law doesn't apply. So we're back to DRM again.
I agree that the 7-day thing is crap, but you'll still need the DRM.
Grab.