so that you only have to get it right one time. If you make developers repeat a process 10,000 times and they get it perfect 99.9% of those times, that means it's still screwed up in 10 places.
Honestly, I truly doubt his supposed CS degree from 1979 ever ONCE came up in the board's discussion to hire him.
I bet it did, albeit in passing: "oh, look: he has a degree in CompSci. That'd give us a little cred with other tech companies."
It's not about him being CEO, it's about whether a degree even matters for a 50+ year old employee with a strong employment background.
It doesn't. Therefore, he shouldn't have included it as a reason why they should hire him.
But on a practical level, I despise that I'm competing for jobs with liars. My resume is probably a lot shorter than his, but it's completely accurate. I did the things I listed. I earned the degree I put on there. I'd hate to think that my resume - my summary description of why a company would want to hire me - is competing with another guy's which is sprinkled with lies that make him look like a better candidate.
I guess I see it the same way as professional athlete who doesn't want to compete with steroid-fueled monstrosities. I want to get ahead by my own merits, but how am I supposed to go up against people who don't play by the rules? Given the choice between outing them to level the playing field or having to stoop to their level, I'd much rather start enforcing those rules.
So fire him. He lied to get to where he is. Maybe that particular lie wasn't the make-or-break that got him the job over someone else who wanted it, but it was important enough to him that he included it.
It's a messed up society when you can get further by lying and cheating than you can by playing it straight.
I understand where you're coming from, but the above is a truism. You could reasonably define cheating as "lying to get ahead unfairly", so by definition, cheating would always get you further ahead than would playing it straight.
Having zero experience with PHP on Windows, I ask this out of curiosity:
In Python, I've taken to passing arguments as a list to things like subprocess.call, bypassing the need for any kind of command line parsing. Does PHP let you do things like that, so that you run the equivalent of "system(commandname, '/z', '/o outputfilename', 'some complex! argument')"? I know that system itself doesn't directly support that, but wonder if some other facility might.
I think I probably know a lot more about it than you do, dear child. But you didn't answer my question: how would a new user - not you, not me, but someone trying PHP for the first time - know not to use mysql_*?
Back to what I said elsewhere: I consider that part of "writing the DB interface library", and not something you'd be doing in daily programming. I draw the distinction that you're building an infrastructure to base other code upon, and not writing ad-hoc code for copying-and-pasting elsewhere.
The docs Just Some Guy posted are from the bloody ancient mysql library which is hardly in use any more. They're of course still available, for backwards compatibility, so obviously the documentation has to be too.
But Google for "php mysql" and you'll get a list of the old-style functions, including "mysql_query", as the first search result. If PHP wanted to clear up the confusion, they should prominently mark those docs as being old-style and that new development should use PDO - but alas, they don't. You and I know that you shouldn't be using mysql_* for most things, but how would a new user who wants to use PHP and MySQL together know that?
I'd file that under "writing database libraries", which is the one place I consider it completely appropriate to handle that kind of stuff (therefore encapsulating the work so you don't have to repeat it everywhere in your code that you want to write "IN" queries). I have no problem with that.
So do it yourself. Sanitize your variables, prepare your statement, and then pass it.
You're wrong. Not difference-of-opinion wrong, but factually-incorrect wrong. What benefit do you get from re-inventing a language feature that's already there and (well, hypothetically in the case of PHP) well tested? Do you also write your own for loops with goto because it's more flexible?
And it's really not that much of a chore once you're used to it.
I swear to God, I hope you're trolling. Why make it a chore at all instead of letting the language libraries handle it? In your own words: if you're going to use a language, you should be able use it correctly. All modern languages provide facilities for doing things the right way, so what possible motive would you have for deliberately and painstakingly doing things the wrong way?
Even if SQL wasn't an issue, you still have to sanitize other things like shell commands.
So keep sanitizing shell commands until PHP catches up to other languages there, but do things the easy and right way in your database logic. You're allowed to use both a hammer and a pliers for different tasks, you know.
Prepared statements. Even PHP supports them, although they don't emphasize that fact enough (such as by causing calls to mysql_query to segfault, or ideally make the server hosting it catch on fire).
I say that in humor, but I'm actually dead serious about always using prepared statements - in any language - over directly executing concatenated query strings. It's one thing if you're the person writing the DB interface library that everything runs through and the database itself doesn't provide some kind of facility for helping you. In that case, you go to heroic lengths to test, test, test that your library is bulletproof. But most people aren't writing client libraries; they're writing apps that use them. Those people should never be manually building query strings. Not "well, not usually but..." or "there are some situations where...". No there aren't. Don't do that or let anyone else around you do it, either.
in practice, you couldn't be more silly, you link to article about people who call crypt() with only an md5 salt? what idiot does that?
Your reading comprehension fails. People expect:
crypt('string', 'salt') === 'saQ9i9dEI8LLA';
to return TRUE. Instead, they got:
crypt('string', 'salt') === 'salt';
So if you used the crypt function to hash and store site passwords, you weren't really storing the hash: you were just storing the salt itself. And when it came time to verify that "hash but really just the salt" by comparing it with the user-submitted password that had been crypted with the same salt, the comparison always came back true. Joyous day!
not any wares I've ever written nor seen.
Ah, I think I've found the disconnect. Would you like a lollipop?
as long as you escape your strings before passing them to MySQL
You know, I only hear PHP developers saying stupid shit like that. No one in Python talks about escaping strings (unless they're writing database libraries). Rubyists don't escape strings. Perl monks sure as hell don't escape strings. VB(\.Net)? programmers might escape strings, but we don't really count them. No one escapes strings anymore because it's stupid, error prone, and dangerous.
// Formulate Query // This is the best way to perform an SQL query // For more examples, see mysql_real_escape_string() $query = sprintf("SELECT firstname, lastname, address, age FROM friends WHERE firstname='%s' AND lastname='%s'", mysql_real_escape_string($firstname), mysql_real_escape_string($lastname));
// Perform Query $result = mysql_query($query);
Fucking hell. In 2012, we're still exposing newbies to that idiocy, and when they do it poorly and some kid in Latvia owns a major PHP project as a result, defenders jump out to yell "it's the programmer, not the language!"
There is nothing that can be done in say Ruby (my favorite language) that cannot also be done well in PHP.
In a theoretical computer science sense, you're correct. In practice, you couldn't be more wrong. In nearly 20 years of development, PHP has never managed to do things the right way on any objective scale. For example, last year PHP had a major crypto bug in a released version which failed unit tests. Let me repeat that: PHP's own unit tests failed but they still shipped it, distributing a major security flaw to all users.
PHP is unfit for major software development, and PHP's authors and maintainers are unfit to write and maintain it. Yeah, I said it. Yes, it's "just as good" as Ruby, Python, or other competing problem-space solutions in a strict Turing-completeness way, but in all pragmatic senses it has been a complete and utter rolling disaster.
Yes, it's popular. So are McDonald's hamburgers. That doesn't mean I'd want to deal with either on a regular basis.
Privacy extensions for IPv6 have been defined to address these privacy concerns. When privacy extensions are enabled, the operating system generates ephemeral IP addresses by concatenating a randomly generated host identifier with the assigned network prefix. These ephemeral addresses, instead of trackable static IP addresses, are used to communicate with remote hosts. The use of ephemeral addresses makes it difficult to accurately track a user's Internet activity by scanning activity streams for a single IPv6 address.
Privacy extensions are enabled by default in Windows, Mac OS X (since 10.7), and iOS since version 4.3. Some Linux distributions have enabled privacy extensions as well.
People dislike NAT because it's a crappy idea whose best featured are better implemented in other ways. It's not because we're too dumb to understand the issues or too cavalier to care about them.
I certainly hope that Linux network stack crowd (because they are the ones whose product will be used, as is customary, in large chunk of wifi routers and other home network devices) will get something done before copyright holders wisen up, and poke Comcast/Cox cable/Verizon to roll out IPv6 to end users.
Hey, we can finally get IPv6 adopted everywhere now that the entertainment mafiaas will lobby for every system to have a unique address.
How would privacy extensions - which are enabled by default on recent versions of Windows, OS X, iOS, and some Linux distros - help them track an ephemeral address to a particular system, let alone user?
And I mention those attempts as well, so people see that I'm serious and take the time for it.
That can't be over-emphasized: if you're stuck, tell what you've already tried. Not only does it save everyone else the time of suggesting something you've ruled out, but it demonstrates intent. It says, "I'm coming to you as a last resort after trying the self-help options, not as my first step because I don't value your time."
Rarely take bart, only when I have business in Oakland, and every experience has been from inconvinant to pure hell.
OK, BART isn't exactly an Uber cab but it's hardly "pure hell". I used to commute between Daly City and Embarcadero each morning and afternoon, and it was nothing if not unexciting. The trains departed on time and arrived on time, and the only inconvenience was that I couldn't refresh Twitter or text my wife between stations while underground. Now I frequently ride between Fruitvale and Embarcadero, and the least pleasant aspect is that you get jostled around a little bit on the way through Oakland. I even get 3G service while under the bay (get your "BART: Transbay Tube" foursquare checking while you wait!).
Crowded, sometimes, but the BART is nowhere near what you describe.
Slashdot Mirror
That's option B, option A is called "Open Source".
Which works as a distributed form of... wait for it... code review.
All your debug flags and compiler flags and build settings etc assume the developers would properly bracket their code under proper #ifdefs .
It's safer to bracket the logging code in #ifdefs:
so that you only have to get it right one time. If you make developers repeat a process 10,000 times and they get it perfect 99.9% of those times, that means it's still screwed up in 10 places.
Why not try to figure out what attractive women think instead of
"I bet that guy posts on Slashdot. Shun! Shun!
I think The Far Side nailed it, circa 25 years ago.
Honestly, I truly doubt his supposed CS degree from 1979 ever ONCE came up in the board's discussion to hire him.
I bet it did, albeit in passing: "oh, look: he has a degree in CompSci. That'd give us a little cred with other tech companies."
It's not about him being CEO, it's about whether a degree even matters for a 50+ year old employee with a strong employment background.
It doesn't. Therefore, he shouldn't have included it as a reason why they should hire him.
But on a practical level, I despise that I'm competing for jobs with liars. My resume is probably a lot shorter than his, but it's completely accurate. I did the things I listed. I earned the degree I put on there. I'd hate to think that my resume - my summary description of why a company would want to hire me - is competing with another guy's which is sprinkled with lies that make him look like a better candidate.
I guess I see it the same way as professional athlete who doesn't want to compete with steroid-fueled monstrosities. I want to get ahead by my own merits, but how am I supposed to go up against people who don't play by the rules? Given the choice between outing them to level the playing field or having to stoop to their level, I'd much rather start enforcing those rules.
So fire him. He lied to get to where he is. Maybe that particular lie wasn't the make-or-break that got him the job over someone else who wanted it, but it was important enough to him that he included it.
It's a messed up society when you can get further by lying and cheating than you can by playing it straight.
I understand where you're coming from, but the above is a truism. You could reasonably define cheating as "lying to get ahead unfairly", so by definition, cheating would always get you further ahead than would playing it straight.
Having zero experience with PHP on Windows, I ask this out of curiosity:
In Python, I've taken to passing arguments as a list to things like subprocess.call, bypassing the need for any kind of command line parsing. Does PHP let you do things like that, so that you run the equivalent of "system(commandname, '/z', '/o outputfilename', 'some complex! argument')"? I know that system itself doesn't directly support that, but wonder if some other facility might.
New users are advised to use MySQL Improved mysqli_ functions
That's a user comment, not part of the official documentation, and it was added today. At least it's a little documented now as of 11 hours ago.
The fact that every function under the mysql extension has the note..
No it doesn't. I'm looking at it right now, at http://www.php.net/manual/en/function.mysql-query.php, and that string does not exist on the page.
The fact that most new users will be using a framework rather then directly writing everything anyway.
Oh, so the language admittedly sucks, but frameworks abstract that suckiness away from new users. Way to move the goalposts.
Just face it, you don't know what you're talking about, stop acting like a little kid.
You're not very good at the whole "staying on subject and presenting evidence" things, but that's OK. It'll come to you with time if you keep at it.
I think I probably know a lot more about it than you do, dear child. But you didn't answer my question: how would a new user - not you, not me, but someone trying PHP for the first time - know not to use mysql_*?
Back to what I said elsewhere: I consider that part of "writing the DB interface library", and not something you'd be doing in daily programming. I draw the distinction that you're building an infrastructure to base other code upon, and not writing ad-hoc code for copying-and-pasting elsewhere.
The docs Just Some Guy posted are from the bloody ancient mysql library which is hardly in use any more. They're of course still available, for backwards compatibility, so obviously the documentation has to be too.
But Google for "php mysql" and you'll get a list of the old-style functions, including "mysql_query", as the first search result. If PHP wanted to clear up the confusion, they should prominently mark those docs as being old-style and that new development should use PDO - but alas, they don't. You and I know that you shouldn't be using mysql_* for most things, but how would a new user who wants to use PHP and MySQL together know that?
I'd file that under "writing database libraries", which is the one place I consider it completely appropriate to handle that kind of stuff (therefore encapsulating the work so you don't have to repeat it everywhere in your code that you want to write "IN" queries). I have no problem with that.
So do it yourself. Sanitize your variables, prepare your statement, and then pass it.
You're wrong. Not difference-of-opinion wrong, but factually-incorrect wrong. What benefit do you get from re-inventing a language feature that's already there and (well, hypothetically in the case of PHP) well tested? Do you also write your own for loops with goto because it's more flexible?
And it's really not that much of a chore once you're used to it.
I swear to God, I hope you're trolling. Why make it a chore at all instead of letting the language libraries handle it? In your own words: if you're going to use a language, you should be able use it correctly. All modern languages provide facilities for doing things the right way, so what possible motive would you have for deliberately and painstakingly doing things the wrong way?
Even if SQL wasn't an issue, you still have to sanitize other things like shell commands.
So keep sanitizing shell commands until PHP catches up to other languages there, but do things the easy and right way in your database logic. You're allowed to use both a hammer and a pliers for different tasks, you know.
Prepared statements. Even PHP supports them, although they don't emphasize that fact enough (such as by causing calls to mysql_query to segfault, or ideally make the server hosting it catch on fire).
I say that in humor, but I'm actually dead serious about always using prepared statements - in any language - over directly executing concatenated query strings. It's one thing if you're the person writing the DB interface library that everything runs through and the database itself doesn't provide some kind of facility for helping you. In that case, you go to heroic lengths to test, test, test that your library is bulletproof. But most people aren't writing client libraries; they're writing apps that use them. Those people should never be manually building query strings. Not "well, not usually but..." or "there are some situations where...". No there aren't. Don't do that or let anyone else around you do it, either.
in practice, you couldn't be more silly, you link to article about people who call crypt() with only an md5 salt? what idiot does that?
Your reading comprehension fails. People expect:
to return TRUE. Instead, they got:
So if you used the crypt function to hash and store site passwords, you weren't really storing the hash: you were just storing the salt itself. And when it came time to verify that "hash but really just the salt" by comparing it with the user-submitted password that had been crypted with the same salt, the comparison always came back true. Joyous day!
not any wares I've ever written nor seen.
Ah, I think I've found the disconnect. Would you like a lollipop?
as long as you escape your strings before passing them to MySQL
You know, I only hear PHP developers saying stupid shit like that. No one in Python talks about escaping strings (unless they're writing database libraries). Rubyists don't escape strings. Perl monks sure as hell don't escape strings. VB(\.Net)? programmers might escape strings, but we don't really count them. No one escapes strings anymore because it's stupid, error prone, and dangerous.
And yet PHP coderz still do it. Why? Oh, right: because the official docs teach them to:
Fucking hell. In 2012, we're still exposing newbies to that idiocy, and when they do it poorly and some kid in Latvia owns a major PHP project as a result, defenders jump out to yell "it's the programmer, not the language!"
There is nothing that can be done in say Ruby (my favorite language) that cannot also be done well in PHP.
In a theoretical computer science sense, you're correct. In practice, you couldn't be more wrong. In nearly 20 years of development, PHP has never managed to do things the right way on any objective scale. For example, last year PHP had a major crypto bug in a released version which failed unit tests. Let me repeat that: PHP's own unit tests failed but they still shipped it, distributing a major security flaw to all users.
PHP is unfit for major software development, and PHP's authors and maintainers are unfit to write and maintain it. Yeah, I said it. Yes, it's "just as good" as Ruby, Python, or other competing problem-space solutions in a strict Turing-completeness way, but in all pragmatic senses it has been a complete and utter rolling disaster.
Yes, it's popular. So are McDonald's hamburgers. That doesn't mean I'd want to deal with either on a regular basis.
That's from the AGPL (not the GPL), which is GNU's new EULA. It doesn't apply to GPL'ed software.
Photoshop. What does it have to do with ecommerce?
From Wikipedia:
People dislike NAT because it's a crappy idea whose best featured are better implemented in other ways. It's not because we're too dumb to understand the issues or too cavalier to care about them.
I certainly hope that Linux network stack crowd (because they are the ones whose product will be used, as is customary, in large chunk of wifi routers and other home network devices) will get something done before copyright holders wisen up, and poke Comcast/Cox cable/Verizon to roll out IPv6 to end users.
We did, about a decade ago.
Hey, we can finally get IPv6 adopted everywhere now that the entertainment mafiaas will lobby for every system to have a unique address.
How would privacy extensions - which are enabled by default on recent versions of Windows, OS X, iOS, and some Linux distros - help them track an ephemeral address to a particular system, let alone user?
And I mention those attempts as well, so people see that I'm serious and take the time for it.
That can't be over-emphasized: if you're stuck, tell what you've already tried. Not only does it save everyone else the time of suggesting something you've ruled out, but it demonstrates intent. It says, "I'm coming to you as a last resort after trying the self-help options, not as my first step because I don't value your time."
If your subway car is on fire, what the heck is your cellphone going to do for you?
"Goodbye, darling. I won't be coming home again. Tell the kids I love them."
If nothing more practical than that, isn't it enough?
Rarely take bart, only when I have business in Oakland, and every experience has been from inconvinant to pure hell.
OK, BART isn't exactly an Uber cab but it's hardly "pure hell". I used to commute between Daly City and Embarcadero each morning and afternoon, and it was nothing if not unexciting. The trains departed on time and arrived on time, and the only inconvenience was that I couldn't refresh Twitter or text my wife between stations while underground. Now I frequently ride between Fruitvale and Embarcadero, and the least pleasant aspect is that you get jostled around a little bit on the way through Oakland. I even get 3G service while under the bay (get your "BART: Transbay Tube" foursquare checking while you wait!).
Crowded, sometimes, but the BART is nowhere near what you describe.
I replaced our Sonicwall with OpenBSD+PF nearly 8 years ago. The only user-visible difference is that we stopped having unplanned network outages.