I have been accused (by myself, mostly), of being a bit too much of a purist sometimes. It’s true that I do like things to have an intellectual rigour to them, but it’s mostly about being honest and clear with ourselves about what we’re doing and why. I welcome the application of common sense, and I’m fine with taking shortcuts as long as they’re consciously chosen for a good reason.

I’d like to think that I’m a pragmatist…

Bookish Development Diary, episode 8.

As I mentioned last time, I’ve been playing around with Github Actions, using them to build and test my Swift packages on a number of platforms.

They’re fairly easy to set up - you make a yaml file called something like Tests.yml, add it to the .github/workflows/ directory at the root of your repository, and commit.

The yaml file can contain a vast range of things, but for testing Swift what it usually boils down to some fairly standard steps.

First you select which system and tool versions to build on. For the mac, the macOS-latest image gives you the latest releases of macOS and Xcode. For Linux, there are Docker images available for Swift 5.0 and 5.1, as well as nightly builds of the latest Swift.

Then you clone your package with git.

Next you perform a build, using either swift build or xcodebuild build, depending on the platform you’re on.

Next you run some tests with swift test or xcodebuild test.

There are plenty of other things you can also do (for example posting notifications, uploading files), but a simple file that just builds & tests on the Mac might look something like this:

name: tests
on: [push, pull_request]
jobs:
  macos:
    name: MacOS
    runs-on: macOS-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v1
    - name: Build
      run: swift build -v
    - name: Test
      run: swift test -v -c release

So far so good…

Bookish Development Diary, episode 7.

Ok, I admit it, I fell down a bit of a rabbit hole a couple of weeks ago.

Quite a lot of my open source packages have some sort of unit tests, and I’d been using Travis-CI as a way of running them, with CCMenu to monitor them locally.

Recently though I’ve been experimenting with Github Actions instead of Travis. They work really well, and I think I’m going to switch over to using them for everything.

The one thing I miss though is CCMenu. So I decided to see how quickly I could hack together a replacement. It was also an excuse to play around with SwiftUI…

Bookish Development Diary, episode 6.

Call me an idiot (“Sam, you’re an idiot” - ed.), but whenever I try to use UISplitViewController, I seem to get myself into a tangle. It doesn’t work the way I expect it to.

What I generally want is an index view side-by-side with a stack of detail views.

If I’m on a phone, or a horizontally-compact environment, I want the index to collapse onto the stack, so that there’s just one view. Tapping an index item here should push the detail view onto the stack, replacing the index.

Assuming that I’m not restoring the previous state of the app, this is how things should start in a compact environment. I definitely don’t want the app to start showing an empty detail view, and hiding the index 🤦🏼‍.

If the view is collapsed and some detail is showing, I don’t want to be able to pop up the index view, or slide it over the detail.

I just want to be able to pop the navigation stack to get back to the index.

This is not rocket science!

I’m sure that you can get UISplitViewController to behave like this, but invariably I seem to end up having to jump through a lot of hoops to do it, and even then sometimes do it wrong.

I hit this situation yet again whilst working on an example viewer app for Datastore, so I started wondering how easy it would be to just throw it away and make something simpler…

Erica Sadun blogged recently about the trials and tribulations of upgrading a system with a long history of tooling on it.

(the link to that blog post seems to have vanished; I’m not sure if it’s been taken down or just moved, but it doesn’t really matter, as the post was just a prompt to me to write what follows)

This is a problem I could relate to, having been working with Macs since 1988, and over many years developed a large number of scripts, utilities and system hacks to make my life easier and more productive.

Fortunately (sort of), it’s a problem I’ve had to try to solve (or at least make easier), since I’ve regularly had to move between systems, and work on multiple systems at once.

At one point, whilst working on Football Manager, I was writing the low level cross platform libraries which had to build on the Mac, Windows, Linux, XBox 360, PSP and PS3! I had about three monitors on my desk, four or five machines under it, and was regularly booting into development environments for all of them. Fun times.

What I used to do for many years was have a single monolithic directory under source control, which contained all of my helpful stuff. This had a bootstrap script in it so in theory I could just fetch the repo to a new machine, and run the bootstrap script.

It was never quite that smooth, but worked, up to a point.

However, it got a little crufty. Over time, as I moved on, most of what was in it became irrelevant, but was still hanging around. Some bits of what was in it actually logically lived elsewhere, which once I’d moved the thing into git meant some dalliances with submodules.

Eventually I realised that what I needed to do was to modularise this big lump of stuff, so that I could still share common things between systems, and still set up a new system easily, but I could also just install the bits I needed on any given system.

This sounded awfully like a package manager! Unfortunately, the ones I was familiar with tended to be tied to the Mac.

“How hard could it be?”, I thought - foolishly - to make a really simple one myself. All it needs is the ability to download packages, and to run a little script inside a package to install/uninstall it.

And thus, XPkg was born.

It is very much a work in progress, and I wouldn’t necessarily say that it’s ready for other people, but Erica’s blog post reminded me that I had been meaning to tell other people that it existed.

Rather than repeat myself, I’ll let the Read Me file tell you more.

You may also be interested to know that not only is it written in Swift, it actually uses the Swift Package Manager as the transport mechanism for fetching the packages that it manages, and resolving dependencies between them.