Jonathan Prozzi and I have challenged one another to make a post about improving our websites once a week. I'm late with this one!
Most of the features on my website are experiments in learning new things. Sometimes I learn a better way of doing something that I've already built into the site and it's time to migrate!
Moving Media files from Git LFS to a Media Endpoint
I build my site with Jekyll, and I store my site's configuration and text content via Git. One of the things that most folks avoid with Git is storing text content (which fits into Git's model of efficiently storing differences over time) with large binary files like images, etc. (which Git cannot manage as efficiently).
When I first set up my site, I made use of Git LFS ("Large File Storage") for managing anything that wasn't text. Any images, video, or audio that I added to my site was stored in an _assets/ folder in a way that matched uploaded files to the posts they were a part of. Git LFS would transparently ship those files off to a secondary server rather than include their content in the Git repository itself. I had to go through some hoops to set up my local GitLab server to support Git LFS and to set up Git LFS with the server that handles receiving new posts via Micropub, compiling and deploying the site.
It turns out that there are many reasons that a site would want to handle media files separately from the text content that refers to them. In fact, it is a common enough pattern that the Micropub standard includes a definition for a separate "media endpoint" to handle file uploads. I shared a Micropub media endpoint implementation that I built called Spano a while back, and it has been working well with support from tools like Quill. So the text content of my site is served from https://martymcgui.re/, and my media files from https://media.martymcgui.re/. With a couple of changes in my code and my workflows, this has become the way I handle all media files for my site.
However, I still had a bunch of files in site being handled by Git LFS, and some of my Jekyll code (plugins and templates) for showing embeds expected files to be on the local filesystem. This past week I took some time to write some scripts to find all references to those local files, migrate them to my media server, and update the outgoing links. I also updated my embed handling so it didn't rely on local files. This let me delete a lot of local metadata I was keeping but not using, like all the EXIF tags in uploaded photos. I am now Git LFS free and it feels like one less thing to worry about.
Better Caching for Mentions from Webmention.io
When I finally started displaying webmentions, I had a very simple model for how to cache all the info from webmention.io. Basically: I stored all mentions in a big array and, when my site went to fetch new mentions, it would keep fetching until it saw the "last" mention again. This led to a bit of a bug where someone might send me a mention, update their page, and send the mention again. My site would not be able to recognize the "last" mention, so it would fetch all my mentions again, leading to everything appearing twice.
This past week I rewrote my mention handling to avoid this problem by replacing this array and storing mentions in a hash based on the source and target. The new code also checks to see if the verification date of the mention has changed (giving me a way to detect and notify about changed mentions in the future). I also reorganized my mention cache to include an index by the target URL on my site. This makes it a bit quicker to find mentions for a given page when rendering out the site.
Neither of these changes are really visible to readers of my site, but they have been useful for cleaning things up. The webmention.io handling in particular has brought my plugin a lot closer to being something I could release for other people to use!
In their shutdown announcement, Autodesk promised that they were "consolidating these tools and features into key apps such as Tinkercad, Fusion 360, and ReMake." However, the future is anything but clear for users of the 123D apps suite.
What Were the 123D Tools?
Autodesk's many tools in the "123D" line were available at 123dapp.com, and included:
123D Design, a desktop and iOS (iPad-only) app that allowed direct manipulation of 2D and 3D shapes with a focus on creating parts with precise measurements.
123D Sculpt+, a desktop app that allowed direct manipulation of 3D shapes as though modeling with clay.
123D Catch, an iOS app that allowed users to create 3D models by taking several photos (dozens or more) and uploading them to a cloud service which analyzed them to produce a rough 3D model
123D Make, a desktop app that enabled users to "slice" existing 3D models into flat 2D designs for manufacturing on CNC machines or laser cutters. Once made, the slices can be stacked to arrive back at an approximation of the original 3D design.
However, these apps were not the entirety of the ecosystem. 123dapps.com was also a social site with sharing and collaboration features. Users could store their designs on the 123D "cloud", encourage others to remix them, import others' designs into their tools for remixing, etc.
However, one important feature was also available in almost all of these tools: the 123D tools allowed users to save and load files from their local computer and share them on any platform they liked, or not share them at all.
What are the New Tools?
Autodesk is encouraging 123D users to migrate to a handful of new tools:
Tinkercad - A manipulation modeler similar to, but missing some features of 123D Design. Rather than being a desktop app, it runs in modern web browsers. Tinkercad is widely used in education.
Fusion 360 - A desktop modeling app that is similar to 123D Design, but which offers much more powerful operations, allowing for more complex designs.
ReMake - A desktop app for Windows which can create and clean up 3D models from photos. It's similar to 123D Catch, but also works with many hardware 3D scanners.
Indeed, on the surface these seem to cover all the use cases of the 123Dapp.com tools, and in most cases provide superior features. However, there are some wrinkles.
Fusion 360 offers multiple versions, a free trial and a pay edition which is free for users who can prove that they are students. However, even if one pays for the full version, Fusion 360 has one amazing anti-feature: it does not support working with local files. This means that even if a user is a paying customer, they must have fast internet access, a valid Autodesk cloud account, and abide by Autodesk's terms of service for any designs they wish to store or share.
Autodesk's shutdown of the 123D apps suite serves as an object lesson in the dangers of trusting "the cloud", but the lessons go beyond that.
The comments section of the shutdown announcement is filled with examples of educators of all stripes who are losing access to education tools. Where it is possible to migrate to the new offerings, curricula must still be rewritten. Given the nature of many school IT systems and student privacy requirements, I am willing to bet that many schools will not be able to replace 123D Design with Fusion 360 or Tinkercad at all.
The shutdown extends beyond the cloud to downloadable apps like 123D Design, as well. While Autodesk will not explicitly cripple any of the 123D tools that don't rely on cloud infrastructure, they will not offer future support or patches, and downloading them will soon become impossible. As of this writing, the Windows version of 123D Design can still be downloaded from their site. However, MacOS and iOS versions have already been pulled from Apple's app stores. Unless Autodesk commits to maintaining support for 123D Design's files in their future offerings, users will become entirely unable to work with them.
Autodesk provides powerful design tools that can be used by anyone from students with no budget up through professional engineering firms working on multi-million dollar projects. However, all Autodesk users should carefully examine the reasons for and the knock-on effects from this "consolidation". The shutdown of Autodesk 123D should make it clear that Autodesk is herding its users into a silo which will tie the fate of user's designs to the fate of Autodesk's ability and desire to run their cloud platform.
Autodesk has shown their willingness to alter the deal they make with their users. Pray they do not alter it further.
TL;DR, my site now pulls attempts to recognize single-emoji comments and display them as a "Reaction".
Slightly longer version - my site uses webmention.io for handling webmentions, and I use brid.gy to backfeed interactions from Facebook to my own site. The way brid.gy handles Facebook reactions other than the standard "like" is a little quirky - they show up in webmention.io as a "reply" with a single emoji as the "content".
Using the Ruby twemoji library, my site checks the "content" of a reply against the emoji index and, if the content is a single emoji, pulls it out of the usual "reply" display and puts it in a facepile. The emoji itself is shown as an icon in the corner of the little face image.
While I was at it, I cleaned up a lot of my webmention-handling template to make things much clearer. This will make things easier for folks that want to re-use this code when I (eventually) release this as a Jekyll plugin.