Category Archives: Facepalm

Stories from the Field, #1: Learn how to push back

(note: all “Stories from the Field” are true, thinly anonymized to protect the -usually- guilty)

Teammate: (goes to a big and important customer)

Customer: I want a software like this and that

Customer: And I want it yesterday

Project Manager: They want it yesterday

Teammate: But I need a bit more time in order to implement some UI checks, so that users don’t make mistakes

Customer: Our users don’t make mistakes, they are permanent employees for so many years, they know their job

Teammate: Hmmmokey

Teammate: (implements software in just a few days)

Teammate: (delivers)

Customer: (installs)

Users: (use the software)

Users: (literally fuck up everything that is possible and some things that are not)

Customer: WHY ARE THE DATA WRONG

Teammate: …but you said…

Customer: you’re not good I want another one

Project Manager: Jim you’re assigned to this

Jim: I will rewrite it from zero and I will implement these UI checks plus many many more

Customer: I WANT IT YESTERDAY

Project Manager: THEY WANT IT YESTERDAY

Jim: (doesn’t give a shit)

Jim: (writes code anywhere, anytime, day, night, while eating, while getting the baby to sleep, while helping his wife with breastfeeding etc etc)

Jim: (delivers)

Customer: Why is this 40MB this is bigger than the previous one I don’t like this

Jim: (loses his shit and starts screaming)

Customer: Jeez why are you so nervous you need to calm down

Customer: (installs)

Users: (use the software)

Users: OH HEY THIS WORKS

Users: IT HAS HELPFUL COLOURS TOO

Users: AND IT HAS EXPLANATIONS FOR EACH FIELD

Users: THIS IS GREAT

Customer: great job Jim, see I told you the first guy was not good

Jim: (silently curses in languages he doesn’t even speak)

Note: to be fair, the “40MB” complaint wasn’t as irrational as it sounds. The software had to be copied to many client computers, some of them in remote parts of the country with slow lines; this was still the days of ISDN. Still, the refactoring was worth it. The added volume was caused by a reporting library (Crystal Reports for .Net) which solved many problems by itself. I now understand the frustration of the customer’s IT as someone had to stay up all night copying. But the pressure from management was so much that at this point the poor guy just said the wrong thing at the wrong time to the wrong person. Elias if you ever read this, please accept my apologies 😊

Signs that you need coffee, #6

You wake up on Monday morning, which is bad by itself because Monday.

You decide you’ll have tea instead of coffee so you boil some water, pour it in a mug and dip two bags of your favourite tea in it.

You go to your home office room to start your laptop, check emails etc.

Then you go back to the kitchen and spend the next 5 minutes wondering where your coffee is.

Please don’t write logs inside Program Files (here’s how to do it right)

So the other day I’m troubleshooting a Windows Service that keeps failing on a server, part of a product we’re using in the company. Long story short, that’s what the problem was:

Access to the path 'C:\Program Files\whatever\whatever.log is denied'

I mean, dear programmer, look. You want to write your application’s logs as simple text files. I get it. Text files are simple, reliable (if the file system doesn’t work, you have bigger problems than logging) and they’re shown in virtually every coding tutorial in every programming language. Depending on the case, there might be better ways to do that such as syslog, eventlog and others.

But sure, let’s go with text files. Take the following example somewhere in the middle of a Python tutorial. Look at line 3:

import logging

logging.basicConfig(filename='app.log', filemode='w', format='%(name)s - %(levelname)s - %(message)s')
logging.warning('This will get logged to a file')

Did you notice? This code writes the log in the same place as the binary. It’s not explicitly mentioned and usually you wouldn’t give it a second thought, right?

To be clear, I don’t want to be hard on the writers of this or any other tutorial; it’s just a basic tutorial, and as such it should highlight the core concept. A professional developer writing an enterprise product should know a bit more!

But the thing is, these examples are everywhere. Take another Java tutorial and look at line 16:

package com.javacodegeeks.snippets.core;

import java.util.logging.Logger;
import java.util.logging.FileHandler;
import java.util.logging.SimpleFormatter;
import java.io.IOException;

public class SequencedLogFile {

    public static final int FILE_SIZE = 1024;
    public static void main(String[] args) {

        Logger logger = Logger.getLogger(SequencedLogFile.class.getName());
        try {
            // Create an instance of FileHandler with 5 logging files sequences.
            FileHandler handler = new FileHandler("sample.log", FILE_SIZE, 5, true);
            handler.setFormatter(new SimpleFormatter());
            logger.addHandler(handler);
            logger.setUseParentHandlers(false);
        } catch (IOException e) {
            logger.warning("Failed to initialize logger handler.");
        }
        logger.info("Logging info message.");
        logger.warning("Logging warn message.");
    }
}

Or this Dot Net tutorial, which explains how to set up Log4Net (which is great!) and gives this configuration example. Let’s see if you can spot this one. Which line is the problem?

<log4net>
  <root>
    <level value="ALL" />
    <appender-ref ref="LogFileAppender" />
  </root>
  <appender name="LogFileAppender" type="log4net.Appender.RollingFileAppender">
    <file value="proper.log" />
    <lockingModel type="log4net.Appender.FileAppender+MinimalLock" />
    <appendToFile value="true" />
    <rollingStyle value="Size" />
    <maxSizeRollBackups value="2" />
    <maximumFileSize value="1MB" />
    <staticLogFileName value="true" />
    <layout type="log4net.Layout.PatternLayout">
      <conversionPattern value="%d [%t] %-5p %c %m%n" />
    </layout>
  </appender>
</log4net>

If you answered “7”, congrats, you’re starting to get it. Not using a path -this should be obvious, I know, but it’s easy to forget nevertheless- means writing in the current path, which by default is wherever the binary is.

So this works fine while you’re developing. It works fine when you do your unit tests. It probably works when your testers do the user acceptance testing or whatever QA process you have.

But when your customers install the software, the exe usually goes to C:\Program Files (that’s in Windows; in Linux there are different possibilities as explained here, but let’s say /usr/bin). Normal users do not have permission to write there; an administrator can grant this, but they really really really shouldn’t. You’re not supposed to tamper with the executables! Unless you’re doing some maintenance or an upgrade of course.

So how do you do this correctly?

First of all, it’s a good idea to not reinvent the wheel. There are many, many, MANY libraries to choose from, some of them very mature, like log4net for Dot Net or log4j for Java.

But if you want to keep it very simple, fine. There are basically two ways to do it.

If it’s a UI-based software, that your users will use interactively:

Create a directory under %localappdata% (by default C:\Users\SOMEUSER\AppData\Local) with the brand name of your company and/or product, and write in there.

You can get the localappdata path using the following line in Dot Net:

string localAppDataPath = Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData);

Take for example the screen-capturing software called Greenshot. These guys do it right:

If it’s a non-interactive software, like a Windows Service:

You can do the same as above, but instead of Environment.SpecialFolder.LocalApplicationData use Environment.SpecialFolder.CommonApplicationData, which by default is C:\ProgramData. So your logs will be in C:\ProgramData\MyAmazingCompany\myamazingproduct.log.

Or -not recommended, but not as horrible as writing in Program Files- you can create something custom like C:\MyAmazingCompany\logs. I’ll be honest with you, it’s ugly, but it works.

But in any case, be careful to consider your environment. Is your software supposed to run on Windows, Linux, Mac, everything? A good place to start is here, for Dot Net, but the concept is the same in every language.

And, also important, make your logging configurable! The location should be changeable via a config file. Different systems have different requirements. Someone will need the logs somewhere special for their own reasons.

But whatever you do, PLEASE PLEASE PLEASE DON’T WRITE WHERE THE BINARY IS. DON’T WRITE IN C:\PROGRAM FILES. IT. DOES. NOT. WORK.

Signs that you need coffee, #5

You wake up on a beautiful sunny Swiss Sunday morning.

You go in front of your filter coffee machine which, spoiler, you have programmed to brew a coffee on a fixed time every day except Sunday.

You wait, like, 5 minutes in front of it wondering why there’s no coffee in the pot and pondering conspiracy theories which you will not confirm nor deny to include coffee-snatching aliens from Tau Ceti.

Signs that you need coffee, #4

You go at the office machine and put an espresso cup in place, which can hold 60 ml max.

You slide in an espresso capsule.

You press the “Large” button which produces around 110 ml coffee.

(spoiler alert, 110 ml is much more than 60 ml)

You stand in front of the machine in amazement while the coffee overflows the cup, wondering what went wrong.

You thank your good fortune that spared you the embarrassment as no colleague was in the company canteen at that time 🙂

Serious but hilarious NSA anecdotes

(This one’s for IT guys, perticularly crypto geeks, source is Schneier’s blog)

NSA recently declassified a lectures book from 1973. It contains some real gems, such as these from pages 55/56:

KAG-1/SEC used to be the bible of US cryptographers, was held in every crypto-center and covered everything from message preparation to compromise reporting in considerable detail. While we viewed it as a model of clarity, this perception was not always shared in the real world. A frustrated Navy Chief stormed out of bis crypto-ccntcr on board a carrier at sea, banded KAG-1 to a sailor and jokingly said “Throw this dam’ thing overboard.” He did. Several ships thereafter steamed back and forth for several days, but never found it. Winds, tides, and currents were studied to predict where it might come ashore with results so ambitious as to offer little hope and, in fact, it was never recovered – at least by us.

This incident triggered an R 1 study on what happens to our documents in salt water. A tank was made, and a copy of KAG-1 immersed. It stayed there for a year or so with no sign of deterioration. Agitators were added to stimulate wave action for another few months, with still no appreciable effect. We never did find out how long such a document would last. Subsequent work, however, has shown that good paper is nearly impervious to salt water, apparently indefinitely. A visit to S2’s exhibit of materials recovered from the sea bottom will bear that out. There you can see perfectly legible codes that had been under water since World War II, together with extraordinarily well-preserved items of hardware and magnetic tape that had been on the bottom for many years. These facts add to the previously expressed skepticism about jettison as a way to get rid of our stuff unless at very great depths and in completely secret location. (Shortly after WWII, small Army training crypto-devices called the SIGFOY were disposed of beyond the 100 fathom curve off Norfolk. Some years later, they became prize souvenirs for beach combers as they began washing ashore.)

UNSOLVED PUZZLE – We used to store a lot of cryptomaterial in a warehouse at Ft. Holabird. It was fenced and protected by a 24-hour armed civilian guard. One evening, such a guard saw an individual inside the fence, evidently attempting to penetrate the warehouse. He drew his weapon, cried “Halt!” and led the individual to the guard shack and started to call in for help. About that time, the intruder started running, climbed the fence, and disappeared.

We asked the guard why he didn’t shoot – he said he was afraid he might hurt somebody.

CONFETTI – When we manufacture one-time tape, a by-product of the punching process is millions upon millions of tiny, perfectly circular pieces of paper called “chad” that come out of holes in the tape. This chad was collected in burn bags and disposed of. Someone thought it would make good public relations to give this stuff to high school kids for use as confetti at football games. Inevitably, one of the burn bags was not quite empty when the chad went in. At the bottom, were a couple of TOP SECRET key card book covers and a few assorted keys. They carried the impressive caveats of those days like “CRYPTO – CRYPTO-CLEARANCE REQUIRED” and were, to use a term earlier referred to, “fascinating” to the kids when they discovered them.

One of the girls, whose father happened to be an Army officer, tacked soine of this material on her souvenir board. When Daddy saw it, he spiralled upward. He decided that it must be destroyed immediately; but first made a photograph of it for the record. He tore it up, flushed it away, and reported in. With some difficulty, various cheerleaders and other students who had glommed on to some of this material were tracked down, and persuaded to part with it.

We no lonser issue confetti.

A History of U.S. Communications Security (Volumes I and II);

the David G. Boak Lectures, National Security Agency (NSA), 1973