Forums
I'll be honest. Code submissions come into our queue sometimes and I have to read them a few times before I can identify the WTF. When Alex asked me to write this one up, I had to read it over line-by-line for almost an hour and figure out what was wrong with it.
This was sent in anonymously, with the note that it's designed to display a pretty, spinning "now loading" image while a report is created.
Cabe B. closed his eyes tightly and sighed. His pager was vibrating and beeping a sad interpretation of O Fortuna. And yet again, their most important server had gotten precipitously hot. If the situation wasn't remedied, XDISP1 would shut down.
It was the early 2000s and Cabe was working for a small startup. And for all the freedom, responsibility, and opportunities to get creative that his position afforded, it was a little frustrating that the budget for the "datacenter" wasn't larger. It was a claustrophobic little room with walls and shelves holding mostly repurposed workstations that were acting as servers and telecom equipment. The A/C was unreliable, and would die several times each month. As such, the equipment was always on the brink of overheating. With a ladle and water to pour over the servers, it could've been converted into a decent little steam room. Cabe wanted to stay on top of all these issues, so he set up some monitoring tools that would page him the moment one of the servers reached a certain temperature.
Years ago I was talking to a friend who was just starting to learn about coding. He'd looked at some of my code, and asked why I used class properties with getters and setters instead of public fields. "Isn't it just more code for no real benefit?" he asked. And he was right; in every case, I had a getter and setter simply acting as a public interface to a private field.
I thought about his question for a second, not really knowing the answer. Frankly, it was just The Way I Learned To Do It. And to my dismay, he didn't just go away while I struggled to think of an answer. I eventually waved my hands dramatically and yelled "encapsulation!" Yes, that'll do nicely, I thought. Later that day I was thinking about it some more, and realized that in most cases, he was right. Still, getters and setters are great for inherited classes in which a method of calculation may be different. Accessors certainly have their place, but that place isn't necessarily everywhere.
1:53 AM, and Sacha's phone was ringing loudly. The woman on the other end of the line was trying to speak calmly, but the fear in her voice was obvious. It was clear that this was the first big production failure she'd had to deal with.
"Production job SYSSYNC_VMX_PROD02 failed, it says something about a failure with... JCL? Er, was it TSS?" Embarrassed and flustered, Leah confessed that she forgot to bring her notebook with her and couldn't remember the specific error.
When Yohan J. heard that the invoice generation code had started to run slowly, alarm bells sounded in his head. The invoicing system hadn't been touched in a long while, no business process had changed, no new outside interfaces, no hardware changes, no logical reason that it wouldn't be running as quickly as it always had. In fact, this was just the step that generated the invoice; not invoice items, just creating a draft invoice. A single insert that would produce a single row.
Yohan started by checking the invoice table to get a spread of invoices over the past few months to see if volume had increased substantially. It hadn't. Though, oddly, the six-numerical-digit invoice numbers were all over the board. He spotted an 000015 and a 702438 that were created within hours of eachother. How is it even generating these? he wondered, expecting to find a constraint on the column containing an algorithm to generate the invoice numbers.
It was only his third day on the job, but Dave could tell it was going to be a long one. His fear had come true; what should've been an easy fix (capture an extra data field) was going to involve him debugging a long regular expression that had no comments revealing its pattern. Its arcane characters may as well have been heiroglyphics, and as regular expressions often do, it looked as though someone had held down shift while randomly mashing the number keys. Worse still, there were recursive methods used to parse these expressions. If you added in linked lists you'd have a CS101 student's personal hell.
"I mean, it's not that regular expressions are bad," he explained to a colleague, "it's just that they're ridiculously hard to interpret when they get to have so many groups and submatches and whatnot."
Although it was a giant telecom, Mike couldn't have imagined how huge "AQ&V" actually was. What seemed like miles of occupied cubicles stretched from wall to wall in labyrinthine passages. Weaving their way through aisles of well-dressed employees silently typing on their computers, Mike and his prospective boss arrived at a conference room and began their interview. It must have gone well, since Mike got a call with an offer on his drive home.
He'd be working for the major telecom's "network health" team. The goal was to build and maintain applications and reports so that the company would find out about outages before the customer did. At least in theory. Mike was particularly interested in the work since AQ&V was his ISP, and he knew all too well why they'd gained a reputation for terrible service. Most customers, Mike included, had learned that it wasn't even worth bothering to call and complain about outages anymore.
Question: when you're accepting input from a user, one should always:
I'll leave that to you to determine the correct answer. One of Joshua S.'s colleagues, "Dave," chose D.
Feb 09