With many projects waiting on parts, or requiring only an hour or two to push them forwards, last week often felt unfocused. In spite of that, I hit a couple of exciting software milestones which sneaked up on me.

The week has also given me the opportunity to decide where to focus my weeknotes: I spent a bunch of time down various rabbit holes—exploring the differences in 90s video game audio between MS-DOS and System 7 (spoiler: Macs were significantly better), attempting to build a Microdox from Boardsource, and trawling forums with a view to purchasing a MiSTer—things which, albeit creative, don’t naturally have a home here. Given that, I’ve decided to concentrate these notes on projects (independent or otherwise) that require significant personal design input, and write dedicated posts for my other exploits if time permits.

Spherical Display

The mechanical parts I ordered from ServoCity last week turned up, giving me a chance to assemble and fit-test the motor assembly of the spherical display. Much to my surprise, everything seem to go together as I had hoped, yet again proving the ‘measure, measure, cut’ maxim.

It’s really exciting to see the part in the flesh so soon after designing it

Right now, the only concern I have is that the tolerances of the U-shaped bracket aren’t quite right: the two pillow block bearings (mounted horizontally in the bracket) are being pulled very slightly out of alignment, stopping the shaft from spinning freely. I won’t be able to tell if this additional friction will cause problems until I get a motor and suitably sized pinion gear, but I’m already toying with the idea of omitting the second bearing as a way of avoiding the issue altogether.

Excitingly, the hula hoop from MoodHoops also turned up (in what looked like a giant pizza box):

The construction of the hula hoop is more than I could have hoped for: it’s made with a translucent polypropylene which should diffuse light from the LEDs well, and is joined simply, with a smaller-diameter insert and rivets which should be easy to drill out to let me fit it to the bottom of the motor assembly.

The hula hoop is joined using a couple of rivets

As a reminder, the hoop and motor assembly will look something like this:

To keep things moving forwards, I ordered a motor, slip ring, and control board from Adafruit, and have a 2m strip of DotStar LEDs on the way from AliExpress. Hopefully, these will turn up in the coming week, and I can put a few more pieces together. 🤞🏻

You can find the project on GitHub.

Tiny Cathode Ray Tube

Also on-going from last week were my efforts to get my Sony CRTs working. Thankfully, I didn’t have to wait long for my new power supply to turn up so, with all the other parts ready and waiting, I spent a little time this week attempting to fire up one of these charming black and white 4" CRTs.

Unfortunately, things didn’t go as smoothly as I might have hoped: as soon as I connected the first display up to the power supply, there was a large bang, followed by that wonderful whiff of burning electronics. Having made sure everything was safe, I double-checked my wiring and, sure enough, I’d managed to connect the 12V cathode and anode backwards. 🤦🏻‍♂️

Not to be deterred, I re-wired the JST connector (taking extra care to get my 12V and composite pins correct), and tried to power up the second display. Thankfully there wasn’t any magic smoke this time, but the second display still didn’t power up, putting my hopes and dreams of a small black and white RetroPie console on hold.

At this point, I’m beginning to accept that the project isn’t going to be as simple as I’d hoped: either the (somewhat suspicious) wiring diagrams are wrong, or the devices themselves are unreliable. The screens were likely built in an era when capacitors were spectacularly flaky so one of the next things I plan to do is test the capacitors (having first learned how to test capacitors).

Open Source

During my time at Apple, I was unable to publish any of my personal software. Since leaving, it’s been wonderfully refreshing to be able to tidy up and slowly release some of the little tools I’ve built for myself over the last few years. This week, I did that for two of my projects: a Pinboard client called Bookmarks, and a document management suite called Fileaway.

I’m trying a new thing with both of these apps: I’m releasing the source under the MIT license (as I do with most of my software), but planning to sell the binary builds on the App Store when they reach a suitable level of maturity. This way I get to develop in the open and hopefully contribute to the development community, while also addressing some of the on-going development and maintenance costs.

Bookmarks

I’ve used Pinboard for bookmarking ever since Delicious went the way of the Dodo. It’s an entirely functional Delicious clone that (and this is one of its strengths) hasn’t changed in about a decade. I rely heavily on bookmarks to organise my projects and research and, at the time of writing this, I have over 6000 bookmarks in Pinboard.

Pinboard is incredibly text-heavy

As a very visual person, my main frustration with Pinboard is that it’s hard to find bookmarks—I don’t scan text quickly, and I remember far better how things look than any wording around them. To address this, I wrote Bookmarks for iOS, iPadOS, and macOS, and I’ve been using it daily for the past few months:

Bookmarks shows thumbnails for all your bookmarks

Conceptually, Bookmarks is a very simple app: it downloads all your bookmarks from Pinboard, fetches an appropriate thumbnail for each, and displays everything in a searchable grid. Identifying a suitable thumbnail is far harder than it first seems though and, under the hood, the app has to fire up WebKit for every bookmark, fetch the page, and evaluate some JavaScript in the page.

Since it’s been working for me for a while now, this week was focused mainly on tidying up some of the rougher edges of Bookmarks, setting up smoke test builds using GitHub actions, and adding an initial release for others to use. Since this is still very much a ‘pre-release’ build, I’ve only published the macOS binary so far, but I hope to add TestFlight builds for iOS in the future.

To set up GitHub smoke-test builds, I had to remind myself how to use xcodebuild, and figure out how to stop Xcode from attempting to sign my binaries (since I’m using a public repository, I don’t want to have any signing keys in the repository and available to third-party PRs). It turns out this can be done simply by adding the CODE_SIGN_IDENTITY, CODE_SIGNING_REQUIRED and CODE_SIGNING_ALLOWED environment variables as follows:

function build_scheme {
    xcodebuild \
        -project Bookmarks.xcodeproj \
        -scheme "$1" \
        clean \
        build \
        CODE_SIGN_IDENTITY="" \
        CODE_SIGNING_REQUIRED=NO \
        CODE_SIGNING_ALLOWED=NO
}

I may look into using xcconfig files to achieve this in the future as it has the advantage of consolidating the settings used by the UI and the command line.

It’s still very much early days for Bookmarks (there are a couple of known crashes when searching, performance is all over the place, the share sheet doesn’t work correctly, and the thumbnails sometimes pick up ads), but I’m really excited to have published my first pre-pre-alpha build.

If you’re interested in following along with the development of Bookmarks, you can find it on GitHub, keep an eye on my weeknotes, or install a build.

Fileaway

Fileaway is a (mainly) macOS app I’ve been working on in various forms for a long time. It’s a cross between an email client, and a GTD app for document management: it’s strongly opinionated about workflow (documents sit in an inbox waiting to be dealt with, and are then filed away in an archive), yet flexible about exactly how you structure your inbox and archive, acknowledging that people often have their own filing system preferences. It’s the result of a good 10 years of trying out different out approaches to paperwork and document management, and the slow convergence upon an approach that seems to work well for me.

Like a mail client, the main window separates documents into an inbox for triage, and an archive for quick reference

The Inbox and Archive are backed by user selected directories, meaning Fileaway is as happy working with Dropbox as it is iCloud Drive. Files (currently only PDFs) located within any subdirectory of these top-level directories are shown in a flat list for quick access and filtering. In the future, I plan to allow users to select which files types appear in Fileaway, and add multiple inbox and archive directories. For example, I expect a common setup would have ~/Desktop and ~/Downloads as inbox directories, and ~/Documents as the archive directory.

The expected workflow (and how I use Fileaway) has users downloading files to ~/Downloads, or saving them to ~/Desktop, meaning they’ll appear in the Inbox. Here they remain until dealt with (bills paid, forms completed, … etc). After that they’re moved to the Archive with a user-initiated wizard and a set of user-defined rules:

The wizard offers a preview of the document and a quick way to select a suitable rule

Rules can move files to specific locations in the Archive based on user-specified parameters

Once files have been moved to the Archive, the whole purpose of Fileaway becomes making finding and accessing them fast and painless. I’ve put a fair amount of work into in-memory filtering and, for my setup (with an Archive of roughly 6000 files) it is significantly faster than Spotlight¹.

Fileaway makes it really easy to find files in your archive

Most of my efforts on Fileaway this week have been been focused on preparing the source for outside consumption: I had some history I needed to prune, user names to correct, and secrets that required redacting. To do this, I used the relatively new git-filter-repo (replacing BFG) which is unexpectedly simple to use (especially in the realm of git). For example,

• replacing a secret

  git filter-repo --replace-text ../expressions.txt
  

  where expressions.txt follows the syntax

  literal:a secret==>public alternative
  

  which can be verified by using git-grep to search all commits for the undesirable string

  git grep "a secret" $(git rev-list --all)
  

• updating an author

  git filter-repo --mailmap ../mailmap.txt
  

  where mailmap.txt follows the syntax

  User Name <user.name@example.com> <mistake@example.com>
  

  which can simply be verified on a project with few authors by listing all unique authors

  git log --format='%aN <%aE>' | sort | uniq
  

Of course, rewriting history is a terrible terrible thing to do, but sometimes needs must.

After a very long period of development, it was wonderfully surprising to realise that these where the last few steps to publishing Fileaway as open source project and starting the journey to a full release.

Like Bookmarks, Fileaway is in the earliest stages of release. It works well for me (and has done for a good few months), but only a handful of people have ever used it—something I hope to change by releasing it like this. If you’re interested in trying out an app at this early stage of development, I’d absolutely love your feedback.

You can find out more on GitHub, and download Fileaway from the Releases page.

Shelving Upgrade

Between the two of us, my partner and I indulge in a wide array of creative and crafting hobbies (if this site isn’t enough of a giveaway). Squeezing all the requisite parts, tools and supplies into our small San Francisco apartment is quite a challenge; one that’s only been made more so by the pandemic.

Feeling the pressure of space yet again, I took a trip to our local builders suppliers and had some longer poplar shelves cut for the spare bedroom (long dubbed the ‘making room’). It’s nice to have even a little extra space for all the new things we’ve acquired over the year (eagle-eyed readers will notice the new bench power supply nestled away).