Forums
To atone for last week's errant Error'd, this week we're giving you 20% extra at no additional charge. For reals.
An anonymous submission starts us off. Ordinarily we wouldn't repost from social media but this is just too delicious.
I frequently write bad code. I mean, we all do, but I frequently write bad code with full knowledge that it's bad, because I first want to test out an idea. Or, I want to inject some additional behavior just for one run, because I'm trying to debug something. If that idea or debugging hook turns out to be valuable, I'll frequently refactor it into something useful and enable it via a flag or something.
Which brings us to the crash Doug was investigating in a VB.Net application. For some reason, the username field was an empty string after logging in, and a bunch of methods which expected the username to have a value misbehaved after that.
Database administrators tend to be pretty conservative about how databases are altered. This is for good reason- that data is mission critical, it's availability is vital, and any change you make threatens that stability and reliability. This conservatism ranges from "we have well defined processes for making changes" all the way to "developers are dangerous toddlers playing with guns and we can't allow them to do anything lest it break our precious database."
"Grumpy" Gus worked with some DBAs that fell much more on the "developers can't be trusted" end of the spectrum. This meant they had big piles of rigorous processes to make sure only the most important, definitely required changes to the database ever got made. The process involved filing several documents, marking an entry on a spreadsheet, emailing a [email protected] inbox, and then waiting. Your request would snake its way through a Database Management Subcommittee, then get kicked over to a Business Need Evaluation Working Group. If the working group agreed that this change met a level of business need, it went back to the subcommittee, which reviewed the findings and if they agreed escalated it to the monthly Database Administration Steering Committee and Database Users Group meeting. Once again, it would get reviewed. If accepted, the DBAs could write a change script, and apply it in the next database maintenance window.
Deanna inherited some code which had gone through many, many previous hands. Like a lot of JavaScript/TypeScript code, it needed to be able to compare objects for deep equality. This is fraught and complicated, and there are many many many solutions available in NPM.
NPM, of course, is its own fraught thing. Widely used libraries frequently have vulnerabilities, and even if you don't use them directly, the nature of dependency management via NPM means that libraries your libraries depend on might.
Many many years ago, when I took my first programming course in high school, our instructor had… opinions. One of those opinions was that you should manually syntax check your code and not rely on compiler errors, because back in her day, you had to punch your program into cards, drop it off in the computer lab, wait for the technician to run your batch, and then pick up the results on the printer. It needed to work the first try or you might be waiting a whole day before you could try again.
One of her other opinions was that your code should contain as many comments as it contained lines of code. Everything needed comments. Everything. Which brings us to this code from Doug.
Shaun F noticed an outage.
"Maybe," Shaun writes, "they should use the Cloudflare Always Online service."
While NoSQL databases have definitely made their mark and have an important role in applications, there's also still a place for RDBMSes. The key advantage of an RDBMS is that, with a well normalized schema, any arbitrary query is possible, and instead of optimizing the query, you optimize the database itself to ensure you hit your performance goals- indexes, statistics, materialized views, etc..
The reality, of course, is wildly different. While the execution plan used by the database shouldn't be dependent upon how we write the query, it frequently is, managing statistics and indexes is surprisingly hard, and when performance problems crop up, without the right monitoring, it can be difficult to track down exactly which query is causing the problem.
Frequent contributor Russell F stumbled across this block, which illustrates an impressive ability to make a wide variety of bad choices. It is written in C#, but one has the sense that the developer didn't really understand C#. Or, honestly, programming.
Sep 21if (row["Appointment_Num"].ToString() == row["Appointment_Num"].ToString())
{
bool b1 = String.IsNullOrEmpty(results.messages[0].error_text);
if (b1 == true)
{
row["Message_Id"] = ($"{results.messages[0].message_id}");
row["message_count"] = ($"{results.message_count[0] }");
row["message_cost"] = ($"{results.messages[0].message_price }");
row["error_text"] = ($"{results.messages[0].error_text }");
row["network"] = ($"{results.messages[0].network }");
row["to"] = ($"{results.messages[0].to }");
row["status"] = ($"{results.messages[0].status }");
row["communicationtype_num"] = ($"1");
row["Sent_Date"] = (String.Format("{0:yyyy-MM-dd hh:mm:ss}", DateTime.Now));
row["Sent_Message"] = row["Sent_Message"].ToString();
}
if (b1 == false)
{
row["Message_Id"] = "0000000000000000";
row["message_count"] = ($"{results.message_count[0] }");
row["message_cost"] = ($"{results.messages[0].message_price }");
row["error_text"] = ($"{results.messages[0].error_text }");
row["network"] = ($"{results.messages[0].network }");
row["to"] = ($"{results.messages[0].to }");
row["status"] = ($"{results.messages[0].status }");
row["communicationtype_num"] = ($"1");
row["Sent_Date"] = (String.Format("{0:yyyy-MM-dd hh:mm:ss}", DateTime.Now));
row["Sent_Message"] = row["Sent_Message"].ToString();
}
}
Like the tides, the popularity of low-code development environments comes in ebbs and flows. With each cycle, the landscape changes, old tools going away and new tools washing up on shore. One one hand, democratizing access to technology is good, on the other, these tools inevitably fail to actually do that. Instead, we get mission critical developed by people who don't understand how to develop, and are thus fragile, and released on platforms that are almost certainly going to be on legacy support in the next cycle.
I don't want to imply that low-code tools are automatically bad, or insult non-developers who want to give developing in a low-code environment a shot, though. Especially when professional developers can't really do any better.
When someone mentioned to Abraham, "Our product has an auto-sync feature that fires every hour," Abraham wasn't surprised. He was new to the team, didn't know the code well, but an auto-sync back to the server sounded reasonable.
The approach, however, left something to be desired.
Two of today's ticklers require a little explanation, while the others require little.
Kicking things off this week, an anonymous reporter wants to keep their password secure by not divulging their identity. It won't work, that's exactly the same as my Twitch password. "Twitch seems to be split between thinking whether my KeePass password is strong or not," they wrote. Explanation: The red translates to "This password is too easy to guess", while the green 'Stark' translates as "you've chosen a very good password indeed."
Using built-in methods is good and normal, but it's certainly boring. When someone, for example, has a list of tags in an array, and calls string.Join(" ", tags), I don't really learn anything about the programmer as a person. There's no relationship or connection, no deeper understanding of them.
Which, let's be honest, is a good thing when it comes to delivering good software. But watching people reinvent built in methods is a fun way to see how their brain works. Fun for me, because I don't work with them, probably less fun for Mike, who inherited this C# code.
Starting in the late 2000s, smartphones and tablets took off, and for a lot of people, they constituted a full replacement for a computer. By the time the iPad and Microsoft Surface took off, every pointy-haired-boss wanted to bring a tablet into their meetings, and do as much work as possible on that tablet.
Well, nearly every PHB. Lutz worked for a company where management was absolutely convinced that tablets, smartphones, and frankly, anything smaller than the cheapest Dell laptop with the chunkiest plastic case was nothing more than a toy. It was part of the entire management culture, led by the CEO, Barry. When one of Lutz's co-workers was careless enough to mention in passing an article they'd read on mobile-first development, Barry scowled and said "We are a professional software company that develops professional business software."
Duncan B was contracting with a company, and the contract had, up to this point, gone extremely well. The last task Duncan needed to spec out was incorporating employee leave/absences into the monthly timesheets.
"Hey, can I get some test data?" he asked the payroll system administrators.
Russell F has an object that needs to display prices. Notably, this view object only ever displays a price, it never does arithmetic on it. Specifically, it displays the prices for tires, which adds a notable challenge to the application: not every car uses the same tires on the front and rear axles. This is known as a "staggered fitment", and in those cases the price for the front tires and the rear tires will be different.
The C# method which handles some of this display takes the price of the front tires and displays it quite simply:
... and gigs for free.
"Apple is magical," rhapsodizes music-lover Daniel W.
I recently started a new C++ project. As it's fairly small and has few dependencies, I made a very conscious choice to just write a shell script to handle compilation. Yes, a Makefile would be "better", but it also adds a lot of complexity my project doesn't need, when I can have essentially a one-line build command. Still, my code has suddenly discovered the need for a second target, and I'll probably migrate to Makefiles- it's easier to add complexity when I need it.
Kai's organization transitioned from the small shell-scripts approach to builds to using Makefiles about a year ago. Kai wasn't involved in that initial process, but has since needed to make some modifications to the Makefiles. In this case, there's a separate Makefile for each one of their hundreds of microservices.
This past Monday, Facebook experienced an outage which lasted almost six hours. This had rattle-on effects. Facebook's pile of services all failed, from the core application to WhatsApp to Oculus. Many other services use Facebook for authentication, so people lost access to those (which highlights some rather horrifying dependencies on Facebook's infrastructure). DNS servers were also strained as users and applications kept trying to find Facebook, and kept failing.
CloudFlare has more information about what went wrong, but at its core: Facebook's network stopped advertising the routes to its DNS servers. The underlying cause of that may have been a bug in their Border Gateway Protocol automation system:
When you promise to deliver a certain level of service, you need to live up to that promise. When your system is critical to your customers, there are penalties for failing to live up to that standard. For the mission-critical application Rich D supports, that penalty is $10,000 a minute for any outages.
Now, one might think that such a mission critical system has a focus on testing, code quality, and stability. You probably don't think that, but someone might expect that.
The year was 2015. Erik was working for LibCo, a company that offered management software for public libraries. The software managed inventory, customer tracking, fine calculations, and everything else the library needed to keep track of their books. This included, of course, a huge database with all book titles known to the entire library system.
This week's installation of Error'd includes a few submissions which honestly don't seem all that WTFy. In particular, this first one from the unsurnamed Steve. I've included it solely so I can pedantically proclaim "24 is not between 1 and 24!" There is still a wtf here though. What is with this error message?
Insufficiently pedantic Steve humorlessly grumbles "Configuring data pruning on our Mirth Integration Engine. Mirth can do many things, just can't count up to 24."