La fibre optique avec DartyBox

Ahah, si vous lisez ce post, c’est que la fibre optique vous titille. Vous hésitez, vous recherchez des informations pour sauter le pas. Et vous faites bien de lire cet article.

Alors venons en vite au fait.

Je venais juste de m’installer sur la région de Lille et j’avais choisi Free en ADSL, un bon opérateur qui m’a malheureusement servi du 4 Mbits/s, car je me trouvais en bout de ligne donc avec pas mal de perte. J’avais donc le choix entre surfer sur Internet, regarder la télé en bas débit ou enregistrer une émission. Choix difficile, voire cruel.

J’ai cherché un peu ce que je pouvais faire pour améliorer tout ca, mais un concurrent toujours dans l’ADSL ne m’aurait rien apporté de plus.

Il y avait bien Numéricable, mais avec sa réputation, visiblement toujours de vigueur, je ne voulais pas payer plus pour ne plus rien avoir. Petite anecdote : Je vais dans une boutique Numéricable et j’attends avec 4 clients mécontents devant moi (pas bon) et un vendeur absolument pas motivé, qui donne des renseignements différents de ceux donnés par téléphone. Et pas de décodeur en stock. Ca ne donne vraiment pas envie.

Mais 4Mbits/s, je ne pouvais pas rester sans rien faire. Et en cherchant, j’ai vu que Darty proposait le THD avec sa DartyBox.

Contacter Darty par téléphone

Alors j’appelle Darty un vendredi soir sur un numéro au tarif local, c’est raisonnable. Et là on me dit, faut prendre RDV pour avoir des infos sur les offres DartyBox. Je me dis bizarre, mais pourquoi pas. Alors je donne mon tel et je leur demande de me rappeler le lendemain. Et le lendemain (samedi donc), pas d’appel. Dommage. Bon, motivé, je rappelle et je tombe sur une charmante opératrice du maghreb qui ne comprend pas vraiment pourquoi je devais prendre RDV, mais on ne cherche pas. Je lance donc mon inscription, même si je ne sais pas vraiment quel sera mon débit réel, 30Mb/s ou 100Mb/s. Je me dis que même 30, c’est déjà pas mal. L’inscription se fait assez rapidement avec une confirmation par email. Je dois récupérer ma DartyBox à mon Darty le plus proche le lundi, pas de souci. Et avec résiliation Free automatique, que demande le peuple…?

Récupérer sa DartyBox

Le lundi, je vais à mon magasin et je dis que je viens prendre ma DartyBox. On me regarde avec de gros yeux, comme si c’était la première fois que quelqu’un venait pour prendre ce type de matériel. C’est récent certes, mais quand même.

Je donne donc ma référence et on essaie de chercher mon contrat, mais ca n’a pas l’air de fonctionner comme il faut. Mon vendeur décide donc d’annuler le premier contrat et d’en refaire un. Pourquoi pas, si je peux avoir mon THD. Une heure quand même pour tout faire, plus que par téléphone, mais ce n’est pas grave, je sors avec mes boites et j’ai une date pour l’installation gratos.

L’installation

Le vendredi, donc, pour cause de dispo perso, l’installateur vient et fait son travail, nickel. J’ai donc le THD. Excellent.

Voici maintenant 15 jours que j’ai le THD et je ne regrette pas son choix. Cependant…

Sur le long terme

Je n’ai « que » du 30 Mbits/s, qui avec les différents tests faits sur Internet s’avère plus proche de 15 MBits/s, voire 12MBits/s. C’est bien, mais bien loin de la réalité.

En appelant Darty, on comprend que les débits qui sont vendus ne sont jamais ceux que vous aurez réellement. En effet, 4 à 7 MBits/s sont utilisés pour gérer le réseau (ce qui permet par la même occasion à Darty de suivre votre consommation, quantité de download/upload, connexion…). J’espère quand même que tout n’est pas tracé, mais ca commence à faire peur…

Et surtout on essaie de vous expliquer que vous ne partagez pas vos 30Mbits/s avec vos voisins, mais que si ceux-ci utilisent beaucoup Internet, ca a quand même un impact pour vous. Ah c’est dommage quand même.

Alors quel est mon conseil ?

  • Si vous avez Internet par ADSL et que vous êtes près du DSLAM, soit dans les 16Mbits/s de download, allez sur le site de Numéricable et voyez si la fibre qu’il propose est à 30 ou 100 Mbits/s. Darty utilisant leur réseau, vous saurez à l’avance quel sera le votre. S’il s’agit de 30Mbits, ne passez pas à la fibre, ca ne vous apportera rien sauf si vous n’êtes pas satisfait de votre FAI actuel, bien sur.
  • Si vous êtes loin du DSLAM, avec des réseaux bas, genre 4 à 7 Mbits, jetez-vous sur l’offre Darty (allez sur le site de Numéricable, si vous voulez connaitre votre futur débit).

Quid des autres services ?

  • Pour le téléphone, rien à dire de particulier. Ca marche, c’est de bonne qualité.
  • Pour la télévision, de la HD de bonne qualité, moins de chaines que sur l’ADSL, mais ce ne sont que des chaines que je ne regardais pas de toute facon. Cependant un guide des programmes vraiment très très (très) mal pensé. Et j’insiste sur ce point. L’interface est jolie mais absolument pas pratique, tout le contraire de celle de Free, très moche mais très facile pour surfer d’une chaine à l’autre ou d’une journée à l’autre.

Les faux prix

S’il y a bien un truc qui me fait marrer, mais qui devrait plutôt me faire pleurer, c’est les prix affichés. On vous annonce des tarifs à 29,90€/mois. Sauf que le décodeur est obligatoire à louer tous les mois pour 5 € et le modem est lui aussi obligatoire pour 3 €. Donc de 29,90€/mois on passe à 37,90€/mois. Si c’est pas de la publicité mensongère ca… M’enfin tous les concurrents sont à peu près pareils, c’est de bonne guerre.

Conclusion

Darty est très compétent dans les services, tant le conseil, les contrats, l’installation que le support, un peu moins dans la maitrise de son réseau (qui n’est pas le sien d’ailleurs) et c’est dommage.

Astuce

Si vous arrivez à prouver que votre débit est à 50% de sa valeur vendue, <15MBits/s au lieu de 30MBits/s, alors c’est possible qu’ils interviennent, mais ca reste à prouver. Je vais tenter l’expérience. Qui ne tente rien n’a rien.

😉

Publicités

La qualité est un voyage

pas une destination.

C’est par ces mots que se termine la conférence Qualité du code source et l’intégration continue des collaborateurs de Xebia. Il est bon de rappeler que la qualité ne peut pas être quelque chose qui s’enclenche en un geste, ni même qu’elle se termine.

Au cours de ma carrière, j’ai souvent été surpris par le peu de qualité fournie sur les projets, tant au niveau du code source que de la documentation. Et ne parlons pas des tests ou de l’intégration continue, concepts encore trop souvent inconnus chez certains éditeurs.

Mais instaurer la qualité sur un projet existant ou dans une société n’est pas chose aisée. Xebia le détaille d’ailleurs très bien sur les dernières diapositives de son exposé.

Pour ma part, je dirais que la plus grosse difficulté n’est pas sur la technique, puisque qu’après tout, si d’autres sociétés le font, tout le monde peut le faire, mais sur les individus et la motivation.

En effet, si les participants au changement ne connaissent pas ces pratiques, ils peuvent douter de leurs biens fondés, de la facilité de mise en place, des gains de productivité et qualité et de l’impact direct sur leur travail.

Imaginez, vous demandez à des développeurs, souvent en place depuis plusieurs années de :

  • changer leur façon de développer, cela pourrait laisser penser qu’ils ne savent pas développer,
  • écrire des tests unitaires et d’intégration, ce qui va leur demander plus de temps, et donc faire baisser leur productivité,
  • suivre leur projet sur un serveur d’intégration et corriger toute erreur en priorité si le cas se présente, ce qui signifie que corriger un serveur de build est plus important qu’une fonctionnalité métier,

Il est clair que si l’on évoque ces trois points, la qualité du code source et l’intégration continue ne semblent pas apporter de productivité aux développements, bien au contraire.

Mais lorsqu’on connait les 3 points suivants, les premiers commentaires semblent bien négligeables, face aux avantages accumulés :

  • Un développeur passe 80% de son temps à lire du code et 20% à en écrire, il a donc tout intérêt à avoir un code lisible et rapidement compréhensible, pour diminuer son temps de lecture et augmenter son temps d’écriture,
  • Les tests permettent d’être informé de la moindre régression dans le code et de modifier à loisirs et sans doute du code existant afin de l’améliorer,
  • Le serveur de build informe, en temps quasi-réel, de l’état du projet et des tests pour l’ensemble des acteurs du projet, afin de corriger une erreur au plus tôt et de ne pas attendre d’être en production pour corriger une faille passée au travers des tests métiers,

Pour une société qui ne maitrise aucun des points cités précédemment, les gains de productivité peuvent atteindre 300%, voire plus si le code est réellement catastrophique ou si l’intégration de nouveaux développeurs est importante. Vous me direz alors, 300%, c’est énorme. En fait à y réfléchir, ces 300% ne sont pas très important, c’est principalement la productivité de départ qui est très faible. Car bien souvent, si vous n’avez pas de qualité du source code ou d’intégration continue, vous empilez les bugs, vous multipliez les copier-coller de peur de modifier l’existant, vous passez votre temps à lire et vérifier une implémentation…

Mais rappelez-vous, pour mettre en place les bons process de développements, le plus important n’est pas la technique, c’est l’accompagnement au changement. Soyez sur d’avoir les bonnes personnes pour vous aider.

Le coût d’un copier-coller

Afin de donner un exemple concret de ce qu’il ne faut pas faire et pour vous montrer qu’il vous coûte plus cher de ne pas suivre vos développeurs que de les accompagner jour après jour, voici une histoire plus ou moins récente d’un de mes clients.

L’histoire est au présent pour plus de simplicité.

Mon client a un fournisseur de contenu que nous avons en charge de traiter. Ce contenu est envoyé de manière assez irrégulière mais demande à être traité avec soin. Il s’agit d’un fichier plat type csv classique. Les données sont séparées par un ; et informent sur un produit, des sections et sous-sections et autres codes.

Le processsus, même s’il est manuel, est plutôt bien rodé. Un développeur reçoit le fichier plat, le fait passer dans son programme « fait-maison », intègre les données dans une base de dev et vérifie que ca passe bien. Ensuite 2 ou 3 personnes sont chargées de vérifier l’ensemble des données pendant une petite semaine. Les données validées sont alors transférées dans une base de pré-prod.

Il se trouve qu’un jour,  le fichier change de format, un caractère : a été inséré pour ajouter une information. Le fournisseur prévient le développeur, celui modifie son programme et le relance pour intégrer les données. Une semaine se passe et les testeurs s’aperçoivent qu’une partie des données est corrompue car le caractère : n’a pas été pris en compte.

Nous entamons alors une réunion à 5 personnes, le chef de projet, le développeur, le responsable des données, le développeur SQL et le responsable des bases de données. Après examen des données corrompues, on s’aperçoit qu’un pan entier n’a pas été pris en compte, parce que la modification du programme a été faite sur les 4 premières parties du code, qui sont en fait 4 copier-coller identiques de gestion du format, mais que la 5ème partie n’a pas été modifiée. Dommage.

Coût du copier-coller

  • Une semaine de 2 testeurs, qui vont devoir tout retester,
  • 1 heure de réunion * 5 personnes pour identifier le problème,
  • 1 heure de développeur pour remettre à jour son programme et vérifier que ca tourne cette fois,
  • 4 heures de développeur SQL pour écrire une procédure stockée afin de corriger les données,
  • 1 heure de réunion * 5 personnes pour expliquer ce qui a été fait et vérifier que cela fonctionne correctement.
  • Combien de temps cela aurait-il pris au développeur de réfléchir à son programme afin de factoriser un maximum de code pour ne pas produire ce genre de problème ? 2 ou 3 heures.
  • Pourquoi ne l’a-t’il pas fait? Parce que factoriser demande à réfléchir. Et qu’un développeur suit souvent la devise « Quand ca marche, tu touches pas!« 

Maintenant lors de ces discussions, personne n’a parlé de modifier le programme afin de factoriser le code, ce qui veut dire qu’au prochain changement de format, vous pouvez être sur à 50% que la même erreur va se reproduire.

Imaginez maintenant que le développeur quitte la société, est malade ou en vacances. Quelqu’un va obligatoirement devoir le remplacer dans cette tâche. Le taux d’échec de la transformation va alors monter à 95%.

Si en plus vous ajoutez le fait qu’il est fort probable que le développeur a créé une nouvelle branche de source pour ce format, plutôt que de rajouter un test sur le type de format, le prochain développeur va même tout réécrire pour reproduire les mêmes erreurs.

Elle est pas belle la vie ?!!!

PS : Attention, je n’exagère absolument pas la réalité.

PS2 : Mais où sont les bons développeurs.

PS3 : Un ancien collègue m’a dit un jour que les développeurs sont une espèce à part. Je vais commencer à croire que c’est vrai…

Accompagnez vos développeurs

Depuis quelques temps, je lis beaucoup de documentations sur la gestion de projet avec Scrum, le Lean Development, l’eXtreme Programming et l’agilité. Je suis toujours ravi de voir qu’une des bases de ces concepts est de fournir un produit avec une structure technique de qualité. Qualité de l’architecture, qualité de la documentation, qualité du code.

Mais chaque fois que j’arrive dans une nouvelle entreprise, je suis toujours étonné de la qualité de ce qui a été conçu.

  • On parle d’architecture, mais il n’y a pas d’architecte.
  • On parle de documentation, mais il n’y a pas de document.
  • On parle de logiciels, mais lorsqu’on étudie le code, on voit clairement le concept principal, « je code vite, je code pour que çà marche, le reste (bon code, commentaires, syntaxe généralisée) on verra plus tard (c’est à dire : jamais)« .

Je crois avoir presque tout vu :

  • Des classes avec le nom du développeur, très pratique quand il ne fait que passer sur le projet,
  • Du code très très technique qui marche à moitié, mais dont on ne sait pas grand chose car il n’y a aucun commentaire, aucune doc et puisque le développeur est parti depuis de nombreuses années,
  • Du code de base, mais sans aucun commentaire, aucune règle, aucune organisation,
  • Des méthodes très longues (+ de 2000 lignes),
  • Du code avec plus de codes commentés que de codes exécutés,
  • Des classes avec des méthodes sans paramètres, les membres de classe sont utilisés comme paramètres, imaginez l’enchevêtrement lorsque le code n’est pas exécuté dans le bon sens,
  • Des membres de classes définis par le constructeur mais jamais utilisés, pratique lorsqu’on se dit que la classe pourrait répondre à nos attentes avec un paramètre mais qu’il n’en est rien,
  • Des projets où tous les fichiers (pages web, classes, javascript, images, fichier de properties…) sont à la racine du projet, aucun dossier, super pour rechercher ses fichiers,
  • Des classes avec l’ensemble de toutes les valeurs utilisées éparpillées dans le code, en dur, répétées des dizaines de fois. Vous changez le nom d’une valeur, il faut le changer dans 10 classes différentes, imaginez lorsque vous travaillez sur un fichier xml et que l’ensemble des balises est répété à plusieurs endroits, comprendre le code, le modifier ou le réutiliser sont un vrai bonheur,
  • Des logs en dur avec System.out partout, avec marquez « toto3, « test1 » ou « passe par ici », « passe par là »,
  • Des centaines de lignes de code copier-coller, avec une ou deux lignes qui changent, comme ça, pour corriger les bugs, ce sera le bonheur,
  • Des développeurs qui, pour adapter leur projet à un process particulier, préfèrent créer une nouvelle branche et faire les quelques modifications qui s’imposent, plutôt que de faire fonctionner leur esprit afin d’ajouter un paramètre dans une méthode,

Ce ne sont que quelques extraits, et ils ne sont pas réservés à des développeurs junior, bien au contraire.

La seule société où j’ai pu travailler sur un code de qualité remonte à ma première expérience en Suisse. Certes les Suisses sont connus pour la qualité de leur travail, mais on peut dire qu’ici le code (et le développeur) était traité avec le respect qui lui est du. Règles de développement, commentaires, documentations, process strict, packages, rôles… Débuter dans cette société m’a permis d’intégrer un point essentiel que tout développeur devrait maitriser. Le développement de qualité.

Et lorsque vous croisez un ‘mauvais’ développeur (mauvais dans le sens où il ne respecte pas de standard en développement, commentaires, organisation), vous ne pouvez pas le blâmer. S’il n’a pas été éduqué pour faire du bon code, il faudrait qu’il prenne sur lui afin d’apprendre seul, ce qui n’est jamais facile.

Qui blâmer alors si on ne peut pas blâmer le développeur ?

Facile, son supérieur direct. Le chef d’équipe ou le chef du projet. On entend souvent qu’un chef d’équipe ou un chef de projet informatique n’a pas besoin de connaitre l’informatique pour être un bon chef. Faites moi rire, vous en connaissez beaucoup des chefs IT qui n’ont jamais fait de développements ? Je n’en ai jamais croisé.

Son rôle est certes de gérer l’équipe ou le projet mais il est également de s’assurer de la qualité de ce qui est produit et pas seulement que le produit répond aux attentes ou non. Ce serait un peu trop facile.

Alors oui, c’est long, oui, c’est fastidieux, oui, il faut répéter, insister, vérifier, re-vérifier. Mais si vous voulez des développeurs de qualité, il vous faut fournir un travail de qualité. Si vous ne faites pas ce travail avec vos développeurs en controlant, expliquant pourquoi vous voulez ceci comme ca, et pas autrement, vos développeurs ne seront jamais de bons développeurs et vous aurez des difficultés par la suite à faire avancer votre projet. Prenez le temps maintenant, vous en gagnerez beaucoup plus tard.

Accompagnez vos développeurs !!!

Les 7 règles d’or du développement

En naviguant sur le Web, viadeo en l’occurrence, je suis tombé sur un post de la société OCTO, qui propose un livre blanc concernant 12 règles pour booster votre productivité en java. Curieux par nature, je me suis dit que j’allais devenir encore plus productif que je ne le suis déjà, super.

Ah ah, dommage, en lisant rapidement le document, on s’aperçoit qu’il ne s’agit que des règles élémentaires du développement, même pas java d’ailleurs :

  • Utiliser un IDE, style Eclipse ;
  • Utiliser un gestionnaire de version, style CVS ;
  • Utiliser un bugtracker, style Bugzilla ;

C’est dommage, je pense qu’il y avait matière à donner des conseils plus avisés. Allez, comme je suis un gars investi et impliqué par son travail, ;-), je vous fais part de mes 7 règles d’or, vous me direz ce que vous en pensez.

les_7_regles_d_or_du_developpement_v0.6.7

Le site d’OCTO où trouver leur document : http://www.octo.com/com/com_Java-Productivity-Primer-white-paper-octo.html

Révélez votre talent…!!!

Il y a quelques temps déjà, je faisais part de réflexions à mes collègues sur quelques principes clés du travail. Ces principes sont certes simples dans le concept, mais difficile à appliquer en concret, car demande du travail, mais pas le travail qui est attendu directement.

Ce sont :

  • La rigueur, être rigoureux dans ce qu’on fait,
  • La qualité, fournir un travail de qualité,
  • Les erreurs, apprendre de ses erreurs, les comprendre et ne pas les reproduire,
  • Le comportement, utiliser les 3 premiers principes pour son quotidien,

Et je me demandais, lors de l’édiction de ces principes, ce qui pouvait le réunir. Je connaissais le terme, mais je ne savais pas comment le définir.

Et voilà que récemment, en surfant sur le blog d’un RH particulièrement au fait des valeurs actuelles, je tombe sur les 2 définitions qui fournissent la réponse que j’attendais. C’est donc avec grand plaisir que je vous renvoie sur son site :

Profitez de ces définitions, des principes que j’ai édicté, et réfléchissez à ce que vous pouvez faire, à ce que vous devez faire dans votre métier pour révéler votre talent !!!

Je travaille actuellement avec pas mal de personnes dans mes projets, d’ici et d’ailleurs, et je sais que celles-ci sont pleines de talent. Mes chers collègues, suivez ces principes, lisez ces quelques lignes, utilisez votre talent, vous irez loin.

Pour les autres, car il y en a, je crois qu’on ne peut rien faire, elles ne vont pas dans la bonne direction, peut-être parce qu’elles ne savent pas, surement parce qu’elles ne veulent pas faire l’effort. Ce sera le thème d’une autre news, plus tard.

%d blogueurs aiment cette page :