• stew (unregistered) 
    value="^' + aData[i] + '$"

    Ummmm ... so it's submitting regular expression patterns to the server?! "Who knows what evils lurks beneath the javascripts?"

  • faoileag (unregistered) in reply to Paul Neumann
    Paul Neumann:
    I believe we have found the father of the president's daughter (and my ex-wife).
    You must be more precise in your language. Your sentence can be read as:

    ( ) the president's daugher is your ex-wife ( ) we have found two people, including your ex-wife ( ) the father of the president's daugher is your ex-wife

    Please click the appropriate radio button.

  • Paul Neumann (unregistered)

    To put this snippet in a form which more visitors of this site will understand:

    public string fnCreateRadioButtons(string[] aData)
{
    const string template =
        @"
    
            <input name=""{0}"" type=""radio"" value=""^{2}$"" id=""{0}-{1}"">
            <label for=""{0}-{1}"">{3}</label>
        
    ";

    var r = new System.Text.StringBuilder();
    var prefix = Math.Ceiling(new Random().NextDouble() * 9999);
    var iLen = aData.Length;

    r.AppendFormat(template, prefix, "all", "", Constants.Window.lbAll);
    for (var i = 0; i < iLen; i++)
    {
        r.AppendFormat(template, prefix, i, aData[i], aData[i]);
    }
    return r.ToString();
}
  • not an expert (unregistered) in reply to EvilSnack
    EvilSnack:
    2. This code is WTFery, but you have to be an expert to see why.
    Are you teasing us? Don't tease us. WHY ARE YOU TEASING US?
  • faoileag (unregistered) in reply to stew
    stew:
    value="^' + aData[i] + '$"
    Ummmm ... so it's submitting regular expression patterns to the server?!
    Not necessarily. All action can take place client-side.

    And with client-side generated random ids and names for the radio buttons the server wouldn't know waht to to with the data anyway :-)

  • Paul Neumann (unregistered) in reply to faoileag
    faoileag:
    You must be more precise in your language. Your sentence can be read as:

    (✔) the president's daugher is your ex-wife (✔) we have found two people, including your ex-wife (✔) the father of the president's daugher is your ex-wife

    Please click the appropriate radio button.

    Ain't DOM manipulation by the client a b****?
  • (cs) in reply to faoileag
    faoileag:
    Krunt:
    I guess the general point I'm trying to convey is that javascript is a crap language.
    Care to highlight just why you think it is?

    I actually enjoy programming with it. Some bits annoy me, true, but some bits also delight me and the overall comfort-factor ist definitely higher than with C. Or the good ole line-number-based BASIC-dialects of the mid-80s.

    js is much better now then 10 year ago where each browser had his own little piece of code for everything. But even now, this is very unstable... look the amount of website with js error and bugs.

    And how dare you talk again GW BASIC! Its like hitting your grand father in the face!

  • Grandpa (unregistered) in reply to faoileag

    [quote user="Krunt"]I guess the general point I'm trying to convey is that javascript is a crap language.[/quote] Care to highlight just why you think it is?

    I actually enjoy programming with it. Some bits annoy me, true, but some bits also delight me and the overall comfort-factor ist definitely higher than with C. Or the good ole line-number-based BASIC-dialects of the mid-80s.[/quote]

    How dare you disregard the good ole line-number-based BASIC-dialects of the early-70s? Not to mention the line-number-based FORTRAN dialects, where the line numbers didn't even need to be in order?

  • (cs) in reply to faoileag
    faoileag:
    ...stuff...

    Sheesh, some people!

    I'm not saying you should tell them to fuck off... just that they can fuck off.

    If you've got a pile of important work to do, and some of that work is made excruciating because of terrible bug reports, that work is going to get done after all the other stuff. The quicker a decent description comes in for that bug, the quicker it will get fixed... for reasons related both to the ease of fixing properly described bugs, and human nature.

  • (cs) in reply to The MAZZTer
    The MAZZTer:
    including a drag-and-drop module that attempts to poorly partly recreate the DOM hierarchy for drag and drop
    There are javascript libraries that do this sort of thing for you out of the box; Dojo for example. Sounds like you're busy re-inventing a lot of dom-manipulation code that is already a core part of many javascript libraries. Please spend some time learning them, and you'll save yourself a lot of headaches.
  • (cs) in reply to Nmare

    js is much better now then 10 year ago where each browser had his own little piece of code for everything. [/quote] That's a browser issue, not a JAVASCRIPT issue. Please try not to confuse the language with the environment it is running in.

  • (cs) in reply to Douglas
    Douglas:
    3333, not 2500.

    1/(1-(9998./9999)**3) = 3333.3334

    Sig Figs, man!

  • Andrew (unregistered) in reply to Björn
    Björn:
    The real WTF is using numbers at the beginning of ids.

    The real WTF is nobody else here caught that. As I was looking at the code I was thinking the same thing but your the only one who caught it.

  • (cs) in reply to Andrew
    Andrew:
    Björn:
    The real WTF is using numbers at the beginning of ids.

    The real WTF is nobody else here caught that. As I was looking at the code I was thinking the same thing but your the only one who caught it.

    So your==you're and Andrew==Björn?

  • (cs) in reply to not an expert
    not an expert:
    EvilSnack:
    2. This code is WTFery, but you have to be an expert to see why.
    Are you teasing us? Don't tease us. WHY ARE YOU TEASING US?
    Don't tease us, bro!
  • (cs)

    Simple solution:

    s/9999/999999/

    That ought to make it better. Problem solved.

  • (cs)

    This article is about one of the most persistent anti-patterns I've seen. I can't even guess how many times I've seen algorithms built around random numbers or fractional parts of system time, or similar, and an assumption that somehow there will magically never be a collision.

    A goodie from my current code base, repeated in multiple components: DB2 SQL offers timestamp resolution to the microsecond. So some lameoid takes that microsecond and turns it into a key; "After all, there's no chance that someone else will get the same microsecond value again...it's one in a million. Right?"

  • (cs)

    No idea why some comets are coming down heavily on radio buttons. I think rado buttons have a purpose like all UI element and it is important to know when to use what element.

    Some time check box will do work sometime you need radio button. Just do some clear thinking on requirement and accomplish your goal.

  • (cs) in reply to Nagesh
    Nagesh:
    No idea why some comets are coming down heavily on radio buttons.

    I think you mean 'meteorites'.

  • Sarcasto (unregistered)

    Re: "the way radio-button sets work, only one option from each set can be selected at any time" -- thanks for the tip! as a professional software GUI and Web developer for the past 14 years I had yet to figure out how radio buttons work! /sarcasm

  • n+1 (unregistered)

    "replaced the prefix generator with a page-global counter"

    Surely that means a per-page counter.

  • Anomaly (unregistered) in reply to eViLegion
    eViLegion:
    Nagesh:
    No idea why some comets are coming down heavily on radio buttons.

    I think you mean 'meteorites'.

    I think he means comments.

  • (cs) in reply to faoileag
    faoileag:
    eViLegion:
    If a complaint comes in every month or so, which says "Your website is broken... the pages don't work", then the complainant can fuck off, and not expect the bug to ever get fixed, until they describe it properly
    You do that once with a complainant that has enough clout (like the most valuable customer your company has, like the vice president's daughter, like the side-affair of your boss...) and you might find out that that policy of yours can make your life far more miserable than the one of the complainant.

    Or to put it another way: complainants are customers and usually don't know heck about the terminology/jargon of (web)developers. They might use a browser without knowing what a browser is, is what I'm saying.

    Or how would you feel if the garage attendant sends you away because "funny sounds from under the bonnet" is not a proper description of the problem your car is having?

    You should take pride in being able to diagnose and fix a problem even without a proper problem description.

    Sheesh, some people!

    And how do you plan to fix it when you get a poor description, and are unable to reproduce?

  • (cs) in reply to EvilSnack
    EvilSnack:
    1. Yes, this algorithm/code/technology choice is WTFery, but only in this circumstance; in other places it could have been the best choice.
    1. This code is WTFery, but you have to be an expert to see why.

    Really?

  • (cs) in reply to Anomaly
    Anomaly:
    eViLegion:
    Nagesh:
    No idea why some comets are coming down heavily on radio buttons.

    I think you mean 'meteorites'.

    I think he means comments.

    I think he means plutoids

  • (cs) in reply to Anomaly
    Anomaly:
    eViLegion:
    Nagesh:
    No idea why some comets are coming down heavily on radio buttons.

    I think you mean 'meteorites'.

    I think he means comments.

    What on earth gave you such a silly idea?

  • (cs) in reply to eViLegion
    eViLegion:
    Anomaly:
    eViLegion:
    Nagesh:
    No idea why some comets are coming down heavily on radio buttons.

    I think you mean 'meteorites'.

    I think he means comments.

    What on earth gave you such a silly idea?

    He has brain and he used it. Don't need too much brain cell to figure this out. More brain cell required for making pun like you are doing.

  • PotatoEngineer (unregistered) in reply to cellocgw
    cellocgw:
    Douglas:
    3333, not 2500.

    1/(1-(9998./9999)**3) = 3333.3334

    Sig Figs, man!

    Sig figs are for when you have measurements of a particular precision. In this case, the numbers involved (1, 9999, 9998, etc.) have an infinite number of significant digits, because there's no uncertainty: no chance that the number might actually be 9999.01.

    If this were really something where sigfigs mattered, and every number was in its correct precision, then the answer would be 3000: the "1" would only have 1 sigfig.

  • pezpunk (unregistered) in reply to Will

    personally I like to generate two GUIDS and concatenate them, that way my identifiers are twice as unique.

  • Pock Suppet (unregistered) in reply to Anonymous Paranoiac
    Anonymous Paranoiac:
    TRWTF is Systems Hungarian Notation in the function name. I would have never figured out that "fnCreateRadioButtons" was a function or that iLen was an integer without that extra bit of help. But what really annoys me is when the developer can't think of a meaningful prefix, but knows he must use something and just picks a random character, such as, say 'z' or 'x', even when they impart no meaning, which is worse than imparting clearly obvious meaning. For the record, I have no problem with judicious use of Application Hungarian Notation.
    I prefer the following system: * 'z' = form element * 'v' = variable * 'a' = array * 'o' = object * 'do' = function, as in "doValidateCrapOnPage"

    It's simple, there's no room for confusion, and it works well with the mostly-typeless languages and mostly-clueless code I suffer through at work. Advanced users will appreciate the convention of having "Foo" functions which are secretly called by their "doFoo" brethren.

  • (cs) in reply to xaade
    xaade:
    I hate comboboxes that say credit card type, only to have Visa and Other as options.

    You don't even need a combo box - the first few digits of the card number will tell you the card type.

  • Anonypony (unregistered) in reply to Silfax
    Silfax:
    xaade:
    I hate comboboxes that say credit card type, only to have Visa and Other as options.

    You don't even need a combo box - the first few digits of the card number will tell you the card type.

    So much this.

    I've long suspected that there might be something in the credit card merchant agreement that says "THOU MUST INCLUDE THE NAME OF $CC_COMPANY IN YOUR PROCESSING FORM" as a subtle form of advertising/brand recognition to remind people what card company they use (and therefore trust and like).

  • (cs) in reply to Silfax
    Silfax:
    xaade:
    I hate comboboxes that say credit card type, only to have Visa and Other as options.

    You don't even need a combo box - the first few digits of the card number will tell you the card type.

    4111 1111 1111 1111 5555 5555 5555 4444 3782 8224 6310 005 6011 1111 1111 1117

  • (cs) in reply to Coyne
    Coyne:
    This article is about one of the most persistent anti-patterns I've seen. I can't even guess how many times I've seen algorithms built around random numbers or fractional parts of system time, or similar, and an assumption that somehow there will magically never be a collision.

    A goodie from my current code base, repeated in multiple components: DB2 SQL offers timestamp resolution to the microsecond. So some lameoid takes that microsecond and turns it into a key; "After all, there's no chance that someone else will get the same microsecond value again...it's one in a million. Right?"

    It's a more profound error in reasoning than that. So many people have somehow acquired the idea that "unique values" and "random values" are synonymous. Because they never bother to check this theory, all else flows from this, in an Aristotelean cascade of wrongheadedness.

  • (cs) in reply to da Doctah
    da Doctah:
    Coyne:
    This article is about one of the most persistent anti-patterns I've seen. I can't even guess how many times I've seen algorithms built around random numbers or fractional parts of system time, or similar, and an assumption that somehow there will magically never be a collision.

    A goodie from my current code base, repeated in multiple components: DB2 SQL offers timestamp resolution to the microsecond. So some lameoid takes that microsecond and turns it into a key; "After all, there's no chance that someone else will get the same microsecond value again...it's one in a million. Right?"

    It's a more profound error in reasoning than that. So many people have somehow acquired the idea that "unique values" and "random values" are synonymous. Because they never bother to check this theory, all else flows from this, in an Aristotelean cascade of wrongheadedness.

    Most people are shit at mathematics. The same applies to computer program designers, although the ratio of shit to competent is marginally lower. So it goes.

    The good news is that shit mathematicians program shit programs. The plan is therefore that people don't like shit programs and will use programs written by competent mathematicians. The latter programs will get the respect. To cut a long story short the shit mathematicians will die of starvation. Good riddance to them.

  • Worf (unregistered) in reply to chubertdev
    chubertdev:
    Silfax:
    xaade:
    I hate comboboxes that say credit card type, only to have Visa and Other as options.

    You don't even need a combo box - the first few digits of the card number will tell you the card type.

    4111 1111 1111 1111 5555 5555 5555 4444 3782 8224 6310 005 6011 1111 1111 1117

    It's called Issue Identifier Numbers which are the first 6 digits of a card. And that link has a list of common ones.

  • DarrenC (unregistered) in reply to faoileag
    faoileag:
    Paul Neumann:
    I believe we have found the father of the president's daughter (and my ex-wife).
    You must be more precise in your language. Your sentence can be read as:

    ( ) the president's daugher is your ex-wife ( ) we have found two people, including your ex-wife ( ) the father of the president's daugher is your ex-wife

    You forgot one:

    () The father of the president's daughter is also the father of your wife.

  • Friedrice The Great (unregistered) in reply to Harrow
    Harrow:
    QJo:
    3. Finally, it should be "pontification" not "potification"...
    Are you sure? I thought "potification" means explaining something complicated while under the influence of marijuana while sitting on the toilet.

    -Harrow.

    FTFY.
  • Anonymous Aggie (unregistered) in reply to eViLegion

    Make this featured, please.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Most people are shit at mathematics. The same applies to computer program designers, although the ratio of shit to competent is marginally lower. So it goes.

    The good news is that shit mathematicians program shit programs. The plan is therefore that people don't like shit programs and will use programs written by competent mathematicians. The latter programs will get the respect. To cut a long story short the shit mathematicians will die of starvation. Good riddance to them.

    Who died?

  • Jim (unregistered) in reply to faoileag
    faoileag:
    eViLegion:
    If a complaint comes in every month or so, which says "Your website is broken... the pages don't work", then the complainant can fuck off, and not expect the bug to ever get fixed, until they describe it properly
    You do that once with a complainant that has enough clout (like the most valuable customer your company has, like the vice president's daughter, like the side-affair of your boss...) and you might find out that that policy of yours can make your life far more miserable than the one of the complainant.

    Or to put it another way: complainants are customers and usually don't know heck about the terminology/jargon of (web)developers. They might use a browser without knowing what a browser is, is what I'm saying.

    Or how would you feel if the garage attendant sends you away because "funny sounds from under the bonnet" is not a proper description of the problem your car is having?

    You should take pride in being able to diagnose and fix a problem even without a proper problem description.

    Sheesh, some people!

    I sort of agree with this. The one thing worse than "it doesn't work" descriptions, is "it doesn't work because...."

    Users who think they understand stuff are far more dangerous than users who know their limitations.

    HINT: When deleting Grand Prix, don't touch the file Drivers.ini in the Windows directory. It has nothing to do with your game.

  • do people seriousl not get it (unregistered) in reply to Anomaly
    Anomaly:
    eViLegion:
    Nagesh:
    No idea why some comets are coming down heavily on radio buttons.

    I think you mean 'meteorites'.

    I think he means comments.

    I think he means cars.

  • Hank (unregistered) in reply to Pock Suppet
    Pock Suppet:
    Anonymous Paranoiac:
    TRWTF is Systems Hungarian Notation in the function name. I would have never figured out that "fnCreateRadioButtons" was a function or that iLen was an integer without that extra bit of help. But what really annoys me is when the developer can't think of a meaningful prefix, but knows he must use something and just picks a random character, such as, say 'z' or 'x', even when they impart no meaning, which is worse than imparting clearly obvious meaning. For the record, I have no problem with judicious use of Application Hungarian Notation.
    I prefer the following system: * 'z' = form element * 'v' = variable * 'a' = array * 'o' = object * 'do' = function, as in "doValidateCrapOnPage"

    It's simple, there's no room for confusion, and it works well with the mostly-typeless languages and mostly-clueless code I suffer through at work. Advanced users will appreciate the convention of having "Foo" functions which are secretly called by their "doFoo" brethren.

    doGetUserID

  • mitchell (unregistered) in reply to da Doctah
    da Doctah:
    Coyne:
    This article is about one of the most persistent anti-patterns I've seen. I can't even guess how many times I've seen algorithms built around random numbers or fractional parts of system time, or similar, and an assumption that somehow there will magically never be a collision.

    A goodie from my current code base, repeated in multiple components: DB2 SQL offers timestamp resolution to the microsecond. So some lameoid takes that microsecond and turns it into a key; "After all, there's no chance that someone else will get the same microsecond value again...it's one in a million. Right?"

    It's a more profound error in reasoning than that. So many people have somehow acquired the idea that "unique values" and "random values" are synonymous. Because they never bother to check this theory, all else flows from this, in an Aristotelean cascade of wrongheadedness.

    You're being unfair.

    I generated 1,000 pairs of random numbers and none of the pairs matched. Therefore, random numbers are never the same.

    Excerpt:

    ...
410841	331973
447467	560932
174327	934266
264407	706924
935638	373619
348430	870572
697496	58394
541261	421188
565430	591973
558070	495402
701441	617296
349567	131257
663316	749970
162565	28954
496642	906491
894895	856550
873266	853063
102620	116176
414838	163105
920017	278195
770862	497605
538445	59203
...
  • (cs) in reply to xaade

    It's not really a pun; radio buttons really do have that name because they resemble buttons found on radios.

  • abico (unregistered) in reply to Nyktos
    Nyktos:
    It's not really a pun; radio buttons really do have that name because they resemble buttons found on radios.
    What buttons?! All my radios always had dials. Hey maybe that's what HTML needs, a <dial> tag. Then we can bring back the paddle controls from the Atari 2600, aka potentiometers or "pots" for short. "Potification", indeed.
  • Bill C. (unregistered)

    The best form has two radio buttons and one combo box, and you press all of them.

  • lolatu (unregistered)

    Radio buttons and drop downs suck. You should be using jQuery UI and drag and drop all options. Just create a 'tag cloud' of options with a drop target. But for the sake of a clean design the tag cloud should be hidden from view and be available via edge actions.

  • (cs) in reply to mitchell
    mitchell:
    da Doctah:
    Coyne:
    This article is about one of the most persistent anti-patterns I've seen. I can't even guess how many times I've seen algorithms built around random numbers or fractional parts of system time, or similar, and an assumption that somehow there will magically never be a collision.

    A goodie from my current code base, repeated in multiple components: DB2 SQL offers timestamp resolution to the microsecond. So some lameoid takes that microsecond and turns it into a key; "After all, there's no chance that someone else will get the same microsecond value again...it's one in a million. Right?"

    It's a more profound error in reasoning than that. So many people have somehow acquired the idea that "unique values" and "random values" are synonymous. Because they never bother to check this theory, all else flows from this, in an Aristotelean cascade of wrongheadedness.

    You're being unfair.

    I generated 1,000 pairs of random numbers and none of the pairs matched. Therefore, random numbers are never the same.

    Excerpt:

    ...
410841	331973
[snip]
538445	59203
...

    It isn't a matter of pairs, necessarily. In the system I was taking as my primary example, it is 20 transactions per second, 2-4 minutes per transaction.

    Assuming even flow, at any given time, the temporary table has around 60 active numbers. The probability of a collision is therefore 60/100000 every time a number is generated; 1 in 1667. My probability is not up to snuff, but I would expect 5 to 6 collisions per 8 hour day assuming (big if!) the numbers are evenly distributed. (I am very sure they are not, though I can't characterize it: It is clear that, for some reason, some microsecond values are much more common than others.)

    The facility in question was protecting itself by locking; when a collision occurred one transaction would stop and wait for the other to finish. That was not deliberate design; that was an accident; that is, the algorithm, which was broken, worked by accident due to another consideration. So when someone inadvertently broke the locking strategy for the algorithm...Wham!...multiple failures (40+) during the next 5 hours of operation.

  • (cs) in reply to Coyne
    Coyne:
    mitchell:
    da Doctah:
    Coyne:
    This article is about one of the most persistent anti-patterns I've seen. I can't even guess how many times I've seen algorithms built around random numbers or fractional parts of system time, or similar, and an assumption that somehow there will magically never be a collision.

    A goodie from my current code base, repeated in multiple components: DB2 SQL offers timestamp resolution to the microsecond. So some lameoid takes that microsecond and turns it into a key; "After all, there's no chance that someone else will get the same microsecond value again...it's one in a million. Right?"

    It's a more profound error in reasoning than that. So many people have somehow acquired the idea that "unique values" and "random values" are synonymous. Because they never bother to check this theory, all else flows from this, in an Aristotelean cascade of wrongheadedness.

    You're being unfair.

    I generated 1,000 pairs of random numbers and none of the pairs matched. Therefore, random numbers are never the same.

    Excerpt:

    ...
410841	331973
[snip]
538445	59203
...

    It isn't a matter of pairs, necessarily. In the system I was taking as my primary example, it is 20 transactions per second, 2-4 minutes per transaction.

    Assuming even flow, at any given time, the temporary table has around 60 active numbers. The probability of a collision is therefore 60/100000 every time a number is generated; 1 in 1667. My probability is not up to snuff, but I would expect 5 to 6 collisions per 8 hour day assuming (big if!) the numbers are evenly distributed. (I am very sure they are not, though I can't characterize it: It is clear that, for some reason, some microsecond values are much more common than others.)

    The facility in question was protecting itself by locking; when a collision occurred one transaction would stop and wait for the other to finish. That was not deliberate design; that was an accident; that is, the algorithm, which was broken, worked by accident due to another consideration. So when someone inadvertently broke the locking strategy for the algorithm...Wham!...multiple failures (40+) during the next 5 hours of operation.

    So the real WTF is that the programmer, having generated a random number for the ID of a radio button, didn't check to see he hadn't used that random number before?

Leave a comment on “Don't Touch That Dial!”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article