• thorin (unregistered) in reply to Wim Coenen
    Wim Coenen:
    thorin:
    Conclusion: while this is a bug, the code is expected to operate without creating collisions for decades (under the reasonable assumption that 1000 new customers each day is an upper limit).

    Where does it say IDstring is a customer?

    ThisCustomerID

    OMG I'm blind!

    Tks for the correction......./me hangs his head in shame

  • (cs) in reply to Anonymous
    Anonymous:
    Wim Coenen:
    If a thousand new customers are added on a given day, the probability of a collision occuring is 1-((1-(1/(16^8)))^499500) (499500 possible pairs, each with a chance of 1-1/(16^8) of NOT colliding)

    Your math is wrong. This is the birthday paradox computation. The probability of no collision is (1 - 0/16^8)(1 - 1/16^8)(1 - 2/16^8)...(1 - 999/16^8). Doing this with double precision floating point (which will be off, but I don't feel like pulling out the exact arithmetic package right now) yields p = 0.999883707, or about 1 in 8600. The number of days that must pass before there is a 1 in 2 probability that a collision will have occurred is ceiling(log(1/2) / log(p)) = 5961. If we consider a 1% risk completely unacceptable, the time is ceiling(log(0.99) / log(p)) = 82 days!

    A 1% chance in 82 days... Except the current day is also included in the ID. So the same number generated 82 days from now will get a different date appended to it, and therefore not collide at all.

  • (cs) in reply to Whitey
    Whitey:

    The REAL WTF - Nobody seems to understand the WTF.

    OK everybody, let me explain it. The UUID is for the transaction. You take the customerID and that day's date string to make your UUID. This is fine as long as the same user doesn't try to make more than one purchase per day. That's the WTF. Man I thought the people who read this page were supposed to be smart

    WTF code were you reading? That's not what this code does at all: <cfset IDstring = CreateUUID()>

    <cfset ThisCustomerID = Left(IDstring, 9) & LSDateFormat(Now(), 'MM-DD-YY')>

    It creates a BRAND NEW UUID, truncates it, and then adds the date to it. Where do you see it grabbing the "customerID"? Yeah, but we're all idiots and you are our savior.

  • Ben (unregistered) in reply to Raymond Chen
    a/c:
    ...which is not such a bad way to generate a pseudo-random number.
    Raymond Chen:
    On the contrary. It's about as non-random as you can get -- it's 100% predictable!

    That's true of every generator of pseudo-random numbers. It's algorithmic. By definition.

  • Wim Coenen (unregistered) in reply to joe.edwards
    Anonymous:
    Wim Coenen:
    If a thousand new customers are added on a given day, the probability of a collision occuring is 1-((1-(1/(16^8)))^499500) (499500 possible pairs, each with a chance of 1-1/(16^8) of NOT colliding)

    Your math is wrong. This is the birthday paradox computation. The probability of no collision is (1 - 0/16^8)(1 - 1/16^8)(1 - 2/16^8)...(1 - 999/16^8). Doing this with double precision floating point (which will be off, but I don't feel like pulling out the exact arithmetic package right now) yields p = 0.999883707, or about 1 in 8600. The number of days that must pass before there is a 1 in 2 probability that a collision will have occurred is ceiling(log(1/2) / log(p)) = 5961. If we consider a 1% risk completely unacceptable, the time is ceiling(log(0.99) / log(p)) = 82 days!

    A 1% chance in 82 days... Except the current day is also included in the ID. So the same number generated 82 days from now will get a different date appended to it, and therefore not collide at all.

    He meant that after 82 days, there is a 1% chance that one of the days has a collision within that day. Of course his formula is still wrong...

  • Oh the math pains me so. (unregistered)

    For all of you tossing out math to argue over the probability of collisions, here's a nut for you: RNG's are not what they are called, thus you have some function to generate pseudo random numbers that will probably completely screw the correct formulae for true RNGs over completely, and not in a good way either. ;)

  • thefakewtf (unregistered) in reply to RobertJohnK
    RobertJohnK:
    The editor is messed up in Konq because it doesn't load fancy rich text editor and there's no stylesheet to set reasonable width/heights for the textarea. Already notified Alex but it doesn't look like he's very interested in fixing it.
    Alex is the real WTF.
  • thefakewtf (unregistered) in reply to RobertJohnK
    RobertJohnK:
    The editor is messed up in Konq because it doesn't load fancy rich text editor and there's no stylesheet to set reasonable width/heights for the textarea. Already notified Alex but it doesn't look like he's very interested in fixing it.
    Alex is the real WTF.
  • test (unregistered) in reply to Wim Coenen
    Wim Coenen:
    Anonymous:
    Wim Coenen:
    If a thousand new customers are added on a given day, the probability of a collision occuring is 1-((1-(1/(16^8)))^499500) (499500 possible pairs, each with a chance of 1-1/(16^8) of NOT colliding)

    Your math is wrong. This is the birthday paradox computation. The probability of no collision is (1 - 0/16^8)(1 - 1/16^8)(1 - 2/16^8)...(1 - 999/16^8). Doing this with double precision floating point (which will be off, but I don't feel like pulling out the exact arithmetic package right now) yields p = 0.999883707, or about 1 in 8600. The number of days that must pass before there is a 1 in 2 probability that a collision will have occurred is ceiling(log(1/2) / log(p)) = 5961. If we consider a 1% risk completely unacceptable, the time is ceiling(log(0.99) / log(p)) = 82 days!

    Accounting for the number of possible pairs (as I did) automatically accounts for the birthday paradox effect.

    It is actually your math which is wrong. For n new customers, you have a probability factor (1 - n/16^8) in your calculation. For n>16^8, this results in a negative probability :D

    No, the poster's math is correct. Whenever you have a factor (1 - n/16^8), you also have a factor (1 - 16^8/16^8) = 0, so the probability of a non-collision is zero.

    This is the expected result: when you have 16^8 customers, by some miracle of chance each assigned their own unique ID among 16^8 possibilities(because the programmer didn't feel like using the common-sense approach of having a sequential component growing in length to make the UID actually unique), your (16^8 + 1)th customer will necessarily get one of the UIDs that have already been assigned.

    (If you have 367 people in a room, the chance that there is no birthay collision is not "practically" zero, it is actually mathematically equal to zero.)

    Note, however, that that poster is not taking into account that the date is concatenated to the UID, this is probably an unintended oversight.

    Anyway, I'd say it is HORRIBLE design to depend in any way on how a UID is generated, beyond considering the strength of the uniqueness guarantee. For many purposes, a sequential approach where the first UID is, say, 0 encoded as a N-bit number, and the nth UID is n encoded as an N-bit number, is a perfectly sane approach(for N so large that it will never be reached during the system's lifetime; 64 or 128 should certainly suffice for most needs, some small systems could get away with using 32, aka a standard unsigned int). With this approach, the first k bits would be the least frequently changed ones: this would be equivalent to shortening "00001", "00002", "00003", .. to "00", "00", "00", which is obviously less than optimal.

  • JC (unregistered) in reply to thefakewtf
    thefakewtf:
    RobertJohnK:
    The editor is messed up in Konq because it doesn't load fancy rich text editor and there's no stylesheet to set reasonable width/heights for the textarea. Already notified Alex but it doesn't look like he's very interested in fixing it.
    Alex is the real WTF.

    Perhaps Alex is a bit busy to try and cater for every single browser out there which has a slightly different interpretation of the standards... and so instead decides to spend his time keeping the 99% of people using mainstream browsers happy, rather than the one person who has made a choice to be different and so therefore should accept that some websites are broken.

  • Michael (unregistered) in reply to a/c
    a/c:
    Michael:
    You're still missing the point. Calculate the chances of CreateUUID returning the same thing twice in one day, then compare it to the chances you calculated above, and realize that the developer made extra effort to INCREASE the chances of collision. That is the WTF.

    Avoiding collision is not the only concern. It seems almost certain (from the additional MM-DD-YY tag) that the ID is intended to be human-readable. A 36-character UUID is too much if you have to read it over the phone, etc. The trade-off here seems entirely sensible.

    I don't buy that excuse, I've seen plenty of people add dates to random numbers to try to ensure uniqueness. That is almost certainly what they are doing here. Chances are they truncated 9 characters either because of the hyphen in the UUID, or because they are storing it in a database field with only enough room for date+9 characters.

    As for the argument about it being too long, I have 16 digits on my credit card, and some utility accounts with 20+ digits, and they are no more complicated to read over the phone than 9 digits would be. Take longer? Maybe, but not any harder. If you want something that can be communicated quickly, you use words or names that are unique, not randomly generated characters.

  • Bill (unregistered) in reply to Wim Coenen
    Wim Coenen:
    Assuming that the CreateUUID function returns a string of the form "550e8400-e29b-41d4-a716-446655440000", taking the first 9 characters will return "550e8400-". There are 8 random hexadecimal characters in there, so the number of possible outcomes for a given day is 16^8 = 4,294,967,296.

    If two customers are added on a given day, the probability of a collision is 1/(16^8).

    If a thousand new customers are added on a given day, the probability of a collision occuring is 1-((1-(1/(16^8)))^499500) (499500 possible pairs, each with a chance of 1-1/(16^8) of NOT colliding)

    That's a chance of less than 1 in 10,000 of creating a collision that day.

    Conclusion: while this is a bug, the code is expected to operate without creating collisions for decades (under the reasonable assumption that 1000 new customers each day is an upper limit).

    Many bad assumptions in there Wim. The UUID returned is advertised as random IN IT'S ENTIRETY. There is no guarantee that it won't return 10 straight perfectly random numbers that all share the same first 9 digits. You simply cannot assume that the random UUID generator randomizes each part separately and then combines them.

  • Wim Coenen (unregistered) in reply to a/c
    a/c:
    Actually as I look up the UUID format, the first eight characters (the ninth being a hyphen) are the least significant bits of the timestamp, which is not such a bad way to generate a pseudo-random number.

    ColdFusion uses the time of day in its UUID generator, but only as the input for a "cryptographically strong random number generator": http://livedocs.adobe.com/coldfusion/6.1/htmldocs/functi54.htm

    What you describe does match the standard time-based UUID generation algorithm: http://www.itu.int/ITU-T/studygroups/com17/oid/X.667-E.pdf

    The standard time-based algorithm seems kinda broken though, as Raymond Chen pointed out elsewhere in this comment thread. Fortunately the standard provides alternatives.

  • Michael (unregistered) in reply to JC
    JC:
    Perhaps Alex is a bit busy to try and cater for every single browser out there which has a slightly different interpretation of the standards... and so instead decides to spend his time keeping the 99% of people using mainstream browsers happy, rather than the one person who has made a choice to be different and so therefore should accept that some websites are broken.

    By "slightly different" I assume you mean "more correct", since as far as I know KHTML is one of, if not the most standards compliant rendering engines available. If the problem is that KHTML doesn't render the standard properly, then Alex should do nothing, if KHTML renders according to the standard, Alex should fix it since standards compliant browsers are on the rise.

  • ElQuberto (unregistered) in reply to etr
    etr:
    The real chances of a collision are 50%. Either you will get one or you won't.

    And the chances of you winning the lottery are 50% -- you either win or you don't.

  • Wim Coenen (unregistered) in reply to Bill
    Bill:
    Wim Coenen:
    Assuming that the CreateUUID function returns a string of the form "550e8400-e29b-41d4-a716-446655440000", taking the first 9 characters will return "550e8400-". There are 8 random hexadecimal characters in there, so the number of possible outcomes for a given day is 16^8 = 4,294,967,296.

    If two customers are added on a given day, the probability of a collision is 1/(16^8).

    If a thousand new customers are added on a given day, the probability of a collision occuring is 1-((1-(1/(16^8)))^499500) (499500 possible pairs, each with a chance of 1-1/(16^8) of NOT colliding)

    That's a chance of less than 1 in 10,000 of creating a collision that day.

    Conclusion: while this is a bug, the code is expected to operate without creating collisions for decades (under the reasonable assumption that 1000 new customers each day is an upper limit).

    Many bad assumptions in there Wim. The UUID returned is advertised as random IN IT'S ENTIRETY. There is no guarantee that it won't return 10 straight perfectly random numbers that all share the same first 9 digits. You simply cannot assume that the random UUID generator randomizes each part separately and then combines them.

    According to the documentation, coldfusion uses a "cryptographically strong random number generator":

    http://livedocs.adobe.com/coldfusion/6.1/htmldocs/functi54.htm

    You can argue what it means to be a "cryptographically strong RNG". But I'm pretty sure that it won't "return 10 straight UUID's with the same 9 first digits".

  • a/c (unregistered) in reply to test
    test:
    Anyway, I'd say it is HORRIBLE design to depend in any way on how a UID is generated, beyond considering the strength of the uniqueness guarantee. For many purposes, a sequential approach where the first UID is, say, 0 encoded as a N-bit number, and the nth UID is n encoded as an N-bit number, is a perfectly sane approach(for N so large that it will never be reached during the system's lifetime; 64 or 128 should certainly suffice for most needs, some small systems could get away with using 32, aka a standard unsigned int).
    The UUID format is specified in an ISO standard, an RFC, and the ColdFusion API. You should be able to trust the output of CreateUUID() as much as you can trust Left(). A sequential ID (0001,0002,0003) has privacy/security concerns because they're easy to guess. It's clear to me that the programmer wanted a pseudo-random number that was still human-readable. This actually seems like a reasonable implementation. If you add on a bit to regenerate the ID in case of collision, this code will never give you problems.
  • george (unregistered)

    guys, thanks for the excellent time i had reading all comments. i failed to see what exactly is wrong with uuid but the discussion really made my day :)

  • Wim Coenen (unregistered) in reply to test
    test:
    Wim Coenen:
    Anonymous:
    Wim Coenen:
    If a thousand new customers are added on a given day, the probability of a collision occuring is 1-((1-(1/(16^8)))^499500) (499500 possible pairs, each with a chance of 1-1/(16^8) of NOT colliding)

    Your math is wrong. This is the birthday paradox computation. The probability of no collision is (1 - 0/16^8)(1 - 1/16^8)(1 - 2/16^8)...(1 - 999/16^8). Doing this with double precision floating point (which will be off, but I don't feel like pulling out the exact arithmetic package right now) yields p = 0.999883707, or about 1 in 8600. The number of days that must pass before there is a 1 in 2 probability that a collision will have occurred is ceiling(log(1/2) / log(p)) = 5961. If we consider a 1% risk completely unacceptable, the time is ceiling(log(0.99) / log(p)) = 82 days!

    Accounting for the number of possible pairs (as I did) automatically accounts for the birthday paradox effect.

    It is actually your math which is wrong. For n new customers, you have a probability factor (1 - n/16^8) in your calculation. For n>16^8, this results in a negative probability :D

    No, the poster's math is correct. Whenever you have a factor (1 - n/16^8), you also have a factor (1 - 16^8/16^8) = 0, so the probability of a non-collision is zero.

    Indeed, I see that I was wrong.

    Turns out that it is quite hard to post a comment to thedailywtf.com which is not B/S. Must be some kind of WTF-distortion field ;)

    Oh well at least I learned something today...

  • (cs) in reply to Zonkers
    Zonkers:
    To be honest, it drives me a little batty to see these captcha comments sprinkled throughout the discussions.
    See my post about my Greasemonkey script that rids your DailyWTF experience of captchas.

    Based on this thread, however, I see that I have to update my script to wipe out not only captcha with a colon but also "captcha-" and "captcha="

  • freakshow (unregistered) in reply to Zonkers
    Zonkers:
    Why does everyone feel the need to reiterate their captchas in their comments? Is it not enough to type it once in that little textbox?

    To be honest, it drives me a little batty to see these captcha comments sprinkled throughout the discussions. Although whatever, comment how you like.

    I know what you mean. The bottom line is, it's neither funny, clever, or thought-provoking. I just don't get it.

  • tml (unregistered)

    Probably should have just used the function

    GetWTFCaptcha()

    which returns a never repeating string of meaningless text.

  • (cs)

    Ok, Cold Fusion sucks...

  • DJS (unregistered)

    I think I saw the same code the other day... Maybe it's time to leave.

    D

  • Anonymous Coward (unregistered)

    I can think of one possibe motive behind the logic. If they wanted to know when the customer joined, that can just parse the ID to get the date and time. Kind of a piggy back database?

  • sf (unregistered) in reply to Whitey
    Whitey:
    etr:
    a/c:
    Bill:
    I think you're missing the point. Regardless of how long the substring is, taking a unique number and chopping off some of it could result in collisions much more frequently than the odds would lead you to believe. Try a small experiment - you don't need all that many iterations to see collisions when you truncate like that.
    The first eight characters of the UUID are actually the least significant bits of a 60-bit timestamp in 100ns intervals. The lower 32 bits repeat in a little over 7 minutes or about 200 times a day. (Remember the ID also incorporates the date, so there's no chance of collision on different days.)

    Since most system clocks only do millisecond accuracy, you're only actually getting 86400000 different values in one day. The same number will repeat 200 times a day, so that's 200/86400000 or 1/432000 chance of collision.

    Like I said, unless you're Amazon, it will probably be fine.

    That's faulty logic... If you create an id every 7 minutes (exactly) then your 100% guarenteed to get a collision... No?

    The real chances of a collision are 50%. Either you will get one or you won't.

    The REAL WTF - Nobody seems to understand the WTF.

    OK everybody, let me explain it. The UUID is for the transaction. You take the customerID and that day's date string to make your UUID. This is fine as long as the same user doesn't try to make more than one purchase per day. That's the WTF. Man I thought the people who read this page were supposed to be smart

    You are wrong. They are creating a customer ID from a portion of a generated UUID and a date. The customer ID will be different for each purchase. I thought that people who question the intelligence of others are supposed to be smart. See how that works?

  • Chris (unregistered) in reply to Wim Coenen

    No, your maths is wrong!

    Take a simple case, pick 3 numbers (A, B, C) from 1-10. Your method says that the probability of no collision is:

    Pnc = 0.9^3 = 0.9 * 0.9 * 0.9 = 0.729.

    What you are trying to express here is the probability of:

    (A != B) && (A != C) && (B != C).

    The problem lies in that fact that (B != C) is not independent of (A != B) and (A != C). What you need to express is:

    (A != B) && (A != C) && (B != C, given that ((A != B) && (A != C))).

    Now, the third term is the above is 8/9 (9 possible values for B, C which don't match A, of which 8 don't match each other).

    Hence:

    Pnc = 0.9 * 0.9 * 8/9 = 0.72

    The way Anon dealt with the problem is the correct way, which expresses:

    1 && (B != A) && (C != A or B )

    Giving:

    Pnc = 1 * 0.9 * 0.8 = 0.72

    Now, returning to the original problem:

    We can say that:

    Pnc = PRODUCT OVER x=0 to n-1 OF (1 - x/N)

    Where n is the number of generated UUIDs and N is the pool. We can now take logs, and conver to a sum:

    ln[Pnc] = SUM OVER x=0 to n-1 OF ln(1-x/N)

    For large x, this can be approximated as an integral:

    ln[Pnc] = INT OVER x=0 to n OF ln(1-x/N)

        = -N(n/N + (1 - n/N) ln(1 - n/N))

    By my calculations, n=77162 gives just over a 50% chance of a collision and n=9292 gives a 1% chance of a collision.

    Chris

  • millennium (unregistered)

    I'm just wondering, why nobody is understanding the idea of this source. The developer just wanted to create some not "very random" UUIDs. The WTF is that LSDateFormat(Now(), 'MM-DD-YY') should be something like this: LSDateFormat(Now(), 'MM-DD-YY HH:MM:SS') or something like this. The idea behind all this stuff is to create similar UUIDs in order to improve database index performance.

  • another dork (unregistered) in reply to millennium

    The real WTF is everyone here assuming they know what the number is used for and that it should, in fact, be unique. Guess it's more fun to ASS-U-ME, which is what leads to a good bit of the content that shows up here. :)

  • JC (unregistered) in reply to Michael
    Michael:
    JC:
    Perhaps Alex is a bit busy to try and cater for every single browser out there which has a slightly different interpretation of the standards... and so instead decides to spend his time keeping the 99% of people using mainstream browsers happy, rather than the one person who has made a choice to be different and so therefore should accept that some websites are broken.

    By "slightly different" I assume you mean "more correct", since as far as I know KHTML is one of, if not the most standards compliant rendering engines available. If the problem is that KHTML doesn't render the standard properly, then Alex should do nothing, if KHTML renders according to the standard, Alex should fix it since standards compliant browsers are on the rise.

    Sorry don't want to get involved in a flame war, so my last comment on the issue. Perhaps I should have said "More correct", I don't know... that wasn't my point! I think if Alex was to do it "properly" and it broke in IE/Firefox and only worked in standards compliant browsers, his advertising revenue would suddenly start to decrease! No doubt he'll worry about the rise of the standards compliant browsers when the reverse is true!

  • Jen Larkin (unregistered) in reply to a/c

    [quote user="a/c"][quote user="Bill"]Like I said, unless you're Amazon, it will probably be fine.[/quote]

    That depends on what the generated customer id is used for, actually. They could be using it to skip the automagic session management, in which case there could be huge collision problems. I work on sites that would go kaboom if we did that, and after seeing some of the stuff that people do in CF, it wouldn't surprise me.

    Of course, it's more likely that they are using it to avoid perceived problems with CFTransaction / lack of knowledge of CFTransaction, or lack of triggers/sequences / lack of knowledge of triggers/sequences. Probably involves an Access database too. Blech.

    Anyway, Paul N, if you are looking for a more sensible third party ColdFusion shopping cart, look me up. :)

    Bay Area ColdFusion User Group meeting tonight!

    Captcha: tastey -- um, that's spelled wrong.

  • Charles Bretana (unregistered) in reply to me
    me:
    a/c:
    Sooo.. the WTF is that they thought a 9 digit User ID was enough? How horrible! Jeez, unless you're Amazon, 9 digits probably will be enough. Maybe the number needs to be parsed by a human at some point.

    no. the wtf is that they're using the first 9 digits of the unique key...which no longer makes it unique. ex: 849183758193 = uuid1 849183758194 = uuid2 and using the first 9 return the same result, which means its no longer unique.

    Except that for GUIDs, (I assume this UUID s a GUID) the most significant digits are on the right... the left most digits change first....

  • darwin (unregistered) in reply to Wim Coenen
    Wim Coenen:
    Anonymous:
    Wim Coenen:
    the probability of a collision occurring is ...

    Your math is wrong. This is the birthday paradox computation. ...

    Accounting for the number of possible pairs (as I did) automatically accounts for the birthday paradox effect.

    It is actually your math which is wrong. ... :D

    Okay, that's it, somebody needs to run a simulation of this and report back the results!

    Captcha: pneumonoultramicroscopicsilicovolcanoconiosis

  • Earl Colby Pottinger (unregistered) in reply to Wim Coenen
    Wim Coenen:

    Conclusion: while this is a bug, the code is expected to operate without creating collisions for decades (under the reasonable assumption that 1000 new customers each day is an upper limit).

    The problem is there are lots of companies that have more than 1000 new customers a day. Worse there are plenty, plenty companies have far fewer than 1000 customers per day but the numbers shoots thru the roof come Christmas or if Oprah mentions them on her show.

    So there you are, a company that is just meeting its bills and then your sales department hits the jack-pot (you could make as much sales in the next week as the entire last year) and your computer keeps crashing/mixing up orders.

    But the time you figured out and fixed the problem the customer will have moved elsewhere.

  • Russ (unregistered) in reply to Ghost Ware Wizard
    Ghost Ware Wizard:
    Ok, Cold Fusion sucks...

    I'm sorry you feel that way about theoretical physics. I believe this is a technology blog, so your comment doesn't make much sense.

  • Zeros (unregistered) in reply to Michael

    Not hard to find out: Browser Standards [webdevout.net]

  • (cs) in reply to Zylon
    Zylon:
    Zonkers:
    Why does everyone feel the need to reiterate their captchas in their comments? Is it not enough to type it once in that little textbox?
    Because stupid people will take any available opportunity to be annoying.

    I nominate this as the post of month. This is what the site is all about.

  • Jaded Dev (unregistered)

    This kind of WTF comes as no surprise to me to be written in ColdFusion.

    At my last job we had a ColdFusion guy who thought it would be a good idea to only use the first 4 chars from a MD5 hash. After all, they are diffrent in the 3 tests that he did, so it must be always true....

    Lets face it, ColdFusion is the VB of the web. If there is a bigger idiot magnet out there, I've not seen it.

    captcha: tastey (ColdFusion? yeah, like a sh*t sandwitch)

  • Flibz (unregistered) in reply to Kuli
    Kuli:
    Duston:
    Anyone that say Coldfusion sucks must either be Hitler or a Nazi.
    Or both.

    Well you can be a Nazi without being Hitler, but being Hitler and not a Nazi could be tricky...

  • sicker (unregistered) in reply to Kuli
    Kuli:
    Duston:
    Anyone that say Coldfusion sucks must either be Hitler or a Nazi.
    Or both.
    Or both? I think that's quite easy, if he is Hitler, he is a Nazi by definition...
  • Flibz (unregistered) in reply to sicker
    sicker:
    Kuli:
    Duston:
    Anyone that say Coldfusion sucks must either be Hitler or a Nazi.
    Or both.
    Or both? I think that's quite easy, if he is Hitler, he is a Nazi by definition...

    Uncanny. Bothering to make the same post at the same time.

  • Flibz (unregistered) in reply to Jaded Dev
    Jaded Dev:
    This kind of WTF comes as no surprise to me to be written in ColdFusion.

    At my last job we had a ColdFusion guy who thought it would be a good idea to only use the first 4 chars from a MD5 hash. After all, they are diffrent in the 3 tests that he did, so it must be always true....

    Lets face it, ColdFusion is the VB of the web. If there is a bigger idiot magnet out there, I've not seen it.

    captcha: tastey (ColdFusion? yeah, like a sh*t sandwitch)

    Hang on. Where am I. Oh yeah. TheDailyWTF. Crap code for most languages...

    All platforms attract idiots. They just become more visible when a platform has a smaller user base.

  • Scottford (unregistered) in reply to darwin
    darwin:
    Okay, that's it, somebody needs to run a simulation of this and report back the results!

    Be sure to use a cryptographically strong RNG. Like CreateUUID().

  • sicker (unregistered) in reply to another dork
    another dork:
    The real WTF is everyone here assuming they know what the number is used for and that it should, in fact, be unique. Guess it's more fun to ASS-U-ME, which is what leads to a good bit of the content that shows up here. :)

    You are right! I would assume that after generating the the id they check if it is already taken, if it is, they generate a new one, until there a unused id is found. But the real WTF is still, why do they generate a 16 byte random number and only use 4 byte (assuming the UUID is the standard canonical form)?

  • Jaded Dev (unregistered) in reply to Flibz
    Flibz:
    Jaded Dev:
    This kind of WTF comes as no surprise to me to be written in ColdFusion.

    At my last job we had a ColdFusion guy who thought it would be a good idea to only use the first 4 chars from a MD5 hash. After all, they are diffrent in the 3 tests that he did, so it must be always true....

    Lets face it, ColdFusion is the VB of the web. If there is a bigger idiot magnet out there, I've not seen it.

    captcha: tastey (ColdFusion? yeah, like a sh*t sandwitch)

    Hang on. Where am I. Oh yeah. TheDailyWTF. Crap code for most languages...

    All platforms attract idiots. They just become more visible when a platform has a smaller user base.

    No, its just more visible when the chronicly unskilled is your target demographic. But in this particular WTF, it just sounded so simmalar to my own experience.

  • Mike5 (unregistered) in reply to Duston
    Duston:
    Anyone that say Coldfusion sucks must either be Hitler or a Nazi. And thus I Godwin's law.

    It doesn't count since you're referring to it...

  • Joseph Newton (unregistered) in reply to a/c

    Huh? WTF are we reading geeky IDs over the phone for? We have these fascinating tools in this'ere century--we calls 'em computers. One of the really neat things that they make possible is fetching a name, as in a real, human name, from the DB, and using that in human communication. We also have some other sorta fancy stuff, like e-mail, and copy-and-paste, for times when there is actually a need to transmit an internal ID.

    Review Database 101--GUIDs are not meant to hold meaningful data--only to guarantee uniquenes within the innards of the DB and related software.

    [captcha: darwin--what would he say about the fitness of this species]

  • (cs) in reply to Jaded Dev
    Jaded Dev:
    Lets face it, ColdFusion is the VB of the web. If there is a bigger idiot magnet out there, I've not seen it.
    lol ... this made my day.
  • pirates (unregistered) in reply to Russ
    Russ:
    Ghost Ware Wizard:
    Ok, Cold Fusion sucks...
    I'm sorry you feel that way about theoretical physics. I believe this is a technology blog, so your comment doesn't make much sense.

    Just because there's no implementation doesn't mean it isn't technology.

  • geo (unregistered)

    and yes, coldfusion really sucks !

Leave a comment on “Taking the U out of UUID”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article