J’ai décidé de faire un petit texte a contre courant, plutôt que de faire un 546ème article sur HTML5/CSS3 pourquoi ne pas parler des bienfaits de la danse ?

C’est moi qui décide

Quand on danse en couple, c’est l’homme qui décide ! Un peu comme dans la pub carrefour. C’est d’ailleurs l’un des rare endroit où on peut guider, diriger  sans avoir une association de féministe en furie sur le dos.

Pour ceux qui pense que la danse ce n’est pas viril j’ai envie de leur dire “Est-ce que vous pensez que décider pour votre partenaire ce n’est pas viril ?”

J’ai confiance en moi

Vous décidez… c’est bien mais encore faut-il le faire en ayant confiance en vous. En danse tout se décide sur un petit mouvement de main. Une main trop haute, trop basse ou hésitante sur ce que vous comptez faire et c’est le drame !

Votre partenaire doit vous faire confiance et elle ne connait pas la chorégraphie que vous comptez faire. Sachant qu’on a pas le temps de faire un plan avant que la musique commence et que vous n’aurez pas l’occasion de lui en crier “LA JE COMPTE TE FAIRE TOURNER A DROITE”, il va bien falloir lui faire comprendre par quelques mouvements vifs et assurés.

Je m’adapte

Si vous avez au début de vos cours de danse de le faire avec une partenaire très “pro”, vous aurez aussi bien l’occasion de danser avec une petite veille de 68ans raide comme un piquet qui sent un peu la naphtaline ou encore avec une ménagère qui a bien décidée de vous faire comprendre qu’elle veut autant guider que vous.

A chaque partenaire il faudra agir d’une manière différente. Plus directif, souple ou laisser une certaine liberté, il vous faudra très souvent changer de stratégie.

Je ne parle même pas ici des différences morphologiques qui vous demanderont de vous adapter.

J’anticipe

La chorégraphie n’est jamais prévu a l’avance. Nombre de personnes sur la piste de danse, durée de la musique, tempo, style sont autant de paramètres qui font qu’on ne peut pas prévoir une chorégraphie “standard”.

Comme vous avez en charge de “diriger” la danse, il vous faut donc établir un plan en temps réel ! Vous devez déjà guider mais en plus vous devez réfléchir a la prochaine figure que vous comptez faire et voir si cela est possible au vu de la place que vous avez autour de vous.

Je me sociabilise

Pour danser, on est obligé d’être en contact avec des gens. Pour un geek completement associal, c’est un très bon exercice !

Il y a de forte chance que pendant le cours vous deviez changer de partenaire. Et ça c’est bien .

Pour conclure

Décision, confiance, adaptation, anticipation  sont autant de qualités qui sont nécessaires pour bien évoluer dans le monde de l’informatique (pour la sociabilisation ça peut être optionnel dans certain cas ).

Si il vous en manque, vous savez ce qu’il vous reste a faire .

Voici les “réponses” les plus fréquentes.

Pourquoi changer ? ça marche

Pourquoi changer ? C’est une bonne question et elle n’est pas si stupide que ça.

Vous avez déjà vu un ou deux stagiaires qui ont voulus optimiser un code backdoor qui n’est quasiment jamais appelé. Passer de 513ms a 437ms sur un code qui est appelé dans un CRON tout les mois… ça n’a pas forcément un grand intérêt. Mais il faut se poser quelques questions:

• Dois-je modifier ce code souvent ?
• Ce code est-il appelé dans une boucle haptique a 1000Hz ?
• Est-ce que ma fonction ressemble plus a une boite noire qui des fois me retourne des résultats “mystique” ?

Si vous avez répondu “oui” a une seule de ses 3 réponses, OUI ! Il faut changer !

solution: Expliquez que la machine à vapeur ça marche aussi et pourtant…

On avait pas le temps

C’est la vie ! Dans une boite (une vrai comme nous), on nous demande des trucs et on a pas le temps de faire comme à l’univ !

HAHAHAHA, celle là me fait bien rire . On a pas le temps de reviewer un peu son code mais on a la temps de rester 3 jours jusqu’a minuit juste avant la prod ! Là on peut bosser !

Le temps ça se trouve. La plupart des entreprises devrait fixer un créneau horaire pour revoir et remanier le code existant. Le temps passé a faire cela serait largement gagné sur les phases de debugging.

solution: expliquez que ranger sa chambre tout les jours c’est moins chiant que de le faire une fois par an juste avant que maman passe en foutant tout sous le lit.

C’est pour optimiser

Il y a un petit coté “humain” derrière cette excuse. “J’aurais bien voulu mais c’est pas possible”.

Tout d’abord si la personne qui vous dit ça fait autre chose que du C ou C++ vous pouvez directement lui jeter des pierres. On “optimise” pas un code PHP ou Ruby en faisant du code crade. A partir du moment ou on ne sait pas comment l’interpréteur/compilateur fonctionne derrière. Le fait de tout mettre dans une fonction ne vous fait faire que des économies de bout de chandelles.

Le soucis d’optimisation pouvait s’expliquer encore il y a quelques années avec des machines plus lentes mais maintenant les machines sont suffisamment puissante.

Les solutions actuelles pour gérer de gros volumes de données se font surtout par des clustering/cloud car les processeurs ne montent plus en puissance mais en nombre. Il y a de forte chance pour qu’un code “optimiser” à l’ancienne ne puissent pas être réutiliser sur un cloud.

solution: proposez de multi-threadé le code comme ça il sera encore plus performant ;). Les autres dev n’auront plus l’excuse de l’optimisation.

C’est trop compliquer, on peut pas faire autrement !

“Il y a trop de vérification a faire, on a besoin de ces 34 if/else imbriqués”.

Souvent les collègues se cachent derrière l’excuse du “trop compliqué”. C’est vrai que c’est facile. Le code est compliqué a lire on en déduit que ce que le code fait est… compliqué.

Si je pars sur l’exemple du “34 if/else”, on peut se poser la question “si c’est une vérification, ce code ne devrait t’il pas être déporté dans une classe Validator ?”. Sémantiquement, les “34 if/else” sont-il dissociable ?

Un problème infiniment complexe n’est que la somme d’une infinité de problème simple

J’aime me dire que tout problème aussi compliqué soit-il peut être résumé par une somme de problème simple à comprendre.

Partant de ce principe, le code aura surement beaucoup plus de classe et pourra peut être effrayé des personnes de passé d’une classe statique a une douzaine de petite classe mais pour autant le code sera beaucoup plus simple et raisonné.

solution: expliquez qu’un code complexe peut être subdivisé en code plus simple.

Quelques “autres” excuses bidons envoyés par twitter

• cette appli a pas loin de 7 ans, on va pas s’amuser à tout reprendre maintenant !
• mais si, c’est bien codé, toi tu sais !
• w3c c’est pour les low
• je mets pas de commentaire parce que j’ai peur de pas comprendre ce que j’ai voulu dire

N’hésitez pas a en laisser en commentaire

Pourquoi GIT n’est pas magique ?

Certaines personnes pensent que GIT est “magique”. Il permet de merger mieux que SVN c’est donc l’occasion de faire plein de fork ? GIT permet de décentraliser, est-ce une bonne idée de le garder centraliser ? Autant de bonnes questions auquel il est important de répondre.

Comment savoir si vous utilisez mal git ?

• Vous avez plus de 20 branches en cours de développement sur votre serveur GIT
• Votre serveur GIT est centralisé et tout le monde utilise ce même serveur
• Tout le monde a le droit de push
• Aucune personne n’est en charge des merges
• Vous n’avez pas l’habitude de signer.

Si vous vous reconnaissez dans un ou plusieurs de ces choix, il faut revoir votre politique de développement .

TROP de fork TUE le fork.

GIT n’est pas magique et même si il facilite les merges entre les branches il n’est pas “conflict proof”. Certains conflits vont apparaitre c’est obligatoire, et ce n’est pas parce qu’il facilite les merge qu’il faut pour autant ne pas prendre des mesures pour les éviter.

Lorsque l’on décide de développer plusieurs projets en parallèles sur une même base il est bon de définir ce qui va être développé. Il est toujours bon dans une structure d’avoir une personne qui décide des points clés d’un projet et si plusieurs points se rejoignent il faut faire en sorte que les équipes n’effectuent pas le même travail chacun de leur coté ou alors vous risquez irrémédiablement d’avoir des conflits.

Cela peut paraitre “trivial” mais pour autant dans des structures de taille moyenne, il n’y a pas toujours de personnes dédiés à ce genre de coordination. GIT nous oblige ici à avoir un développement discipliné.

Une organisation bien défini

Si vous n’avez qu’un seul serveur GIT pour tout centraliser vous avez fait une grosse erreur. Pourquoi ?

• Si vous avez une équipe ou une personne avec des compétences assez médiocres, comment contrôlerez vous l’intégration de son développement ?
• Quand bien même vous auriez une équipe très compétente, quel est l’intérêt d’avoir tout vos commits centralisé sur un même serveur en permanence ? A part avoir beaucoup trop de branches et beaucoup trop de choses à gérer cela n’est pas très utile. C’est une mauvaise habitude résultant de l’utilisation de SVN

Intéressons nous à  l’organisation du noyau Linux. Si je devais la résumer en une seule phrase de Machiavel “Diviser pour mieux régner”. Si Linus Torvalds a choisit cette organisation ce n’est pas pour rien. C’est un geek et tout bon geek est fainéant.

Il fait confiance à un certains nombre de personnes. Il vérifie de manière ponctuel un certain nombre de patch mais si un patch qu’on lui envoie est signé par 2 ou 3 personnes de confiance il peut l’intégrer sans trop de vérification au noyau Linux.

Dans une entreprise cette attitude serait similaire a un coordinateur qui irait récupérer une branche git définit comme stable et qui ferait une vérification de cette branche avant son intégration. Si ce coordinateur n’a jamais eu de soucis avec le responsable du développement de la branche, il peut juste effectuer des vérifications sommaire mais là nous rentrons plus dans une relation de confiance et dans le relationnel entre les personnes de l’équipe.

Dans une grosse structure on pourrait voir ainsi 1, 2, 3, voir même 4 niveaux de hiérarchie entre le développeur et le “code keeper”. Le plus haut niveau n’a pas a se soucier des problèmes de développement, il a juste a valider la version finale qui sera intégrer dans le GIT. A contrario, le bas niveau n’a pas à se soucier de l’integration, il respecte juste un certain nombre de règles et développe son application.

Et si on pense que cela ne sert à rien ?

Si il n’y a aucune validation on peut se retrouver dans des cas dramatiques.

Un merge farfelus d’une branche en test dans un développement pour ne pas se prendre la tête et faire un raccourcis, des hotfix sur le noyau dans plusieurs branches, aucun suivis des branches upstream ou encore des merges avec une strategy “-s ours” sans vérification. L’intégration d’une branche “MAUDITE” peut devenir un vrai casse tête voir même impossible.

Au hasard les conséquences peuvent être:

• De nombreux conflits
• L’intégration de code “instable” par merge d’une branche déjà mergé avec une autre branche instable
• Rendre le code moins performant.

Bien sûr vous avez pu mettre un certain nombre d’indicateur comme des tests unitaires, des coverages reports mais il faut dans tout les cas avoir une organisation solide.

Cas pratique: la traversée du désert

Prenons un cas pratique que j’ai déjà eu l’occasion de voir. Ce cas j’aime l’appeler “la traversée du désert”.

Prenez un développeur, donnez lui une tâche et laissez le faire son fork. Il revient 3 mois après avec un développement qui a modifié votre noyau de base, qui n’a pas suivis les évolutions de l’upstream et qui soit dit en passant a sûrement réinventé la roue carrée. Résultat ? 3 mois de travail de perdu. Son code peut être considéré comme inutilisable.

L’image de traversée du désert montre bien l’image de ce développeur qui part seul sans radio avec une mission sommairement posé sur un bout de papier. Son chef de projet confiant pense que GIT arrivera comme un grand a merger ce qu’il “dénichera”. Il se trompe, cela ne changera rien.

Si vous deviez retenir que quelques regles ?

With great power comes great responsibility

1. Définissez une organisation.
2. Formez les personnes responsables aux différents enjeux.
3. Instaurez un climat de confiance entre les différents niveaux de votre pyramide.
4. Ne donnez pas des “pouvoirs” à des gens qui ne les maitrisent pas.
5. Définissez des règles pour les modifications de parties communes a tout les projets.

Ces règles pourraient être tout aussi utile pour un développement sous SVN mais le fait de faire des “fork” accentuent ces problèmes car les développeurs peuvent vite être isolé et leurs erreurs peuvent être detecté moins vite et avoir un plus gros impact sur le long terme.

Pour conclure

GIT est un outil puissant avec une grande liberté d’action. Il peut vous apportez beaucoup mais il faut bien comprendre son fonctionnement. Autant pour l’utilisateur néophyte qui fait un fork de Ruby on Rails pour rajouter une fonction, son utilisation est simple; autant pour la gestion de très gros projet, son utilisation peut être contre productive si vous n’avez pas une organisation bien structurée.

Si vous prenez la décision de changer de logiciel de versionning est d’adopter une méthode plus agile, plus souple, retenez bien cela ne se traduit pas que dans les logiciels que vous utilisez mais aussi dans l’utilisation que vous en faite.

Les mentalités sont encore habitués a un système de versioning centralisé avec un impact direct sur le développement. Avec GIT vous entrez dans des méthodes de développement sur le long terme où il faut savoir anticiper les problèmes avant de les laisser germer.

On sent le vécu hein ? . Non bon serieusement, on va essayer de rendre ça “FUN” avec un cocombre et un renard de feux. Déjà on va définir notre vocabulaire.

• Cucumber est un “framework” de test unitaire ou on écrit tout en langage “humain”. Genre “là j’ouvre ma page web et j’epluche des carottes”.
• Watir c’est une bibliothèque pour faire des tests unitaires sur une interface web.

Et si comme Dave Hoover, on combine les 2, ça donne quoi ?

Installation de Cucumber et FireWatir

Simple. Après avoir installé gem (le systeme de packaging de ruby) on tape

gem install cucumber
gem install firewatir

Vous aurez aussi besoin d’un petit plugin firefox disponible ici

En route pour notre premier test.

On nomme les test de cucumber “feature”. La syntaxe d’une feature de cucumber est assez libre mais se base essentiellemet sur 3 mots clé “When”, “Given” et “Then”. On peut assimiler ça a “Hypothèse, developpement et conclusion”.

Ici j’utilise Cucumber en anglais (car les clients que l’on a sont essentiellement anglais) mais il existe une version française de cucumber.

Feature: "lab" section Menu
  In order to ensure that the lab menu
  Verify that the "lab" menu entry exist on lo2k websites

Scenario: Check if "lab" menu exist
  Given I am on website "http://www.lo2k.net"
  Then "lab" is present in the menu

Voici le contenu du fichier “lab.feature”

Si je lance cucumber avec la commande “cucumber lab.feature” j’ai le resultat suivant.

Feature: "lab" section Menu  # features/lab.feature
  In order to ensure that the lab menu
  Verify that the "lab" menu entry exist on lo2k websites
  Scenario: Check if "lab" menu exist           # features/lab.feature:5
    Given I'm on website "http://www.lo2k.net"  # features/lab.feature:6
    Then "lab" is present in the menu           # features/lab.feature:7

1 scenario
2 steps pending (2 with no step definition)

You can use these snippets to implement pending steps which have no step definit
ion:

Given /^I am on website "http:\/\/www\.lo2k\.net"$/ do
end

Then /^"lab" is present in the menu$/ do
end

Sympa, il me definie des templates pour mes “steps”. Comme vous pouvez le voir, les steps sont definis par des expressions regulières. COOL !!! On va donc ecrire nos “steps” dans un repertoire que nous allons nommer “step_definitions”.
Nous allons a l’interieur nous constituer une “bibliotheque” de “step”. Peut importe le nom du fichier ici.

Je définis donc un fichier “bootstrap.rb”

#Include the FireWatir file.
require 'firewatir'

#include the FireWatir Module.
include FireWatir

Before do
	@browser = Firefox.new
end

After do
	@browser.close
end

Puis mes steps.

Given /^I am on website "(.*)"$/ do |url|
	@browser.goto(url)
end

Then /^"(.*)" is present in the menu$/ do |menu|
	@browser.link( :text, 'lab').exists?
end

J’ai profité ici de redefinir avec des parenthèses les elements succeptible de changer.

Bingo, le scenario passe sans aucun soucis

On améliore un peu

Maintenant je peux réecrire mon script comme suit.

Feature: "lab" section Menu
  In order to ensure that the lab menu
  Verify that the "lab" menu entry exist on lo2k websites

Scenario: Check if "lab" menu exist
  Given I am on website "http://www.lo2k.net"
  Then "lab" is present in the menu
  And "timeline" is present in the menu

Et avoir le resultat directement car ayant définis un pattern qui match, il ne me demande même pas de réecrire un bout de code

Feature: "lab" section Menu  # features/lab.feature
  In order to ensure that the lab menu
  Verify that the "lab" menu entry exist on lo2k websites
  Scenario: Check if "lab" menu exist            # features/lab.feature:5
    Given I am on website "http://www.lo2k.net"  # features/step_definitions/step1.rb:27
    Then "lab" is present in the menu            # features/step_definitions/step1.rb:31
    And "timeline" is present in the menu        # features/step_definitions/step1.rb:31

1 scenario
3 steps passed

Et si je veux m’y mettre serieusement ?

Vous remarquerez déjà quelques erreurs dans mon test que j’ai fait précipitement.

• Je fais le test que le lien “existe” pas qu’il est bien situé dans le menu
• Je ne simule pas d’action sur d’autre page.

Vous pouvez facilement mettre des informations dans des champs, simuler des clicks sur des boutons. Voici un exemple de code ci dessous.

When /^with password "(.*)"$/ do |password|
	@browser.text_field(:name,"passw").set(password)
end

Given /^I press the "(.*)" button$/ do |button_name|
	@browser.button(:value,button_name).click
end

Watir est assez exhaustif et montre une flexibilité très interessante qui couvre la plupart des cas, vous n’aurez pas trop de soucis a lui faire ce que vous voulez.

Conclusion

Enfin quelque chose de clair a montrer a votre client et quelque chose d’assez simple a mettre en place.

Quelques idées en vrac que j’ai dans mon cerveau bouillonant:

• Faire un serveur web pour taper vos “features” avec autocompletion basé sur votre bibliothèque de mots clés déjà définis
• Integrer ça a un systeme de builbot pour verifier que les scenarios de votre application marche correctement .

Enfin bref… ya du “potentiel” (et du boulot) .

VITE URGENT ! Notre client “xxx” veut à tout pris une integration avec gloubiboulga maintenant. Cela ne PEUT pas attendre.

Cas de figure avec SVN

Je pense que vous avez déjà tous eu le cas d’un client qui a une demande super urgente.

La gestion de ce genre de cas est très difficile car:

1. L’application doit rester stable.
2. Les developpeurs ne DOIVENT pas gérer plusieurs version à la fois.

Concrètement cela va se résumer à la création d’une branche, sûrement un “branches/gloubiboulga”. Mais voila ! Il doit partir en production mais il n’a pas été testé dans tout les cas car le client sur lequel l’appli va être testé n’utilise pas toutes les fonctionnalités de votre logiciel et dans l’état, IL MARCHE. Il peut partir en production mais en aucun cas ne peut être mergé avec le “trunk”car cela pourrait causer un désastre sur le reste de l’appli. 3 versions se succedent et votre client revient en vous demandant “pourquoi ma version n’évolue plus ?”.

SVN donne de mauvaises habitudes

Si vous êtes un utilisateur de SVN vous devez trouver la gestion de branch assez “utopique”. On a souvent en tête le développeur un peu foufou qui part s’exiler 3 semaines dans un chalet pour faire un fork complet qu’il faudra reintegrer à l’appli. Le reste du temps, tout le monde développe dans “trunk” et trouve cela parfaitement normal. Pour reprendre une phrase que j’ai déjà souvent entendu “ça marche, pourquoi changer ?”.

Et si maintenant je veux une version stable, dans la seconde, je fais comment ?

Le soucis est maintenant, avec cette méthode de développement, si je veux une version stable instantanément je fais comment ? Vous allez me ressortir une vieille version stabilisé il y a 2 mois. Vous êtes sûr qu’elle marche, elle a était testé par 30 personnes de manières intensives pendant 2 semaines. Pourtant à l’heure actuel, vous pourriez peut être faire une version stable sauf que “Roger” doit finaliser un support de fichier quelconque et le soucis c’est que lui aussi travaille dans “trunk”.

Pourquoi on a prit de mauvaises habitudes ?

Tout simplement parce que SVN ne permet pas de faire simplement un merge dans les deux sens.

Si chacun travaille dans une branche dans SVN

1. Les merges peuvent devenir un cauchemard
2. Si Roger commit une amélioration, Patrick n’en beneficiera pas dans sa branche sans faire un merge qui pourrait devenir un casse tête.

Alors je vais vous poser deux questions:

1. Et si “trunk” devenait stable ?
2. Et si tout le monde crée une branche par amélioration à apporter ?

Maintenant on change la méthode de travail

Voici à présent comment sous GIT le développement peut s’articuler. Une branche est crée pour chaque “tache”. Les taches mineures pouvant bien évidemment être dans une même branche.

Il y a 3 principal zones

1. Les branches (en developpement)
2. La branche “Testing”
3. La branche “Stable”

On garantit ici la stabilité par 2 tests.

Le deuxième test est justifié sur de possibles interactions entre taches qui pourraient faire apparaitre des bugs qui ne seraient pas apparu pendant le test du module a la fin de la période de développement.

On se retrouve ici avec une architecture de développement proche des packages debian avec plusieurs niveaux de “stabilité”.

GIT serait-il magique ?

GIT permet une approche de développement totalement différente et permet plus facilement a mon sens de “stabiliser” une version d’une application si on utilise ce type d’architecture. Cependant il y plusieurs autre élément a prendre en compte.

• Une architecture de ce type est inutile pour des petits projects avec juste 2 ou 3 personnes
• GIT est un outil qui propose une grande liberté. Un merge avec par exemple “-s ours” pourrait causer des catastrophes desastreuses, il faut donc avoir conscience de ce que l’on fait.

Pour plus d’info sur git je vous conseille de voir comment fonctionne la fonction “rebase” de GIT et de consulter mais bookmarks associé sur “del.icio.us”
C’est mon premier post “serieux” sur mon blog… donc n’hesitez pas a donner des critiques .