What's it all about, Alfie?

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 decided to give HBO's Titans a watch, and I have to say it's not bad for a live-action from comics show. I mean it's all the same things that I enjoyed as a kid... yelling at the screen Don't go in there! and then, of course, they do. 🙂 It's just as predictable as you'd expect, and just as silly, and at the same time, the sense of family is nice.

It's just entertainment... it's not Oscar material - just good, silly, escapist TV for having on while you're working or to fritter away an hour.

I was reading IRC this morning, and saw that someone was asking about pattern matching in Clojure, and there were two suggestions: core.match and fnl-match. The first seems to do a pretty nice job, and it's got a lot of examples of the different kind of sources, and patterns. In all, it's an excellent example of a really super-charged case statement.

The second is written by technomancy - the author of Leiningen, a really good build, version, project tool for Clojure, so I was very interested in that as well. It looks like there is a lot of overlap in the design and capabilities, and that's nice - and it also means that there are options if I ever really need to use this.

The examples for core.match really make it clear how useful this is, and how much effort went into making the code efficient. That's where I'll likely start, as soon as I need something.

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.

This morning I was thinking about the move to the upcoming M1/M2 MacBook Pros that are supposed to be coming out later this year, and I decided it was time to move off my old screen capture and annotation tool, Annotate, and move to something that's: 1) Supported... 2) Going to be built for Apple Silicon. And when I read a review about CleanShot and SnagIt, I decided to look into both - SnagIt first.

The reviewer had it right - SnagIt has way more than what I need, and the increased feature set means complexity that I just don't need. Annotate was great... simple, easy, it did all I needed. SnagIt is just too much. But CleanShot is right what I was looking for!

I needed something to make nice screen shots - both area and window-based. I also wanted to be able to draw arrows from the head to the tail, as several of the screen annotations I've used had used that, and my arrows are so much more precise because of it. Also, I wanted to have the white-outlined text so that it was easy to read - regardless of the image below.

CleanShot does all of those. It's just exactly what I was looking for. So I got the basic app, with the 1GB of storage, and we'll see how it goes. If I want to get more updates in a year, then I'll renew then. But I didn't need the "Pro" features like unlimited storage, and I really don't want to pay a monthly fee for software like this - it's not critical to what I do.

So here we go... and we'll see how this works out. I have high hopes. 🙂

This morning I saw a tweet that a new version of Sublime Text 4 is out - and given the few little issues I've seen, I was quick to upgrade and see what the release notes said. What I read was that there were significant speed improvements, along with improvements in the OpenGL rendering, and several fixes in the specifics of the UI rendering. There was only one Mac-specific issue, and that was related to the Dark/Light scheme, which is fine, but doesn't worry me.

When I started using it, I was pleased to see that I didn't see any of the problems I'd seen before, and the editor seemed zippy - so what's not to like? 🙂 I have a new TypeScript project I'm about to start, so we'll see how it handles that load as well.

When last I looked at GitHub Codespaces, it had a few issues that meant I couldn't really do all the development I needed because it couldn't yet forward ports on the web-based UI. I found a way to run Postgres on a Codespace, so I'd have a built-in database, and it was persistent across restarts - which was marvelous. And I could customize the UI to be pretty much exactly what I needed to get work done.

But it was that nagging port forwarding that really meant I couldn't get real work done - not like I could on my laptop. And then I decided to give it another look... and they have not been sitting idly by. 🙂

The latest update to Codespaces has a much improved UI in the browser. It seems nearly native on my iPad Pro, and handles both the touch and trackpad gestures. Very nicely done. It also has a slight difference on the mounting of the work, so I had to update the cleanup() script in my .bashrc file:

  #
  # This is a simple function to cleanup the GitHub Codespace once it's been
  # created. Basically, I need to remove the left-overs of the dotfiles setup
  # and clean up the permissions on all the files.
  #
  function cleanup () {
    pushd $HOME
    echo "cleaning up the dotfiles..."
    rm -rf dotfiles install README.md
    echo "resetting the ownership of the /workspaces..."
    sudo chown -R drbob:drbob /workspaces
    echo "cleaning up the permissions on the /workspaces..."
    sudo chmod -R g-w /workspaces
    sudo chmod -R o-w /workspaces
    sudo setfacl -R -bn /workspaces
    echo "done"
    popd
  }

and with this, all my new Codespaces will have the right permissions, and the terminal will look and act like it should. Not too bad a change. But the real news is in the forwarded ports.

It appears that what GitHub has done is to open the port(s) on the running Docker image so that you can easily open a browser to the jetty port 8080 service that's running. It's really just as good as the port forwarding, and it completes the last needed capability to use Codespaces for real development.

If there was one more thing I'd wish for - it's that this would be included in the GitHub iPad app - so that the files are held locally, and edited locally, and the connection to the Docker instance is remote, but you can work locally.

Maybe soon. 🙂