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.

 

Tilo Development summary

The brief for TILO is quite broad and requires the use of a number of technologies. As lead developer I’m currently researching and using:

  • NodeJS – Online data services
  • Scala – Digital Signage Platform
  • C++ – Creating Rich Interactive Content
  • HTML + Javascript – Mobile Web Apps
  • Raspberry Pi/Beaglebone – Creating Remote Sensors and Actuators

The internet is now a very powerful tool. Even for simple web apps I’m now looking at leveraging:

  • Social Network APIs – sharing content and streamlining sign in forms
  • AWS S3 – uploading and sharing large media files
  • Mobile Phone App APIs – more apps are sharing information (e.g. ‘Move’ for iOS and Android, pull information about users activity)
  • SMS and Voice APIs – send and receive text messages (e.g. respond to queries or notify members) or provide an intelligent automated telephone system
  • Connected Devices – use services like Xively.com to share information between connected sensors and devices

Doing any of these from scratch would be a huge drain on my time, a resource I can’t afford to squander. Instead these platforms and services provide an easy jump off point meaning I get to do more interesting creative work sooner. On going, the Third Party maintains and manages their service requiring only occasional input from myself, automatically scaling as my demands on the service grow.

Drawing a Fbo with Alpha Blending Enabled

I’ve wasted a couple of weeks trying to find the solution to this one, but as is sometimes the problem when searching online it’s often difficult to get the exact mix of keywords right before you start to yield any valid leads.

I was working with OpenFrameWorks on an application that generated a series of animated tiles. Because each tile needed to be individually rendered and masked I need to use a Fbo to render it off stage and then blend them all together as part of a final step. This was all working well until I tried to render some text into the Fbo. The Anti-Aliasing was terrible, something I initially put down to the font.

After a lot of testing I discovered that the Alpha channel in the Fbo was being treated in a very odd manor. As an example, if I filled a Fbo with a solid black color, then drew some white text I’d expect to have a texture that was completely solid (no transparency) with the white text anti aliased onto the black background. Drawing straight to stage without the Fbo indicated this was correct.

If I then took this Fbo and drew it to stage which had been filled red I would get a black background and white text (as expected) but instead the antialiasing around the text appeared as a blurry red edge. After a lot of testing I came to the conclusion that the alpha channel was being used to acheive the anti-aliasing around the text allowing the red background to show through.

I finally found this thread on the OpenFrameWorks Forum: https://forum.openframeworks.cc/index.php/topic,1643.0.html

It was the recommended solution by ‘blainer_s’ that worked for me:

void testApp::setup(){  
    image.loadImage("myPng.png");  
    //image is an ofImage, myPng.png is an image i created in photoshop real quick for testing  
    texture.allocate(ofGetWidth(), ofGetHeight(), true);  
    //texture is my ofxFBOTexture  
}  
  
//--------------------------------------------------------------  
void testApp::update(){}  
  
//--------------------------------------------------------------  
void testApp::draw(){  
      
    texture.begin();  
  
    ofEnableAlphaBlending();  
  
    image.draw(0, 0);  
  
    ofDisableAlphaBlending();  
      
    texture.end();  
      
    glEnable(GL_BLEND);  
    glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);   
  
    //This is what is normally called with ofEnableAlphaBlending  
    //glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);  
  
    //if you have changed your blend equation, uncomment to return to default  
    //glBlendEquation(GL_FUNC_ADD);  
          
    texture.draw(0,0);  
  
    glDisable(GL_BLEND);  
}

The important step being to change the blend function like so.

glEnable(GL_BLEND);  
glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_ALPHA);   
//return to normal using
//glBlendEquation(GL_FUNC_ADD);