cue Dr Bobby Tables
yeah yeah - coat please!
Australia’s bug-ridden PCEHR – personally-controlled electronic health record – has run into another first glitch, with its registration site reportedly rejecting names containing non-alphanumeric characters. If you’re an O’Dwyer or have a double-barrelled surname, the registration process for PCEHRs would have failed, …
yeah yeah - coat please!
And Hen4ry (the '4' is silent).
for people like me who don't have a family name at all (there is no legal requirement to have one in this country and I chose not to have one long ago and had my legal name ammended to suit). Plays havoc with various incompetently-implimented government IT systems. Sucks to be them!
I was at uni with a bloke who changed his name to Wolf, dropping his family name (there was a big family conflict at the bottom of this that we never heard all of but it was nasty and he wanted nothing to do with them). The enrollment system could not cope with this so it gave him an initial. Thus he was A Wolf. He spent ages trying to get them to change it to "The"...
Last time I checked the calendar it was 2012. Why are people still encountering data entry problems that were solved decades ago?
"Why are people still encountering data entry problems that were solved decades ago?"
Perhaps the people implementing it are under the age of 30, and their supervisors have not actually implemented a non-trivial system?...
That's what you get when you hire contractors that rely on magic_quotes to solve this problem.
The crap I see every day attests to that. Allowing users to enter unsanitized data straight into databases is still rampant, enforcing the same business rules in different frontend PHP pages rather than properly centralizing them in shared backend classes, copy pasting of huge sections of code so you can "reuse it" because one variable needs to be different. These things are all endemic in your typical in-house developed business application these days.
The coders that are pumped out of our "degree factories" learn the syntax of a language but have no idea on how to properly structure their code or sanitize user inputs.
"Shared backend classes" my arse. What you mean is "opaque layers of dynamically generated files in which errors can only be detected by testing, and even that probably won't work half the time".
I'm prepared to bet that whatever technology Accenture threw at this project, it wasn't PHP.
but my experience has been that having too much is far harder to achieve than having too little, and actually doesn't cause as many problems. Granted that something about MVC seems to foster this kind of excess, and granted that something like Magento is no fun to deal with at all, precisely because it has been over-architected -- but I'd rather work with that, than with a system produced by some balls-out cowboy who's never heard of anything and so doesn't see why it's a problem to produce half-megabyte-long script files which promiscuously mix database calls, business logic, and rendering code, unrelieved by even the slightest hint of sanity or maintainability.
MVC and heavy backend architecture in general -- hard to maintain? Sure! I'd rather that than impossible. Wouldn't you?
You have got to be bloody kidding me... a multi-million dollar system being coded by morons! How the hell does anyone working in such a situation not know better? Seriously! What the hell is wrong with these people!?
It's one thing to make mistakes like this when working on a $500 PHP website for the local footy club... but a multi-million dollar website for the federal government?
I remember being young.
"Accenture", huh? Didn't they use to be "Andersen Consulting"? 'cause I *know* all the programmers I worked with shuddered when told they had to maintain a system "developed" by AC.
APOSTROPHIZE them! And semicolonoscopies, too.
Despite the references to Bobby Tables and un-sanitized inputs, it's actually far more likely that the system was doing TOO MUCH sanitization than none at all, especially given that hyphens are apparently not allowed. Thus much more likely that the inputs were being scanned to validate that they only had alphabetic characters in, rather than no validation was being performed at all and that the system was then crashing with entries containing apostrophes and hyphens.
Still makes it a rubbish design and build but I guess I'd prefer a crap system with too much sanitization than a crap system with none at all.
More likely no sanitisation at all, effectively interpreting the minus sign and apostrophe as valid programming language syntax and failing due to the resulting syntax errors. Easy enough to check, but to answer your point, sanitisation that falls over when the input is not valid is not good programming practice either.
Why does this not surprise me? I've lot count of the number of websites that steadfastly refuse to allow me to enter my telephone number correctly, stubbonly just saying "not a phone number" until I guess that I have to enter a completely unpunctuated and unreadable string of digits.
I'd like to see what would happen if they tried using the (in)famous Xkcd name in http://xkcd.com/327/
Because if they don't test for this, someone else will on their behalf...
I understand that bugs arise and things can be overlooked, but to fail at something as basic as someones surname that contains an apostrophe or that is hyphenated, tells me that either the programmers are lazy or incompetent.
I read up above in a comment that this is Accenture's doing - colour me something tastfully contrasting to surprised...
A story apostrophic, and not apocryphal:
When writing the pile-of-crap RITA system for the UKs RPA (Rural Payments Agency), they managed to sneak into a functional design a statement that an interface (related to printing customised forms and letters) would not use genuine XML, but rather something somewhat like XML.
Suffice to say, everything performed nominally for the new system (that is to say, it shat itself) whenever customer data included XML markup characters. Rather than fixing the problem by redoing it properly with an XML encoder, they string replaced the problem characters (like ampersand and apostrophe) using cludge search-replace scripts until it got through the test environment.
Of course, everything was over dead-line already, and when the first, well-overdue, live production run unsurprisingly went tits-up, (due to a single customer amongst the 100,000 with a greater-than symbol in it's name) it was blamed on the truly-hardworking team of civil servants in the department for obviously not testing thoroughly enough, Accenture were to be held basically blameless by the senior management; after all. they were the experts in technical implementation - my suggestion that they might be incompetent and deserving of a firm legal spanking seemed only to result in more fire coming in our direction...
Anonymous, because I'm embarrassed I didn't pick up the glitch was still in the functional design until too late... (ie: post-signoff, once requiring something trivial to be fixed meant tens-of-thousands-of-pounds of change request)
Hmm, since that post makes fairly strong allegations, it's probably important that I correct something I'm not 100% sure about...
In the fifth paragraph: it might have been a less-than sign.
fscked by SHA-1 collision? Not so fast, says Linus Torvalds