The title of this video won’t be exactly right.
It only updates every few minutes at most, and besides,
YouTube doesn’t update its view counts in real time anyway,
so don’t bother refreshing and refreshing and refreshing,
you won’t actually be able to see it ticking up second-by-second.
If it’s actually 100% spot-on,
it’s a miracle, but if it’s close,
then the code I’ve written is still working.
But at some point, that code will break,
and the title of this video will slip more and more out of touch with reality.
This is the story of how I made that changing title work,
why it used to be a lot easier to make things like that work,
and how all this ties in to the White Cliffs of Dover
and the end of the universe.
Now, I’m not going to talk about the exact details of my code here,
it is not the important part,
because code is just incredibly dull on camera.
But, big-picture, if you’re automating a job like that,
there are two main approaches you could take.
First: you could write something that pretends to be a human.
Not in some Blade Runner replicant way,
but you could run a system that loads up the YouTube video page,
reads the number of views, and then goes to the video manager,
changes the title, and hits save.
That’s actually not too tricky to do:
“screen-scrapers” have been built to do things like that for decades.
And that’s a fairly innocent use of a screen-scraper.
But if you can write code to change a title,
then you can also write code that signs up for loads of new accounts.
Or spams people. Or sends out messages trying to steal personal information.
That’s why you see those “I’m not a robot” checkboxes.
Which aren’t impossible to defeat, by any means,
but they make screen-scraping like that much, much, much, much, more difficult.
And, plus, it’s an approach that’ll break quickly:
every time one of the pages that’s being scraped gets redesigned,
you’ll have to rewrite your code.
But for a long time, the people who build web services like YouTube have recognised
that there are legitimate reasons for letting code interact with their systems.
Like pulling analytics data into a spreadsheet,
or letting captioning services add subtitles to videos quickly and automatically.
Or you might want to hook multiple web services together:
to automatically tweet when a new video goes up,
or ask your voice assistant to search for a playlist.
That can and should all be done with code.
So behind the scenes, nearly every major web service has an "API",
an Application Programming Interface.
It’s a way for bits of code to pass data and instructions
back and forth between services safely without having to deal with
all the complicated visual stuff that humans need.
So when I want my code to change a video title, I don’t ask it to open up a web browser.
Instead, it sends a single request to YouTube:
here’s the video ID, here’s the stuff to change,
here’s my credentials to prove that I’m allowed to do that.
Bundle that all up, send it over.
And YouTube sends back a single answer:
hopefully it’s a response code of 200, which means “OK”,
with confirmation of what the video’s data has changed to.
But if there’s some problem with that request, it’ll send back some other status number,
and an error message about what went wrong.
I can write code to handle those errors, or for something simple like this,
I can just have it fail and log it somewhere so I can deal with it later.
No typing, no clicking on things; no pretending to be a human.
One request out, one reply back.
At least, that’s how it’s meant to work.
This idea, that web services could interact with each other through code,
was amazing when it first became popular.
It became "Web 2.0",
a buzzword that is now more than fifteen years old.
And honestly, the Web 2.0 years were some of the most optimistic times on the web.
All these new startups were making sure they could interchange data with each other,
so maybe in the future,
you could see your friends’ Facebook statuses on your fridge!
Or lights could flash to warn you if your bus was arriving early!
The web would be all about data, and we could make all sorts of things of our own
to understand it and control it and shape it.
It was going to be the Age of Mashups: take data, and do interesting things with it.
I built so many things in the days of Web 2.0.
So many little web toys that took data from one place and showed it in weird ways.
And the most ridiculous, over-the-top tool that I loved to build with
was called Yahoo Pipes.
You didn’t need to write any code to make a mashup with that.
You could just click and drag boxes on a screen to make a flow-chart,
and it would all be done for you,
Yahoo would run it all on their servers, for free.
I made a thing called Star Wars Weather.
It was a really simple web page, it’d show you the weather forecast
by comparing it to a planet from Star Wars.
I had a million people visit that site in one day at its peak,
a few people genuinely used it to get the weather every morning,
I got lovely emails from them,
and all the processing was done in the background through Yahoo Pipes,
I didn’t have to pay for some expensive server or pay for access to the weather data.
There didn’t seem to be any limit, either.
Yahoo just handled it,
because this was Web 2.0 and that was the right thing to do,
and, y'know they’ll figure out how to make money later.
Google Maps. That was free to build on, too.
World-class maps just to play with. I built a terrible racing game on top of it,
put it in my own site, loads of people played it, I didn’t pay them a penny.
None of those free services exist now.
And in hindsight, it was never sustainable.
See, when Twitter launched,
it wasn’t pitched as just an app, or a web site;
Twitter was a platform, a messaging service.
You could use their web site to read and send tweets, sure,
or you could write code that used the API,
that looked at tweets, that reacted to them, or even wrote tweets of its own.
It was so quick, so open that anyone with a little coding experience could make stuff easily.
Everything you could do on the Twitter website, or later, on the app,
everything was available in the API for your code to play with.
The first sign that something was wrong,
for me at least, was the Red Scare Bot.
It appeared in August 2009 with the face of Joseph McCarthy as its avatar,
and it watched the entire Twitter timeline,
everything posted by everyone --
because Twitter was small enough back then that you could do that.
And if anyone mentioned communism or socialism,
it would quote-tweet them with… not even really a joke, just a comment,
just something that said “hey, pay attention to me”!
Hardly anyone followed it, because, yeah, it was really annoying.
Over the six years before it either broke or was shut down,
that bot tweeted more than two million times,
two million utterly useless things added to Twitter’s database,
two million times that someone was probably slightly confused or annoyed.
Somehow it survived, even as Twitter’s rules changed to explicitly ban
“look for a word and reply to it” bots,
even as countless other irritants got shut down.
“Search for every use of a word on Twitter and reply to it”
seems a lot more sinister these days,
in a world where social media shapes public opinion.
We didn’t really know what we were playing with.
I built some Twitter bots myself,
although they weren’t quite as annoying as that.
My best one tweeted any time someone edited Wikipedia from within the Houses of Parliament,
although I handed that political disaster over to someone else
only a couple of days later when the press started calling,
'cos that was far too much hassle.
And those were just the harmless ones.
To be clear, there are still people out there
making really good and interesting and fun Twitter bots:
but “bot” has a whole new meaning now.
Because it turns out you can’t open up data access just to the good guys.
I remember being really impressed with Facebook’s API:
it was brilliant, I could pull my data and all my friends’ data,
and do weird, interesting things with it!
We all know how that turned out.
It’s amazing, in hindsight, just how naively open everything was back then.
APIs were meant to create this whole world of collaboration, and they did --
at the cost of creating a whole lot of abuse.
So over the years, the APIs got replaced with simpler and more locked-down versions,
or were shut down entirely. Or, in the case of Twitter,
their website and app gained features like polls and group DMs which were just…
never added to the API.
You want to use those features?
You’re going to have to go to the official app or the official site.
Because after all, if people can access the platform however they want, with code…
how on earth are Twitter going to show them adverts?
Nowadays, if you want to build something that connects to any major site,
there will be an approval process,
so they can check in on what you’re doing.
And that connection could get shut down at any time.
The Google Maps games I made; the Twitter toys; anything I ever built on Yahoo Pipes;
they’re all broken now and they can never come back.
Pipes must have cost Yahoo so much money.
Even if the service you’re building on survives,
there’s still upkeep associated with making anything that connects to an API.
Sooner or later, the server you’re hosting your code on will fail,
or there’ll be a security patch that you’ll have to install,
or technology will move on enough that you’ll need to update and rewrite the whole thing,
and you will have to ask yourself the question:
is it actually worth it?
Computer history museums are filled with the software and hardware that I grew up with
and that I’m nostalgic for, because they all ran on their own,
they didn’t need any ongoing support from an external company.
But if what you’re making relies on some other company’s service, then…
archiving becomes very, very difficult.
So for the time being, every few minutes, my code is going out to YouTube,
asking how many views this video has, and then asking to update the title.
Maybe it’s still working as you watch this.
But eventually, it will break.
Eventually, so will YouTube.
So will everything.
Entropy, the steady decline into disorder that’s a fundamental part of the universe…
…entropy will get us all in the end.
And that’s why I chose to film this here.
The White Cliffs of Dover are a symbol of Britain,
they are this imposing barrier, but they’re just chalk.
Time and tide will wash them away, a long time in the future.
This, too, shall pass.
But that doesn’t mean you shouldn’t build things anyway.
Just because something is going to break in the end,
doesn’t mean that it can’t have an effect that lasts into the future.
Joy. Wonder. Laughter. Hope.
The world can be better because of what you built in the past.
And while I do think that the long-term goal of humanity should be
to find a way to defeat entropy,
I’m pretty sure no-one knows where to start on that problem just yet.
So until then: try and make sure the things you’re working on push us in the right direction.
They don’t have to be big projects,
they might just have an audience of one.
And even if they don’t last:
try to make sure they leave something positive behind.
And yes, at some point, the code that’s updating the title of this video will break.
Maybe I’ll fix it. Maybe I won’t.
But that code was never the important part.