Forums
This week we received a plethora of failed text substitutions. I'd like to find a pithy name for this sort of error; suggestions in the comments here will be welcomed.
But before we dive into those typical errors, repeat contributor Valts S. has shared a classic blunder: "White text on white background. Who among us hasn't done this in our lives? :)"
Typos are the bane of delevopers' existence. For most of our typos, the result is a syntax error. It's quick and easy to find and fix. But any time we're working with strings (or in languages where variables are declared at use) there can be many more subtle bugs.
So when Abigail's company sent an intern off to fix a few typos, they thought this was a lovely little low-hanging fruit bug to fix.
There are common errors that are (or were) once so common that we've built tools to help us avoid them. So I was a little surprised to see this JavaScript from Annie's co-worker.
Aug 23toggleField() {
this.updateToggle(this.obj.id, this.toggle).subscribe(data=> {
if (data.status = "success") {
this.showToast('Toggle updated successfully');
...
}
...
}
}
David's organization didn't fully understand why you bring interns into a company. The purpose of an internship is to provide an educational opportunity and resume line-item to someone looking to enter the industry, and possibly recruit said intern after they graduate, getting a new-hire that is more ready for your team than average. It's good for the intern, it's good for the overall health of the industry, it's good for the company building its network of professional relationships and recruiting opportunities.
The purpose of an internship is not to just throw tickets at an intern, and let them commit code to your main branch, unsupervised. Unfortunately for David, and for the poor interns that preceded him, that is what the company had done.
Sometimes, you see a code sample and you almost scroll by. "This isn't bad, I see it all the time." So it took a second glance to see the awful charm of what Henrik H found.
Henrik was asked to join a project to fix a high load website having "some issues". Here's a JavaScript tag that was included on nearly every page.
From our readers this week, we have a couple of mixed numbers. David B even gets a twofer.
Trainspotter Daniel notes "The LIRR now has the technology to pass 9 minutes with only 5 minutes of waiting!" They're apparently doing something nonobvious about scheduled versus expected times in one context, but not in another. Maybe the readers can figure it out.
"John Doe" was asked to take a look at a slow-running application. It didn't take too long to discover that the application was slow because the database was slow, but figuring out why the database was slow involved digging deeply through some logs.
The database was a central system, which many applications connected to. Every ten minutes, performance dropped significantly, and it just so happened that every ten minutes a batch update process ran.
Moz works for a company that needs to handle financial transactions. They use Delphi, which has a handy-dandy fixed precision Currency type, which should make this easy.
Of course, someone opted to do most of the math in double precision floating points anyway. Which lead to this function:
As frequently stated, concurrency is hard. Ensuring that all of your data is accessed in a threadsafe manner is a real challenge. So when Ryan saw a method called ThreadSafeArray, it seemed like an obvious utility method: wrap an array up in a thread safe accessor, right?
Well, the signature of the function made Ryan suspicious. And the code…
Time zones are hard. And, to my surprise, if you want to enumerate all the time zones in the world in C#, there isn't an easy way to do that. You can enumerate all the time zones configured on the host computer (in Windows), but that may be incomplete and also may use idiosyncratic names, since it doesn't use the IANA database of timezones.
This leaves developers with a three real options. The first would be to either load the IANA database yourself, and the second would be to use a library that provides it.
Joseph H. is a little salty about vapid adverts. "Vacation planners long ago figured out that the Great Salt Lake didn't make for great resorts. They must be referring to the up-and-coming land cruises across the desert plains of Utah. Definitely that. No other possible explanation."
The easiest way to write programs that support concurrency is to not. JavaScript in the browser is famously single-threaded, unless you add web-workers, which have a very specific way of interacting with your main script that avoids most of the pitfalls of concurrency. Or at least makes them easy to avoid.
But what if you had a developer who didn't know any of this, and just assumed JavaScript was multithreaded and needed locks, but didn't understand how locks worked? Then you'd get something like this code, from an anonymous submitter.
A decade ago, Adam was doing support on a classic ASP application. This was an internal application which tracked sales accounts, employee reviews, and general HR information. Now, the company had a real HR system, but some of their internal processes predated the HR system, thus they had a custom application that did things the HR system already did, but they already owned the application and didn't want to retrain people.
One day, a manager logged in, started doing some work, took a break, and came back, only to discover that when she pulled up a list of employees, she no longer saw her direct reports, but instead saw all of the employees at the company. She reported the bug and Adam picked up the ticket.
Tracking the performance of an application matters. Too often, developers will try and tune and optimize an application based on their instincts about where the performance is bad- instincts which are frequently wrong.
Remy L's company included performance tracking blocks in their code, enabled by a debug flag. According to the performance stats, their program performed incredibly well. There were rarely ever any long-running methods.
It's Labor Day in the US, which means we're taking a break from the usual grind. Enjoy this classic story about the challenges of providing users with the authentication system they desire- one with no passwords or usernames. Original -- Remy
“It’s impossible,” Gerald said in a matter-of-fact tone, “simply impossible.”
“Now just so we’re clear,” Craig responded, “by ‘impossible’, you actually mean ‘a big pain in the ass’, but you’re a smart guy who can make it happen, right?” That drew a few chuckles from the handful of other coworkers who joined them in the conference room, but Gerald just sighed. “No, Craig, by impossible, I mean impossible. Not doable. Can’t be done. Im-poss-i-ble. Well I mean, unless you can somehow change the underlying structure of the way everyone communicates on the Internet.”
We had to stretch just a little bit to make a purely Microsoft-themed column this week. Gone are the days when it was trivial to make BSOD jokes and rail at Outlook Express. But they still give us material for some lolz now and then.
Well-rested reader
Michael W.
remarks
"After waking up my laptop from a long period of slumber
and logging in I am greeted by the attached error message
on my desktop: You'll need the Internet for this.
Which makes me wonder what do I need the internet for?
The dialog has no title and it's not clear if it's connected
to any other open windows. Whatever the ''this'' is supposed
to reference to stays shredded in mystery providing no context
whatsoever. But I guess it's at least a step up from those
''Internal Error'' message dialogues.
And yes, of course a solution can be googled for, but alas most
of those pages will tell you how to fix a network connection
problem but also mostly won't tell you to what application
or use this dialogue relates to (apparently it's Windows 365 subscription related)"
Obviously, you'll need the Internet to post it to Error'd!