Generic reposter code now available — repost your Twitter timelines with pictures
Vacation is the best time to write code, isn’t it ![]()
I got my act together and somewhat cleaned up the generic reposter code that powers miscrandom.com. You can now immerse yourself in its wikipage with links to downloads and all that. And I made this fancy pic for it too that tries to explain a bit of reposter’s modus operandi.
So… if I had to sum it up in one sentence, I would say that reposter aggregates feeds and lets you build your own meta-blogs with much more versatility and customization than you could ever get from online aggregator services like FeedBurner.
A word of warning
It’s not really for the faint of heart and it’s not really friendly. It’s optimized for running from your crontab, say daily. So the commandline UI won’t say anything if all is OK, and only complains if things are wrong. (And if you were to run it from cron like I do, you would of course receive these cries as email.)
Why, oh why do you bother with such stuff…
I think it’s both interesting and important. The mechanics of feeds and API-s are interesting. And as time goes by, we’ll surely need more solutions for collecting, dissecting, transforming, archiving and reposting information.
But wait, there’s more
Reposter pretty much does what I said in the original motivation post. One thing that’s got a bit more specific since then is what I call entry transformers. I call them like this because it’s a cool name and the movie is coming out soon. And the transformers do exactly that — they transform the feed entries.
Allow me to try to explain. So let’s say you’ve got this Twitter feed from yourself or from your friends. By default, it’s not very interesting because it only has text. But Twitter has these fun little profile pictures. And if you’ve already got an URL for a twit from anyone, you can go and pull the picture out of there, and also repost it on your own site to make things a bit more, as they say, “interactive” and “entertaining”. I’m a big fan of pictures so this is why I did this Twitter pictures thing.
Or, if you have a Youtube feed, you have a bunch of URL-s and titles. If you only posted that on your site, it wouldn’t be so interesting because you’d still have to go to Youtube to play the video. But since all the info needed to construct the embedded video is already in the URL, you can have a little transformer that recreates the embedded video player code right then and there. And it’s much simpler than Twitter because it doesn’t need to fetch anything from anywhere. One thing that’s currently missing from the Youtube transformer, though, is more metainfo, like the description and post date and author and all that. I didn’t think it was necessary so I didn’t include it in my own transformer.
I branched out this entryTransformer stuff into a separate class because it’s useful on its own and in other projects, too. You may need to repost things in various settings and if you find entryTransformer useful for it, you’re welcome to use it. I’m using it from my Reposter as you could do from any other script.
What’s next.
You could do many more things with this. Here’s what I’m thinking of…
- more transformers. Yep. I didn’t add any because here are the ones that I’m currently using except del.icio.us. And the transformers need an extra feed vector — they should consider not only the link itself as they do currently, but also where they are coming from. For example, in case of del.icio.us, we have del.icio.us tags available. But you could also simply have extra transformers for, say, Flickr, or ma.gnolia etc.
- the MT XMLRPC API posting code needs cleanup. The code is currently generic and from mtsend.py, but I should make it more domainspecific, compact and nicer specifically for Reposter. Works fine as is, but doesn’t make me proud yet. (But I’m quite happy with the feed scraping and entrytransformers parts.)
- anything more? Let me know.
3 Comments
Leave a comment



Jaanus, please tell me again why you don’t just use Yahoo Pipes?
Haha - good and valid question
Here are the main reasons why I have this reposter thing instead of using Y! Pipes.
I came up with the Reposter idea slightly before Y! Pipes was released. So Pipes simply didn’t exist at the time.
All Pipes does is reformat things. It only provides you an RSS feed. Reposter is more generic - it posts the data in a blog backend. This is better for two reasons 1) Reposter lets you archive things permanently (assuming your blog backend doesn’t die), whereas Pipes is only working as long as the data is present in source feeds and I believe data eventually gets “lost” from there, 2) reposting things using a blog backend lets you use more presentation formats than just RSS (such as simple web pages as seen on Misc Random).
I must say I haven’t dug into the Pipes API to full detail. Just scratching the surface, it seems to be fairly powerful, so it would be an interesting exercise to try to recreate the same thing as Reposter using Pipes. Maybe I’ll do that at some point, I’m especially interested to see if it lets you do the full entryTransformers type of stuff, i.e reformat content based on both URL and source feed vectors.
Web-based solutions are abstractions. You’ll never be able to do everything on the web that you can do in a full script and in your own hosted environment. But that might not be needed if the API and featureset that’s exposed on the web is powerful enough for the task at hand.
… and one more thing I didn’t mention that’s probably the most important: such “projects” are important to me not only because of their end result and output, but also because of the learning process and what you can learn while building it. I believe there is a lot of value in learning how to build things from scratch, and there’s equal value in learning how to use other people’s solutions. It helps you make informed “build or buy” decisions down the road, and just generally understand better how things work on the Internet.