by Mark Bowytz on (#3MMSF)
"I wonder what events, or lawsuits, lead TP-Link to add this warning presumably targeted individuals who updated firmware just ahead of performing medical procedures," writes Andrew.
| Link | http://thedailywtf.com/ |
| Feed | http://syndication.thedailywtf.com/TheDailyWtf |
| Updated | 2026-09-04 15:20 |
|
by Scot Devera on (#3MFE3)
Your software is terrible, but that doesn’t make it special. All software is terrible, and yes, you know this is true. No matter how good you think it is, bugs and performance problems are inevitable.But it’s not just the ugly internals and mysterious hacks and the code equivalent of duct-tape and chewing gum which make your software terrible. Your software exists to fill some need for your users, and how do you know that’s happening? And worse, when your application fails, how do you understand what happened?In the past, we’ve brought your attention to Raygun, which allows you to add a real-time feedback loop that gives you a picture of exactly what’s happening on their device or their browser. And now, Raygun is making it even better, with Raygun APM.Raygun Application Performance Monitoring (APM) tackles the absolute worst part of releasing/supporting applications: dealing with performance issues. With Raygun APM, you can get real-time execution stats on your server-side code, and find out quickly which specific function, line, or database call is slowing down your application.You won’t have to wait for someone to notice the issue, either- Raygun APM proactively identifies performance issues and builds a workflow for solving them. Raygun APM sorts through the mountains of data for you, surfacing the most important issues so they can be prioritized, triaged and acted on, cutting your Mean Time to Resolution (MTTR) and keeping your users happy.In addition to all this, Raygun is adding tight integration with source control, starting with GitHub.Request access to the beta here. Or if you’re already tired of searching logs for clues in an effort to replicate an issue, try out Raygun’s current offerings and resolve errors, crashes and performance issues with greater speed and accuracy. [Advertisement] ProGet supports your applications, Docker containers, and third-party packages, allowing you to enforce quality standards across all components. Download and see how!
|
|
by Jane Bailey on (#3M944)
As we've seen previously, not all government jobs are splashy. Someone has to maintain, for example, the database that keeps track of every legal additive to food so that paranoid hippies can call them liars and insist they all cause cancer and autism. Today's submitter, Cass, had just released an update when users started getting the dreaded blue Internal Error screen—never a good start to the week.Everything that's added to food is added for a reason; otherwise, why spend money doing it? The additive website allows searching by function, as well as by name. For example, some items might be alternative sweeteners, while others might be coloring agents. The problem of the week turned out to be in the stored procedure related to this particular search, which was intuitively titled prc_AdditiveRegulation_GetResults_NEW. Not to be confused with the entirely unused prc_AdditiveRegulation_GetResults, prc_AdditiveRegulation_GetResults_DEV, or prc_AdditiveRegulation_GetResults_PROD.As Cass quickly discovered, prc_AdditiveRegulation_GetResults_NEW is a hefty chunk of code. 1044 lines, to be precise, all dedicated to returning a list of additives and their functions. After hours of searching, Cass managed to isolate the portion that was causing the problem:
|
|
by snoofle on (#3K7H2)
Booleans. One would think that simple true and false would be sufficient to represent all the possible values. However, even more than dates, they are one of the most difficult things to master in all of computer science. There are all manner of possible values and many different ways of comparing different entities.Compounding everything is another dimension to boolean-ness: internationalization. After all, not every language uses English spellings of true and false. In high school, they made me take French, so it'd be vrai and faux. For most of us, we'd put the language-specific spelling in an application-phrases file, cache it and pick the appropriate spelling based upon the meaning of the required phrase. However, the underlying core values of truth/falsehood would still be programming-language-specific.For most of us...
|
|
by Ellis Morning on (#3JTW5)
Jonathan T. had recently been afforded the opportunity to go back and tweak the very first Python-based CMS he'd ever built. Years earlier, he and another junior developer had been forced to cobble this site together with no code reviews, oversight, or help of any kind. Terrible choices had been made in the name of getting their work done.Jonathan rebuilt every page in the CMS and made sure the forms and plugins cooperated with the new structural elements he introduced. In the process, he got stuck trying to figure out how a "col-sm-6" was showing up on a particular form. He found nothing in the CSS, LESS files, or page-specific JS controlling the form. In desperation, he ran a project-wide search for the randomClass.This was the result Jonathan found in project/scripts.js, authored by the other junior dev. It explained why, for the past several years, new images on the site had randomly not worked for any discernible reason.
|
|
by snoofle on (#3JMWG)
Banks. They take your money and lend it to others. They lend money deposited by other people to you, either as a car loan, mortgage, or for credit card purchases. For this privilege, you give them all of your personal information, including your social security number. Implicit in that exchange is the fact that the bank should keep your personal information confidential. Security is important. One might think that such a concept would be important to banks. One would be wrong.To be fair, the high ranking people at the banks probably believe that all of their customer information should be - and is - secure and protected. Unfortunately, there are multiple layers of middle and lower management (that we all know all too well) that might not comprehend that point.The other thing that banks do is nightly batch processing to keep assorted records updated, generate TPS reports, issue bills, update financial inventory, credit usage and so forth. Since customers tend to hit ATMs at all hours of the day and night, you want your systems-update processing to be able to occur while the system is live. To that end, date and timestamp ranges of transactions to be processed for a given business period usually come into play in some form. The point is that you shield your ongoing transactions from reconciliation activity by excluding it from the reconciliations. The beat business goes on.Randy worked at a major bank in the Pittsburgh, PA area. Considering that it's a major bank, it seemed odd that their customer facing website was often down for more than an hour at a time during business hours. When he started in 2016, it took about a month to get permissions to get the development tools he needed installed. Hmmm, perhaps they are vigilant about controlling access to their environments, even development; possibly a good, if bureaucratic sign. Once set up, he was assigned to work on their Web Banking app which was written not in MVC but in ASP.NET WebForms. OK, maybe they're slow to adopt newer technologies because they want someone else to beta test them. Caution can be a good sign.As part of doing his work, Randy sent SOAP messages to the mainframe to retrieve test data for developmental testing. One day, he deduced that the test social security number was that of his boss. He verified this by asking his boss what he had for lunch that day. Sure enough, there were debit card charges for it in the test environment. Uh oh.That's right; live data in the test environment. Anyone with even novice skills could have gotten social security, routing and account numbers for every customer of the bank! Rather than fight with the, ahem, highly knowledgeable individuals that thought that this was a good setup - and potentially be blamed for any breaches, Randy chose to jump ship and head for saner pastures.Interestingly, I went to their website, which states that their business hours are M-F 8AM-8PM and Sat 9AM-3PM. At 1:15 on a clear, dry Saturday when the bank should have been open for business, I called the bank posing as a potential customer to ask why their website is often down for more than an hour at a time almost every single night. The auto attendant said to try back during business hours.Hmmm... [Advertisement] ProGet can centralize your organization's software applications and components to provide uniform access to developers and servers. Check it out!
|
|
by Charles Robinson on (#3HYP3)
|
|
by Ellis Morning on (#3HJ16)
Tim B. had been tasked with updating an older internal application implemented in Java. Its primary purpose was to read in and display files containing a series of XY points—around 100,000 points per file on average—which would then be rendered as a line chart. It was notoriously slow, taking 1-2 minutes to process each file, but otherwise remained fairly stable.Except that lately, some newer files were failing during the loading process. Tim quickly identified the problem—date formats had changed—and fixed the necessary code. Since the code that read in the XY points happened to reside in the same class, Tim asked his boss whether he could take a crack at killing two birds with one stone. With her approval, he dug in to figure out why the loading process was so slow.
|
|
by Jane Bailey on (#3HF2J)
So here's a thing that keeps me up at night: we get a lot of submissions about programmers who cannot seem to think like users. There's a type of programmer who has never not known how computers worked, whose theory of computers in their mind has been so accurate for so long that they can't look at things in a different way. Many times, they close themselves off from users, insisting that if the user had a problem with using the software, they just don't know how computers work and need to educate themselves. Rather than focus on what would make the software more usable, they program what is easiest for the computer to do, and call it a day.The same is sometimes true of security concerns. Rather than focus on what would be secure, on what the best practices are in the industry, these programmers hammer out something easy and straightforward and consider it good enough. Today's submitter, Rick, recently ran across just such a "security system."Rick was shopping at a small online retailer, and found some items he liked. He got through the "fill in all your personal information and hope they have good security" stage of the online check-out process and placed his order. At no time was he asked if he wanted an account—which is good, because he never signs up for accounts at small independent retailers, preferring for his card information not to be stored at all. He was asked to fill in his email, which is common enough; a receipt and shipping updates are usually sent to the email associated with the order.Sure enough, Rick received an email from the retailer moments later. Only this wasn't a receipt. It was, in fact, confirmation of a new account creation ... complete with a password in plain text.Rick was understandably alarmed. He headed back to the site immediately to change the password to a longer, more secure one-off he could store in a password manager and never, ever have emailed to him in plaintext. But once on the site, he could find no sign of a login button or secure area. So at this point, he had an insecure password he couldn't appear to use, for an account he didn't even want in the first place.Rick sent an email, worried about this state of affairs. The reply came fairly rapidly, from someone who was likely the sole tech department for the company: this was by design. All Rick had to do next time he purchased any goods was to enter the password on the checkout screen, and it would remember his delivery address for him.As Rick put it:
|
|
by snoofle on (#3GWEG)
In software development, there are three kinds of problems: small, big and subtle. The small ones are usually fairly simple to track down; a misspelled label, a math error, etc. The large ones usually take longer to find; a race condition that you just can't reproduce, an external system randomly feeding you garbage, and so forth.The subtle problems are an entirely different beast. It can be as simple as somebody entering 4321 instead of 432l (432L), or similar with 'i', 'l', '1', '0' and 'O'. It can be an interchanged comma and period. It can be something more complex, such as an unsupported third party library that throws back errors for undefined conditions, but randomly provides so little information as to be useful to neither user nor developer.Brujo B encountered such a beast back in 2003 in a sub-equatorial bank that had been especially fond of VB6. This bank had tried to implement standards. In particular, they wanted all of their error messages to appear consistently for their users. To this end, they put a great deal of time and effort into building a library to display error messages in a consistent format. Specifically:
|
|
by Ellis Morning on (#3GD8M)
It feels as though disc-based media have always been with us, but the 1990s were when researchers first began harvesting these iridescent creatures from the wild in earnest, pressing data upon them to create the beast known as CD-ROM. Click-and-point adventure games, encyclopedias, choppy full-motion video ... in some cases, ambition far outweighed capability. Advances in technology made the media cheaper and more accessible, often for the worst. There are some US households that still burn America Online 7.0 CDs for fuel.But we’re not here to delve into the late-90s CD marketing glut. We’re nestling comfortably into the mid-90s, when Internet was too slow and unreliable for anyone to upload installers onto a customer portal and call it a day. Software had to go out on physical media, and it had to be as bug-free as possible before shipping.Chris, a developer fresh out of college, worked on product catalog database applications that were mailed to customers on CDs. It was a small shop with no Tech Support department, so he and the other developers had to take turns fielding calls from customers having issues with the admittedly awful VB4 installer. It was supposed to launch automatically, but if the auto-play feature was disabled in Windows 95, or the customer canceled the installer pop-up without bothering to read it, Chris or one of his colleagues was likely to hear about it.And then came the caller who had no clue what Chris meant when he suggested, "Why don't we open up the CD through the file system and launch the installer manually?"These were the days before remote desktop tools, and the caller wasn't the savviest computer user. Talking him through minimizing his open programs, double-clicking on My Computer, and browsing into the CD drive took Chris over half an hour."There's nothing here," the caller said.So close to the finish line, and yet so far. Chris stifled his exasperation. "What do you mean?""I opened the CD like you said, and it's completely empty."This was new. Chris frowned. "You're definitely looking at the right drive? The one with the shiny little disc icon?""Yes, that's the one. It's empty."Chris' frown deepened. "Then I guess you got a bad copy of the CD. I'm sorry about that! Let me copy down your name and address, and I'll get a new one sent out to you."The customer provided his mailing address accordingly. Chris finished scribbling it onto a Post-it square. "OK, lemme read that back to—""The shiny side is supposed to be turned upwards, right?" the customer blurted. "Like a gramophone record?"Chris froze, then slapped the mute button before his laughter spilled out over the line. After composing himself, he returned to the call as the model of professionalism. "Actually, it should be shiny-side down.""Really? Huh. The little icon's lying, then.""Yeah, I guess it is," Chris replied. "Unfortunately, that's on Microsoft to fix. Let's turn the disc over and try again." [Advertisement] Incrementally adopt DevOps best practices with BuildMaster, ProGet and Otter, creating a robust, secure, scalable, and reliable DevOps toolchain.
|
|
by Jane Bailey on (#3G868)
Every year, Initrode Global was faced with further and further budget shortages in their IT department. This wasn't because the company was doing poorly—on the contrary, the company overall was doing quite well, hitting record sales every quarter. The only way to spin that into a smaller budget was to dream bigger. Thus, every quarter, the budget demanded greater and greater increases in sales, and the exceptional growth was measured against the desired phenomenal growth and found wanting.IT, being a cost center, was always hit by budget cuts the hardest. What did they need money for? The lights were still on, the mainframes still churning; any additional funds would only encourage them to take wild risks and break things.One of the things people were worried about breaking were the thin clients. These had been purchased some years ago from Smyrt, who had been acquired the previous year by Hell Computers. There would be no tech support or patching, not from Hell. The IT department was on their own to ensure the clients kept running.Unfortunately, the things seemed to have a will of their own—and that will did not include remaining up for weeks on end. Every once in a while, when booting Linux on the thin clients, the Thin Film Transistor screen would turn dark as soon as the X server started. They would remain dark after that; however, when the helpdesk SSH'd into the system, the screen would of course render perfectly on their end. So there was nothing to do to troubleshoot except lug a thin client to their work area and test workarounds from there.The worst part of this kind of troubleshooting is when the problem is an intermittent one. The only way they could think to reproduce the problem was to spend hours in front of the client, turning it off and back on again. In the face of budget cuts, the already understaffed desk had no manpower to do something so trivial and dull.Tedium is the mother of invention. Many of the most ingenious pieces of automation were put in place when an enterprising programmer was faced with performing a mind-numbing task over and over for the foreseeable future. Such is the case in this instance. Lacking the support staff to power cycle the machine over and over, the staff instead built a robot.A webcam was found in the back room, dusty and abandoned, the last vestige of a proposed work-from-home solution that never quite came to fruition years before. A sticker of transparent rubber someone found in their desk was placed over the metal rim of the camera so it wouldn't leave any scratches on the glass of the TFT screen. The webcam was placed up close against one strategically chosen corner of the screen, and attached to a Raspberry Pi someone brought from home.The Pi was programmed to run a bash script, which in turn called a CLI image-grabbing tool and then applied some ImageMagick filters to determine the brightness value of the patch of screen it could see. This brightness value was compared against a known list of brightnesses to determine which state the machine was in: the boot menu, the Linux kernel messages scrolling past, the colorful login screen, or the solid black screen representing the problem. When the Pi detected a login screen, it would run a scripted reboot on the thin client using SSH and a keypair. If, instead, the screen remained dark for a long period of time, it would send an IM through the company messaging solution to alert the staff that they could begin their testing, then exit.We've seen machines with the ability to manipulate physical servers. Now, we have machines seeing and evaluating the world in front of them. How long before we reach peak Skynet potential here at TDWTF? And what would the robot revolution look like, with founding members such as these? [Advertisement] Incrementally adopt DevOps best practices with BuildMaster, ProGet and Otter, creating a robust, secure, scalable, and reliable DevOps toolchain.
|
|
by Remy Porter on (#3FYVP)
Steven worked for a company that sold “big iron†to big companies, for big bucks. These companies didn’t just want the machines, though, they wanted support. They wanted lots of support. With so many systems, processing so many transactions, installed at so many customer sites, Steven’s company needed a better way to analyze when things went squirrelly.Thus was born a suite of applications called “DICSâ€- the Diagnostic Investigation Console System. It was, at its core, a processing pipeline. On one end, it would reach out to a customer’s site and download log files. The log files would pass through a series of analytic steps, and eventually reports would come out the other end. Steven mostly worked on the reporting side of things.
|
|
by snoofle on (#3FD0B)
We've all seen code that ignores errors. We've all seen code that simply rethrows an exception. We've all seen code that wraps one exception for another. The submitter, Mr. O, took exception to this exceptionally exceptional exception handling code.I was particularly amused by the OutOfMemoryException handler that allocates another exception object, and if it fails, another layer of exception trapping catches that and attempts to allocate yet another exception object. if that fails, it doesn't even try. So that makes this an exceptionally unexceptional exception handler?! (ouch, my head hurts)It contains a modest amount of fairly straightforward code to read config files and write assorted XML documents. And it handles exceptions in all of the above ways.You might note that the exception handling code was unformatted, unaligned and substantially larger than the code it is attempting to protect. To help you out, I've stripped out the fairly straightforward code being protected, and formatted the exception handling code to make it easier to see this exceptional piece of code (you may need to go full-screen to get the full impact).After all, it's not like exceptions can contain explanatory text, or stack context information...
|
|
by snoofle on (#3F74N)
A few years ago I was hired as an architect to help design some massive changes to a melange of existing systems so a northern foreign bank could meet some new regulatory requirements. As a development team, they gave me one junior developer with almost a year of experience. There were very few requirements and most of it would be guesswork to fill in the blanks. OK, typical Wall Street BS.The junior developer was, well, junior, but bright, and he remembered what you taught him, so there was a chance we could succeed.The setup was that what little requirements there were would come from the Almighty Project Architect down to me and a few of my peers. We would design our respective pieces in as generic a way as possible, and then oversee and help with the coding.One day, my boss+1 has my boss have the junior guy develop a web service; something the guy had never done before. Since I was busy, it was deemed unnecessary to tell me about it. The guy Googled a bit and put something together. However, he was unsure of how the response was sent back to the browser (e.g.: what sort of line endings to use) and admitted he had questions. Our boss said not to worry about it and had him install it on the dev server so boss+1 could demo it to users.Demo time came, and the resulting output lines needed an extra newline between them to make the output look nice.The boss+1 was incensed and started telling the users and other teams that our work was crap, inferior and not to be trusted.WTF?!When this got back to me, I went to have a chat with him about a) going behind my back and leaving me entirely out of the loop, b) having a junior developer do something in an unfamiliar technology and then deploying it without having someone more experienced even look at it, c) running his mouth with unjustified caustic comments ... to the world.He was not amused and informed us that the work should be perfect every time! I pointed out that while everyone strives for just that, that it was an unreasonable response, and doesn't do much to foster team morale or cooperation.This went back and forth for a while until I decided that this idiot simply wasn't worth my time.A few days later, I hear one of my peers having the same conversation with our boss+1. A few days later, someone else. Each time, the architect had been bypassed and some junior developer missed something; it was always some ridiculous trivial facet of the implementation.I got together with my peers and discussed possibly instituting mandatory testing - by US - to prevent them from bypassing us to get junior developers to do stuff and then having it thrown into a user-visible environment. We agreed, and were promptly overruled by boss+1. Apparently, all programmers, even juniors, were expected to produce perfect code (even without requirements) every time, without exception, and anyone who couldn't cut it should be exposed as incompetent.We just shot each other the expected Are you f'g kidding me? looks.After a few weeks of this, we had all had enough of the abuse and went to boss+2, who was totally disinterested.We all found other jobs, and made sure to bring the better junior devs with us. [Advertisement] Easily create complex server configurations and orchestrations using both the intuitive, drag-and-drop editor and the text/script editor. Find out more and download today!
|