J'ai une confession à vous faire.
J'ai écrit il y a quelques temps déja des petits scripts en Groovy pour exporter mes données de Posterous et Goodreads. Au début, ça me paraissait facile. Et puis j'ai voulu rajouter des fonctionnalités : exporter plus de trucs, exporter dans plus de formats ... Et ce qui devait m'arriver m'est arrivé. un jour (je crois que c'était l'année dernière au mois d'octobre) j'en ai eu marre.
J'en ai eu marre de la limitation débile que je m'imposais de tout mettre dans le même fichier.
J'en ai eu marre également de ne pas pouvoir débugger, d'être coincé dans une version spécifique de http-builder, et de ne pas vraiment pouvoir faire ce que je voulais.
Et puis je commencais à me perdre dans mes closures.
J'ai donc longuement réfléchi au problème, et pris la décision qui s'imposait.
J'arrête ces scripts en groovy. Ou plutôt, en m'appuyant sur cette expérience, je fais un reboot et je redémarre les projets dans mon langage de prédilection : Java.
Je ne crois pas que Groovy soit en cause, en fait. Mais, comme les développeurs de free.fr qui sont passés de JSF à PHP en deux jours, j'ai ma zone de confort. Et il semble que cette zone de confort soit bien définie (autrement dit je commence à me scléroser) : Java, Maven, et Eclipse de préférence (mais j'y reviens plus bas, pas de panique). Donc, je retourne dans mes pantoufles, et je m'y remets.
Avec toutefois une nuance. je me suis dit que tant qu'à faire un aspirateur de site web, autant avoir une prétention, même minime, à l'universalité. Je développe donc maintenant une espèce de "truc" à laquelle je donne un fichier de configuration (avec les différents login/password/clés d'accès aux APIs), et qui, pour chaque site "connu", va aspirer les éléments intéressants. Un truc somme toute basique.
Tellement basique, d'ailleurs, que le truc avec lequel j'ai eu pour l'instant le plus de diffculités à comprendre est le mécanisme d'authentification basique avec http-client. Pour le reste, laissez-moi juste vous dire que Jackson est sacrément balaize pour le mapping JSON/objet. En revanche, une chose me chagrine : il semble que personne n'ait pensé à utiliser les pouvoirs "magiques" des proxies Java pour écrire un accès à une API web sous forme d'une interface .. quelque chose comme ça :
Avec ça, j'écris vite fait les parties utiles de l'API du site, et après mon code devient hyper-facile, vous ne trouvez pas ?
Bon, je crois que je vais le faire tellement c'est simple.
En revanche, le truc qui em déçoit beaucoup, c'est GitHub. je croyais que c'était facile d'y créer un dépôt pour y placer mon code, mais en fait non : il faut à chaque fois passer par cette saleté du millénaire précédent de ligne de commande pour créer la branche originale avec msysgit. Parce qu'évidement (ou tout au moins d'après ma compréhension du truc) EGit n'arrive pas à faire le premier push sur GitHub. Et ça, franchement, ça me donne envie d'abandonner ce "truc" hyper-hype pour revenir à un simple Subversion (chez origo ou google code). Notez bien que je n'ai pas encore essayé avec NetBeans.
Parce que oui, en ce moment, j'utilise un peu NetBeans. Je ne comprend pas tout, et l'absence des pespectives d'Eclipse me manque beaucoup, mais l'un dans l'autre il y a de bonnes idées dans cet IDE (par exemple dans les refactorings comme le pull up qui permet de créer automatiquement les déclarations de méthode abstraite dans la super-classes).
Bon, ben avec tout ça, normalement, je devrais avoir vite codé l'export, non ? NON ? non.
Parce qu'il y a quand même du boulot : il faut récupérer plein de données en accédant à plein d'APIs, faire en sorte que les URLs soient toutes réécrites pour ne pas retourner sur les sites initiaux, télécharger les pièces jointes, et finallement produire du contenu (mais pour ça, je crois bien que ej vais passer par un quelconque (lire StringTemplate) moteur de templates Java. Mais, l'un dans l'autre, je suis confiant, même si on verra ce que l'avenir me réserve à ce sujet.
