Immer wieder aufs neue bin ich beeindruckt, wenn Firmen lieber die Zeit investieren ihren “No Spaces are allowed in the card number” in 120 Sprachen zu übersetzen als eine Entwickler:in kurz ranzusetzen einfach die Leerzeichen aus der Kartennummer zu löschen.
Es wurde eine Entwickler:in rangesetzt zu prüfen ob Leerzeichen drin sind und dann die Fehlermeldung anzuzeigen. Aber das Problem einfach zu fixen, dafür war keine Energie da.
@343max Die traurige Wahrheit wird sein, dass das niemand programmiert hat, sondern einfach nur das erstbeste Package hinzugefügt wurde und das halt mit dieser "Einschränkung" daher kommt.
@343max Gibt bestimmt eine regulatorische Anforderung, die sagt, dass Kund:innen-Eingaben nicht verändert verarbeitet werden dürfen.
@343max leider ist das Verständnis für solche „Details“ bei vielen Managern und leider auch Entwicklern (jeweils m/f/d) nicht oder nur sehr minimal vorhanden 🤷‍♂️ Die nutzen ja auch Windows oder Excel, wie sollen sie es da besser wissen?
@chbeer Ich glaube das hat oft weniger mit den Individuen zu tun und mehr mit den Organisationsformen. Oft ist für die Beteiligten nichts zu gewinnen, wenn sie eine Aufgabe besser lösen und nur was zu verlieren, wenn sie vom vorgegebenen Weg abweichen.
@343max gleicher Spaß mit Telefonnummern 🤯
@343max I recently had a website (lidl-connect) reject a contact form submission because parentheses in the *message body* were 'not secure'. Had to sit down for a few minutes to process that. (They also do not allow semicolons in passwords. Makes you wonder where they are putting those password. 🥴)
@343max Das erinnert mich an mein Onlinebankingsystem. Das weist mich oft darauf hin, dass die TAN-Codes keine Null, sondern den Buchstaben O enthalten können (oder umgekehrt).
@343max sehr treffend:👌🏼 genau der Grund warum Kreditkarten- und Konto-Nr immer doppelt im Passwortsafe gespeichert sind bei mir, da ich Freund von CopyPaste bin. 🤷🏻‍♂️ #müssteabernich🤦🏻‍♂️