475
This old food court stand at the mall had digital menus, but used stickers when the prices changed.
(fedia.io)
this post was submitted on 23 Jan 2025
475 points (99.6% liked)
Mildly Interesting
18239 readers
126 users here now
This is for strictly mildly interesting material. If it's too interesting, it doesn't belong. If it's not interesting, it doesn't belong.
This is obviously an objective criteria, so the mods are always right. Or maybe mildly right? Ahh.. what do we know?
Just post some stuff and don't spam.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
As a developer, users doing dumb shit like this really makes me question why I’m trying to help make life easier for them in the first place.
I have a shipping web application with fields that every shipment should have, for example “tracking number.” These people will prefix the value with “PRO#” or “#” as if the field isn’t already labeled correctly. I’ve fought for years with validation, sanitizing, etc. because having this junk data causes issues further down the line.
The same goes for other similar fields (reference numbers for example); they’ll also do everything they can to fuck up the address as much as possible so that it can’t be validated (unit number first, completely mismatched city and postal code, putting the street in a field that doesn’t belong to the address, etc).
I always try to give them the benefit of the doubt—they’re not developers. But is this something like, hard to understand for normal people? I’ve talked to them several times yet they can’t be fucked with to change their ways.
I'll share my story about stupid customers too. In our application we have the option to require an email address or not require an email address for new users based on the customer's preference. So naturally, we have/had a customer that set it to require an email address, but when they took information from their customers they did not actually require them to provide an email address. So for all their customers that didn't actually provide an email address they would enter something like noemail@fake.com. Something to satisfy the field requirement without actually being an email address. No consistency mind you.
This worked fine until we started offering a SaaS version of our software and emails stated being sent from AWS servers. Needless to say, AWS doesn't like it when you have an undelivered rate of like 30% for your emails. It ended up locking a pod out of sending emails for a day which ending up affecting multiple customers of ours.
And naturally, the customer using the fake emails never said anything about it to us beforehand or indicated what type of workforce they actually wanted; which was, "we want our employers to be forced to ask for an email and if the email is required they can't accidently forget to ask because they won't be able to continue in the app until they enter something." Probably a bit more paraphrased at this point since it happened years ago.
We don't expect all entered email addresses to be valid, but come on.
Well, unlike postal addresses, email addresses have an easier way to validate them. OTPs.
But that needs to be implemented on the application side
Wouldn't have been useful in this particular case.
Yeah. Definitely needs the form makers to implement it on their side.
I meant you wouldn't want to do that in this use case. We can't wait to verify an email at this step. There are plenty of things that could be implemented, if we knew about this workflow.
Yeah, in your case, the most I see could be done, is to remove the address that gives an unreachable response and add it to a list which can be referred to, right before a mail to the next record's address is sent (to not retry duplicates).
Or maybe use some AI mumbo-jumbo to determine availability.
Of course, I can also think of using DNS records to precheck if the domain name exists, but I would think they would mostly be parked domains anyway, so maybe not.
I don't even know what they ended up doing, not my department. They did come to us though as we were the ones sending out the emails though.