Grace was tracking down some production failures, which put her on the path to inspecting a lot of URLs in requests. And that put her onto this blob of code:

app.get(
    (
      [
        "/api/ddm/getProjectList",
        ":dueDate",
        ":status",
        ":userAssignedId",
        ":managerID",
        ":clientID",
        ":projectHeaderID",
        ":tagId",
        ":companyId",
        ":clientGroup",
        ":isDefault",
        ":dateRange",
        ":dateToFilter",
        ":tagIds",
        ":statusIds",
        ":repeatValues",
        ":engagementID?",
        ":completionDate?"
      ]
      .join( "/" )
    ),
    ddmDboardCtrl.getProjectList
);

Last week's out of order logging reminded Adam R of a similar bug he encountered once.

The log files looked like this:

Matthias sends us what he calls the "tern of the century". Which, before I share it with you: bad news, it's just a regular bad ternary. But it remains bad in interesting ways, so it's definitely worth talking about. But let's not oversell it.

private static String getOrderTypeCode(CreateOrderRequest order) {
  return !StringUtils.isBlank(order.getOrderParams().getReceivingCompanyFoo()) && ORDR_TP_DQQ_FOO.equals(order.getOrderParams().getOrderType()) ? ORDR_TP_DQQ_BAR_CDE : order.GetOrderParams().getOrderType().getOrderTypeCode();
}

Philipp H was going through some log files generated by their CI job to try and measure how long certain steps in the process took. He took the obvious path of writing code to read the logfiles, parse out the timestamps, and then take the difference between them.

Everything worked fine, until for certain steps, a negative timestamp was reported:

Today we have a true confession from Carl W. It has the benefit of being in R, which means that at a glance, I just assume "eh, looks fine to me." I guess I'm turning into Jimbo.

But let's dig into it. Carl's first snippet is this: