Security
April 24, 2019 at 9:01 PM by Dr. Drang
Today I spent some time with Keyboard Maestro, the Numbers app, a shell pipeline, and—you weren’t expecting this—the Social Security Administration. I managed to avoid some tedious data entry.
It started with my going to the My Social Security site to make sure my earnings records were correct. The SSA sends reminders to do this every once in a while, and like most people, I have usually ignored them. But last year I learned that my earnings and contributions for 2016 had not been recorded, and I had to jump through some hoops to get it corrected, so I’m now more diligent about checking.
After confirming that my earnings history was correct and complete through 2018, I started thinking about benefits. I’m 58, and retirement is not that far in the future. I wanted to check out a few retirement scenarios, varying my retirement age and projected earnings between now and then. There used to be an online benefits calculator that would incorporate your earnings history into its forecast, but I couldn’t find it today. Instead, I came across this page, which requires you to enter all your earnings history into a series of fields in a long HTML form.
If you have earnings going back to 1951, I salute you.
I have almost 40 years of earnings, and there was no way I was going to tab-type-tab-type my way through all of those numbers. So I wrote a short Keyboard Maestro macro to do it for me:
Ignore the definition of the earnings variable in the first step; we’ll get to that in a bit. The important thing is that earnings is a multiline string with each line representing a year’s earnings. For me, the list starts in 1980 and continues through 2018.
The macro loops through the lines in earnings. For each line, it
- puts the line into the variable
amt; - types a Tab;
- pauses for a quarter of a second; and
- types the
amtstring.
The pause is in there to make sure the focus has moved to the next field before typing the amount.
These are exactly the steps I would have gone through had I filled in the fields by hand. The key to running the macro successfully is to make sure the cursor is blinking in the 1979 earnings field before invoking the macro. Ten seconds later, all the necessary fields are filled with no typos.
Let’s go back now and see how I filled the earnings variable. The numbers came from the earnings history page that I started on, which looked like this (apart from the values, of course):
This is an HTML table with years. The values I wanted were in the second column, which I couldn’t select by itself. So I selected the whole table and copied it into a Numbers spreadsheet to do some editing.
You’ll note that we need to enter the numbers in the benefits calculator in chronological order, but the earnings table is in reverse chronological order. So the first order of business was to sort the spreadsheet by the first column. After that I was free to delete the first and third columns, leaving me with a single column of the numbers I needed. Except…
The values in the remaining column have dollar signs and commas, and I was afraid that Numbers had interpreted them as strings when I pasted them in. But, mirabile dictu, Numbers did the right thing and interpreted those values as numbers. So all I had to do was set the style for those cells as a generic number type, with no commas and no currency symbols. Then I copied the column and pasted it into the top step of the macro.
The earnings extraction part of today’s work will never have to be done again. In the future, I can just add lines for earnings in 2019 and beyond.
This is obviously not a macro I’m going to be using more than once a year, but now that I have it, I can fill in the benefits calculator fields easily and accurately. It’s not a great savings in time, but it is a great savings in frustration.
Century
April 23, 2019 at 8:00 PM by Dr. Drang
Once upon a time, this blog had posts that weren’t about Apple and automation. In those halcyon pre-Twitter days, I would actually write full blog posts about things I’d seen and done instead of tossing out a tweet or two and calling it a day.
This past Saturday, my wife and I visited the Garfield Park Conservatory on the West Side of Chicago. We’ve gone there many times before, but always in the winter as a way of seeing some greenery and color during the gray months. This time, in addition to the usual wandering through the various houses, we had a particular plant we wanted to see.
The conservatory’s Century Plant, which has been on display for over 50 years, started to shoot up a stalk in January, not too long after our last visit. This is the beginning of the end for the Century; when its stalk stops growing, it will flower for a few months and then die.
The bottom of the plant looks pretty much like it did last year.
The difference is the 6″ to 8″ thick stalk growing up out of the center of the plant. If you zoom in on the photo, you can see the rope that the conservatory staff has hung from the roof of the greenhouse to track the growth of the stalk. They couldn’t ask the plant to stand up against a door jamb.
The red JAN 1 and JAN 15 labels show about a foot of growth over those two weeks. How tall is it now? This was my best attempt to show the whole stalk with the labels turned toward me.
Unfortunately, this missed the tip, which I had to get from a different angle.
When the stalk got over 25′ high, the conservatory staff had to remove one of the glass panels in the roof to let it out. You can see also that it’s outgrown the rope they were using to track its growth. The conservatory posted a funnier photo of the tip on its Instagram feed.
It looks like it’s poking its head out to take a look at the fieldhouse dome.
What’s next?
April 21, 2019 at 12:20 PM by Dr. Drang
Last week, Guilherme Rambo was the the unofficial guest on every Apple-centric podcast. His inside information on what’s coming in macOS 10.15 and iOS 13 gave everyone something to anticipate, dread, or argue about. I want to talk about his last revelation of the week, that Shortcuts is coming to the Mac and what I hope that means.
Let’s start by noting, as Jason Snell did, that Rambo doesn’t use the most definitive language on this topic. First, he says
According to people familiar with the development of macOS 10.15 – which has been in the works for at least two years – the new version will include support for Siri Shortcuts…
OK, “support for Siri Shortcuts” may simply mean that apps will be able to suggest voice activation of certain actions. To me, this is the least interesting part of Shortcuts, because it’s basically limited to the automation of single steps. To be sure, these single steps sometimes take several taps or swipes to get at, so their activation with one “Hey Siri” is a real benefit, but they’re nowhere near as useful as the more complex combinations you can achieve through the Shortcuts app.
But then there’s this:
It’s also likely that the Shortcuts app – a result from the acquisition of Workflow – will be available on macOS, the inclusion of system-wide support for Siri Shortcuts on macOS 10.15 strongly suggests it.
Here, the prediction is for the Shortcuts app itself, which would be much more useful, but it’s weakened by “likely” and “strongly suggests.” Rambo seems to be drawing an inference about the introduction of a Mac Shortcuts app rather than having a source saying it’s coming.
And then there’s this:
According to sources, only Marzipan apps will be able to take advantage of the Shortcuts support on macOS.
Here we have actual sources, but it’s not clear what aspect of Shortcuts is being discussed here. My guess is that it’s just Siri Shortcuts, not a Shortcuts app. And of course, there’s the disappointing—but not surprising—limitation to Marzipan apps only.
Regardless of what comes to the Mac in 10.15, it seems inevitable that Marzipanification will eventually lead to a Mac Shortcuts app. Which raises the question of how Shortcuts will fit within the Mac automation environment. I want to expand on what Jason said in his last paragraph:
In the long run, Shortcuts for macOS needs to be able to access all sorts of low-level Mac features that its iOS counterpart can’t do, via support for shell scripts and AppleScripts. (The ability to run scripts is really Automator’s killer feature.)
Here’s the current state of scripting on the Mac:
At the base of macOS is Darwin, a BSD-style Unix. This can be scripted by all the usual Unix tools: Bash, Zsh, Perl, Python, Ruby, and so on. Sitting on top of that is all the Mac-like stuff, which gets scripted by AppleScript (ported over from the classic Mac OS) and Automator.1 The ability to script at both levels is very nice, but what makes this system so flexible as an automation environment are the connections between the two environments.
AppleScript can pull up Darwin-level information by running shell scripts through the “do shell script” construct, and Automator can do the same through the Run Shell Script action (Jason’s killer feature.). Just as important, though, is the ability for scripts at the Darwin level to access Mac-level information by running AppleScripts via the osascript command and Automator workflows via the automator command.2 Users can create their automations at the level that seems the most appropriate, confident that they can reach up or down to get whatever they need.
When Marzipan gets layered on top of the Mac and Shortcuts comes along to automate it, we’ll have this situation.
The big question is how will Shortcuts connect to the layers underneath it. Jason’s concern about the upward-pointing arrows along the left side of the diagram—will Shortcuts be able to run scripts and access the resulting information from the Macintosh and Darwin levels?—worries me, too, but I’m just as concerned about the downward pointing arrows along the right side of the diagram. Will AppleScript and shell scripts be able to run Shortcuts and access information from Marzipan apps?
My concern stems partly from my overall belief that an automation environment that shares in both directions is the most flexible. More specifically and selfishly, though, I have current automations that run in both directions, and I’m worried that those will be killed off if the main Mac productivity apps go Marzipan. For example, my system for sending and following up on invoices at work, which I discussed in this post and this episode of the Automators podcast, uses Keyboard Maestro to call a Python script that runs a couple of AppleScripts—it runs up and down both sides of the current diagram. If the Contacts and Reminders apps on the Mac become Marzipan-only and don’t give me connections between the upper and lower layers on both sides of the diagram, that system will stop working, and I will be very angry.
The people who built Unix understood the value of passing information back and forth between processes, and they gave that ability not just to C programmers but also to regular users through pipes, redirection, and shell scripting. The NeXT developers who built the Mac’s current OS maintained that tradition and extended it from the command line to GUI apps by hooking into AppleScript and Apple Events with osascript and do shell script.
We all know, though, that latter-day Apple has blown hot and cold on user automation and on opening up interprocess communication to the rest of us. The introduction of Shortcuts at last year’s WWDC suggests we’re currently in a hot phase, and I hope the connections necessary to make Shortcuts on the Mac a truly valuable tool get made before interest cools again.
-
To this level, you could also add Keyboard Maestro, Hazel, and other third-party apps, but I’m listing only Apple-supplied features. ↩
-
You can also run AppleScripts in Automator via the Run AppleScript action, but because that’s working at essentially the same level, I’m not going to talk about it here. It would be like discussing Perl’s backticks or Python’s
subprocessmodule. ↩
Some PCalc stuff
April 20, 2019 at 10:19 AM by Dr. Drang
My PCalc setup tends to stay the same for long stretches of time—it’s a stable app, and I’ve settled into a comfortable way of using it. But I did make some small adjustments a couple of months ago and thought you might be interested.
First, I moved some of the function buttons in my customized “Drang” layout. It now looks like this with the standard and 2nd functions:
Apart from a little rearranging of the gray buttons, the main change is removing the gamma function (which I never use and had in there only because it fit as companion to the factorial) and replacing it with a combination function, yCx. It’s in the second row, third button from the left.
I say “a combination function” instead of “the combination function” because the built-in combination function, which is in the Special functions group, organizes its input and output in ways I don’t like.
Let’s say we wanted to find the number of combinations of 10 items taken 5 at a time. The input and output using the built-in combinations function look like this:
There are two things I don’t like about this:
- The inputs are in reverse order, at least according to the way I think. When I think of combinations, I always think of the total number of items first and the number chosen second. In my head are the phrases “10 items taken 5 at a time” or “10 choose 5.” So my history with the built-in combinations function has been to enter the arguments that way, get an error message, then swap the inputs and redo. I finally got fed up with this and decided that PCalc should bend to my will rather than the other way around.
- The output is just one number, but PCalc gives me two. I can understand why James Thomson, PCalc’s developer, did it this way, because built-in functions should accommodate both Algebraic and RPN modes and there’s a symmetry to having both the input and output with numbers in the x and y registers. But I don’t use Algebraic mode, and the extraneous zero in the y register gets in the way of other items I may have further up the stack. Again, PCalc isn’t the boss of me.
So I rewrote the combinations function to fit the way I think and work. Now if I want to get the number of combinations of 10 items taken 5 at a time, I enter the 10 and 5 in that order and tap the yCx button. The input and output look like this:
Here’s James’s code for the built-in combinations function on the left and my code on the right:
As you can see, I just stole James’s code and changed the beginning and ending bits to match my preferences.
(As a side note, you can also see that PicSew, which I used to make the extended screenshot on the right, uses a slightly darker iPhone frame image than Federico Viticci’s framing shortcut, which I used for the standard screenshot on the left.)
On my iPads, PCalc is usually my Slide Over app, ready to be pulled out from the right side of the screen whenever I need to do a quick calculation.
The layout is stretched vertically a bit more than I’d like—especially on the 12.9″ iPad, as shown above—but I haven’t felt the need to customize it for this use.
I may be unusual among PCalc users in that I use it as a calculator instead of an AR gaming platform. Despite the many other options I have for crunching numbers on iOS, it’s the app I turn to most often.
