For a while now, I've been running a service that generated RSS feeds for Pinterest boards on Google's App Engine. For most of its life, this service didn't work particularly well - the script was a quick hack that was never designed with the kind of attention it received in mind.

Today I can announce that I've reimplemented the service, and am redirecting all requests to the new scripts. The source code is available on github.

I can't make any promises, but I'm hopeful that this new service will be able to handle the load and consistently produce Pinterest RSS feeds for its users. This service generates feeds from its internal cache of your pins, which is refreshed periodically, so pins won't show up immediately, but new pins will make their way to your IFTTT recipes after a short while.

My IFTTT recipes are firing just like they should — let me know if you're having any trouble!

About six weeks ago, I created a small web service that provides RSS feeds for Pinterest users and boards, fixing some issues with the official RSS feeds. Apparently, it's a smash hit, to the point that several users have pointed out when it hasn't been working for them. This has uncovered bugs (thanks, Mary), and sometimes, it just looked like Pinterest itself was having some kind of mid-life crisis. This morning, however, I had a very different problem: (and thanks for the two people who pointed out the error to me, I wouldn't have seen it otherwise!)

The app in running into Google AppEngine quotas! Wow. That, my dear friends, is how popular this shit is.

I've updated the app to cache feeds a bit more effectively, which will hopefully help push database usage back below the limit for the time being. (it could also make things worse) What this update will definitely do is make my app serve feeds even if it's temporarily unable to get good data from Pinterest.

The 48% of the daily quota you see above is what the old version amassed in about seven or eight hours. That alone could be enough to push us over the limit again tonight (we'll see), but if there's still a problem on Tuesday morning, I'll look into how much it'd cost to raise the AppEngine quota and consider moving the app to a different server. I'll do what I can to keep it up and running, of course.

Check out the app!

Experimenting with the fabulous web automation service If This Then That this morning, I thought it would be nice to do something with my Pinterest posts, such as saving them to Dropbox or posting them to Tumblr. The problem with this was that the RSS feeds provided by Pinterest only include thumbnail images that are of little use here.

However, it's not that difficult to get the full-sized image if you know how to program, so I didn't let that stop me and wrote a simple solution. May I present to you: The Better Pinterest RSS Feed Generator, powered by Google App Engine. It gives you your Pinterest feed in a format you can use.

As I write this, I'm in the process of deleting tonnes of old posts and comments from my Facebook profile. This is not an easy task: Facebook loves data, and wants to keep as much of it as possible. So, of course, they've made it rather difficult to clean up; you essentially have to do it manually, on the Facebook website. This can be partially automated — I use iMacros, as suggested by ZDNET — but it's not perfect, and you still have to do bits manually or modify the macro to skip things. It's tedious.

Going through the mess that is my Facebook past, I was, naturally, intrigued by some of the things I spotted. Occasionally, I would have a look at the context of a strange comment I left somewhere. Then, I spotted one very worrying thing:

Facebook keeps around comments to posts that have been deleted.

That's right. Facebook loves data so much that they'll clutter up their databanks with information that nobody will ever see, ever.

A lot of people got rather upset about the introduction of Facebook's Timeline profiles. I, personally, find it liberating. Now, there is absolutely no doubt about how Facebook is “meant to work” (according to Facebook). Now, everybody knows: your Facebook profile is supposed to be a record of your entire life, and you're supposed to make sure it's complete.

Is that how I want to use Facebook? Certainly not! I don't even want there to be a record of my entire life, let alone let some American corporation with a questionable commitment to privacy manage it. No, I use Facebook to share impressions from my life and links from the internet with my friends and acquaintances. Maybe they'll see the things I post, maybe they'll enjoy them, maybe we'll have a spirited discussion in the comments. And maybe somebody will save a photo or link to their computer because they think it's worth keeping. But will they go digging in the archives? Probably not, these interactions are very much rooted in the now. Will they link to my insightful posts elsewhere? No they won't: they're (mostly) not public.

So, is it worth using Facebook? I would have to say yes, it is. I like seeing what other people share, and other people enjoy my posts (somebody I see very infrequently told me so in person just a few days ago). But is there any reason for old posts to hang around? No, there isn't.

Here's what I'm going to do: I'm going to make backups of photos I want to keep, but I'm going to delete all but the past few months of Facebook activity. I'm going to continue using Facebook just as profusely as I have been, regularly deleting old activity, but I'm going to keep copies of photos of and by me automatically using If This Then That. Ideally, I'd want to fully automate the deletion bit, but I know that, even if I do find a solution, it will mysteriously stop working quite soon, because Facebook loves my data, and wants to keep it.

Scalable Vector Graphics (SVG) are a promising technology. We've all known for years that vector graphics are, scalable as they tend to be, a great thing and often more useful than raster-based image formats. SVG in particular is nice because it's

• all text
• an XML-based format, and thus hip in the industry
• an open format
• an open XML-based format, and thus portable and good with stuff like XSL-T.

Web browsers like to boast about their SVG support, it being a hip technology pushed as a web standard by the W³C, and the support isn't bad. Recent versions of Gecko (Firefox etc), Opera, KHTML and WebKit have all implemented a working subset of SVG and are able to display simple images correctly. Some browsers (at least Firefox and Opera) have decent support for XSL-T style sheets, allowing you to display an XML data sheet graphically in a browser by linking a suitable style sheet at the top — I never expected this, but I was pleasantly surprised when I discovered that last year. Also interesting is the support of ECMAScript within SVG, making it possible to play tetris in a vanilla IceWeasel.

What was this stuff called again?

We're talking about scalable vector graphics within a WWW context. The fact that these things are scalable could be used to our advantage, n'est-ce pas ? Let's say you have a website styled with only ems for measuring distance, no pixels or other absolute stuff. Being nice and accessible, having the whole website scale when you hit Ctrl++ or Ctrl+-. Something like <img src="foo.svgz" alt="An illustration of bar" style="width:20em"/> should be just what you need. So, which browser supports that ? Bingo, not a single one !

There is a standard, portable way to include SVG in websites: you use the <object> tag, like so: <object type="image/svg+xml" data="foo.svgz" ...>. This works in pretty much all modern browsers (if you don't count IE7, but why would anyone call that bastard “modern” ?), but it doesn't do what I want it to do: it doesn't scale the graphic. At all. It stubbornly uses the size in the SVG file. If you're lucky, zooming with change the font size in the image, but only the font. What's the point of that, I ask you ? Why bother with scalable vector graphics support if you can't scale them ? Maybe we should call them scriptable vector graphics when using them on the web...