Affichage des résultats du sondage: Quels sont les meilleurs conseils pour bien déboguer son code ?

Votants
54. Vous ne pouvez pas participer à ce sondage.
  • Beaucoup utiliser la fonction Print

    23 42,59%
  • Commencer avec un code qui fonctionne déjà

    13 24,07%
  • Exécuter votre code à chaque petit changement

    21 38,89%
  • Bien lire les messages d'erreur

    33 61,11%
  • Rechercher le message d'erreur sur Google

    16 29,63%
  • Deviner et vérfier

    7 12,96%
  • Déguiser votre code en commentaire

    8 14,81%
  • Effectuer une recherche dichotomique

    5 9,26%
  • Faire une pause et s'éloigner du clavier

    29 53,70%
  • Savoir comment demander de l’aide

    14 25,93%
  • Autres (à préciser dans les commentaires)

    12 22,22%
  • Pas d'avis

    1 1,85%
Sondage à choix multiple
+ Répondre à la discussion Actualité déjà publiée
Page 5 sur 5 PremièrePremière 12345
  1. #81
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 358
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 358
    Points : 6 801
    Points
    6 801

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Ben, souvent, on te montrera la porte.
    Ya des cas où il faut partir. Après il faut aussi pouvoir je sais bien mais de ce que je lis ci-dessous t'as quand même une armée de débiles aux commandes de ta boite.

    Citation Envoyé par el_slapper Voir le message
    Et la base de ma réponse était la suivante : les TU, c'est au-delà du possible. Même dans une bonne(mais pas parfaite, ni même excellente) boite comme la mienne.

    [...]

    Mais le TU, non, ça ne passera pas. Déjà, au bout de 4 ans, les tests automatiques d'interface commencent à peine à être acceptés comme autre chose que des lubies(je rappelle qu'ils ont déjà sauvé des vies), mais si je commence à mettre des TU automatisés sur les fonctions dont je me sers dans lesdits tests automatiques, j'ai 3 étages pour apprendre à voler.
    Par curiosité c'est qui dans ta boite qui est contre les TU ? Un tech ? Un manager ? Un chef de projet ?
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  2. #82
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 564
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 564
    Points : 8 404
    Points
    8 404
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par el_slapper Voir le message
    Le concept de dette technique est bien utile, mais seulement face à des gens un minimum intelligents et ouverts.
    Il faut qu'ils soient assez technique aussi. J'avais lu une remarque comme quoi il fallait pas utiliser ce concept avec les managers et autres personnes non techniques parec qu'ils ne le comprennent pas. Et je crois que je suis plutôt d'accord que ça peut être contre-productif pour demander du budget pour refactorer par exemple.

    Citation Envoyé par el_slapper Voir le message
    Et la base de ma réponse était la suivante : les TU, c'est au-delà du possible. Même dans une bonne(mais pas parfaite, ni même excellente) boite comme la mienne.

    Je fais ce que je peux, je mets en fonctions les codes que mon collègue copie-colle partout, je documente mes crimes, j'automatise tout process qui peut l'être(et là dessus, par contre, mon collègue est très bien, même mieux que moi), je suis heureux d'ouvrir mon code à la critique et à la revue, etc..... Mais le TU, non, ça ne passera pas. Déjà, au bout de 4 ans, les tests automatiques d'interface commencent à peine à être acceptés comme autre chose que des lubies(je rappelle qu'ils ont déjà sauvé des vies), mais si je commence à mettre des TU automatisés sur les fonctions dont je me sers dans lesdits tests automatiques, j'ai 3 étages pour apprendre à voler.
    Faites-vous de l'intégration continue? Pour moi les TU sont difficiles à justifier sans l'intégration continue. Par contre une fois que ça tourne de façon automatisée à chaque commit, il ne faut pas bien longtemps pour constater - de manière factuelle - que c'est super utile. Sinon, c'est juste un truc chiant de plus à maintenir, qu'on sait vaguement exécuter de temps en temps... ou pas.

    De manière générale c'est un vrai challenge que de tenter d'améliorer les process d'une boîte. Encore plus quand on est le nouveau presta qui débarque. Mais là je suis content car pour ma nouvelle mission, j'ai pu faire approuver tout ça! Hourra, plusieurs années de galère et de recherche sur comment s'y prendre enfin récompensées. Et pour moi l'intégration continue est la base de tout.

    Je compte faire une série d'articles et de tutos sur ce sujet car c'est une vraie difficulté que je souhaite partager. Typiquement, en France, la PME dans l'industrie est très difficile à faire bouger : le software c'est pas leur coeur de métier, ça les dépasse / ça les gonfle alors moins ils en entendant parler mieux c'est. Surtout qu'à cause des terribles normes auxquels ils sont soumis ils peuvent pas bouger un orteil etc... (c'est quand même un comble quand une norme censée garantir la qualité et la fiabilité empêche d'améliorer la qualité de ses développements!!)

  3. #83
    Expert éminent Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2005
    Messages
    2 358
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : août 2005
    Messages : 2 358
    Points : 6 801
    Points
    6 801

    Par défaut

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Il faut qu'ils soient assez technique aussi. J'avais lu une remarque comme quoi il fallait pas utiliser ce concept avec les managers et autres personnes non techniques parec qu'ils ne le comprennent pas. Et je crois que je suis plutôt d'accord que ça peut être contre-productif pour demander du budget pour refactorer par exemple.
    Ca dépend de quel type de refactoring on parle.

    Si on parle de refactorer du legacy, oui ça a du sens de demander un budget, mais c'est un projet à part entière que de refondre du legacy.

    Si on parle de demander de pouvoir faire un sprint de refactoring sur un produit en cours de développement ça n'a juste aucun sens. Un développeur est en permanence entrain de refactorer. Estimer une fonctionnalité, la développer puis ne plus jamais toucher au code ça n'a aucun sens sinon en faisant du waterfall. Mais dans la vie réelle ça n'existe pas.
    Donc pour moi, c'est au développeur de prendre en compte le refactoring dans ses estimations, et il n' a pas à donner la ventilation de ses taches pour chiffrer une fonctionnalité, c'est lui qui connait l'implémentation, il sait ce qu'il a à faire, le manager n'y connait rien.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Faites-vous de l'intégration continue? Pour moi les TU sont difficiles à justifier sans l'intégration continue. Par contre une fois que ça tourne de façon automatisée à chaque commit, il ne faut pas bien longtemps pour constater - de manière factuelle - que c'est super utile. Sinon, c'est juste un truc chiant de plus à maintenir, qu'on sait vaguement exécuter de temps en temps... ou pas.
    L'intégration continue est un bonus mais ce n'est pas du tout la justification de l'existence des TU. Si tu n'exécutes jamais tes TU c'est que tu n'as rien compris à leur utilité. Le but c'est d'avoir un feedback immédiat sur le code que tu as écrit. Tu auras donc exécuté tes TU des dizaines de fois avant même de commit. Si tu ne fais pas ça ça ne sert à rien, autant travailler comme dans les années 90 ça ne changera rien.

    Exécuter les TU seulement en intégration continue ça veut dire que tu vas avoir des tests KO commités, donc tu vas propager tes bugs aux autres développeurs qui vont tirer la branche d'intégration qui aura été pétée. C'est une très mauvaise pratique. L'intégration continue sert de 2ème rempart pour éviter les erreurs humaines au niveau des TU mais :
    - il est préférable de les exécuter avant de commit/push.
    - elle sert de socle pour l'analyse qualité (sonar), les builds (nightly builds) et les pratiques de déploiement (continuous delivery ou deployment selon comment on travaille).

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    De manière générale c'est un vrai challenge que de tenter d'améliorer les process d'une boîte. Encore plus quand on est le nouveau presta qui débarque. Mais là je suis content car pour ma nouvelle mission, j'ai pu faire approuver tout ça! Hourra, plusieurs années de galère et de recherche sur comment s'y prendre enfin récompensées. Et pour moi l'intégration continue est la base de tout.
    Oui ça s'appelle la résistance au changement. Mais c'est entrain d'entrer doucement dans les moeurs. C'est de plus en plus faisable de trouver des boites où les décideurs sont un minimum informés sur les pratiques à mettre en oeuvre pour produire sereinement.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Je compte faire une série d'articles et de tutos sur ce sujet car c'est une vraie difficulté que je souhaite partager. Typiquement, en France, la PME dans l'industrie est très difficile à faire bouger : le software c'est pas leur coeur de métier, ça les dépasse / ça les gonfle alors moins ils en entendant parler mieux c'est. Surtout qu'à cause des terribles normes auxquels ils sont soumis ils peuvent pas bouger un orteil etc... (c'est quand même un comble quand une norme censée garantir la qualité et la fiabilité empêche d'améliorer la qualité de ses développements!!)
    Je ne comprends pas ta dernière phrase. Les PME auraient des normes les empêchant de faire de l'intégration continue ou du TDD ?
    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

    Trust me, i'm an engineer !
    https://www.youtube.com/watch?v=rp8hvyjZWHs

  4. #84
    Expert éminent sénior

    Profil pro
    Développeur informatique
    Inscrit en
    novembre 2006
    Messages
    6 086
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 086
    Points : 11 531
    Points
    11 531

    Par défaut

    Citation Envoyé par Luckyluke34 Voir le message
    Je suis d'accord que l'époque se fout royalement du moyen terme. L'approche de Marco46 (et de Uncle Bob) se heurte de plein fouet à la quête folle du profit immédiat et à la loi du financier qui règnent en ce moment. Mais pour autant, est-ce qu'on doit laisser tomber notre devoir de conseil en tant que professionnels ?
    ...
    tout le monde est parfaitement d'accord que oui un vrai pro a un devoir de conseil.
    Ce qui est sensé apporter de la valeur ajoutée à la production d'un service.
    Mais les gens qui gèrent les sociétés de service ( sans refaire le débat ) ne jure effectivement que la rentabilité immédiate.
    Donc ce n'est ni plus ni moins que se tirer une balle dans le pied
    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Typiquement, en France, la PME dans l'industrie est très difficile à faire bouger : le software c'est pas leur coeur de métier, ça les dépasse / ça les gonfle alors moins ils en entendant parler mieux
    à ce moment-là les dites PME ne devraient pas utiliser de systèmes informatiques si elles ont du mal à les intégrer et en tirer partie...
    un SI c'est destiné à accroitre la productivité d'un processus industriel ,d'une PME c'est pas fait pour faire joli ou glorifier un DSI..
    Citation Envoyé par el_slapper Voir le message
    Le concept de dette technique est bien utile, mais seulement face à des gens un minimum intelligents et ouverts. Quand on fait face à des gens qui prennent 100% de leurs décisions en fonction de leur intérêt immédiat, ça ne fonctionne pas.
    ( merci pour le lien très instructif );
    Dette technique ? Euuhh éditeur hexagonal qui développe depuis des années une techno propriétaire vendue à des PME mais qui date de plusieurs années dans sa conception et dans ses fondements ?

    Quelque part c'est pour cela que les start-ups comme Uber et de taille moindre ont souvent besoin d'effectuer des levées de fond afin de faire de la qualité.
    * Descartes: "je pense donc je suis"
    * Bob l'éponge : "je pense donc j'essuie"
    * l'infirmière : "je panse donc je suis"

  5. #85
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    4 474
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 4 474
    Points : 18 184
    Points
    18 184

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Ya des cas où il faut partir. Après il faut aussi pouvoir je sais bien mais de ce que je lis ci-dessous t'as quand même une armée de débiles aux commandes de ta boite.
    Ca, c'était quand j'étais presta en bancaire. Sans être parfait, c'est largement mieux là ou je suis maintenant.

    Citation Envoyé par Marco46 Voir le message
    Par curiosité c'est qui dans ta boite qui est contre les TU ? Un tech ? Un manager ? Un chef de projet ?
    Le chef des développeurs. Qui passe 70% de son temps à développer(on a très peu de managers qui passent leur temps dans les chiffres, et c'est une bonne chose. La big boss du département technique, ça suffit largement comme manager à plein temps) et que ça ferait chier de changer ses habitudes.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Il faut qu'ils soient assez technique aussi. J'avais lu une remarque comme quoi il fallait pas utiliser ce concept avec les managers et autres personnes non techniques parec qu'ils ne le comprennent pas. Et je crois que je suis plutôt d'accord que ça peut être contre-productif pour demander du budget pour refactorer par exemple.
    Un grand classique : adapter son discours à la personne qui écoute.

    Citation Envoyé par Aurelien.Regat-Barrel Voir le message
    Faites-vous de l'intégration continue? Pour moi les TU sont difficiles à justifier sans l'intégration continue. Par contre une fois que ça tourne de façon automatisée à chaque commit, il ne faut pas bien longtemps pour constater - de manière factuelle - que c'est super utile. Sinon, c'est juste un truc chiant de plus à maintenir, qu'on sait vaguement exécuter de temps en temps... ou pas.
    On est en train de mettre ça en place pour la partie client. Pour la partie serveur, on fera face aux mêmes conservatismes.

    Citation Envoyé par Marco46 Voir le message
    Ca dépend de quel type de refactoring on parle.

    Si on parle de refactorer du legacy, oui ça a du sens de demander un budget, mais c'est un projet à part entière que de refondre du legacy.

    Si on parle de demander de pouvoir faire un sprint de refactoring sur un produit en cours de développement ça n'a juste aucun sens. Un développeur est en permanence entrain de refactorer. Estimer une fonctionnalité, la développer puis ne plus jamais toucher au code ça n'a aucun sens sinon en faisant du waterfall. Mais dans la vie réelle ça n'existe pas.
    Donc pour moi, c'est au développeur de prendre en compte le refactoring dans ses estimations, et il n' a pas à donner la ventilation de ses taches pour chiffrer une fonctionnalité, c'est lui qui connait l'implémentation, il sait ce qu'il a à faire, le manager n'y connait rien.
    Le manager croit savoir, et comme il est chef, le programmeur doit s'exécuter. En bancaire, c'était ça. Et Glutinus nous a aussi offert quelques anecdotes allant dans ce sens. Il y a trois semaines, nos programmeurs ont tout arrêté pour refactorer pendant une semaine, et ensuite repartir sur de bonnes bases. La big boss n'a pas moufté. Je me suis cru au paradis. Même si c'est loin de l'être.

    Citation Envoyé par Marco46 Voir le message
    L'intégration continue est un bonus mais ce n'est pas du tout la justification de l'existence des TU. Si tu n'exécutes jamais tes TU c'est que tu n'as rien compris à leur utilité. Le but c'est d'avoir un feedback immédiat sur le code que tu as écrit. Tu auras donc exécuté tes TU des dizaines de fois avant même de commit. Si tu ne fais pas ça ça ne sert à rien, autant travailler comme dans les années 90 ça ne changera rien.
    On faisait des bonnes choses, dans les années 90. Mais pour de la survie à long terme, l'absence de TU est un problème, on est d'accord.

    Citation Envoyé par Marco46 Voir le message
    Exécuter les TU seulement en intégration continue ça veut dire que tu vas avoir des tests KO commités, donc tu vas propager tes bugs aux autres développeurs qui vont tirer la branche d'intégration qui aura été pétée. C'est une très mauvaise pratique. L'intégration continue sert de 2ème rempart pour éviter les erreurs humaines au niveau des TU mais :
    - il est préférable de les exécuter avant de commit/push.
    - elle sert de socle pour l'analyse qualité (sonar), les builds (nightly builds) et les pratiques de déploiement (continuous delivery ou deployment selon comment on travaille).
    Je n'ai jamais eu la chance de pouvoir monter jusqu'à ce niveau de mauvaises pratiques. Enfin, nous, nôtre rêve mouillé, c'est de passer les tests automatiques d'homologation en intégration continue. Histoire de ne pas attendre le prochain build dans 3 semaines. C'est un progrès. Effectivement, des TU qui empêchent les devs de malencontreusement tout casser, ça manque. Mais là, je fait face à un blocage culturel.

    Citation Envoyé par Mat.M Voir le message
    à ce moment-là les dites PME ne devraient pas utiliser de systèmes informatiques si elles ont du mal à les intégrer et en tirer partie...
    un SI c'est destiné à accroitre la productivité d'un processus industriel ,d'une PME c'est pas fait pour faire joli ou glorifier un DSI..
    Une bonne partie du problème est relationnel, je le répète. Les dynamiques de pouvoir ne facilitent pas les bonnes pratiques.

    Citation Envoyé par Mat.M Voir le message
    ( merci pour le lien très instructif );
    Dette technique ? Euuhh éditeur hexagonal qui développe depuis des années une techno propriétaire vendue à des PME mais qui date de plusieurs années dans sa conception et dans ses fondements ?
    C'est pour ça qu'on refond toute notre partie client, en ce moment. Un projet nécessaire pour survivre. Nôtre techno client actuelle est end of support depuis plus de 10 ans. Et les gens qui savent faire approchent l'âge de la retraite. Ou démissionnent. Le serveur devra suivre.

    Citation Envoyé par Mat.M Voir le message
    Quelque part c'est pour cela que les start-ups comme Uber et de taille moindre ont souvent besoin d'effectuer des levées de fond afin de faire de la qualité.
    Enfin, Uber a surtout besoin de fonds pour faire face à son modèle économique structurellement déficitaire, le temps de tuer les taxis, avant de relever les prix. C'est pas pareil. Mais, dans d'autres cas, ton argument est réel.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  6. #86
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 564
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 564
    Points : 8 404
    Points
    8 404
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    L'intégration continue est un bonus mais ce n'est pas du tout la justification de l'existence des TU. Si tu n'exécutes jamais tes TU c'est que tu n'as rien compris à leur utilité. Le but c'est d'avoir un feedback immédiat sur le code que tu as écrit. Tu auras donc exécuté tes TU des dizaines de fois avant même de commit. Si tu ne fais pas ça ça ne sert à rien, autant travailler comme dans les années 90 ça ne changera rien.

    Exécuter les TU seulement en intégration continue ça veut dire que tu vas avoir des tests KO commités, donc tu vas propager tes bugs aux autres développeurs qui vont tirer la branche d'intégration qui aura été pétée. C'est une très mauvaise pratique.
    J'ai jamais que les TU n'étaient exécutés qu'en intégration continue...

    J'ai juste fais le constat que la discipline idéale d'exécuter ses TU localement de manière fréquente reste du ressort de l'idéal s'il n'y a pas une CI qui risque de péter à chacun de mes commits non testé. La CI n'est pas un bonus, mais le garant (euphémisme de gendarme) de la bonne mise en oeuvre des TU. Parce que sinon, quand ça fait 10 ans que je bosse sans TU, mais pourquoi diable je me fatiguerais à tester monde code avant de le commiter? En tous cas là où j'ai pu travailler, c'est ainsi que ça fonctionne.

  7. #87
    Expert éminent

    Profil pro
    Inscrit en
    juin 2003
    Messages
    5 564
    Détails du profil
    Informations personnelles :
    Âge : 35
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 5 564
    Points : 8 404
    Points
    8 404
    Billets dans le blog
    3

    Par défaut

    Citation Envoyé par Marco46 Voir le message
    Je ne comprends pas ta dernière phrase. Les PME auraient des normes les empêchant de faire de l'intégration continue ou du TDD ?
    C'est plutôt dans le fait d'avoir une approche agile où on livre fréquemment par petits incréments.

    De ce que j'en ai perçu, il est assez fréquent dans le milieu industriel de percevoir le logiciel comme un produit hardware sur lequel on bosse au niveau théorique pendant des mois avant de le livrer en QA qui effectue alors tous les tests (typiquement: le soft embarqué d'une machine assemblée sur chaîne). Et tout ça est bien codifié dans un processus qui sert à garantir l'obtention d'une norme / label (et qui offre bien peu de place pour les ascpets agile du dev logiciel).

    Du coup, travailler en sprints de 2 ou 3 semaines, ça déstabilise, semble très exotique et ne rentre pas dans le processus habituel de livraison / traçabilité. Alors le coup de "on a des normes à respecter" sert souvent de joker pour botter en touche, même si dans les faits rien n'empêche de travailler en mode agile "dans une bulle" avant de livrer le produit final comme attendu.

    L'autre difficulté de la CI c'est qu'il faut un peu de budget pour un (deux) serveur(s) supplémentaires. Et d'expérience ça peut être difficile à obtenir tant qu'on a pas démontré l'utilité du truc. Or, c'est difficile de démontrer (factuellement) l'utilité du truc sans pouvoir en faire une démo. C'est le serpent qui se mord la queue... Astuce qui a fonctionné dans mon cas : héberger la CI dans une VM sur ma machine, habituer l'équipe à travailler ainsi pendant quelques semaines, puis faire une démo aux responsables pour leur demander (collectivement) un serveur dédié.

Discussions similaires

  1. Comment bien déboguer son code ?
    Par D[r]eadLock dans le forum Débuter
    Réponses: 46
    Dernier message: 04/07/2013, 10h48
  2. Réponses: 145
    Dernier message: 15/02/2009, 11h51
  3. Comment bien commencer la Programmation
    Par Le_Faya dans le forum Débuter
    Réponses: 6
    Dernier message: 01/12/2006, 18h39
  4. Memory Managment dans vos programmes
    Par Clad3 dans le forum C++
    Réponses: 11
    Dernier message: 25/07/2006, 01h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo