• (cs) in reply to Schol-R-LEA
    Schol-R-LEA:
    That it only handles US style mailing addresses, and poorly at that

    There are many cheap providers of address verification. The expensive ones will charge half a penny per lookup.

    Unless your company is the size of Amazon, writing this from scratch is a WTF. And if your company is the size of Amazon, you pay the annual fee to USPS for a direct access to their API and you're done.

  • (cs) in reply to pjt33
    pjt33:
    The example given for "A building number will only be used once per street" is of two addresses in different towns.
    Be that as it may, when we were looking for carpet places a year or two ago, we couldn't find one of them at the address we'd copied down - it turned out that it was the *other* number 367 on the same street, about 10 blocks away.
  • (cs) in reply to Ronald
    Ronald:
    The expensive ones will charge half a penny per lookup.
    The expensive ones might also handle international validation, which is a lot more complicated. (Or they might just be overcharging asses.)
  • rt (unregistered) in reply to C-Derb
    C-Derb:
    no laughing matter:
    C-Derb:
    Sometimes the potential of a handful of international clients isn't worth the trouble of planning for them. Catering to your largest market, not the smallest, usually produces better results. Maybe, just maybe, mailing stuff to international addresses is too "annoying" and this is their way of discouraging you from using their service. You aren't worth it.
    Wait what? More than 50% of the world population (even much more, as the rest is only "a handful") now live in the USA?

    Learnt something new today!

    See, you assume that all businesses that use the internet and collect addresses will at some point want to cater to the entire world. But that's because you are an ass.

    Take, for example, pizza delivery. Why would my local pizza joint, over 1000 miles from any other country, spend any money or time at all to support international addresses when their delivery area is limited to, maybe 20 miles?

    We can debate why they'd want to do any address validation at all (probably needless), but for damn sure they don't need to consider international addresses.

    Of course it would make no sense for pizza joints to support international addresses. Hower if a website offers international shipment, they should support international addresses.

    Another example : airlines need foreigners going to the US (or in transit through the US) to fill a form with their destination address. Going from Canada to Europe via New-York, I had to fill this form. Required field for my destination address? A drop-down menu with only US states. TRWTF is that it was on a european airline website... Do you think their largest market is US customers too?

  • JWB (unregistered) in reply to Svempa

    Looks like C# to me.

  • (cs)

    Previously, I have written a DB project that included validations for the postal codes, where I stored a regular expression in the Country table. Canada uses one style of code. The US has two (Zip and Zip+4), which can be easily handled by regular expressions.
    Canada: [A-Z][0-9][A-Z] [0-9][A-Z][0-9] USA: [0-9]{5}(-[0-9]{4})? What is the UK doing? The lengths and letter/digit placement rules seem to be all over the place.

  • nitePhyyre (unregistered) in reply to rt
    rt:
    Why isn't there a big white text box where I can type in my adress the way I want? That's my problem if I screw it up.
    Because that makes analytics harder/impossible. If I separate out all the fields and validate them, I can then easily select everyone in a region using their state or postal code. I can create a report to view my sales in a particular region of a country. If they write whatever they want for addresses, it is far harder to do that.

    They might write it in a weird format, adding or removing spaces. Maybe they'll write an abbreviation, maybe they'll invent their own incorrect abbreviation.

  • (cs) in reply to Ronald
    Ronald:
    Schol-R-LEA:
    That it only handles US style mailing addresses, and poorly at that

    There are many cheap providers of address verification. The expensive ones will charge half a penny per lookup.

    Unless your company is the size of Amazon, writing this from scratch is a WTF. And if your company is the size of Amazon, you pay the annual fee to USPS for a direct access to their API and you're done.

    in my limited experience of dealing with north america (us and canada), I have noticed that PC MIller is best thing to get addresses from.

  • anonymous (unregistered) in reply to Scarlet Manuka
    Scarlet Manuka:
    pjt33:
    The example given for "A building number will only be used once per street" is of two addresses in different towns.
    Be that as it may, when we were looking for carpet places a year or two ago, we couldn't find one of them at the address we'd copied down - it turned out that it was the *other* number 367 on the same street, about 10 blocks away.
    Probably either 367 N Main St 367 S Main St

    or else 367 Prairie Ln 367 Prairie Dr

    What's really fun is, in the latter case, when the street signs are inconsistent, and putting the name found on the nearest street sign into Google may actually take you somewhere else.

    And then you've got the fun streets whose names look like part of the extra stuff normally tacked on (South St, Lane Rd) but you can't abbreviate those (S St, Ln Rd) because it's actually the name of the street.

  • not an anon (unregistered) in reply to nitePhyyre
    nitePhyyre:
    rt:
    Why isn't there a big white text box where I can type in my adress the way I want? That's my problem if I screw it up.
    Because that makes analytics harder/impossible. If I separate out all the fields and validate them, I can then easily select everyone in a region using their state or postal code. I can create a report to view my sales in a particular region of a country. If they write whatever they want for addresses, it is far harder to do that.

    They might write it in a weird format, adding or removing spaces. Maybe they'll write an abbreviation, maybe they'll invent their own incorrect abbreviation.

    TRWTF is turning customers away at the door for an analytics requirement. (Or, you just landed a huge order from Ford; rub is, it's big enough that they want it shipped by rail, and your backend systems can't handle destinations that aren't street addresses.)

  • SimpleSimon (unregistered) in reply to djingis1
    djingis1:
    ARWTF: All of this logic happens on (probably EntityFramework) model classes instead of business entities.

    txtStreetName.Text clearly shows this is taken from code behind for a web form, which in fact is probably worse.

  • Norman Diamond (unregistered) in reply to rt
    rt:
    Of course it would make no sense for pizza joints to support international addresses.

    Another example : Going from Canada to Europe via New-York, I had to fill this form. Required field for my destination address? A drop-down menu with only US states. TRWTF is that it was on a european airline website...

    If you live in Canada and wanted to order a pizza to share with your friends in Europe, or vice-versa, wouldn't you want the pizza joint to support the billing address of your credit card?

    Walmart's help desk was genuinely helpful -- they told me how to input a mix of fake and real information for my card's billing address when I ordered something for delivery in the US. (I bet I'll have to do the same next time too, even if I use my Walmart card. Seiyu department stores still use the Seiyu name but they issue Walmart cards.)

  • Educator (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    SHN (prefix variable names with a wart indicating the in-language type of the variable) is, indeed, a WTF of the highest order, and the *need* to use it does suggest an excess of variables.

    ... In a language with the restrictions outlined above, however, we rely on the eyes of the reviewer to detect that no, it isn't appropriate to assign things that way.

    Missing the point. "Systems" Hungarian Notation is completely appropriate for the place it was correctly used. Where you relied entirely on the eyes of the 'reviewer'.

    That is, for writing example code snippets on MSDN.

    Not entirely sane or insane when working with small bits of interface code, where the intrinsic type was a reflection of the logical type,

    Insane when copied in large enterprise applications.

  • just a french guy (unregistered)

    Do you love addresses?

    What do you think of this one, just a few houses from mine:

    27 bis, rue Guynemer 94240 L'Haÿ-les-Roses France

    Yes, those are an apostrophe two hyphens and one of the only three 'ÿ' in the whole country.

    And as you can read, the street number is "27 bis", a perfect int.

    I love my city name!

  • (cs) in reply to Norman Diamond
    Norman Diamond:
    rt:
    Of course it would make no sense for pizza joints to support international addresses.

    Another example : Going from Canada to Europe via New-York, I had to fill this form. Required field for my destination address? A drop-down menu with only US states. TRWTF is that it was on a european airline website...

    If you live in Canada and wanted to order a pizza to share with your friends in Europe, or vice-versa, wouldn't you want the pizza joint to support the billing address of your credit card?

    Walmart's help desk was genuinely helpful -- they told me how to input a mix of fake and real information for my card's billing address when I ordered something for delivery in the US. (I bet I'll have to do the same next time too, even if I use my Walmart card. Seiyu department stores still use the Seiyu name but they issue Walmart cards.)

    Easy fix, just don't live in Canada.

  • TenshiNo (unregistered) in reply to Schol-R-LEA

    Having first-hand knowledge of where this code came from, I can say that only US addresses will be entered in the system. As for the street number being "integer only" that is a pain point that is still being argued. PO Boxes will also never be entered here, just FYI.

    The entire need for the existence of this code is because every table in the system has a "LastUpdated" field, and we store address information in two different tables that actually have a 1x1 relationship (there was a reason for this at one point). After the page had been built, there was a requirement added during QA to make sure that "LastUpdated" was only updated when the address itself had changed (not just the other record).

    When they developer asked how to do that (yes, they had to ask) they were told to compare each entered value against what was already in the database, and set a boolean variable to true if the values were different (in addition to updating the value, of course). At the end, if the boolean is true, update the "LastUpdated" field. That seemed simple enough. This is what that developer came up with :)

    And, yes, this did make it to production (this was just a CRUD screen) and we had to do an emergency release to fix the problem when the client discovered it.

    The developer who wrote this (and their code) are no longer with the company.

  • Vernon Burt (unregistered)

    I'm really afraid that the answer to the question "Why do we throw an exception if the user accidently types an 'a' in Street Number is "Don't worry, The user doesn't see exceptions"

Leave a comment on “Feeling Validated”

Log In or post as a guest

Replying to comment #:

« Return to Article