As each door is opened, a different part of a (distinctly-Bodleian/Oxford) winter scene unfolds, complete with an array of fascinating characters connected to the history, tradition, mythology and literature of the area. It’s pretty cool, and you should give it a go.
If you want to make one of your own – for next year, presumably, unless you’ve an inclination to count-down in this fashion to something else that you’re celebrating 25 days hence – I’ve shared a version of the code that you can adapt for yourself.
Features that make this implementation a good starting point if you want to make your own digital advent calendar include:
Secure: your server’s clock dictates which doors are eligible to be opened, and only content legitimately visible on a given date can be obtained (no path-traversal, URL-guessing, or traffic inspection holes).
Responsive: calendar adapts all the way down to tiny mobiles and all the way up to 4K fullscreen along with optimised images for key resolutions.
Debuggable: a password-protected debug mode makes it easy for you to test, even on a production server, without exposing the secret messages behind each door.
Expandable: lots of scope for the future, e.g. a progressive web app version that you can keep “on you” and which notifies you when a new door’s ready to be opened, was one of the things I’d hoped to add in time for this year but didn’t quite get around to.
What I’d prefer would be to be able to write my logs here, on my own blog, and for my content to by syndicated via some process into the logging systems of the various silo sites I prefer. This approach is called POSSE – Publish on Own Site, Syndicate Elsewhere. In addition to the widely-described benefits of this syndication strategy, such a system would also make it possible for me to:
write single posts that represent the same location published on multiple silos (e.g. a visit to a geocache published on two different listing sites [e.g. 1, 2])
Applying such an tool would require some work as different silos have different acceptable content rules (geocaching.com, for example, effectively forbids mention of the existence of other geocache listing sites), but that’d theoretically be workable.
Unfortunately, content rules aren’t the only factor making PESOS – writing content into each silo and then copying it to my blog – preferable to POSSE. There’s also:
Not all of the silos offer suitable (published) APIs, and where they do, the APIs are all distinctly different.
Geocaching.com specifically forbids the use of unapproved automated robots to access the site (and almost certainly wouldn’t approve the kind of tool that would be ideal).
The siloed services are well-supported by official and third-party apps with medium-specific logic which make them the best existing way to produce logs.
Needless to say: as much as I’d have loved to POSSE my geo* logs, PESOS will do.
The second part of the plugin takes this data and creates a new draft post. My plugin is pretty opinionated on this part because it’s geared strongly towards my use-case, so if you want to use it yourself you’ll probably want to tweak the code a little (e.g. it applies specific tags and names metadata fields a particular way).
It’s not fully-automated and it’s not POSSE,but it’s “good enough” and it’s enabled me to synchronise all of my cache logs to my blog. I’ve plans to extend it to support other GPS game services to streamline my de-siloisation even further.
The OpenStreetMap project consists of raw map data, collected and aggregated by thousands of users. This tutorial covers the configuration and maintenance of a web service using Open Source Routing Machine (OSRM), which is based on the OpenStreetMap d
The OpenStreetMap project consists of raw map data, collected and aggregated by thousands of users. However, its open access policy sparked a number of collateral projects, which collectively cover many of the features typically offered by commercial mapping services.
The most obvious advantage in using OpenStreetMap-based software over a commercial solution is economical convenience, because OpenStreetMap comes as free (both as in beer and as in speech) software. The downside is that it takes a little configuration in order to setup a working web service.
This tutorial covers the configuration and maintenance of a web service which can answer questions such as:
What is the closest street to a given pair of coordinates?
What’s the best way to get from point A to point B?
How long does it take to get from point A to point B with a car, or by foot?
The software that makes this possible is an open-source project called Open Source Routing Machine (OSRM), which is based on the OpenStreetMap data. Functionalities to embed OpenStreetMaps in Web pages are already provided out-of-the-box by APIs such as OpenLayers.
While slightly dated, I found this guide to be really valuable in my effort to set up a server that could spit out fastest walking routes around Oxford to support a PWA-driven tour of places relevant to J. R. R. Tolkien’s life, at my “day job”.
Just want to play my game without reading this whole post? Play the game here – press a key, mouse button, or touch the screen to fire the thrusters, and try to land at less than 4 m/s with as much fuel left over as possible.
In 1969, when all the nerds were still excited by sending humans to the moon instead of flinging cars around the sun, the hottest video game was Rocket (or Lunar) for the PDP-8. Originally implemented in FOCAL by high school student Jim Storer and soon afterwards ported to BASIC (the other dominant language to come as standard with microcomputers), Rocket became the precursor to an entire genre of video games called “Lunar Lander games“.
The aim of these games was to land a spacecraft on the moon or similar body by controlling the thrust (and in some advanced versions, the rotation) of the engine. The spacecraft begins in freefall towards the surface and will accelerate under gravity: this can be counteracted with thrust, but engaging the engine burns through the player’s limited supply of fuel. Furthermore, using fuel lowers the total mass of the vessel (a large proportion of the mass of the Apollo landers was fuel for use in the descent stage) which reduces its inertia, giving the engine more “kick” which must be compensated for during the critical final stages. It sounds dry and maths-y, but I promise that graphical versions can usually be played entirely “by eye”.
Let’s fast-forward a little. In 1997 I enrolled to do my A-levels at what was then called Preston College, where my Computing tutor was a chap called Kevin Geldard: you can see him at 49 seconds into this hilariously low-fi video which I guess must have been originally shot on VHS despite being uploaded to YouTube in 2009. He’s an interesting chap in his own right whose contributions to my career in computing deserve their own blog post, but for the time being all you need to know is that he was the kind of geek who, like me, writes software “for fun” more often than not. Kevin owned a Psion 3 palmtop – part of a series of devices with which I also have a long history and interest – and he taught himself to program OPL by reimplementing a favourite game of his younger years on it: his take on the classic mid-70s-style graphical Lunar Lander.
My A-level computing class consisted of a competitive group of geeky lads, and we made sort-of a personal extracurricular challenge to ourselves of re-implementing Kevin’s take on Lunar Lander using Turbo Pascal, the primary language in which our class was taught. Many hours out-of-class were spent in the computer lab, tweaking and comparing our various implementations (with only ocassional breaks to play Spacy, CivNet, or my adaptation of LORD2): later, some of us would extend our competition by going on to re-re-implement in Delphi, Visual Basic, or Java, or by adding additional levels relating to orbital rendezvous or landing on other planetary bodies. I was quite proud of mine at the time: it was highly-playable, fun, and – at least on your first few goes – moderately challenging.
Always game to try old new things, and ocassionally finding time between the many things that I do to code, I decided to expand upon my recently-discovered interest in canvas coding to bring back my extracurricular Lunar Lander game of two decades ago in a modern format. My goals were:
A one-button version of a classic “straight descent only” lunar lander game (unlike my 1997 version, which had 10 engine power levels, this remake has just “on” and “off”)
An implementation based initially on real physics (although not necessarily graphically to scale)… and then adapted as necessary to give a fun/playability balance that feels good
Adapts gracefully to any device, screen resolution, and orientation with graceful degredation/progressive enhancement
You can have a go at my game right here in your web browser! The aim is to reach the ground travelling at a velocity of no more than 4 m/s with the maximum amount of fuel left over: this, if anything, is your “score”. My record is 52% of fuel remaining, but honestly anything in the 40%+ range is very good. Touch the screen (if it’s a touchscreen) or press a mouse button or any key to engage your thrusters and slow your descent.
And of course it’s all open-source, so you’re more than welcome to take it, rip it apart, learn from it, or make something better out of it.
This will be the first time I’ve ever written an On This Day post where I haven’t been able to link back to a blog post that I actually wrote in the year in question. That’s because, in 2002, I was “between blogs”: the only thing I wrote about online that I still have a copy of was the imminent re-launch of AvAngel.com, my vanity site at the time. In that post, however, I did mention that I’d re-written my CV, which was relevant to what was going on in my life in March 2002…
On this day in 2002, I first began working for SmartData, my primary employer for the last nine years. A few months earlier, Reb – my girlfriend whom I’d moved in with in 2001 – and I had broken up, and I’d recently found the opportunity to visit Aberystwyth and visit friends there (the trip during which I first met Claire, although we didn’t get together until a little later). On that same trip to Aber, I also met Simon, who at that point had recently accepted a voluntary redundancy from the Rural Studies department of the University and was getting started with the launch of his software company, SmartData. He’d recently landed a contract with the National Dairy Farm Assured Scheme and needed an extra pair of hands on board to help out with it.
Sorting out premises was coming along somewhat slower than he’d planned, though. As part of the SpinOut Wales scheme, SmartData had been offered cheap accommodation in a University-owned building, but they were dragging their feet with the paperwork. On our first day working together, Simon and I crammed into his tiny home office, shoulder-to-shoulder, to hack code together. The arrangement didn’t last long before we got sick of it, and we “moved in” to the room (that would eventually be legitimately ours) at Peithyll, a former farmhouse in the village of Capel Dewi, near Aberystwyth.
Over the last nine years since, as the company has grown, I’ve always felt like a core part of it, shaping it’s direction. As we transitioned from developing primarily desktop applications to primarily web-based applications, and as we switched from mostly proprietary technologies to mostly open-source technologies, I was pointing the way. By working with a wide variety of different clients, I’ve learned a great deal about a number of different sectors that I’d never dreamed I’d come into contact with: farm assurance schemes, legal processes, genetic testing, human resource allocation, cinema and theatre, and more. It’s been a wonderfully broad and interesting experience.
When I began making plans to move to Oxford, I initially anticipated that I’d need to find work over here. But Simon stressed that my presence was important to SmartData, and offered to allow me to work remotely, from home, which is most of what I’ve been doing for the last year or so. Thanks to the miracles of modern technology, this has worked reasonably well: VoIP phones keep us in touch, tunneling and virtual networks allow us to work as if we were all in the same location, and webcams help us feel like we’re not quite so far from one another.
But this wasn’t to be a permanent solution: just a way to allow me to keep contributing to SmartData for as long as possible. Last week, I was offered and accepted a new job with a new employer, here in Oxford. Starting in April, I’ll be managing the administration and the ongoing development of the website of the Bodleian Libraries, the deposit library associated with Oxford University.
It’s a huge change, going from working as part of a tiny team in a West Wales town to working with hundreds of people at one of the largest employers in Oxford. I’ve no doubt that it’ll take some getting used to: for a start, I’m going to have to get into the habit of getting dressed before I go to work – something I could get away with while working from home and that might even have been tolerated in the office at SmartData, as long as I threw on a towel or something (in fact, I have on more than one occasion taken a shower in the SmartData offices, then sat at my desk, wrapped in towels, until I’d dried off a little).
This feels like a huge turning point in my life: a whole new chapter – or, perhaps the completion of the “turning a page” that moving to Oxford began. My new job is a brand new position, which provides an exciting opportunity to carve a Dan-shaped hole, and I’ll be working with some moderately-exciting technologies on some very exciting projects. I’m sure I’ll have more to say once I’m settled in, but for now I’ll just say “Squeee!” and be done with it.
Oh: and for those of you who follow such things, you’ll note that Matt P has just announced his new job, too. Although he’s a sloppy blogger: he’s actually been working there for a little while already.
This blog post is part of the On This Day series, in which Dan periodically looks back on years gone by.