KeiruaProd

I recently gave an introductory talk about the Rust language, to experienced programmers who did not know the language. The presentation can be seen here and downloaded on Github. This article is a short summary of what I described.

The idea was not to enumerate features, but to highlight some of the cool things that have made this language so popular and growing quickly with a lot of enthusiasm.

I chose to focus on the 4 following elements:

• Tools
• Borrow checker
• Community
• Integrations with other languages

There are more of course, but hey, attention and time are limited resources, tech talk are no exception. Lire la suite »

I had a hard time learning rust at first. I didn’t quite know where to start, I focused on the wrong resources and lost some time. Here are my suggestions about everything you may need in order to learn and work with rust: where and what to learn, how to properly install the compiler, what tools you need and how to use them.

Lire la suite »

There is no example about how to use XML with Go on GoByExample, so here is how to do it. We’ll use the encoding/xml package for the standard library.

Lire la suite »

I’m using Markdown as a markup syntax for many things: the syntax is indeed really simple to use, it lets me focus on the content I need to write, and it can later be converted to HTML for « real life » display once I’m done. In the open-source community, it has become largely spread, and many developpers use it, like me, for non code-related stuff, like keeping notes or writing their journal. Lire la suite »

La plupart du temps, pour tester si une clé est présente dans un tableau, il faut utiliser array_key_exists. Pourtant on trouve encore des empty et isset à sa place, en pensant que ces 3 fonctions sont interchangeables : ce n’est pas le cas. Fin 2016 on trouve encore des confusions, donc cet article me servira de référence pour les futures revues de code 🙂

Lire la suite »

C’est bientôt Noël. Et si vous vous faisiez le cadeau d’apprendre quelque chose de radicalement nouveau, comme un nouveau langage de programmation ?

Lire la suite »

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 :

$ ./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 :

$ 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 :

$ 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 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

• 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.

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 :


$scope.types = [];

// 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é.

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 :


$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 :

#!/bin/sh
# On récupère la liste des fichiers modifiés
modifiedFiles=`git diff --cached --name-only --diff-filter=ACM`;
error=false;

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.