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."<p>One developer at this company, who was annoyed with having to tweak a particular system every time they added a new possible status flag, wrote code which was, essentially:<p><pre><code> if (InternalStringUtils.isAllLatinCharacters(employee.getJapaneseName()) {
/* no need to pay this 'employee' so remove them from batch
before we retrieve bank details for salary transfers */
...
}
</code></pre>
Do I have to explain why I'm aware of this curious implementation choice?
As long as we're playing the "Falsehoods Programmers Believe About Names" game again, here's the relevant patio11 article:<p><a href="http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/" rel="nofollow">http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b...</a><p>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.
Reminds me of a story a police reservist told me. Guy got a license plate caled "none," and instantly had thousands of outstanding warrants. (The cop thought "none" was trying a fast one, and so deserved it.)
We had a customer with the last name "Echo" who couldn't make a credit card payment. Turns out that the card processor was looking for strings which were common Unix commands and not allowing them.
This problem isn't about funny employee names. It's about thick, untransparent software stacks that make simple problems difficult.<p>SOAP is maybe the most popular example and this is really why it's lost popularity against REST. However, similar "It works with values W, X, Y, but not Z" situations are found in any stack or standard that has too much magic going on. Rails certainly comes to mind.<p>This is the biggest argument in favour of using many small, isolated components rather than one big all-encompasing framework, in my opinion. If every piece of third party functionality you import into your project can be easily understood, problems like these shrink in size, because there's a limit to how deep the magic can go.<p>I'm very fond of the Node.js ecosystem for particularly this aspect (even though I dislike the language). There's a big bucketload of tiny components there, rather than 90% of the community relying on a single humongous framework, like is common for e.g. Ruby or C#.
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!<p>1: <a href="http://stackoverflow.com/a/18000768/203705" rel="nofollow">http://stackoverflow.com/a/18000768/203705</a>
A website I was building, which depended on a ColdFusion service, started breaking for Norway users. Why? Norway's country code was "NO" - <a href="http://stacktoheap.com/blog/2012/12/19/why-a-feature-of-our-website-stopped-working-for-norway/" rel="nofollow">http://stacktoheap.com/blog/2012/12/19/why-a-feature-of-our-...</a>
Vaguely related but we had a customer using some feature that split text blobs using a record separator. One time someone wanted to not split at all and set separator="none" without bothering to look up how to actually turn off record splitting. It worked well enough in quick tests, but by the time we'd gotten the support call, they'd corrupted a massive database where every product with a description containing the string "none" was now corrupted.
I've got a friend whose last name is Null, and he used to have all kinds of issues with the phone company...<p>Obviously if your lookup app is having a problem with using "Null" as a string then you have data type issues.<p>It's not rocket science.
There was a DailyWTF article years ago about a "Robert Null" who would be shown whenever you searched for employees with a blank input.<p><a href="http://thedailywtf.com/Articles/Paging_Dr_0x2e__Null.aspx" rel="nofollow">http://thedailywtf.com/Articles/Paging_Dr_0x2e__Null.aspx</a>
SOAP: the gift that keeps on giving. I built two SOAP APIs for Google (Search and AdWords) and spent way, way too much time on this kind of data interop nonsense. I wrote up a quick summary of why SOAP sucks, it's still my most popular blog post. <a href="http://www.somebits.com/weblog/tech/bad/whySoapSucks.html" rel="nofollow">http://www.somebits.com/weblog/tech/bad/whySoapSucks.html</a><p>XML is a terrible encoding for data. Fortunately JSON does pretty well and has mostly replaced it for new stuff.
I recently moved to Japan. My name, as it appears on my passport, is 26 characters long and consists of a-z letters and spaces. This means I run into three problems:<p>First, many computer systems here can't fit names that long, leading to truncation, or in some cases, denial of account creation (some places have rules that whatever's on the account must match exactly what's on the passport; one was nice enough to add a new column to their database for the rest of my name).<p>Second, many systems don't support a-z, so we throw the name in as katakana or double-byte romaji, depending on what works. Sometimes neither will work, and we just have to give up and go somewhere else.<p>Finally, many computer systems can only link accounts if the names match exactly, for example inter-bank transfers and bill payments. Since my name is truncated differently in different places, and is formatted differently in different systems, in many cases it's just impossible.<p>For example, right now I'm charged a fee for transferring money between two bank accounts, since the free transfers only apply if the names match exactly. I just withdraw cash from one and deposit it into the other as a workaround.<p>Another example is my cell phone bill. To pay it by CC my name must match exactly, but all my cards have slightly different spellings.<p>Don't even get me started on my wife, who is ethnically Japanese but came with me as a foreigner and hence has a name written using a-z letters. It literally has set of fraud detection systems.
My last name has a space in it. The three years that I have filed paper taxes, IRS has split up my last name into two words and put one of them as my middle name. This despite the fact that I clearly label the middle name box as "n/a". I was told by the IRS representative that I should change my name.
Well Imagine a person has two 'first names' plus his surname of his mother and by last the surname of his father.
Something as<p>XXXX XXXX YYYY ZZZZ<p>The Visa papers does not support 'large' names..
So he has to abbreviate..<p>Imagine this guy has the same last name and first name of FBI wanted list.<p>Now, after sep - 11 everytime he has to go to the 'vip' room at border and there is large confusion as visa papers do not 'support' longer names...<p>This is US...<p>Not complaining but can the Prism people flag work it out ;)
I remember having "funny" situations with with AS3 SOAP marshaling and unmarshaling. For example, in same cases it would just fail silently, providing half populated objects without without any errors. In the end, the workaround was to just invoke SOAP methods directly using HTTP and just manually parse XML response. Good old days.