• 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.

  • H|B (unregistered)

    Perhaps they were totally afraid of SQL injections?

  • (cs)

    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!

  • beyondthislife (unregistered)

    Slow, and unless they were the last user in the database, they'd never get authenticated either....

  • (cs)

    People should be able to contract STDs from writing bad code.

  • Loren Pechtel (unregistered) in reply to akatherder
    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

  • (cs)

    Add a break statement and you've got yourself some enterprisey code right there.

  • (cs)

    I blame the unit test, procedures should always be tested with multiple variables.

  • (cs) in reply to Loren Pechtel
    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.

  • J (unregistered)

    No default value is set. If the user table ever gets truncated, 

    this.authenticated = FILE NOT FOUND;

  • Kinglink (unregistered) in reply to DaveK
    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.

  • 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()

  • (cs) in reply to DaveK
    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?

  • Theo (unregistered)

    A real unit-test should not go to the database anyway. It should use a mocked datasource.

  • SQB (unregistered)

    Am I the only one who feels that 

      this.authenticated = (source["user"].ToString() == username && source["pass"].ToString() == passhash);
    would be cleaner?

  • 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?

  • Thorin (unregistered) in reply to SQB
    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?

  • 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)

  • EagleErnie (unregistered)

    If he makes a proper ORDER statement, he will probably get it working no matter how many users in the table?

Leave a comment on “Classics Week: But It Worked in the Demo”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article