Forums
These fine folks make it possible to run The Daily WTF.
Tim H inherited some code which has objects that have many, many properties properties on them. Which is bad. That clearly has no cohesion. But it's okay, there's a validator function which confirms that object is properly populated.
The conditions and body of the conditionals have been removed, so we can see what the flow of the code looks like.
Today's anonymous submission is one of the entries where I look at it and go, "Wait, that's totally wrong, that could have never worked." And then I realize, that's why it was submitted: it was absolutely broken code which got to production, somehow.
Collection.updateOne(query, update, function(err, result, next)=>{
if(err) next(err)
...
})
An anonymous cable-puller wrote "Reading a long specification manual. The words "shall" and "shall not" have specific meaning, and throughout the document are in bold italic. Looks like someone got a bit shall-ow with their search-and-replace skills."
I feel like we've gotten a few SQL case statement abuses recently, but a properly bad one continues to tickle me. Ken C sends us one that, well:
SELECT CASE h.DOCUMENTTYPE
WHEN 2 THEN 3 WHEN 3 THEN 4 WHEN 4 THEN 5
WHEN 5 THEN 6 WHEN 6 THEN 7 WHEN 7 THEN 8
ELSE h.DOCUMENTTYPE
END AS DocumentType,
h.DOCNMBR AS DocNmbr,
h.FULLPOLICY AS FullPolicy,
h.BATCHID AS BatchId,
h.OrigBatchId,
h.UPDATEDDATE AS UpdatedDate,
h.CUSTOMERNO AS CustomerNo,
h.PROJECTID AS ProjectID,
h.AMOUNT AS Amount
You've already read the longer version. You need a quick phrase of corpo-speak to distract and confuse your rivals. Here's the generator for doing that:
As we all know, there are two basic kinds of scientific studies. The first is a ground-breaking paper that changes the way we view the world, and forces us to confront our presuppositions and biases about how we think the world works, and change our perspective. The other tells us what we already know to be true, and makes us feel good. The second kind, of course, is what we'd call "good science".
Or, if you want to skip past this straight to the generator at the bottom.
Sandra from InitAg (previously) works with Bjørn, and Bjørn has some ideas about how database schemas should be organized.
First, users should never see an auto-incrementing ID. That means you need to use UUIDs. But UUIDs are large and expensive, so they should never be your primary key, use an auto-incrementing ID for that.
Angela's team hired someone who was "good" at SQL. When this person started, the team had some regular jobs which ran in the mornings. The jobs were fairly time consuming, and did a lot of database IO. When their current database person left for another job, they hired someone who had a "good grasp" on SQL. We'll call him Barry.
Barry started out by checking the morning jobs every day. And over time, the morning jobs started getting slower and slower. That was a concern, but Barry swore he had it under control. Barry did not share that a handful of slow queries- queries which took three or so minutes to run- had suddenly started taking 75+ minutes to run. Barry didn't think about the fact that a little time with the query planner and some indexes could have probably gotten performance back to where it should have been. Barry saw this problem and decided: "I'll write a Python script".