Gillette AFL Trade Tracker

461 Comments | This entry was posted on Oct 16 2012

My most recent appointment required me to build a CMS and front-end for the Australian Football League for the trade period. The CMS was built to allow editors to add news items, trades and free agency movements between the 18 clubs.  The front-end was to display the inserted items, but allow the end-user to filter them to given rules. Again, I chose Yii to build this as it’s a great framework for rapid development but also robust and a pleasure to work with.

After designing the database I started building the models, views and controllers before modifying the forms to match the experience required for an easy to use and intuitive CMS. For the main news feed section, the front-end results could be filtered with different filters such as club, date and result type, eg. Trade only or general comment. These filters work together for fine control over the results shown. As each filter is used, the results are returned and populated by AJAX requests with filters being cleared by selecting Live Feed. The challenging part here was deciding on how to have the filters work together in the browser. I ended up building the URL that would be passed in the AJAX request. Session could have worked also but was an issue in load balancing and caching as I’ll point out later.

The second view was a breakdown of trades in and trades out by club. The result for the view were pulled from the same data as in the main feed to save on repetition will adding content. Also with filters that load with AJAX this came together quickly. I’m impressed the way that Yii allows you to reload content for partial views with just a few extra lines of code writing the jQuery for you.

The third view shows the players that fans most want traded. This data is pulled from another website which the results are user generated. I could build this view quickly also by implementing a second database that is easy to do in Yii.

The site went live on October 1 and the demand was a lot greater than I was expecting. This resulting in the server becoming overwhelmed and some slow or failed page loads. Being a little unprepared I quickly made new instances of the server and put them all under a load balancer to meet demand. Cloning servers and putting them under a load balancer couldn’t be easier than what is available with Rackspace. This was quick and saved me a lot of pain early on. I then spent some time adding and fine tuning the built-in caching that Yii provides. I had not used caching in Yii before but I was surprised at how easy and effective this is. Although the content should only be cached for 60 seconds on the live feed, the resources being used on the server were dramatically reduced.

This is an example of adding caching to a given part of the site with Yii:

if($this->beginCache('main-content', array(
            ))) {
                $this->renderPartial('_entryList', array(
    $this->endCache(); }


This would cache the view to 60 seconds and the varyByParam parameter tells the cache to use GET variables filter, club and dataRange as values to take into account when caching to ensure that each unique request is cached and returned as expected. This is essential as the view has a single URL but the content will change depending on what GET variables are also supplied. If I was to use sessions to keep track of what filters the browser had selected, it would fail through the cache and load balancers so sessions here was not an option.

Overall this was a fun project that required me to provide a solution for an event that I have a lot of interest in. The result is an easy to use CMS with a great user experience in the front-end also.



WebSockets In HTML5

0 Comments | This entry was posted on Aug 18 2010

Over the weekend I participated in the GTUG (Google Technology User Group) campout hackathon. The focus of the event was to learn what new things HTML5 introduces to the web and to build something using this new technology.

Along with new HTML elements such as <nav>, <footer>, <video> and <audio>, HTML5 includes a new set of APIs to drag-and-drop elements around the page, free-hand drawing on a canvas, storing data in the browser and geolocation. However my favourite new API is WebSockets.

WebSockets is a standard that intends to significantly simplify two way communication between the browser and the web server. The idea is that with a little Javascript you can open a connection to the server just by supplying the URL and port number of the service. Some server side service needs to be running on this port. For example, if the back-end technology is PHP then you would write a script (to be started from the shell) that would open a port using PHP sockets and then handle any data to be passed back and forth.

Of course the server side code will be as complicated as the application requires. The purpose of WebSockets is to have a standard that all web browsers can follow and to make the front-end development as simple as possible. To achieve this type of communication in today’s browsers requires some Javascript that polls the server for any new messages. With WebSockets, the server side service can send messages to the browsers without the browser polling at all.

The project we decided to build with WebSockets was to re-create the old game of Battleships. I thought this was an interesting idea as it breaks away from the traditional instant message module that would be a likely use of the new technology.

Although we put together some of the fundamentals of the comms I was unable to attend day two of the hackathon. I am anticipating Websockets to become available in all browsers so I can implement some ideas into a real use application.