A few days with the Luna Display

January 20, 2019 at 9:57 AM by Dr. Drang

A couple of weeks ago, I bought a Luna Display. It worked fine, but it didn’t feel comfortable doing what I’d bought it for, and I returned it after a few days. I learned in those few days that I don’t like running Mac software on an iPad, especially an iPad without a hardware keyboard.

If you know about Squarespace web hosting, Away luggage, and Casper mattresses, you’re familiar with the Luna Display. It’s been a ubiquitous sponsor of Apple-centric podcasts for months, so you know it’s a little plug that pops into the USB-C or Mini DisplayPort on your Mac and allows you to use your iPad as a sort of controllable monitor.

Luna Display dongles

If you want to supplement what you’ve heard on podcasts and what you can read on the Luna site, T.J. Luoma has an excellent writeup on his Luna Display configuration, including some practical tips he’s picked up as he’s gained more experience with it.

When I bought my Luna, I had a very particular use in mind, and it’s that use that informed my ultimate decision that the Luna wasn’t for me. I have an iMac in my office at work on which all my project-related files reside. Each project gets a folder (in Dropbox so I can also get them easily on my home iMac) and a bunch of subfolders for drawings, plans, specifications, and photographs of the machinery or building that the project is about. While I do most of my work in my office, inspections and testing of equipment are done in my company’s laboratory space, some 75–100 feet from my office. What I wanted from the Luna display was a quick and convenient way to refer to drawings and (especially) photographs from my iPad while I was looking at parts back in the lab.

With the photos on Dropbox, I could access them from the lab through either the Dropbox or Files apps, but latency was often a problem, as the iPad had to download each photo from the cloud before it could be displayed. I figured a local network solution, like the Luna Display, would solve the latency problem.

And it did. Photos viewed through the Luna software popped up on the iPad screen quickly because they were coming through a fast internal network instead of through a sometimes sluggish outside connection. Overall, I’d say the Luna Display worked exactly as advertised. But…

Because my iPad was acting as a Mac display, I was viewing the photos through Mac software, and none of the software I tried—while perfectly fine when run directly on the Mac itself—felt right when run indirectly on the iPad.

When I’m working on my Mac and I need to flip through a bunch of photos, I typically open up the folder in which the photos are stored and do one of two things:

This system doesn’t work well on the iPad because its efficiency depends on keyboard shortcuts—the space bar to go in and out of QuickLook and the arrow keys to flip from photo to photo—and I don’t want to bring a keyboard with me into the lab. The value of the iPad in this situation is its compactness, the ability to set it up in a small space that doesn’t intrude on the inspection or test. You might think a keyboard wouldn’t take up enough space to get in the way, but it does.

There are other software options for viewing photos. Xee was the photo viewer I used to use a lot in the pre-QuickLook days. It’s a nice piece of software, and using it again during my Luna Display tryout has made me think I should go back to it (its ability to quickly show EXIF data very useful). But like the Finder/QuickLook system described above, it isn’t efficient without a keyboard and wasn’t a good fit with the Luna.

I also tried out Phiewer, which can give you both an overview of the photos in a folder like Icon View and a detailed view of an individual image like QuickLook. It has onscreen buttons for navigation—which is a waste of screen space for a Mac app, but a godsend if you’re running that Mac app on a keyboardless iPad—but it doesn’t allow zooming via pinching, and that just seems wrong when working on an iPad.

In fact, everything felt wrong when I was running Mac apps through my iPad. Buttons were too small, even when I tried tapping on them with the Pencil. Resizing windows was a chore; dragging felt off. I confess I didn’t spend time examining why the behavior just didn’t feel right, but it didn’t.

I use both my Macs and my iPad a lot, and while I don’t have any trouble switching between the two, I found it very annoying to be forced into using Mac-like actions on an iPad. This was surprising to me, as I have nearly 35 years of Mac use under my belt and only 2½ years of iPad use.1 But my immediate sense—a sense that didn’t change over the 4–5 days I used the Luna—was one of unease.

Would I have felt this unease had I been using the Luna Display in a more keyboard-centric manner? Maybe not. And I can see where people who are iPad-first users would find the Luna very convenient if they only occasionally need to be hands-on with their Mac mini server. But for my use, the neither-fish-nor-fowl behavior that the Luna forced me into was very inconvenient. It made me have to think about what I was doing instead of just doing it, and that got in the way of my real work.

The good thing that came out of my Luna Display tryout was that it made me think harder about a software-only solution to my problem. I finally learned of a way to use FileBrowser on my local network that was pleasant instead of teeth-grittingly frustrating, which was my previous FileBrowser experience. I’ll describe that in a later post.

  1. The 11 years of iPhone are probably a confounding factor in this comparison. ↩

Don’t fear the regex

January 9, 2019 at 8:17 AM by Dr. Drang

If you saw Jason Snell’s recent article on reviving an old podcast feed and skimmed past it because you don’t expect to ever need to revive an old podcast feed, you missed some excellent generally applicable advice within the specifics.

The real purpose of Jason’s article is to show you how to use simple software tools we all know—a text editor and a spreadsheet—to accomplish what would normally thought of as a “programming” task. Listeners of The Talk Show may remember an episode in which Jason and John Gruber discussed how both of them have done this many many times over the years.12

Although I do often write short programs for text munging, I typically resort to that only if the problem requires more than just large-scale text editing or if I expect to be repeating the process several times. And even then, I usually start out by playing around in BBEdit3 to see what searches, replacements, and rearrangements need to be done. It’s a convenient environment for getting immediate feedback on each transformation step.

(And if you expect to do a series of text transformations often and really don’t want to get into writing scripts in Perl or Python or Ruby or whatever, BBEdit’s Text Factories allow you to string together any number of individual munging steps.)

I will say, though, that one bit of “programming” you’ll find really helpful—and which Jason uses in his podcast feed example—is the building of regular expressions for searching and replacing. Simply put, regular expressions allow you to find patterns of text instead of specific text. For example, if you need to find all the US zip codes in a long chunk of text, you can’t go searching for a specific zip code, like “60606.” You have to look for a pattern: five digits, optionally followed by a hyphen and four more digits.

Regular expressions allow you to build these patterns by using placeholders for generic character types (like digits), repetitions, and options. Unfortunately, for historical reasons, these placeholders consist of normal ASCII character strings like \d, *, and ?. This has the unfortunate effect of terrifying newcomers when they see something like

^\d{5}(-\d{4})?$

described as a simple regex, something I have probably done dozens of times.

Even worse, people who are thinking they should start using regular expressions often hear about this great book on the topic and have a natural reaction when they see it: A 500+ page book to learn how to search for text? No thanks.

This is too bad, because while Friedl’s book is great, it’s called Mastering Regular Expressions for a reason, and that reason is not because it’s a tutorial. My recommendation for a tutorial is the one I learned from over 20 years ago: the “Searching with Grep” chapter4 in the BBEdit User Manual. I believe it was largely written by a young guy named John Gruber.

The nice thing about regular expression syntax is that it can be learned a little bit at a time. You can be productive right away knowing only a few regex constructs. Even people who have been using regexes for ages tend to use just a dozen or so patterns, bringing out the more obscure ones only when they have a particularly tricky problem to solve. A good way to pick up new regex knowledge in small portions is to follow John D. Cook’s @RegexTip Twitter feed.

You may have heard that there are regular expression “flavors,” different regex syntaxes used by different programs, and been put off by the potential for confusion. Don’t be. There are different flavors, but that won’t have any practical effect on your learning until you’re an expert. Every program you run into nowadays uses the “Perl-Compatible Regular Expression,” or PCRE, syntax. Only very old programs use different flavors, and by the time you find yourself using them—if ever—you will be well-equipped to handle the variation.

And before anyone on Twitter can do it, I’ll bring out the obligatory Jamie Zawinski bon mot:

Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.

Don’t be led astray by this, either. Only a person who’s used regexes a lot, and successfully, would make this kind of joke.

  1. I would link you to that episode, but the episode descriptions in the TTS archives aren’t detailed enough for me to find it. I know it isn’t the most recent episode, even though they talk about BBEdit in it, because I haven’t listened to that one yet. ↩

  2. But in looking at the links for the most recent episode, I see that they do talk about the Studio Neat and Fintie carrying cases for the Magic Keyboard, so I need to move it up in my overflowing podcast queue. ↩

  3. Whatever text editor you’re comfortable with will do. Ten years ago, I would have been using TextMate. ↩

  4. “Grep” is the name of a Unix command that uses regular expressions for searching through files. I have always believed—but never confimed—that Rich Siegel used the term “grep” instead of “regular expression” because the shorter word fit better in BBEdit’s Find dialog box. ↩

Dates with Siri

January 7, 2019 at 11:25 PM by Dr. Drang

This morning, Casey Liss tweeted out a complaint about a typical Siri stupidity:

Silver lining of Apple’s focus on services: maybe Siri will actually… work? 🤨



  — Casey Liss (@caseyliss) Mon Jan 7 2019 6:38 AM CST

This was a bit of a shock to me, not because I thought Siri was smarter than this, but because I had been collecting similar Siri screenshots concerning dates and times for a few days and was planning to write a post about it. This post.

Before I get any further, let me tell you that some of what I’m going to say here was already covered by David Sparks in this post from almost six years ago. This was just a year and a half after the “beta” introduction of Siri with the iPhone 4S, and David was pleased with what Siri could do. I like a lot of what Siri can do with dates, too, but there are still some frustrating blind spots and inconsistencies. In fact, with one of David’s examples, Siri isn’t as convenient as it was six years ago.

Context has always been one of Siri’s weaknesses, and that’s where it failed Casey. Any normal human being would understand immediately that a question asked in January about days since a day in December is talking about the December of the previous year. But Siri ignores (or doesn’t understand) the word “since” and calculates the days until the next December 18.

If you take care to give Siri the full date, it gives the right answer:1

Siri days since full date

You might think—which is to say, I originally thought—that Siri defaults to the current year when the year isn’t given in the question. You would be wrong. Take a look at this, a question I asked today:

Siri days since partial date this year

Apple would argue that Siri is forward-looking technology.

One bit of date math on which Siri has never failed me is getting the day of the week for a given date. I use this quite often at work, especially when the date in question is years in the past and flipping backward through a calendar app would take too long.

Siri day of week

For dates well in the past, I would never think of not including the date, but for dates later in the current year, I would. Siri handles them well:

Siri day of week partial Mar 5

What about a day earlier this year?

Siri day of week partial Jan 1

That’s good. But it’ll screw up a date last year, right? Wrong.

Siri day of week partial Dec 17

And what if I change the tense of the question?

Siri day of week partial upcoming Dec 1

Suddenly, Siri is a master of context. I am at a loss to explain why.

In my experience, Siri is good at figuring out dates some interval away from a given date:

Siri days after given date

Siri days before given date

I can’t really blame Siri for thinking I mean this year when I ask about a date after December 17:

Siri days after Dec 17

Here’s the question for which Siri has lost some of its intelligence:

Siri days between two dates

Six years ago, Siri answered this kind of question correctly for David Sparks. Interestingly, it gave its answer in the form of a Wolfram Alpha page:

MacSparky date answer

Steve Moser suggested using the “Wolfram Alpha trick” to answer Casey’s question:

@drdrang @caseyliss That is why you use the Wolfram Alpha trick (you’ve probably seen it but just in case).



  — Steve Moser (@SteveMoser) Mon Jan 7 2019 9:12 AM CST

Personally, I think it’s easier to just include the year for that type of question, but the Wolfram Alpha trick is the only way I know of to get the number of days between two dates.

Siri and Alpha days between two given dates

Similarly, Siri can’t give you elapsed time within a day by itself,

Siri minutes between times

but it can through the Wolfram Alpha trick:

Siri and Alpha minutes between two given times

Take care how you phrase this question, or you’ll get the dreaded “here’s what I found on the web” answer:

Siri and Alpha time between two given times

The upshot is that Siri can be good at date and time math, but it needs the right syntax. Not surprising for a computer program, but not how Siri has been promoted by Apple.

  1. My examples are for December 17 instead of Casey’s December 18 because that was the date I had already been using in my exploration of Siri’s date capabilities. It was the date of a client’s email that I wanted to refer to in later message, and it was my asking Siri a question very much like Casey’s that got me started on this exploration. ↩

Z key followup

January 6, 2019 at 10:43 AM by Dr. Drang

As long as I’m following up on the condition of Apple hardware I’ve broken, I should mention the broken Z key on my Magic Keyboard. This is the keyboard I use with my 9.7″ iPad Pro, and it travels, unprotected, in a narrow compartment of my backpack next to the iPad itself.

Back in the summer, I returned from a business trip and found this damage when I pulled the keyboard out of the backpack:

Well, crap. Anyone know the best way to pop this back on? It’s a recent Magic Keyboard.



  — Dr. Drang (@drdrang) Wed Aug 1 2018 7:25 PM CDT

I don’t know whether it broke as I slid it into the compartment or as I slid it out, but it obviously caught on something and got pried off.

I ordered a replacement key from LaptopKey.com. It cost about $7.50 with shipping and arrived a few days later. I popped it in place and it worked.

Replazement key zeemz to be working well. Not az zpringy than the original, maybe, but zertainly workable.



  — Dr. Drang (@drdrang) Mon Aug 6 2018 6:01 PM CDT

(Why did I use the illiterate construction “Not az zpringy than…” instead of “Not az zpringy az…”? Probably because the sentence started life as “Less springy than…”, and I didn’t read it carefully after the rewrite. It’s a fine line between clever and stupid.)

If this weren’t the Z key, I’d be more careful about saying it works. It doesn’t have nearly the snap as the original key and feels distinctly different (worse) than all the other keys. If it were a key I used a lot, I’d be disappointed in its behavior and would have gone hunting for another replacement. But being one of the least-used keys, it’s fine.

I’ve been more careful with the keyboard since then. Eventually, I’l get a Studio Neat Canopy or this less expensive Fintie Carrying Case that Federico Viticci mentioned in his magnum opus on the new iPad Pros.

The springiness of the Magic Keyboard keys, by the way, comes from a rubber dome that holds the key up at rest and undergoes snap-through buckling when you press down on it. Snap-through buckling—with diagrams, equations, and charts—is discussed in my favorite blog post.

Older posts