Non Stop Hammer

You know how sometimes I make a thing and, in hindsight, it doesn’t make much sense? And at best, all it can be said to do is to make the Internet more fun and weird?

Hammer Logo

I give you:

Things that make it awesome:

  • Well, the obvious.
  • Vanilla Javascript.
  • CSS animations timed to every-other-beat.
  • Using an SVG stroke-dasharray as a progress bar.
  • Progressively-enhanced; in the worst case you just get to download the audio.
  • PWA-enhanced; install it to your mobile!
  • Open source!
  • Decentralised (available via the peer-web at dat:// / dat://0a4a8a..00/)
  • Accessible to screen readers, keyboard navigators, partially-sighted users, just about anybody.
  • Compatible with digital signage at my workplace…
Digital signage showing
My office aren’t sick of this… yet.

That is all.

Bodleian Advent Calendar

Hot on the tail of Pong, I wanted to share another mini-project I’ve developed for the Bodleian: this year’s digital advent calendar:

Bodleian 2018 digital advent calendar
If you look closely, you’ll find I’ve shown you a sneak-peek at some of what’s behind tomorrow’s door. Shh. Don’t tell our social media officer.

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.

Sample advent calendar
The open-source version doesn’t include the beautiful picture that the Bodleian’s does, so you’ll have to supply your own.

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.
  • Friendly: accepts clicks and touches, uses cookies to remember the current state so you don’t have to re-open doors you opened yesterday (unless you forgot to open one yesterday), “just works”.
  • 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.

I’ve no idea if it’s any use to anybody, but it’s available on GitHub if you want it.

Importing Geocaching Logs into WordPress


As an ocassional geocacher and geohasher, I’m encouraged to post logs describing my adventures, and each major provider wants me to post my logs into their silo (see e.g. my logs on, on, and on the geohashing wiki). But as a believer in the ideals behind the IndieWeb (since long before anybody said “IndieWeb”), I’m opposed to keeping the only copy of content that I produce in an environment controlled by somebody else (why?).

How do I reconcile this?

Wrist-mounted GPS in the snow.
Just another hundred metres to the cache, then it’s time to freeze my ass back to base.

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 amalgamating multiple locations (e.g. a geohashing expedition that included geocache finds) or,
  • 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 (, for example, effectively forbids mention of the existence of other geocache listing sites), but that’d theoretically be workable.

POSSE would involve posts being made first to my blog and then converted via some process into logs in each relevant silo
The ideal solution would be POSSE-based.

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.
  • 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.
PESOS would mean that posts were made "the usual way" to the silos and then a process duplicates them onto my blog
A PESOS-based solution is far easier to implement, in this case.

Needless to say: as much as I’d have loved to POSSE my geo* logs, PESOS will do.


My implementation is a WordPress plugin which does two things. The first is that it provides a Javascript bookmarklet and an accompanying dynamically-generated Javascript file (the former loads the latter) served from my blog’s domain. That Javascript file contains reference to every log already published to my blog, so that the Javascript code can deliberately omit these logs from any import. When executed on a log listing page like those linked above, it copies all of the details of that log into a form which submits them back to my blog, where it’s received by the second part of the plugin.

Geocache logs to WordPress importer seen running on
The import controls appear in a new, right-most column (GCVote is also visible running in my browser).

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).

Import plugin running on
When run on effectively the same interface is presented, even though the underlying mechanisms and data locations are different.

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.

And of course, I’ve open-sourced the whole thing. If it’s any use to you (probably in an adapted form), it’s all yours.

How To Set Up an OSRM Server on Ubuntu 14.04

This article is a repost promoting content originally published elsewhere. See more things Dan's reposted.

How To Set Up an OSRM Server on Ubuntu 14.04 | DigitalOcean (DigitalOcean)
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”.

Lunar Lander

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“.

Source code of Rocket and sample output.
Like many pieces of microcomputer software of the time, Rocket was distributed as printed source code that you’d need to carefully type in at the other end.

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”.

Atari's Lunar Lander (1979)
Atari’s 1979 adaptation is perhaps the classic version you’d recognise, although its release was somewhat overshadowed by their other vector-graphics space-themed release in 1979: Asteroids.

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.

Psion Series 3
I never owned a Psion Series 3 (pictured), but I bought a Series 5mx in early 2000 out of my second student loan cheque, ultimately wrote most of my undergraduate dissertation using it, and eventually sold it to a collector in about 2009 for almost as much as I originally paid for it. The 5mx was an amazing bit of kit. But I’ll blog about that another day, I guess.

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.

Dan's Lunar Lander (2018)
I sometimes wonder what it would have looked like if I’d have implemented my 1997 Lunar Lander today. So I did.

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
  • Runs in a standards-compliant browser without need for plugins: HTML5, Canvas, Javascript
  • 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.

End point of Dan's Lunar Lander (2018)
“Houston, the Eagle has landed.” Kerbal Space Program, it isn’t. Here’s a very good landing: 3 m/s with 48% of the fuel tank remaining.

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.

On This Day in 2002 (New Job!)

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, 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…

Looking Back

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.

The entrance to Peithyll, where SmartData established itself for much of the first six years of its life. It was quite a cycle to get out there every day, but in the summer it made for a great office: not many people can sit at their desk and watch red kites hunting outside, or go for a lunchtime walk up a hill with a picnic.

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.

Looking Forward

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.

My new office, right in the heart of Oxford. It looks a lot less green, and a lot more prestigious, than Peithyll.

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.