Exciting News About Goodreads: We’re Joining the Amazon Family!

Exciting News About Goodreads: We’re Joining the Amazon Family!

Mouais …

En tant qu’utilisateur d’un paquet de services déja (ou bientôt) morts, cette nouvelle ne me réjouit pas particulièrement. Je comprend bien que ça va permettre à Amazon d’améliorer sa base de données d’avis nettement mieux qualifiés que ceux disponibles habituellement. Mais quand même, il me semble qu’un backup puisse devenir nécessaire (oui, comme chez Posterous, Google Reader, Origo, et tant d’autres).

lifestream ou backup ?

Bon, depuis le temps que vous lisez ce blog, vous le savez, j’aime l’idée d’un lifestream, c’est-à-dire d’un flux contenant toutes mes informations. Enfin, je crois.
Parce que si j’aime bien cette idée, pourquoi diable mon générateur de site en Java, qui utilise en entrée le backup posterous et le backup goodreads, est aussi en retard, aussi moche et surtout aussi peu fonctionnel ?
Je me posais la question depuis quelques jours (et c’est d’ailleurs pour ça que j’en parle), et j’ai finalement trouvé la réponse, bien aidé par deux sources.
La première, c’est l’auteur de Sweetcron, qui annonce dans un post sur posterous (dont il dit d’ailleurs le plus grand bien, comme moi) qu’il arrête les développements d’une très bonne plateforme de lifestream (oui, sweetcron). Ses raisons sont proches de celles qui m’ont fait choisir posterous, avec toutefois la nuance que lui a déjà un lifestream qui tourne.
La seconde, c’est le graphique fait par cet allemand qui montre tous les endroits où il contribue, et comment ses contributions voyagent à travers le web. Compliqué, non ? Et si je devais faire le même, quelle tête aurait-il ? Ca, en fait, j’en sais rien, et finalement, je m’en moque.
En fait, ce dont je me suis rendu compte à la lueur de ces informations, c’est que je ne veux pas forcément faire un lifestream. Ce que je voudrais plutôt, c’est avoir une sorte de backup de toute mon activité sur le web. Mais un backup "intelligent", en quelque sorte, qui me permette de rechercher dans mes anciens messages de toute sorte (lectures de Goodreads, liens de delicious, messages de ce blog), et qui permette bien sûr à ce contenu de survivre à tout.
Alors comment je peux faire ça ? Bien sûr, mon générateur de site est une solution "raisonnable", au sens où je peux m’arranger pour que Google indexe son contenu et me l’affiche. Mais … si j’étais capable de faire la même chose "autrement", comment est-ce que je ferais ?
A bien y réfléchir, je pourrais tout-à-fait m’inspirer de Rui Carno. Je m’explique. Actuellement, j’exécute mes différents scripts de backup au petit bonheur la chance, et ensuite je lance le script de génération du site pour obtenir un site navigable. Pourtant, mes fichiers "source" sont des fichiers XML. Alors si ces fichiers XML apparaissaient directement dans Dropbox, est-ce que je ne gagnerais pas des tonnes d’énergie ? Après tout, c’est du texte, donc un Google Desktop (ou équivalent, parce que je n’aime pas trop leur outil, malgré ses possibilités. En fait, je n’aime surtout pas leur affichage de résultats dans une page web chargée depuis ma machine, je trouve que c’est une facilité assez moche) pourrait très facilement me trouver du contenu quelquesoit la machine sur laquelle je me trouve. Et, pour peu que je dispose d’une feuille de style XSL, je n’ai plus à lancer mon affreux script (bon, je perds un peu de fonctionnalité de navigation – et encore – mais je ne crois pas que ce soit si dramatique. Après tout, je ne fais qu’ajouter du contenu XML) et j’aurais pourtant des résultats joliment affichés dans mon navigateur. Je vais peut-être avancer dans cette direction, tiens, même si je perds certaines fonctionnalités de moteur de recherche de tags.

Posterous backup, an upgrade

This message is an update to the previous one.
it is due to my users being true bentlemen, that wants nothing more than a sweet script allowing them to do whatever kind of backup they want.

One of these users, Eli, asked me if it was possible to save images in another folder than the messages one.

As a matter of fact, I thought it would be even more convenient to have ilmages stored in a folder named from the message.

As a consequence, I added a new flag to posterous backup command line : "-s". When using this flag, images are all stored in a folder named like the message url.

When opitting it, the "historical" mode has been kept, and all images are saved alongside the messages.

Obviously, you can download that script by following that link : download it immediatly and without any kind of nagware.

Feel free to manifest your appreciation !

Posterous groovy bug due to bad HTTP Builder dependency.

I allow myself to post this on my posterous blog, as a follow-up to my message concerning the availability of the script.

 

2010/4/7 E*** B******* L*** <******>
>

> Hi Nicolas,

 

Hi, E***

>
> I just tried to use your script on my Ubuntu machine but it can not find the following class:

>

> unable to resolve class groovyx.net.http.URIBuilder
>
> Can you maybe tell me how I can install this class to be available in Java? I found it with Google but don’t know how to make it available for your script / the JVM.

 

Will have to dive deep in groovy internals for that, I hope you’ll understand the whole.

 

The posterous groovy script, for getting all the entries, make use of the groovy version of HTTP Builder : http://groovy.codehaus.org/modules/http-builder/

This dependency is resolved using groovy specific mechanism : grape. You can see the @Grab instruction for HTTP builder at line 289 :

 

@Grab(group=’org.codehaus.groovy.modules.http-builder’, module=’http-builder’, version=’0.5.0-RC2′)

 

I’ll make the guess you don’t know at all groovy grape. It’s a kind of « live » version of Ruby Gems : your program dependencies are expressed using annotations in the body of your program. Once run by the groovy runtime, each time one of these annotations is encountered, grape checks if the dependency is already known (that’s to say already present as ~/.groovy/grapes/ »group »/ »module »/jars/ »module.version »). If not, it is downloaded and its checksum is verified.

 

Currently, the HTTP Builder website says on its front page

 

So I had a couple people mention that they had trouble using Grape to download RC3 due to a bad checksum on the POM file. I tried re-deploying it, (thinking it was a bad upload) and now I’m getting a _bunch_ of people saying they can’t download it!

As a work-around, please add the following line to ~/.groovy/grapeConfig.xml: <property name= »ivy.checksums » value= » »/>. This should allow Grape to ignore the checksum and download the file, until I’ve got the checksum problem resolved. Stay tuned!

 

May I suggest you to do the mentionned operation ? Notice however this operation seems to disable checksum verification on all jars, not only on HTTBuilder one. So, don’t forget to remvoe that line once the application is run successfully !
>

> Greetings from Germany,
>

Thanks for the feedback !

Posterous backup updated !

So, thanks to a comment from Richard, I discovered on saturday that my little posterous backup script did not backup private posts.
I initially found it weird since I knew that, in my script, I correctly set the basic authentication mechanism.
In fact, it was due to the way posterous api is built, I think. From what I’ve understood, there is no session maintained on server side (weird choice, Sachin).
So, from Tom’s advice, I updated my script to ensure the basic authentication token where written on all requests.
Now, Richard, posterous export should grab all your entries, even private ones !
Besides, I’ve also copied that script on git (since relying solely upon dropbox survival does not seems enough to me). So, if you want to update it, it must be rather easy, no ?

Goodreads export : yep, another beta reached !

Yep, in exactly the same fashion than the previously mentionned posterous export, I’ve also created a goodreads export script working exactly the same way
The advantages are
  1. exactly the same install path (install Java, then groovy, then download the script)
  2. exactly the same command line arguments
  3. exactly the same output XML format (with some extensions for books that I leave to your imagination from the following file)

An example

<post>
  <title><!– book title –></title>
<book>
<title><!– book title –></title>
<author><!– book authors –></author>
<isbn13><!– book isbn13 –></isbn13>
<rating>
<personnal>4</personnal>
<average>4.00</average>
<initialPublication>1985</initialPublication>
</rating>
</book>
<date><!– date book was read –></date>
<tags>
  <tag>w<!–each tag is independant –></tag>
   </tags>
<body><![CDATA[
]]></body>
</post>

Notice in-body links are for now not handled (but it may come soon)
So, it’s a far more betaish script (since in-body links are not handled). Anyway, this could help you keep your precious reviews with you.

Posterous backup : beta reached !

Exceptionnellement, j’écris en anglais histoire de toucher la plus large audience possible …

One easy way to backup all of your posterous blogs

As anybody (and as the posterous creators stated), I don’t want my data to be locked in an application, be it as smart as posterous currently is.
As a consequence, I’ve decided it was time to ensure my posts (this one like all the others) would remains even if posterous collapsed (what I absolutely not want).
For that, relying upon posterous API, I wrote a groovy script that will backup all my posts, photos, sounds, and videos on the computer I use.

Organized backup

This backup is quite simply organized :
One folder for each site.
In each folder, entries keep the file name they have in posterous, followed by a nice .xml extension.
Each media associated to an entry uses the entry name, followed by _#anumer, where the #number is the media number.
Notice I also do URI replacement in the entry, for backup media to be used instead of posterous ones.

As an example, my own backup contains the following


+—knackfx.posterous.com
|   all-your-bases-are-belong-to-rest.xml
|   cant-wait-for-the-671.xml
|   knack-it.xml
|   netbeans-671-available-for-download.xml
|   rest-in-game.xml
|   serve-me-good-games.xml
|   whats-new-today.xml
|
riduidel.posterous.com
   il-mavait-prevenu-le-bougre.xml
   il-mavait-prevenu-le-bougre_0.png
   il-mavait-prevenu-le-bougre_1.jpg
   tester-lutilisation-de-la-memo.xml
   tester-lutilisation-de-la-memo_0.gif
   tester-lutilisation-de-la-memo_1.jpg
   the-big-band-theory.xml
   the-gaf-collection-collected.xml
   the-gaf-collection-collected_0.jpg
   the-gaf-collection-collected_1.jpg
   xkcd-movie-narrative-charts-0.xml

Well, in fact, I only shows here an excerpt, since backup generates 205 files on my machine.

How to use

Here comes the hardest part : installing this backup script. There are two little prerequisites :

  1. Install a recent Java (theorically, your machine should laready use a Java 5 or Java 6 compatible version, what you can check by issuing the java -version command in a shell)
  2. Install a recent Groovy (which is just a little harder).
  3. Download the posterous.groovy script (this is quite easier). You can put this script anywhere on your disk.

One all is downloaded, go in the script folder and

groovy posterous.groovy

should output the following

This is posterous export script v 0.1error: Missing required options: u, p, ousage: groovy posterous.groovy -u email@posterous -p password -ooutputFolder -h,--help provides full help and usage information -o,--output  An eventually existing output folder, where all data will be output. Beware, if some data exists in that folder, it may be overwritten. -p,--password  Unfortunatly one have to give its password to this little script -u,--username  Sets posterous mail address here
Notice that first run may show error messages, since grape download (the tool used by groovy to pull dependencies from the interweb) has some issues regarding used dependencies.

The result

So, as told before, this script generates a bunch of files on your machine.
Each of this file is an XML file containing all infos from posterous (in another format I plan to use to pull data from various websites).
This format seems to me quite legible :

<post>
  <title><!– posterous title–></title>
  <date>2008-12-31T17:48:00.000+0100<!– posterous post date in a quite standard form –></date>
<author>
  <name><!– author name –></name>
  <pic><!– author pic –></pic>
</author>
<body><![CDATA[
<!– post body, protected from XML interpreting by the CDATA section
   ]]></body>
<comments>
<comment>
<author>
  <name></name>
  <pic></pic>
</author>
  <date></date>
<body><![CDATA[
   ]]></body>
</comment>
</comments>
</post>

I thinkk this format will allow you to execute any complementary treatment, as nothing since to be lost from original (expect medias file sizes, which you can see in your OS).
Additionnaly notice that only medias stored by posterous are downloaded, not Flickr images or Youtube videos.

The license

This script uses a creative commons license : paternity, share-alike, no commercial use.

Feed me back !

Any feed back you can send me will be greatly appreciated ! Don’t hesitate to use comments below to mark your appreciation.

Backup posterous ? Job’s done !

Et voilà !
Après une petite journée de travail, j’ai un script de backup posterous en version « alpha ».

En fait, je me suis appuyé sur la doc de l’API de Posterous pour écrire un script Groovy qui prend toutes mes entrées, et les stocke dans un dossier de mon choix. Evidement, comme je suis un peu fainéant,c e script ne marche qu’avec un groovy installé sur la machine. Bien sûr, je pourrais packager ça dans un jar qui ne nécessiterait plus que Java. Avec Griffon, je pourrais même en faire une applet … Mais ça, c’est pour les versions suivantes.
Pour l’instant, c’est un petit projet qui utilise essentiellement les expandos (regardez à la fin) et HTTPBuilder pour faire des trucs rigolos.
Voici maintenant, dans l’ordre, les développements suivants
  1. Backuper les médias joints (images, vidéos, fichiers groovy …)
  2. Créer une UI digne de ce nom pour choisir l’utilisateur, le mot de passe, le dossier de sortie, …
  3. Faire du backup « incrémental » en n’ajoutant que les nouveaux fichiers pour gagner du temps (quoique je ne crois pas que posterous puisse me les trier dans l’ordre de dernière modification, ce qui m’obligera quand même à tout récupérer)
  4. Faire un outil à la webgen pour créer un site affichant toutes ces entrées avec des tags, une timeline, …
  5. Trouver une licence (pour l’instant, on peut le considérer en creative commons paternité – pas d’utilisation commerciale – pas de modification)

Comme je suis un mec sympa, le fichier est joint (et aussi pour augmenter ses chances de survivre). Ah, tiens, ça ne semble pas marcher. je vais le mettre ailleurs alors (mais je ne sais pas encore où).

Ma stratégie de backup/synchro/…

Après les quatre premières incarnations du blog, et pour éviter la sixième, j’ai décidé de mettre en palce une stratégie de backup, bien aidé par le fait de disposer au bureau de deux machines. Et surtout bien motivié par cet article de Coding Horror qui explique une stratégie de backup à trois disques.

Pour l’instant, je vais me contenter d’une bête duplicationd e toutes les données qui sont sur mon portable (y compris ce site) vers mon poste fixe. Le top, c’est que c’est vraiment très facile à faire grâce, par exemple à Comodo Backup qui gère tout seul les tâches planifiées, l’envoi à travers FTP, …

FTP ? Oui, FTP, parce que j’aimerais bien mettre à profit mes 10 Go d’espace disque pour y stocker un autre backup, mieux choisi celui-là, avec mes photos, les sources du site, …. bref les données clé. Et mon espace perso n’est évidement accessible qu’en FTP, d’où le besoin. Bon, j’ai même pensé utiliser le service dl.free.fr comme un bourrin, mais ça me ferait des gros transferts tous les 15 jours et ça, je n’en ai pas du tout envie. Donc pour l’instant on va voir. Tiens, je devrais aller voir du côté de Tao of mac (Comme le site est down au moment où je regarde, j’ai juste trouvé ce lien sur son utilsioation du backup fourni dans le package .mac . C’est pas mal, mais il doit sûrement avoir mieux à offrir dans un coin bien caché.).

Récupération des données Ziki

J’ai eu une bonne idée, le jour où je me suis abonné à Ziki. Parce que dans cette boîte, ils maintiennent un cache des billets de mon blog, ce qui fait qu’au lieu de perdre toute l’année 2007, je n’ai perdu que les mois de janvier à mars.

Pour la période mars/juillet, j’ai dû me payer un gros copier-coller.

Et pour la période juillet/décembre, c’est la fête, j’ai un bon gros fichier RSS de 150 Ko à parser. De la rigolade, par rapport à mon dump SQL de 5 Mo 😉 Du coup, je m’en vais commencer à écrire un début de plugin pour importer des données issues de flux RSS quelconques.