Saturday, February 8, 2020

Music in my Soul

Today, I gained back a piece of my soul.

Five weeks ago all of my music (iTunes/Music) playlists went missing

My music was in my library, but my playlists were all duplicated, in name. One playlist had all of my music and the other was empty. After opening and closing the macOS Music app several times, the duplicate playlists remained. So, I deleted the empty playlists... all 85 of them. Over the course of the next ten minutes, all of my playlists disappeared on my iPhone, iPad, TV, and HomePods (thanks to iTunes Match, Apple's music cloud syncing service). My playlists remained on my Mac, but clearly there was a problem, so I called AppleCare for support. While I was on the phone with them, all of the playlists disappeared from my Music app on my Mac. That's nearly two decades of curated music that went missing an all of my devices.

The senior Apple advisor I was talking to was extremely sympathetic to my issue. Over the course of a couple hours, we tried a number of different things, including recovering my music library from my Time Machine backups. But, to no avail. It seems iTunes music libraries used to get backed up via Time Machine, but the new macOS Music app, released in October 2019, doesn't backup the library.

Over the following few weeks, things were a mess as I was transferred around amongst different senior advisors throughout AppleCare. There was a lot of confusion over the proper description of the issue in my trouble ticket. Many were describing it as "missing music" instead of "missing playlists."

Throughout these steps, there were times when I could restore an iTunes music library playlist into the macOS music app. But, while the playlists remained, all of the music in the playlist would quickly disappear (within in a minute or two) as iTunes Match thought the playlists were stale, and deleted them.

Playlist Solution

I finally figured out a somewhat tedious workaround to restoring my playlists that AppleCare confirmed with me as my best option on our next, and final call.

1. Uncheck Sync Library in macOS Music General preferences.

2. Close the Music app. 

3. Restore my last iTunes music library backup, from September 2019. 

4. While holding down the Option key, open the Music app and choose the old iTunes music library. My playlists appear, although, without any songs.

5. Choose each playlist, individually, and choose File –> Library –> Export Playlist. (I had to do this 85 times.)

6. Once complete, I went back to my Music General preferences in step one and checked Sync Library (and then my playlists disappeared). 

7. I then imported all 85 playlists, one at a time, by clicking File –> Library –> Import Playlist. Here's what that looked like.

One gotcha was that, when I double clicked on most songs in my playlist, a modal window popped up saying that Music couldn't locate that song. Once I clicked cancel, to dismiss this modal, all was fine.

The other gotcha was that I lost any playlist updates between September 2019 and the beginning of January. Luckily, that was a small amount of edit, especially compared to the last 19 years.

On 3 Jan 2020, I lost all of my macOS Music playlists. That's 19 years of curated music that was wiped out on all of my devices since iTune Match syncs my music.

Sunday, January 26, 2020

Celebrity Server Overload: Kobe Bryant

Kobe Bryant died in the crash of a helicopter he owned, this morning. broke the news and the load brought down the TMZ servers... they couldn't respond to the traffic. And now, hours after his death, his Wikipedia page is highly unresponsive as people visit and edit it.

I got my first taste of managing extreme server load when I worked at Apple, after a Steve Jobs Keynote speech. But we always anticipated that load. When Michael Jackson died, in 2009, I was working with my Adjix startup and even simple URL redirects overloaded my servers.

When a celebrity unexpectedly dies, server load goes through the roof. I call it Celebrity Server Overload. You can plan for it to happen, you just don't know when it will happen. But you can scale up as the traffic grows.

The other end of the spectrum is when a business is brand new – they have no experience on scaling up. Facebook could manage their growth, in the early days, because they brought on new users one college campus at a time. But even smart developers can't handle a high load, off the bat, without any past data points. We saw this with Twitter's fail whale and the launch of Obamacare. Semper paratus, or as we used to say in the Boy Scouts, Be Prepared. 

Kobe Bryant: August 23, 1978 – January 26, 2020.

Saturday, January 4, 2020

Interchangeable Words? (Part 2: Honesty vs. Integrity)

This is an extract from an article I wrote for the Marine Corps Gazette about when it's okay to lie. Part 1 of this post addresses data vs. information.

Honesty and integrity are frequently used interchangeably – but these two words have a nuanced, yet important difference.

Honesty deals with the past.
Integrity deals with the future.


Honesty means making your words fit reality. More specifically, it's speaking the objective truth about the past without any intention to deceive.

For example, George Washington's father asks him, "George, did you cut down that cherry tree?"

"Father, I cannot tell a lie. Yes, I cut that cherry tree," replies George Washington.

In this example, at least according to fable, George Washington's words fit reality; therefore, his response was an honest one.


Integrity means making reality fit your words. Simply put, it means that you do what you say you are going to do.

George Washington's father tells George, "George, as part of your chores, today, I want you to cut down that cherry tree."

George replies, "Yes, father, I shall cut down that cherry tree."

At the end of the day if George has cut down the tree then he had the integrity to make it happen. In other words, he got results. Integrity is the ability to do what you say you're going to do. It's about executing on your plan.

Interchangeable Words? (Part 1: Data vs. Information)

Part 2 of this post addresses data vs. information.

Some words are used interchangeably, such as prediction vs. forecast. I like to think of a prediction as when we take historical observations and apply it to the future (winters are cold, summers are hot). But that doesn't tell us the weather for tomorrow. For that, we need a forecast where we apply a system of equations to process data for trend analysis.

Data vs Information

Information is processed data. Recording the average temperature, every day, gives us data. Examining that data (processing it) yields the information that summers are hot and winters are cold. In turn, that information can become data in yet another system. 

Wednesday, January 1, 2020

Happy 2020! It's Good to be Alive!

Sometimes it's good to be "unremarkable."
As I labored through my sunset run, today, I recalled the military axiom, "Pain's a good thing, it means you're not dead.” Which reminded me that 20 years ago I had just finished my final round of chemotherapy for late-stage, widespread cancer (stage 4 Hodgkin’s lymphoma).

My last chemo treatment was in December 1999 and, after five years of checkups, my prognosis was cured --- not remission, but fully cured --- to the point that I went back on active duty in the Marines in 2003 and deployed with them to East Africa in 2005. Today, it’s literally like I was never sick. I am lucky.

Human Being, Not Human Doing

Cancer, and my father's unexpected death in 2007, gave me a deeper insight and perspective on life. At that point, I realized I could take two or three years off from corporate America. But I didn't expect a few years to turn into more than a decade of retirement.

People ask me, "What did you do during all that time off?"

My answer's simple, "Nothing," followed up with, "What do you do on weekends? That's what I did most everyday."

Looking back, from one mile high. 
Looking back on all that time off, I see that I learned how to be a human being instead of a human doing. While I did focus on my own personal projects like learning to fly, creative writing, and volunteering, it was my ability to be fulfilled while not accomplishing a single task, in a day. Some might call that lazy; I call it the simple life. La dolce vita.

While the pursuit of happiness is our unalienable right, it does require more than that to be fulfilled. It requires meaning and here's how to make meaning.

Carpe diem and live the dash.

Update: Something I completely failed to mention was I always knew my retirement wouldn't be permanent. Sooner or later, I'd have to return to full time work which I just did in August, and I'm loving it. 

Sunday, December 29, 2019

Copy & Paste Screen Shot Info

I recently received a screenshot of a USPS tracking number. It was well over 20 digits and I found it extremely burdensome, on my phone, to go back-and-forth to copy the numbers from the screenshot to the website. So, I tried something different and it worked...

I said to my HomePod, "Hey, Siri, remind me to 638373947374..." and then a reminder appeared on my To Do list of only the digits which I could easily copy and paste into the post office tracking website.

VoilĂ !

I'm sure this will work equally well with other smart speakers.    

Friday, December 13, 2019


I tried cryotherapy for the first time, today. It's basically the opposite of a sauna. Instead of extreme heat, it's extreme cold.

How cold? About -225°F. Yup, two hundred twenty-five degrees below zero for three minutes.

If pain's a good thing because it means you're not dead then I felt very alive at the end of my three minutes. The hairs on my legs were frosty brittle. I don't know if it had any health benefits – but what are the health benefits of a sauna or steam room? If heat is relaxing, then cold is invigorating.

Three minutes cost $25 and, without an appointment, I was in and out in less than 15 minutes. I only wore my underwear, gloves, and flip flops with socks (not exactly a fashion statement).

The woman administering my treatment, who coincidentally had the same last name as me, chatted with me throughout my session. Probably to make sure I didn't pass out. It was chilly.

Wednesday, December 11, 2019

Investment Litmus Test

I had a discussion about timeshare vacations properties, today. Timeshare sales seminars are notoriously high pressure. They're pitched as an investment... but, even though they can be real property, they're a liability.

The litmus test for an investment is simple. If you buy something, today then you can sell it tomorrow for the same price, less a small amount of fees or commission then it's an investment. Real estate (fee simple) and stocks can be bought today and sold tomorrow for virtually the same price. Gold also falls into this category as an investment. However, cars, jewelry (i.e. diamonds, rubies), and timeshares most certainly do not.

Thursday, November 7, 2019

USPS Informed Delivery

I just signed up for the US Post Office's Informed Delivery which e-mails you a scan of that day's inbound mail. It's very handy and works as advertised.

The USPS started this service as a pilot in 2014 and a few years later they rolled it out to most of the country with more than 15 million. Give it a try – it's free, a bargain at twice the price.

Tuesday, October 15, 2019

Can't Send E-mail More Than 500 Miles

I do love great storytelling...


From: Trey Harris

Here's a problem that sounded impossible... I almost regret posting the story to a wide audience, because it makes a great tale over drinks at a conference. :-) The story is slightly altered in order to protect the guilty, elide over irrelevant and boring details, and generally make the whole thing more entertaining.

I was working in a job running the campus email system some years ago when I got a call from the chairman of the statistics department.

"We're having a problem sending email out of the department."

"What's the problem?" I asked.

"We can't send mail more than 500 miles," the chairman explained.

I choked on my latte. "Come again?"

"We can't send mail farther than 500 miles from here," he repeated. "A little bit more, actually. Call it 520 miles. But no farther."

"Um... Email really doesn't work that way, generally," I said, trying to keep panic out of my voice. One doesn't display panic when speaking to a department chairman, even of a relatively impoverished department like statistics. "What makes you think you can't send mail more than 500 miles?"

"It's not what I think," the chairman replied testily. "You see, when we first noticed this happening, a few days ago--"

"You waited a few DAYS?" I interrupted, a tremor tinging my voice. "And you couldn't send email this whole time?"

"We could send email. Just not more than--"

"--500 miles, yes," I finished for him, "I got that. But why didn't
you call earlier?"

"Well, we hadn't collected enough data to be sure of what was going on until just now." Right. This is the chairman of statistics. "Anyway, I asked one of the geostatisticians to look into it--"


"--yes, and she's produced a map showing the radius within which we can send email to be slightly more than 500 miles. There are a number of destinations within that radius that we can't reach, either, or reach sporadically, but we can never email farther than this radius."

"I see," I said, and put my head in my hands. "When did this start A few days ago, you said, but did anything change in your systems at that time?"

"Well, the consultant came in and patched our server and rebooted it. But I called him, and he said he didn't touch the mail system."

"Okay, let me take a look, and I'll call you back," I said, scarcely believing that I was playing along. It wasn't April Fool's Day. I
tried to remember if someone owed me a practical joke.

I logged into their department's server, and sent a few test mails. This was in the Research Triangle of North Carolina, and a test mail to my own account was delivered without a hitch. Ditto for one sent to Richmond, and Atlanta, and Washington. Another to Princeton (400 miles) worked.

But then I tried to send an email to Memphis (600 miles). It failed. Boston, failed. Detroit, failed. I got out my address book and started trying to narrow this down. New York (420 miles) worked, but Providence (580 miles) failed.

I was beginning to wonder if I had lost my sanity. I tried emailing a friend who lived in North Carolina, but whose ISP was in Seattle. Thankfully, it failed. If the problem had had to do with the geography of the human recipient and not his mail server, I think I would have broken down in tears.

Having established that -- unbelievably -- the problem as reported was true, and repeatable, I took a look at the file. It looked fairly normal. In fact, it looked familiar.

I diffed it against the in my home directory. It hadn't been altered -- it was a I had written. And I was fairly certain I hadn't enabled the "FAIL_MAIL_OVER_500_MILES" option. At a loss, I telnetted into the SMTP port. The server happily responded with a SunOS sendmail banner.

Wait a minute... a SunOS sendmail banner? At the time, Sun was still shipping Sendmail 5 with its operating system, even though Sendmail 8 was fairly mature. Being a good system administrator, I had standardized on Sendmail 8. And also being a good system administrator, I had written a that used the nice long self-documenting option and variable names available in Sendmail 8 rather than the cryptic punctuation-mark codes that had been used in Sendmail 5.

The pieces fell into place, all at once, and I again choked on the dregs of my now-cold latte. When the consultant had "patched the server," he had apparently upgraded the version of SunOS, and in so doing downgraded Sendmail. The upgrade helpfully left the alone, even though it was now the wrong version.

It so happens that Sendmail 5 -- at least, the version that Sun shipped, which had some tweaks -- could deal with the Sendmail 8, as most of the rules had at that point remained unaltered. But the new long configuration options -- those it saw as junk, and skipped. And the sendmail binary had no defaults compiled in for most of these, so, finding no suitable settings in the file, they were set to zero.

One of the settings that was set to zero was the timeout to connect to the remote SMTP server. Some experimentation established that on this particular machine with its typical load, a zero timeout would abort a connect call in slightly over three milliseconds.

An odd feature of our campus network at the time was that it was 100% switched. An outgoing packet wouldn't incur a router delay until hitting the POP and reaching a router on the far side. So time to connect to a lightly-loaded remote host on a nearby network would actually largely be governed by the speed of light distance to the destination rather than by incidental router delays.

Feeling slightly giddy, I typed into my shell:

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
    * 558.84719
    / 0.0017893979

"500 miles, or a little bit more."