Je suis développeur web freelance et propose des formations à Symfony2 ! Contactez-moi pour en discuter.

La semaine dernière, j’ai eu un problème avec un exécutable, celui de wkhtmltopdf qui n’arrivait pas à générer de PDF et le log n’était pas clair. D’après certaines indications sur StackOverflow, ca pouvait être du à un problème de version de la librairie libjpeg. On peut le vérifier avec strace, c’est un utilitaire qui intercepte et loggue tous les appels systèmes, ce qui permet de voir ce qui se passe en fouillant dans les logs. Je ne connaissais pas cet outil, c’était une bonne occasion de découvrir.

La commande à inspecter est la suivante :

1
$ ./wkhtmltopdf-amd64 in.html out.pdf

On prend un fichier html en entrée, et on chercher à générer à en faire un fichier pdf.

Pour inspecter la trace d’exécution avec strace, on fait comme ça :

1
$ strace -f -o trace.log ./wkhtmltopdf-amd64 in.html out.pdf

L’option -f permet d’enregistrer égalements les appels systèmes des processus fils, -o indique un fichier dans lequel stocker les logs.

On peut ensuite chercher à voir quels sont les appels au chargement de libjpeg.so. On trouve vite ce qu’on cherche :

1
2
$ cat trace.log |grep libjpeg
18590 open("/usr/lib/x86_64-linux-gnu/libjpeg.so.8", O_RDONLY|O_CLOEXEC) = 3

On voit donc que l’exécutable cherche à charger libjpeg dans sa version 8 dans un répertoire particulier. En cherchant les installations de libjpeg ($ locate libjpeg), j’ai pu voir que la version installée sur la machine en question est libjpeg.so.62, ce n’est donc pas la bonne version, un problème résolu avec un

1
apt-get install libjpeg8

. Bref, un problème pas banal mais qui m’a permis d’apprendre plein de choses 🙂

J’ai eu l’occasion de participer à plusieurs projets, le plus souvent de développement. Ils ont eu des durées et des importances variées. Certains se sont cassés la figure d’une manière ou d’une autre, et d’autres se sont très bien passés. Ces expériences m’ont permis de constater quelques unes des caractéristiques de projets qui marchent bien. Cela n’est pas valable que pour du développement, cela marche pour vraiment n’importe quel type de projet.

Quand je parle de réussir, je ne m’intéresse ici qu’à la réalisation technique du projet. C’est mon métier. Ce n’est pas le seul, et souvent d’autre éléments sont en jeu, l’aspect commercial par exemple. en sont un autre et je ne suis pas la bonne personne pour en parler.

Deux manières de procéder

Il y a plusieurs manières de lire cette liste :
  • Lancement d’un projet : elle peut servir de checklist
  • Projet en cours : risquez-vous d’aller dans le mur ? Vous pourrez peut-être corriger le tir.
  • Projet terminé : permet d’en faire une rétrospective, où l’on peut identifier quels éléments du projet étaient fragiles

Caractéristiques clé

Facile à comprendre

Les projets sont souvent rangés dans une application de gestion de projet (cela peut être un simple fichier google doc partagé, ou bien dans Jira, Trello…).

Le titre du projet, ou bien la définition macro du besoin doivent être clairs. Au premier contact avec un projet, ce qui se fait souvent par un titre assez succin, on doit savoir de quoi il retourne.
Si ce n’est pas le cas, c’est en général mauvais signe : « Ce qui se conçoit bien s’énonce clairement ». Si l’initiateur du projet ne fait pas l’effort de présenter son projet clairement ou si le projet est flou car le projet lui même n’est pas encore abouti, il risque d’y avoir des problèmes de communication rapidement.

Le périmètre fonctionnel est clair

Il ne doit pas y avoir d’ambiguïté sur ce qui doit être réalisé. Cela peut être lié au problème précédent (préférer « Concevoir l’interface de gestion des messages privés entre utilisateurs » à « Outils de discussions interne »).

Lorsque le titre ne suffit pas à préciser ce qui doit être fait, il faut aller plus loin : texte de description, maquettes, documents de spécification… Tout dépend du projet et de l’autonomie dont dispose (en théorie, et surtout en réalité) l’équipe.

Les actions à réaliser sont listées de manière exhaustives et précise

Avant de commencer à faire quoi que ce soit, on doit savoir ce qu’il faut faire; c’est un travail collaboratif ! Seul, on a vite fait d’oublier une tâche qui va s’avérer importante par la suite, en minorer le temps nécessaire ou l’importance. Tous les acteurs du projet doivent contribuer à lister ce qui doit être fait, et réfléchir à leur faisabilité.

Certaines actions ne seront pas forcément réalisables immédiatement (ex: la migration d’un module dans un nouveau framework nécessite la refonte du modèle de base de données). Il faut trouver des solutions (ex: bridge temporaire avec l’ancien modèle, et initiation d’un projet plus globale de refonte du modèle).

Cette étape est cruciale car on a vite fait d’omettre des éléments clés qui peuvent remettre en cause le temps effectif de réalisation, ainsi que les choix techniques mis en places.

Les livrables sont définis précisément

Livrer un site responsive, ce n’est pas la même chose que livrer un site ET une application mobile. Cela peut sembler évident, mais ca ne l’est pas. Penser à lever les ambiguïtés et les non-dits sur ce qu’il faut rendre en fin de projet.

Les experts et les ressources matérielles sont accessibles

Dans n’importe quel projet on a besoin d’avoir accès à des personnes et des ressources. Les personnes vont par exemple avoir une expertise métier nécessaire à la conception du produit (ou plutôt à l’avant projet, ce qui peut être considéré comme un projet en soit).

Les ressources matérielles nécessaires doivent également être fournies ou disponibles. Cela peut être :

  • Les accès aux différents serveurs nécessaires (base de donnée, accès SSH)
  • Les licences nécessaires (IDE, applicatifs, outils SaaS…)
  • Les applicatifs sont correctement configurés. Si ce n’est pas le cas, on doit avoir la possibilité de le faire. Le temps nécessaire devra alors être anticipé et alloué pour cela

Quoi qu’il en soit, il faut savoir à l’avance de quoi on aurait besoin et pouvoir y avoir accès lorsque c’est nécessaire.

Une date butoire réaliste

Ha, les estimations… On ne va pas se mentir, les estimations, c’est de la magie noire et personne ne peut prédire précisément le temps que va prendre la réalisation d’un projet.

C’est pourtant un indicateur clé qu’il ne faut pas négliger. Elle doit être réaliste : si on laisse 15 jours pour faire quelque chose qui prend de toute évidence 2 mois, on va dans le mur en niant l’évidence (c’est plus courant qu’on ne le croit).
La pertinence d’une date butoire est difficile à évaluer a priori, mais on peut mesurer sa dérive en cours de projet. A mi-projet, on peut tenter d’estimer si on est encore dans les clous ou si on est déjà foutus. Si on a de l’avance (c’est plus rare que l’inverse), en profiter pour améliorer la qualité.

Découper en milestones

Si le projet est long, il peut devenir pertinent de le découper à l’aide de milestones, des dates clés auxquelles on va vérifier un certain nombre de choses (livrables intermédiaires). On peut alors considérer chaque milestone comme un sous projet, qui doit alors avoir les mêmes caractéristiques que le reste (date butoire réaliste, livrables précisément définis, etc.)

Pas d’interruptions

Nous, les humains, sommes très mauvais pour faire deux choses à la fois. Quand on travaille sur un projet, c’est mieux de se concentrer sur celui ci plutôt que d’essayer d’en développer plusieurs à la fois. Passer d’une tâche à l’autre est une catastrophe pour la concentration. Quand on est sur un projet, cela veut dire, autant que possible : pas de debug d’un autre projet, pas de R&D en parallèle du projet…

Cela n’empêche pas de le faire, et c’est d’ailleurs ce qui arrive assez souvent. Dans ce cas, le temps nécessaire à la réalisation des diverses tâches et projets doit être clairement défini et alloué dans ce sens.

Eviter de changement

Les caractéristiques décrites ici s’insèrent très bien dans une méthodologie agile, qui prône une réactivité presque totale au changement. D’une itération à l’autre, ce qui est conçu peut être jeté pour faire complètement autre chose que ce qui était prévu au départ. C’est une bonne chose (pas forcément toujours bonne à entendre pour le développeur qui conçoit l’application, certes), car elle permet d’assurer que le produit réalisé est bien le bon.

Par contre, il faut un peu de rigueur pour utiliser cette méthodologie correctement, et ne pas interrompre ou altérer un sprint à tout bout de champ. Ajouter de nouvelles tâches, ou modifier les tâches existantes est le meilleur moyen d’aller dans le mur en croyant bien faire. Rapidement, cela peut réduire à néant tout ce qui a été précieusement préparé (périmètre fonctionnel, livrables attendus, date butoire qui devient difficile à respecter, etc.), tout en faisant baisser la qualité du résultat ainsi que la motivation des parties prenantes.

Tout est communication

Finalement, toutes ces remarques gravitent autour de la problématique de la communication. N’importe qui devrait pouvoir comprendre les caractéristiques du projet, et en comprendre les tenants et aboutissants. Il ne doit pas y avoir de non-dits, ou d’idées tacites qui ne soient pas exprimées, explicitées, clarifiées, couchées sur papier.

Ce qui est clair pour quelqu’un ne l’est souvent pour plusieurs personnes que quand elles en ont discuté et se sont mises d’accord à grand coup de schéma. Noter le résultat permet d’y revenir plus tard.

Vous constaterez probablement qu’il n’y a rien de fou dans cette liste et probablement pas d’idée nouvelle. Comme souvent en management ou en gestion de projet, il est question de bon sens. Bien que tout le monde croit en avoir, trop souvent les les projets en manquent d’une manière ou d’une autre. La clé d’un projet qui démarre bien, c’est finalement la rigueur avec laquelle il est décrit.

Gérer les cases à cocher avec angularJS est un peu plus compliqué que les autres associations. On ne peut pas simplement utiliser ng-model, il faut gérer la possibilité que plusieurs cases soient cochées et cela nécessite d’implémenter cette logique métier.

Nous allons voir comment le faire à la main, puis à l’aide de la directive checklist-model.

Gérer la checkbox « à la main »

Le moyen le plus simple, c’est d’avoir un tableau des différentes possibilités, de boucler dessus. Pour chaque case à cocher, lors d’un clic on va déclencher une action de contrôleur. On va également tester si la case est cochée ou non via une autre action de contrôleur.

1
2
3
4
5
6
7
8
9
10
11
<ul class="checkboxes">
    <li ng-repeat="(key, text) in availableTypes">
        <label>
            <input type="checkbox"
               name="filterType"
               ng-click="toggleTypeSelection({{ key }})"
               ng-checked="isTypeChecked({{ key }})">
                {{ text }}
        </label>
    </li>
</ul>

Il faut donc dans le contrôleur plusieurs choses :

  • Une liste des différentes possibilités (availableTypes)
  • La propriété qui va stocker le modèle (types)
  • Une méthode pour dire si une case est cochée ou non (isTypeChecked)
  • Une méthode pour cocher les cases (toggleTypeSelection)

Le javascript associé contient donc ces quatres choses :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
$scope.types = [];

$scope.availableTypes = {
    'apple': 'Pomme',
    'peach': 'Peche',
    'pear':  'Poire'
}

// Dit si une case est cochée
// en testant si le tableau types contient la propriété testée.
$scope.isTypeChecked = function(typeName){
    return $scope.types.indexOf(typeName) > -1;
}

// Coche ou décoche une case
// en ajoutant ou supprimant une propriété du tableau types
$scope.toggleTypeSelection = function(typeName){
    if ($scope.isTypeChecked(typeName)) {
        var index = $scope.types.indexOf(typeName);
        $scope.types.splice(index, 1);
    }
    else {
      $scope.types.push(typeName);
    }
}

Factorisation grâce à checklist-model

En fait, on se rend assez vite compte que les deux actions de contrôleur sont toujours les mêmes. Pour éviter de devoir la réécrire à chaque fois, on peut donc les factoriser, dans une directive ou un service. Plutôt que de le faire soi-même, il existe une directive, checklist-model qui fait cela.

Le code HTML fait la même taille, mais la philosophie est différente. checklist-model devient l’équivalent du classique ng-model, et checklist-value va devenir la propriété à ajouter au tableau types lorsque la case est cochée ou non. La directive peut également savoir si une case est cochée, en testant si le tableau du modèle contient cette propriété.

1
2
3
4
5
6
7
8
9
10
<ul class="checkboxes">
    <li ng-repeat="(key, text) in availableTypes">
        <label>
            <input type="checkbox"
               checklist-model="types"
               checklist-value="key">
                {{ text }}
        </label>
    </li>
</ul>

Le contrôleurs devient beaucoup plus simple. Il n’y a plus besoin d’implémenter les logique d’actions au clic, et pour tester si une case est cochée, c’est géré par la directive. Il suffit de déclarer les différents tableaux :

1
2
3
4
5
6
7
$scope.types = [];

$scope.availableTypes = {
    'apple': 'Pomme',
    'peach': 'Peche',
    'pear':  'Poire'
}

Il est facile d’ajouter des fichiers invalides dans un système de contrôle de version si on ne fait pas attention. Un des moyens d’éviter ça, c’est d’utiliser les hooks de git.

On peut « s’accrocher » à un événement, et exécuter du code à ce moment. Git permet de le faire à peu près n’importe quand : avant un commit, avant un push, après un checkout… La liste complète des possibilités est dans la doc.
Pour cela, il suffit d’ajouter un script shell dans le répertoire .git/hooks d’un dépôt git. On peut d’ailleurs y trouver quelques exemples (inactifs, il faut les renommer pour les « activer »).

Pour éviter de soumettre des fichiers à la syntaxe invalide, on peut donc écrire un hook pre-commit en creant le fichier pre-commit dans ce répertoire. Ce script s’exécutera avant que le commit soit réalisé lorsque l’on exécute la commande commit.

Voici son code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#!/bin/sh
# On récupère la liste des fichiers modifiés
modifiedFiles=`git diff --cached --name-only --diff-filter=ACM`;
error=false;

for file in $modifiedFiles; do
# On vérifie la syntaxe des fichiers PHP avec php -l
   if [[ $file =~ .*\.php ]]; then
      result=`php -l $file 2>&1`;
      if [[ $result =~ .*'Parse error'.* ]];
      then
         echo $file;
         echo $result;
         error=true;
      fi;
   fi;
done

if [ $error != false ]; then
   # En cas d'erreur on empêche le commit
   echo "Erreur de syntaxe dans l'un des fichiers";
   exit 1;
fi;

Le code est simple et commenté, le comprendre ne devrait pas poser de problème (l’écrire a demandé quelques coups de main à google ceci-dit. bash, quelle galère…). La vérification de syntaxe se fait avec php -l, le linter de PHP, en parsant le texte de sortie car il n’y a pas de code de retour qui permette de déduire une erreur de syntaxe. En cas d’erreur, on interrompt le commit et on affiche les fichiers à corriger. Simple et efficace.

On pourrait bien sûr faire d’autre vérifications : validation de la syntaxe des fichiers JavaScript avec jslint, assurer le bon respect des règles de codage avec PHPCS

Plus d’informations sur les hooks dans la documentation.

Un des problèmes majeurs de l’entreprise, c’est l’engagement de ses employés. Souvent, dans une entreprise, les gens sont motivés lorsqu’ils prennent un poste, mais rapidement de nombreuses contraintes et barrières les empêchent de mettre en oeuvre les bonnes idées qu’ils peuvent avoir. Rapidement, ils finissent alors par faire comme tout le monde, « faire leurs heures » et attendre de rentrer chez eux pour commencer leur vie.

Une entreprise libérée cherche à résoudre ce problème (et de nombreux autres, comme nous le verrons). C’est une entreprise dans laquelle les employés mettent en place tout ce qu’ils trouvent favorable au développement de l’entreprise, sans procédures asphyxiantes.

Entreprise libérée

L’introduction a présenté quelque chose d’assez flou, voici quelques précisions. Le reste de l’article a pour but de préciser les motivations et l’état d’esprit d’une entreprise de ce genre.

Une entreprise libérée, c’est une entreprise qui a un certain nombre de croyances.

  • Elle pense que l’Homme est naturellement bon, que les gens sont des gens biens, qu’ils ont envie de bien faire et qu’ils font de leur mieux
  • Elle est convaincue que l’intelligence collective, c’est quelque chose de très fort
  • Elle sait que le patron de l’entreprise est la première personne qui doit changer pour que l’aventure fonctionne

Chronoflex ?

Début janvier, nous avons rencontré Alexandre, dirigeant de Chronoflex. Ils font du dépannage sur site de flexibles hydrauliques, 24h/24, 7j/7. Ca a pas l’air super sexy et pourtant, ce qu’il nous a présenté est à des années lumières de ce que l’on aurait pu imaginer d’une entreprise de ce genre. Il a parlé de son entreprise, sans langue de bois, en nous présentant ce qui marchait et ce qui ne marchait pas.

Créée en 1995, la vision initiale de l’entreprise fonctionne de 1995 à 2009. Pendant cette période, l’entreprise est en forte croissance (parfois, à 3 chiffres). C’est une boite jeune, où il fait bon vivre et où on s’amuse bien. En grossissant, elle finit par se structurer, comme partout ailleurs.
La croissance se fait pendant 10 ans. Avant, pas de recherche de rentabilité. Elle arrive à faire 22 millions d’euros de chiffre d’affaire, avec 250 personnes.

En 2009, la crise les frappe de plein fouet. Ils font -34% de chiffre d’affaire. Cette entreprise qui gère bien une période de forte croissance n’est pas faite pour encaisser une période de décroissance.

Deux rencontres, à quelques années d’intervalle, vont amener l’entreprise à se redresser.
La première, c’est de rencontrer le dirigeant de l’entreprise Favi, lors d’une conférence. Jean François Zobrist fait depuis des années des conférences où il incite les entreprises à dé-hiérarchiser, et à supprimer le contrôle et le remplacer par la confiance. C’est un personnage à la forte personnalité qui va lui faire prendre conscience qu’il faut changer des choses dans son fonctionnement.

Alexandre constate qu’il a fait deux erreurs :

  • La première, c’est de gérer l’entreprise pour les 3%. Mettre en place plein de règles qui gênent la majorité des gens, à cause d’une minorité, les 3%. Ces murs invisibles empêchent les 97% de gens qui cherchent à faire de bonnes choses.
  • La seconde, c’est d’avoir confié la prise de décision à des dirigeants. Les gens les plus compétents pour savoir ce qui est bon de faire sont souvent ceux qui font le travail, et se priver du savoir collectif c’est souvent se priver de la première richesse de l’entreprise : ses employés.

3 chantiers

Pour changer, ils ont silloné la France, armés de Post-it. Partout, ils ont discuté, échangé avec les différentes structures afin de reconstruire la vision de l’entreprise et les valeurs qu’elle porte. Il s’agit de définir, d’expliciter deux choses :

  • Quel est le but du jeu ? C’est à dire, à quoi sert l’entreprise ?
  • Quelles en sont les règles ? C’est à dire, comment on fait ça ?

Les visions et valeurs

Une des premières questions pour laquelle ils ont cherché à trouver une réponse, c’est de définir, d’expliciter la vision et les valeurs de l’entreprise.
Ils ont trouvé quatre éléments de réponses :

  • Atteindre la performance par le bonheur
  • L’amour du client
  • Des équipes respectueuses et responsables
  • Un esprit d’ouverture et une ouverture d’esprit

Les irritants

Vous avez déjà essayé de marcher avec un caillou dans la chaussure ? On peut s’y habituer, mais c’est super pénible.
C’est pourtant ce qui arrive rapidement. Un ordinateur qui ne marche pas, du manque de matériel, des incidents récurrents, des procédures compliquées…

Un grand nombre de détails sont finalement des problèmes irritants qui deviennent parfois obsédants. En enlevant les cailloux, l’entreprise a permis à ses employés de se concentrer sur leur travail.

On a par exemple permit aux employés de faire du télétravail. Les études sur le sujet constatent qu’un employé en télétravail travaille 13% de moins en durée, mais est 22% plus productif. Il faut de tout pour arriver à un équilibre, mais permettre le télétravail lorsque l’employé le souhaite (pour ne pas poser une après midi pour en rendez-vous médical) ne doit pas être négligé.

Attention, n’abandonnez pas le travail sur site, en groupe. Il permet, lui, de stimuler les idées et la motivation. Si l’on prend l’exemple de qui veut gagner des millions, une étude a montré que l’appel à un ami gagne dans 64% des cas, alors que l’avis du public est bon dans 80% des cas. Ensemble, on ne gagne pas tout le temps, mais on gagne plus souvent que seul.
Il y a ainsi plus d’efficacités dans le collectif que dans quelques esprits aiguisés, ce qui peut être résumé par cette phrase : « Seul, on va plus vite, ensemble, on va plus loin ».

Les signes du pouvoir

Sans forcément faire attention, un certain nombre de choses étaient devenus des signes de pouvoir :

  • Les dirigeants ont des grands bureaux, plus grands que les autres
  • Le patron, bien qu’il n’avait pas de place attitré, avait toujours la place la plus proche de l’entrée. Au départ, c’est parce qu’il arrive plus tot que tout le monde, mais quand il part en visites, « sa » place est toujours libre
  • Les réunions secrètes du Codir. Il ne s’y passe rien de secret, et pourtant cela se passe en huis clos, sans que personne ne sache jamais se qui s’y dit.
  • Internet était bloqué pour les employés, afin qu’ils n’aillent pas sur Internet pour leur usage personnel. La solution mise en place bloquait tellement de choses qu’il était impossible de réserver un billet de train. On a donc désactivé ce bloquage pour les dirigeants.
  • Les postes à responsabilité : Directeur marketing, Directeur financier, etc.

Afin d’arrêter de donner l’image selon laquelle les dirigeants détiennent plus la vérité que quelqu’un d’autre, ils ont changé un certain nombre de choses. Par exemple, les réunions du Codir sont devenues ouvertes à tous, ceux qui étaient dans les locaux pouvaient y venir. C’était déjà le cas avant, en fait : mais comme personne n’avait expliqué qu’on pouvait y venir, les gens étaient persuadés que c’était une réunion fermée. Le dirigeant a également arrêté de mettre un costume, et a arrêté de se garer devant l’entrée, pour montrer que la place qu’il occupait le plus souvent ne lui est pas attitrée.

En ce qui concerne à Internet, oles bloquages ont été supprimés. Oui les gens utilisent Internet pour leur usage personnel, mais le principe d’avoir confiance en ses employés, c’est d’accepter l’idée qu’ils soient capables d’en faire une utilisation raisonnée.

Quand aux postes à responsabilité, comme directeur marketing, ces postes ont deux composantes, une expertise opérationnelle et une composante décisionnaire. Ils ont supprimé le titre, gardé l’expertise opérationnelle et donné aux équipes la prise de décision (cela n’a pas toujours été bien vécu mais de l’accompagnement au changement a été proposé).

Liberté & compagnie

La seconde rencontre clé, c’est la lecture du livre Liberté et Cie. Cette étude analyse le fonctionnement classique des entreprises, et étudie surtout des entreprises qui ont choisi des fonctionnements alternatifs.

Ce livre propose une sorte de recette pour libérer l’entreprise :

  • Ecouter ses collaborateurs. Cela commence par arrêter de parler, soi, et d’écouter, sans filtrer, ni influencer.
  • Partager sa vision. La vision est essentielle à l’entreprise, il faut la répéter. Mais il faut le faire après avoir vraiment écouté les collaborateurs.
  • Arrêter d’essayer de motiver les collaborateurs. Le management par l’incentive, avec des primes, des salaires variables sur objectifs individuels… plus globalement, le système du baton et de la carotte ne marche pas. Ca ne motive pas les gens, ça ne sert à rien, du moins pas suffisament. Le livre suggère donc de trouver d’autres moyens d’être performants : L’homme est programmé pour 2 choses, le plaisir et la maîtrise. Pour que le collaborateur soit performant, l’entreprise doit lui construire un environnement dans lequel son travail n’en semble pas, et où il a le contrôle de ce qu’il se passe.
  • Le triptyque de l’engagement :
    1. Supprimer les signes de pouvoir
    2. Créer un environnement nourricier, qui va permettre aux gens de monter en compétences
    3. Laisser place à l’action en donnant de l’espace aux employés pour qu’il puisse faire ce qu’ils considèrent être bon pour l’entreprise.

Le but, c’est d’atteindre un vrai management participatif. Souvent, le management participatif classique consiste à demander aux gens leur avis, mais en ayant déjà plus ou moins le sien à l’avance, et ne pas modifier ses idées en fonction de celles des autres.

Le vrai management participatif se fait en deux temps :

  • Partager tout ce que les dirigeants connaissent sur un sujet, fournir tous les éléments de réflexion qu’on possède aux employés
  • les laisser décider

Une étape essentielle, c’est le coaching, l’accompagnement.
La première personne qui doit changer sa vision, c’est le dirigeant. Elle doit se faire coacher.
Ensuite, les équipes, si elles souhaitent se remettre en question, doivent pouvoir se faire accompagner.

Le saut en parachute

Les premières étapes de ce chantier ont eu lieu de manière sous marine. Il n’y avait pas encore de communication globale sur ce changement, pour pouvoir revenir en arrière si cela n’était pas une bonne solution.

Pendant 18 mois, des actions ont eu lieu mais il n’y a pas eu d’annonce. Les dirigeants et des équipes ont travailllé avec un coach pour désapprendre les croyances et travailler sur lui/elle. Beaucoup de lectures / coachs (Favi et Liberté & Cie).

Le saut en parachute, c’est le moment où il y a cette communication globale, après que l’on ai décidé que c’est la voie à suivre.
Saut en parachute, car comme ce sport, c’est un acte irréversible. Une fois qu’on a sauté, il n’est plus question de remonter dans l’avion.

Ils ont donc fait une réunion clé, où a participé toute l’entreprise. Ils ont décidé, en quelques heures, de transformer ce qui était devenu un porte avion lourd a manoeuvrer, en plusieurs speed boat, plus rapides et maniables.

  • Où ? Les employés ont décidé de l’emplacement des 13 succursales
  • Qui dirige ? Les employés, à nouveau, ont coopté leurs leaders, les dirigeants de ces succursales, pour des mandats de trois ans.

C’était super : en l’espace d’1h30 ils avaient redéfini l’entreprise. Humainement, quelque chose de fort était en train de se passer.

Pourtant, ils se sont cassés la figure assez rapidement.

Ils ont mis en place seulement deux points du triptyque de l’engagement (supprimer les signes de pouvoir et donner les moyens aux employés), mais il en manquait un. Sans avoir créé d’environnement nourricier, sans avoir formé les gens, ils n’ont pas réussi leurs premières missions. Ils ne sont pas à blâmer, ils n’étaient pas équipés pour.

Au moment de la libération, on passe d’un structure où aucune information n’est accessible à une structure où tout est accessible. C’est difficile à gérer pour beaucoup, il faut de l’accompagnement et du coaching.

Finalement, ce changement est un changement de différents types de logiques.

  • Au lieu de dire aux gens ce qu’ils doivent faire, on passe à une logique de volontariat.
  • Au lieu d’être dans une logique de contrôle, on est dans une logique d’autocontrôle. Il y a une différence, que ce soit dans les faits ou dans la perception, entre le flicage et l’auto évaluation.
  • Rentrer dans une logique de culture de l’erreur.

En poussant un peu plus, au moment du saut en parachute ils ont constaté 4 types de comportements :

  • les papillons : certains des employés ont tout de suite été à l’aise
  • les paumés : la plupart des gens. Ils ne savent pas ce qu’ils peuvent faire et ne pas faire
  • les attentistes : ceux qui attendent de voir qui va gagner, l’ancien système ou le nouveau ? Ils prendront position en fonction du résultat.
  • Les chefaillons : des personnes qui ont besoin de pouvoir, et qui ne se retrouvent pas dans la nouvelle organisation

Accepter de mettre en place une culture de l’erreur

Ils se sont plantés ? Tant pis.

En France, on aime pas l’erreur. C’est très culturel. On peut prendre l’exemple des dictées à l’école, où chaque mot érronnée est entouré d’un rouge accusateur. On ne parle pas de tous les autres mots qui sont justes. On ne voit que l’erreur, et il ne faut pas se tromper, c’est mal.
On pénalise donc l’erreur au lieu de la valoriser.

Pourtant, ne pas avoir peur de l’erreur est essentiel dans une entreprise.

Quand on se plante, c’est qu’on a osé. Si on tape sur les doigts de quelqu’un qui se plante, il se plantera une fois ou deux mais pas 50. C’est un problème ! L’employé va finir par ne plus oser. Et si on n’ose pas, l’entreprise ne se développera pas.

le travail du dirigeant

  • Communiquer sur les valeurs de l’entreprise au quotidien, « remettre l’église au centre du village »
  • Créer un environnement nourricier, ce qui se fait de plusieurs manières :
    • vis mon job : passer sa journée d’anniversaire dans un autre service
    • UP, université permanente, propose des cours pour le développement personnel (cours de langues, excel…). Se fait entre midi et deux ou le soir.
    • module découverte, pour apprendre des sujets divers sans forcément de lien avec l’entreprise. les locaux et les ressources de l’entreprise sont mis à disposition, elle paye les repas.
  • Gardien du temple. Quand la vision dérive, il la recentre sur ses valeurs

Bref

Cet article contient de nombreux mots clés mais ne donne pas vraiment de clés à mettre en oeuvre directement. En fait, on retrouve de nombreux ingrédients des recettes de Zobrist et de « Liberté et compagnie » dans de nombreuses entreprises libérées. Les détails concrets de leur implémentation sont à voir au cas par cas.

Un des éléments à garder à l’esprit, c’est de ne pas négliger l’importance de responsabiliser les employés, pas juste créer un contexte dans lequel ils sont libres.
La liberté sans la responsabilité, c’est l’anarchie. Au contraire, la liberté avec la responsabilité entraîne le bonheur et la performance.

Il ne faut pas remplacer le contrôle par l’absence de contrôle, mais remplacer les outils contrôlant et structurants par d’autres outils. L’autoévaluation est l’un d’entre eux.

Et quel que soient les processus que l’on crée, ne pas négliger de les remettre en cause régulièrement.

Il y a quelques temps, j’ai du filmer un écran pendant un long moment, plusieurs heures; comme il n’allait rien s’y passer pendant la majeure partie du temps, utiliser une application qui allait prendre plusieurs images par seconde n’était pas envisageable, car le fichier de sortie aurait rapidement atteint une taille trop grosse. De plus, j’avais juste besoin de voir en gros les moments où il y aurait de l’activité donc je n’avais pas besoin d’une telle précision. Une précision de l’ordre de la seconde suffisait largement.

J’ai donc opté pour un script shell, qui faisait une capture d’image par seconde, que j’ai ensuite assemblée, à une vitesse supérieure (plusieurs images par secondes). On appelle ce genre de vidéo un timelapse.

Divers articles m’ont aidé, mais c’est finalement celui-ci que j’ai mis en oeuvre car il est simple. Le processus est assez facile à reproduire sur une Ubuntu.

On commence récupérer les deux packages que l’on va utiliser, pour faire les captures puis l’assemblage :

1
$ apt-get install scrot mplayer

Pour faire les captures d’écran, on écrit le script shell suivant, qu’on lance et qu’on laisse tourner :

1
2
#!/bin/sh
while [ 1 ]; do scrot -q 100 $(date +%Y%m%d%H%M%S).jpg; sleep 1; done

Ce script prend une capture toute les secondes, et sauvegarde dans un fichier JPEG dont le nom correspond à la date formattée.

Une fois la capture terminée, on arrête le script et on liste les fichiers images dans un fichier, du plus récent au plus ancien :

1
$ ls -1tr *.jpg > files.txt

C’est l’occasion de découvrir de nouveaux paramètres pour ls !

    -1 permet d’avoir un nom de fichier par ligne (attention, c’est le chiffre « un », pas la lettre « l »)
    -t trie les fichiers par date de modification
    -r inverse l’ordre des fichiers

On assemble enfin les images avec mencoder, à raison de 20 images par secondes. Vous pouvez ou non ajouter un fichier mp3 directement pendant l’assemblage :

1
$ mencoder -ovc x264 -oac mp3lame -audiofile basket_case.mp3 -mf w=1400:h=900:fps=20:type=jpg 'mf://@files.txt' -o screenlapse.avi

Et voila. Prochaine utilisation de ce script lors de ma participation à une future Ludum Dare, peut être la 32ème ? Les timelapse de participants y sont monnaie courante.

Nous sommes aujourd’hui le premier décembre. Comme tous les ans, c’est le premier jour des calendriers de l’avent. Sur le web, de nombreux calendriers virtuels en profitent pour parler du web sur un principe simple : un jour = un article. Les articles sont généralement écrits par des auteurs de tous bord, et c’est l’occasion de découvrir de nombreux sujets.

Voici une petite liste des calendriers que je connais, et qui parlent de développement web, de prêt ou de loin :

24joursdeweb est le seul que je connaisse. Il parle du web en général, pas d’une techno en particulier. Tous les sujets sont abordés : développement, intégration, UX, accessibilité, bonnes pratiques…

24ways est son pendant en anglais. Même style d’articles, mais en anglais.

UXmas propose des articles sur le thème de l’UX (User eXperience).

24pullrequests fonctionne un peu différement. Il propose aux utilisateurs de contribuer à un projet open source différent chaque jour, en fournissant une plateforme qui incite à faire une pull request par jour.

Plus décalé, The Avengifs propose tous les jours un Gif rigolo.

Si vous connaissez un calendrier qui manque à cette liste, n’hésitez pas à le dire dans les commentaires !

Retours sur le ForumPHP 2014

27 octobre, 2014

Le Forum PHP, c’était la semaine dernière et c’était super bien. Petit compte rendu pour les absents, les liens ramènent vers la page joind.in des conférences.

La théorie, une vision de l’avenir du web

Plusieurs conférences étaient un peu théoriques, dans le sens où elles présentaient une vision du développement et des pratiques qui gravitent autour de manière idéale. Même si le monde réel est plus mitigé, celles auxquelles j’ai pu assister valaient le coup, et je vous les recommande.
Sebastian Bergman (créateur, entre autres, de phpunit), expliquait qu’il y a 4 grands problèmes à faire des applications : la présentation, la persistance, les problématiques bas niveau, et la logique métier. Aujourd’hui, on gère à peu prêt correctement les 3 premiers grâce -entre autre- aux framework, il y a maintenant plein de choses à faire mieux pour améliorer et rendre pérenne la plus importante, la logique métier. Même si la conférence en elle même était un peu passe partout, j’ai trouvé le rappel d’idées qu’on considère implicites pertinent.
William Durand et son analyse des pratiques de tests automatisés m’a mis sur le cul. Thésard sur la question, son état de l’art et sa vision d’où les tests se dirigent et doivent se diriger donnaient vraiment envie de mieux maîtriser la question. Sa présentation contient un paquet de mots-clés et de librairies qui devraient gagner en popularité.
Francois Zaninotto, dans un discours façon homme politique (une idée originale bien menée) présentait une vision selon laquelle les framework full stack vont décliner pour laisser place à plus de micro framework, de micro services, d’API. L’idée, à terme, étant de se rapprocher d’une philosophie à la unix (faire des applications/services ayant un but unique mais le faisant très bien). L’avenir n’est plus à des mono-technologies, mais à l’usage de techno adaptées à des besoins précis : CMS en PHP, api en node, applis mobiles qui consomme ces API. Ce sera entre autre possible grâce à l’interopérabilité permise par l’utilisation d’HTTP, et des groupes de discussion comme php-fig.

Je vous encourage à regarder les conférences lorsqu’elles seront disponibles car il est bien évidemment très difficile de résumer en quelques mots ces conférences riches en idées.

La pratique, c’est à dire la théorie avec du retard et du pragmatisme

J’ai beaucoup apprécié la vision théorique de ces présentations, mais j’ai aussi beaucoup apprécié les retours d’expérience de plusieurs boites présentes. Cela permet de situer l’état de l’industrie par rapport aux visions théoriques, et car cela m’a permis de voir que ce nous faisons dans ma boite tient autant la route que ce qui se fait ailleurs. Au delà du côté « c’est bon pour l’ego », cela m’a surtout permis de voir que où nous n’avons pas de réponses, d’autres sont tout autant dans le brouillard que nous.

La conclusion ? En théorie, on sait faire beaucoup de choses depuis longtemps. En pratique, le temps que les choses soient intégrées dans l’industrie il faut beaucoup de temps, et pas mal de compromis (« The only sure thing about computer science: everything is a tradeoff« , comme le disent certains, et qui se généralise probablement très bien).

Maison du monde parlait des problèmes de régression de leur site e-commerce. Intégrer l’automatisation de la qualité par des tests ne s’est pas fait sans mal, pose de vrais questions d’organisation et est, chez eux, un enjeu permanent.

Les développeurs de L’express expliquaient l’état de leurs recherches sur l’automatisation de déploiement d’environnement de développements grâce à puppet, chef et amazon. Ces outils permettent de gagner en automatisation, et ont une forte valeur ajoutée, mais laisse encore des questions et ont chez eux un coup d’adoption élevé. Répliquer la configuration exacte de prod est compliqué (notamment quand on souhaite également répliquer la base de données quand elle est conséquente, pour reproduire des bugs complexes sans avoir à le faire directement en prod par exemple). Ils n’ont pas de solution pour reproduire les problèmes d’assets (images, uploads) dans les environnements de développement de manière systématique sans avoir à dire « t’inquiète, ça marchera en prod ».

Maxime Valette, fondateur de Viedemerde, expliquait comment ils ont (sur)vécu à l’explosion de viedemerde.fr à ses débuts, à cheval entre les besoins de communication pour répondre aux journalistes, et les besoins démentiels d’infrastructure auxquels ils n’étaient pas du tout préparé (en pour lesquels le temps possible de mise en place d’une solution se chiffrait en heures). Bref ça a plus parlé de survie que de qualité, mais cela montrait clairement que la qualité de code n’empêche pas du tout un site de survivre à des très gros volumes de visite (comme le dit Jeff Atwood, hardware is cheap).

Les vieux de la vieille

C’est assez inévitable avec un langage qui a plus de 15 ans et qui est le plus déployé dans le monde, des présentations sur les CMS les plus répandus présentaient leur situation courante et l’avenir.
Je ne suis pas utilisateur, mais ça a permis de voir que là où EzPublish et Drupal ont récemment fait le choix de la refonte pour tenir dans le temps, WordPress préfère conserver la rétrocompatibilité en ne touchant pas au core. On verra bien ce que cela donnera dans les années à venir : wordpress a le volume, les autres ont maintenant une meilleure qualité de code, mais ça n’est pas forcément pertinent et nécessaire pour mieux pénétrer le marché…

Les API à l’honneur

Les micro services et API avaient le vent en poupe lors du forum. Plusieurs conférences en parlaient et il y a notamment eu 2 retours d’expérience sur le sujet, l’une faite par les gens d’Elao expliquant tous les problèmes qu’ils ont eu et auquel on peut s’attendre d’être confrontés un jour ou l’autre lorsqu’on cherche à mettre en place une architecture d’api orientée micro services. La présentation était assez macro, et présentait les problématiques de communication, d’infrastructure, de sécurité, de monitoring, de cache…
L’autre, présentée par quelqu’un de l’équipe d’Arte rentrait plus dans les détails, avec quelques bouts de code sur comment ils avaient pu résoudre certains problèmes. Les deux donnaient des idées à des niveaux différents et sont complémentaires.

De nouveaux usages

Les conférences parlaient aussi de « nouveaux » usages, des usages pas encore tout à fait répandus dans la communauté.

Je parle beaucoup d’API, quelqu’un de chez Lemonde est venu expliquer comment ils ont intégré du nodeJS dans leur pile applicative lors de la refonte de leur CMS, notamment pour exposer une API consommé par une application javascript monopage.

J’ai beaucoup aimé sa remarque « Considérez vous comme des développeurs avant d’être des développeurs PHP ». Merci ! Il faudrait l’imprimer en immense et l’afficher dans toutes les boites. Ca marche également avec « vous êtes des développeurs avant d’être des développeurs web ». Cette idée a l’air simple mais en pratique, c’est parce que des gens ont regardé ce qu’il se faisait ailleurs, notamment dans les applis clients lourd, que les bonnes pratiques du génie logiciel (tests automatisés, injection de dépendances par exemple) ont fini par arriver dans le monde du PHP. Ca a toutefois mis beaucoup de temps et PHP (et le web en général) continue d’avoir du retard. Bref, cette conférence était l’application directe de l’idée de Francois Zaninotto, selon laquelle nous arrivions sur plus d’interopérabilité grâce à HTTP, et à l’utilisateur d’outils spécifiques pour des besoins précis.

Une autre série d’outils que j’ai pu découvrir, ce sont les outils d’analyse de code. Scrutinizer, ainsi que qu’Insight de SensioLabs permettent de voir le code qui ne respecte pas des règles élémentaires (le passage de paramètres get directement dans les requêtes SQL, donc source d’injection par exemple), même dans des configurations complexes. Leur force, c’est leur utilisation en SaaS, intégrée avec Github, qui ouvre des perspectives intéressantes.

Une conférence présentait également une idée assez intéressante: l’utilisation de diffbot pour concevoir des API pour ses propres besoins. Basé sur du scraping de page intelligent, on peut se créer sa propre API pour des sites qui n’en proposent pas, par exemple pour sortir de manière automatique la liste des articles publiés par une personne sur un site éditorial, pour par la suite automatiser des tâches (en faisant des graphes de fréquence de publication) de suivi.

J’ai eu l’impression que ça n’a pas intéressé grand monde, peut-être l’intérêt pour les développeurs est moins immédiat que dans d’autres sujet. C’est pourtant hyper disruptif et je suis convaincu que ça va gagner en popularité d’ici peu avec les avancées et les nouveaux besoins amenés par le big data (ça y est, moi aussi je me mets à parler comme un chef de projet d’agence digitale).

La conférence en elle même

La conférence a bien marché, l’organisation était top. Les speakers, pour beaucoup très connus dans la communauté étaient évidemment très compétents. Les sujets étaient généralement pointus, ce qui permet de ramener plusieurs idées et pas mal de motivation pour faire mieux chez soi…

Une seule conférence m’a franchement déçue, celle de Dayle Reese. Il devait parler de Laravel, mais après avoir parlé 15mn de lui s’est trouvé à court de temps. J’y suis allé pour découvrir la philosophie de ce framework controversé (et, ironiquement, qui semble pratiquer le culte de la personnalité derrière son gourou, Taylor Otwell), je ne suis pas plus avancé, et n’ai aucune envie de creuser plus la question, dommage.

Au niveau du fonctionnement, il y avait simultanément deux conférences, ce qui permettait de choisir les thématiques qui nous intéressaient (ou, parfois, de devoir faire un choix terrible !). L’horloge était bien gérée par l’équipe d’organisation, il n’y a presque pas eu de retards et c’était vraiment bien pour ne pas louper de présentation. Une gestion rigoureuse du temps n’est pas la norme dans les conférences alors que c’est pourtant essentiel, c’était donc cool d’avoir bien géré ça.

Le seul bémol, c’est le manque de places parfois pour certaines conférences. Il fallait arriver en avance pour certaines conférence afin d’avoir une place assise, pour des histoires de sécurité, le personnel du beffroi était intransigeant sur la question. C’est d’autant plus dommage pour la table ronde finale, seul événement à ce moment là… il n’y avait pas de places pour tout le monde, et arrivant parmi les derniers, l’accès à la salle m’a été refusé car il ne restait plus de places assises. Dommage pour moi. Même si c’est un signe positif pour l’événement qui marche très bien et pour la communauté qui n’a pas fini de faire des trucs sympa, vu le prix des places c’est pas super cool.

Evidemment, cet article bien trop long met de côté la moitié des conférences, et ne parle pas des ateliers vu que je n’ai participé à aucun d’entre eux. Et si le sujet des API m’a marqué car il m’intéresse, il est probable que chacun soit revenu avec des idées différentes. Quoi qu’il en soit, c’était très chouette et si vous n’y étiez pas, je vous conseille de regarder les slides des présentations. Si vous n’en pouvez plus d’attendre les vidéos officielles, rabattez vous sur la video officieuse du karaoké slideshow 🙂

Quelques astuces testées sur le terrain pour débugguer une application angularJS sans quitter le navigateur.

Dans chrome, on ouvre la console avec F12 ou ctrl+maj+j. Couplé au fait que l’on peut modifier le code et le faire rejouer directement depuis les outils pour développeurs, cela permet de débugger/corriger rapidement son code sans avoir à recharger la page systématiquement, ce qui est parfois très pratique.

Récupérer un service

Des fois un service en cours de développement ne marche pas comme il faut et c’est pas toujours marrant de devoir recharger la page à chaque modification pour déclencher à nouveau l’appel en question et le débugger. Par contre, on peut récupérer le service avec la méthode ci-dessous, modifier en direct la méthode depuis l’onglet « sources » de chrome dev tools, et lancer l’exécution à la main de la méthode réticente.

1
2
var service = angular.element('body').injector().get('myService');
service.maMethodeARelancer("plop");

A mettre entre toutes les mains. Depuis que j’ai découvert ça, je ne peux plus m’en passer.

Récupérer un scope local

Des fois on a besoin de récupérer le scope sous un contrôleur, que ce soit pour voir le contenu d’une variable à un instant particulier. Pour ce cas d’usage, la plupart du temps le débuggueur est plus pratique.
Par contre, quand on veut appeler une action de controlleur présente dans le scope, c’est très pratique.

Il faut connaitre le sélecteur DOM de l’élément du DOM dans lequel se trouve le scope auquel ou souhaite accéder.

1
var scope = angular.element('[ui-view=panel-communication]').scope()

Ensuite, on peut accéder aux propriétés accessibles dans ce scope, et appeler les méthodes que l’on souhaite.

1
2
scope.unMethodeARelancer("pouet")
scope.UnAttributQueJePeuxRegarderPlusFacilementDansLeDebuggueur

Débugger les directives

Il est parfois d’accéder au scope local à la directive, qui ont un don assez fou pour ne pas contenir les valeurs que l’on croit, les rendant particulièrement pénibles à débugger.

1
var localScope = angular.element('[ui-view=panel-communication]').localScope()

Certains directives ont un contrôleur, auquel on peut accéder, ce qui est un luxe qui peut vous faire gagner pas mal de temps et vous économiser nombre de dolipranes.

1
var controller = angular.element('[ui-view=panel-communication]').controller()

Bon courage !

terminatorIl y a quelques semaines, mon collègue tilap écrivait un article sur l’utilisation de screen partager un terminal en plusieurs.

Screen est plus largement répandu, et permet de partager un terminal sans installation préalable lors d’une connection SSH. Par contre au quotidien je préfère utiliser terminator, qui est quand même plus simple et convivial. Voici donc un petit guide de survie.

Installation

L’installation sur Ubuntu 14.04 se fait via :

1
apt-get install terminator

Les raccourcis essentiels

4 raccourcis servent à faire la plupart des choses :

  • ctrl+maj+o = ouvre un terminal dans le répertoire actuel, une barre horizontale sépare alors les 2 terminaux
  • ctrl+maj+e = ouvre un terminal dans le répertoire actuel, une barre verticale sépare alors les 2 terminaux
  • ctrl+maj+w = ferme le terminal sélectionné
  • ctrl+maj+x = fait disparaitre les autres terminaux, en ouvrant le terminal sélectionné en grand. ctrl+maj+x permet de revenir aux autres écrans

Pour ceux qui aiment naviguer au clavier, on peut se déplacer entre les terminaux rapidement assez rapidement avec quelques
ctrl+tab permet de naviguer vers le terminal suivant (ctrl+maj+tab pour obtenir le précédent)
ctrl+maj+gauche/droite/haut/bas permet déplacer les séparateurs entre les différents terminaux

La configuration de terminator est stockée dans ~/.config/terminator/config. Voici quelques paramètres que je trouve bien pour donner à terminator l’apparence d’un gnome shell :

1
2
3
4
5
6
7
8
9
[global_config]
  suppress_multiple_term_dialog = True
[profiles]
  [[default]]
    background_image = None
    background_color = "#2c001e"
    split_to_group = True
    show_titlebar = False
    foreground_color = "#ffffff"

Cela permet d’avoir la couleur de fond d’ubuntu et masque les titres ajoutés par terminator, donnant ainsi aux terminaux le même aspect qu’un gnome-terminal, mais en ayant plus de possibilités.