eric.lemerdy

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 11 mars 2012

Start and stop mongodb with Junit in java

package fr.lemerdy.eric;

import com.mongodb.*;
import org.fest.util.Files;
import org.junit.AfterClass;
import org.junit.BeforeClass;
import org.junit.Test;

import java.io.BufferedReader;
import java.io.File;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.UnknownHostException;
import java.util.ArrayList;
import java.util.List;

import static junit.framework.Assert.assertNotNull;
import static junit.framework.Assert.fail;
import static org.fest.assertions.Assertions.assertThat;

public class AbstractMongoTest {

    @BeforeClass
    public static void start_database_as_a_forked_process() throws IOException, InterruptedException {
        File dbPath = ensureDbPathDoesNotExits();
        assertThat(dbPath.mkdir()).isTrue();
        List lines = startMongoDBAsADaemon();
        assertThat(lines.get(0)).startsWith("forked process: ");
        assertThat(lines.get(1)).startsWith("all output going to: ").endsWith("logpath");
        assertThat(lines).hasSize(2);
        assertThatConnectionToMongodbIsPossible();
    }

    private static List startMongoDBAsADaemon() throws IOException, InterruptedException {
        ProcessBuilder processBuilder = new ProcessBuilder("../../mongodb-osx-x86_64-2.0.3/bin/mongod", "--dbpath",
                "dbpath", "--fork", "--logpath", "logpath");
        processBuilder.directory(new File("target"));
        processBuilder.redirectErrorStream(true);
        Process pwd = processBuilder.start();
        BufferedReader outputReader = new BufferedReader(new InputStreamReader(pwd.getInputStream()));
        String output;
        List lines = new ArrayList();
        while ((output = outputReader.readLine()) != null) {
            lines.add(output.toString());
        }
        pwd.waitFor();
        assertThat(pwd.exitValue()).isEqualTo(0);
        return lines;
    }

    private static void assertThatConnectionToMongodbIsPossible() throws InterruptedException, UnknownHostException {
        Mongo server = null;
        try {
            while (server == null) {
                Thread.sleep(250);
                server = new MongoURI("mongodb://127.0.0.1").connect();
            }
            assertThat(server.getDatabaseNames()).hasSize(1);
        } finally {
            server.close();
        }
    }

    private static File ensureDbPathDoesNotExits() throws IOException {
        File dbPath = new File("target/dbpath");
        if (dbPath.exists()) {
            Files.delete(dbPath);
            assertThat(dbPath.exists()).isFalse();
        }
        return dbPath;
    }

    @Test
    public void should_connect_to_the_test_database() throws Exception {
        Mongo mongo = new Mongo();
        try {
            DB test = mongo.getDB("test");
            assertThat(test.getCollectionNames()).isNotNull();
        } finally {
            mongo.close();
        }
    }

    @AfterClass
    public static void shutdown_mongodb() throws IOException {
        Mongo mongo = new Mongo();
        try {
            DB db = mongo.getDB("admin");
            CommandResult shutdownResult = db.command(new BasicDBObject("shutdown", 1));
            shutdownResult.throwOnError();
            fail("Expecting to loose mongodb connection on shutdown.");
        } catch (Throwable e) {
            assertThat(e.getMessage()).isEqualTo("can't call something : /127.0.0.1:27017/admin");
        } finally {
            mongo.close();
            ensureDbPathDoesNotExits();
        }
    }
}
Edit:
A github project has been created
Thanks to Florent Ramière, an elegant solution based on Rules has been provided. I am grateful to him.

samedi 25 février 2012

How to execute a command when a file change ?

Use incron ! It is similar to cron that triggers commands based on time. Incontab triggers commands based on file system changes.

1. Install incron

sudo apt-get install incron

2. List your incron jobs

incrontab -l
returns :
user 'ericlemerdy' is not allowed to use incron

3. Authorize your user to have incron job

sudo whoami >> /etc/incron.allow

4. List your incron jobs

incrontab -l returns :
no table for ericlemerdy

5. Add a job to your incron

incron -e
Your text editor is now opened, ready to add your first job.

5. Help on job syntax

man 5 incron
The syntax is :
<path> <mask> <command>
Incron will examine your <path> based on the <mask> that can be IN_ACCESS or IN_MODIFY for exemple and then executes your <command>>.
Exemple :
/home/ericlemerdy/tutorial.txt IN_MODIFY pandoc -s --webtex -i -t slidy $@ -o /home/ericlemerdy/tutorial.html
This jobs inspects the file /home/ericlemerdy/tutorial.txt. Every time the file is modified (according to the IN_MODIFY mask), a documentation is generated through a command.
Note the use of $@ in the command. This is replaced with the examined path.

6. Tracking job execution

You can follow the incron activity through the syslog :
tail -f /var/log/syslog
You should get :
Feb 25 17:29:36 harukiya incrond[21714]: starting service (version 0.5.9, built on May 10 2010 14:59:40)
Feb 25 17:29:36 harukiya incrond[21715]: loading system tables
Feb 25 17:29:36 harukiya incrond[21715]: loading user tables
Feb 25 17:29:36 harukiya incrond[21715]: ready to process filesystem events
Feb 25 17:59:49 harukiya incrond[21715]: table for user ericlemerdy created, loading
Feb 25 18:01:23 harukiya incrond[21715]: (ericlemerdy) CMD (pandoc -s --webtex -i -t slidy /home/ericlemerdy/tutorial.txt -o /home/ericlemerdy/tutorial.html)

Conclusion

Incron can be very helpful to execute your tests when your code change or generate a webpage when the sources are changing.

jeudi 22 juillet 2010

HTML5 with Peter Lubbers 3/3

Ce billet est le troisième et dernier sur le compte rendu de la soirée avec Peter Lubbers hébergée par Zenika le 7 juin dernier. Reprenons où nous avions laissé ce compte-rendu.

WebSocket

C'est une nouveauté "invisible" qui concerne plutôt la communication sous jacente. Http, le protocole de communication qui sert les documents HTML n'a pas été conçu pour ce que l'on appelle aujourd'hui le "Real-time" web qui nécessiterait plutôt un protocole connecté de type Socket. Avec Http, on ne peut qu'envoyer une requête à laquelle un serveur répond. Pour obtenir une dynamique côté client, on serait tenté de faire des rafraichissements de page. Le problème, c'est qu'à chaque fois, on obtient des tas d'informations dans les entêtes. Cela génère du trafic inutile et augmente la latence. Des stratégies ont tout de même été mises en place pour lutter contre cet aspect asynchrone du protocole http. Avec Ajax par exemple, on peut faire du "polling". C'est une stratégie qui consiste à interroger régulièrement le serveur pour mettre à jour le client. Même si le service est rendu, Peter nous a fait remarquer ce c'est très inefficace et cela ne tiens pas la charge. Merci à Peter pour nous faire partager un exemple réel sur le site facebook. La fonctionnalité de chat de facebook qui utilise le polling ajax nécessite 10.000 serveurs pour tenir la charge de ses utilisateurs.
WebSocket est donc la spécification qui se propose de résoudre ce problème. La société Kaazing dans laquelle Peter travaille a participé activement à cette spécification. Il nous en a résumé les caractéristiques:
  • Full-Duplex Socket (communication montante et descendante simultanée) dans le navigateur. Vous ouvrez une connexion persistante entre le navigateur et le serveur web.
  • L'initialisation de la connexion ("hand-shaking") se fait toujours à partir du protocole http. Ça reste donc compatible avec une infrastructure web existante, on ajoute juste un client qui sait parler le WebSocket et un serveur également compatible.
  • Permet des requêtes sur l'autres serveurs que celui qui a transmis l'application web originale. C'était une "lacune" des requêtes Ajax.
  • La réduction de la quantité d'information non nécessaire transmises dans les entêtes peut aller jusqu'à 1/1000 dans les tests effectués par Kaazing.
    Les usages de ce protocole pourraient être par exemple l'édition simultanée à un google doc par plusieurs personnes. Ce serait irréaliste avec http si chaque caractère tapé émettait sa propre requête http.
  • WebSocket permet aussi de faire passer des protocoles de plus haut niveau comme XMPP par exemple pour la messagerie instantanée ou encore d'autres protocoles client-serveur qui seraient utilisés dans le SI.
Peter nous montre ensuite dans le domaine du jeu vidéo, l'exemple du portage de Quake2 qui utilise WebGL et WebSocket. Chez Kaazing, ils ont écrit un client VNC dans le navigateur basé sur WebSocket ce qui évite d'installer un client VNC pour accéder à un partage d'écran.
Pour une démo, rendez-vous sur la page d'accueil de kaazing ou sur leur site de poker en ligne basé sur HTML5.

Geolocation

Cette API permet à une application web de connaître la localisation géographique de l'utilisateur. L'utilisateur peut tout de même refuser de transmettre sa position auquel cas, l'application devra échouer en gérant agréablement ce cas de figure (par exemple en affichant un message). L'application peut donc avoir accès aux coordonnées géographiques de l'utilisateur (et la précision) quel que soit le moyen que le navigateur emploie pour trouver cette position:
  • dispositif de positionnement par satellite type GPS,
  • triangularisation GSM lorsqu'on est en mobilité,
  • ou géo-codage de l'adresse postale du point d'accès à internet déduit à partir de l'IP de l'utilisateur.
On peut aussi avoir accès à d'autres méta données telles que l'altitude ou la vitesse, toujours dépendantes du matériel dont dispose l'utilisateur pour accéder à l'application web.
Chacun de ces dispositifs a des avantages et des inconvénients. Par exemple, le GPS est la solution de positionnement la plus précise mais elle consomme beaucoup d'énergie, ce qui peut se révéler critique pour suivre un trajet pendant longtemps. Le wifi quant à lui est la plupart du temps payent. La résolution à partir de l'IP est rapide mais n'est pas très précise.

Web Storage

Pensez à cette API comme un moyen pour une page de stocker des données directement. Dans la version actuelle de HTML, on dispose déjà des cookies pour faire se genre d'opérations. Peter nous fait la citation de quelqu'un qui aurait qualifié l'API Web Storage de "Cookies dopés" (mieux en anglais "Cookies on Steroïds").
Cette fois, un volume beaucoup plus important peut être stoké dans le "Local Storage" (stockage local) et le Session Storage (stockage dans la session) ou la base de données. Cela fait trois type de stockage. Les deux premiers sont des stockages associatifs de type "clé-valeurs". Le troisième est une base de données WebSQL. La force de cette API est donc de pouvoir alléger les échanges réseaux puisque l'on crée un stockage local de données qui n'ont pas à transiter sur le réseau. De plus, les données sont persistées entre deux démarrages du navigateur ce qui permet de prolonger l'état de la navigation de l'utilisateur.
Le problème avec les cookies, ce sont leur taille fixe. Par exemple, sur un site de voyage qui stocke la commande de l'utilisateur dans un cookie, on peut arriver aux limites de stockage et celà entraîne une rupture de navigation et une perte de données pour le visiteur. Avec cette API, on a beaucoup plus de place. Peter avance aussi l'argument de la sous-exploitation de nos machines. Autant que les sites web puissent profiter de l'espace disque de plus en plus grand sur nos ordinateurs pour ne pas se contenter de simples terminaux web. Dans les implémentations actuelles de l'API, on a accès à une vue qui permet de visualiser ce que les sites web ont stockés dans l'espace du navigateur.
A propos du WebSQL, la spécification est au point mort car il n'y a pas vraiment d'intéret en fait pour spécifier encore un autre dialecte SQL...

Autres API de communication

  • Server-sent events: Cela standardise l'envoi de données en broadcast du serveur au client. C'est le mode 'Comet' qui permet de recevoir des données sans en faire la requête.
  • Cross-document messaging: Cela permet de faire des échanges dans une page (du document principal vers un iframe par exemple) en permettant le partage de contexte javascript.
  • XHR `Level 2` : C'est la nouvelle version de l'objet javascript qui apporte le support d'Ajax. Il est possible maintenant de faire des requêtes à d'autres serveurs qui sont hébergés sur d'autres domaines que celui qui héberge votre script.
Selon Peter, ces APIs sont intéressantes. Il les met tout de même en perspective par rapport à WebSocket qu'il considère comme plus puissant puisqu'il permet de mettre en oeuvre une connection TCP entre un client et un serveur.

Autres nouveautés

  • Offline web applications : C'est plus que le cache actuel qu'on peut trouver dans les navigateur. Avec cette fonction, on spécifie au navigateur qu'une sous-partie du site doit être accessible offline. On décrit cela à travers un fichier cache-manifest.xml à la racine du site. On peut aussi savoir si le navigateur est on-line ou off-line, ce qui permet de réagir applicativement.
  • Drag-and-Drop,
  • History API : apporte un contrôle plus fin sur les bouton précédents et suivants pour historiser la navigation de l'utilisateur.
  • Content editable

Vous pouvez trouver sur ce billet la présentation PDF de Peter Lubbers. Merci à lui pour cette présentation très complète sur l'état de HTML5.

lundi 14 juin 2010

HTML5 with Peter Lubbers 2/3

Compte rendu HTML 5

HTML 5 Forms

Les WebForms 2.0 ou HTML 5 Forms, fournissent des fonctionnalités de formulaire natifs. En guise d'illustration, Peter nous montre le volume de code non négligeable nécessaire à la validation d'une simple adresse e-mail. Ces efforts répétés par les développeurs de sites ou dans les frameworks ou les toolkits se trouvent implémentés dans le browser grâce à HTML 5. Il y a aussi de nouveaux composants comme DatePicker, ColorPicker, valideurs d'adresses web, sliders, etc. D'après le présentateur, on a pas à se soucier de la compatibilité descendante de ce genre de composant car en cas de non compatibilité, les composants sont rendus avec du texte. Il y a aussi la possibilité de rendre un attribut obligatoire. Dans ce cas, la validation côté client est assurée par le navigateur avant même l'envoi au serveur. Ce fut l'occasion de voir le code associé et de constater que les guillemets deviennent accessoires en HTML5:

<input id=name name=name type=text required>
C'est en cela qu'HTML5 est un contrepied au XHTML qui prône lui une conformité rigoureuse à la syntaxe XML.
Pour résumer, cette spécification ajoute à HTML des fonctionnalités natives au navigateur en un nombre réduit d'éléments déclaratifs au lieu de devoir recoder cette partie là à chaque fois côté client.

Des tas d'API

HTML 5 innove en apportant des standards d'API tels que : Canvas, SVG, Audio & Video, Web Socket, Web Workers, Geolocation, Web Storage, etc.

Canvas & SVG

Ce sont des API de dessin pour le navigateur. Par exemple, on peut dessiner une ligne dans la page grâce à ces API. Conformément à l'esprit de HTML5, ces zones graphiques sont accessibles à Javascript et au styles CSS à l'inverse d'une zone remplie par un plug-in. Alors pourquoi deux API pour dessiner ? L'un génère des graphismes "bitmap" (canvas) tandis que l'autre génère des images vectorielles (SVG). Dans un canvas, on est au "bas niveau", on a accès aux dessins de pixels, etc. Alors que SVG nous propose une syntaxe XML, un modèle objet pour décrire des formes, des traits, etc. Cela permet par exemple de concevoir des interfaces fines en réagissant à un clic sur une certaine zone par exemple. Peter tranche en disant qu'il n'y a pas vraiment de bonne ou mauvaise API à ce niveau. Il y a juste des usages différents.

Canvas

Lorsqu'une zone canvas est dessinée, elle l'est à une certaine résolution, elle serait pixelisée si on zoomait dessus. Il existe des canvas 2D et des canvas 3D. Le présentateur a partagé avec nous le site canvasdemo.com qui est une collection de liens vers des créations canvas, une bonne façon de découvrir des exemples de ce qu'on peut faire avec cette API. Je suis assez d'accord avec Peter, "that's cool stuff".
A noter que les canvas 3D (Web GL) ne sont supportés que par quelques navigateurs dans leur version de développement (les canvas 3D que vous pouvez voir sont de la 3D calculée et projetée sur un canvas 3D, ndla)
Comment ça marche ? Vous définissez un élément canvas et un dans un javascript, vous accéder au contexte de ce canvas. Ensuite, vous empilez des instructions de dessin dans ce contexte (line, gradient, rectangle, etc.) et à la manière d'une transaction en base de données, vous "commitez" ces instructions ce qui a pour effet de les dessiner dans la zone. Vous avez aussi accès aux évènement sur les mouvements de la souris.

SVG

En SVG, tout ce qui est dessiné peut passer à une échelle différente, ce n'est pas dépendant de la résolution. C'est assez adapté pour représenter des graphiques de données par exemple ou une carte avec des informations cartographiques additionnelles sur laquelle on pourrait zoomer précisément. A noter que IE 9 supporterait bien SVG et ajouterait une accélération matérielle prometteuse.

Audio and video

Il y a pour ça deux nouveaux éléments audio et video. Ils permettent d'inclure nativement des sons et des vidéos dans vos documents web. L'idée originale de HTML5 ne spécifiait à l'origine qu'un seul codec mais ce n'était pas une offre très diversifiée. Il y a donc aujourd'hui deux conteneurs multimedia compatibles : OGG (libre) et H.264 (non libre). Par exemple, Youtube et Dailymotion proposent déjà du contenu video en HTML5. Cela permet en particulier de se passer de Adobe Flash pour héberger des vidéos ou de la musique. Pour illustrer son propos, Peter nous montre qu'il est possible d'avoir accès aussi au contenu : une vidéo se joue sur une page et un script prend une capture toute les 5 secondes. On peut aussi zoomer lorsque la souris entre sur la vidéo.

Je continuerai dans la dernière partie du compte rendu sur Web Sockets, Web Workers, Geolocation et Web Storage.

mardi 8 juin 2010

HTML5 with Peter Lubbers 1/3

HTMLV

Voici un compte-rendu de la présentation HTML5 de Peter Lubbers de la société Kaazing. Il était invité par Zenika à présenter les grands principes de HTML5.
Dans toute l'assistance de 30 personnes environ, seulement une personne a déclaré être en train d'utiliser réellement HTML5 pour un projet ! Au moins, nous n'étions pas là bas pour rien ce soir.

La société Kaazing dont il est employé est spécialisée dans les web sockets pour l'entreprise, c'est-à-dire fournir des serveurs et des logiciels adaptés pour la diffusion d'informations en masse à travers internet. Peter est quant à lui le co-fondateur du San Francisco HTML5 User Group depuis quelques mois dont le nombre d'adhérents à atteint 500 personnes, ce qui montre l'intérêt pour le sujet en Californie.

HTML5 a au moins un premier mérite, c'est de mettre d'accord des sociétés qui ne le sont jamais ! Apple, Google, Microsoft ou la Fondation Mozilla, toutes ces sociétés soutiennent activement la spécification HTML5 !

Histoire de HTML et origine de HTML5

Un rapide point de vue historique pour commencer:

1981
T. Berners Lee pose les
bases du format HTML

>
'90
HTML 1.0
 

>
1995
HTML 2.0
 

>
1997
HTML 3.2 & HTML 4.0
 

>
1999
HTML 4.1
 

>
2001
XHTML
 

>
2004
WHATWG propose HTML5,
c'est l'apogée du web 2.0

>
2009
HTML5 approprié par le W3C
 

>
2012
la Release Candidate de
HTML5 sera prête

>
2022
Version finale de la spécification
 

A propos de la date de 2022, ne vous inquiétez pas, 80 à 90% de la spécification est dorénavant déjà implémentée dans les navigateurs !
La principale différence entre HTML5 et une simple nouvelle version de HTML est le contrôle très poussé que la page web peut obtenir avec le navigateur à travers CSS et surtout Javascript. HTML5 ajoute de nombreuses API qui permettent de pousser l'application web encore plus loin.
Derrière cette spécification, on trouve le groupe de travail à l'origine de la spécification, le WHATWG, puis le W3C et l'IETF (plus centré protocole) ont rejoint le mouvement. Le WHATWG s'est constitué avec des membres qui développent des navigateurs pour contrer la direction trop puriste prise à l'époque par le W3C.
HTML5 est en fait l'union de plusieurs sous spécifications: WebSocket, Geolocation, Local Storage, etc. Peter nous a expliqué que ça permettait aux participants d'être spécialisés par sujet.

Les principes de conception

Voilà les principes qui guident la spécification:

#1 Compatibilité

Les auteurs sont restés pragmatiques sur le sujet. Ils ont souhaité garder un maximum de compatibilité avec la masse gigantesque de pages internet existantes.

#2 Utilité

Sécurisé, utilisable, erreurs non bloquantes (un fragment de la page ne devrait pas briser toute la page), séparation entre le contenu et la mise en forme

#3 Interopérabilité

Un effort de simplification se cache derrière ce concept. Par exemple, on va chercher à proposer des implémentations natives dans les navigateurs plutôt que de proposer des plugins pour chaque besoin. La plupart des API se veulent simples à utiliser. Peter nous a montré ici la simplification à l'oeuvre dans les entêtes des pages HTML5 :
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />

Mais cette simplicité ne veut pas dire ambiguïté, on se souvient tous de l'époque où chaque navigateur interprétait différemment le contenu et la mise en forme. Un effort dans HTML5 est porté sur la non ambiguïté des spécifications.

#4 Accès universel

Cette idée recouvre l'internationalisation et l'accessibilité en fournissant des règles sur les contenus pour les rendre interprétables par d'autres dispositifs qu'un navigateur web sur un écran.

"Plug-in Free"

Peter a voulu insister sur ce point (on voit bien ici que ce sont des éditeurs de navigateurs qui sont majoritairement derrière la spécification, ndla). Par exemple, si on a une page dans lequel un contenu est rendu par un plug-in, le reste de la page ne va pas pouvoir interagir avec ce contenu "piégé" dans le contexte d'exécution du plug-in. Pour illustrer son propos, il nous a propose une démo avec Adobe Flash, il est donc passé au slide suivant et là, paf, écran bleu Windows sur le projecteur - on y a cru 3 secondes ;-) En tous cas, le propos est illustré. Les navigateurs veulent contrôler leur stabilité et ne plus dépendre de plug-in hors de leur contrôle.

Anatomie de HTML5

De nouveau tags apparaissent (section, header, aside, etc.), d'autres sont dépréciés. C'est le cas par exemple de l'élément basefont qui est clairement de la mise en forme. HTML5 ne fait que déprécier car il doit se conformer au principe #1 de compatibilité, vous suivez toujours ?
Comme Peter, je relaye le lien vers la très utile "HTML5 Cheat Sheet" pour visualiser les nouveaux et les anciens éléments.
Pour HTML5, une page dessert un objectif différent d'une autre et n'a donc pas a adopté le même squelette. Peter nous a tout de même montré un exemple classique comparé à sa version HTML4. Voilà un exemple équivalent:

Pour faire du HTML5 dès maintenant, alors que la spécification n'est pas finalisée, il existe des astuces. Par exemple, pour s'adresser en CSS3 à certains navigateurs en particulier, on utilise des attributs spécialisés (-moz... ou -webkit...) en fonction des fonctionnalités implémentées. L'autre astuce pour IE est d'inclure le script html5.js fournit par un projet google code. Ce script transforme un document HTML5 en fonction de l'implémentation actuelle du navigateur.

Je poursuivrai ce compte-rendu avec les innovations des Forms et un aperçu des principales nouvelles APIs qui ont été présentées par Peter.

jeudi 18 juin 2009

Comment faire des podcasts facilement ?

Voilà ma méthode pour réaliser des podcasts. Elle est issue de mes recherches sur le sujet et quelques tentatives. En trois étapes, je ne pense pas être original sur la démarche globale, mais plutôt sur les choix faits dans ces étapes.

Acquisition du son

podcastMaterial.jpg
  • 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.
J'obtiens finalement un bon son avec le micro intégré dans le dictaphone. Le micro sur pied permet juste de s'approcher de la discussion si possible. Quant au micro Sony stéréo, il fonctionne mais pas de différence majeure avec le micro intégré.

Montage

  • mp3dcscr1.jpgPour 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.
  • audacity-linux-small.jpgPour 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 ?
    archive.org.jpg 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.

vendredi 29 mai 2009

Tout savoir sur Gradle

Grégory et moi avons décidé de faire un podcast sur Gradle.

On a créé une google page pour l'occasion:
http://gradleconversation.googlepages.com

Vous pourrez écoutez les deux épisodes de 45 minutes chacun en français pour tout savoir sur ce nouveau système de build.

jeudi 28 mai 2009

Une journée au XP Day France 2009

Je n'ai assisté qu'au deuxième jour du XP Day France 2009.
Le cadre était bucolique. Si je peux me permettre un reproche, les salles du chalet n'étaient pas si pratiques. Je connaissais déjà les lieux pour y avoir fait un "Team building" l'année dernière et nous avions rencontré déjà le soucis de la traversée des salles pour accéder aux autres.

Sessions:
Voici ce que j'en retiens:
  • 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.
La communauté agile semble toujours très active. L'association XP France a évolué cette année en changeant de statuts et en prenant le nom d'"Agile Paris". Du coup, le titre de l'association est beaucoup plus en phase avec les compétences réelles de ses membre qui n'ont jamais été réduites seulement à la méthode XP.
A l'année prochaine pour une nouvelle session. 2009 sera riche en événements et on ne peut également que se féliciter de la création d'associations à travers la France entière.

mercredi 13 mai 2009

Présentation du Lean Software Developement

Je vais parler aux XP Day !

XP Day bag 1 (c'est le sac de l'année dernière)
1 2 3
  1. Ne pas négliger la théorie
  2. S'entraîner en s'écoutant pour se corriger
  3. Prendre des forces (5 fruits et légumes par jour, c'est un objectif dur à atteindre !)
La théorie permet d'être à l'aise avec les fondements de ce que l'on vit sur nos projets.
En s'écoutant, on apprend à se placer du côté de l'auditoire. Je cherche à me poser les questions en tant que public de la présentation : quels sont mes attentes et serais-je déçu si j'y assistais ? Mais la voix n'est pas le vecteur primordial pour faire passer l'information. L'attitude, le ton, la présence comptent aussi beaucoup.
Il est aussi important d'avoir une idée claire des messages que l'on souhaite faire passer. Ensuite, le mieux est de trouver une histoire à raconter pour faire passer le tout de façon agréable. Ce qui me plaît dans une présentation, ce sont les accroches, et lorsque les exemples résonnent dans mon expérience actuelle et passée. J'utilise donc des cartes pour répéter sur lesquelles j'inscris le message important du slide et les accroches et les transitions dans une autre couleur.
Tentons de faire tout ça pour le 26 mai !

lundi 23 février 2009

Nabaztag plugin improved

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.
    hudson-1.5-advanced.png
  • 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).
    hudson-1.5-variables.png
  • Add help for each parameter.
    hudson-1.5-help.png

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 ?

- page 1 de 3