I’ve been working with Andrew Nagi to put together a new (much improved) version of timeliner-maker.com. It’s an app that allows you to make timelines, including what we hope is a handy auto-suggest feature.
It’s been a chance to have a play with a few interesting bits of tech.
We turned to Freebase‘s API to allow users to automatically add the dates of events. It uses their auto-suggest JS library and some custom code to work out the dates. For example, if you type in “Albert Ei” it will auto-suggest “Albert Einstein”. If you click on his name, it will automatically add his lifespan to your timeline, including his Wikipedia intro if it’s available. The quality of the data is hit and miss. Generally, while people are well covered, events are less likely to have accurate dates.
We also used MIT’s Simile library which library does a lot of the heavy lifting of display a scrolling timeline, which is vastly more complex than you might expect if you haven’t tried getting a computer to represent human readable dates. Which leads me to…
If you didn’t already know that it’s famously difficult to make computers work with dates, a few moments of reflection make it obvious. Leap years, timezones, irregular numbers of days in the month are easily foreseeable landmines. Here are some of our favorite nuggets:
- The Georgian calendar was only introduced in 1582, meaning that dates before this time can either be indicated by using the previous Julian calendar or by dating the Georgian calendar backwards (the Proleptic Georgian calendar) . This is similar to the phenomena of Russia’s October Revolution happening in November, depending on which calendar you want to use. The two calendars disagree about leap years so they slowly run out of sync with each other.
- In the Georgian and Julian calendar there is no year zero.
- Time in computers is very often calculated in seconds since 1970. Makes sense, because there weren’t many computers before 1970. However, for dates after 2032 or before the 20th century, the number of seconds becomes so large that PHP loses the ability to understand the number.
- For more mind-bending complexity, check this out, or even this.
Ruby on Rails
The Ruby on Rails app development framework hardly needs more commentary, I’ll just mention a couple of observations. It’s very instructive to have a look at the Rails approach to making web apps, everyone agrees it’s an elegant structure. Rails is great at making app development beautiful, or at least enforcing good structure. It also removes a lot of the repetitive tasks that waste time when you develop apps without a framework. But I don’t think anyone can honestly say that it makes development easy. Ruby is a hard language to understand, Rails does a lot of magic that makes understanding it even harder. You don’t often see this fact reported, I guess because it impugns the programming skill of the writer. Rails might make the best of expensive developer time by letting those programmers work as quickly as possible, but it does nothing to lower the level of experience required to be an app developer. Nor is exclusively a matter of experience – this note from O’Reilly is an interesting insight.