Droit à l’oubli du code

Vous n’y avez sans doute pas échappé, Google Code a fermé ses portes. Dommage, j’aimais bien, quand il a démarré, ce service. Et j’y avais quelques projets …

J’aurais pu, pourtant, exporter ses projets pour les mettre dans un quelconque git. Mais je ne l’ai pas fait.

Parce que même si certains de ces projets étaient intéressants (majick-properties, en particulier), je crois qu’il faut savoir certaines choses disparaître dans un oubli relatif (puisque de toute façon, the internet wayback machine se souvient de tout).

Publicités

Plus de vagues

Je suis quand même une tanche, moi.
hier, l’un des premiers trucs que j’ai voulu faire avec Google Wave a été d’envoyer un message posterous pour dire à quel point c’était bien.
Malheureusement, je n’avais pas vraiment compris le fonctionnement des Blips
Et surtout le fait qu’il fallait cliquer sur le bouton « done » avant de cliquer sur le bouton « login to posterous ». Maintenant que je suis loggé, j’en profite.
Et je peux donc vous dire qu’à mon avis, la feature qui fera décoller Google Wave (et peut-être le marchand de saucisses) sera l’édition de code collaborative à travers le web, un peu à la façon de Bespin » Code in the Cloud , ce qui ne sera peut-être pas trivial à implémenté, mais vachement pratique pour les boîtes distribuées.
Pour être pragmatique, qu’est-ce qu’il faut pour implémenter tout ça ?

  • Un gadget pour éditer du code avec de la coloration syntaxique (un peu comme KaSyntaxy – Google Wave Bots Wiki )
  • Un outil qui sauvegarde automatiquement le code dans un SVN/GIT en tenant compte de l’utilisateur de wave
  • Et un serveur d’intégration continue façon Hudson.

Et avec ça, on pourra facilement produire du code (mais pas forcément le débugger) depuis son navigateur.
Je me demande si d’autres ont déja pensé à cette idée … (en tout cas, d’autres ont déja posé la question).
je sais qu’il eixste aussi déja des waves de jeux de rôle : Google Wave RPGs = Excellent Experience!
Bref, Wave ne va pas tarder, à mona vis, à devenir un outil génial pour la collaboration en « live ».

Tester l’utilisation de la mémoire

Dans majick-properties, je suspecte le code que j'ai écrit d'être potentiellement à l'origine de fuites de mémoire. Et ça, c'est plus qu'embêtant quand on fait une bibliothèque dont le but est de faciliter la vie.

Surtout que, traditionnellement, la chasse aux fuites mémoires en Java est compliquée : il faut un profiler (en Java, le meilleur rapport qualité/prix est obtenu avec le profiler de NetBeans), trouver le truc qui foire, le corriger, et espérer que ça tienne 

360

Heureusement, la communauté Java dispose maintenant de méthodes permettant de vérifier que ces fuites de mémoire ne reviennent pas. La première que j'ai trouvé utilise une librairie dont le nom seul est un hommage au bont goût : insane. Et la deuxième utilise jUnit pour parvenir au même résultat, ce qui fait que je vais pouvoir utiliser les concepts dans mes tests. Je me demande quand même s'il ne va pas falloir que je regarde insane de prés pour améliorer ça, parce qu'en fait, cette deuxième solution ne semble pratique que quand on sait précisément ce qu'on cherche, alors que la première est plus efficace en terme d'exploration.

Tiens, au fait puisqu'on parle de mémoire en Java, il semble que cet article : understanding weak references, soit une mine d'infos sur les distinctions subtiles entre weak, soft et phantom references.

Un peu de code ?

Ben oui, après tout, je suis développeur Java, j'aimerais donc pouvoir, de temps en temps, me faire un blog avec du code dedans.

Du coup, comme maintenant, je découpe, je suis à la recherche d'un "bon" site de snippets. J'en ai déja vu plusieurs :

  • snipplr a un étonnant look façon journal, qui rend les snippets très lisibles, des flux RSS par utilisateur (qui, après un rapide passage dans le vieil IE, n'apporte pas beaucoup d'infos), un gem ruby pour faire je ne sais pas quoi avec …
  • pastie ne gère pas les utilisateurs, et n'est donc pas adapté à mon besoin
  • friendsnippets se paye une sale tête de communauté (y compris les limitations du flux RSS), et à part ça ressemble beaucoup à snipplr, mais sans la possibilité d'ajouter du texte à coté des snippets
  • DZone est un peu moins joli, mais aussi complet que snipplr et, surtout, surtout, inclut le code source dans le flux RSS. Ce qui en fait le vainqueur évident de ce rapide comparatif !

Donc pouf, je me crée un code chez DZone, et je l'inscrit dans mon ziki. Faudra que je vous parle plus tard de mon lifestream en projet, tiens …

Avancement

Bon, je viens de faire la demande d’enregistrement du projet chez sourceforge. Maintenant, il faut trouver des implémentations des fonctionnalités dont je disposais en Rails. Surtout que j’ai pris une décision historique, structurante, dingue.Comme dans yaki, je vais stocker mes données dans des fichiers plats. Grâce à la FAQ, on apprend en effet que Rui considére les éditeurs dans des pages web peu convaincants. Et, à bien y réfléchir, et même si j’édite actuellement une entrée dans une page web, je suis plutét d’accord avec lui. Je veux dire que, même si on peut faire des trucs dans ce genre d’éditeur, rien ne nous empêche de faire de même dans, par exemple, un fichier YAML (L’une de mes meilleures découvertes en Ruby, YAML dispose de plusieurs implémentations Java : jyaml et jvyaml. Ce dernier bénéficie de l’avantage énorme de faire partie de JRuby.). Et puis, une fois que je serais capable de traiter mes fichiers YAML correctement, je pourrais facilement créer une page générant mon fichier YAML. Bon, ça, c’était pour le gros changement. Après, il y a toutes les réimplémentations de la liste des fonctionnalités prévues.

  • Un arbre des catégories, qui existe, je crois, dans Wicket, mais pour lequel il ne faudra pas oublier le tag à utiliser dans les pages
  • Le support des commentaires et des trackbacks, qui se fait pour sa majeure partie à la main, enfin je crois
  • Une administration facile des utilisateurs, des commentaires et trackbacks, des pages
  • ‘intégration des ASIN d’Amazon (Voir par exemple a4j)
  • L’i18n, aussi bien pour les articles que pour l’appli. Au moins, pour l’appli, ça a l’air simple : wicket i18n
  • La coloration syntaxique multi-langage, grâce à un bout de Javascript trouvé sur google code : syntaxhighlighter, à moins que ce ne soit pretify. Dans tous les cas, c’est vraiment pas compliqué à intégrer (car complétement codé en javascript) et ça, c’est bien !
  • L’inclusion de flux RSS (comme ma page LinuxFr) doit pouvoir se faire raisonnablement facilement (voir sur Java-source)
  • La recherche se fera évidement avec Lucene, j’espére juste qu’il s’intégre bien dans Wicket …
  • lien automatique des articles proches. Comme je ne l’avais pas encore codé en Ruby, je ne sais pas si c’est facile. En revanche, ce que j’avais déja fait, et qui était raisonnablement simple, c’est les liens entrants/sortants.
  • Les flux RSS, bon ben c’est comme l’inclusion de sources RSS, sauf que ça a l’air plus facile (voir code poet)
  • du HTML dégradable pour mon futur n800, ça, c’est plus une façon de faire (D’autant moins importante que le n800 utilise Opera8 !)
  • Le nuage de tags, c’est pas bien compliqué à faire, ça
  • L’authentification, avec Wicket a l’air de se faire assez bien (comme le montre cet article)
  • Générer des graphes des liens entre pages, auteurs, commentaires et autres devrait se faire avec une quelconque API de graphe Java, mais je vous en reparlerai plus tard.
  • Le CSS (Cascading Style Sheets) se fera comme je l’ai déja dit avec Blueprint
  • Et pour OpenID, on verra plus tard.

Bon, ben ça me fait du boulot, tout ça, hein. Alors allons-y !

Encore un peu plus de Wicket

L’une des choses que je souhaite garde de Le bliki, c’est l’idée de ne pas tout faire moi-même et, plus précisément, de m’appuyer sur les bons outils.L’idée, c’est donc de choisir un bon ensemble d’outils. Et, suite à la lecture d’un article fascinant de Wicket, je pense que jebliki sera une application Apache Wicket.Mais bon, avant tout ça, il faut d’abord les bases, c’est-à-dire que mon serveur Ubuntu dispose d’une JVM moderne et d’un Tomcat en état de marche. Heureusement, il semble que ce soit assez facile (voir par exemple la documentation Ubuntu). Bon, bien sûr, il me faudra le support des syntaxes Wiki (ah, j’ai le choix, on dirait).Il me faudra aussi de belles feuilles de style. Mais, d’après Nicolas Mérouze, BluePrint, c’est bien. Et puis bien sûr, il y a toutes les fonctionnalités que j’ai eu la bonne idée d’indiquer dans le gestionnaire de projet de Le bliki. Pour certaines d’entre elles, j’ai des idées … mais pour les autres, c’est le brouillard complet ! Et, surtout, ce qu’il ne faut pas oublier, c’est que j’ai déjà un excellent prototype ! Pour finir cette espèce de fourre-tout, j’ai déjà pas mal de trucs à faire :

  • Installer Java et Tomcat sur mon Ubuntu
  • Créer un projet ailleurs (pour la sauvegarde, la gestion de projet, les listes, …)
  • Créer un environnement de dév qui marche sur mon iBook , Linux et Windows. Heureusement, comme c’est du java, je sais à peu prés ce qu’il faut faire
  • Me documenter sur les briques que je pourrais utiliser pour l’authentification, l’autorisation, et tous les autres trucs faits avec des plugins rails. Je pense que je ferais une liste d’équivalence un peu plus tard.

Allez, je vous laisse, ce portable commence à être à sec de batterie !

Le Bliki meurt, mais JeBliki va prendre sa place

Hien ? Quoi ? comment ?Bon, je vous explique. Depuis 6 mois, le bliki est au point mort pour une raison assez simple : un bug. Un seul bug ? oui, un seul bug. Mais alors, quel bug ! Figurez-vous que lorsque, dans une entrée du bliki, je mets un AmazonAsin, toute l’application freze car, apparement, une transaction se termine mal ou je ne sais pas quoi. Coup de bol, ce comportement déviant est reproductible dans mes tests unitaires. Enfin, coup de bol, j’en sais rien car, même si le comportement se reproduit, le fait d’avoir un test unitaire ne change absolument rien à mon incapacité à résoudre le bug. Du coup, n’étant pas qu’un imbécile, j’ai réfléchi. Beaucoup réfléchi. Et j’en suis arrivé à une conclusion aussi simple que poignante. Même si Ruby et Rails sont trés bien, ce couple langage/framework n’est pas pour moi. Enfin, si, mais non. En fait, il se trouve que je pense tout simplement qu’un langage n’est utile qu’à condition d’être pratiqué. Or, il se trouve que, pour mon plus grand bonheur, je ne fais que du java et, plus particulièrement, du Swing. Alors bien sér, tenter de me construire un blkiki en Ruby, même si à priori, c’est trés chouette, c’est un peu infaisable. Qui plus est, je commence à entrevoire certaines des failles les plus gênantes du Ruby, comme par exemple l’absence d’un debuggeur …Du coup, je vais reprendre en java tout ce que j’ai fait en Ruby, avec bien sûr quelques modifications d’ordre technique. Mais, promis, je vais essayer de garder l’esprit du truc, et en bonus ajouter des idées prises chez Rui Carno, comme le fait de stocker les données dans des fichiers, au lieu d’une base de données qui n’a que des avantages marginaux. Bon, c’est pas tout ça, mais maintenant, faut que je me mette au boulot !