Forums
These fine folks make it possible to run The Daily WTF.
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".
There is no particular theme this week, except that I have noticed many of these contributors are providing "customized" email addresses. This is a practice which I too have followed, to detect who is selling my email address to spammers. I would use a consistent login id for many web sites, and a decent password generated by a mental algorithm, with a unique email address for each site. It worked great until some website wanted to know specifically what "my" email address is, and I couldn't remotely remember which of 300 variant email addresses I had signed up for their services with.
First up, Martin is traveling by air. "I have heard it's so beautiful this time of year, so I look forward to visit @arrCity_SLPH." Martin helpfully explains "First sentence is in Danish: Your SAS-booking has been confirmed."