Live data from Hacker News

We have an employee whose last name is Null. He kills our employee lookup (2012)

stackoverflow.com

211–220 of 245 posts

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#211

Earlier quoted context omitted.

Tibetans (with Hukou anyways) have Chinese names though. Usually they are phonetically chosen. Its something that must be done when you are born in China I guess, even if your native language isn't Chinese. This applies to all minorities who use different writing systems (Uigher, Manchu, Mongolian, etc...). Japanese of Korean descent can also choose Kanji names I think, to use as legal aliases.

Anyone who lives in Japan can register a legal alias, regardless of their citizenship. The special permanent residents that you mentioned (who typically hold North / South Korean or Chinese citizenship) are probably the most common users, but some Japanese people who are divorced use them, too. An alias with Kanji is really useful for living in Japan. I'm an American citizen but I use an alias with a Kanji last name…

That is actually a crazily innovative solution to a hard problem. I wish China would adopt something like this.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#212
post #65
post #4

As long as we're playing the "Falsehoods Programmers Believe About Names" game again, here's the relevant patio11 article: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... If you try to validate names, or if you don't safely escape names along with your other user-input strings, you're gonna have a bad time.

One thing that's annoying to me is that governments and employers increasingly believe many of these things, partly because they want to cross-reference names and match canonical forms. My given names in English are Mark Jason, and that's on my birth certificate. In Greek, they're Μάρκος Ιάσονας, which are the equivalents, and that's on my municipal birth records there (registered as a foreign birth at the time of ba…

Human names are an excellent illustration of the reason that you shouldn't use 'real' data as a key in a database. If the key is arbitrary and meaningless then it doesn't need to be mutable.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#213

Earlier quoted context omitted.

Growing up, my parents called me by my middle name, as I share a first name with my dad. (I'd rather be an Edward than a Ralph anyway.) When giving my name to someone, I tell them I'm Edward , as telling them I'm R. Edward just sounds pretentious. But if I'm beginning a relationship with a doctor's office or lawyer, or filling in a tax form, it's Ralph E. Lastname, because that's what's on my birth certificate and SS…

My name is Kim and I'm a male. Try convincing Americans (and other English speaking countries) about that... One example: Many years ago I subscribed to TIME and filled out a form where I checked "Mr." Apparently the person who typed in my name decided to "correct" this error and I became a "Mrs."... and I wasn't even married :-) The company I work at has offices in different cities, so most of the communication are…

Kim, like Hilary and Evelyn is a traditional boys name that has somehow become exclusively female over that last half-century or so.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#214
post #141
post #4

As long as we're playing the "Falsehoods Programmers Believe About Names" game again, here's the relevant patio11 article: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... If you try to validate names, or if you don't safely escape names along with your other user-input strings, you're gonna have a bad time.

This list is useless, because trying to follow it is impossibly ambitious. Which of these do I need to support for my system to work for X% of users with X+Y % being able to work around the limitations?

You don't need to explicitly support them if you just treat "name" as a freeform, unicode text field.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#215
post #53

A Japanese company once made the decision that they needed "virtual" employees in a particular system, for example to support e.g. adding a job to the org chart before that position had been filled (and another dozen use cases), so they had the clever idea "Hey, if we need to do this, we'll just input their 'name in Japanese' as one of a dozen status flags, like XX_JOB_REQUEST or XX_INCOMING_TRANSFER." One developer…

Many systems in China depend on your Chinese name and identification number. Suffice it to say, foreigners who work in China don't have either of these: a made up Chinese name is not meaningful or legal (China also lacks any kind of kana), a passport number is not a "valid" ID number and changes every 10 years anyways. I don't get to use many online services accordingly, and every year there is some problem with how…

It's expected when we look at how many English pages handle non-ascii characters.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#216

Earlier quoted context omitted.

I found your comments on "Filho" interesting. In English, the equivalent is "Junior" with the father sometimes using "Senior." It is not part of your name per se, and thus would not be typed into the name field of a form. However, in places where naming sons after their fathers is common, there is often be an additional drop down box listing (Jr, Sr, I, II, III, and so on).

Oh yeah, these drop boxes piss me off, specially because here in Brazil there is BOTH Junior and Filho... And I am Filho, not Junior. (also we have "Neto" that means Grandson, it is quite popular, I know a bunch of guys like that, I don't think dro down boxes in other countries will expect that)

Prefix and Suffix should be free form text!

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#217
post #141

Earlier quoted context omitted.

This list is useless, because trying to follow it is impossibly ambitious. Which of these do I need to support for my system to work for X% of users with X+Y % being able to work around the limitations?

You don't need to explicitly support them if you just treat "name" as a freeform, unicode text field.

Well, you can still get bitten by "11. People’s names are all mapped in Unicode code points," as well as the sets 1-8 and 32-36 (people have exactly X names at a given point in time, where X>0); that's not to mention ordering and collation (12,13,18,30). But it's definitely the easiest option, and avoids many common pitfalls (if I had a nickel for every database using latin1 + latin1_swedish_ci because that's the first charset + collation in the list, I'd have a lot of nickels).

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#218

Earlier quoted context omitted.

It get's worse. A friend of mine has a hyphenated name, "Kerry-Jean". The hyphen alone often breaks things.

Hyphenated last names seem to break many customer service people - they'll do things like insist one is the "real" name, assume you are married and ask when , etc. I think it's that hyphen is such a simple thing, it screams "understand me!" instead of simply being entered verbatim.

Assuming hyphen = married = wife's father's name-husband's father's name is just so ignorant. I've known many people who have always have hyphenated names, a few I've gone to primary school with. I have a good friend with an always-hyphenated-last-name who gets asked personal questions by strangers and near strangers about her name. How about "It isn't any of your business, I can have as many names as I want?"

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#220

Just took a few minutes to look into it. Found a gnarly bug in the AS 3.5 XMLEncoder class[1]. Type coercion strikes again! 1: http://stackoverflow.com/a/18000768/203705

Just a quick update: it wasn't a coercion bug. Instead, XML.appendChild seems to do nothing if passed the string "null".
Post reply on HN