The MapPoint service is a commercial offering by Microsoft which gives developers access to a wide variety of mapping functionality through a web service interface. Well that's how it used to be anyway. For a while MapPoint was just a web service and a technology that powered products like Autoroute, then for a while it became Microsoft Virtual Earth which did nothing apart from change what appeared on the map images that you loaded from the servers. Then Microsoft launched their Bing extravaganza which meant that it's now called Bing Maps - well it is when one logs into the control panel but the service is still called MapPoint. It's highly confusing and makes it intensely difficult to find what one wants on the Microsoft site, especially on plumbing the depths of MSDN. For the purposes of this diatribe however, MapPoint is a web service that uses the SOAP protocol.
the process could fail catastrophically, mostly due to the abject bloody-mindedness of the MapPoint service
SOAP and PHP have not always been the most accommodating of bedfellows, it wasn't until version five that PHP had the language constructs to support SOAP (namely XML and Objects) and even now they're not exactly seamlessly integrated. Version four of PHP relied upon pure-PHP to manage SOAP, while five introduced a dedicated extension and related classes. The classes themselves are basic, and lamentably the Zend Framework concentrates more on serving SOAP content than consuming. In short, talking to the MapPoint service using PHP is a pain and fraught with problems - most predominantly is that MapPoint is a service built with .NET in mind (indeed the service was originally called MapPoint .NET), PHP just happens to be supported through the open-standard nature of the protocol.
The longest running and most high-profile website I have the pleasure of working on is for Little Chef. With such a recognisable brand and in a period of increased company activity, the site is increasing its role as the primary communication with customers. With a recent aesthetic refresh which only select parts of the site were quick to follow, the remainder was still stoically in the old style - updating the rest was a deceptively large task and exposed the opportunity to rectify some of the niggling obstructions that had grown with the site. What on the surface was just a visual update was in a fact a more far-reaching upgrade.
if these were the most complicated aspects of the site the rebuild would have been simpler and drastically more straightforward.
Rebuilding an existing site always starts with the best intentions - glassy eyed optimism seeing only improvements and never pitfalls, but experience has taught temperance rather than ambitious extravagance. Ambivalence is quick to set in: on the one hand there is a full and detailed specification available in the form of the currently used site, while on the other it soon becomes rapidly apparent that with history comes refinement that may not lend itself to rapid reconstruction. Striking a balance between reconstructing for improvement and the silent threat of feature creep is the key to a timely and successful project.
My Sunday afternoon project wasn't something that I could just let lie and it didn't take long for work to start on it again. Using the list of improvements I had identified, I began with the aesthetics and then moved on to other, more number intensive areas of research.
Before even touching the code I subsumed everything into a Git repository; I'm a long time Subversion user but relatively new to Git so I still regularly refer back to the "Git - SVN Crash Course" which is pleasantly concise. With this done, I attacked the GIF output method first:
cooked up in a few hours and wasn't subject to any stringent mathematical basis
First was visibly increasing the size of the cells, I had originally used a multiplier of four for previous iterations but that made them very indistinct, and with only fifty generations it meant a large portion of the space wasn't used. The result was an increase in cell size to seven with a one pixel border: this was the result of a happy accident while crafting the previous post and resulted in the introductory images, however the calculations for the edge cells was incorrect which is why those animations don't appear to "loop" at the edges as they should. This implementation fixed that and with a vastly smaller environment (only 8x8 with a 5x5 seed), each generation of cells and their progression is easier to see. Next was addressing the colour issue, generating both a background and foreground colour met with mixed results so taking a leaf from WP_Identicon's book, I kept the background colour constant and generated the foreground colour only:
As a way of spending my bank holiday Sunday afternoon, I decided to embark on a small project; I didn't know what the project would be when I first began browsing through Wikipedia but eventually I ended up in About.com's C++ challenge section, one of which concerned John Horton Conway's "Game of Life": a rudimentary cellular automaton which, after its inception in 1970, had immeasurable impact on fields as diverse as philosophy and theology. After toying with some ideas, I decided to build a script which automatically creates animations of a number of generations of the game. From that seed the project grew into the first steps towards an avatar system, much like the automatically generated Gravatars that currently adorn so many Wordpress based blogs.
I wanted something that was deterministic and identifiable
The first step was getting the algorithm working, and as I had already decided to make it web-based, that meant a PHP implementation. Using only the Wikipedia page as reference, I threw together a very basic script that allowed me to enter in some settings (grid dimensions, seed and generation limit) and for it to spit out the states between the seed and the generation cut off. After some wrangling with minor bugs (spelling errors, incorrect typing etc.) an unoptimised first version of the algorithm was complete:
The newest addition to chaostangent.com is the carousel nestling comfortably at the foot of every page. Sporting a variety of "social media" feeds as well as other morsels, it showcases a number of interesting technologies and techniques including: a fully looping carousel (JavaScript and CSS), integration with numerous external APIs (PHP, Zend Framework), screen-scraping and local caching of results to name but a few. It successfully fulfils the primary goal I had for it: cramming as much functionality into a contained a space as reasonably possible.
I can just boot up Zend_Service_Delicious and be done with it right? If only things were that simple.
JavaScript
The carousel interface is design du-jour at the moment - sported by sites such as Apple, BBC iPlayer and Gametrailers - they manage selective display of information while still providing a high degree of interactivity. In short: they're swish and solve the problem of too much to feature in too little space. The carousel library I am using is a simplified, stripped-down version of one I developed for a large work project - for this reason I'm unable to release it under any kind of license. The original has a number of features that I wouldn't be using including automated construction of a "jump to" control and being able to navigate over a number of entries at once. My library is the only one I know of which successfully loops, providing an "infinite" carousel of sorts; other publicly available libraries cease at either end of the carousel which in some situations is more intuitive but the challenge of making one not do this was posed to me, and I couldn't very well pass it up.
