• FRIST (unregistered)

    frist aksimet no

  • Ikik (unregistered)

    The XBox deal wasn't a % off it was a free $100 amazon gc that you got with that deal only.

  • (cs)

    And this is why things like telephone numbers should be stored as strings. Yes, even if it fits into a "long long".

  • (cs)

    It's obviously asking if you want 32, 64, or 10 dollars cash back. Haven't you ever seen an old-school assembler where hex values are marked with '$'?

  • (cs) in reply to FRIST
  • (cs)

    Wow, TDWTF does weekends now? Nice...

  • (cs)

    Red is such a soothing colour...

  • Matt (unregistered)

    I see no problem with the first one. This atm is just using hex notation.

    0x20 = $32 0x40 = $64 0xA = $10

  • Animal (unregistered)

    Aaah come on you are getting a full cent discount on the Xbox, that's a 0.0033334444481% discount you innacurate twat.

  • Sehe (unregistered)

    Heh. The VS2010 Bug is actually a real bug encountered by many users:

    http://connect.microsoft.com/VisualStudio/feedback/details/565866/conversion-from-vs-2008-solutiona-and-projects-to-vs-2010-fails

  • (cs)

    It used to be that before 1995 you COULD store US phone numbers in a 32 bit word. You changed the area code from N(0/1)X to (0/1)NX and then the 7 digits. It worked out wonderfully. The max number was something like 199 999 9999 (original number 919/999-9999), and fit nicely into 32 bits. After 1995, they had digits other than 1 & 0 as the middle digit of area codes and LOTS of software needed to be changed, along with PBX updates.

    Now we store phone numbers as nice strings, even though they are all digits. We seem to want to punctuate then and add all sorts of silly prefixes so idiots don't need to think when they are dialing them (which is a further WTF for another day).

  • (cs) in reply to herby
    herby:
    It used to be that before 1995 you COULD store US phone numbers in a 32 bit word. You changed the area code from N(0/1)X to (0/1)NX and then the 7 digits. It worked out wonderfully. The max number was something like 199 999 9999 (original number 919/999-9999), and fit nicely into 32 bits. After 1995, they had digits other than 1 & 0 as the middle digit of area codes and LOTS of software needed to be changed, along with PBX updates.

    Now we store phone numbers as nice strings, even though they are all digits. We seem to want to punctuate then and add all sorts of silly prefixes so idiots don't need to think when they are dialing them (which is a further WTF for another day).

    How do you propose storing a list of digits? Considering a digit is represented on a computer as a character, isn't a string the obvious choice?

    Storing it as a number is wrong for so many reasons. It will only save you some memory, but it will:

    • Make your application rely on a particular length (and even a specific set of possible prefixes), causing the kind of problems you mentioned.
    • Make some database tasks ridiculously hard, like doing a search for similar telephone numbers, or numbers with the same prefix.
    • Allow you to do a lot of useless things, like multiplying telephone numbers.

    The fact is, a telephone number consists of digits, but it is an address. It has none of the properties of mathematical numbers, and all the properties of addresses. There is no reason to counter-intuitively store it as an integer, unless you desperately need the disk size.

  • Brendan (unregistered) in reply to briverymouse

    Hi,

    briverymouse:
    The fact is, a telephone number consists of digits, but it is an address. It has none of the properties of mathematical numbers, and all the properties of addresses. There is no reason to counter-intuitively store it as an integer, unless you desperately need the disk size.

    Can you confirm the rumours that American telephone exchanges are all changing over to regex based switching? Thanks.

    • Brendan
  • Bruce W (unregistered)

    I want my A dollars!

  • Someone (unregistered)

    Duh, A is 10, of course.

  • mickey (unregistered)

    All the twats saying $A is hex know squat!!!

    The A represents ALL. You select this to take ALL The money out of your account, and ship it to Nigeria (www.nigeriagoogle.com)

  • (cs)

    Taiwan one screams of machine translation. I see this first person singular stuff all the time at rakuten: http://plaza.rakuten.co.jp

    (WTF? Firefox doesn't let us copy the scheme portion of a URI anymore? Bad enough they stopped displaying it ... )

  • (cs) in reply to briverymouse
    briverymouse:
    And this is why things like telephone numbers should be stored as strings. Yes, even if it fits into a "long long".

    I regularly have to throw s/w back to the Dev team for storing tel nos in a number field. That's what QA is for, you - you - ... you COBOL programmers!.

  • Dazed (unregistered) in reply to herby
    herby:
    It used to be that before 1995 you COULD store US phone numbers in a 32 bit word. ... It worked out wonderfully...
    herby:
    ... and LOTS of software needed to be changed ...
    Your second statement rather comprehensively contradicts your first. As briverymouse indicates, storing phone numbers as a numeric field is the work of programmers who don't understand what they are doing. (I might give a pass to people working prior to 1980, when every byte counted.)
  • (cs) in reply to Dazed
    Dazed:
    herby:
    It used to be that before 1995 you COULD store US phone numbers in a 32 bit word. ... It worked out wonderfully...
    herby:
    ... and LOTS of software needed to be changed ...
    Your second statement rather comprehensively contradicts your first. As briverymouse indicates, storing phone numbers as a numeric field is the work of programmers who don't understand what they are doing. (I might give a pass to people working prior to 1980, when every byte counted.)
    No contradiction, just missing the important part of the quote. It worked out wonderfully, until changes came along that it wasn't prepared for. Then it broke horribly.
  • Thomas Winwood (unregistered) in reply to Matt Westwood

    Hey, hey, no need for that kind of language.

  • Philip Newton (unregistered)

    Similarly with postal codes - they look like numbers (in many countries) but don't have the properties of numbers, and should be stored as strings.

    Having leading zeroes dropped (if postal codes can start with 0, as they can at least in the US and Germany) is the least of the problems you get by treating them as numbers.

    They're strings! You can't calculate with them meaningfully, so store them as an opaque item.

  • Peter (unregistered) in reply to Matt Westwood
    Matt Westwood:
    I regularly have to throw s/w back to the Dev team for storing tel nos in a number field. That's what QA is for, you - you - ... you COBOL programmers!.
    Matt, I've noticed that you frequently use bad language in your postings. This time, however, you've really gone too far. Don't do it again.
  • DSkoll (unregistered) in reply to briverymouse
    briverymouse:
    The fact is, a telephone number consists of digits, but it is an address. It has none of the properties of mathematical numbers...

    "The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."

    (Seen in ancient times on USENET.)

  • (cs)

    RE that Office Communicator issue: It looks like Microsoft has been hiring Lotus Notes programmers away from IBM.

  • (cs)

    Visual Studio: "You can cancel the requested action. If you do, the project loading will continue and you can try to perform the action again later."

    WTF? Does that mean that even if I cancel, the loading will continue? What is the cancel button for, then?

  • (cs) in reply to TheRider

    It cancels the action.

    It doesn't cancel the loading.

    It also doesn't cancel the thunderstorm outside, or your cat hollering at you to be fed.

  • (cs)
    <rant> Storing phone number in a real. Sigh.

    Barcodes, category UPC. Social Security Number (SSN). Phone numbers. Zip code. Password, category "PIN". Street number.

    When will programmers learn the difference between numeric values that need to be processed mathematically and external identifiers they don't control, and stop storing the later in numeric columns?

    We just went through this yet again: A sister organization needs to use fake SSN's for people that don't want to provide a real one. They suggest values of the form A00-00-0000, and we have to decline. Because of the possibility that some idiot third-party designer for another sister system is storing SSN in an INTEGER.

    This anti-pattern may not be the biggest WTF ever, but it ranks high. </rant>

  • (cs)

    Use $A if you want to get Australian money out.

  • Vamp (unregistered)

    Am I the only one that thinks the YES/NO/CANCEL style dialogs are good practice? Even if in this case NO and CANCEL do the same thing, I've always thought that CANCEL option is for 'leave the things as they were, do not change anything'.

    It's like hitting undo when you did something you didn't want to :)

  • (cs) in reply to Coyne
    Coyne:
    Barcodes, category UPC. Social Security Number (SSN). Phone numbers. Zip code. Password, category "PIN". Street number.

    When will programmers learn the difference between numeric values that need to be processed mathematically and external identifiers they don't control, and stop storing the later in numeric columns?

    Except for your last example.

    Because unlike the others, there is at least one way in which street numbers are treated arithmetically, albeit only in an ordinal sense and not necessarily as interval or ratio scales, and that's having a definitive lower and upper limit.

    If someone hands you an address on Whatchajiggy Street, and you happen to know that addresses on Whatchajiggy Street only run from 1900 through 8000 (where beyond the upper limit Whatchajiggy Street turns into Howzamacallit Parkway), you can do a range check and reject an obviously wrong address like 22246 (the guy meant to enter 2246 but his finger bounced on the key and he didn't realize it at the time). And you can even reject 8170 as invalid, which makes this different from the ones where someone just puts in too many digits.

  • (cs) in reply to Vamp
    Vamp:
    Am I the only one that thinks the YES/NO/CANCEL style dialogs are good practice?
    Better practice would be labelling the buttons with what they actually do: "Remove this contact from your contact list? [Remove] [Don't remove] [Cancel]" — but like many others I still don't see what the Cancel button would do here that differs from the function of the No (or Don't Remove) button.
  • Decius (unregistered) in reply to herby
    herby:
    It used to be that before 1995 you COULD store US phone numbers in a 32 bit word. You changed the area code from N(0/1)X to (0/1)NX and then the 7 digits. It worked out wonderfully. The max number was something like 199 999 9999 (original number 919/999-9999), and fit nicely into 32 bits. After 1995, they had digits other than 1 & 0 as the middle digit of area codes and LOTS of software needed to be changed, along with PBX updates.

    Now we store phone numbers as nice strings, even though they are all digits. We seem to want to punctuate then and add all sorts of silly prefixes so idiots don't need to think when they are dialing them (which is a further WTF for another day).

    No, +(country code)(area code)(exchange)(number) e.g. +13606625202 IS a the proper way to display a phone number, as as +1-360-662-5202. The + and country code may be omitted ONLY when displaying the phone number to a known audience, in which case it should be replaced with their specific sequence (e.g. 9-5202, or speed code 7) (Nextel Worldwide Customer Apathy number, for those of you who wish to dial every number you see.)

  • Decius (unregistered) in reply to da Doctah
    da Doctah:
    Coyne:
    Barcodes, category UPC. Social Security Number (SSN). Phone numbers. Zip code. Password, category "PIN". Street number.

    When will programmers learn the difference between numeric values that need to be processed mathematically and external identifiers they don't control, and stop storing the later in numeric columns?

    Except for your last example.

    Because unlike the others, there is at least one way in which street numbers are treated arithmetically, albeit only in an ordinal sense and not necessarily as interval or ratio scales, and that's having a definitive lower and upper limit.

    If someone hands you an address on Whatchajiggy Street, and you happen to know that addresses on Whatchajiggy Street only run from 1900 through 8000 (where beyond the upper limit Whatchajiggy Street turns into Howzamacallit Parkway), you can do a range check and reject an obviously wrong address like 22246 (the guy meant to enter 2246 but his finger bounced on the key and he didn't realize it at the time). And you can even reject 8170 as invalid, which makes this different from the ones where someone just puts in too many digits.

    Do you think that maintaining a database of legitimate street numbers is less trivial than comparing a street address to them? How often do you need to check if a street number is real, if not just once on initial validation?

  • (cs) in reply to da Doctah
    da Doctah:
    Because unlike the others, there is at least one way in which street numbers are treated arithmetically, albeit only in an ordinal sense and not necessarily as interval or ratio scales, and that's having a definitive lower and upper limit.
    This may make sense in American-style addresses, but not in most European countries where numbers aren't assigned in blocks but simply start at 1 for every street and are incremented by 1 per building in the street, with no definite upper limit. Also, you might encounter a number like 7a because a new house was built between nos. 7 and 9, but renumbering the whole street would cause more confusion than it's worth.
  • (cs) in reply to da Doctah
    da Doctah:
    Coyne:
    Barcodes, category UPC. Social Security Number (SSN). Phone numbers. Zip code. Password, category "PIN". Street number.

    When will programmers learn the difference between numeric values that need to be processed mathematically and external identifiers they don't control, and stop storing the later in numeric columns?

    Except for your last example.

    Because unlike the others, there is at least one way in which street numbers are treated arithmetically, albeit only in an ordinal sense and not necessarily as interval or ratio scales, and that's having a definitive lower and upper limit.

    Subdivisions.

    12A Example Street

    12C/455 Example Street

  • Vamp (unregistered) in reply to Gurth
    Gurth:
    Vamp:
    Am I the only one that thinks the YES/NO/CANCEL style dialogs are good practice?
    Better practice would be labelling the buttons with what they actually do: "Remove this contact from your contact list? [Remove] [Don't remove] [Cancel]" — but like many others I still don't see what the Cancel button would do here that differs from the function of the No (or Don't Remove) button.

    Cancel and No would do the same here, however it's more convenient for the user to see that cancel button, so he can safely click it without even reading the dialog message - if he clicked it by accident.

  • (cs) in reply to Gurth
    Gurth:
    This may make sense in American-style addresses, but not in most European countries where numbers aren't assigned in blocks but simply start at 1 for every street and are incremented by 1 per building in the street, with no definite upper limit. Also, you might encounter a number like 7a because a new house was built between nos. 7 and 9, but renumbering the whole street would cause more confusion than it's worth.
    I vote we put this debate to bed. We should use a shotgun to make sure it doesn't rear its ugly head again.

    I lived for ten years on a street in a town in Sussex, England, where there were numbered houses in a fairly conventional fashion, from 1 at the top to 12 at the bottom, with evens on one side and odds on the other. OK so far. Up the hill from number 1 were five or six houses with names but not numbers, but they were still on the same street.

    Then my father chased a job to the US, and we lived for a while on a street with maybe two dozen houses. We were in the middle, number 914. The houses to either side were 900 and 920, or something like that, and in fact the number space of the street was fairly sparse, because they weren't house numbers. Each house was numbered for the land plot it was on (or, actually, one of them, because the numbered plots were fairly small).

    And don't forget these things that screw up your convenient scheme for European street addresses:

    • A street in, I believe, Hamburg (Germany) which is numbered in chronological order of construction, so 1 is at one end, 2 the other, and 3 in the middle, etc.

    • Boundary Road / Station Road in Portslade and in Hove (part of Brighton-and-Hove) (both these places are in Sussex, but not the same part of Sussex). OK, streets with different names in different parts of them are common. These two names, however, apply to the two sides of the road, not the two ends.

    tl;dr. Conclusion: the "numbers" in street addresses are just oddly-shaped letters. They are not digits, and do not form numbers.

  • meme (unregistered)

    Somebody set up open-chan the impossibility!

  • (cs) in reply to briverymouse
    briverymouse:
    The fact is, a telephone number consists of digits, but it is an address. It has none of the properties of mathematical numbers, and all the properties of addresses. There is no reason to counter-intuitively store it as an integer, unless you desperately need the disk size.
    On the other hand, you could consider it to be a unique identifier - and those are often numbers. (Except if you're working with Siebel, in which case it's a 64-byte string.)

    TRWTF is that we're still using MSISDNs (mobile phone numbers) on mobile phones, whereas each SIM card has its own unique identifier (IMSI). Which, um, is a 15-digit string.

    But yeah, being an opco, we work a lot with telephone numbers, and whoever decides to store them as a number has a thing or two to explain to me.

  • (cs) in reply to Steve The Cynic
    Steve The Cynic:
    And don't forget these things that screw up your convenient scheme for European street addresses:
    Don't forget Florence. In Florence, they reuse the numbers on certain streets, but they're the 'red' and the 'black' numbers. Red numbers are for shops and businesses, whereas black numbers are for private residences.

    Why? Well, why not? Probably, it seemed a good idea at the time.

  • Emil Vikström (unregistered)

    $A is exactly equal to the integer 65 in Erlang, where these are all integer values:

    65 $A 16#14

  • (cs) in reply to Emil Vikström

    Time to get another bank.

  • Chuck (unregistered)

    In defense of the Rock Band Facebook app, Roger has conveniently cropped out the giant "BETA" banner at the end of the title, and this was apparently cleaned up pretty quickly since I started using that app a few days after launch and never saw this message.

    If there's a TRWTF it's not having "TODO:" at the beginning of the message to make it easy to find for replacement later.

  • Yiroep (unregistered)

    I pity the FooBar.

  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    Gurth:
    This may make sense in American-style addresses, but not in most European countries where numbers aren't assigned in blocks but simply start at 1 for every street and are incremented by 1 per building in the street, with no definite upper limit. Also, you might encounter a number like 7a because a new house was built between nos. 7 and 9, but renumbering the whole street would cause more confusion than it's worth.
    I vote we put this debate to bed. We should use a shotgun to make sure it doesn't rear its ugly head again.
    And then there are places where the street isn't even used. In Japan, addresses are based on the block you're located in, and are not even guaranteed to be sequential going around the block.
  • Caboliou (unregistered) in reply to Severity One
    Severity One:
    Don't forget Florence. In Florence, they reuse the numbers on certain streets, but they're the 'red' and the 'black' numbers. Red numbers are for shops and businesses, whereas black numbers are for private residences.

    Why? Well, why not? Probably, it seemed a good idea at the time.

    Why ? This is just a guess but maybe long ago many merchants lived in a house near their shop. So using the same number for the shop and the house could have been more convenient ?

  • Peter (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    * Boundary Road / Station Road in Portslade and in Hove (part of Brighton-and-Hove)
    By a strange coincidence, I'm reading Steve's comment from an address about 50 yards away from that road.
  • Dave-Sir (unregistered) in reply to lolwtf
    lolwtf:
    Dazed:
    herby:
    It used to be that before 1995 you COULD store US phone numbers in a 32 bit word. ... It worked out wonderfully...
    herby:
    ... and LOTS of software needed to be changed ...
    Your second statement rather comprehensively contradicts your first.
    No contradiction, just missing the important part of the quote. It worked out wonderfully, until changes came along that it wasn't prepared for. Then it broke horribly.
    I don't think "worked until it broke" is an example of "worked out wonderfully."
  • (cs) in reply to SQLDave

    TRWTF is using the Microsoft Office Communicator client instead of Pidgin + SIPE

Leave a comment on “Variable Cash Back”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article