About

I'm Mike Pope. I live in the Seattle area. I've been a technical writer and editor for over 30 years. I'm interested in software, language, music, movies, books, motorcycles, travel, and ... well, lots of stuff.

Read more ...

Blog Search


(Supports AND)

Google Ads

Feed

Subscribe to the RSS feed for this blog.

See this post for info on full versus truncated feeds.

Quote

"Does this break a rule?" is the first question and "Does it work?" is the second question. If "Does it work" outweighs "Does it break a rule," then it's OK to break the rule.

Merrill Perlman



Navigation





<March 2023>
SMTWTFS
2627281234
567891011
12131415161718
19202122232425
2627282930311
2345678

Categories

  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  
  RSS  

Contact Me

Email me

Blog Statistics

Dates
First entry - 6/27/2003
Most recent entry - 2/21/2023

Totals
Posts - 2642
Comments - 2655
Hits - 2,552,688

Averages
Entries/day - 0.37
Comments/entry - 1.00
Hits/day - 354

Updated every 30 minutes. Last: 9:37 PM Pacific


  09:32 PM

On Twitter recently, DeAnna Burghart reminded us that if you use Microsoft Word, it's important to back up your Normal.dotm file. If the file is overwritten or corrupted, you lose your macros, your keyboard shortcuts, and other goodies that editors rely on.

I've experienced that problem, gah. So a while back, I set up Windows so that it automatically backs up my Normal.dotm file several times a day. I thought it might be useful to show other people how I did this.

Sad note: The information in this post applies only to Windows. I'm sure there's a way to do this on the Mac, but I don't currently know how to do it.

I realize that this is a long post and therefore looks complicated. It isn't, I promise! I added some extra steps to test as you go to try to make sure that you don't Experience Disappointment.

Update: I created a video version of this tutorial!

Background

To back up your Normal.dotm file, you copy it from its default location (i.e., where Word looks for it) to some other location. AFAIK, the default location is always this:

DRIVE:\Users\YOUR-USER-NAME\AppData\Roaming\Microsoft\Templates

For example, my Normal.dotm file is here:

C:\Users\Mike\AppData\Roaming\Microsoft\Templates

You can certainly copy the file manually. But you can also automate the copy process so that Windows copies the file for you. You might sometimes forget to back up your file by hand, but if you automate the process, you never need to worry about it.

What I did—and what I'll show you here—is that I created a script. The script doesn't just copy the Normal.dotm file to another folder. During the copy process, it names the backup file by adding a date and time stamp. For example, the script creates a file that has a name like this:

Normal(2021-04-26 17_49).dotm

You can see that the filename includes the date (Apr 26, 2021) and time (5:49 pm). Timestamping the backup files has two advantages:

  • Each time you run the backup, you make a new, different backup file. This can be useful if Normal.dotm gets corrupted—you have multiple backup versions of the file, some of which (hopefully) are older than when the corruption occurred.
  • You know when the backup was made.

I use two technologies for the automated backup:

  • PowerShell. This is a programming language that lets you automate Windows tasks like copying files. PowerShell has been in Windows since Windows 7, so you don't need to install anything. I have the complete script in this post, so you don't need to know PowerShell; you can just copy and paste the script.
  • Windows Task Scheduler. This is a Windows utility that lets you run tasks—for example, a script—at specific times or at intervals.

Create the PowerShell script

  1. Create a folder named C:\backup on your computer to copy the backup files to.

    You don't have to use this folder; you can use any folder you like. Just make sure that the folder already exists. (The script won't create it.) If you don't use C:\backup, you need to make some minor changes later.

  2. Open a text editor (for example, Notepad ... don't use Word for this), create a new file, and then copy the following script into it:
    # PowerShell script to back up the Word Normal template (Normal.dotm)
    # 2020-Apr-26 Mike Pope
    
    $bu_path = "C:\backup"
    
    $bu_datetime = Get-Date -Format "yyyy-MM-dd HH_mm"
    $source_file = $env:appdata + "\Microsoft\Templates\Normal.dotm"
    $dest_filename = $bu_path + "\Normal(" + $bu_datetime + ").dotm"
    Write-Output $dest_filename
    Copy-Item -Path $source_file -Destination $dest_filename
  3. If you don't want to use the C:\backup folder, change the path in the third line (the one that starts with $bu_path =). Make sure that you don't add a trailing backslash (\) to your path.
  4. Save the file to the C:\backup folder (or your alternative) using the following name:

    back-up-normal-template.ps1

    The .ps1 extension is used for PowerShell scripts.

  5. Close the text editor.

Test the script

Before you create a scheduled task for the script, it's a good idea to make sure it's working on your computer.

  1. Open a Windows command window. (Press Windows+s, then type CMD). You see a command line:

  2. Enter the following command (better yet, copy and paste it):

  3. powershell.exe -ExecutionPolicy Bypass -File "C:\backup\back-up-normal-template.ps1"

    Again, if you're not using C:\backup, substitute your folder name.

    The command invokes PowerShell and tells it to run the script that's in the back-up-normal-template.ps1 file that you created earlier. The ExecutionPolicy argument tells PowerShell that your script is safe; if you don't include this part, PowerShell will refuse to run the script due to security concerns.

    If all goes well, the script displays the name of the backup file, like this:

    C:\backup\Normal(2021-04-26 17_59).dotm

    If you see red text, read it carefully. Carefully check the command that you entered. You might also need to fix the script itself (the .ps1 file). Some possibilities:

    • The script you used earlier assumes that the Normal.dotm file is in the default location. If the file is in a different location, it's possible the script isn't finding it.
    • If you're not using the C:\backup folder, did you fix up the script to reflect the folder that you are using?

    You must resolve any errors before you can proceed.

  4. If the script appeared to run correctly, look in the C:\backup folder (or the folder you are using instead). Do you see a .dotm file that starts with Normal followed by a date and time? If so, everything is working.

Schedule the backup

You can now configure Windows to run your script at intervals. You do this by creating a scheduled task. When you create the task, you specify what you want to run (the PowerShell command that you just tested) and when you want to run it.

  1. Open the Task Scheduler app. (Press Windows+S, then type Task Scheduler.)

  2. In the folder tree on the left, right-click Task Scheduler Library and then click New Folder. Name the new folder My Tasks. This step isn't essential, but it makes it easier for you to find your custom task later if you want to modify it.

  3. Right-click the My Tasks folder and click Create Task. This opens the Create Task dialog, which has several tabs that you'll be working in.

    Note: Don't close the Create Task dialog (that is, don't click OK), until you've done all the steps.

  4. In the General tab, do the following:

    1. In the Name box, enter the name BackupNormalTemplate.

    2. In the Description box, enter details about what this task is about.

  5. Go to the Actions tab and click New. This is where you specify what you want to run—namely, the PowerShell script.

    1. In the Program/script box, enter powershell.exe.

    2. In the Add arguments box, enter the following:

      -ExecutionPolicy Bypass -File "C:\backup\back-up-normal-template.ps1"

      These settings specify that you want to run the PowerShell script that you tested at the command line earlier.

    3. Click OK to close the New Action dialog and return to the Create Task dialog.

  6. Go to the Triggers tab and click New. This is where you specify when (how often) to run your script.

    1. Under Advanced settings, select the checkbox next to Repeat task every.

    2. Enter an interval for how often you want to run the script. For example, to run the script twice a day, enter 12 hours. (It doesn't look like it, but you can type in that box.)

    3. In the for a duration of list, choose Indefinitely. This tells Windows to keep running the script until you change the interval or delete the scheduled task.

  7. Click OK to close the New Trigger dialog.

  8. In the Create Task dialog box, click OK.

Note: Don't close the Task Scheduler window yet.

Test the scheduled task

You know that the script runs; now you want to make sure that the scheduled task works.

  1. In the Task Scheduler, in the file tree, click the MyTasks folder. The list of scripts in that folder is displayed on the right.

  2. In the right-hand pane, right-click the BackupNormalTemplate task and then click Run.

    The PowerShell scripting window appears briefly, then vanishes.

  3. Go to the C:\backup folder and check that another backup copy of the Normal.dotm file has been saved.

    If this worked, you should be all set.

  4. Close the Task Scheduler app.

You probably want to check the C:\backup folder tomorrow and the next day to make sure that the script is writing out backup files at regular intervals.

If you need to recover a Normal.dotm file, go to the C:\backup folder, rename one of the backup files to just Normal.dotm, and then copy it back to the folder where Word keeps the template.

Hopefully you'll never need to do that. But if you do, you'll have a recent backup available!

[categories]   , ,

|


  08:54 AM

The hazards of overclaiming

I was listening to a podcast yesterday when it was interrupted with an ad that started like this:

Do you have 30 minutes to spare? Because after just one half hour, you'll never have to worry about a break-in at home again. That's how easy it is to set up a security system from [company name].

My editor brain froze at the point. What I heard was a claim that if you installed their system, you would not be broken into—you would be protected against burglary forever ("never have to worry").

When we technical-edit documents at work, one of our priorities is to check for what we call overclaiming. For example, we stay on the lookout for instances of overclaiming about security, like this:

This product prevents bad actors from hacking your system.

A claim like this simply can't be guaranteed. In the realm of security, the apparent strength of your product might just mean that a hacker hasn't found a flaw in it yet. For example, encryption algorithms that once seemed secure enough to be used by the NSA have been cracked.

We look for overclaiming in any discussion of performance:

Using this product makes your applications three times faster.

We look for it in mentions of costs:

This product reduces your computing costs by 50 percent.

For performance claims, we warn authors that anything that states a number has to have data to back it up. If you say your product is three times faster, you better be able to produce the tests that show this. The same applies to any mention of costs: numbers, please.

And we look for it in any text that involves comparison to other products:

Our product is substantially easier to use than [competitive product].

This claim is problematic in multiple ways. First, what does "easier" even mean? Something that's easy for me might be hard for you and vice versa. And competitive products are a moving target anyway; perhaps our product is "easier" than the current version of product X, but who knows what's in their next release.

So naturally I stumbled over "you'll never have to worry about a break-in at home again." But I thought about it for a bit. First, it's advertising copy, not a technical document on how to configure cloud computing. Maybe there's more wiggle room for wild claims, as in, people aren't expected to interpret these things literally.

I also homed in on the phrase "worry about." With some work, this can be made ambiguous. One idiomatic interpretation is that it means that something won't occur:

What if we run out of Cheetos tonight?
You don't need to worry about that[, we just went to Costco].

A more literal interpretation is that, well, you don't need to worry. This is the type of messaging that insurance companies use: it's not that [thing] won't happen, it's that you can stop worrying about [thing] happening because insurance.

I have a hard time fitting this second meaning onto the ad copy for home security systems. But if I had to defend that statement in court, say, that's what I'd go with.

Speaking of consequences, all of this hypervigilance about overclaiming is of course ultimately about protecting the company. The fear is not just that we'll be shown to have been wrong. ("Sorry.") When people spend vast sums based on assurances that you've given them about security or performance or cost, and when those assurances don't prove true, they might take a litigious turn of mind. At the very least, they're not going to trust you in the future and might look elsewhere to spend their money.

I'm not personally aware of the various companies I've worked for being hauled into court to defend an assertion. ("You said we wouldn't be hacked!") But clearly the lawyercats think about this a lot, and I've certainly participated in my share of fire drills in which we dropped everything to grub through many documents, tweaking some text that was discovered to be overclaim-y.

I would not be surprised to hear an ad from the same company a year from now in which the claim "you don't need to worry about break-ins" has been hedged to something like "Get yourself some peace of mind." If I were editing their copy, that's definitely what would happen.

[categories]   , ,

|


  10:52 AM

Over the weekend I ran a security check on my computer. One of the startling results was the report by my password manager that I had many dozens of "compromised passwords."

After my pulse returned to something resembling normal, I looked a little more closely at the report. What they were not saying, I had to figure out, was that dozens of my accounts had been compromised. They only meant that the password that my password manager is storing for some websites was among the passwords found in someone's data breach.

I looked through the list of affected websites in my password manager and had an Aha! moment: virtually all of them are sites where I use a "throwaway" password. That is, I'm interacting with a site and they insist that I create an account, and I end up using the same password over and over. For example, I've done this for some sites that I intend to visit only once.

This is a bad idea, and I should know better. Reusing passwords is a big security risk.

Think about how this works: you use the same username and your throwaway password for a number of sites. One of the sites is breached, and your password and username fall into the hands of people with mal intent. These people then try your username+password combination on hundreds or thousands of sites. In my case, for example, they could have gotten access to dozens of sites that way.

I like to think that I've reused my throwaway password benignly, only for "unimportant" sites. But I can see in retrospect that even if the sites have no commercial value, someone could impersonate me on those sites and do some sort of mischief.

But I think we can also imagine many people using the same password not just for benign sites, but for important sites. This is one way that people's social media accounts get hacked.

So, in part for my own benefit, let's review some security practices that everyone (me, too) should be following:

Don't use the same password on different sites. As explained earlier.

Use a strong password. A strong password is one that's long and random. It doesn't mean just substituting numbers or punctuation in a word (like S3att!e). A decent approach is to use a passphrase rather than password: not just a string of characters, but a string of words. The longer the phrase, the more "entropy" it was, meaning that it's harder to crack. Many people know the xkcd cartoon that explained this beautifully:

Of course, the site has to allow this. A surprising number of sites still prohibit spaces or have a too-short maximum password length. And the "strong test" that some sites show you as you're creating a password isn't necessarily very good, so don't take their word for it.

Use a password manager. One reason people reuse passwords is so they can remember them. Use strong passwords, as noted, and then let a password manager do the remembering. You just have to remember one password, namely the one for the password manager. (Use a strong password for that, please.)

If a site offers it, use two-factor authentication. Two-factor authentication (2FA) is where you have to provide both a username+password and a one-time password (OTP) that they send you in email or text message. 2FA isn't perfect, but it's better than username+password alone.

Among 2FA options, a good one is a hardware key, like those offered by Yubico. For this, you have a little thing that looks like a USB dongle; as part of your login, you have to touch the key. Hardware keys aren't supported on many sites yet, but you can use them on some important ones, including Gmail. (Full disclosure: we use hardware keys at work.)

Use security questions wisely. In 2008, Sarah Palin was famously hacked by someone who got answers to her security questions by studying her biographical data. The answers to your security questions are probably not that hard to find either—for example, how fast do you think someone can discover your mother's maiden name or your high school mascot? (Many social-media questions and polls seem designed to solicit information that can be used to answer security questions.)

If a site insists that you have to set up security questions, you can create answers that are meaningful to you but that aren't easily guessable. As the simplest possible approach, just lie. Just remember what your lies are. :) A more sophisticated approach is to devise an algorithm for yourself that you always use. For example, maybe you take the first letters of the question and use those as an answer. If the question is "What is your mother's maiden name?," your answer could be WIYMMN. (Don't use this particular algorithm, please.) Or you do something with numbers or whatever. The idea is just to have something that you can reproduce many months hence but that isn't guessable.

Get rid of accounts you're not using. Did you set up an account on Pinterest or Coursera or the Los Angeles Times but you never use it? Delete the account. No password worries then for that account.

And finally, lock down your main email account as tightly as possible. When there are changes to your accounts, like a password change, you often have to confirm them via email. But if your email account has already been compromised, the game is up.

I guess I'll also note that I don't let websites store my credit card number. The only company I really trust is Amazon, in part because during my time there, I was impressed with the level of paranoia that they have about security issues, haha. But if J. Random Website offers to store my credit card info, no thanks.

If you want more details on all of this, I highly recommend a whitepaper written by a couple of the solutions architects at work: Modern password security for users (PDF). They have great ideas about strong passwords, about how to handle security questions, etc.

[categories]  

[1] |


  12:19 PM

In an effort to improve my sleep regimen, I was recently prescribed a CPAP machine. This device helps with obstructive sleep apnea, where your throat closes during sleep. The CPAP machine basically pushes air into your nose and/or mouth to keep things open.

The concept is relatively simple, but it involves technology. You wear a mask; the mask is connected via a hose to the device itself, which blows air and has sensors to adjust the pressure and temperature. There's a water reservoir so the machine can humidify the air it's blowing at you. There are air filters that need to be changed periodically. The mask, hose, and water reservoirs need to be washed regularly.

So how does the manufacturer (Philips) make and distribute a machine that's a this complex but is intended for a wide variety of people? I count four ways, and am wondering about a fifth.

First, before you can take home your CPAP machine, you get a 20-minute training session slash demo. The trainer walks you how to assemble and use the machine, and they give you the schedule and some tips for cleaning.

I read once that people retain 10% of what they hear during a presentation. The exact number (10%) isn't that important; the idea is just that people don't retain everything you tell them.[1] And I think about all the people who use a CPAP machine. Is a 20-minute demo going to be enough to train this wide range of people? My guess is no.

So second, the machine comes with a manual—two, in fact, a quickstart and a detailed manual. These reiterate a lot of what you learn in the presentation, so you have at least the possibility of hearing it all twice. The quickstart has a lot of pictures. (The manual, a few line drawings.) For me, it was an interesting case of reading documentation for something that I felt I kind of already knew but that I needed some refreshing on.

A third way that Philips tries to help their users is through design. For example, when things connect, they go together in only one way. There's only one way to plug in the machine. The hose goes into the machine only one way. The filters and water reservoir go into the machine only one way; you can't close it if they're not right. The nosepiece in the mask has clear markings right on it for how to put it together. These are all versions of self-documenting features: you literally do not need to read the manual to understand how to put together the components.

As another example, there are very few controls on the machine. For basic use, you need to press only a single button to turn the machine on and the same button again to turn it off. There's a second button if you want to adjust the "ramp"—that is, to set the air pressure to increase gradually when you start up the machine.[2]

And there is a fourth way in which Philips can help people. The machine phones home to report a bunch of statistics about the user's sleep. (That part of the machine required no setup at all, which was great.) This feature has several purposes (some of them a little uncomfortable to contemplate), but at least if the distributor is getting odd reports or no reports from the patient, they know something went wrong. Perhaps they contact you if that's the case.

I imagine that with these efforts on Philips's part, most people can manage to put on their mask and get the machine running. But how well Philips does attempt to help users with ongoing maintenance? It's easy to forget to fill the reservoir. Similarly, the training emphasized that you should wash the hose every week. Is everyone really going to do that? I mean, we're all supposed to floss every day, but how many people really do that?

So I wonder. Does the machine stop and display a message if the water reservoir is empty? Does it tell you when it's time to change an air filter? Does it (somehow) figure out that it's time to wash the hose? I don't know, and I'm reluctant to get into a situation where the machine has to tell me these things. But given the many ways in which the machine, once running, can go wrong, I hope that the manufacturer has taken steps to try to keep it going.

All in all, giving out a complex piece of technology to people and expecting them to all use it right is a hard problem. It's clear that the folks at Philips have thought a lot about this and come up with different ways to try to handle it. Still, I am curious how many people fail when trying to use the machine—they never figure out how to use it, they use it wrong, or they don't maintain it and the machine itself fails. As someone with a professional interest in communicating complex concepts, I find this to be an interesting challenge.

[1] Someone on my team at work has a variant on this idea: you need to hear something 7 times before you learn it. ^

[2] There is also a dial that you can use to make a bunch of other settings, and the dial is multi-modal: turn left for one mode, turn right for another mode, and push for a third mode. Arg. I hate multi-modal controls. But at least this one is optional after you've done the initial setup. ^

[categories]   ,

[1] |


  08:15 PM

I spend a lot of time on social media—Facebook, Twitter, and Instagram. There's value here; for example, I "know" many people only through these media, and I much appreciate what I've learned from them. For example, I know hardly any linguists IRL, but I follow many on Twitter, and it's great.

But even I can tell that I overdo it. It's a time suck, and it's an easy way to procrastinate when I need to be doing, you know, work. ("While this documentation is building, I'll just check Twitter quick-like.")

More insidiously, too much social media starts making me cranky. And when I get cranky, I do unfortunate things, like respond in pissy ways to innocent posts by other, nicer people. Or, gah, I give in to the temptation to respond to morons and their idiotic political opinions, a no-win situation if ever there was one.

So I decided recently to implement what I'm calling Asocial Sundays. Between midnight on Saturday night and midnight on Sunday night, I don't visit any social media sites, period.

This is a new experiment, but I can see some benefits already. Not having the option of social media redirects my attention to more productive things. If I'm sitting at my desk and finish some task—paying bills, say—I don't just mindlessly switch to FB or Twitter to see what's up. Instead, I might actually get up from my desk and wander into the rest of the apartment.

It also has been a way to unplug from a source of stress. We all know that it is distinctly not conducive to good sleep to doomscroll Twitter before bed. Politics and COVID are inescapable on social media, and both are not only inherently stressful, they're sources of endless arguments, outrage, scolding, shaming, uninformed opinions, and on and on. It's nice to take a break from that.

I'm far from ready to withdraw altogether from social media, the way some of my friends have. (A social media detox or social media fast, as it's sometimes called.) I've occasionally considered unplugging permanently from Facebook because their ad models are scary and because Zuckerberg is an incorrigible weasel. But as I say, I still get a lot from my social interactions.

If the experiment goes well, I might at least expand my lights-out policy for social media. I suspect that the more I do it, the easier it will be to use social media in a healthier way.

[categories]   ,

|


  10:42 AM

One of the effects of this year's protests is that it has brought about heightened consciousness about language and how it affects or reflects certain thinking. For example, there have been discussions in the editorial community about capitalizing the word Black "in a racial, ethnic or cultural sense."

In the world of IT, we've been discussing the implications of certain terms for a while. The Microsoft style guide has suggested for a over a decade that writers avoid the terms whitelist and blacklist in order to avoid a connotation that white==good and black==bad. (I wrote about this a while back.)

Our own style guide has a section on inclusive language, and it suggests finding alternatives to a range of language that, when you look at it consciously, can have negative connotations or the possibility of offense. In addition to disrecommending the word blacklist, we tell our authors to use alternatives to terms like crippled system, dummy variables, sanity checks, native features, and first-class citizen.

A short digression about cloud technology. (For tl;dr, you can skip to the discussion of terminology.) We work in the world of cloud computing, which has its own concepts and vocabulary. The cloud, as the jokey definition goes, is just using someone else's computer. More specifically, it means using someone else's one or ten or hundreds of computers, because a fundamental benefit of the cloud is that you can adjust computing power as needed. For example, if you have a retail business, your website might need medium power normally, low power during a summer slump, and heavy-duty computing power to handle your yearly sale. The point is that your need for computing resources goes up and down, and rather than having to build out your own data center to accommodate the maximum possible demand (and whose high capacity might mostly just sit idle), you build your system in the cloud and spin up computers (servers) when demand is high, and take them down when they're no longer needed.

In this environment, computers are commodities. Any single computer is just a faceless worker in your overall computing infrastructure. Compare that to the computer sitting on your desk; you've probably personalized how it runs, installed many updates, and otherwise fussed over it. If one of the faceless computers in the cloud crashes, it's not a big deal; another one spins up and carries on the work. On the other hand, if your personal computer crashes, it's usually a disaster.

Ok, back to terminology. To conceptualize the difference between the faceless fleet of computers in the cloud and your personal computer, technologists devised the metaphor "cattle, not pets."[1] If a computer is a quasi-anonymous something that can be replaced any time, it's "cattle"; if it's an indispensable part of your work, it's a "pet."

Some authors love this metaphor, because, undeniably, it has explanatory power. More than once it's appeared in a document I'm editing, and if I question it, I'll be pointed to how widespread the expression is in IT/cloud texts. And we try to use the vocabulary of our audience.

However. One of my colleagues recently pointed out what might be obvious to a lot of people: the expression "cattle, not pets" is … problematic. One of our principles is "avoid unnecessarily violent language," and once you think about it, you realize that there's implicit violence in the metaphor as pertains to the fate of the "cattle." Moreover, there are cultures in which no cow is just "cattle," and for whom the idea of animals being killed is abhorrent. Therefore, we've updated our guidance to "avoid the use of figurative language that relates to the slaughter of animals."

This sets up a tension we sometimes have when we tell writers to avoid terminology that's still common in a field. We might ask authors to avoid whitelist or cattle-not-pets, and they'll point out that these are well-understood expressions and that using some alternative form potentially confuses readers. ("Allowlist? Did you mean whitelist? Why not just say so?") And people might search for these terms and they'll have no joy if they don't appear in our documentation. Plus it can give off the vibe that we don't know our own field.

But change begins at home. Sure, these problematic terms are part of the industry lingo. And we can't just ignore them out of existence. What we often do, then, is to include the expression parenthetically on first mention of the preferred term. So we might suggest something like "Create an allowlist (whitelist)" or "servers as commodities (sometimes referred to as 'cattle, not pets')" to tie the old term in the reader's mind to a new, better one.

We hope that the collective work of consciousness-raising by many editors and writers over a period of time will gradually alter the perception of problematic terms. The work is never truly done, of course, but it has to start somewhere.

PS I should note that not everyone supports the idea of this type of language change; there's plenty of pushback in the IT world against changing to "so-called inclusive language." These things are not easy.

[1] Devised to explain scaling by Bill Baker, adapted for the cloud by Randy Bias.

[categories]   , ,

|


  08:25 AM

We've been without a microwave oven for about 9 months now.

This is not because we have some sort of philosophical objection to microwaves; the reason is much more practical. Before we remodeled the condo, there was a built-in microwave above the stove, which doubled as the no-vent/recirculating range hood. We knew that we didn't want this 1980s-era microwave, and we replaced it with a dedicated range hood:

Our initial idea was that we would get a countertop microwave. But once we'd moved in and sorted out the kitchen, there wasn't really an obvious place to put a microwave, because there's just limited counter space, alas.

So we've been doing without. This means we've had to explore substitutes for how we used to use the microwave. Like, how do you reheat leftovers without a microwave?

We use our oven or toaster oven. The room we might have given over to a microwave is taken up by a small toaster oven. That appliance is more useful than a microwave, I think, because it can heat and toast and broil. I make toast all the time, and we have no toaster-toaster, so this is a daily-use device for me.

One of the advantages of a microwave is that it's fast. But heating things in our little toaster oven doesn't take that much longer. It's a little oven, so it heats up pretty fast. It also has a convection setting (which I think just means it has a fan that blows the hot air around). All in all, what might have taken, say, 2 minutes in the microwave takes maybe 8 or 10 minutes in the little oven.

We heat things on the stovetop. Anything that's got liquid—soup, stew, whatever—we can throw in a pot and heat on the stovetop.

There are definitely dishes that would be easier to reheat in a microwave. Leftover pasta, for example. What I've been doing is putting these into a pan on the stovetop with a glug of water and a lid. It's not perfect, since it inevitably steams whatever you're reheating, but it's tolerable.

We (mostly I) heat things in a frying pan. Some dishes can be fried or refried. Heat a splash of oil in a frying pan and toss in your leftovers. If I fried up hash yesterday and have leftovers (unlikely), I can reheat it by giving it a short version of the same treatment again. And if we've got something like leftover rice, I can steam it again, or I can make fried rice.

I never much liked defrosting things in the microwave anyway. These days, if I have to defrost a hunk of hamburger, for example, I'll put it in the Dutch oven on very low heat on the stovetop.

And then there's popcorn. I love me my popcorn, but I never used prepackaged microwave popcorn anyway. I did have a series of microwave poppers, but they have an unfortunate tendency to break. So I went to the discount store and got a cheap 6-quart pan that is my dedicated popcorn popper. I heat it on the stove and do that classic thing where you shake the pan as the popcorn pops merrily.

I don't miss the microwave as much as I thought I would. It's been interesting to, in effect, return to our pre-microwave days. I didn't grow up with a microwave (back when they were known as "radar ranges," ha), and it wasn't ingrained in me to rely on it. We might still get one someday, but I think that the longer we make do without it, the less likely it is that we'll want to house one more bulky appliance in our limited kitchen space.

[categories]   , ,

|


  07:00 PM

I commute to work on crowded mass transit, and when I get there, I work in an open office. So I consider good headphones an essential part of my gear. My employer apparently agrees; they subsidize headphones for us. I’ve appreciated the pair I got: over-ear, noise-reducing, Bluetooth headphones. I use them for hours a day every workday.

But the daily use has taken a toll. A few months ago I noticed that the headphones seemed loose on my head. Close examination revealed that the plastic arch between the earpieces had cracked. Thus began an ever more involved effort to save these lovely headphones.

Bridging the crack

My first thought was to patch over the crack. I found a washer that was about the size of a quarter, and used epoxy to glue the washer across the crack, then taped it over to salvage some semblance of aesthetics. (Ha.) was a little dubious about this, but it actually worked ok.

However, a few weeks later the headphones were loose again. I thought my patch had failed, but no—a second crack had appeared at a different point. It seemed clear that there are stress points in the headphones:

I tried a second patch like the first one, but a third crack developed.

Repair or replace?

After this discouraging development, I spent some hours online looking for a replacement for my headphones. I looked and looked, but two things ultimately stopped me from buying a new pair. One was that omg, headphones that have all the features I want (NR, Bluetooth, over-ear, decent audio) are expensive. And to add to this disheartening discovery, many reviews suggested that many other brands of headphones were probably just as prone to breakage as the ones I already had. So I returned to the idea of trying to engineer a fix for the ones I already had.

Brothers of bands

After the severally patched cracks had failed, I kept thinking that I needed to in effect make a new arch for the headphones. I needed some sort of spring-like band of material that I could attach to the headphones. (Some people might already have thought about an obvious solution, which I arrived at later; bear with me a few moments.) I kept thinking about some sort of plastic, but couldn’t arrive at a material that was both flexible enough and had enough spring. What I eventually did was to cut apart the plastic jar from a well-known brand of popcorn and laminating four layers. This seemed to provide the right amount of spring:

I then taped this ad-hoc spring to the headphones with lots of tape, even further reducing their visual appeal:

(I swear that I catch people on the train looking at my jury-rigged headphones and wondering “What the heck is that?”)

Is there a spring for the head?

This worked pretty well for a couple of months. But inevitably, my plastic spring started losing some of its sproing, so I was back to thinking about a better way to make this fix. It finally occurred to me that there is a device that is pretty much designed for this exact purpose: headbands for hair. I betook myself to the beauty section of the local drugstore and pondered my many choices. I ended up with a set of thin metal bands:

I disassembled and reassembled the headphones, this time adding one of the metal headbands to the arch. (I don’t want them to be too springy, because I wear the headphones for long periods and don’t want to squash my ears.)

And that’s where I am today. I’m hoping that this repair, or if necessary, another one like it, will hold until the electronics fail, or I step on them accidentally, or I have some other reason to buy a new pair. And next time I’ll have a head start on ways to fix the headphones when they start cracking.

[categories]   , ,

|


  09:30 PM

I find it harder and harder these days to ride as a passenger when other people drive. Some of that is just part of getting old. But it's not just that; as I've noted before, learning to ride a motorcycle has helped make me a better driver.

One tactic I've worked on is how much space I leave between me and the driver in front of me. To my mind, most people follow too close. You really don't want to do that. Here's why.

Note: If you want the tl;dr, skip to So what do I do?

Speed and distance

Let's start by examining what sort of distance you're covering when you drive, because it might be more than you think. At 10 mph, in 1 second you cover about 15 feet. At 70 mph, in that same 1 second you cover 103 feet. Here's a graphic that illustrates this ratio.

An accepted measure of a car length is 10 feet. This means that if you're going 60 mph, in 1 second you will travel 9 car lengths. Even small differences in speed result in significant differences in how far you travel—the difference between driving at 60 and at 70 is that in 1 second at 70 you will travel an additional 15 feet (88 vs 103). More than one car length.

Braking distance

Let's imagine that for some reason you have to slam on the brakes. Alas, physics tells us that you cannot stop on the proverbial dime. The faster you're going, the longer it takes to get to zero mph.

There's no standard chart for stopping distance for cars. Cars weigh different amounts and they have different brakes; for example, newer cars have anti-lock brakes a.k.a. ABS. (Jeremy Clarkson of the TV show "Top Gear" also makes the case [video] that cars that are engineered to go fast are also engineered to stop quickly.) External factors also come into play, such as the road surface (wet? gravelly?) and the tires on the car. Also whether you're going uphill or downhill.

Anyway, it's complex. The best that people can offer is a minimum braking distance based on a formula that takes into account the initial speed, the car's mass (weight), and the friction coefficient of brakes and road. I'll spare you that here, but I'll suggest some ballpark numbers, as shown in the chart. (You'll see a variety of numbers for this measure if you look around; these are actually on the low end.)

Notice that braking distance at 60 is 180 feet—18 car lengths. That's about 1 city block. Going 70, which of course is only 10 mph faster, the braking distance goes up to almost 250 feet, or an additional 7 car lengths.[1]

Reaction ("thinking") distance

Braking distance is measured from the time the brakes are engaged. But everyone will remind you that there's a delay between the time you see that you have to brake and when you finally get your foot onto the pedal. Remember from the earlier bit that if you delay one second before you hit the brakes, your car might already have traveled many car lengths before you even start slowing down.

The combination of reaction distance and braking distance is referred to as the total stopping distance. Since I'm all about the pretty charts today, here's one from the UK that shows the total stopping distance as "thinking distance" plus braking distance (click to embiggen):

It's the total stopping distance that matters when you're driving behind someone: how far will you keep going before you can stop if something happens ahead of you? Or stated another way, is there enough room between you and the car ahead so that if they slammed on their brakes, you could avoid slamming into them?

As with braking distance, there's no standard measurement for reaction distance. Some people have faster reflexes than others. But even lightning-quick reflexes result in some delay between stimulus and reaction.

And much more importantly, some people pay closer attention to traffic than others. People text while they drive, they yack with their passengers, they watch their GPS, they fool with their radio, they search the passenger footwell for their dropped phone, they watch TV while driving. There have been accidents where the driver behind never hit the brakes at all. In our little car bubble, we sometimes forget that we're piloting 1 ton or more of iron at 88 feet per second, something that's not scary only because we're used to doing it.

And it's your fault

The law generally puts the responsibility on you to leave enough distance. If you rear-end someone, it will almost be always considered your fault. There are a few circumstances when you can make a case that the driver in front contributed to the accident, but the default assumption will be that you were not driving in a safe manner. Not to mention, I suppose, that if you have an accident, you will have had an accident, with all the hassle that that entails.

Think of the traffic

Even if you have superhuman reflexes and a physics-defying vehicle that can stop on a dime, leaving a gap between you and the car in front can have benefits for overall traffic flow. By leaving a gap, you can actually minimize the accelerate-then-brake cycle that characterizes most heavy traffic.

Imagine that you’re behind someone and they tap their brakes to slow down by 5 mph. If you’re close, then you, too, have to tap your brakes to slow down. Even this small slowdown, and even if both of you immediately speed up again, creates a kind of wave that moves backward through traffic. In fact, this is sometimes the source of “phantom” slowdowns on the freeway, where everyone slows down for no apparent reason.

However, if you’re far enough behind someone, when they tap their brakes, you might not need to tap yours at all, or you can slow down enough just by easing off the accelerator. And if you don’t have to, the person behind you doesn’t either, and so on backwards through traffic. Result: possible traffic jam averted.

The engineer William Beatty refers to this as "eating" traffic waves. He explains:

By driving at the average speed of traffic, my car had been "eating" the traffic waves. Everyone ahead of me was caught in the stop/go cycle, while everyone behind me was forced to go at a nice smooth 35MPH or so. My single tiny car had erased miles and miles of stop-and-go traffic. Just one single "lubricant atom" had a profound effect on the turbulent particle flow within miles of "tube."
Obviously, there are limitations to this; if traffic is completely stopped, it’s just completely stopped. But if you can help reduce traffic jams by leaving a little extra space between you and the next person, isn’t that a worthy goal?

So what do I do?

When I got my license many decades ago, the rule was to leave 1 car length ahead of you for every 10 mph. If you're going 60 mph, 6 car lengths. As you can see from the various distances listed above, that's probably not enough. And that's even assuming that you can estimate car lengths correctly, which I think a lot of (most?) people cannot. (Little-known fact: the dashed white lines between lanes on the freeway are 10 feet long.)

When I got my motorcycle license, I learned a far more useful guideline: the three-second rule (PDF). The idea is that when the car ahead of you passes some landmark (a streetlight, a sign, anything static), you count "one-thousand-one, one-thousand-two, one-thousand-three." If you reach the landmark before you finish counting, you're following too close.

The rule is useful because it's independent of speed—the faster you're going, the longer the distance is that you go in 3 seconds, so it (kind of) works out. Naturally, this is just a rule of thumb, which has to take into account all the factors that go into how quickly you can stop. But it has the advantage that if you routinely practice counting off your 3 seconds as you drive on the highway, it means you're paying attention, and that's a very big factor in how safely you're driving.

Event horizon

As if it isn't hard enough just to pay attention to the car in front of, you really should be aware of what's going on in front of them. The same motorcycle manual that recommends the three-second rule suggests that you try to see what's happening 12 seconds ahead of you. This is sound advice, because the driver in front of you might not be paying close attention. If you see that the driver ahead will have to slow down even before they're aware of it, you can adjust your own driving accordingly. (This is captured in the concept of assured clear distance ahead, which you can read about in a particularly poorly written Wikipedia article.)

By the way, all of this applies also to cars behind you, and to your side. Driving safely is hard work.

If you can't see ahead of the car in front of you, it's best to leave even more room than you normally would. I actually have this problem a lot. The motorcycle isn’t very tall, of course. And my normal car is a MINI, which sits pretty low to the ground. In both cases, if I'm behind an SUV or pickup or anything larger than that, I have no clue what's going on up front.

Parting notes

People have pointed out that if you leave gaps ahead of you, other drivers will swoop in. That's true. If you have completely mastered the zen of good following practice, you just let them, and you slow down to again open up a suitable gap ahead of you. I will acknowledge that this is a state of driving enlightenment that most of us can only aspire to. Still, it has helped me to think holistically about safety and about traffic, and if I’m in just the right frame of mind (like, not late to an appointment), I can do a decent impression of someone who actually has mastered all this. And of course, if I'm on the motorcycle, I am ever mindful that even a small miscalculation in how closely I follow can have grave consequences.

For the most part, driving is uneventful. Even if we speed, even if we speed and follow too closely, mostly things don't happen. But it's this very uneventfulness that can make us complacent and lead us to stop paying close enough attention to an activity that can wreak mayhem in the "unlikely event of" a crash.[2]

[1] I'm not sure how clear this is, but the "safety" of a large vehicle like an SUV has to do with how well it survives a crash, not in how well it can avoid one by, for example, stopping quickly.

[2] There's a movement to stop using the word "accident" and instead use the word "crash" in order to emphasize that almost all crashes are caused by drivers. The Motorcycle Safety Foundation puts it this way: "Using the word accident tends to make people think safety is a matter of luck, and it isn't."

[categories]   , ,

[2] |


  02:36 PM

Here's a keen thing I learned about from a Vox article: a Chrome extension named Library Extension that adds library information when you're viewing books on Amazon or Goodreads. The extension tells you whether the book you're interested in is available in one or more library systems.

Let's say you're interested in the book The ABC of How We Learn, so you look it up on Amazon. In the bar at the top of the page, the library extension icon lights up to tell you that you're on an enabled site:


On the actual page where you're viewing book information, the extension displays library information:


If you want to get the book from the library, you click the Borrow button. This sends you to the library site with the book preloaded.

To configure the extension—for example, to tell it which libraries you want to look in—you click the icon in the toolbar, then click Options:


In the options dialog, you find the library you're interested in, then click the add (+) button:


I just started using this, so I don't know whether I'll end up liking it. It seems a bit intrusive to actually inject information into the page, instead of optionally displaying that information in a dialog or something. I also don't know how robust it is. Does the extension rely on Amazon APIs? Does it scrape information from the page? (A strategy known to be fragile.) How reliable will it be in terms of interacting with library sites?

But I like the concept just fine, since it reflects something I do a lot anyway—namely, look up books, then see if I can get them at the library. I'm curious whether others use this extension, or something like it, and what they think.

[categories]   , ,

[1] |