The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
I once debugged a problem where users reported that they'd print a batch of invoices, say 100, but only half of them were printed.
So I check the logging and sure enough, all print jobs were created, but only half of them finished.
No errors or exceptions, printer worked, the client couldn't think of anything that happened prior to the printing.
They printed two batches a day, one in the morning and one in the afternoon, but this only happened in the afternoon.
The next day everything went fine, then it didn't, when I tested it everything worked, I built all kinds of checks and logging, but NOTHING would solve the problem.
I even went there to check out why it went wrong, but I couldn't find anything and of course everything printed as it should that day.
This went on for months, not every day, but quite often and I would be looking for the problem regularly.
One fine day, my manager was over at the client and he wanted to go home just when the department was about to print invoices.
In a moment of clarity he thought he'd walk in to see if the invoices were printed.
He found the problem.
They selected 100 invoiced, pressed the print button, THEN TURNED OFF THEIR FRIGGIN COMPUTER!
That explained why it always worked in the morning, no one turned off their computer in the morning.
It doesn't explain why these people can't make a connection between turning off their computer and a printer stopping
I don't think I've ever spent that much time on a "bug"
I spent a week sitting in a library, waiting for an intermittent fault to happen.
We'd delivered a new design of VDT (a terminal that talked to a mainframe) and this one site 300 miles away had a problem with it glitching out and restarting sometimes. The hardware had been replace with a brand new one, it only seemed to happen with my software. So a service engineer and I went up there are sat until it failed. Monday was dull. Tuesday more so. Friday was "climb the walls" time ... And then it happened.
Because they laminated a new library user's card for the first time that week.
And the laminator "spiked" the mains supply and the VDT PSU glitched out, crashing the software ...
One line conditioner later and we headed for home.
That was an expensive problem, not just in our time, but definitely in the bar bill which was "quite staggering" in the words of the Managing Director!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
Nothing amazes me anymore, even when I provide detailed step by step instructions how to install and use the software we write they somehow manage to do things wrong most of the time.
Guess it's too hard to read the instructions
A telephone switch was installed in Alaska to carry calls between Asia and North America. It connected to the North American network by satellite. It was so far north that it could barely see the satellite in its orbit, low over the horizon.
A satellite dish is usually mounted on a tower, but posts conduct heat into the ground, melting permafrost and creating a Leaning Tower of Pisa look. So the dish stayed on the ground.
After some uneventful months, the switch suddenly went insane. Thousands of links simultaneously failed and reconnected shortly afterwards, and the cycle would then repeat. Each failed link resulted in a message for the maintenance software, which began to diagnose the problem. This used up a lot of CPU time. And each link reestablishment resulted in a call origination message for the call handling software.
The switch couldn't handle the intense message flood. Call originations timed out and were retransmitted, exacerbating the problem. Then the links would crash again, causing another message flurry for the maintenance software. The switch got so far behind that it couldn't even handle calls on the links that had actually remained in service.
Eventually the links came up and stayed up, but it still took the switch quite a while to recover from the message flood.
The next day, the same thing. This continued until some field engineers took a snowmobile to go and inspect the satellite dish. It was in perfect working order. But one day while they were out there, they experienced what felt like a mild earthquake. A great herd of caribou (reindeer) were crossing the horizon on their yearly migration. The satellite dish was mounted so low that the dust cloud kicked up by the caribou broke the microwave beam between the satellite and dish, causing all the links to crash. The gaps between herds would then allow the links to reconnect before the next herd took them down again.
In the early days of email, a colleague of mine reported that he had received a rush of emails from his wife, working with another company, some of the messages weeks and months old - messages that had "disappeared" for unknown reasons now reappearing.
They found the reason: At my employer, we still did offline backup, taking down the machines at midnight to make backup copies. At the company of my colleague's wife, their email system tried to send the mail when submitted, but if unsuccessful (which wasn't uncommon in those days), the mail was put into a backlog for a retry after midnight ... when our machines were offline for backup. So the midnight retransmission failed, night after night. Then our mailserver had a major crash at nighttime. It was restarted right before midnight, without being taken down for backup. Then the whole rush of backlogged emails where accepted.
In the UK, a telephone subscriber is signalled by sending 90 volts across one side of the two-wire circuit and ground. When the phone is answered, it switches to the two-wire circuit for conversation. This method allows two parties on the same line to be signalled without disturbing each other.
An elderly man called British Telecom to say that his telephone nearly always failed to ring when his friends called. On the few occasions when it did ring, his dog always barked first. A technician dispatched to the premises climbed a nearby pole, connected his test set, and dialled the house. The phone didn't ring.
On investigation, it was found that the dog was tied to the telephone system's ground post via an iron chain and collar, and was receiving 90 volts of signalling current. After several jolts, the dog urinated on the ground and barked. The wet ground then conducted and the phone rang.
A friend of mine has two tickets to the 2020 Super Bowl in Miami, box seats. He paid $11,500 each.
They come with limo service from and back to the airport, lunch, dinner, and up to a $400 bar tab.
Also an authorized pass to the winner's locker room.
He did not realize last year when he bought them, that the game was going to be on the same day as his wedding.
If you are interested, he is looking for someone to take his place.
It's at St. Paul's Church in Ocala at 3 PM. Her name is Ashley.
She's 5'4", about 125 lbs., and a good cook. She loves to fish and hunt.
She will be the one in a white dress.
Most of the apps i can think of that would be useful require connection to some sort of DB or service. I'm assuming you're going to host something for that? Like a DB and a webserver, or a some sort of cloud deployment
If so, how about something that automatically shows your closest friends/family? and allows you to set up radiusus for what constitutes "closest"?
you could do group chats and/or organize meets using it.