mrspeaker's head in a monitorYou find yourself at the entrance to the Hompage of Mr Speaker. In a darkened corner sits a trunk containing HTML5 games and some JavaScript tidbits. In a dark corner you spy a Twitter account. Exits are North, East, and .

?> _


THIS IS WHERE YOUR DEMO GOES is my aborted attempt for this year's js1k competition. It uses the browser's speechSynthesis capabilities along with some Web Audio API drones to make a lovely bedtime song...

I don't think I'll get it squashed to < 1k in the next few days though, so plopping it up here for posterity. The source is buried in the middle of the js1k shim somewhere. Just search for "THIS IS WHERE YOUR DEMO GOES".

The elusive Pinterest App Link handler

App Links seem like a perdy good idea: trying to bring back a bit of the web to walled garden-ed applications. Of course, the issue is it's up to the individual app developers to support them. And it seems that the big social sites are quite fond of not making things more open. Also, they like to break stuff that was working before.

The tl;dr is the old Pinterest protocol handler for opening the app was pinit12, now it's pinterestsdk.v1. Previously, to create a pin you'd use pinit12://pin/create/bookmarklet/ now you use pinterestsdk.v1://pinit/. I haven't tested it out completely, because I got really bored of the limitless hell that is "sharing to social networks" - but it opens up the app and looks like it works (I added the info.plist settings from the SDK docs - though they probably shouldn't be necessary).

I found the handler thanks to an error message that popped-up in a stack trace. It eventually lead me to PDKPin.m which contained the following lumps of gold:

static NSString * const kPDKPinterestAppPinItURLString = @"pinterestsdk.v1://pinit/";
NSURL *pinitURL = [NSURL URLWithString:[NSString stringWithFormat:@"%@?%@", kPDKPinterestAppPinItURLString, [params _PDK_queryStringValue]]];
    if ([[UIApplication sharedApplication] canOpenURL:pinitURL]) {
        [[UIApplication sharedApplication] openURL:pinitURL];
    } else {
        //open web pinit url
        NSDictionary *webParams = @{@"url": [sourceURL absoluteString],
                                    @"media": [imageURL absoluteString],
                                    @"description": pinDescription};
        NSURL *pinitWebURL = [NSURL URLWithString:[NSString stringWithFormat:@"%@?%@", kPDKPinterestWebPinItURLString, [webParams _PDK_queryStringValue]]];
        [[UIApplication sharedApplication] openURL:pinitWebURL];

Hopefully this is useful to fellow tired and weary social-sharing-integration souls wandering the wastelands of terrible SDKs and out-of-date documentation (including, most likely, this blog post). God speed.

Code-golfing the BASICs

Moments of genius: they strike me once ever 9 years, apparently. The last one happened when I realised how to correct distribute beers - this one happened when I figured out how to shave 4 bytes off the perennial BASIC classic...

20 GOTO 10

Applying my Mr Speaker's Stroke-of-genius 2015:

20 RUN

I deserve a correctly-distributed beer for that one.

British Pathé random video viewer

British Pathé recently released 90,000 videos on to YouTube (though I could only find 82058 of them) - I wanted to make some kind of mashup art with it, but was not creative enough to think of anything interesting. So, instead I present: Random video player! Randomly (and pretty-much-endlessly) play through the collection, marveling at the wonders of the not-so distant past.

If you want to play with the code, check out the repo... it's an ES6 React app, that uses RxJS to create and consume a stream of video ids based on button clicks & pop state events.

Functions as RxJS Subjects

Here's a nifty trick if you're using RxJS, and want to subscribe to plain ol' function invocation. This is especially useful if you want to use React, and don't want to bind with Rx.Observable.fromEvent with standard DOM event listeners.

import Rx from 'rx';

const RxFuncSubject = () => {
  const subject = Object.assign(
    (...args) => subject.onNext(...args),

  return subject;

export default RxFuncSubject;

We create a regular function that we extend with both Rx.Observable and Rx.Subject (you need to mix in Rx.Observable as this is extended by Rx.Subject internally).

The function passes its arguments along to the internal onNext function: so it can be called as a regular function but still act like a Subject:

const clicker = RxFuncSubject();
clicker.subscribe(() => console.log('clicked!'));
clicker(); // clicked!

Now it can be used in a normal React component, wherever a function call would be expected!

<MyComponent onClick={clicker} />

Five short years

On Friday, October 22, 2010 I conducted a scientific experiment: if one URL shortener can make a URL shorter, then fifteen URL shorteners can make it reaaaally short. The results were quite as you'd expect: the resulting link was longer than source, and browsers would go into convolutions trying to resolve the chain of shortened shorteners.

2010 was a big year for people who thought it would be a good idea to make smaller URLs. All it took was a rudimentary knowledge of a hash map and an hour of coding and suddenly you had a viable startup on your hands. There are a lot of URLs out there, so the thinking went, and people need a place to make them shorter. Phase 1: Shorten URLs...

So now it's 5 years later, and I thought it would be interesting to see what become of that unraveling chain of hopes and dreams. Here they are, in reverese order of resolve-y-ness:

  1. ALIVE. Correctly resolves to
  2. ALIVE. Correctly resolves to
  3. ALIVE. Correctly resolves to
  4. Service: ? Link: DEAD. I'm not even sure how this one ever worked!
  5. DEAD. Domain squatter-ed
  6. ALIVE. "The internet's first and only sex-positive url shortener".
  7. ALIVE "Free short URLS since 1999"
  8. Service: ALIVE Link: DEAD. This looks reasonable though: "Link Disabled because of T&C violation".
  9. DEAD. Domain squatter-ed
  10. DEAD. "Wurl Redirection Service is permanently closed."
  11. DEAD. Domain squatter-ed
  12. ALIVE. "Snippety snip snip". Whatever that means.
  13. DEAD. Redirects link to a 404.
  14. DEAD. Domain squatter-ed. Also, my office router warns "Gateway BOTNET Filter Alert".
  15. ALIVE. Resolves correctly, but the service has a lovely broken image gif as a logo now.

I was quite impressed to discover that 8 out 15 still resolve the links correctly (counting the T&C violation). That means that only around half of world's shortened URLs now 404: much better than I thought! I'll revisit this post in 2020, so be sure to come back then to see how it goes - just keeping this handy 8x shortened link lying around. I've run it through all the remaining contenders, so I see no reason it won't resolve in another 5 years.