Bookish Development Diary, episode 2.

One of the devevelopment tasks I enjoy most is designing then implementing a new module. The smaller the module, the more self-contained the job it is tasked with, the cleaner and simpler the resulting API, the better.

Perhaps that’s the reason that I allowed myself to be distracted by convinced of the need to develop Datastore, my generic data storage layer for Bookish…

Bookish Development Diary, episode 1.

So currently, Bookish is sort of on the floor in pieces.

I was getting fairly close to something I thought that I could start sharing with a few select friends, then I decided that a feature that I thought I could leave until version 2.0 really needed to be in version 1.0.

Or more precisely, the underlying technology for the feature needed to be in version 1.0, even if the feature itself didn’t get exposed until version 2.0.

The feature in question was the ability for the user to add custom fields to the database. Sounds innocent doesn’t it…

Since finishing work on Sketch, I’ve been a bit quiet on this blog.

Initially I took quite a bit of time off because I needed a rest, and was battling various demons.

The largest of these was burn-out, which for me presented as a major loss of confidence and enthusiasm, brought about by long periods of professional conflict. This left me wondering whether I was any good at coding, and whether it was even what I wanted to do any more. I realised that if it was, I needed to find a healthier way of doing it. There are certain negative patterns that seem to have repeated a number of times at various stages in my working life; generally when I’m working full time on a project, have a sense of shared ownership of it, and feel that I want my future to be tied up with it. I needed to take some time to reflect on why these patterns happen, and to work out how to square a certain need for control¹ with my genuine desire to work with other people as part of a team.

All of which is a big topic, worthy of a blog post (or more) in its own right, but this is not that post. Suffice to say that those battles are still part of my life, I’m still not sure I have all the answers, but on the whole I think I’m winning.

In the meantime, this post is about how (somewhat predictably, and very reassuringly), I couldn’t stay away from coding for long, and what I’ve been up to in the couple of years it’s been since I wrote my last line of Objective-C for Sketch.

I’ve been meaning to try out Xcode’s UI Testing support ever since they introduced the feature way back in Xcode 7 / 2015!

In the past I’ve tended to worry that UI testing was too brittle - it was too easy to change the appearance or layout of the UI and accidentally break tests, even though the functionality was still ok. It’s also a really major committment to retro-fit UI testing to an existing application of any significance, which has made it hard for me to adopt for existing projects.

However, I’m currently working on a new application with desktop and mobile aspects to it, so this seemed like the ideal time to give it a go.

So far the jury is out on how useful it’s going to be, but one thing was immediately irritating me.

I recently installed a new server, and decided to use Debian 9 (Stretch).

Apple distribute built versions of Swift for Ubuntu 14.04/16.04/16.10, but nothing specifically for Debian.

Since Ubuntu is downstream(-ish) from Debian, there’s a chance that the binaries might have just worked, but I decided that it would be worth the effort to try to build Swift from source on the new server, to see how hard it was.

The answer turned out to be: not very.