Well, I did, so I wrote a script to do this (Link is to my github page).
screencap of sample digital bookshelf
To be precise, it grabs all the ‘cover.jpg’ files that calibre creates in each eBooks sub directory, and copies them into another directory, renaming them to the title of the book as it goes.
I now use a fairly common feature of screensavers to point it at a folder and randomly display images. A kind of digital bookshelf, if you will.
…It does make me realise I have a lot of items from fictionwise (with identical covers), and magazine articles (from Hugo Awards), that don’t look as good as a book cover. Once I learn Python, a plugin to do this from tagged books would be the best option. A project for next year, perhaps, given I have to learn Python first!
By Chromatic and Ian Langworth
Work’s library got this in for me by request; I’ve done a lot of work on a module (Storage::Nexsan::NMP) that I hope to release to CPAN soon, and I’d never got my head round software testing. All the books and articles, and even courses I’d been on stressed the importance of writing them, and then showed simple applications I couldn’t see the point of. Having now written a module (my first for, what, 8 years?), and broken it while adding new functionality, this book made a lot more sense to me, especially as it lays out when and what to test.
Ignore any reviews you see saying its old, or out of date; its the only book I’ve found that actually walks you through what and how of testing from the beginning, rather than assuming you know about testing and want to know how to do it in perl.
Thanks to this book, I now have, including some ideas on how to write functional tests for a module that needs a Nexsan storage unit to connect to for all its functions!
Now I just need the time to write some tests and play around… I’m resisting buying the print and eBook bundle right now, as work have this paper copy and access to the fantastic Safari Books Online, but…..
While reading assorted Perl themed blogs, I came across David Precious’s code for backing up Google calendar, contacts and reader subscriptions. Since I use all of these myself, partly to sync with my Android phone, I thought making local copies of them would be a good idea, particularly if I deleted some by mistake – easy to do when trialling a new tool or syncing something the wrong way.
Unfortunately, his tools worked for everything but Contacts – the bit I was most interested in. Further investigation showed that Google had changed the way they provided for you to export your contacts, and the old link no longer existed (but they had put up a page describing what and why). Fortunately, WWW::Contacts came to the rescue, with a working way to get at the data via the API. In retooling his script to use this, I ended up rewriting it to use my preferred command line/documentation parser, to give a consistent interface (as recommended in ‘Perl Best Practices‘, which I’ve been dipping into a lot at work), this lead to me splitting each backup into a separate function so you can choose to back up all three or just one.
The script is up at my Github page; feel free to fork, submit patches or just download and use!
On a related note, the work into this, partly to look at using App::Addex to manage my contacts data (which I’ve wanted to do since RBS blogged about it in his last year’s advent calendar), made me realise what a poor contacts system the Google Contacts is, especially for addresses – the API and the CSV export has fields for address lines 1 and 2, post code etc, but the interface, and the data, is all stored in the first address line, line breaks and all, making it painful to parse into a more useful format (such as the excel spreadsheet I used to bulk order my Christmas cards from Moonpig this year) – a project for another time perhaps, unless Google improve the way Contacts stores/manages the address data.