Google Reader for me was never just a way to plow through a large number of feeds, but also a database of important articles that I lovingly annotated with tags and notes when they still existed. Apparently I was in minority, judging by Reader clients and more importantly its own exporting tools which lets you take away most of your stuff, but not tagged items themselves.

Hence I wrote a quick and dirty Python script which allows you to do just that using libgreader. You can find it on Github and it has few other features like exporting all feed articles. Who knows how long Feedburner will be around so next step will be resolving those links.

My current backup amounts to almost 500MB so script is obviously useful to me. Hopefully it is also to others.  If you find bugs or data that is not exported, but should be, please do let me know.

I am also looking for a good alternative that is not hosted only service, supports archiving and can process most feeds. Currently I am biased to modifying Newsblur to support tagging and running my own instance, but I would definitely prefer to avoid this work if possible.

I like easy-thumbnails and use it often in my Django projects, but I wished for a long time that its PIL generated thumbnails would be smaller. That’s why I wrote image-diet, a drop-in extension for those easy-thumbnails users who use file system for storing images. Images remain visually the same, but can be significantly smaller (mine by more than 50% but your mileage my vary).

This matters because images are together with Javascript main cause for ever larger page sizes which leads to slower websites, especially in low-bandwidth environments. But really, don’t we all want our websites to be as fast as possible?

image-diet was inspired by ImageOptim and Trimage and I’m grateful to authors of both. It uses jpegtran, Jpegoptim, Gifsicle, OptiPNG, AdvanceCOM PNG and Pngcrush to do the heavy work of squeezing redundant bytes. Getting them should be easy as they are part of Ubuntu distribution and can be installed on Mac with brew. For more information please check documentation or ask.

I would love to hear any comments and ideas you may have, even more so if you try it.

A class of bugs I really dislike debugging are those that depend on specific data and affect only a very small subset or just one user. Things could sometimes be fixed so much faster if you could just log in as him to see what is happening. Sometimes this is exactly what we do with his explicit permission, but I really dislike asking for passwords.

First it inconveniences user. He has to come up with either a new good password or go through two password changes. Second it implicitly teaches wrong behavior. Passwords simply should never be revealed.

That is why I wrote Impostor, a Django app that allows staff members (and only them) to login with their own credentials as a different user. Idea is not mine (kudos goes to Ned Batchelder), but I like it. To discourage abuse every such authentication is recorded and can be seen in Django admin interface, but can not be altered from there.

So how does it work in practice?

Lets say that I would need to log in as user fry. To do this I would enter as my username markos as fry, provide my password and voila, I’m him. This has been recorded so anyone with access to ImpostorLog part in admin can see all such cases, mine included.

Impostor may also ease your development by removing need to remember different passwords for testing. This is usually not a problem unless you happen to develop with fake data but real accounts. Like me.

And again for morally challenged out there: you should never login as somebody else without his explicit permission.

Update: Thanks Ross for reminding me where idea came from. I updated text accordingly.