Originally posted at https://tech.labs.oliverwyman.com/blog/2017/09/06/gasconade-making-blog-posts-for-twitter-users/
Recently there’s been a lot of Twitter posts with the text ‘1/X’ or ‘Thread:’ in them, followed by umpteen other tweets because apparently the relevant poster both refuses to follow the parsimonious limits of the Twitter platform, and for some reason also refuses to write an actual blog post. Given these days the technical act of writing a blog post out there on the internet is really very easy, this both surprises and annoys me (especially as Twitter really isn’t optimised for such matters). The hard bit of doing such a matter is the writing of the content, but if you can write a 100-tweet diatribe on some matter, you can write the post!
I decided a little while back to fix this problem, and was beavering away at such a thing, but apparently it’s such a good idea, someone else built one first. Nevertheless, it’s still worth talking about a bit, in part because my one is open-source and so you can see how I did it. It’s once again a Rust web app, mostly because I felt I wanted this to be pretty speedy (and it is). The core work is pretty simple – talk to the Twitter API, get a tweet, get the tweets it’s a reply to if they’re from the same user, etc, etc. That plus the oEmbed API gets you a decent way in.
However, then you run into a couple of difficult ones. First one you hit is “how do I get the replies to a tweet to work forwards in a thread?”. Some archeology later indicates that there used to an undocumented ‘related_results’ method that doesn’t work any more. I ended up doing a search for all tweets ‘from:YourUsername’ and ‘to:YourUsername’ that are later than the original tweet which seems to work most of the time.
The next fun one is that the oEmbed results while providing a pretty representation of things (e.g. pulling in images) have a couple of problems. Firstly, they display the username bits for every Tweet, there’s a lot of whitespace around them, and there’s the ‘in reply to’ text we really don’t need every time. I could build my own Tweet displayer code, or I could just hack around with the existing stuff. Worse, it’s all dynamically generated by a lot of Javascript magic and we don’t quite know when it’s done. Or that’s what I assumed to begin with… Turns out Twitter are nice folks, and they provide a Javascript API to find out about events like ‘we’ve finished rendering’, which means I can then go in there and hack around with the display bits.
This is all now live, the source code is about where you’d expect, and here are two example threads.