[Développement] Git, pourquoi, comment, que nous arrive-t-il?

posté le 27 July 2014 à 16:25

Bon, la masse crasseuse plèbe ingnorante foule avide de connaissance ayant exprimé un cerain intêret pour Git, je me vois contraint d'expliquer pourquoi je ne reviendrais pas en arrière depuis que je m'y suis converti (pourtant pas très motivié à la base) depuis le mois de janvier dernier. Attention, j'ai toujours pas appris à faire court et à m'empêcher de faire des digressions, ça va donc être long.

Commençons par le commencement

Déjà, il faut savoir que Git, comme SVN avant lui et CVS encore avant, est gratuit et open-source. C'est aussi le cas du plugin Eclipse correspondant, c'est déjà une bonne chose.

Deuxième point important, il y a une référence absolue pour Git, à savoir le livre "Pro Git" écrit par Scott Chacon (un des fondateurs de Github), dispo évidemment en édition papier chez tous les bons libraires, mais aussi gratuitement en ligne en anglais là: http://git-scm.com/book et même en français (je l'ai pas lu, donc je garantie pas la qualité de la traduction ni le fais que ce soit à jour) ici: http://git-scm.com/book/fr

Le "livre" fais 9 chapites, mais le premier est une introduction + historique des SCM, et si vous avez lu les chapitres 2 et 3 vous êtes déjà capables d'utiliser 80% des fonctions les plus utiles de Git.

Troisième point important: oui, l'outil est "pensé" comme un outil en ligne de commande (n'oublions pas qu'il a été pensé et implémenté par les développeurs du kernel Linux, on pouvait difficilement s'attendre à autre chose de leur part), c'est pour ça que Pro Git ne fera quasiment référence qu'à des lignes de commande. Et je conseille de commencer par là, ça permet de se familiariser avec les concepts (un peu différents mais pas trop) de Git sans s'embrouiller avec des interfaces graphiques proposant toutes les options dont vous n'avez que faire.

Encore une fois, dès la phase d'apprentissage et de migration terminée, vous n'y reviendrez (presque) jamais.

Ok, mais en quoi c'est mieux que SVN ou CVS ou ...

Les anciens de Git vont tous vous faire la même réponse: parce que c'est décentralisé. Et c'est une réponse de merde, déjà parce que si vous n'êtes pas un minimum callé sur le "comment ça fonctionne" des SCM cette réponse ne vous éclaire pas du tout, mais aussi parce qu'à moins de travailler sur un projet open-source massif (disons au hasard: comme le kernel linux) il est conseillé de garder une notion de centralisation. Je vais y revenir plus tard.

L'autre argument qu'on vous sortira souvent c'est "parce que c'est facile de brancher/merger vu que chacun a son propre repository" (en français on dit "dépôt", mais je n'arrive pas à me faire à ce terme, donc vous devrez supporter de me voir dire "repo" à chaque fois, et ne vous plaignez pas, à l'oral c'est encore pire). Là, y a déjà quelque chose de plus intéressant si vous êtes déjà utilisateurs d'un SCM comme CVS ou SVN. Sauf que si vous avez déjà fais un peu joujou avec les notions de branch et de merge en SVN, ça devrait provoquer chez vous une réaction entre le sourire narquois et le rictus figé de terreur.

Décentralisons, décentralisons, il en restera toujours quelquechose (Dixit un certain Defferre)

Décomposons la phrase, en commençant par la fin: "vu que chacun à son propre repository".

Les ancêtres centralisés ont une faiblesse: le repo n'existe qu'à un endroit, et à moins de se lancer dans ces procédure de sauvegardes régulières du repo, une crash de la machine hébergeant le repo peut être une catastrophe. Sachant que sauvegarder le repo n'est qu'une demi solution (toute personne ayant déjà essayé de rétablir un environnement de travail collaboratif pour une équipe de 10 personnes à partir de la sauvegarde vieille d'une semaine d'un repo SVN comprendra). Disons que si ça vous arrive, attendez vous à perdre une deuxième semaine à régler des conflits lors des prochains commit.

Git a cette spécificité que chaque utilisateur dispose de son propre repo. Oui, oui, un repo complet, avec tout l'historique, et un certain nombre de branches (mais pas forcément toutes pour le coup). Il se trouve qu'en dehors de la première personne (appelons-le Adam) à créer le repo pour un projet, tous les autres vont "cloner" un repo existant (pas forcément celui créé par Adam d'ailleurs).

J'ai nommé Adam parce que je compte lui donner un rôle un peu à part des autres utilisateurs: admin du repo central. Et là vous me dites: tu te fous de notre gueule. Alors non, déjà parce que je suis poli, et vous pourriez me rendre la politesse. Ensuite parce qu'en entreprise, contrairement aux projets open source, on a souvent besoin d'une référence unique (par exemple pour faire tourner un serveur d'intégration continue, pour produire la version release, etc). La force de Git c'est que chacun a un repo, ce qui n'exclue nullement que l'un de ces repo (au hasard; celui qui est sur le serveur d'intégration) fasse office de référence pour différentes tâches. D'ailleurs même pour les projets open-source, il y a souvent une référence (pour le kernel linux, je serais vous je me pencherais du côté de monsieur Torvalds par exemple).

Donc voilà, Adam, premier utilisateur, a créé un repo pour le nouveau projet (ou pour un projet déjà en cours, mais on y viendra plus tard sinon on s'en sors plus). Mon conseil, c'est que ce repo soit sur un serveur visible du reste de l'équipe et serve pour toutes les tâches d'intégration continue, production de release, suivi des rapport de bugs, etc. Et SURTOUT PAS de repo de travail de développement pour Adam.

Adam, comme tous les autres membres, va se faire un repo de travail à lui, dans son environnement de développement, en "clonant" un repo existant. Bon, pour faire simple, on va dire qu'il clone le repo initial. Mais son pote Benjamin qui arrive juste après lui, a le choix entre cloner le repo initial ou cloner le repo d'Adam. Ca change assez peu de choses au final, mais pour faire simple disons que tout le monde clone le repo initial.

Donc maintenant, chaque utilisateurs à un repo cloné à partir d'un autre repo... so what?

Ben déjà, si jamais un repo disparait (mettons le plus critique: celui du serveur, mais même simplement parce qu'un membre a vu son HDD flamber, ou s'est fait volé son portable, ou bien vient d'acheter une nouvelle machine), il est extrêmement simple de rétablir la situation très vite: il suffit de cloner un des autres repo existants et voilà, on est prêts à travailler en 2 temps 3 mouvements. Plus besoin de sauvegarde externe: tout utilisateur est une sauvegarde à lui tout seul. La date de sauvegarde correspondant à sa dernière connection avec le repo disparu (donc pour le repo central: en général moins d'une journée).

Autre avantage: vous pouvez travailler déconnecté. C'était absolument obligatoire pour les développeurs du kernel linux qui ne veulent pas (et pour bon nombre: ne peuvent pas) être connectés à chaque fois qu'ils ont un bout de code dans un état satifaisant dont ils veulent garder une trace d'historique pour ne pas la mélanger au bout de code suivant. Pareil pour vous: vous êtes en déplacement pro, votre portable sur la tablette du train qui vous emporte dieu sait où? Vous êtes du genre "télétravail" à bosser 1 semaine chez vos amis dans le Larzac, loin de toute connection digne de ce nom? Pas de soucis, vous avez votre propre repo, vous pouvez donc faire des commit, faire des branches, faire des merge, etc.Evidemment, quand vous retrouverez la civilisation faudra resynchroniser un peu tout le monde, mais vous verrez que ça se fait plutôt bien.

Branch, Merge, historique

Allez, on tourne autour depuis tout à l'heure, maintenant on y va: l'autre avantage, c'est que vous pouvez faire des branches (plein, autant que vous voulez) et des merge (pareil) à tout va.

Bon, là va falloir me croire sur parole parce que sinon on y passe l'année: Git gère les merge de branche 1000 fois mieux que SVN. Pourquoi? Bonne question, je n'ai pas la réponse exacte mais je suppose que ça tient surtout à 2 facteurs:

1) la façon dont Git stock les différents états de l'historique dans le repo: contrairement à SVN, il ne stock pas uniquement les delta de modification d'un état à un autre d'un fichier, mais bien la totalité du fichier dans son nouvel état. Ca devrait provoquer une montée en taille abominable des repo (c'est pour des considérations de taille du repo que SVN a adopté cette stratégie des delta), ce n'est pas le cas, je ne sais pas pourquoi. Et puis à l'heure actuelle le Go coûte rien, donc même si votre repo fait 5Go, c'est pas vraiment un problème.

2) du fait de la facilité de faire des branches et de la facilité et rapidité de passer de l'une à l'autre, on fait des branches plus souvent, qu'on merge plus souvent, donc les risques de conflits sont plus limité. De mon expérience (environ 5 ans) de SVN, on fait des branches pas trop souvent (genre pas plus d'une par semaine, voir moins) et les merge sont chaque fois une épreuve qu'on repousse autant que possible. Avec Git, vous prendrez vite l'habitude de faire des branches, potentiellement plusieurs fois par jour, qui seront parfois ré-intégrées dans la même journée

Si vous êtes comme moi, vous me dites: OK, mais chaque branche est une copie complète du projet qu'il faut mettre à un endroit différent du disque, ça doit être un bordel monstre, en plus de prendre une taille folle sur les disques, et je parle pas de passer de l'une à l'autre avec mon environnement de développement.

Ben non. Parce que Git est sympa, et qu'il gère toutes les branches au même endroit. Je m'explique: vous avez votre répertoire de développement: C:développementmon_projet . Et bien tous vos travaux auront lieux dans cet unique répertoire (et ses sous-répertoires).

Vous avez besoin de travailler sur une nouvelle fonctionnalité? Vous demandez à Git de vous faire une nouvelle branche à partir de l'état actuel du tronc (ou de n'importe quelle autre branche), et de basculer dessus. L'état du projet dans C:développementmon_projet est celui sur lequel vous travaillez.

Mais un patron vous appel en urgence, il faut un fix de sécurité sur la branche de maintenance de la dernière release 2.4... pas de soucis, vous demandez à Git de vous mettre de côté les modifications en cours (ce que vous étiez en train de faire en tout dernier mais pas encore en étant d'être historisé tel quel), puis vous demandez à basculer sur une nouvelle branche "hotfix" créée à partir de l'état courant de la branche de maintenance de la release "2.4". L'état du projet dans C:développementmon_projet est maintenant celui de la branche de lreease 2.4. Vous travaillez, faites des commit, etc. Quand c'est bon, vous intégrez votre branche à la branche de release (ou vous demandez au responsable de cette branche de le faire), puis vous demandez à Git de revenir sur votre branche de fonctionnalité. L'état du projet dans C:développementmon_projet est à nouveau celui dans lequel vous l'aviez laissé avant d'être interrompu, moins vos dernières modifications non commitées. Mais il suffit de demander à Git de vous les rendre, et voilà.

Sachant que chaque "basculement" d'une branche à une autre est affaire de secondes (moins de 2 pour mon précédent projet d'un millier de fichiers sur un SSD, pour exemple).

Et chaque basculement se fait en 1 commande en ligne ou quelques clics (genre 3 ou 4, pas plus) dans Eclipse. Et vous n'avez rien d'autre à faire, puisque tout à lieu dans le même unique répertoire, donc tous vos outils externes (Eclipse en particulier, mais aussi vos scripts de compilation, etc) vont continuer à fonctionner sans soucis.

Et donc en sachant cela, on hésites plus à créer une branche, même pour 5 minutes, même pour modifier un seul fichier, une seule ligne au besoin. Et d'un point de vue traçabilité de l'historique, c'est un vrai plus. Si ça vous est déjà arrivé de devoir chercher quand un bug a été introduit et ce qui l'a introduit, vous me comprenez. Avec Git, il est TRES facile de tester différents points de l'historique (tout simplement en demandant à Git: bascule mon projet sur une branche créée à partir de l'état du tronc tel qu'il était hier/avant-hier/etc, compiler et tester si le bug est déjà présent ou non) puis d'identifer pourquoi il a été introduit (= comment s'appelle la branche qui a introduit le bug lors du merge? et que dit le message du commit qui a introduit le bug dans cette branche?). Evidemment, ça implique de donner des noms "parlant" à vos branche (donc pas "ma_branche" mais plutôt "fonction_tri_par_date") et de mettre des messages de commit un peu parlant ( pas "Work In Progress" mais "modification de l'aglo de tri").

Oui parce qu'en plus, comme vous êtes dans votre propre repo, vous n'hésitez pas à faire beaucoup, beaucoup plus de commits, et donc les messages deviennent plus faciles à écrire, parce qu'ils sont courts et résument juste ce que vous avez fait ces 2 dernières heures en gros. Ca aussi c'est bien pour la traçabilité (et donc la maintenabilité).

Ok, mais les conflits?

Bon, on va pas se mentir: des conflits vous en aurez, forcément. A moins de bosser tout seul, ou d'avoir une séparation des tâches et des domaines absolument parfaite, il y aura des moments où 2 personnes auront modifié le même fichier. Mais déjà comme je le disais précédemment, Git gère ça plutôt mieux que SVN, et donc régulièrement Git se contendra de vous dire "ouais, j'ai vu, Benjamin et Carlos ont modifié le même fichier, mais c'est pas les mêmes lignes donc ça va, je gère". Mais même ça, ça arrivera pas souvent, pour une raison simple: chaque développeur s'occupe de résoudre ses éventuels conflits AVANT d'intégrer sa branche.

Allez, déroulons un scénario:

1) Adam a créé un repo pour le projet, et ajouté un fichier nommé source.txt et contenant 2 lignes de texte:

debut

fin

2) Benjamin et Carlos on tous les deux cloné le repo initial, et ont chacun fait une branche "fonction 1" (pour Benjamin) et "fonction 2" (pour Carlos) et ajouté une ligne entre les deux existantes : "ma ligne" dans un cas, "mon autre ligne" dans l'autre.

3) Benjamin a fini le premier. Et là on entre dans la partie intéressante: il COMMENCE par vérifier que son travail ne créé pas un conflit avec l'état ACTUEL du tronc en faisant un merge de la branche principale (elle s'appelle "master" par defaut, mais c'est l'équivalent du "trunk" SVN) dans sa branche à lui. Comme la branche master n'a pas changé depuis la création de sa branche à lui, Git lui indique que l'intégration s'est faite sans soucis, et il peut maintenant:

a) intégrer directement sa branche "fonction 1" dans la branche master DE SON REPO A LUI puis signaler au serveur central que la branche master du repo initial devrait être remplacée par la branche master de son repo à lui, et seulement si Adam lui a donné les droits d'écritures nécessaire

OU

b) signaler à quelqu'un ayant les droits d'écritures nécessaires sur le serveur (disons Adam) d'intégrer la branche "fonction 1" de son repo à lui dans la branche "master" du repo initial. Adam étant consciencieux, il commencera par créer une branche sur le repo initial à partir de l'état de la branche master, essaiera d'y intégrer la branche "fonction 1" du repo de Benjamin, et s'il n'y a pas de conflit, reproduira l'opération sur la branche master

4) Maintenant Carlos a fini aussi. Mais lui c'est un fainéant (saligaud de basanés), donc il se fait pas chier, il demande direct à Adam d'intégrer sa branche "fonction 2" dans la branche master du repo initial. Adam fait une branche depuis son master qui contient déjà l'intégration de la branche "fonction 1", essaie de faire un merge, arrive à un conflit: il refuse l'intégration, signalant le problème à Carlos.

5) Carlos doit donc mettre à jour la branche master de son repo par rapport à la branche master telle qu'elle est dans le repo initiale PUIS faire un merge de la branche master de son repo dans sa branche "fonction 2". Git lui signale le conflit sur le fichier "source.txt". Carlos ouvre le fichier et voit:

debut

<<<<< theirs zer54ez867654zer

ma ligne

=======

mon autre ligne

>>>>> mine

fin

6) il résoud le conflit (au besoin en contactant Benjamin pour savoir exactement à quoi correspond la ligne en conflit, savoir s'il la garde, etc) EN LOCAL. Une fois le conflit résolu (git va créer un commit supplémentaire dans l'historique correspondant à ce merge de la branche master et à la résolution du conflit), Carlos peut redemander l'intégration de sa branche dans master.

En conclusion de ce long (beaucou trop) paragraphe, il faut surtout retenir que le "gestionnaire" du repo central n'a pas pour tâche de résoudre tous les conflits (raison n°1 pour laquelle ma précédente entreprise refusait de passer à Git), mais que chaque membre doit s'assurer de la bonne intégration de sa branche avant de la proposer.

Mais encore une fois, Git est là pour vous aider, car chaque développeur peut comparer et intégrer sa/ses branches non seulement avec celle(s) du repo central, mais aussi avec les branches des repo de chaque autre développeur!

Mettons que vous avez un développement en cours sur une fonctionnalité un peu compliquée, ça fait bien 3 jours que vous êtes dessus, et il vous reste au moins 2 ou 3 jours de boulot à vue de nez. Sauf qu'entre temps la branche master progresse, et qu'hier un autre développeur a fourni la correction d'un bug critique pour votre fonctionnalité qui a été intégrée à la branche master du repo central. Vous avez plusieurs options:

1) intégrer directement la branche master du repo central dans votre branche. Avantage: vous restez synchro avec la branche master, donc les risques de conflits à la fin, lorsque vous voudrez intégrer votre branche sont diminués d'autant (et au pire vous les résolvez au fur et à mesure ça devrait êytre plus simple). Inconvénient: vous récupérer toutes les autres modifs, et ça vous arrange peut-être pas pour le moment.

2) intégrer uniquement la branche du développeur contenant le correctif. Avantage; vous ne récupérez que la branche nécessaire, donc moins de risque de conflits et de "pollution" par des modifications qui n'ont rien à voir. Inconvénient: Et les conflits lorsque vous allez vouloir intégrer "master" alors? Est-ce que les modifications ne vont pas être faites 2 fois, provoquant des conflits systématiques? Ben non, Git est un malin, il va "reconnaitre" les commits de la branche en question et ne pas les re-intégrer, et hop, pas de conflits. Mais intégrer une branche complète, c'est potentiellement encore trop.

3) intégrer uniquement le (ou les) commit contenant le correctif. Oui, Git permet d'aller chercher un unique commit dans une autre branche et de l'intégrer dans la branche courante. Et bien sûr, il identifiera correctement tout ce petit monde plus tard quand vous intégrerez la branche master et ne le rejouera pas.

Souplesse maximale de votre workflow, et tout ça toujours en local, donc sans emmerder personne et sans squatter de ressources communes (ça vous est déjà arrivé d'avoir un commit SVN "bloqué" pendant 1h parce qu'un collègue a commité par erreur un fichier dump de 2Go? Moi oui, et pendant ce temps là vous ne pouvez plus faire aucun commit). Bien sûr, il faut un minimum de communication réseau pour "récupérer" une branche d'un autre repo, mais c'est assez rapide.

Oui mais nous on a 10 ans d'historique SVN et une demi-douzaine de branches, comment qu'on fait?

Vous ne mettez pas la mode au pays, Git exitse depuis déjà quelques années, donc ce cas de figure est connu et couvert depuis longtemps. Git intègre donc un outil "git-svn" permettant des communications entre un repo Git (le vôtre, en local) et un repo SVN "central". Je ne vais pas m'étendre parce que sinon je finis plus, mais cet outil permet entre autres de migrer un repo SVN en repo Git (branch et tag compris), mais également des trucs un peu dangereux, comme se faire un repo Git en local pour travailler avec une équipe qui utilise toujours un repo SVN central (essentiellement dangereux parce que votre repo local gère beaucoup plus de branches que ce que le repo SVN peut gérer, et que la gestion des numéros de commit est radicalement différentes).

C'est précisement dans ce contexte que j'ai découvert Git (migration d'un repo SVN en repo Git), ça m'a pris une petite semaine d'écrire le script qui va bien pour tout bien récupérer, sachant que le reste de l'équipe continuait de bosser et de commiter sur le repo central SVN en même temps et qu'ils s'étaient tous créé des comptes Github avec des identifiants différents (donc qu'il fallait modifier les commit SVN au fure et à mesure pour changer l'attribution du commiter). Et que je suis pas un expert du script shell. Donc c'est vraiment à la portée de n'importe qui ou presque (on exclue tata michèle par principe, mais à part ça).

Tout ça c'est beau, mais c'est trop technique pour être vendu à mon incompétent de directeur

Je ne peux que vous conseiller d'aller regarder du côté des outils graphiques comme "giggle" ou "gource" qui permettent de faire des rendu graphique de l'historique d'un repo Git, ça peut faire des visuels convaincant pour une présentation powerpoint. Et ça peut aussi servir pour de vrai (enfin pour gource j'ai un doute, mais giggle je m'en sers régulièrement pour vérifier l'état des différentes branches de mon repo et de celui de mon collègue).

 

Allez, j'ai la flemme de me relire mais je suis sûr que j'ai très mal expliqué un tas de trucs, donc allez-y, posez vos questions!


[Développement] Application Android

posté le 23 July 2014 à 14:37

Salut les geeks (oui, si vous avez cliqué malgré le titre, vous êtes irrémédiablement un geek, voir un nerd), et attention: voilà du wall of text!

Comme je me suis lancé dans l'aventure des applications mobiles depuis quelques mois, et que j'ai appris pas mal de choses en cours de route, je me suis dit que ça pouvait valoir la peine d'écrire un post pour:
1) partager avec ceux que ça pourrait intéresser les trucs que j'ai appris (en particulier des outils/librairies sympa comme tout)
2) apprendre vos propres trucs et astuces

J'ai mis Android dans la titre, parce que c'est mon focus du moment, mais si vous avez des trucs et astuces qui peuvent s'appliquer aux applications mobiles dans l'absolu, ça marche aussi. Par exemple (pas tout à fait au hasard: je vais avoir à faire ça dans pas longtemps donc si quelqu'un sait comment faire ça, je suis preneur d'un peu d'aide): vous connaissez un super outil pour mettre en place vite et bien un webservice en java hébergé sur l'AppEngine de google (et pouvant donc servir de backend à une application web ou mobile), allez-y, dites nous tout!

Et histoire de démarrer le truc, voilà ma première pierre à l'édifice:

Recrute majordome, mobilité et capacité à rédiger des rapports exigées

Déjà, et contrairement à ce que j'avais lu sur plusieurs sites (dont l'habituellement raisonnablement bien renseigné openclassroom, ex site du zero), il est tout à fait possible de mettre en place un environnement d'intégration continue pour un projet Android. S'il y en a qui ne savent pas ce que c'est que l'intégration continue et pourquoi c'est génial et qu'on ne peut plus s'en passer une fois qu'on y a goûté, faites-moi signe dans les commentaires (en particulier si vous bossez sur un projet avec plus de 4 personnes sur la même base de code).


Pour cela, il faut:
 - un SCM (SVN ou Git, ma préférence allant à ce dernier depuis que je l'ai adopté en janvier dernier, si ça intéresse quelqu'un je pourrais expliquer pourquoi)
 - un outil de compilation (Gradle, Ant ou Maven, je connais déjà Maven donc je reste sur celui-là mais à priori c'est possible avec les 2 autres quasiment de la même manière)
 - un serveur d'intégration continue (vous posez pas de question, c'est Jenkins qu'il vous faut)

La difficulté réside dans la capacité à faire compiler le projet avec l'outil de compilation. Par compiler, j'entends; compiler les fichiers de code .java en .class (ça Maven sait le faire en natif), produire le .dex qui les réunit tous, puis intégrer le .dex et les ressources dans l'apk (signé ou non, selon qu'on est en debug ou en release), déployer et executer sur un device (c'est à dire un téléphone ou un tablette connectée en USB et avec le mode debug activé) ou sur un émulateur (parce qu'on a pas tous les moyens d'avoir 15 devices différents pour tester toutes les tailles d'écran et toutes les versions d'android), tout ça x2 puisqu'il faut un projet "principal" (l'application en elle-même) et un projet de test (vous testez votre code, n'est-ce pas?).

Pour ma situation (Maven + Jenkins), il faut 3 outils:
1) Un "outil" appelé "Maven Android SDK deployer", qui va essentiellement ajouter à votre repository Maven local les jar des différents versions d'android (et des extra, genre les Google APIs si vous vous utiliser Google Maps, etc), sachant que sa plus-value principale est surtout sur ces extra (les jar des principales version d'android étant désormais ajoutés par google sur Maven Central).
2) un plugin maven: le bien nommé "Android Maven Plugin" qui va ajouter à maven quelques goal bien pratiques, tels que "android:deploy" pour déployer un apk sur un device ou un émulateur, ou encore "android:run" pour lancer l'execution. Et aussi un format de packaging supplémentaire "apk" (sachant que maven gère nativement "jar" et "war" il me semble).
3) un plugin Jenkins: le (lui aussi bien nommé) "Android Emulator Plugin" pour automatiser la création d'émulateurs, leur paramétrage, obtenir les résultats d'une exécution, bref, tout ce qu'il faut pour de l'intégration continue. Pardonnez moi de rester flou sur ce point, je suis tout juste en train de le mettre en place, je ne maitrise pas encore super bien (mais encore une fois, si ça intéresse du monde, je pourrais développer au fur et à mesure de mes avancées).

Tout ça c'est chouette comme tout, vous allez pouvoir mettre en place une intégration continue de votre projet Android, et tout sera pour le mieux dans le meilleur des mondes...

Plus vite nestor ou je te remplace par un mouton réplicant

... enfin presque, parce que bon, même comme ça, l'intégration continue ne va pas se déclencher toute les 3 minutes non plus et même si c'était le cas, lancer un émulateur, déployer l'apk dessus et lancer l'appli ça prend au moins quelques minutes dans le meilleur des cas. Donc pour dérouler des tests de non régression fonctionnels ça va encore, mais pour du test unitaire c'est pas idéal.

Et c'est là qu'intervient ma découverte d'hier (qui a motivé ce post interminable): Robolectric. Cette petite merveille (gratuite et open source, comme tous les outils/plugins cités jusque là) "remplace" le fichier android.jar habituel (et qui vous jettera des "java.lang.RuntimeException : Stub!" à la tronche si vous essayez de le faire tourner dans un JVM classique car il ne contient aucun vrai code, uniquement les déclarations d'API pour vous permettre de compiler) par ce qu'il faut (non, j'en sais rien et je sais même pas comment, mais ça marche) pour que vous puissiez faire tourner votre code de test dans une JVM classique, par exemple (au hasard) celle de votre IDE préféré (Eclipse pour moi, et probablement 90% des dveloppeurs d'appli Android). Ca veut dire que moyennant un peu de paramétrage de raccourcis clavier, il y a moyen d'exécuter vos tests unitaires quasiment à chaque fois que vous sauvez votre fichier de code, et qu'ils seront exécuté presque instantanément. En ce qui me concerne, j'ai re-configuré Ctrl+D pour lancer mes tests unitaires, ce qui fait que je fais très souvent Ctrl + S, Ctrl + D sans même lever le doigt de la toucher contrôle, vous allez voir que ça devient un réflexe assez vite (en vrai, je fais en général Ctrl + O, Ctrl + F, Shift + Ctrl + S, Ctrl + D, pour respectivement: organiser/nettoyer les import, formatter/indenter le code, sauver tous les fichiers ouverts et lancer les tests unitaires, les 3 premiers étant des raccourcis standard eclipse).

Attention, ça ne remplace pas des "vrais" tests fonctionnels sur émulateurs (au pire) et sur device (au mieux), ça vient les compléter. Et si vous ne pouvez pas vous permettre le luxe de faire les deux (même si d'après mon expérience personnelle c'est largement rentable sur le long terme), j'ai tendance à conseiller les test unitaires en priorité, car leur execution quasi synchrone avec l'écriture du code permet d'éviter de s'éloigner de l'objectif en cours de réalisation pour l'heure/la journée. Tandis que les tests fonctionnels délimitent les grandes lignes attendues du point de vue utilisateur que vous allez peut-être mettre des semaines voire des mois à atteindre...

La prochaine fois (c'est à dire: quand j'aurais eu le temps de tester) je vous parlerer de Dagger, une chouette librairie pour faire de l'injection de dépendance sur Android (et pour les suivantes, j'ai au menu: Mockito, un framework de mock pour compléter Robolectric, Otto, une librairie de bus évennementiel à la guava, ButterKnife pour faire l'injection des vue dans une activité, Retrofit, un client REST type safe pour android et plus largement pour Java et FestAndroid, une collection d'assertion AssertJ pour android).

Voilà, c'est tout pour aujourd'hui!

Des questions? Des avis? Vous avez rien compris mais ça vous intéresse et vous voudriez que j'explique un terme ou un concept précis? Les commentaires sont la pour ça, lâchez-vous!


Intervention surprise: de l'eau jusqu'au cou

posté le 20 April 2011 à 01:03

Dans un effort pour garder ce blog vaguement en vie: un nouvel article!

Donc de temps en temps, parce qu'il faut bien qu'on rigole un peu sinon la vie manque de sel, on a une galère. La dernière pour moi, c'était le chauffe-eau. 

Pour ceux à qui ça parlerait: groupe de sécurité qui fuit en continue. 

Pour ceux à qui ça parle pas: plus d'eau chaude du tout, et de l'eau qui coule en continue directement à l’égout. 

Cause probable: particule de calcaire qui vient bloquer le mécanisme en position ouverte, vu que ledit chauffe-eau a été détartré récemment par mes soins (15 bons kilos de tarte sortis, ça m'avait déjà bien occupé). 

 

Bon, comme je ne sais pas nettoyer un groupe de sécurité (il parait que ça se fait, mais le concept même me paraît incompatible avec le terme "sécurité"), il a fallu remplacer. Quitte à y être, j'ai décidé de mettre en application deux-trois choses apprises depuis ma dernière intervention sur la bête.

 

État des lieux: comme à peu près tout dans cette maison, le chauffe-eau a été monté en mode "après moi le déluge". Rien n'est flexible: arrivée d'eau froide en tuyau de cuivre non flexible jusqu'au groupe de sécurité, sortie d'eau chaude pareil, évacuation du groupe de sécurité aussi. Il va falloir découper les tuyaux pour installer les nouveautés.

 

Chantier prévu: 

 - isoler la partie chauffe-eau du reste du réseau par l'ajout de 2 vannes à boisseau qui permettront en cas de chantiers ultérieurs ne pas avoir à couper l'eau dans toute la maison.

 - ajouter de flexibles à la sortie de ces vannes pour faciliter le raccordement du ballon (même en cas de changement dans le futur par un ballon d'un modèle différent) et autre matériel.

 - ajouter entre le ballon et le groupe de sécurité un vase d'expansion sanitaire qui limite le gaspillage: quand l'eau chauffe la nuit, elle prend plus de place. Si vos robinets sont bien fermés et que le groupe de sécurité joue bien son rôle (obligatoire) d'anti-retour vers le réseau d'eau froide, le groupe de sécurité laisse s'échapper une petite quantité d'eau pour éviter que le chauffe-eau ne monte trop en pression et finisse par exploser. C'est d'ailleurs cette fonction de régulation de la pression qui lui vaut son nom. L'ajout d'un vase d'expansion va, par un système de membrane souple, compenser ce volume gagné lors de la chauffe sans trop augmenter la pression à l'intérieur du ballon, évitant au groupe de sécurité de devoir laisser partir de l'eau chaude et saine. On économise ainsi environ 1000L d'eau par an. Alors certes, au prix actuel du mètre cube d'eau, l'investissement pourtant faible mets plusieurs années à se rentabiliser, mais en termes d'économie d'eau potable, la planète vous dis merci.

 - ajouter un mitigeur thermostatique à la sortie d'eau chaude du ballon. Double avantage de cet équipement: d'une part il évite les accidents en limitant la température maximale de l'eau chaude à 50°C (ce qui est largement suffisant pour une vaisselle ou une douche même très chaude, mais on peut baisser ce seuil) ce qui explique qu'il est désormais obligatoire en construction et en rénovation lourde, et d'autre part il garantit une température stable de l'eau chaude: tant qu'il reste de l'eau chaude dans le ballon, la température de l'eau chaude dans vos tuyaux sera la même. Sans ce dispositif, entre le "début" et la "fin" de l'eau chaude dans votre ballon, la température peut varier de 80°C à 40°C, obligeant à de constants ajustements au niveau des robinets...

 - tant qu'on y est, installer 2 raccords diélectriques (absents dans l'installation d'origine) qui protègent le tout de la corrosion galvanique (entre le tuyau de cuivre qui amène l'eau froide et l'acier du ballon d'eau chaude peut se développer une réaction chimique qui raccourci la durée de vie de l'installation).

 

Allez, quelques photos du résultats pour vous reposer les yeux.

Le mitigeur thermostatique en forme de T (le "bouchon" en plastique bleu permet de régler la température de l'eau chaude entre 35°C et 50°C ), avec au dessus de lui le raccord diélectrique doré qui le sépare du ballon (arrivée d'eau chaude), au premier plan et en bas le flexible qui lui amène de l'eau froide, et en arrière plan la vanne à boisseau suivit d'un flexible qui isole le reste du réseau d'eau froide. La sortie d'eau chaude vers les robinets est à gauche (branchée sur un flexible suivi d'une vanne à boisseau donc).

 

Vous voyez que le principe est simple: dès que l'eau (très, voir trop) chaude sort du ballon, on la mélange avec de l'eau froide, l'aspect thermostatique permettant d'obtenir une température constante en sortie, indépendamment de la température de l'eau dans le ballon et de la température de l'eau dans le réseau d'eau froide.

 

 

Le vase d'expansion sanitaire, pas encore fixé au mur, mais déjà raccordé à un flexible lui-même raccordé à un Té qui vient s'insérer entre le chauffe-eau et le groupe de sécurité.

 

Et pour finir, une vue d'ensemble de l'installation:

L'arrivée d'eau froide se fait par la vanne rouge au fond à gauche, et via le flexible arrive au Té au milieu. La sortie de droite de ce Té alimente le ballon en eau froide (notez le groupe de sécurité en bas à droite dont on voit bien la vanne de sécurité rouge, le Té du vase d'expansion au dessus, et le raccord diélectrique tout en haut juste avant l'entrée d'eau froide du ballon), tandis que la sortie de gauche alimente en eau froide le mitigeur thermostatique (entrée du bas de ce dernier) qui dont l'entrée d'eau chaude et branchée directement sous le raccord diélectrique à la sortie d'eau chaude du ballon (à gauche donc, si vous suivez). Pour finir, la sortie d'eau chaude du mitigeur part dans le flexible le plus à gauche, vers le réseau d'eau chaude (on ne voit pas la vanne qui sépare ce flexible du réseau).

 

Les plus observateurs auront remarqué que l'évacuation du groupe de sécurité n'es pas encore raccordée, ce qui n'est pas grave puisqu'elle servira beaucoup moins grâce au vase d'expansion.

 

Bilan: presque 4 heures de boulot (plus le temps d'aller chez lerein-mèreloie choisir et acheter:), un peu plus de 100 euros de matériel (soit environ 300 euros d'économisés par rapport à l'intervention d'un plombier en urgence pour le seul remplacement du groupe de sécurité), une poignée de galères comme sur tout bricolage digne de ce nom (oublié d'acheter les raccord mâles pour les tuyau de cuivre, etc), une jolie frayeur (oublié d'ouvrir la vanne d'arrêt du groupe de sécurité =&gt; pas de pression d'eau chaude après avoir tout monté...) et une "belle" installation sécurisée.

 

Ça valait la peine de se donner du mal!

 


Où l'on ajoute le sucré

posté le 06 January 2011 à 21:32

Allez, deuxième essai, deuxième article.

Vous connaissez le truc maintenant, je vous refais pas une introduction complète, si? Si? Bon d'accord... où est mon lubrifiant?

Hein? On s'est mal compris? Ah pardon... bon ben je vais vous parler de mes yaourts alors.

Donc hier soir, motivation, deuxième tournée. Toujours par 8, mais avec un peu de variation. On commence par mettre un peu de douceur au fond.

yaourts avec fond sucré

De gauche à droite: confiture de figues (x2), confiture de framboises (x4) et crème de marrons (x2). Cette photo a été prise ce soir, donc après 8h de fermentation et un peu plus de 12h de réfrigération...

Je vais pas vous faire saliver plus longtemps: plongeons, goûtons! (enfin surtout moi, vous vous allez devoir vous contenter de regarder...)

plongée

Le cobaye est de la variété dite "aux figues".

Comme la confiture de figues est assez épaisse, il faut remuer un peu pour bien mélanger, ça fait de jolis effets.

yaourt et confiture

Et surtout, c'est bon. Très. Faut dire que j'adore la figue (et le yaourt, je pense que vous aviez compris).

Vu que ma chère et tendre a trouvé bon aussi, le test est considéré concluant et l'expérience sera renouvelée. Ce qui n'empêchera pas d'autres expériences, surtout qu'on a acheté un set de pot en verre supplémentaire pour pouvoir faire une tournée chaque soir.

D'ailleurs je vais pas allonger plus, j'ai une tournée aux speculoos à lancer.

Allez, hier j'avais promis de penser aux (trop rares) dames et demoiselles qui fréquentent ce lieu de perdition... je viens de me taper 25 pages de google image avec le filtre désactivé et les mots clés "sexy yogurt male", et j'ai rien trouvé de mieux que ça:
man with yogurt

Alors oui, il y a un watermark à la con et oui, le type a l'air demeuré, mais c'était ça ou du gay très très explicite.

En vous remerciant, bonsoir.


Sexy Yogurt...

posté le 04 January 2011 à 22:05

Commençons par le commencement: Si votre première pensée à la lecture de ce titre a été sexuelle, passez votre chemin!

Ici on parle des vrais plaisirs de la vie, les seuls qui comptent vraiment, les seuls qui aient une quelconque importance, ceux qui ont lieu à table. Et si vous avez pensé "pipe sous la table", vous êtes disqualifiés aussi. Mais je digresse.

La bouffe donc. Important. Très. Et en bon bobo - ou bonobo, allez savoir - j'ai tendance à vouloir contrôler de plus en plus ce que je mange. Le fait d'avoir une miniature de 18 mois doit jouer un peu aussi. Mais surtout je suis super gourmand. Pas gourmet, ça fait tafiole. Et ça implique des quantités ridicules. Et si vous continuez à me faire digresser tout le temps je ne vais jamais arriver à finir cet article...

Donc je suis gourmand et je veux contrôler. Comme ma belle-mère m'aime bien (si, si) et qu'elle commence à me connaître, pour mon noël elle m'a offert une yaourtière. Certes, je soupçonne la fourbe d'avoir d'abord pensé à la qualité de ce que mangera la petite mais nul n'est parfait sauf moi. Je ne peux donc pas trop lui en vouloir - ce qui ne m'empêchera pas de lui faire un cadeau de merde l'an prochain.

Du coup, hier soir j'ai lancé mon premier batch: 1L de lait demi écrémé et 1 yaourt du commerce (Auchan au bifidus, pour ceux qui aiment les détails cochons). Ca part par 8 petits pots (je laisse la production semi-industrielle au lama), mais c'est pas plus mal, parce que vu la taille, s'ils sont bon, je vais les manger par 2.

Ce matin, après 8h de fermentations, je transfère fébrilement mes petits pots au réfrigirateur.

Et en rentrant ce soir, j'avais ça:

 

Un petit pot blanc, l'air de rien

(les plus observateurs remarqueront un pot vide sur la droite... madame et la miniature ne m'ont pas attendu pour goûter!)

 

Déjà, je suis content: contrairement à ce qu'on m'avait annoncé, l'utilisation de lait demi-écrémé ne nuit pas à la texture. Ca se tient, et même ça se tient bien:

 

ça se tient même très bien

 

J'avais lu a plusieurs endroits qu'il fallait renforcer le taux de protéines en ajoutant du lait en poudre sous peine d'avoir une texture liquide. Il n'en est rien, la texture est à la fois ferme et onctueuse, je suis fort satifsait.

Au niveau du goût enfin, le résultat est à la hauteur de mes attentes: sans être complètement différent d'un yaourt du commerce, le goût est légèrement plus prononcé, avec une petite note d'aigreur à peine marquée.

Conclusion: non seulement il y aura d'autres fournées, mais je vais de ce pas commander quelques pots de plus pour pouvoir les enchaîner et varier les recettes.

 

Et pour remercier ceux qui ont lu jusqu'au bout malgré la déception initiale - mesdames et mesdemoiselles, je penserais à vous la prochaine fois, promis - du nichon au yogurt:

Annie aime le yogurt aussi

 

(vous n'imaginez pas ce que j'ai du affronter comme résultats sur google image avec comme mot clé "sexy babe yogurt" pour trouver un truc raisonnable)


EDF: a nous de vous faire préférer la concurrence

posté le 25 August 2009 à 08:56

Allez, par solidarité avec groove et hohun, je vous raconte mes propres déboires...

Ca commence aux alentours de la mi-avril. Etant mensualisé (pour me simplifier la vie... en théorie), je paye une certaine somme par mois (tous les mois la même), et une fois par an, EDF m'envoie un récapitulatif de l'année, avec équilibrage, selon que j'ai consommé plus ou moins que ce qui était prévu. En général (les 2 années précédentes), ça se passe plutôt bien, je consomme en gros ce qui est prévu, et j'ai un équilibrage de moins d'une centaine d'euros prélevé au mois de juin (donc au final a peu près pareil que les autres mois), et en juillet on recommence.
Donc là, arrive comme prévue le bilan de l'année, et c'est la première surprise: tiens, j'ai dû dépasser comme un con, j'ai 450 euros d'équilibrage... ben merde alors, pourtant l'automne dernier j'ai remplacé tout mes radiateurs (vieux convecteurs de merde par des radiateurs à brique réfractaire), c'était censé me faire faire des économies... les boules donc.

Deuxième surprise: le calendrier des prélèvements de l'année prochaine commence en juin au lieu de juillet. Donc au mois de juin, je vais devoir payer 600 euros (oui parce qu'en plus, du coup ils augmentent la somme par mois) à EDF. Heuuuuu... c'est sympa, mais ça va commencer à me faire un trou dans les finances là quand même...

Bon, par aquis de conscience, je vais quand même voir mon compteur à la cave, des fois qu'ils auraient un peu sur-estimé. En fait ils ont même gravemen sur-estimé! Calculatrice en main, je fais en gros mes comptes: la différence est quand même de 200 euros!!!

 

Bon, c'est pas grave: j'appelle la hotline, ils vont régulariser ça, pas de problèmes. C'est là qu'on voit que je suis naïf, hein?

Donc, j'appelle (début mai, parce que j'avais autre chose à foutre faire). Je tombe sur un conseiller, à qui j'explique ma situation:
 - Je viens de recevoir ma facture annuelle, y a erreur sur les chiffres, et en plus vous voulez faire repartir la mensualisation le même mois que l'équilibrage... est-ce qu'il y a moyen de corriger le tir (genre: étaler, ou commencer la mensualisation en juillet, comme les années précédentes).
 - Ben non monsieur, c'est de l'électricité que vous avez consommé, il faut la payer maintenant.

 - ... alors déjà, non, puisque les chiffres que vous avez utilisés pour me facturer sont faux. Je me demande comment vous faites d'ailleurs, puisque c'est moi qui vous envoie mes chiffres touts les 6 mois par le biais de la fiche que vous me fournissez... De toutes façons, je veux bien payer, je voudrais juste qu'on étale un peu, et que la mensualisation commence le mois où elle est censée commencer.
 - Désolé monsieur, on peut rien faire.
 - Pourquoi?
 - On est le 10 mai, pour les prélèvements de début juin tout est déjà lancé, on peut plus changer.

 - ??? Quasiement un mois à l'avance, on peut plus toucher à rien?
 - Non monsieur.
 - Mais vos chiffres sont faux!
 - On peut rien faire.
 - Si, si, on va faire un truc: vous aller arrêter tout de suite la mensualisation pour l'an prochain, puisque le prélèvement était prévu le 15 juin et qu'on est le 10 mai, ça doit être assez longtemps à l'avance. Et puis on va en revenir au bon vieux système de paiement par TIP, avec courrier et tout le merdier, hein?
 - D'accord. Du coup, pour le TIP de juin, il me faut les chiffres de votre compteur.
 - [je donne les chiffres]
 - Mais c'est très inférieur à ce qu'on a!
 - ... ... c'est un peu ce que j'essaie de vous dire depuis un moment là...
 - Je peux pas faire confiance à vos chiffres (?) il va falloir qu'un technicien passe faire une relevé (??), ça va vous coûter 45 euros (?!? WTFBBQ??!?)
 - Pas moyen.
 - De toutes façons ça fait plus de 6 mois qu'un relevé visuel n'a pas été fait par un technicien, donc il faut qu'il passe.
 - Ca c'est votre problème, de toutes façons ça fait même plus de 2 ans qu'il y a pas eu un technicien pour relever mon compteur et bizzarement ça posait pas problème quand il s'agissait de me surfacturer.
 - Si, il y a un technicien qui est passé l'an dernier.
 - J'en doute: le compteur est dans ma cave, et EDF n'a pas encore les clés de chez moi (enfin j'espère).
 - De toutes façons il faut qu'un technicien passe.
 - Non, je paierais pas 45 euros pour qu'un gars vienne lire des chiffres que je peux lire moi-même, sous prétexte que ça vous fait chier que j'arrête la mensualisation.
 - D'accord, donnez moi les chiffres (? Ah, ça y est, finalement y a plus besoin d'un technicien?)
 - [je re-donne les chiffres, déjà donnés 5 minutes plus tôt]
 - Très bien monsieur, la mensualisation est arrêtée, vous recevrez un TIP en juin.
 - Et donc je serez prélevé de trop début juin, et le TIP de mi-juin corrigera le tir?
 - Oui, oui, pas de problèmes.
 - Et ben voilà, c'est déjà mieux que rien! Merci quand même pour l'effort.
 - Je vous en prie, bonne journée à vous monsieur.

Là, j'étais presque content, je me suis dit que ça allait se régler, et qu'en septembre je re-prennais la mensualisation sur des bases saines (comprenez: des chiffres correspondants à mon compteur).

...

Passe le 10 juin, je suis effectivement prélevé de 450 euros (ouch). Passe le 15 juin, je suis prélevé de 150 euros. BORDEL!

Furax (forcément), je rappelle la hotline:
 - [j'explique mon cas, et ce qui avait été décidé avec mon précédent interlocuteur]
 - Il vous a dit n'importe quoi, on peut pas arrêter la mensualisation par téléphone, il faut faire un courrier (?!).
 - Un courrier a qui? A vous?
 - Non, à votre banque (!?).
 - Donc là je suis encore en mensualisation, et avec les nouveaux chiffres en plus?
 - Oui.
 - Bordel! ... Pardon, mais fais chier quoi! Je viens de vous filer 600 euros ce mois-ci, dont 250 que je vous dois pas réellement, j'ai un peu les boules quand même.
 - On peut rien y faire.
 - Si: vous allez me passer votre supérieur, je suis sûr qu'on va trouver une solution (là, je commençais à être vaguement agacé).

[attente interminable à 34 centimes la minutes]

 - Bonjour monsieur, qu'est-ce que je peux faire pour vous?
 - [je re-explique mon cas, bien en détails, avec tout ce qu'on m'avait dit, etc, toujours à 34 centimes la minute]
 - Oui, oui, pas de problèmes, on peut arrêter la mensualisation (Ah? Mais putain mettez vous d'accord entre vous, merde!) et on va prendre vos chiffres pour régulariser à partir du mois prochain.
 - [je descends à la cave, je relève les chiffres, je les donnes] Donc là c'est bon cette fois?
 - Oui, oui. Mais bon, faut pas vous étonner d'avoir des grosses factures quand même, avec une grande maison de 200m² à chauffer.
 - Ma maison fait 68m² (en comptant la cave, que je ne chauffe pas), c'est de l'ancien avec des gros murs épais qui isolent bien, j'ai changé tous les radiateurs...
 - Ah?
 - Oui, oui.
 - Mais pourquoi vous avez un aussi gros abonnement alors?
 - Gros comment?
 - De quoi alimenter une petite usine en fait: du tri-phasé en 18 kilo-volt-ampère (18 kilo Watt, quoi). D'après ce que vous me dites, à moins que vous ayez une machine outil, un spa, ou une pompe à chaleur (ces petites bêtes là demande du tri-phasé), c'est sur-dimensionné.
 - De beaucoup?
 - Ben un abonnement mono-phasé à 9kVA suffirait.
 - Et ça change la facture?
 - D'environ 200 euros par an.
 - ... c'est quoi cette merde? Pourquoi j'ai ça comme abonnement?
 - Ben le tri-phasé, c'était le standard dans les années 60, faut croire que ça a pas été changé chez vous depuis (bon, là je confirme: mon compteur était antédiluvien). Et la puissance, ben le conseiller que vous avez eu quand vous avez ouvert le compte a dû surdimensionner un peu (un peu...)
 - Comment on règle ça?
 - Il faut qu'un technicien passe chez vous (mais c'est une manie ma parole), mais là c'est plus nous qui géront ça, c'est ERDF.
 - Qui ça?
 - Electricité, Réseau et Distribution de France. ( digression: ERDF = La filiale qui a été fabriqué de toutes pièces quand le gouvernement a commencé à prévoir la mise en concurrence et la privatisation du marché de l'énergie. ERDF gère la production et la distribution, puis facture à EDF une location des lignes, et EDF vous facture vous. ERDF est volontairement déficitaire, ce qui permet à EDF d'être artificiellement très bénéficiaire. C'est un peu la même stratégie que pour la SNCF et Réseau Férrés de France: on met l'essentiel des coûts sur une petite boîte qui continue à être subventionnée par l'Etat, donc c'est pas grave si elle est très déficitaire puisque les contribuables paient, et la boîte principale fait du bénéfice puisqu'on lui sous-facture le coût réel de production/entretien et peut être mise en concurrence pour satisfaire les demandes de Bruxelles sur la sacro-sainte concurrence libre).
 - Et donc, je dois faire quoi?
 - On va vous prendre un rendez-vous téléphonique avec un technicien d'ERDF qui établira avec vous un devis sur le prix du changement.
 - Et en attendant?
 - En attendant on arrête la mensualisation, et vous aller re-partir sur un paiement par TIP.
 - Ok, ça me va.
 - Je vous re-passe le conseiller pour qu'il prenne le rendez-vous téléphonique avec vous et qu'il mette en place le paiement par TIP.

[ encore un peu d'attente, et je tombe sur UN AUTRE CONSEILLER!! Bon, il a quand même l'air a peu près au courant de ce que j'attends de lui... On prend le rendez-vous téléphonique avec le technicien pour le lendemain matin]
 - Et puis il faut qu'un technicien passe chez vous relever les chiffres du compteur pour passer en paiement par TIP
 - ... ... ... L'autre peut pas le faire?
 - Non, par contre on fait un geste commercial, on vous facture pas le passage du technicien qui vient relever votre compteur (manquerait plus que ça!)
 - Bon, et donc il va passer quand?
 - Le 25 juin.
 - Ma femme doit accoucher le 18 juin, le 25 on devrait être rentrés, ok.

Le lendemain, je guette l'appel du technicien.
 - Bonjour monsieur, ERDF à l'appareil. Je vous appelle pour un devis de passage de triphasé en monophasé, et un changement de puissance.
 - Oui. Donc combien ça va me coûter?
 - 135 euros.
 - Bon, je suppose que de toutes façons j'ai pas le choix?
 - Pas vraiment non, désolé, c'est forfaitaire.
 - Bon, et donc vous passez quand?
 - 15 juillet.
 - Perdu, je pars en vacances le 11 juillet, je rentre le 30.
 - Ben après j'ai pas de créneau libre avant octobre.
 - WTF?!?
 - Bon, je vais laisser un message aux services techniques pour qu'ils essaient de vous trouver un autre technicien.
 - Merci, c'est gentil.

Le gars poli, sympa, et aussi arrangeant que possible, ça m'a changé des "conseillers" d'EDF.

Un quart d'heure après, nouveau coup de fil:
 - Bonjour monsieur, ERDF à l'appareil. Je vous appelle pour un devis de passage de triphasé en monophasé, et un changement de puissance.
 - Oui, un collègue à vous m'a appelé il y a pas longtemps, il m'a dit que ce serait 135 euros, mais il avait pas de créneau libre avant octobre.
 - Oui, c'est bien ça, j'ai eu un message par le service technique (autrement plus efficace que la hotline, donc). Donc j'ai un créneau le 24 juin.
 - Ma femme doit accoucher le 18, ça devrait aller (c'est notre premier enfant, j'étais naïf). Ok.

Voilà: court, efficace, tout bon.

Intermède: le 18 juin, ma femme est toujours enceinte, et ma fille ne donne pas signe de vouloir pointer le bout de son nez. On passe à l'hosto pour contrôle, tout va bien, revenez le 20 si rien n'est arrivé d'ici là, on fera un déclenchement. Le 20 on va à l'hosto, et ma merveilleuse fille arrive enfin le 22 dans la journée... Le 23 au soir (vers 1h du matin) en rentrant de la maternité, je réalise que le mec est censé passer le lendemain... et meeeeeeeerrrdeeeeuuuuuu!! Bon, il doit passer entre 15h et 19h, y a plus qu'a espérer qu'il sera à l'heure...

Donc le 24, je laisse ma femme et ma fille à la maternité et je regagne mon chez-moi. 15h10, le gars est là (youpi!). Super sympa, on descend à la cave voir le compteur.
Et là première surprise (de la journée): il arrache l'ancien compteur.
 - Mais, heuuuuu... comment dire? Et les chiffres? Parce que j'ai un gars qui doit passer les relever demain?
 - Ah ben non, faut que je change le compteur, donc de toutes façons je fais un relevé sur mon PDA, et ce soir je vide tout ça dans la centrale et ça sera transferé automatiquement...
 - bon, ben le temps que vous bricoliez, je vais appeler la hotline pour leur dire de pas m'envoyer le technicien demain alors (j'aime autant, je pourrais rester à la maternité avec ma femme à la place).

Dont acte. Le gars au téléphone essaye vaguement de me facturer le déplacement, parce que j'appelle moins de 48h à l'avance, je gueule comme un veau (la fatigue aidant, j'étais moins patien qu'à l'habitude), il me facture rien et annule le technicien. Je redescends à la cave.
 - Par contre il passe quand votre électricien?
 - Plaît-il?
 - Ben pour passer votre tableau électrique de triphasé en monophasé? Parce que là vous avez deux tiers de la maison dans le noir et sans électricité...
 - .... je sens comme un genre de grande fatigue là...
 - Vous saviez pas?
 - Non, sinon je ferais pas cette gueule là.
 - Mais vous êtes un peu bricoleur.
 - Un peu. J'ai juste refait toute la maison en gros.
 - Alors c'est facile:faut juste relier ça avec ça et avec ça.
 - Et on pourrait pas le faire maintenant, genre?
 - Ah ben si, ça sera vite fait.
 - Merci bien.

Un quart d'heure après, le gars m'a fait la bricole, je lui offre une bière pour le remercier, il file, je retourne à la maternité, je suis content.

Et je me croyais tiré d'affaire.



15 juillet, je suis en vacances avec ma femme et ma fille chez mes beaux-parents dans le sud, on a fait un re-direction de courrier (au cas où) et là c'est le drame: une lettre d'EDF.
C'est une "Facture rectificative" où ils prennent enfin en compte les chiffres que je leur ai donné. Avec l'intervention du technicien, on reste encore en négatif, donc en bas de la facture, il est marqué qu'ils me doivent 60 euros. Très bien.
Sauf qu'avec la facture, il y a aussi un courrier:
" Vous nous devez toujours 90 euros, vous pouvez aller les payer à n'importe quelle poste avec ce courrier (WTF?) ou par téléphon avec une carte bleue (à 34 centimes la minute, bien sûr). Sinon on va couper."
Mais BORDEL DE BORDEL DE MERDE!

Donc appel:
 - [Premier conseiller que j'obtiens, j'explique mon cas de plus en plus long, mais toujours à 34 centimes la minute]
 - Ah oui, non, je comprends pas, j'ai bien un montant de 60 euros en votre faveur, vous nous devez rien.
 - Mais pourquoi ce courrier alors? C'est quoi cette somme?
 - Aucune idée.
 - ...
 - ... (pas mieux)
 - Passez moi votre supérieur (oui, ça devient une habitude mais bon, hein...)
 
 - Ah oui, alors en fait c'est parce que vous avez bloqué le paiement du prélèvement de juillet.
 - Moi? Non. Et quel prélèvement d'abord?
 - Ben pour votre mensualisation.
 - Celle qui a été arrêtée vous voulez dire?
 - Ben non, elle a pas été arrêtée, mais y a une main levée sur le prélèvement, donc il se fait plus.
 - Y a quoi?
 - Une main levée. Vous avez pas eu un conflit de paiement avec nous?
 - [je re-explique, en détails, j'en ai marre]
 - Ah oui. Alors c'est sans doute nous qui avons fait la main levée en fait.
 - Super. Et maintenant?
 - Ben vous devez aller voir votre banque pour faire supprimer la main levée.
 - JE dois aller voir ma banque pour supprimer une truc que VOUS avez fait?
 - Oui.
 - J'ai autre chose à foutre (oui, quand je m'agace je deviens vulgaire, et moi aussi je peut être laconique dans mes réponses).
 - ...
 - ...
 - Mais comment vous allez payer alors?
 - Payer quoi?
 - Les 90 euros.
 - Que je vous dois pour quelle raison? Vu que j'ai une facture sous les yeux qui me dit que c'est vous qui me devez de l'argent, puisque je vous en ait avancé au mois de juin, malgré mes appels?
 - Ben en fait en juillet vous auriez dû être encore prélevé de 150 euros, moins les 60 qu'on vous devez fin juin suite à la facture rectificative (que je n'ai eu qu'en juillet), donc il reste 90 euros à payer.
 
Et là ça coupe...
Si, si, je vous promets: un clic bien net de fin de communication.
Vaguement en colère, je rappelle, encore un peu d'attente, et j'ai enfin un conseiller
 - Passez moi votre supérieur.
 - C'est impossible monsieur, qu'est-ce que je peux pour vous?
 - Me passer votre supérieur.
 - Je ne peux pas (pourquoi? il est en train de se faire tailler une plume dans son bureau?). Quel est votre problème?
 - Mon problème c'est que j'en ai marre de raconter mon histoire à des conseillers qui ne peuvent rien pour moi. Passer moi votre supérieur.
 - Très bien (et ben voilà, tu vois quand tu veux!).

 [Bien sûr, je n'ai pas le même supérieur que tout à l'heure, mais je m'y attendais un peu, donc je raconte vite fait mon histoire]

 - Oui, il faut que vous alliez à votre banque supprimer la main levée.
 - C'est votre main levée, j'ai autre chose à faire, donc non.
 - Alors on va avoir un problème.
 - Ah bon? Sans blagues? Bougez pas, je vais vous enregistrer, ça me fera une preuve devant le tribunal (oui, là j'étais vraiment très agacé).
[Je gratouille un peu, je fais du bruit... oui, c'était du bluff, mais il avait aucun moyen de le savoir]
 - Voilà. Donc je tiens à vous prévenir qu'à partir de maintenant, cette conversation est enregistrée et qu'elle pourra servir dans un tribunal en cas de conflit entre votre société et moi. Comme il vous arrive régulièrement d'enregistrer les conversations, il n'y a pas de raisons qu'on en fasse pas de même.
 - [silence un peu angoissé du coup]
 - Donc vous me confirmez ce que vous venez de me dire précedemment: votre société a placé une main levée sur mon prélèvement automatique sans raison valable, et je dois maintenant m'occuper des démarches pour la supprimer, faut de quoi je vais me retrouver en situation de non paiement?
 - Heuuuu... non mais attendez, c'est pas la peine de le prendre comme ça, on va trouver un moyen?
 - Ah? Par exemple?
 - On doit pouvoir la faire supprimer nous, cette main levée, puisque c'est nous qui l'avons mise (tiens? c'est marrant avant on aurait dit que c'était pas possible). Je vais consulter notre service paiement et je vous recontacte.
 - D'accord, j'attends votre appel très rapidement.
 - Oui, oui.

Voilà, donc avec des menaces, on commence à se diriger vers quelquechose... c'est sympa de voir à quoi il faut en arriver pour obtenir un résultat que je juge personnellement "normal".

Un bon quart d'heure après, on me rapelle (en numéro caché, comme tout les appels que j'ai eu, y compris les techniciens, malheureusement): c'est le même supérieur que j'ai eu précedemment:
 - C'est bon, la main levée est supprimée, les prélèvements vont recommencer à se faire normalement, et à partir du 15 du mois prochain, vous ne serez prélevé que de 106 euros, pour prendre en compte la différence du prix d'abonnement. Ca vous va? Par contre vérifiez quand même que vous êtes bien prélevé le 15, à tout hasard (ouais, ouais). Et vous devriez recevoir avant la fin de la semaine un courrier récapitulaif qui devrait tout remettre à plat.
 - Très bien, j'ai enregistré vos déclarations (oui, je contiinue mon bluff, puisqu'apparement il n'y a que ça qui marche), j'attends votre courrier et je guette le prélèvement le 15. Et je vous préviens qu'au moindre problème, ça se règlera au tribunal (quitte à perdre du temps, autant que ça serve à quelquechose au bout d'un moment hein).
 - Non, non, ce sera pas la peine.
 - Si, si, s'il y a ENCORE un problème, je vous assure que ce sera la peine et que ça se règlera au tribunal.
 - Non mais il n'y aura pas de problèmes.
 - Je vous le souhaite.
 - Je vous souhaite une très bonne journée monsieur.
 - Et moi je souhaite que vous mettiez de l'ordre dans vos services et que les choses soient simples, mais je sens que nous allons rester frustrés tous les deux.


Depuis j'ai effectivement reçu un courrier signé de la main du responsable du service paiement, où ils se confondent en excuses (en plus de tout "remettre à plat" comme disait l'autre).
Le 15, le prélèvement (de la bonne somme) est passé. Ouf!
Je tiens quand même à faire remarquer:
 - qu'au final, malgré les promesses des uns et les dénégations des autres un particulier ne peut pas passer de la mensualisation avec prélèvement automatique à un paiement standard par TIP sans courrier, mais EDF peut par contre interrompre le paiement en faisant une main levée sur le prélèvement, sans motif, et sans que vous en soyez informé (en tout cas pas tant que vous n'êtes pas encore en défaut de paiement).
 - que tant que je n'ai pas eu sorti l'artillerie lourde (bluff d'enregistrer la conversation avec menace de procès à la clé), le seul à avoir été arrangeant et réellement professionel, c'est le technicien d'ERDF.

Merci à ceux/celles qui ont tout lu!

tags : edf, hotline, sodomie, youpi