Category Archives: Development

Entries relating to the technical construction and programming of the project

Flash on the beach 2009

FOTB 2009

I’m a great believer that organisations take on the personalities of their founders. This is certainly true of Flash on the beach, an annual gathering of creative and technical innovators from in and around the Flash community. John Davey, the events organiser, loves people. He’s big, he’s brash and he loves a party. And that’s exactly what you get with Flash on the beach.

Now in year four, it’s been going long enough that for regular attendees it has a real family atmosphere. This in turn gives the whole event an open and infectious creative vibe that I hope makes newcomers feel welcome. There is a lot of love for this event. You only have to run a quick Twitter search for the #FOTB tag to see for yourself.

This year I covered it for FlashMagazine along with my long term collaborator Jensa Brynildsen. With only two of us covering three streams it was a bit of a sprint but we have all the sessions written up now. I won’t duplicate the content but here are the links if you’d like to find out more.

Adobe Flash CS5 Sneak Peaks from FOTB 2009
Flash on the beach – Day 1
Flash on the beach – Day 2
Flash on the beach – Day 3

And finally for a flavour of the event here is a short video I took of Andre Michelle’s Flash Audio DSP session.

Thanks again to everyone who came along – it’s the people that makes this event so special.

Searching the Digg API with AS3

I’ve been messing around with a lot of social API’s recently. Most of the common ones have their own AS3 wrappers although often these are authored by someone else. The diggflashdevkit for the Digg API for example is written by the guys over at Stamen who, as I’m sure you’re aware, have got some game.

It’s a nicely architected framework with cleanly separated model and service classes. Calls to Digg are proxied through the class. This contains methods for all the API calls except strangely for SearchStories. It could be I’ve missed something but I gave up looking and wrote a method for it. Just add this function to the API class and call it as you would any other method.

public static function searchStories( query: String ):StoriesResponse
	var request:URLRequest = new URLRequest(getURL('search/stories'));
	var args:URLVariables = new URLVariables()
	args['query'] = query
	if (mediaSize)
		if (!args['size']) args['size'] = mediaSize;
	} = args;
	return load(request, new StoriesResponse()) as StoriesResponse;

Will Flash for cash


Well I had “the conversation” this morning and it looks like my employer will be making a big round of redundancies next week. I don’t tend to talk about work here (this is the home of my personal projects)  but this is a the big one so forgive me this once.

If anyone is in need of an experienced Flash developer in the London or Brighton area then please get in touch. My email is john at this domain. I have a new portfolio of work and cvs are available on request.

Minkowski Spacetime

Herman Minkowski

“The views of space and time which I wish to lay before you have sprung from the soil of experimental physics, and therein lies their strength. They are radical. Henceforth space by itself, and time by itself, are doomed to fade away into mere shadows, and only a kind of union of the two will preserve an independent reality.”

Hermann Minkowski, 01809

Time and Space
In the previous post I surmised that current temporal standards offer poor support for historical data. I also know that modelling time at deep timescales is going to throw up some new problems. The thing is, once you start messing around with time outside of historical systems like calendars you run into another dirty little secret. Time and space are related. We’ve known this for over a hundred years but temporal specs are all geared towards events in the short now, so fiddly little problems like relativity are conveniently ignored.

Even if I ignored relativity, I can’t ignore space. Recent temporal innovations like daylight saving time and the timezone system are all local modifiers based on spatial coordinates. What I find odd is that I haven’t encountered a single specification that tries to treats time and space equally.

Hermann Minkowski
The German mathematician Hermann Minkowski (1869 – 1909) was the first to formalise the notion that space and time are not separate. He proposed that the best way to understand Einstein’s special theory of relativity was to use a 4 dimensional space he called spacetime. It’s often referred to as Minkowski spacetime to differentiate it from a slew of other modern multi-dimensional theories.

Getting your head around the ideas of relativity and spacetime isn’t as hard as you might expect. I found some great articles here that walk you through all the concepts using simple examples. Getting my head around the mathematics of spacetime is another thing entirely!

Minkowski image via AIP Emilio Serge Visual Archives


'The ancient of days' by William Blake, 01794

Getting external data into Herodotus is an important part of the project. Data can be encoded in a wide array of formats and they all have to be parsed into Actionscript Value Objects. I’ve yet to define the metadata for these VOs so in an effort to find some commonality I spent much of the last few months digging through a mountain of   temporal specifications, projects and APIs. It’s been hard work and a journey peppered with surprises and revelations. Over this and the next two posts I hope to cover some of what I’ve learned and how this has shaped my semantic model of time.

The semantics of time
The properties of time are elusive. It’s a fundamental concept with a myriad of definitions, each dependent upon the experiences and requirements of the individual or group who defines it. Disciplines as diverse as physics, chemistry, biology, astronomy, theology, philosophy, history, music and politics have all had a hand in shaping our definitions of time.

It’s fascinating to watch different people approach the same problem. Some attempts make you want to scream “oi, no!”, and others have you immediately reaching for your notebooks; throwing out old ideas in favour of new, each revelation informing your overall understanding of the problem.

The fundamentals and architecture of time require some deep thought and on the whole this is evident in the specifications I looked at. The introduction to the ISO8601 specification gives a good introduction to the basic temporal concepts of a Timeline, an Instant and an Interval. The Time ontology in OWL describes them in a little more detail. These three concepts seem to be universally applied or at least implied in all of the specs I looked at.

Old Father Time: ISO8601
In a review of Temporal Web Standards I showed that almost all web standards for DateTime have their roots in the ISO8601 specification. This was great because it gives me the commonality I was looking for.

ISO 8601

Unfortunately this common ancestry throws up another problem, but before I get into that it’s worth noting the main innovations to take from ISO8601:

  • Dates are human readable.
  • Dates are stored internally in UTC and converted to local time as required.

When date and time are represented as strings they are formatted in order of granularity, from largest to smallest. This offers the following advantages:

  • Dates are language neutral.
  • Dates are unambiguous.
  • Dates are machine sortable.

Julian 1.1
Now for the bad news. ISO8601 models our modern civil “Gregorian” calendar. Introduced in the Inter gravissimas papal bull by Pope Gregory XIII this system of measuring time reformed the earlier Julian calendar. The difference between the two calendars is small – only a slight change to the leap year rule to correct the drifting date of Easter. In software terms the Gregorian calendar would be considered a patch: it’s Julian 1.1.

The problem of dating historical events with ISO8601 is really one of practicality. The reform came into effect, in Catholic countries at least, in 1582. The thing is (rather obviously) a lot of history happened before then. These sorts of dating problems aren’t new to historians but the conversion to Gregorian, and often back again, can be non trivial.

For example, meet Tom. Tom is a historian studying the French Revolution. He has found a date on a document that uses the short-lived put completely wonderful French Republican calendar. The FRC was a metric calendar (10 days in a week, 10 hours in a day etc.) adopted very briefly alongside the rest of the metric system. If Tom wanted to store information on the web about this document he would have to convert the date from French Republican to Gregorian.

The Proleptic Gregorian Calendar
The common response of spec writers to the problem of historical dating is to use the proleptic Gregorian calendar. A proleptic calendar is one in which the calendar rules are extended backwards in time before when the calendar was introduced. Now this sounds like a great idea until you actually try and use it.

Meet Tom again. This time he is studying the life of Julius Caesar. Caesar was born when one of many permutations of the Roman calendar was in effect, and he died two years into the counting of his eponymous Julian calendar. Dates in his life require conversion from at least two different calendar systems into the proleptic Gregorian. Just to add to the complexity all of those dates are considered BC in the Julian/Gregorian calendars. While most implementations of proleptic Gregorian (including ECMAScript) happily count zero and on into negative numbers, the proper BC/AD (or BCE/CE if you prefer) system doesn’t count a year zero. 1AD is preceded by 1BC. Conversions like this are complex and error-prone. I really don’t think the proleptic Gregorian is a very practical storage solution.

As if I haven’t rammed the point home enough then consider a further example. Meet Dick, he’s a geologist studying the Cretaceous Tertiary boundary. What is 65.5 million years ago in Gregorian? It’s all a bit fuzzy. Don’t even bother asking Harry the cosmologist.

The revelation
Once you realise there is no practical support for historical events prior to 1582 it quickly becomes obvious why we don’t yet have a deep-zoom for history. No online support = no online data. To pull this off I need a model of time (and space, but I’ll get into that later) that goes back beyond the common Gregorian calendar and in fact beyond any calendar into the timescales of geology and cosmology.

Project updates April 2009

OKCon Talis

Open Knowledge Conference 2009
A few weekends ago I gave a short talk about The Computus Engine at the Open Knowledge Conference in London. It was interesting to attend a con outside of the usual Flash circuit, and with Open Knowledge being so ‘em… open, it meant there was a wide range of topics under discussion. I missed the first part of the day but in the afternoon we were treated to everything from open source fashion (image below), to aid work in Africa, to the intricacies of semantic markup.

OKCon fashion

The open philosophy is applied to the con as well as the subject matter. Much like BarCamp, speaking slots can be added to the schedule by audience members. Fitting everything in meant I rattled through mine at breakneck pace but I think I got my points across. I’ve submitted the slides to Jonathan Gray at The Open Knowledge Foundation and I’m told they have audio as well. If they put them up online I’ll post a link.

New class documentation
I finally got round to configuring ASDoc (the Actionscript class documentation generator) in FlexBuilder. It’s notoriously painful to configure but thanks to my friend Seb for publishing his efforts it gave me enough clues to get mine up and running. Since then I’ve worked my way through the current set of classes and marked them all up. Taking another tip from the PV3D team I’m checking the docs into the repo alongside the code so they’ll always be in sync with the codebase.

GoogleCode repo updates
Yesterday I checked in a stack of updates to the Computus Engine repo on GoogleCode. In addition to the ASDoc markup and docs directory you’ll also find updated examples for the Animated Main Preloader and the Timekeeper. The preloader now has a fix to resolve the problem of it stalling if the SWF is already cached.

More importantly I’ve made a change to the Timekeeper API. I’ve replaced a number of methods with single properties to reduce the complexity of the API. The affected methods are:

value:Number replaces getValue() and setValue()

tickDuration:Number replaces getTickDuration() and setTickDuration()

tickFrequency:int replaces getTickFrequency() and setTickFrequency()

I don’t like changing a live API but I think these changes are sensible and greatly simplify things. The Timekeeper test example has been updated to use the new API.

A S.T.A.R. is born
Eagle eyed visitors will also spot a new set of unit tests and util directory called star. More about this in a forthcoming post!

Hacking the Date class for GeoLocation

The demo above attempts to locate your current position on the earth. I can’t take any credit for the 3D stuff as I based it on Andy Zupko’s great post about Geolocation in Papervision3D. My little contribution is the code below. This takes the humble Date class and does some reverse engineering on it to derive your approximate location on the earth. First the code, then I’ll explain how it works…

// Estimate Latitide and Longitude from the Date class.
var latitude:Number
var longitude:Number
var now:Date = new Date()
var northernWinter:Date = new Date( 2000, 0, 1 )
var northernSummer:Date = new Date( 2000, 6, 1 )
var northernWinterOffset:Number = northernWinter.timezoneOffset
var northernSummerOffset:Number = northernSummer.timezoneOffset
// Find just the Timezone modifier TZD (in minutes).
// DST modifier is negative so TZD is the larger value.
var tzd:Number = Math.max( northernWinterOffset, northernSummerOffset )
// if you need the current value of DST (in minutes) it's...
var dst:Number = now.timezoneOffset - tzd
// Estimate Longitude:
// 60 minutes of time == 15 degrees of longitude.
longitude = tzd / -4
// Estimate Latitude:
// If DST is adopted we can detect the current season and from that we can find the hemisphere. If not assume equatorial.
if ( northernWinterOffset == northernSummerOffset )
	// equatorial
	latitude = 0
	else if ( northernWinterOffset > northernSummerOffset )
	// northern hemisphere
	latitude = 45
	// southern hemisphere
	latitude = -45
// and the estimates are...
trace( "Longitude: " + longitude )
trace( "Latitude: " + latitude )

Last year I wrote a series of posts that looked Inside the AS3 Date class. One of the gotchas I mentioned was the confusingly named .timezoneOffset property which is actually comprised of two offsets: timezone designation (TZD) and Daylight Saving Time (DST). In the article I showed some code that split these values back out again. Well it struck me the other day that you can use these values to approximate a users position on the earth. The cool thing about this hack is that it relies solely on understanding the mechanics of timezones and daylight saving, so itl will work just as well in Javascript as it does in AS2 or AS3.

If you follow the code above you’ll see the first thing we do is split out TZD and DST. Once you have these values you can make some estimates about latitude and longitude.

TZD == Longitude
The earth rotates once on it’s axis each day so that’s 360° in 24 hours, or 15° of longitude every hour. So if we know a user’s TZD we can estimate their longitude (east/west) to within about 15°. In reality timezone boundaries are a little wobbly so I’d gave or take another 15°.

DST == Latitude
Using DST to estimate latitude is really inaccurate but if you need to know then this way is better than nothing – here’s the theory anyway. As a general rule Daylight Saving Time is adopted by countries with temperate climates. Employing it nearer the poles is pointless and the last thing you need at the equator is more sunshine. In the code above we created a summer and a winter date. By comparing these we can tell if the user’s current location employs DST and if it is currently in effect.

There are plenty of special cases for DST (don’t get me started on that) but if no DST offset exists in summer or winter then the user is probably within the equatorial band. If DST exists but is not in effect then that hemisphere is in winter, and the opposite hemisphere is in summer. A quick check against the current date will tell you which hemisphere that temporal band is in.

Caveat Emptor
So there you go, GeoLocation using just the Date class. I’m the first to admit that determining latitude is really inaccurate so if you need to know for sure then use server side IP Location. If accuracy is less important then this method is small, self contained and works in AS3, AS2 and Javascript. One last piece of trivia before I finish up; although I said employing Daylight Saving Time near the poles is largely pointless, it turns out that for reasons of synchronicity most Antarctic survey stations follow the DST rules for their home country.

A review of Temporal Web Standards

The semantics of time have been defined by just about every standards body you can shake an egg timer at. Even within the internet space you will find overlapping definitions and specifications from ISO, ECMA, IMC, W3C, IETF and the Dublin Core Metadata Initiative. And that’s without getting into individual language APIs, frameworks and data models. Oh yeah and just for kicks, some standards contain their own temporal entities and definitions.

ISO 8601
This is the grandaddy of all temporal web standards and you’ll find it referred to in every other specification. Originally released in 1988, ISO8601 defines a range of textual formats for the interchange of dates, times and time periods.

For all it’s ubiquity, it is not without it’s problems: parametrization can be a little loose. For example it’ll accept hour values between 0 and 24, and early versions were comfortable with the dropping of centuries from year definitions.

In reality no-one implements all of ISO8601 – it’s just too loose to be practical. What happens is, a standards body defines a subset (or “profile”) of the full standard, and sometimes another standard will include or be based upon a child standard. The diagram below shows the ISO8601 family tree of adoption.

ISO 8601

For an overview of the various formats check out HackCraft’s Date and Time Formats on the web.


When the W3C came to define their date and time standards they very sensibly choose to adopt a profile of ISO 8601. Favouring reliability over flexibility, they achieve this by enforcing a stricter simplified subset of ISO 8601.

The W3C’s specification for RDF semantics contains a recommended XML datatype for date time: xsd:dateTime. This is also a profile of ISO 8601 and can be use to express a W3C-DTF in the XML format.

The Internet Engineering Task Force took a similar approach when defining RFC 3339 Date and Time on the Internet: Timestamps. This standard enforces a subset of W3C-DTF and is consequently the simplest of the three formats.

It’s worth noting therefore that any date conformant with RFC 3339 will also be valid in W3C-DTF and ISO 8601. This was the primary reason for adopting it as the date time format for Atom syndication. Talking of syndication, beware of the older RSS specification which uses the same archaic datetime format used by email and HTTP. You can find this specified in RFC 822 and modified in 1989 by RFC 123 to enforce four digit years.

Calendaring and Scheduling

The original internet calendaring standard was vCalendar. This and vCard were co-developed initially by Apple, AT&T, IBM, and Siemens, before being passed to the Internet Mail Consortium in 1996. This textual format can contain temporal and descriptive data about an event or task.

iCalendar ( RFC 2445 )
In many respects iCalendar can be considered vCalendar 2.0. It supports all the features of vCalendar and has a similar textual structure. The advantage of using iCalendar over it’s predecessor is that you can also exchange journal entries and information about the free-busy status of an entity.

This is a microformat implementation of iCalendar. Microformats are small XML documents that can be easily embedded, read and exchanged across the web. The microformat datetime-design-pattern page hosts an interesting discussion about the need for a machine and human readable date time format.

This is a proposed XML implementation of iCalendar.

RDF Calendar
This is a proposed RDF implementation of iCalendar.

Client side language specifications

There is currently no support for temporal elements in HTML, but one of the proposals in HTML 5 is for a time element. This would support dates and times in the Gregorian calendar as well as timezones.

ECMA 262 v3 (Javascript and Actionscript)
This is the standard that Actionscript and Javascript are derived from. The Date class is an implementation of the Gregorian calendar and although it models UTC, leap seconds are ignored. Some of these issues are under review and proposals are in motion to make changes in version 3.1 and version 4.0.

Projects update March 2009

I’ve made a few changes and updates to the site over the last few weeks. I thought it might be worth posting a quick update.

Da Vinci
This project now has it’s own page and the BaseComponent class is checked into the repo. I’ve made a couple of updates to the code since the ahem, “finished” version I posted a few months back. Firstly I’ve added Grant Skinner’s EventDispatcher optimization. And the second is a workaround for a weird bug in the Flash Player.

It turns out that a stage resize can fire the ADD_TO_STAGE Event twice. This causes the BaseComponent init() to be called twice. I didn’t notice it when working with components on the Flash timeline but it becomes really obvious if you use it on an Actionscript only project in FlexBuilder. The fix is to remove the listener after the first event is fired.

This project also has it’s own page and the Timekeeper class is in the repo now as well. I’ve built a new combined example to go along with it. If you’re interested in music sequencing you might like to check out Studio Anuirin’s remixed version of the Timekeeper class.

This is the current project I’m working on. The first two base classes are built and they happily pass all the unit tests I can throw at them. Although it’s early days for this one I’m inclined to open it up as soon as possible to get some feedback. I’ll put a proper post together about it soon.

Big History

Big History books

When I came up with the fanciful notion of an interactive timeline that stretches back as far as the Big Bang I thought I was onto something exciting and new. The problem with new ideas these days though, is that you’re only one quick web search away from the realisation that they are anything but.

Although I think the interactive visualisation aspect is still new, it turns out that the unified (multi-disciplinary) approach to history has been around for about 25 years. The study of Big History attempts to combine the timescales of cosmology, geology, paleontology, archeology and history into a single unified timeline. As we have more detailed information about events closer to the present, the result is a naturally logarithmic timeline.

Big History courses have been taught in Australia and the US and David Christian’s excellent lecture series is available from the Learning Company. The information and insights contained in these books are going to be invaluable for structuring periodization for Herodotus.