Technical challenges of creating the TILO platform

Tools & Methods:

  • Git: Source Code Management (and improved development workflow).
  • Uptime Robot: Realtime website status notification.
  • LogMeIn and iTeleport: Remote computer management.
  • OAuth: Authentication method to protect your API.

General Insights:
TILO has been in development for almost a year and has been in planning for almost 2 years. Although TILO is now quite an elegant efficient solution it has gone through a number of iterations, and some of those were not very pretty and were awkward to work with.

Despite the additional year of planning before development began we didn’t fully understand how it would be embraced and used until we had a version installed. We learnt more in the first 2 weeks that TILO was installed than the 3 months of development that preceded it.

Our first mistake was because we had such ambitious plans for TILO we tried to implement them all straight away. We also had a very enthusiastic client that was keen to suggest new functionality which we enthusiastically added to our feature request list. We quickly ended up with a product that was feature rich but bloated as a result.

At one point development ground to a complete halt, we were pushing new features that could couldn’t be supported by the foundation we’d hastily put in place with no clear purpose, as a result functionality was inter locked and subtle changes had an impact in multiple locations. Added to that our live and development platforms were too closely linked, a bug in the code on our development platform could leak over to the live. It was around this time we knew we needed to slow down and take a more measured long term approach to our code.

This sounds like a disaster but it wasn’t actually that bad, we just knew we couldn’t continue with our current approach. We had all the features we wanted, it just wasn’t held together very well. We needed a new ethos to adding functionality to TILO. We decided that:

TILO should only manage basic CMS functionality. All additional functionality should be added as stand alone modules that interact with TILO through a simple API.

We started using OAuth and exposed a simple API that could be used to command TILO to:

  1.  Trigger templates
  2.  Interact with the database

With this simple approach we realised that not only could we re-write our bloated CMS as independent third party modules, but other developers/artists could contribute their own modules and tools. As an added bonus, by re-building our CMS using the API we were effectively testing it for other developers and providing working examples. This got our development team quite excited, bless them, they don’t get out much.

Whilst we were reviewing our processes and workflow we also implemented:

Git Integrated Workflow:
Previously Git had only been used for version control. To speed up our workflow and improve stability we added Git to our server and used it with scripts to stop/update and restart our applications as updates were pushed to it. This was integrated with test scripts so updates would only be applied if all tests were passed. This removed human error from the process and the number of bugs reported by the client dropped significantly.

Independent application instances:
Initially we had a single instance of TILO running that was designed to handle all clients. Big mistake. It meant that to update one client we had to update them all. Using Git we set up a script for each client that would checkout a specific version of TILO, test it, and then upload it to it’s own instance on the server. The server is now running multiple versions of TILO and also has an instance used just for testing, they each hang off their own subdomain so can be individually addressed.

TILO is now running very well and our development team get a lot more sleep as a result.

 

Rhythmanalysis – work life balance

A short piece about a research project I was involved with, comparing the biometric measures of workers in the digital industries with a more traditional industry

At the start of the project a central theme brought us all together. We all became keenly aware within our separate areas, (Art, academia, creative industry and arts organisation) that over time our working and personal lives have merged. This was polarised most clearly when compared with the traditional 8 hours work, 8 hours play and 8 hours sleep model – mentioned frequently across the different projects within Time & Motion: Redefining Working Life.

Our thoughts quickly turned to how these changing working methods could be affecting our health and natural rhythms, then to how the tools required to measure and monitor these rhythms are increasingly to be found in cheap consumer products and apps

This led to the central core of our research in comparing the biological rhythms of workers in the digital industries to those in a more traditional workplace. What really struck me was how outdated the legislation behind our 40-hour week is becoming. Can we draw any comparisons between workers rights, successfully fought for during the industrial revolution and the changing working practices of the digital revolution?

The main difference is that it is no longer obvious when and where we are working and it is the individual rather than the state whom now makes this value judgment. “I must finish that report before i go to bed!”

We are fortunate that the same technology behind our new rhythms and behavioural patterns can also be used to test their physiological affects. So for me the big questions that Rhythmanalysis raises is.

As technology allows us to profile and monitor our health, wellbeing and productivity in real-time and at an individual and corporate level, is new legislation necessary for the state to protect workers and provide for a non-linear and healthy work – life balance?