Week 152 saw my return to the studio after a week off, which was an excellent tonic after a busy August.

I spent much of the fortnight building a standalone environment for Selworthy. It was initially configured for an internal environment provided by one of its end-users, but my client wanted their own install to be able to demonstrate it and use it themselves.

I did this with Ansible. It’s a tool I didn’t know well at the beginning of the fortnight, but by the end, it had already proved its value several times over.

Ansible is a tool to help provision servers. It allows me to write small rules to describe the configuration of a server component, that will be idempotent – I can run them as many times as I’d like, and they either bring the server up to that configuration, or do nothing.

To begin with, it felt quite slow: prodding at syntax until the behaviour I want has been applied. I built the environment by building and destroying servers repeatedly, continuing to test that it’d work from a standing start. And each time I do that, the fact that all previous steps just work immediately becomes a huge advantage.

The other advantage is that Selworthy actually consists of two separate application – the main application, and a media-encoding tool – which have fairly similar system requirements. I built the Ansible playbooks for the media encoder first – which took a bit under a week of work. Then, however, it took about an hour to provision the main application server – because so much of the work had already been done and could be reapplied. It’s useful to be able to provision boxes so fast, and I’m definitely going to be continuing to use Ansible on future projects. The value isn’t just in the repeatability: it’s also in the ease of sharing it with other potential developers – guaranteeing that they can build the same environments as you. I’m not a great sysadmin, and it’s never going to be the main focus of my work, but the more controlled the environment I’m deploying to, the more confident I can be in it – and that’s a huge advantage.

By the end of the work, I could build the entire environment for Scribe in about ten minutes, from a single command, and then deploy each application to it in another single command. I was pretty pleased with that.

Around that work, I fitted a variety of other small pieces of work. I had an excellent chat with Holly Gramazio over coffee one morning, where she told me how Now Play This had gone, and we had a long conversation about the curation of games. It’s always valuable as a freelancer to be able to chat to colleagues, especially those at the edges of some of the spaces I work in, and Holly’s always a delight to talk with; nice to get out of the software for a morning, and hear about other friends’ successes.

I spent an afternoon at the Polyphonic Playground Lab, watching how musicians worked with the playground, and thinking about ways to potentially involve a much wider audience as part of the project. It was also a good opportunity to think about the intersection of music, sound and interaction design, which I’m thinking about a lot at the moment. That overlapped with the TouchOSC controller for Panoramical that I built the weekend before, as a small personal piece of tinkering.

Finally, I spent some time chatting with Richard about bringing Twinklr into land. We’ve got a plan of how to do that, which should fit around our life in the next few weeks, and an idea of where we’d like to take it next. As part of that exploration, I kicked off an attempt to rebuild it in Unity. As ever when porting code from something you know well to something less well, it can feel painfully slow at times, and as a result, I’ve only got code for drawing staves at the moment – but it’s a beginning, and something to build on. I’ve been thinking about a Unity build simply to make it easier to iterate on the real-time aspects of the code, and especially to consider more complex interactions that will become harder and harder to write in the browser.

Oh – and I took the opportunity, nearly six months on, to finally write up Rubato, another project Richard and I worked on together. As usual, project write-ups are always slower than I anticipate (and I still carve out a fair chunk of time for them), but I’m pleased with how that turned out.