• fleg (unregistered) 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.

    Lucky you're not one to respond to trolls....
  • (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?"

    I'm disappointed nobody's said something like this, "And one in a million chances happen nine times out of ten."

    Sheesh!

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    I'm disappointed nobody's said something like this, "And one in a million chances happen nine times out of ten."

    Sheesh!

    Ninety percent of people have never taken a formal class in probability or statistics. And the other fifty percent have forgotten everything they learned.

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

    Failure to communicate in a sane way is nothing to do with lack of understanding of a technology. I would actually expect a sensible mechanic to open the bonnet and listen if someone made that statement... However when it comes to computers and internet, people seem to be utterly retarded. "It doesn't work" does not even begin to explain the problem. Rather frustratingly, most people who use that description then follow up with "I'm not good with computers" as an excuse for their shitty descriptions.

    If you walk into a doctors office and say "I think I have a medical condition" and then refuse to answer any further questions because "I'm not good with medicine", then you can't expect the doctor to even know what part to start looking at.

    Failure to communicate observations has nothing to do with jargon or terminology. It's pure stupidity, and the internet is growing it like mould on an old piece of toast.

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    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?"

    I'm disappointed nobody's said something like this, "And one in a million chances happen nine times out of ten."

    Sheesh!

    Oh just shoot him in his voonerables.

  • faoileag (unregistered) in reply to tin
    tin:
    faoileag:
    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?
    I would actually expect a sensible mechanic to open the bonnet and listen if someone made that statement...
    Same here, I was using that car-related error description as a metaphor. I would expect a sensible developer to look at the problem the complainants are complaining about.
    tin:
    However when it comes to computers and internet, people seem to be utterly retarded. "It doesn't work" does not even begin to explain the problem.
    But the complainants coming to Bjørn were far better than that - to quote from the article "Bjørn was always baffled by the occasional complaints he'd receive from users, [b]reporting that the filtering and categorization functions on many of the application's pages were broken[b]" That's a pretty precise problem description for a non-techie.
  • (cs) in reply to Matt Westwood
    Matt Westwood:
    Steve The Cynic:
    I'm disappointed nobody's said something like this, "And one in a million chances happen nine times out of ten."

    Sheesh!

    Oh just shoot him in his voonerables.

    Thank goodness someone recognised the reference. I was a little worried by the other post, some blither about statistics...

  • CigarDoug (unregistered) in reply to QJo
    QJo:
    JimmyCrackedCorn:
    QJo:
    JimmyCrackedCorn:
    TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

    From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

    The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

    The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

    Oh, and while I'm about it, grammar fail:

    1. It should be "The use (of radio buttons) is ok" - the number of the verb must agree with its subject, not just the noun which happens to be closest, which in this case is the word "buttons" in the qualifying clause (emphasised by me as being a separate linguistic entity by parenthesising it) "of radio buttons".

    2. It should be "it is their implementation in HTML that sucks", a similar mistake but in the opposite direction. The subject of the verb "sucks" is in this case "(their) implementation", not "their". Compare: "The children are crying because their ball are lost", which exhibits the same error but in a more obviously incorrect context.

    3. Finally, it should be "pontification" not "potification", but I will allow that this mistake may well be just a typo caused by carelessness rather than a genuine spelling mistake caused by ignorance.

    Behold, the Col. Hans Landa of Grammar Nazis! Most impressive, sir.

  • Old 30-year veteran (unregistered) in reply to JimmyCrackedCorn
    JimmyCrackedCorn:
    TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

    I just want to thank you.

    Folks like you who obviously do not grasp the fundamentals of User Interface Design are what have kept food on my family for this entire century (and the decade before that).

    For the newbs who don't already know everything: if the number of choices is ~=< 5, use radio buttons. Avoid combo boxes (or "dropdown lists", which are the same thing) when the number of choices is small as they are harder to use on mobile and by older/inexperienced folks.

    If the list is very long, using a filterable combobox (example) will make your users' lives easier.

  • Jay (unregistered) in reply to JimmyCrackedCorn
    JimmyCrackedCorn:
    TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

    What a bizarre statement. You say that radio buttons should be used "sparingly", which means that you acknowledge that there are at least some times when they are appropriate. Then, with zero information about what choices he was showing as radio buttons, the layout of the page, or anything else about the application, you conclude that radio buttons were inappropriate in this instance. How could you possibly know?

  • Jay (unregistered) in reply to ABBA
    ABBA:
    I don't even read the stories anymore. I just come straight to the comments. If there's one thing I've learnt from the internet is that reading and/or understanding something just hinders your ability to effectively criticise it.

    A good general rule that many people follow: Never allow complete ignorance of a subject to prevent you from having strong opinions about it.

  • Norman Diamond (unregistered) in reply to tin
    tin:
    faoileag:
    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?
    I would actually expect a sensible mechanic to open the bonnet and listen if someone made that statement...

    If you walk into a doctors office and say "I think I have a medical condition" and then refuse to answer any further questions because "I'm not good with medicine", then you can't expect the doctor to even know what part to start looking at.

    If you walk into a veterinarian's office and say "I think my cat has a medical condition" then I would expect the vet to look at the cat.

    We have to think of our customers as cars or cats. The user doesn't know what's wrong with them, and we have to tell them to bring their computer or car or cat to us so we can look at it.

  • (cs) in reply to Norman Diamond
    Norman Diamond:
    If you walk into a veterinarian's office and say "I think my cat has a medical condition" then I would expect the vet to look at the cat.

    ? LOOK AT CAT It looks like a regular house cat.

    ? LOOK AT CATS EYES The cat meets your gaze with its green eyes for a moment, but then looks away shyly.

    ? LOOK AT CATS TAIL The cat's tail flickers back and forth slowly.

    ? LOOK AT CATS BODY It looks like a regular cat. It has fur, and it's not too fat. It's just a regular cat.

    ? LOOK AT CATS FEET You look at the cats paws. The cat uses them to walk, and to climb, and sometimes to shred its owners furniture. Its claws are currently retracted.

    ? LOOK AT CATS ANUS What are you, some kind of sicko?

    ? ASK OWNER ABOUT MEDICAL CONDITION Ask the owner? What the hell? You're a vet -- just look at the damned cat and fix it!

    ? LOOK AT CAT It looks like a regular house cat.

    Your assistant enters the office and asks if you'll be long -- you're running over time for your next appointment.

    ? TELL ASSISTANT I'LL BE DONE IN A MOMENT What?

    ? LOOK AT ASSISTANT You don't see an assistant here.

    The cat's owner is getting impatient.

    ? LOOK AT CAT It looks like a regular house cat.

    ? ASK OWNER IF CAT HAS BEEN VOMITING Ask the owner? What the hell? You're a vet -- just look at the damned cat and fix it!

    ? LOOK AT CATS TONGUE The cat doesn't enjoy that, but you do manage to ascertain that it does indeed have a tongue, and it appears to be like a normal cat's tongue.

    ? ASK CAT WHAT IS WRONG The cat does not seem interested in conversation at the moment.

    The owner looks at you incredulously.

    ? PET CAT ON THE HEAD You pet the cat on the head. It is furry and pleasant to the touch. The cat purrs.

    The owner is making an obvious show of looking at their watch.

    Your assistant comes in and asks how much longer you'll be.

    ...

  • duis (unregistered) in reply to lolatu

    indeed, lol at u.

    Let's say you need to have your form be the interface a desk human needs to use to process a very long line of, let's say, attendees of some sort. Congratulations! you have no reasonable keyboard interface, so you've made everyone wait some factor longer. However, I will concede that drag and drop is, uh, drag and drop-ier.

    Or let's say you have some manual QA happening, Congratulations! the QA person will curse your name for forcing them to mouse around every time they get to your tots not teh suck page which uses drag and drop exclusively.

  • Norman Diamond (unregistered) in reply to nomdeplume
    nomdeplume:
    Norman Diamond:
    If you walk into a veterinarian's office and say "I think my cat has a medical condition" then I would expect the vet to look at the cat.
    ? LOOK AT CAT It looks like a regular house cat.

    ? LOOK AT CATS EYES The cat meets your gaze with its green eyes for a moment, but then looks away shyly.

    ? LOOK AT CATS TAIL The cat's tail flickers back and forth slowly.

    ? ASK OWNER ABOUT MEDICAL CONDITION Ask the owner? What the hell? You're a vet -- just look at the damned cat and fix it!

    Sorry to be pedantic, but in fact that was the case. We knew the cat was weak but we didn't know why. The vet diagnosed pneumonia.

    This reminds me though, Dungeon version 2.6 or something like that was spread all over the net, but I got Dungeon 3.0 working under NT around 1999 or so. I should put it somewhere where it can be downloaded by other old fogies who know real adventurers use text consoles.

  • Norman Diamond (unregistered)

    P.S. Some time before we got the cat, the animal shelter took the cat to a veterinarian and said...

    "It ain't broke. Fix it."

  • lolatu (unregistered) in reply to duis
    duis:
    indeed, lol at u.

    Let's say you need to have your form be the interface a desk human needs to use to process a very long line of, let's say, attendees of some sort. Congratulations! you have no reasonable keyboard interface, so you've made everyone wait some factor longer. However, I will concede that drag and drop is, uh, drag and drop-ier.

    Or let's say you have some manual QA happening, Congratulations! the QA person will curse your name for forcing them to mouse around every time they get to your tots not teh suck page which uses drag and drop exclusively.

    Dude get with the times. No one uses a mouse anymore. This is the optimal experience in the post-PC touchscreen world we live in.

    [CAPTCHA damnum -- damnum to hell!]

  • foxyshadis (unregistered) in reply to The MAZZTer
    The MAZZTer:
    I have a similar issue with a web app we develop that might have to, in theory (if it was flexible enough), generate the same HTML code multiple times on the same page. Of course IDs are hard coded and the code uses .innerHTML to generate the code and .getElementById to retrieve references to elements. Once you generate a second copy of the HTML everything breaks.

    My own code uses classes for all CSS-styling, uses DOM-style generation and retains references to critical nodes it'll need later, and uses a UID generator to generate any IDs I DO need.

    That web app has all sorts of WTFs that would be good for this site, including a drag-and-drop module that attempts to poorly partly recreate the DOM hierarchy for drag and drop (by having coders manually declare all drop regions as HTML elements and bounding regions), all so that it can put a "dragging this thing" image under the cursor and figure out what's behind it based on X/Y coords (since e.target only returns the image). Has to support IE so no pointer-events: none;

    I personally would have just generated a custom .cur for each image they wanted in front of the cursor. But that would have been far easier.

    Get ye to the sidebar!

  • foxyshadis (unregistered) in reply to Nagesh
    Nagesh:
    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.

    But not multi-select list boxes. Those are a horrifying accident and have no place whatsoever in any context, no matter how much you try to highlight your "hold control to make multiple selections" tip.

    Single-select list boxes are OK and more compact than radio buttons without the click-me annoyance of a drop down. Then it's down to designer preference.

  • foxyshadis (unregistered) in reply to Old 30-year veteran
    Old 30-year veteran:
    JimmyCrackedCorn:
    TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

    I just want to thank you.

    Folks like you who obviously do not grasp the fundamentals of User Interface Design are what have kept food on my family for this entire century (and the decade before that).

    For the newbs who don't already know everything: if the number of choices is ~=< 5, use radio buttons. Avoid combo boxes (or "dropdown lists", which are the same thing) when the number of choices is small as they are harder to use on mobile and by older/inexperienced folks.

    If the list is very long, using a filterable combobox (example) will make your users' lives easier.

    This reminds me of a particular anti-pattern I see occasionally: Filterable comboboxes that round-trip to the server for every single letter typed. If the server is slow, you're never going to see your cute list as you type, just that eternally spinning throbber.

    Obviously, that's required for search and other big data operations, but many operations have a small enough set of possibilities that they can be easily downloaded and stored for local filtering.

  • blarsen (unregistered) in reply to faoileag
    faoileag:
    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 :-)

    You're correct, the values of the radio buttons are used for jQuery DataTable filtering.

  • blarsen (unregistered) in reply to Björn
    Björn:
    The real WTF is using numbers at the beginning of ids.
    Yes, that is a WTF. And I fixed that in this function once I was in there to do something with the ID generation. Sadly, numeric IDs are rife in the application and can be found in Javascript code, in Java code, in JavaScript code generated by Java code and probably elsewhere as well.

    Bjørn

  • urza9814 (unregistered) in reply to Norman Diamond
    Norman Diamond:
    tin:
    faoileag:
    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?
    I would actually expect a sensible mechanic to open the bonnet and listen if someone made that statement...

    If you walk into a doctors office and say "I think I have a medical condition" and then refuse to answer any further questions because "I'm not good with medicine", then you can't expect the doctor to even know what part to start looking at.

    If you walk into a veterinarian's office and say "I think my cat has a medical condition" then I would expect the vet to look at the cat.

    We have to think of our customers as cars or cats. The user doesn't know what's wrong with them, and we have to tell them to bring their computer or car or cat to us so we can look at it.

    See, I would expect the vet to respond by asking "What makes you think that?" If your vet doesn't, I suggest you seek one who actually knows what the heck he's doing.

    Again, you don't tell the vet "I think my cat has a medical condition" -- you tell the vet "My cat isn't eating as much as usual" or "my cat limps" or "my cat keeps coughing".

    And if the vet can't find a cause and nothing seems obviously wrong, he'll tell you nothing is wrong with you cat and give it back to you -- which is the vet's way of saying "CLOSED: Could not reproduce"

  • urza9814 (unregistered) in reply to xaade
    xaade:
    JimmyCrackedCorn:
    QJo:
    JimmyCrackedCorn:
    TRWTF is the use of radio button groups as a design choice. In HTML they should be used sparingly. Dropdown lists or combo boxes would have been a better choice.

    From which fount of wisdom gushes this invigorating cup of advice? Is it a similar place to "don't use tabs, use spaces"?

    The real WTF is paying attention to so-called guru sites which pontificate on best practices without expounding as to why. If a reason is provided, then one is able to glean some understanding of whether the advice is relevant and appropriate to the page in question.

    The use of radio buttons are ok as a visual choice, but it is their implementation in HTML that suck, as well as making it harder for developers to make them work correctly. There, potification with explanation.

    What, having shared group names? I suppose you could put them in a div and somehow work out that's a group. However, do you really need a groupbox around every set of radio buttons?

    Yes, you do. It's an integral part of how they function.

    Of course, you need a <select> box around any set of combobox elements, so it's basically the same thing...

  • Alsee (unregistered)

    Easy fix, works fine now: var prefix = Math.floor((Math.random() * 19999) + 1)

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

Log In or post as a guest

Replying to comment #:

« Return to Article