JaPythoScriptML

JaPythoScriptML

By | | Comments 0 Comment

More and more I’m discovering that I consume media on my laptop instead of traditional “living room TV”. To some degree it’s a resource contention issue with the family, but even when the TV is available I find watching on a personal device simpler.

An unexpected side effect of that is that I find myself taking screenshots and closely inspecting examples of “source code” that appear onscreen (my genre of choice is sci-fi, so there are plenty of opportunities). The following is from an episode of Westworld:

Looks like some odd mixture of HTML, JavaScript, and Python. Clearly some design work went into this display, even though it was only shown for about second. I can’t help but wonder whose job it is to build out these designs. Must be fun.

Truth And Consequences

Truth And Consequences

By | | Comments 1 comment

Yesterday I was in an all day meeting preparing for a large customer demonstration. Ran into a bug that turned out to be a misunderstanding of how JavaScript handles truthiness. Consider the following code:

if (person.address) {
  console.log('Address is ' + person.address);
}
else {
  console.log('No address.');
}

Seems clean enough right? Not so fast. If person.address is null, no problem. However, if person.address is an empty object, that evaluates to true, and the code fails to do the right thing. To me at least, this is non-intuitive behavior.

I started this blog with a discussion of why I love Python, and once again it behaves more intuitively. Empty dictionary, empty list, None, and empty string all evaluate to False. So the code works in a broader-variety of cases:

if person['address']:
    logging.info('Address is ' + person['address'])
else:
    logging.info('No address.')

Isn’t that nice and clean?

As an aside, most developers have become so accustomed to bracketing punctuation (e.g. braces, semicolons) that they assume there’s no other way. Personally I’ve come to love the lack of noise in Python syntax, and I think you will too.

Duplicity

Duplicity

By | | Comments 2 comments

The problem I described in my last post is relevant to more than just useless code comments. Check out these helpful and totally not redundant download instructions I found on a website today:

I sure am glad the extra text is there to clear up any confusion on which version I needed.

This Is A Post

This Is A Post

By | | Comments 0 Comment

A friend of mine suggested to me a few days ago that the recent Apple vulnerability might have been avoided if the (supposed) offending code had been commented. Perhaps, but perhaps not.

Code comments are a tricky business. Everyone knows they’re a “good thing” but that doesn’t mean every comment is a good one. Blindly them in quantity can actually make code legibility worse. I don’t go as far as Uncle Bob, however, who considers every comment “a failure to make the code self-explanatory.”

For me, a great rule of thumb is that code itself should be expressive enough to communicate the “what”, and comments should be used to explain the “why”. An example is instructive:

# If user is root and there is no root password, don't do the thing
if user == 'root' and password is None:
    dontDoTheThing()
else:
    doTheThing()

See how the comment doesn’t provide any information beyond what the code says? Pretty unhelpful. What a developer who’s asked to maintain this code needs is context, like the following:

# By default an installation of MacOS does not set a root password, thus root
# should never be used as a privileged account unless a password has been set
if user == 'root' and password is None:
    dontDoTheThing()
else:
    doTheThing()

Much better. A comment like that, and maybe Apple doesn’t end up in the headlines.

Even If It’s Broke, Don’t Fix It

Even If It’s Broke, Don’t Fix It

By | | Comments 0 Comment

I doubt we’ll ever learn the root cause of a particularly nasty security vulnerability recently revealed in MacOS High Sierra. But it’s fun to theorize. I’d wager it went down about like this:

  1. In the earliest days of the Darwin kernel, it was decided not to set a default root password, because it could cause usability issues for non-technical people buying Macs
  2. As a consequence, any dialogs or other interfaces that ask for login information had to have special cases built into them to not allow root as an option, or at least not to allow it if no password had been set
  3. Over the years, the number of such widgets grew, requiring more and more little special case checks
  4. The reasoning behind the decision at step one was forgotten, probably to the point where entire teams of developers didn’t even know MacOS has no default root password
  5. While building the High Sierra release, a developer (probably new and/or junior-ish) noticed an odd bit of special-case code in a library that was getting in the way of a new feature being added; a few clicks later and the seemingly unnecessary check was removed, and now the feature worked
  6. QA regression tests the release and finds no problems, because no one thought to try using the unprotected root account in various places (see #4)

Good times, Apple. I feel your pain.

An Apple A Day

An Apple A Day

By | | Comments 0 Comment

Anyone want to speculate on how many .DS_Store files and other MacOS cruft have been inadvertently uploaded to Google Drive, Dropbox, etc? Every time I see these things it’s a reminder that when designing a system, one should never assume it’s always going to be used within whatever comfortable little ecosystem the engineer envisions for it.

Way Way Back

Way Way Back

By | | Comments 3 comments

I’ve had the pleasure of working with a large variety of technologies over the course of my career. Yesterday I was working on an interface to an old government database, without the aid of documentation, natch. After a few hours I was able to extract data from the system, but I was unable to decode it. Google is a great tool (I couldn’t get 15 minutes into my day without it), but if you don’t know what to search for you can’t find anything. Thankfully some careful guesses led me to the Wikipedia entry for EBCDIC, a character encoding developed in the mid-60s.

“Extended Binary Coded Decimal Interchange Code (EBCDIC) is an eight-bit character encoding used mainly on IBM mainframe and IBM midrange computer operating systems. EBCDIC descended from the code used with punched cards and the corresponding six bit binary-coded decimal code used with most of IBM’s computer peripherals of the late 1950s and early 1960s.”

It’s a fun thing in this industry to say you’ve worked with 50-year-old technology, but only once you’ve figured it out. Surprisingly there’s some modern tooling to interface with this particular encoding (yay Python!), so once I knew what I was dealing with it was straightforward enough. Maybe even easier than what it used to be, if this anecdote is to be believed:

EBCDIC: An alleged character set used on IBM dinosaurs. It exists in at least six mutually incompatible versions, all featuring such delights as non-contiguous letter sequences and the absence of several ASCII punctuation characters fairly important for modern computer languages (exactly which characters are absent varies according to which version of EBCDIC you’re looking at). IBM adapted EBCDIC from punched card code in the early 1960s and promulgated it as a customer-control tactic, spurning the already established ASCII standard. Today, IBM claims to be an open-systems company, but IBM’s own description of the EBCDIC variants and how to convert between them is still internally classified top-secret, burn-before-reading. Hackers blanch at the very name of EBCDIC and consider it a manifestation of purest evil.

Don’t Judge Your Book By Its Cover

Don’t Judge Your Book By Its Cover

By | | Comments 0 Comment

It’s been said that Vincent Van Gogh didn’t like _The Starry Night_, which is crazy, because it’s one of the world’s most recognizable paintings, and an obvious masterpiece.

If some of history’s greatest artists were unable to judge the value of their work accurately, how much less so are we. Don’t be quick to disparage your creative efforts, no matter how meager they may seem.

Follow The Money

Follow The Money

By | | Comments 0 Comment

I read this quote in a completely non-software context last week, and it’s been rattling around in my brain ever since for its implications in numerous disciplines:

“It is difficult to get a man to understand something, when his salary depends upon his not understanding it.”

I’ve had experiences where I’ve been trying to explain the benefits of automation to people whose job descriptions include large amounts of manual work. Or more significantly, managers whose bonuses are directly tied to the profit they can bring in via labor hours billed to the customer. Needless to say those explanations fell on deaf ears.

That’s just one example. I’m certain there are more.

Phantom Fix

Phantom Fix

By | | Comments 0 Comment

I’ve got good news and bad news. The good news is that the system is working now. The bad news is that we have no idea why.

The above scenario plays out regularly in the life of a software developer, and it’s infuriating. In some sense it’s worse for a problem to disappear without warning than it is for the problem to persist, because without reproducibility it’s nearly impossible to determine the actual cause of the issue.

This happened to me after losing a big chunk of my Saturday night. Essentially the issue fixed itself after several retries. No idea at all as to why, but at least I could finally go to bed.