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.
In setting out to write up a little status report of what I’ve been up to recently, I found myself thinking of military acronyms.
Combat, not surprisingly, engenders a dark cynicism, leading to some amusing abbreviations for situation reports. A few examples:
No doubt there are many more.
I suspect that programmers generally share the same attitude to planning - and the sense of how much any plan matches reality - that most troops on the ground in the thick of it do.
This may explain why, when setting out to describe my current situation, an acronym of my own came to mind: SNAIL.
The good news is that it’s is not (quite) so negative as the miliary ones.
It is though quite descriptive of the state I normally find myself in - and also the pace at which things tend to move as a result.
SNAIL: Situation Normal, All Inter-Linked.
Also incidentally much loved by programmers. It took me a surprisingly long time to work out why people always picked the names
bar whenever they were writing out a code example… ↩
Recently I’ve been working with some cross-platform Swift, that needs to build ok on both macOS and Linux.
Naturally I want to unit test it, and I’d like to have the tests hooked up to continuous integration.
Previously I was a big fan of Jenkins, and whilst working on Sketch I helped to build up a fairly complex testing setup with a bunch of Mac Minis all hooked up as remotes to a Jenkins server.
At the time, it gave us the flexibility we needed, and it still has a lot of things going for it as an approach, especially if you want it to perform a lot of complex operations, including code signing, and preparing and releasing final builds. It does mean housing (or co-locating), and maintaining a bunch of physical machines though, which is a pain in the arse.
These days, my needs are a little simpler, and I’m an even bigger fan of Travis.
Back in February, I mentioned that I was pondering which platform(s) to work on.
Having been a Mac developer for most of the last 30 years, I was starting to feel that it might be time to at least experiment with other things, and also starting to feel a little frustrated with the hardware options available to me if I stuck with buying from Apple.
A few weeks ago I finally got round to doing something about this. I specced out a PC, bought the components, and put it all together.
As part of this process, I obviously had to decide what systems to install on it.