What's it all about, Alfie?

I was doing a little Node/JS coding on play.js on my iPad Pro this week, and ran into a few issues that I wrote to the developers about. They weren't all that big a deal, save one:

• Logging is iffy - using Node/Express, their default is the debug logging package, and yet you can't see any of the log messages in the console in the app.
• Running nodemon doesn't reload on changes - it would be nice to have a way to auto-reload changes in the files - specifically because the editor is saving them.
• Exceptions aren't logged - if there's an uncaught exception, it's not logged/printed in the console at all. Just silence.

And it's really the last one that's the kicker... no way to see if there has been any exceptions... that's something that would make it very hard to find errors in the code.

They wrote back that there would be updates that were coming soon that would fix most of these, and that I should sign up for the CodeSandbox Beta program and look for the updates. Well... this morning, I saw that they had an update, and changed the name of the app on iPadOS to CodeSandbox. So I fired it up to see how things had changed.

There were lots of changes, but the key problems I was having haven't changed, and they have really moved it away from what I liked about it, and towards another style, with different goals. It's OK... it's their app, but it's not the direction I was hoping they were going.

So... it looks like I'll have to wait a little longer to see what comes up as a development platform for the iPad...

This morning I did a little searching about how to disable any Auto-Complete in Sublime Text, as there are a lot of times that I really don't want to have any autocomplete happening, as it just gets in my way. So I was very happy to find that all I needed to do was to add:

  "auto_complete": false

to the Settings file, and that will turn it off.

Blissful silence. 🙂

Thankfully, Ctrl-Space will bring it back, and that's exactly the thing I was hoping to find. Then it's at my command, as opposed to simply appearing. Once again, less is more... coding is what I do, and I know what to type... so Sublime Text is again my favorite editor. Wonderful. 🙂

Over the weekend, I had a problem with a project at work that was using PostGraphile and I was having an issue with the Postgres URL that I was feeding to the configuration of PostGraphile:

    postgraphile(
      process.env.PLATTER_POSTGRES_URL,
      'public',
      {
        watchPg: false,
        graphiql: true,
        enhanceGraphiql: true,
        graphqlRoute: '/graphql/v2',
        graphiqlRoute: '/graphiql/v2',
        eventStreamRoute: '/graphql/v2/stream',
        appendPlugins: [
          require('@graphile-contrib/pg-simplify-inflector'),
          require('postgraphile/plugins').TagsFilePlugin,
        ]
      }
    )

The process.env.PLATTER_POSTGRES_URL was generated by a call to the Platter service, and it turned out to be cached, and stale, and as the source is Let's Encrypt, it needs to be updated monthly. The cache had been running for more than a month, and that left an old, expired, certificate for the site, in memory.

It was easy enough to have them restart the cache, getting to that point... well... 🙂 that was a little more involved. The first issue was that with PostGraphile, used as a Library, had the feature that if it could not generate the initial schema for the GraphQL engine, it would exit the process, and effectively crash the service.

I wanted to protect the service, so the first order of business was to update the way I was using PostGraphile to allow me to capture the failure, and just disable the GraphQL engine until we could get this problem figured out. Thankfully, that was as easy as adding a function to the retryOnInitFail option:

    postgraphile(
      process.env.PLATTER_POSTGRES_URL,
      'public',
      {
        watchPg: false,
        graphiql: true,
        enhanceGraphiql: true,
        graphqlRoute: '/graphql/v2',
        graphiqlRoute: '/graphiql/v2',
        eventStreamRoute: '/graphql/v2/stream',
        appendPlugins: [
          require('@graphile-contrib/pg-simplify-inflector'),
          require('postgraphile/plugins').TagsFilePlugin,
        ],
        retryOnInitFail: (err, att) => {
          log.error(`[PostGraphQL] Error on initialization: '${err}' with ${att}
                     attempts. Bailing out on PostGraphQL.`)
          return false
        }
      }
    )

At this point, we had time to figure out what the issue was. I was going to dig into the PostGraphile code, and Alex, at Platter, was going to look at it from his end. Which brings me to the point... the PostGraphile TypeScript code is very nice. Yes, there are a lot of packages/modules, and the organization is clean, but I'd have done it the same way - easy separation of responsibilities. The code is exceptionally clean... well considered and implemented. The more I dug into it, the more impressed I was with it as a project.

I thought it might be an issue with their code - an asset they are loading that has an expired certificate, so I filed that on GitHub, and had a wonderful exchange with the maintainer of the project. As I dug in more, and worked to repeat the issue on a much more limited basis, the back and forth with the maintainer was very helpful... just exactly what you'd hope to encounter - but often don't.

It was the most unexpected, wonderful, experience I'd had in months. It renewed my faith in Open Source again. 🙂

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. 🙂

A friend pointed out Cloudflare Workers to me as a near-Heroku style deployment and run-time platform for Node/JS projects. It's really more turn-key than Heroku - it's targeted at the folks that don't want to maintain servers, or worry about global data centers, or anything like that. Just make a Node/JS project, deploy it, and pay for what you use.

There are a lot of reasons to like something like this - it's what someone would need if they just wanted to write the code and leave all the other details to someone else. It's got a nice "Free Plan", for little hobby projects - much like Heroku, but it doesn't provide all the services that Heroku does in it's Store... but again, if this is a simple Node/JS app, you are probably set up with your own database and Cloud Services, so that's not necessarily a bad thing.

I haven't really used it on a project - yet, but I can imagine trying one - from my iPad and play.js... it might be interesting to see how it all might work in a non-laptop mode... 🙂

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.

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. 🙂

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.

Several weeks ago, The Shop made the decision to implement CI/CD on the code repositories at GitHub using GitHub Actions. And it has been an amazing success. The ability to set up individual responses to GitHub actions like push, and so on. It's also very nice that it's all done in parallel, which is very nice for speed.

One of the things I have really enjoyed about the Actions is that GitHub gives each project quite a lot of free compute minutes for the execution of the Actions. This means that if you have a relatively static project, this is likely something you will be able to use for free. And if it's a business, you could prove out that this will work for you before having to invest in more tooling.

When you do run up against the limits of the free plan, the only thing that will happen is that the Actions will all fail. This is completely understandable, and a very reasonable fall-back position for projects. Add a billing source, and you're back in business. Very nicely done.

This morning I pulled up play.js on my iPad Pro to run a simple project I built to hit a MLB stats site and extracts some data, and format it into a simple JSON output. It's nothing, really... a simple Express/NodeJS site that I used in learning Express... but it is just an amazing tool for writing Node services - with front-ends, or not.

It's really pretty nice - includes a full git client, and complete dependency searching and incorporation... it's all you'd really need if you had a Node service back-end, and a static assets front-end. I know it can do even more on the front-end, but I'm quite happy with the ability to use HTML/CSS/JavaScript to build the front-end - I typically don't build elaborate front-ends to validate the back-end service.

The one wrinkle I've seen with some Node dependencies that include non-JavaScript components - like downloaded commands. These are not going to run in play.js's environment. It has to be 100% Node and JavaScript. So... there are some limitations on the projects it can handle... but not many.