eric.lemerdy

J'ai fait quelques logos pour contribuer au concours Agile France.

Edit :

Je recherche maintenant du feed-back pour les améliorer...

Acquisition du son

• Un dictaphone numérique Philips VOICETRACKER 600 qui enregistre en mp3 (Mono, 22050 Hz à 64kb/s) ; estimation du rapport temps poids : 2 minutes = 1 Mo.
  Les 512 Mo embarqués conviennent à mes besoins. Un port mini-usb permet de transférer les fichier mp3 sur l'ordinateur.
• Un microphone cheap de chez itworks (8 € !)
• Un microphone Sony stéréo d'occasion sur eBay (inutile pour le dictaphone qui est mono).
• Il est aussi possible de réaliser l'acquisition à partir d'un pc portable équipé d'un logiciel de capture mais de nombreuses perturbations électriques internes viennent brouiller l'enregistrement (bruit du disque dur, écran, et même processeur).
• Je n'ai pas retenu non plus la solution carte son externe (sur port USB). Même si on élimine le problème des perturbations électroniques, il est toujours nécessaire d'avoir son ordinateur allumé, ce qui est moins compatible avec un usage nomade.

Montage

• Pour un montage simple (sans mixage), je conseille :
  mp3DirectCut : un freeware qui supporte le découpage de la piste sonore (élimination des temps morts) et surtout l'application d'un gain sur la piste ce qui permet d'augmenter le volume - très utile en cas de prise de son un peu faible. Ce logiciel est dit "lossless", c'est-à-dire sans perte de qualité, il ne ré-encode pas la piste mp3. On obtient donc un fichier mp3 d'une taille égale après modification.
• Pour un montage plus sophistiqué, je me suis orienté vers le fameux :
  audacity : un logiciel libre qui permet de travailler une bande son. On peut faire la même chose que le précédent mais avec une perte de qualité à l'arrivée puisqu'il y a une phase de ré-encodage à l'enregistrement. En contrepartie, on peut par exemple mixer une musique avec les paroles.

Mise en ligne

Le couple gagnant : internet archive et feedburner.

• Internet archive est une organisation à but non lucratif qui souhaite lutter contre l'aspect éphémère d'internet en proposant d'héberger du contenu. Vous lui apportez de la richesse et lui vous héberge gratuitement, un bon deal, non ?
  Après avoir créé un compte (avec un openid par exemple), vous avez accès à une belle interface d'upload pour envoyer votre fichier (utiliser l'interface Ajax en beta, elle est plus efficace pour les fichiers volumineux). Ensuite, une page dédiée permet de centraliser les méta-données générées par l'envoi du fichier.
• Un flux RSS doit être mis en ligne. Moi, je le fais "à la main" pour y ajouter la pièce jointe (en fait, le lien vers le fichier MP3 hébergé par internet archive).
  

  <?xml version="1.0" encoding="UTF-8"?>
  <rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  	<channel>
  		<title>{titre}</title>
  		<link>{home page}</link>
  		<description>{description}</description>
  		<atom:link href="{lien vers le flux}" rel="self" type="application/rss+xml" />
  		<item>
  			<title>{titre de l'épisode}</title>
  			<link>{lien de l'épisode}</link>
  			<description>
  				{du html avec caractères échapés}
  			</description>
  			<enclosure url="{l'URL du fichier sonore}" length="{la taille en octets}" type="audio/mpeg"/>
  			<guid>{un identifiant unique, pourquoi pas l'url de l'épisode}</guid>
  		</item>
  		{d'autres item...}
  	</channel>
  
  </rss>

  Il est possible de gérer l'upload et l'intégration RSS directement dans un blog, mais c'est pour ceux qui ont de la place sur leur blog.
• Je n'ai plus ensuite qu'à enregistrer ce flux chez feedburner sans oublier de préciser qu'il s'agit d'un podcast pour obtenir les statistiques de téléchargement.

Conclusion

A moindre frais, avec un dictaphone numérique et son micro intégré, un mixage simple pour améliorer la prise de son en post-production sans perte de qualité et moyennant une mise en ligne légèrement fastidieuse, on peut créer des podcasts sans trop y passer de temps. C'est pour l'instant la méthode qui me garantit à la fois : de la mobilité lors de l'acquisition, des fichiers sonores pas trop longs à télécharger et une qualité satisfaisante à l'écoute.

• Lightning talks Outils logiciels
  • Sonar
  • Outils .Net
  • GreenPepper
• Lean Software Developement et Pratiques Agiles
• Pratiques d'ingénierie incrémentale
• Introduction à certains principes Lean
• De l'atelier à l'usine logicielle : Enjeux et retours d'expérience d'Orange Labs
• Une informatique hédoniste et responsable.

• Lightning talks Outils logiciels
  • Sonar
    • Qu'est-ce que c'est ?
      un outil de collecte et de visualisation de mesures faites sur le code source (java en premier lieu).
    • Eprouvé
      Il repose sur des briques d'analyse de code reconnues depuis longtemps déjà dans le monde java.
    • Riche
      Son interface web de reporting des mesures est agréable à consulter. L'analyse bi dimentionnelle sous forme de treemap (une métrique sur la surface, une autre sur la couleur) permet de comparer de façon les deux métriques choisies.
    • Manques
      L'outil manque peut-être selon certain d'une gestion des droits un peu plus fine pour raffiner l'accès aux mesures par projet. Je crois moins à l'argument avancé en session par un participant sur le masquage de certaines mesures "faille" à son client. L'agilité ne prônerait-elle pas une transparence sur les données projet ?
  • Outils .Net
    J'avoue ne pas être familier du framework .Net. Sans avoir pris de note, voici ce que j'en ai retenu. L'écosystème des outils semble à première vue couvrir tout le "cycle de développement". Entre parenthèses, le cycle présenté était certes itératif mais peu adapté à une stratégie de test-first. La force de Microsoft Team System serait l'intégration poussée de l'outillage. Par contre, la qualité de certaines briques serait inférieure à leur équivalent Open-source (notamment pour les Tests unitaires). Les présentateurs ont sentit la montée en puissance de l'écosystème. Ils tiennent à souligner l'effort de la communauté Alt.net qui pousse Microsoft à s'ouvrir de plus en plus. A en croire par le nombre croissant d'outils open-source qui sortent, ils obtiendraient une bonne attention de la part de l'éditeur. D'après ce que j'ai compris, Microsoft supporterai même certains outils open-source. C'est vrai qu'ils ont tout à y gagner si la contribution est de bonne qualité. Team System est déjà un outil ALM intégré alors qu'en java, ou avec les briques open-source ou gratuites de .Net, il faut se construire son propre ALM...
  • GreenPepper
    Une introduction pas si claire que ça sur la motivation du besoin des tests d'exigences automatisées a fait place à quelques écrans GreenPepper. Tout y est dans cet outil: le Wiki pour éditer les spécifications, la machinerie interne pour passer les tests sur le code de l'application, les fixtures à apporter pour fournir ce code liant. Cependant, on sent assez vite que GreenPepper souffre de quelques lacunes. Impossible par exemple de gérer en ligne de produit ces exigences fonctionnelles car la base des exigences est exportable mais pas rejouable dans le wiki. Il doit également faire face à une concurrence renforcée depuis 6 mois car Fitnesse bénéficie actuellement une forte activation de sa communauté grâce à la refonte du moteur de FIT vers Slim.
• Lean Software Developement et Pratiques Agiles
  Ce fut moi le speaker de cette session. Ma première contribution au XP Day fut donc d'expliquer le Lean Software Development aux participants. J'ai bien aimé l'exercice, Je me suis sentis assez à l'aise. C'est ma collègue Elisabeth Ducarre qui devait assurer la présentation mais elle n'était pas disponible. Le sujet me passionne beaucoup et semble être la méthode agile à découvir en 2009. La salle était comble et je m'en félicite. J'en profite pour vous parler du prochain Valtech AfterWork qui se tiendra la La Défense le 10 juin prochain. Cette session gratuite et ouverte à tous après le boulot vous permettra de rencontrer Elisabeth et moi pour une présentation approcfondie du Lean Software Development et sans doute quelques animations participatives. Elisabeth donne aussi un cours chez Valtech Training sur 3 jours pour apprendre à pratiquer le Lean dans votre organisation.
  J'ai finalement répondu au mieux aux diverses questions que la pratique du Lean n'a pas manqué d'éveiller chez l'auditoire. Je serai heureux de récolter vos commentaires sur ma présentation.
• Repas en compagnie d'un des alchimiste-agile. Une discussion passionnante sur le métier de coach.
• Pratiques d'ingénierie incrémentale
  Cette session a rencontré un succès certain puisque la salle était comble. Il est vrai que c'est toujours un plaisir d'écouter Eric Mignot. Cette fois-ci, il a fait le point sur les pratiques d'ingénierie incrémentale. Cette présentation sous forme d'échange avec l'auditoire avec peu de support powerpoint fut d'abord axée sur les différentes pratiques agiles qui permettent d'assurer une ingénierie incrémentale. Eric semble être un adepte de l'application de la méthode SCRUM aux individus. En particulier, il nous a parlé de sa méthode d'immersion dans les équipes qui consiste à ne pas imposer de pratiques mais à provoquer chez les équipiers l'envie de les pratiquer. Il maintient un backlog de tâches qu'il souhaite livrer à l'équipe. Par exemple, l'adoption des réunions quotidiennes n'est pas une cérémonie imposée, il préfère montrer à la machine à café par exemple que les gens ont besoin de ce point journalier pour avancer dans de meilleures conditions. Si on impose la cérémonie, le premier point douloureux est de trouver un horaire qui convienne à chacun des participants. Si je devais un jour avoir à être accompagné sur un projet ou passer le cap et faire de l'accompagnement moi-même, j'aimerai avoir la même aisance qu'Eric dans le domaine.
• Introduction à certains principes Lean
  Une courte session qui s'est faite légèrement manger par le discours d'Eric. Lean étant un sujet vaste, ce que je retiens de cette présentation est de ne pas forcément chercher à tout automatiser. Il a plutôt préconisé de tenter d'éxécuter l'activité manuellement pour bien mesurer si il existe un bénéfice à l'automatiser. L'orateur n'avait pas beaucoup d'aisance et cela s'est ressentit sur le succès de sa présentation.
• De l'atelier à l'usine logicielle : Enjeux et retours d'expérience d'Orange Labs
  L'ALM est aux portes de nos organisations, mais la route reste encore longue quand on souhaite bâtir cette solution avec les produits existants. Orange Labs nous a fournit un retour d'expérience pertinent sur l'état de leurs travaux dans le domaine. Lorsqu'ils réalisent un développement sur une des briques open-source, ils n'ont pas peur de le verser dans la communauté. C'est un signe de maturité face à l'adoption de l'open source.
  Quelques accroches: "de l'atelier à l'usine logicielle", "de l'intégration continue à la synchronisation continue", "le statut du projet sur le serveur d'intégration continue est la seule référence valable".
  L'objectif de leur unité: assurer la répétabilité temporelle et spatiale de la production des livrables logiciels. Temporelle car on souhaite pouvoir régénérer à l'identique un livrable produit précédemment, spatiale car on souhaite que ce comportement soit valable non seulement sur tous les postes de développement de l'équipe, mais aussi sur tous les projets que l'organisation héberge.
  Pour arriver à ce résultat, toutes les solutions ne sont pas encore mûres. Voyons ce qu'il existe et ce qu'il reste à faire:
  Solutions mûres:
  
  • gestion des dépendances: avec Maven, les projets modulaires déclarent de façon versionnée leur dépendances aux librairies externes.
  • gestion de configuration: avec Subversion, on assure une historisation du code source indispensable au développement collaboratif.
  • intégration continue: L'outil Hudson assure que la compilation du logiciel est automatisé, des tests automatisés peuvent être passés sur cette plate-forme pour en valider la qualité. On peut aussi générer de la documentation, des mesures qualitatives sur le code à ce moment et packager les livrables automatiquement.
  • portail de mesures: Sonar permet d'exécuter et d'historiser les mesures qualitatives sur le code source.
  • référentiel de livrables: un repository maven permet à un service de peupler une base de libraires provenant des contributions open-source mais aussi issu de ses propres développements
  • "tracker": l'outil Jira permet de gérer l'ensemble des anomalies et évolutions sur un composant. Aujourd'hui, leur solution est basée sur un plugin maven qui automatise le commentaire de commit en associant automatiquement une modification de code à un ticket de la base. Cela leur permet aussi de générer automatiquement la release note d'une version non pas simplement en tant que liste de fichiers qui ont évolué dans la gestion de configuration mais surtout en termes de bugs résolus et d'évolutions apportées par requêtage de la base Jira.
  Solutions à mûrir:
  
  • Automatisation du déploiement de l'usine logicielle: Même si ils arrivent aujourd'hui à un bon niveau d'intégration des briques, ils souffrent encore du temps nécessaire pour déployer ces outils sur chacun des projets qu'ils ont à gérer. La voie de la virtualisation est une bonne piste pour constituer des serveurs "scalables" à mettre en place par projet. De même, la configuration du poste client prend encore pas mal de temps (retour d'expérience de Bull).
  • Trop de portails: un portail pour les builds, un pour le suivi des mesures qualitatives, un pour les sites générés au build: ils travaillent donc tout d'abord sur les liens inter-sites pour qu'ils soient au moins liés entre eux
• Une informatique hédoniste et responsable.
  Session rafraichissante sur les parallèles entre la philosophie hédoniste (opposée à la philosophie idéaliste platonicienne bien répandue dans notre société occidentale). Un appel a participation à un manifeste hédoniste a été lancé en ouvrant la participation à des philosophes ou des profils sciences humaines.

This is a list of improvements of the lastest version:

• Use a checkbox for the "Report On Success" parameter.
• Hide non mandatory parameters in an "Advanced..." section.
  
• Text-To-Speech messages supports "${projectName}" and "${buildNumber}" special syntax to be more expressive (instead previously of adding project name and build number automatically at the end of the TTS).
  
• Add help for each parameter.
  

The version is available here: nabaztag-1.5.hpi.
The wiki page also contains a new section to request changes. A Jira for such a little plug-in seems oversized, no ?