Ca y est ! J’ai enfin terminé la migration de posterous !

Evidement, ça ne va pas intéresser grand monde … quoique.

Donc, vous vous souvenez de cet article « L’import de posterous, c’est quand même pas ça » ? J’y expliquai rapidement que les caractères non ASCII des articles que j’en importais étaient salement transformés. Au total, j’avais environ 600 articles contenant des accents, et donc contenant des saletés de « ?? ». J’ai donc dû, quasi-manuellement, remplacer tous ces caractères par les vrais bon caractères accentués (merci d’ailleurs aux macros de Notepad++ qui m’ont bien facilité les choses). J’aurais bien aimé, dans l’idéal, pouvoir monter un partage WebDAV pour trouver plus rapidement tous ces articles à mettre à jour. Malheureusement, comme ce blog est hébergé gratuitement par WordPress.com (ce dont je les remercie), je ne peux pas installer de plugins, et je n’ai donc pas accès à mes articles facilement.

D’où cette terriblement longue phase de correction, qui a duré quand même 6 mois !

Du coup, évidement, je suis très content d’en avoir fini avec cet enfer, parce que je peux maintenant passer à des choses plus intéressantes, comme par exemple des améliorations du lifestream.

La première chose à faire, c’est finir d’implémenter le support de WordPress, ce qui me permettra de proposer ce support à l’auteur de JBake …

La deuxième, ce sera sans doute de détecter automatiquement les liens morts. Parce que dans WordPress, comme dans Shaarli, les liens périssent. Et pour l’instant, je ne le détecte pas et c’est bien dommage. Mais je sais que ça viendra !

Publicités

Back to wordpress

Bon, après ce message

Celui-là,

Cet autre

Et ce dernier est un peu énervé

Une conclusion s’impose : je retourne chez WordPress !

Evidement, c’est pour ce dernier que je développerai ensuite un module agorava. Tant pis pour posterous !

Et à quoi servira ce module à votre avis ? A deux choses :

  1. Réimporter tout le vieux contenu WordPress que j’ai aspiré comme une brute (ben oui, quand les APIs subtiles ne marchent pas, l’aspiration HTTP, elle, fonctionne toujours)
  2. Exporter ensuite tout ce que j’ai écrit dans un site statique (c’est loooiinnn d’être fait, mais un jour, ça viendra)

La mauvaise nouvelle du matin

Internet m’apprend ce matin (via ce twit de Jean-Michel Billaut) que Twitter rachète Posterous. Pour les développeurs de posterous, pas de problème, je suis content. Pour moi, en revanche, la situation est plus floue : entre l’export qui ne marche pas trop bien et le fait que je me retrouve face au behemoth Twitter, je suis perplexe : j’ai l’impression de perdre en indépendance. Bon, on va voir ce que l’avenir nous réserve … en jetant éventuellement un oeil à la FAQ de Posterous …

C’est mal fait, ça tiens

Ce matin (bon, ce midi, en fait), j’ai pris une grande décision.
J’ai décidé d’arrêter de passer mes midis à jouer à Urban Terror pour faire des trucs plus constructifs.
En fait, j’avais déja fortement diminué mon temps de jeu il y a quelques mois, pour pouvoir blogger d’une façon plus régulière. Je pourrais bien entendu vous sortir une timeline de derrière les fagots, mais je ne suis pas sûr que ça en vaille la peine.
Donc, j’ai décidé de diminuer encore mon temps de jeu (poussé par le fait que mon niveau commence à stagner), pour reprendre des occupations utiles.
Au premier lieu de ces occupations, il y a la mise à jour de mes différents scripts. Et évidement, en premier, l’export posterous sur lequel je dois pratiquer deux opérations
  1. Remplacer le format de sortie personnalisé que j’avais créé (vaguement inspiré, il faut le dire, par Docbook) par un micro-format très adapté au contenu.
  2. utiliser l’API v2 de posterous
Et sur ce deuxième point, je cale déja un peu (oui, je commence par le deuxième point parce que, tant qu’à faire, autant se faciliter la vie et commencer par lire les données avant de les écrire, ce qui me donne d’ailleurs une diée foudryante de puissance quant à l’utilisation de GPars et du Groovy fonctionnel pour accélérer le bouzin).
En effet, les gens de Posterous disent de récupérer simplement ce token d’identification à une url, et évidement ça ne marche pas.
Bon, je détaille, sinon personne n’y comprendra rien.
Dans mon code Groovy, pour me connecter, j’utilise simplement

 

 

Et devinez ce que me dit Groovy quand j’exécute ça ?

 

Ben oui, ça ne marche pas.
Et apparement, c’est dû au fait que posterous utilise une authentification basique préemptive, alors que HttpClient (et donc HttpBuilder) n’aime pas ça.

 

Ce qui me pousse tout de suite à changer mon plan pour faire d’abord en premier la première partie de mon plan : exporter dans un joli HTMl réutilisable facilement.
Ensuite, je migrerai en API v2 (et oui, sur les petits projets, je n’hésite pas à modifier l’ordre des tâches si ça peut me permettre de réussir plus de trucs plus vite).

Ajouter un bouton flattr sur posterous

Puisque je suis en train de le faire, autant vous l’expliquer. Voici donc ma solution pour ajouter un bouton flattr sur un blog posterous. Pour cela, vous devez déja avoir un compte flattr et un blog posterous.

Ajoutez votre blog comme « thing » flattr. Pour ça, je vous laisse découvrir sur le site de flattr comment faire (en tout fcas, la capture ci-dessous devrait pouvoir vous aider …).
Ss-2010-08-25_13
Une fois que c’est fait, vous disposerez d’une page comme celle-ci.

Sur la page de votre blog, il doit y avoir un lien intitulé « Button code« .

Ss-2010-08-25_13

Cliquez dessus.

Dans le panneau qui va s’afficher, vous trouverez deux types de boutons : un bouton dynamique (avec du Javascript, donc, et qui ne marchera pas sur posterous) et un bouton statique (Default static button code). Dans le cadre sous cet intitulé, il y a un paquet de code HTML. Copiez-collez le.
Ss-2010-08-25_13

Bien, maintenant que vous avez votre code flattr, vous pouvez aller sur votre site posterous. Donc vous vous connectez à posterous, vous cliquez sur settings, et ensuite sur « Edit Theme« 

Ss-2010-08-25_13

Là, vous allez devoir modifier le code HTML du thème de votre posterous. Il faudra donc être prudent ! Pour cela, vous devez d’abord cliquer sur le mode « Advanced » de l’édition de thème posterous.
Personnellement, je trouve le bouton bien placé dans le pied de page. J’ai donc modifié le pied de page de mon thème personnel. Hélas, selon le thème utilisé – et vos envies – vous pourrez avoir envie d’autre chose … Je vous laisse donc cette édition de code HTML en guise d’exercice.

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 !