Comment On Classics Week: But It Worked in the Demo

But It Worked in the Demo was originally published on January 26, 2007. [expand full text]
« PrevPage 1Next »

Re: Classics Week: But It Worked in the Demo

2007-05-09 09:04 • by A Nonny Mouse (unregistered)
where o where has my little 'where' gone...? oh and all my effiency

how do these people pass themselves off as programmers. honestly.

Re: Classics Week: But It Worked in the Demo

2007-05-09 09:40 • by H|B (unregistered)
Perhaps they were totally afraid of SQL injections?

Re: Classics Week: But It Worked in the Demo

2007-05-09 09:43 • by DaveK
The best bit is not the lack of WHERE - that's just an optimisation after all. The best bit is the way after he finds the matching entry he keeps on going... and immediately de-authenticates on the first following non-matching entry.

Adding a WHERE clause so there's only ever one record returned would conceal, rather than fix, this bug. The dangers of premature optimisation!

Re: Classics Week: But It Worked in the Demo

2007-05-09 09:44 • by beyondthislife (unregistered)
Slow, and unless they were the last user in the database, they'd never get authenticated either....

Re: Classics Week: But It Worked in the Demo

2007-05-09 10:10 • by akatherder
People should be able to contract STDs from writing bad code.

Re: Classics Week: But It Worked in the Demo

2007-05-09 10:16 • by Loren Pechtel (unregistered)
135593 in reply to 135592
akatherder:
People should be able to contract STDs from writing bad code.


How? When is the last time you actually used a serial port for anything? And what other communications system stars with an S?

At least the captcha is on target: sanitarium

Re: Classics Week: But It Worked in the Demo

2007-05-09 10:43 • by shakin
Add a break statement and you've got yourself some enterprisey code right there.

Re: Classics Week: But It Worked in the Demo

2007-05-09 10:45 • by RobertJohnK
I blame the unit test, procedures should always be tested with multiple variables.

Re: Classics Week: But It Worked in the Demo

2007-05-09 10:53 • by akatherder
135602 in reply to 135593
Loren Pechtel:
akatherder:
People should be able to contract STDs from writing bad code.


How? When is the last time you actually used a serial port for anything? And what other communications system stars with an S?



I'll pay bums to go around sticking programmers with dirty needles. There may be some collateral damage, but that just makes it funnier.

Re: Classics Week: But It Worked in the Demo

2007-05-09 11:14 • by J (unregistered)
No default value is set. If the user table ever gets truncated,
this.authenticated = FILE NOT FOUND;

Re: Classics Week: But It Worked in the Demo

2007-05-09 11:18 • by Kinglink (unregistered)
135606 in reply to 135587
DaveK:
The best bit is not the lack of WHERE - that's just an optimisation after all. The best bit is the way after he finds the matching entry he keeps on going... and immediately de-authenticates on the first following non-matching entry.


AHHH yes, this is what I noticed too and it was quite delightful.

Captcha: Doom, such as what this program should bring.

Re: Classics Week: But It Worked in the Demo

2007-05-09 11:42 • by He Who Must Not Be Named (unregistered)
Even better is that it's going to hold a read lock onto every row, so there is addition concurrency issues w/o:
source.Close()

Re: Classics Week: But It Worked in the Demo

2007-05-09 19:17 • by chrismcb
135684 in reply to 135587
DaveK:
The best bit is not the lack of WHERE - that's just an optimisation after all. The best bit is the way after he finds the matching entry he keeps on going... and immediately de-authenticates on the first following non-matching entry.

Adding a WHERE clause so there's only ever one record returned would conceal, rather than fix, this bug. The dangers of premature optimisation!


So are you suggesting that they might have multiple rows with identical user names but different passwords?

Re: Classics Week: But It Worked in the Demo

2007-05-10 03:05 • by Theo (unregistered)
A real unit-test should not go to the database anyway. It should use a mocked datasource.

Re: Classics Week: But It Worked in the Demo

2007-05-10 05:18 • by SQB (unregistered)
Am I the only one who feels that
  this.authenticated = (source["user"].ToString() == username && source["pass"].ToString() == passhash);
would be cleaner?

Re: Classics Week: But It Worked in the Demo

2007-05-10 06:14 • by Alien426 (unregistered)
Am I the only one who wonders how many fields the table "users" has? Why do people still generally query all the data, even columns they don't ever need?

Re: Classics Week: But It Worked in the Demo

2007-05-10 07:48 • by Thorin (unregistered)
135758 in reply to 135745
SQB:
Am I the only one who feels that
  this.authenticated = (source["user"].ToString() == username && source["pass"].ToString() == passhash);
would be cleaner?


Does it really matter how "clean" it is if it only works when there's a single user of the system?

Re: Classics Week: But It Worked in the Demo

2007-05-10 15:33 • by Student (unregistered)
all of your test cases worked the night before but when it comes time to run the demo you realize you missed something


Happened to me today. Tested on windows server worked fine but inmmediatly segfaulted on Linux. Seems Linux's strdup() don't check if you pass it a NULL pointer.

PD: yes, it was more or less finished the night before and i'm also expecting the TA doesn't notice some code doesn't work)

Re: Classics Week: But It Worked in the Demo

2008-06-10 08:56 • by EagleErnie (unregistered)
If he makes a proper ORDER statement, he will probably get it working no matter how many users in the table?
« PrevPage 1Next »

Add Comment