Traces (log) dans les applications

On m’a récemment demandé d’expliquer quelles étaient les bonnes pratiques en terme de trace dans les applications. Voilà rapidement mon opinion sur le sujet.

Tracer, pour quoi faire?

Les traces servent à raconter ce qui se passe dans la partie cachée d’un programme informatique. Cette partie cachée étant tout ce qui n’est pas visible par l’utilisateur final. En fonction de leur niveau (ERROR, WARNING, INFO, DEBUG), elles ne s’adressent pas à la même personne, mais elles sont indispensables pour:

  • surveiller simplement l’activité de l’application. Sans parler des capacités des outils de trace moderne comme log4j, un simple tail sur un fichier de log permet de surveiller simplement l’activité d’un programme.
  • savoir ou, quand et surtout dans quel contexte une erreur est apparue
  • permettre au développeur d’analyser un problème sans qu’il soit nécessaire de le reproduire sur son poste

Ce dernier point est particulièrement important, et l’ensemble des bonnes pratiques à mettre en place visent à améliorer cette capacité d’analyse.

Lire la suite

Témoignage pour le guide « Libre Association »

Je me suis récemment inscrit sur la liste de diffusion de « Libre Association », un groupe de l’April, association dont je suis membre. Alors qu’ils élaboraient la prochaine version d’un guide sur les logiciels libres, j’ai mentionné l’existence de Project-1901. Le logiciel n’est manifestement pas encore assez abouti et/ou accessible pour être indiqué pour une association (et je suis d’accord sur ce point), mais ils m’ont demandé d’écrire un témoignage, ce que j’ai fait sur leur page wiki dédiée. Voici mon texte original reproduit ci-après

Développement d’un logiciel de gestion d’adhérents: Project-1901

Qui témoigne ?

Je suis Julien Béti, aka Motofix, 35 ans. Je travaille chez un éditeur en tant que « Responsable Méthodes et Outils » (Infrastructure / Usine de production logicielle / Socle Technique). Plongeur, je suis membre du CA et responsable informatique du CNHC, Club Nautique de Houilles et Carrières-sur-Seine, qui regroupe les sections Aquaforme, Éveil Aquatique, Natation, Nage avec Palmes en plus de la Plongée enfants et adultes (1059 adhérents cette année).

Comment Project-1901 est-il né ?

La section Plongée est animée par des moniteurs et encadrants bénévoles, qui ne comptent ni leur temps ni leurs efforts pour faire découvrir et enseigner la plongée. Adhérent au CNHC depuis plusieurs années, j’y ai passé mes niveau jusqu’au N3, mon grade actuel. Il y a 4 ans, lorsque le club a annoncé rechercher de l’aide pour remplacer le responsable informatique actuel, j’ai trouvé là l’occasion remercier le club, et j’ai répondu présent.

La gestion des adhérents était alors effectuée via un logiciel « client lourd » maison, très spécifique à chaque section, développé depuis des années sur une plate-forme propriétaire. Je tiens à saluer l’effort qu’a représenté ce logiciel, développé et mis en place par un non-informaticien. Le résultat était plus qu’honorable, et bien intégré par les utilisateurs. Mais plusieurs raisons m’ont amené à proposer une alternative:

  • Technologie lourde, propriétaire et obsolète. J’ai vraiment eu du mal à m’y mettre, la maintenance était difficile
  • Une application spécifique par section, et une dernière application pour re-centraliser les données (via échanges de fichiers, export / imports douloureux)
  • Pas de base centralisée accessible par les responsables du CA

Mon activité professionnelle évoluant, je voulais conserver une activité de développement, en en profitant pour me former à de nouvelles technos (Hibernate, ExtJS,…). Voilà l’occasion de joindre l’utile à l’agréable: je développerai l’alternative proposée.

Licence Libre ?

J’utilise le logiciel libre depuis des années, et pour moi les licences libres s’imposent d’elles-même dans le milieu associatif. Le développement de ce logiciel est ma contribution bénévole à mon club. Cela étant dit, dans le milieu du logiciel libre comme ailleurs, je supporte assez mal que le travail bénévole des uns enrichisse financièrement les autres. Ainsi, mon logiciel n’est placée sous licence libre que dans le cadre d’une activité à but non lucratif.

Travailler sur la HEAD d’abord

Les bugs sont souvent levés sur une branche « stable » ou encore « de production », et il semble donc naturel de corriger l’erreur d’abord sur cette branche, puis de reporter les modifications sur la HEAD.

Je pense que c’est une erreur. Dans un monde où on prendrait le temps de corriger et tester aussi bien sur une branche que sur une autre, fût-elle la HEAD, ça ne devrait pas avoir d’importance. Malheureusement, on est plus dans des optiques de « quick, dirty and auto-merge »… Autant limiter la casse, avec un seul objectif en tête: que le futur soit meilleur.

Privilégier l’état du code actuel

La première raison est de privilégier le code tel qu’il est sur la HEAD. C’est le « vrai » code présent, et surtout la seule base logique des développements futurs.

Lorsqu’on appréhende la correction d’un bug ou l’implémentation d’une évolution, il faut donc l’optimiser et la penser avec l’état présent du code, puis ensuite l’adapter au code ancien. Si cet effort n’est pas fait:

  • Le code de la HEAD finit par n’être qu’une adaptation de merge de code ancien.
  • L’éventuel objectif d’amélioration de l’architecture sur la HEAD se retrouve brouillée / parasitée par du code « à l’ancienne ».

Profiter des dernières avancées technologiques

C’est sur la dernière version du logiciel que les dernières technologies, architectures et versions d’API sont intégrées. En Java, ces intégrations peuvent être par exemple une nouvelle version du JDK, le passage à J2EE 6 (ou à OSGi!), ou encore la mise à jour de toutes les librairies Commons Apache.

Si les développements ne sont pas d’abord faits sur la HEAD, ils ne sont pas adaptés dès leur conception à ces changements. On peut ainsi voir du code « neuf » ne pas profiter des avancées du JDK 1.5 juste parce que les développements ont été faits sur une branche plus ancienne qui ne le supportait pas.

Maximiser les chances de résolution rapide des régressions

Il paraît évident que plus un bug est détecté tôt, moins il coûte cher à tout le monde (éditeur, client et utilisateur). On s’acharne donc à mettre en place une palanquée de mesures pour « traquer le bug » au plus tôt: développement en binôme, tests unitaires, outils d’analyse de code, intégration continue, tests automatiques, tests manuels, recette…

Plus on s’éloigne dans cette chaîne, plus le coût de correction est élevé. Si en plus on ajoute le facteur temps, c’est à dire la durée écoulée entre le moment où le code a été écrit et le moment où le bug a été trouvé, les coûts explosent. En effet, le développeur qui aura à corriger le bug ne sera plus dans le contexte, sera peut-être même une personne différente de celle qui a écrit le code, etc. Les risques de régression suite à cette correction deviennent non seulement importants, mais surtout difficiles à évaluer.

Les premiers éléments de cette chaîne (binôme, tests unitaires, intégration continue) sont censés prévenir tout risque de conception ou de régression et sont effectués quelque soit la branche. Les derniers éléments (tests automatiques et manuels, recette) sont sensés tester l’ensemble des processus métiers de manière exhaustive, et passer de manière systématique sur chaque version « officielle ».

Dans la pratique, non seulement il est rare de voir des tests unitaires nombreux, entretenus et pertinents, mais en plus ils ne permettent pas de mettre en évidence les bugs les plus complexes liés à l’exécution d’un workflow métier complet. Les tests automatiques et manuels quant à eux se focaliseront plus volontier sur des workflows métier particuliers sur une livraison de branche de prod, ceeux-là même qui sont impactés par la correction /évolution effectivement attendue. De plus, ils seront exécuté rapidement après le développement. Sur HEAD au contraire, les tests manuels et automatiques, même complets, seront non seulement moins focalisés sur des processus précis, mais en plus seront exécutés bien après le développement: au moment de la première livraison de la future version majeure.

Dans ce contexte, imaginons maintenant qu’une correction, ou pire une évolution, s’intègre assez mal entre la HEAD et une branche de production d’une application, ce qui arrive relativement souvent ;-):

  • Dans le cas où la correction est d’abord conçue et effectuée sur la branche, la correction sera faite plus vite mais entraînera des régressions sur la HEAD, lesquelles ne seront détectées que…trop tard.
  • Dans le cas où on s’occupe d’abord de la HEAD, les éventuelles régressions introduites sur la branche seront immédiatement trouvées, puisque la fonctionnalité incriminée sera intensivement et rapidement testée.

En conclusion…

Bien sûr, c’est surtout vrai pour les éditeurs dont le but n’est pas de faire du code jetable, qui partent rarement de la page blanche et qui souvent, si il est petit face à ses clients, sera forcé de faire des évolutions sur branche issue de branche de production, à l’inverse de toute logique, entraînant des coûts en terme de temps, d’argent et de motivation.

Ce coût doit être calculé pour couvrir la surcharge de travail que peut entraîner, à court terme, l’application de cette recommandation: travailler sur la HEAD d’abord. Les économies seront réalisés dans la maintenabilité, l’évolutivité et la compétitivité des développements futurs.

Contrôle technique

Rien de surprenant: plus c’est urbain et plus ils font de pub, plus c’est cher ;-):

  • Contrôle Technique Lainvillois, chem Loison 78440 LAINVILLE EN VEXIN: 65€
  • Autovision Auto Bilan du Vexin Adhérent, 5 r Gutenberg ZI DE LA DEMI LUNE 95420 MAGNY EN VEXIN: 65€
  • Autobilan Barrat Et Cie, 45 r Fossettes 95650 GENICOURT: promotion 65€
  • Autovision Auto Bilan Cergy Affilié, 1 chem du Clos 95650 PUISEUX PONTOISE : 70€
  • Autovision CSK Contrôle Centre agréé, carrefour de la Demi Lieue 15 rte Gisors 95520 OSNY: 70€
  • Cergy Controle Auto, 71 r Francis Combe 95000 CERGY: 72€
  • Norisko Auto, 11 chem Chapelle St Antoine 95300 ENNERY: 77€

Au final, je suis allé à Lainville, où j’ai été très bien accueilli par le propriétaire des lieux, qui m’a en plus fait un prix pour les 2 voitures (62€ chacune).

Le téléphone sonne sur France Inter: « Autos et motos : la paix est-elle possible ? »

Mise à jour 2011-08-20: le sujet n’a pas trompé beaucoup de monde, manifestement les gens partagent plutôt mon avis: ça se passe globalement très bien, et il n’est donc pas question de « paix » puisqu’il n’y a pas de « guerre ». Le débat a très vite dévié vers des sujets de sécurité routière, avec les clichés et argumentaires habituels, de part et d’autre.

Publicité Sécurité Routière: Partageons la routeOn ne peut pas leur en vouloir faire de l’audience, mais la question et l’introduction au débat est clairement orienté vers la polémique:

Autos et motos : la paix est-elle possible ?

Automobilistes et motocyclistes cesseront-ils un jour de se disputer dangereusement la route ?

Comment parvenir en France à une cohabitation pacifique et courtoise entre deux-roues et quatre-roues ?

J’ai écrit une réaction, qui n’est pas encore publié:

Je fais 100km/jour à moto pour me rendre à mon travail dans l’ouest Parisien. 99.9% des automobilistes ont un comportement admirable avec les motards, et je profite de cette tribune pour les remercier une fois encore.

99.9% des motards sont aussi des personnes responsables et conscientes que de mauvaises habitudes, une erreur d’inattention ou une infrastructure routière mal conçue et mal entretenue peut la tuer.

Je pense que la question est orientée et donc mal posée. La cohabitation pacifique et courtoise existe déjà. Les bonnes questions seraient:

  • Comment éviter la mise en place d’infrastructures meurtrières?
  • Comment inciter à l’achat d’équipements de sécurité sans ressembler à un arbre de noël?
  • Comment intégrer la perception des usagers fragiles de la route dans le cursus du passage du permis?

La FFMC sera manifestement présente lors des débat. J’espère qu’elle réussira à orienter celui-ci vers quelque chose de plus positif…

Project-1901 en Bétâ… et en prod!

Project-1901 est un logiciel de gestion d’association type « loi 1901 ». Il est hébergé sur SourceForge

En développement depuis plus de 2 ans, le projet vient de connaître des étapes importantes puisque les dernières modifications lui ont permis de passer en production pour la gestion de l’association CNHC (Club Nautique de Houilles et Carrières sur Seine), qui comporte plus de 1000 adhérents actifs, et un historique de plus de 3000 adhérents qui ont été « migrés » avec succès.

À cette occasion, Project-1901 est donc passé en Bétâ et une nouvelle version 0.02.01 a été déposée sur SourceForge. La liste des fonctionnalités couvertes dans cette version est:

  • Configuration souple
    • Multi-association: sélection basée sur le nom DNS
    • Saisons, Sections et Catégories
    • « Éléments » de Section:
      • Persistants sur les saisons ou non
      • Obligatoires ou non
      • À liste de valeur ou à saisie libre
      • À sélection multiple ou non
      • Avec un coût ou non
  • Gestion des rôles au niveau de l’association et au niveau des sections
  • Gestion des paiements
  • Vérification de la validité des membres
  • Processus d’identification lors de la création d’un nouveau membre pour éviter les doublons
  • Fonctionnalité d’envoi de courriels
  • Création de rapports facilité (JasperReports)

Un effort particulier a été fait pour la documentation du modèle de donnée, en attendant les fonctionnalités d’administration du référentiel. Pour le moment il est en effet nécessaire d’effectuer toute la configuration directement en base…

Pour aller plus loin:

La prochaine étape est le développement de la gestion de l’assemblée générale…

PicassaRSS2File

Edit: je ferai évoluer ça

Vite fait un petit programme Java qui permet de télécharger les photos d’un album Picassa grâce à son flux RSS. Il manque plein de chose pour qu’il soit facile à utiliser mais bon.

  • Sauvegarder le flux RSS dans un fichier (par exemple in.xml)
  • Lancer le programme en redirigeant la sortie (java -cp . PicassaRSS2File ./in.xml > go.sh)
  • Lancer go.sh

Code à 2 balles:

import org.xml.sax.*;
import org.xml.sax.helpers.*;

public class PicassaRSS2File extends DefaultHandler{

    private int index = 0;

    public static void main(String[] args) throws Exception {
        XMLReader saxReader = XMLReaderFactory.createXMLReader();
        saxReader.setContentHandler(new PicassaRSS2File());
        saxReader.parse(args[0]);
    }
    public void startElement(
        String uri,
        String localName,
        String qName,
        Attributes atts) throws SAXException {
        if (localName == "enclosure") {
            System.out.println(
                "wget -O img" + 
                this.index + ".jpg \"" + 
                atts.getValue("url") + "\"");
            this.index++;
        }
    }
}

Journée internationale contre les DRM – édition 2011

Bannière journée internationale contre les DRM

Dans son combat contre les DRM, l’April soutient la Journée internationale contre les DRM de la Free Software Foundation (Fondation du Logiciel Libre) le 4 mai 2011. Cette journée est l’occasion de rappeler à quel point ces menottes numériques sont dangereuses pour les utilisateurs comme pour les développeurs de logiciels libres, et empêchent certains usages légitimes sur les contenus numériques.