What's it all about, Alfie?

I have been using the iPad Pro for two generations now, and my current model is the M1 iPad Pro, and during the pandemic, it has really proven to be a great Zoom, Meet, etc. box. It has a nice camera, and with Front and Center in iPadOS, it really makes it easy to have a good presentation, or meeting. But it's really so much more.

With the GitHub app, I can get PR notifications, review them, and merge them. With the GitHub Workflow Actions, we have continuous deployment, and that is really quite amazing to me. Of course there are the shells to boxes, and that is great, but even offline, there is so much to like about this machine.

It's rugged - compared to my MacBook Pro, and the screen is a lot easier to clean. I'm not saying my MacBook Pro isn't nice... it's just that in some respects, the iPad Pro is nicer.

What a really amazing device. 🙂

With the update to macOS Monterey, the previous macOS command-line program for generating UUIDs, uuid, has been replaced with uuidgen. I'm not at all sure why the change, but I was glad that a little investigation with ls /usr/bin revealed something that turned out to be the winner.

With this, one of my favorite aliases is now:

alias uupb="uuidgen | tr '[:upper:]' '[:lower:]' | tr -d '\n' | pbcopy"

which generates a new UUID, lower-cases all the characters, removes the trailing new-line, and then puts it into the paste buffer for pasting in an editor, or on a form... as many times as you need.

I don't know if there are even release notes about the changes at this level of macOS, but they usually get figured out - one way or another. 🙂

I knew it was coming... they warned me with macOS 11 Big Sur... but it was still a bit of a surprise this morning to reconfigure Apache 2 to use userdir, which macOS Monterey doesn't enable by default, and undoes if you have it already configured. That's OK, it's not a huge deal to turn it back on, but the big news was the complete loss of PHP.

I haven't used it in many years, but it was the one tool that shipped with macOS that I could talk to Postgres, and script, but hey... things change, and they did warn me. 🙂

I guess it would be nice to have something like Node automatically handled, but then that would likkely clash with the Node devs and the nodenv installs, etc. So I'll live with Apache 2, and the userdir, and then just serve up static content on port 80, and leave the other stuff for the development environments.

I did a little digging over the past few days to see what's new in the latest release of Blink (v14.0.2) - the terminal/shell for iOS and iPadOS. It's a nice tool - has even more features than I initially thought. It's really a nice subset of a Unix shell without needing to connect to any other hosts. But that's not really the point of this dig... I was hoping that they had implemented SSH Agent Forwarding in mosh connections so that I'd be able to use git on the remote machines. If you don't forward the SSH key, then you have to have them on the remote hosts, and ssh-add them there. That's not ideal for me, as it opens up the location of the key to a somewhat untrusted host.

I read the release notes and it seems they have re-written the SSH Agent component, and yet they didn't get very specific about the Mosh improvements, so I did a little more digging on the mosh-client code itself, and it seems that there's a bit of a disagreement about including Agent Forwarding in mosh due to security reasons. The conveneince of using git and SSH keys for git operations means that most folks want to have the key forwarding. And you can do it in simple ssh connections.

But for mosh, eventhough it's built on ssh, it seems they don't want to add it. Odd. But hey... it's their code, it's their choice, and that's why I have the workflow where I do the commits on my iPad, and use Blink with mosh just to run the code. It would be nice to have SSH Agent Forwarding, but the durability of mosh trumps the need for agent forwarding... so I'll just stick to what I have now.

But it sure would be nice... maybe they'll figure it out.

This morning I was looking to visualize some time-series data from a Plaid Asset Report, in preparation for some work at The Shop, and I thought that it would be a perfect opportunity to use the xkcd Chart package. I like the way it's clearly trying to be a little less serious, and it seems like just the thing to try out for this visualization.

The data from the endpoint I created is returned as a sequence of tuples:

{
  accounts: {
    'Checking': [
      [ '2021-09-05', 115.4 ],
      [ '2021-09-06', 115.4 ],
      [ '2021-09-07', 110 ],
      [ '2021-09-08', 110 ],
      [ '2021-09-09', 110 ],
      [ '2021-09-10', 110 ],
      [ '2021-09-11', 110 ],
      [ '2021-09-12', 110 ],
    ],
    ...
  }
}

these are really the closing balances for each date for the account, and I just wanted to be able to visualize them so that any calculations can be validated by looking at the data.

The graph turned out pretty well:

This is just exactly what I'd hoped for. 🙂

This morning, play.js had an update the allows for real-time collaboration through Code Sandbox, and I have to say, it's a very interesting development, for the development I'd like to be doing on the iPad. I have really been hoping to move more development to the iPad, and play.js is an amazing tool that I've just started to experiment with, and the idea of the collaborative sessions would be very nice to have as a teaching and support tool.

While I'd love it if there were similar iPad tools for ObjC, and Clojure, I can't complain because it's really a nice set of tools for the majority of the Node/JS and Typescript work that I do. Sure... there are npx commands that don't work because they are compiled, and so not everything is going to work today on the iPad, but quite a lot will, and the collaboration features are a nice move in that direction as well.

I was chatting with a friend this morning, and he has a new job at a blockchain company, and reached out to me on GTalk - which can be accessed from his messaging client: Telegram. Now I'd never heard of Telegram, even though it's been around for ages, and my friend says that it's pretty much the defecto standard for the crypto space. It makes sense, the feature list is something you'd expect from the crypto space: Simple, Private, Fast, Open... it makes sense.

Also, they have clients for all platforms, and the clients all stay secure and in sync. It's a nice idea, and while I think the clients aren't minimal enough, maybe that's something that you can change - after all, the code is all open source, and stripping out is usually simpler than adding in. 🙂

It's something to keep in mind... Interesting space, and challenges...

This morning, I was wondering if iTerm2 had yet added the feature to restore all the window positions on restart. In the past, I used the Open Default Window Arrangement - making sure to save any changes before a restart. But there were issues with that - one, I'd forget... two, on restart, all the windows would be on the first screen, and I'd have to move them to the six (or so) screens they needed to be, and while it's not horrible, it's time-consuming.

This morning, I did a quick search to see if there was any status update on that... and I was very happy to see that when I wasn't looking, they seemed to have added that option in the Settings of iTerm2.

Go to the General -> Startup settings in iTerm2, and then select Use System Window Restoration Setting, and I should be good to go. I haven't had the chance to test it, but I'm hoping that it's going to be exactly what I want. Right down to putting the windows on the correct screens.

UPDATE: when updating the macOS 11.5.2 this morning, this worked perfectly. The windows are all in the right places, the contents of each tab (session) is still there to reivew. It's just exactly what I'd hoped for. 🙂

On the heels of the Notarize Node Client, we took the time to create a Node Client for the PostGrid service - where they will use regular Postal Delivery for PDFs, and HTML pages, and we needed that at The Shop. It was easy enough to build on the previous client, and just update the different domain elements, and handle the data interfaces. Not bad at all.

One thing I did have a few issues with was the handling of the Form Data for the posts to the service. There were endpoints that could accept application/json data, and some that required multipart MIME data from a FormData element. Thankfully, I'd had to work with this for some additions we made to the HelloSign Node Client, but that was a lot easier because the basic client was written by the HelloSign engineers, and we just had to add the ability to post PDF documents provided as Buffer objects.

In all, it wasn't all that bad, and now I have a core TypeScript library for building almost any client for a restful service with either JSON or Form Data. That's a nice place to be. 🙂

Back in June, I wrote to the folks at Smile, about an issue I was having with PDFpenPro 13.0.1 on my laptop. It was annoying because I could copy and paste some Form Fields to a document, but then when I tried to save it, it'd lock-up, and go non-responsive to Finder as well as the "spinning beachball". It was very repeatable, but depended on the file. Some had this issue - some didn't.

They were able to reproduce this issue, and said they'd get on it. I was thrilled that it would soon be resolved, as it was a great PDF authoring tool for Forms and Text Tags - which I've been doing a lot for a project at The Shop.

Then I read that Smile was selling PDFpenPro and PDFpen for iOS/iPadOS to Nitro, and I got a little concerned that the bug report, and corresponding fix, might be falling through the cracks. So today I sent an email asking for a status on the issue, and we'll see what they happen to say. I really do hope they fix this crashing bug because other than that, PDFpenPro is an excellent tool.

UPDATE: they wrote back, and for the time being, support for PDFpen(Pro) is being handled by the Smile folks, and Jeff at Smile mentioned that it was still an open issue, and that he'd pass along my question about a status. We will see.