Stephen Beattie

The web is really broken right now. It takes all sorts of elegant hacks and skill with CSS and Javascript to take something originally intended as a document and turn it into an interface for a fully-functioning web application.  The fact that Google have already managed to pull of Google Maps and GMail so brilliantly is nothing short of amazing given the underlying mess they have inherited to work with.

I think HTML5’s canvas support could change a lot as it becomes possible to render directly to screen. I wouldn’t be suprised if Google or some other big organisation release a new kind of markup more suited to laying out application interfaces than HTML to make this easier – some kind of CanvasML (Update: In fact Mozilla Thunderhead seems to be pursuing this).

Mozilla’s Bespin looks like an awesome project but the decision to use Canvas as the rendering layer to avoid the overhead of HTML makes me realise why I like developing with Flash and Flex and why Silverlight looks like a great option too.  OK so Flash’s text handling isn’t brilliant but on the flip-side it’s going to take years before there is the same level of  Canvas to the same level of rendering capability as Flash and even then there’s the whole networking and data binding layers.  Javascript just isn’t as nice to work with as a compiled language like Actionscript 3 or C#.  So, with Canvas applications, aren’t we just starting over for the sake of “standards” ?   Maybe propietary plugins aren’t so bad after all… or perhaps haXe + xinf is the open-source answer waiting in the wings?

Seems I’m not the only one thinking about this.

A nostalgic, tongue-in-cheek, roller coaster of a film that captures the spirit of the original trilogy. Plenty of over the top action sequences, comic book villainy and rich special effects that enhance the much-loved Indy aesthetic.

However, the film feels like a cast and crew reunion with Indy as the guest of honour, swept along in the action rather than being the dynamic pivotal character. After the ‘fridge’ scene, Indy was never in any believable danger and the minimal romance aspects of the plot didn’t allow Harrison Ford a chance to fully deliver his famous wise-guy charm.

Overall though definitely worth a watch. Real value for money in terms of sheer entertainment.

I’ve been reading Deane’s posts on Gadgetopia a lot recently and one of them refers to the notions of ‘ Data Push’ and ‘Template Pull’ in terms of how content gets to the page driven by a CMS. This was an interesting post for me as I’ve recently found that a combination of these models provided a solution to a problem I was having.

As part of my work for Golley Slater Digital I’ve been architecting a PHP5-based CMS that uses the ‘Push’ model where content authored on a private ‘admin’ server is published to a public ‘live’ server to be viewed by end-users. Essentially, the CMS stores content in MySQL, writing it out as a hierarchy of static HTML (well PHP really) pages when the user elects to publish. These static pages, along with the other assets are ‘pushed’ live using RSync which copies them from one server to the other.

In addition to regular page content, there are other types of content such as ‘Collections’ that are used in the CMS and that need to be copied to the live server. A Collection is a list of structured data types, Collection Items, that are managed independently from page content. Collection Items have their own approval workflow, go-live dates etc. and can be bound to pages through the admin UI. Typically, Collections are used for News, Events, FAQ’s etc. but really any content type that can be modeled with a simple structure is a candidate.

Now up to last month I had stored published Collection Items in XML which was parsed at runtime on the live site (The XML would get conveniently pushed live with RSync along with the pages). With PHP 5’s improved XML support this was a reasonably performant solution and provided a basic storage mechanism for the structured data. But what if I had thousands of items in a Collection and wanted to perform a complex search to display the results over a few pages? Hmmmm. It was achievable with XML but was going to get tricky with XPath expressions and server resources would definitely suffer when parsing the XML and sorting arrays of data. I needed another way.

Enter SQLite! This database engine is embedded into PHP5, and was the answer to my woes. SQLite databases require no setup, passwords and are nothing more than regular files so they play very nicely with the RSync deployment scheme I use. On top of that since the vast majority of SQL can be used to query SQLite databases, searching and paging of results was going to be a breeze. So I made a change to the CMS that saw published collection items going into a local database rather than the XML.

Using SQLite means that the CMS can effectively queue-up content ahead of a display date and expire content at some point in the future. What’s even better is that the published sites are still standalone in nature and do not need any knowledge of the CMS which created them.

O.k. so using SQLite is nothing groundbreaking but the application of it in this context made me stop thinking of a database as something at the bottom of a technology stack and as an portable and intelligent file format that can be shared between applications. Revelation!

If you’re planning a CMS then I recommend you look at SQLite for creating hybrid static/dynamic pages. It certainly opened some doors for me.

Disclaimer: Yes, I used the word ‘performant’ in this post.  Apparently it’s not a word but I like it. So Sue me.