And now it’s all this

I just said what I said and it was wrong
Or was taken wrong

Eero and Orbi

March 19, 2019 at 9:33 PM by Dr. Drang

Earlier this month, I installed an Orbi mesh wifi system in my company’s office/lab. This is after over two years of experience with an Eero system in my home. I thought it would be useful to compare the two.

Let’s start with the two reasons I chose to go with Orbi for work after two years of using Eero at home.

1. The Amazon thing. Amazon bought Eero in February, and although it has said it won’t be peeking at Eero’s data, it’s hard to imagine that being a longterm policy.
2. Intranet connectivity. A few months after installing the Eero in my home, our Comcast/Xfinity connection went down for an hour or so, and I was shocked to learn that the Eero’s internal routing functions went down with it. Which meant I couldn’t print or move files around until Comcast came back up. This hasn’t proved to be a significant burden at home, where the internet connectivity has been quite reliable and printing file transfer are relatively rare, but it would be a concern at work, where our internet goes out more often and internal networking is more important. Eddie Smith, my go-to for real world Orbi experience, tells me the Orbi works more like a regular router and doesn’t need an external connection to route internally.

Both systems have a base unit, the one connected to the modem, and two satellites. At home, which is about 30′×40′ in plan, there’s a unit roughly centered in each of the basement, first floor, and second floor. At work, which is a single floor about 60′×100′, there are units near the two long ends and the center. The coverage is good everywhere at both places. Speed tests show just about the maximum speed no matter where I go within the buildings. I don’t see any reason to favor one mesh system over the other on the basis of network performance.

The router software is another story. The Eero was distinctly easier to set up, requiring fewer reboots and retries. What sticks in my mind from the Orbi installation procedure was continually being told by the Orbi app that I wasn’t connected, please go to Settings and choose Orbi from the list of wifi networks. And then finding that Settings said I was connected to the Orbi—getting both devices on the same page meant turning wifi off and back on again on the iPhone. This sort of software clumsiness was de rigueur in the olden days of network configuration (actually, things used to be much worse), but I expected even old-line networking companies like Netgear to have upped their game by now.

More annoying is that Orbi’s iPhone app is simply incapable of doing certain router configuration tasks like port forwarding.¹ You have to log in to the router via a web browser and hunt through the poorly named feature sets to get to the configuration page you’re looking for. This is great for people into early-2000s nostalgia, but nowhere near as smooth an experience as Eero provides.

Installation and configuration make up a small part of one’s interaction with a router, so Orbi’s software isn’t a fatal flaw, just an annoyance. If you’ve been setting up networks for years and have never used an Eero or an AirPort, you might not even notice that Orbi is behind the times in user friendliness.

Overall, I’m happy with both systems. Despite its inability to route when the external connection is down, Eero was definitely the better choice for my home two years ago. When you’re doing something like setting up a mesh network for the first time, the extra attention Eero puts into its software is a big help. And if the acquisition by Amazon doesn’t bother you, it’s probably still the better choice unless your ISP has a lot of downtime and you’re a heavy user of internal networking. Software holds the Orbi back, but if you’re willing to put in some extra work, and if you’re uncomfortable with the possibility of Amazon owning your traffic data, the Orbi is a fine choice.

If you find the names Orbi and Eero hard to remember, this may help:

---

Regex groups and numerals

February 23, 2019 at 1:12 PM by Dr. Drang

A week or so ago, I was editing a program and decided I should change some variable names. I thought it would be a simple regex find/replace, and it was. Just not as simple as I thought.

The variables were named a10, v10, and x10, and I wanted to change them to a30, v30, and x30, respectively. I brought up BBEdit’s Find window and entered this:

I couldn’t just replace 10 with 30 because there were instances of 10 in the code that weren’t related to the variables. And because I think I’m clever, I didn’t want to do three non-regex replacements, one each for a10, v10, and x10. But I wasn’t clever enough to notice the blue coloring in the replacement pattern. Had I done so, I would have seen that BBEdit was interpreting my replacement pattern as “Captured group 13, followed by 0” instead of “Captured group 1, followed by 30,” which was what I intended. Since captured group 13 was blank, all my variable names were replaced with 0.

You see, BBEdit can capture up to 99 groups in the search pattern and, strictly speaking, we should use two-digit numbers when referring to them in the replacement pattern. But in most cases, we can use \1 through \9 instead of \01 through \09 because there’s no ambiguity. In other words, if I had been trying to change a10, v10, and x10 to az, vz, and xz, a replacement pattern of \1z would have been just fine, because the trailing z means there’s no way to misinterpret the intent of the \1 in that pattern.

So after undoing the replacement, I changed the pattern to this,

and all was right with the world.

There was another option: a named group. Here’s how that would have looked, using var as the pattern name:

I don’t think I’ve ever used a named group in any situation, whether the regex was in a text editor or a script. My general feeling is that if the pattern is so complicated I have to use variables to keep track of all the groups, I should stop and break the problem down into smaller parts.

By the way, you may have heard that BBEdit is celebrating its 25th anniversary of not sucking. When a well-documented app has such a long history, the manual starts to accumulate delightful callbacks to the olden days. As I was looking up the notation for named groups in the BBEdit manual, I ran across this note:

BBEdit is currently on Version 12.5; Version 6.5 came out in 2001. But the manual wants to make sure that long-time customers (I believe it was on Version 4 when I first bought it) don’t get confused by changes in behavior, even when those changes occurred nearly two decades ago.

---

Automation evolution

February 20, 2019 at 4:05 PM by Dr. Drang

In my experience, scripts and macros almost never end up the way they start. This shouldn’t be a surprise. Just as spending time performing a particular task makes you realize it should be automated, spending time working with the automation makes you realize how it can be improved. Contra XKCD, this doesn’t mean the decision to automate a task puts you on an endless treadmill of tweaking that’s never worth the time you invest. It means you’re continuing to think about how you do things and how your methods can be improved. I have an example that I’ve been working on for years.

Two of the essential but dull parts of my job involve sending out invoices to clients and following up when those invoices aren’t paid on time. I’ve gradually built up a system to handle both of these interrelated duties. I’ve written about certain details before, but here I want to talk about how and why the system has evolved.

It started with TextExpander snippets. One was for the text of the email that accompanied the invoice when it was first sent, and it looked like this (albeit less terse):

Attached is invoice A for $B on project C. Payment is due on D.

where the A, B, C, and D were fill-in fields. Similarly, there was a snippet for the followup emails.

The attached invoice, X for $Y on project Z, is still outstanding
and is now E days old. Pay up.

While these snippets was certainly better than typing this boilerplate out again and again, they weren’t using the computer for what it’s good at: looking things up and calculating. The invoices are PDFs that came out of my company’s accounting system and contain the information for X, Y, Z, and D. The age of the invoice, E, can be calculated from D and the current date.

So after a month or two of using the snippets, I wrote an invoicing script in Python that read the invoice PDF and created an email message with all of the parts filled in. It also added a subject line and used a project database to look up the client’s email address to put in the To field. A similar script created a dunning email message. Both of these scripts could be run from the Terminal and took the invoice PDF as their argument, e.g.,

invoice 12345.pdf

and

dun 12345.pdf

I should mention that these scripts created the email messages, but they didn’t send them. Sometimes I need to add an extra sentence or two to handle particular situations, and these scripts stopped short of sending so I could do that.

It didn’t take very long for me to realize that opening a Terminal window just to run a single command was itself a waste of time. I used Automator to add Quick Action workflows that run the invoice and dun scripts to the Services menu. That allowed me to run the scripts by right-clicking on an invoice PDF file in the Finder.

This system lasted quite a while. Eventually, though, I decided it was foolish to rely on my memory (or periodic checking of my outstanding invoices) to decide when to send out the followup emails on unpaid bills. I added a section to the invoice script that created a reminder along with the invoicing email. The reminder went in the Invoices list of the Reminders app and was given a due date of the first Tuesday at least 45 days after the invoice date. My invoices are net 30, so 45 days seemed like a good starting time for followups. And rather than having the reminder pop up on any day of the week, I set it to Tuesday—early in the week but unlikely to be on a holiday.¹

Changing the invoice script changed the behavior of the Services menu item that called it; I didn’t have to make any changes in Automator.

This system was the state of the art until it hit me that I could write a script that checked Reminders for every invoice that was past due and run the dun script on all of them, creating a series of followup emails in one fell swoop. I wrote this script as a combination of Python and AppleScript and embedded it in a Keyboard Maestro macro. With this macro in place, I no longer had to hunt for the invoices to right-click on.

A couple of weeks ago, after reading Federico Viticci’s article on using a Mac from iOS, I began thinking about the hole in my followup system: I have to be at my Mac to run Keyboard Maestro. What if I’m traveling on Tuesday and want to send out followup emails from my iPhone or iPad? OK, sure, I could use Screens to connect to the Mac and run the Keyboard Maestro macro that way, but that’s very slow and clumsy over a cellular network connection, especially when trying to manipulate windows on a 27″ iMac screen as viewed through an iPhone-sized keyhole.

The obvious solution, which wasn’t obvious to me until I’d thought of and rejected a few other ideas, was to change the dun script to create and save the followup email. Saving the email puts it in the Drafts folder, which I can get at from all of my devices. I also changed the Keyboard Maestro macro that executes the dun script on every overdue invoice to run every Tuesday morning at 5:00 am. When the reminders pop up later in the day, the emails are already written and waiting for me in the Drafts folder.

Yesterday was the first “live” test of the new system. I was in an airport restaurant—nothing but the best cuisine for me—when my watch buzzed with reminders for two overdue invoices. I pulled out my phone, opened Mail, and there were the emails, waiting to be sent. In this case, I didn’t have to edit the messages before sending, but it wouldn’t have been a big deal if I had—no more difficult than writing any other email from my phone.

Am I done with this? History suggests I’m not, and I’m OK with that. By getting rid of more scutwork, I’ve made myself better at following up on old invoices, and my average time-to-collection has improved. Even XKCD would think that’s worth the effort.

---

Transparency

February 11, 2019 at 8:27 PM by Dr. Drang

Today I upgraded the OS on my work iMac to Mojave. The upgrade took maybe an hour and had no hiccups, which I was glad of. I haven’t used it enough to know whether any of my software is broken¹, but I have used it enough to know that Apple is making visual changes to the user interface that certainly don’t enhance the user experience and probably detract from it.²

I’m not talking about Dark Mode. Personally, I think Dark Mode is a step back to the light-on-dark terminals I used back in the 70s and 80s, and I have no interest in working on a system that reminds me of those days. But that’s more a matter of taste than usability—done right, Dark Mode can be just as usable as the classic mode. I’m talking about Apple’s inexplicable embrace of transparency.

Here’s my Dock after the upgrade. My Desktop color for years has been Solid Aqua Dark Blue³, and now the Dock is just about the same color because of the transparency.

Why should the Dock appear as if it’s transparent? It’s not as if there’s anything interesting behind the Dock. That space can’t be used for icons, and I wouldn’t put any there even if it could be. So there’s no value is seeing through the Dock, but there is value in distinguishing the icons in the Dock from those that may be next to it on the Desktop. The distinction between the icons in the Dock and those on the Desktop is unnecessarily reduced by the excessive transparency of the Mojave Dock.

In case you’re wondering, I do have the “Reduce transparency” box checked in the Accessibility System Preference. That used to make the Dock more opaque than it does now.

Strangely, Apple keeps the Dock pretty distinct on the iPad.

It’s not as distinct on the iPhone. Maybe there’s some setting difference I don’t know about, or maybe it has something to do with the OLED screen.

In any event, what’s weird about this is that the Dock doesn’t need to be as distinct on iOS as it does on the Mac, because tapping any icon on iOS, Dock or not, launches the app. That’s not the case on the Mac, where icons on the Desktop are just files, and the distinction between Dock and not is more important.

What bothers me most, though, is that transparency has no real meaning on the Mac. It’s just decoration, not tied to any spatial sense that we expect from our experience with the physical world. For example, if you start typing in the URL field in Safari, the menu of suggestions that extends down from the URL field takes on a lighter version of the Desktop color, basically the same “semi-transparent” color in the background of the Dock.

This is ludicrous. This menu isn’t directly in front of the Desktop, it’s in front of the browser window (which is white because I was on Google’s home page when I took the screenshot). There is no reason for it to look like you’re seeing through it to the Desktop. That it looks that way screws up the sense of layering, especially since it still has that shadow around its border.

This absurd fake transparency isn’t confined to Safari. The little popup boxes that appear in Maps have the same muted Desktop coloring even though their conceptual position is floating on top of the map, not on top of the Desktop.

I can get rid of the ersatz transparency by checking the “Increase contrast” box in the Accessibility System Preference, but that also adds thicker border lines around windows and buttons, which I’d rather not have.

To summarize, there are three things wrong with transparency in Mojave:

1. It doesn’t help. Unlike other graphical flourishes in macOS, like the genie effect, it doesn’t do anything to help the understand the conceptual stacking of the UI elements.
2. It gets things wrong. It always “shows through” the Desktop, no matter what is directly behind the supposed transparent element.
3. It can’t be turned off without messing with other UI features. Unlike previous version of macOS, “Reduce transparency” doesn’t reduce all the transparence. As best I can tell, the only thing “Reduce transparency” still does is make the menu bar and its menus opaque.

It’s possible there are some settings I can change, through either System Preferences or defaults write, to get the user interface I want. I have, after all, been using Mojave for only a few hours. But it’s bothersome that Apple has chosen a default look that takes away from the experience of using a Mac.

---

Older posts

Site search

Meta

• drdrang at leancrew
• Blog archive
• RSS feed
• JSON feed
• Twitter stream
• GitHub repositories

Recent posts

Credits

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.