What's it all about, Alfie?

I was surprised to read that at it's yearly conference, Amazon announced that you can now spin up EC2 instances based on their custom ARM CPU. This isn't a complete surprise - face it, Apple is close to launching ARM-based laptops and desktops. It's been batted about in the press for a while, and based on the old quad-fat binaries, the technology is there, and Apple certainly has all the experience to get macOS up and running on ARM.

This isn't necessarily the cheapest EC2 instances - for the a1.medium, a 1 CPU, 2 GiB RAM instance, is $0.0255/hr which rolls up to $233.38/yr for the instance. And the t3.nano starts at $0.0052/hr, but what's most interesting is that AWS did the math, and decided that building their own CPU - and then, of course, their own machines, was the cost-effective way to go. Amazing.

I have to believe that Intel is missing out - or maybe they will be tied to the x86 chipset and ride that for all it's worth. Who knows... but it seems like something they are missing out on. And how long can it be before we see laptops and desktops based on ARM? Not long.

This morning I saw a tweet from SubEthaEdit that they were Open Sourcing the editor - and the current version, SubEthaEdit 5, was still on the Mac App Store, and would be free. This was a real surprise to me. I've paid for several of the versions of this collaborative editor on the Mac - heck, I've written syntax highlighting definition files for Make and Fortran for this editor. It's a big part of my tools in the past.

I have worked with my good friend on Macs for many years, and when this first appeared, as Hydra, I thought that this would be a great tool for working on code with him. But it was commercial, and we were in different states, and we hadn't even started using Git - and GitHub wasn't even an idea at the time. So it just fizzled out.

But at several times in the last 5 years we've both talked about getting something like this going for remote pair coding. It's just an editor, and he's now using Cursive for his Clojure coding, so again, maybe it's not such a great fit... and there are other services that are going for an add-in mode for existing editors, so maybe it needs to be updated to really find it's market. If so, I think that would be great.

I hope it finds a great group of developers now that it's Open Source. I'd love to have a good tool that's really written to handle the collaborative editing from the jump. Then again, I'm not all that sure what we'd need above GitHub... but it's an admirable goal.

This morning I noticed that Paw 3.1.8 was released, so I updated right away - it's about the best tool I've ever used for testing and exercising REST APIs on any platform, and on the mac, it's just gorgeous. This is a tool that I used constantly for years when working on Clojure REST services. It allowed me to have variables for each call, and then to group them into environments so that it was easy to switch from development to local to production and see the different responses - where the variables would include the name of the host, etc.

Postman is nice - and it's got a lot of features, but it isn't a native Mac app, and it's tied to the UI and workflow of a web app - which is fine, and I've used Postman a lot, but when I started using, and configuring, Paw, it wasn't even close. This is how Mac apps - tools - should be written, and sure, it's not cheap, but good things rarely are.

I still smile when I pull up the sets of calls, and how easy it was to load up a problem request, fire it off, document what was happening, and then see it in the logs... well... this was one of the tools that really made that job a dream.

Well... it was a lot of driving, but I'm home, and enjoying the long weekend where I can catch up with work around the house, and rest for the week ahead. It was nice to see my family - all my siblings were there - save my oldest sister, and it was good food... I brought the pies, as usual... but it's also nice to be home.

I find that I'm reaching a point in life that I get about all the company I need with these few trips home at the holidays. I have lots of company at work, and on the train, so it's not like I don't see people. I just find that I can be cheerful and pleasant, but I don't have to have deep conversations at this point in my life.

I'm making the best of the path that I'm on.

Today I was looking for a solution to a problem I saw in the syntax highlighting of Sublime Text 3's Markdown files when there were Clojure code blocks in the file. All the other coding blocks I had been using were highlighting with a different background, and the text in the block was highlighted according to that language's rules. But not so with Clojure.

So I asked on the Sublime Text Forums about the issue and to my amazement, I got a response! The response was clear about what I needed to do, and while there was a slight issue with the installation of a package, I solved that with a git clone in the directory, and I was in business.

At the time, I also submitted an issue with the Sublime Text GitHub group, and let them know I was having a problem. Very much like the issue on the Forum post. When I got an answer on the Forums, I updated the GitHub issue, and included the answer I got from the Forum guy. He didn't sound like he was tied into the GitHub group.

Mistake #1.

I then got a response on the Issue kinda poking me to make a PR because I have an answer that worked for me. And me, trying to be helpful to the folks that helped me, wanted to respond. It was just the tone of the request that was a little off. I should have listened to that voice.

Mistake #2.

So I made the Pull Request on the project and put in the comments, etc. and submitted it. At this point, I really want to thank GitHub for making a tool that has the most amazing workflow I've ever used. The ability to fork, and make a PR on a GitHub repo, and have the fork linked to the PR so that updating one updates the other is just amazing. I know it's not impossible - but it is very nice, and that's so nice to see.

The PR, as you can see, is really a very specific YAML file section, and there were, of course, no comments in it. I had no idea that the elements have changed, so when the reviewer chastised me for not looking at the rest of the file, and detecting the changes, I got a little prickly. But I said to myself "Take it easy... this is a simple mistake", and I apologized on the PR, and made the changes.

At the same time, the guy who helped me on the Forum chimed in and threw me under the bus - saying "Yeah, he didn't do the right thing - I gave him something that worked on the release version, but not master". I love it when people do this. It's such a comforting thought to be in an industry of people with such high integrity.

So that was fixed, and I thought "OK... enough of this, moving on..."

Mistake #3.

I then got a note saying that I hadn't read the rules of PR submissions, and that I needed to write rendering tests for this new code block. And believe me, these are not easy, and they are not trivial, and all this for something I should have just said "Sorry, I'm too busy, you can do the PR on your own."

But I read up on the tests. How to write them - and they are stupid. But I did it. And then I wrote the rendering tests and added those to the PR. And they all passed. Which was nice. So now I'm thinking "OK... this is finally over." But when will I learn?

Then a maintainer comes along and says this will have to be put on hold because they don't understand something about what's happening in the code, and that is causing an issue that is unrelated to the PR, but the PR would make things worse, or something.

So... I try to be a nice guy after someone has been nice to me... you know... passing it on... and for that, I get to deal with the Slashdot Kids living in their parent's basement and holding some power trip over poor saps like me that try to help folks out.

But I have a fix. I know what to do for subsequent releases, and I'll never do this again with these folks. Lesson learned.

I was walking to work from the train this morning, and heard a Christmas song in the Grand Hall at Union Station, and it got me to humming Christmas Songs on the walk into work. Now it's full-tilt Christmas Songs while I work. Good stuff!

It's just one of the wonderful ways of noticing the passage of time. Songs I haven't heard in nearly a year, and always remind me of the very best of what we can all be.

This morning, I wanted to get the first version of Cap'n Hook published on Clojars, but I needed to get a few things cleaned up. First, I needed to get the latest changes to durable-queue up to Clojars, as there were some dependencies I need to clear up - most notably in the nippy and byte-streams packages, so that was fixed up and a simple publish, and I'm up on Clojars.

At this point, I'm a little surprised that I have to type in my GPG passphrase each time I sign the jar for publishing. I can see the logic that I've read online - basically, signing is a fairly infrequent task, and needs to be done with care, so ask for the passphrase on those occasions. OK... I get it, but I'd still like to have it in my Keychain, and then just lock it up there. No need to keep typing it in.

I need to pay closer attention to the passphrase dialog on the next publish, and see if I can't get it to save the passphrase in the Keychain. But it's not horrible at this time - I don't publish all that often.

After I got durable-queue up, I could then clean up the capn-hook code a little and then publish it. Again, not bad - cleared out a few dependencies to streamline things just a touch, and then update the README.md for the folks coming to the GitHub page, and away it goes.

Not a bad morning - got a little more familiar with GPG, and published a few things. Good enough.

Today I was looking for my favorite mustard - French's Plain Yellow Spicy Mustard - online because I really do like it, and my local Jewel stores have stopped selling it. I'm not a fan of Amazon's treatment of it's employees, so I have not really become an Amazon shopper. Sure, I've bought a few things in the past, but it's not a company I want to support - but I don't judge people that use it all the time, because this is my choice, and not theirs.

So I found that Jet has my mustard, and I was quite excited. It wasn't Amazon, and the web site looked nice, and it seemed like a decent place. So I ordered the mustard, and downloaded the iPhone app, and felt pretty good about myself.

And then a friend told me that Walmart owned Jet.

Shucks.

I'm not a fan of Walmart, either. But I guess in the grand scheme of things, I can tolerate Walmart a little more than Amazon, and so I'll keep my order for the mustard. But I sure wish there were a way to support a non-mega-company, and get the few things I'd like to have. I was happy with Jewel, but they stopped carrying it. So I have to deal with one of these mega-corporations. And if that's the choice I have, I'll stick with Jet because they were once an independent company, and Walmart is a little less distasteful than Amazon.

But I wish there were another option.

This morning I've finally put the docs and a few tests on my Clojure library called Cap'n Hook - after the cereal, and the fact that it's all about making web hooks easier to implement in services. When I was looking for my current position, I was thinking what could I write that would be fun and useful at the same time. One of the things that I knew were really useful were the web hooks that allowed one-way, asynchronous, message passing from a service to a set of registered clients.

While it's not really a good replacement for a real messaging system like any of the messaging offerings from AWS, or Tibco, or even Java MQ - it is very easy to implement, and if you're in the world of RESTful services, it's a really handy thing to have, as it's super simple to implement.

Also, if you put in retries, as I have, then it's pretty close to reliable - but only if your receiver is online and taking POST messages on that URL. Sure... it's not perfect, but for dealing with simple messaging between data centers, it's hard to beat. There are a ton of services (GitHub, etc.) that are using this to fire-off events on the client-side of things.

So it's pretty simple to use - the key is that for most cases, you are going to need to have some persistent set of registered URLs, These are the "endpoints" for the HTTP POST calls that this library will be sending in response to the main application saying "Here you go!".

I was a little blocked for several months on this - because I wanted to be able to implement a shared, persistent, reliable storage for the registrations - and then yesterday I realized that was just a bad idea. Each application that uses this will want to implement their own registration their way - and while I implemented a simplified registration that wasn't shared or persistent, the ideas are there, and it's easy to slot in a different registration scheme at any time.

I can see using redis to store the URLs - it has all the primitives to do what's needed. And there's Postgres - or any database, really, and I even cover that in one of the examples in the README.md on the GitHub repo. So there's no need to really solve the registration problem for everyone. Just give the users a simple one to get going, and then they can get as fancy as they need to.

I spent a little time on writing some unit tests, but it's going to be hard to really test the sending as it really needs to hit something, but I'll spend a little time today seeing if there isn't an "echo" test site out there for just this kind of testing, and then I can test sending the POST messages to see if they work.

But it's been a lot of fun to get this done and into testing... The documentation was great fun, and it just was a great little thing to finish.

I've been using iTerm2 since it was forked from the original, as there were things in Terminal.app that I just didn't like at the time: forced scroll bars, difficult selection of words... lots of little usability and chrome things. Now it's true that since then, Terminal.app has gotten a lot better - and on each new macOS upgrade, I always give it a try for a little bit... just to make sure it's still not the tool I'd like to use. But for quite a while, it's been iTerm2.

So why write about it now? Well... with version 3.2, they have used Metal to make the text rendering amazingly fast and the scrolling super smooth. This makes the overall appearance a real treat. Just amazing, really.

Now I'm going to see what the status is for BBEdit and Sublime Text 3 - because this kind of scrolling and updating is really quite impressive!

UPDATE: Sublime Text 3 seems to be using the GPU for rendering! Great! No need to worry about that. I know that there are new MacBook Pros coming out this month with the new GPUs, and now may be the right time to look at upgrading!