atoum adopte semver

Pour ceux qui ne le savent pas encore, j'utilise atoum pour mes tests unitaires.

Il s'agit d'un framework de tests unitaire qui a été le premier à mes yeux à bousculer PHPUnit avec une approche novatrice, orienté objet, avec des performance impressionnante, un système de mock très simple et efficace.

Depuis 3 ans, j'évangélise cet outil partout où je passe, même chez M6Web, pour qui je travaille depuis 1 an 1/2.

Toutefois, lors de cette dernière expérience, je me suis confronté aux limitations de la Rolling Release, à savoir que lorsque l'on déploie atoum sur plein de projets, on emporte continuellement des nouveautés qui influent sur le résultats. Tant que ces changements sont compatibles avec l'existant, cela ne pose pas plus de problème que ça. Par contre, lorsqu'un changement apporte une régression, il suffit d'utiliser des outils d'intégration continue, et c'est tout les déploiements d'une société qui peuvent se retrouver bloquer.

On peut débattre sur la manière de nommer le changement : regression, correction, évolution, mais à partir du moment où le résultat de l'exécution d'une suite de tests change uniquement parce que l'outil de test à évolué, je considère qu'il y a régression.

En conséquence, je milite depuis plus d'un an pour qu'atoum soit taggé, de manière à pouvoir stabiliser la version d'atoum utilisée pour un projet.

Et depuis ce matin, cet espoir est comblé puisque la release 1.0.0 de atoum a été délivrée ! J'irais même plus loin en disant qu'atoum va désormais être taggé selon l'approche semver !

Et si vous avez lu l'article de Julien, vous aurez donc vu que nous sommes désormais 2 RM (Release Manager), Ivan Enderlin et moi-même, à gérer ce versionning qui va très fortement faciliter l'intégration d'atoum via composer, et qui, je l'espère, sera une véritable aide à sa démocratisation.

Me voici donc embarqué dans la team atoum, ce qui est un grand honneur qui m'est fait, et qui me donne désormais envie de m'investir un peu plus dans son développement.

La mode du bashing

Depuis de longs mois, voire des années, je me fais souvent la même réflexion en observant les réactions des gens lors des discussions de comptoir : le bashing est tendance.

Il me semble que, par le passé, je voyais plus de débats où on défendait son avis, on mettait en avant les qualités pour justifier ses choix. Mais maintenant, il est plus "hipe" de dénigrer les choix de l'autre, voire l'autre (Argumentum ad hominen).

Récemment, nous avons eu l'exemple des libraires qui affichent leur "choix" de ne pas proposer le livre de V. Trierweiler, alors que la réalité est sûrement tout autre.

La réalité est que ces libraires sont certainement plus intéressés par l'impression de supériorité intellectuelle qu'ils vont donner à leur clientèle que par une profonde conviction éthique.

Hier soir, j'étais témoin d'un énième Apple bashing et j'ai eu cette même impression que la personne cherchait à se donner une image de supériorité en dénigrant les "idiots qui vont jeter un téléphone qui a à peine 1 an et jeter par la fenêtre des centaines de $ parce qu'Apple change le nom du modèle".

N'avons-nous pas été témoins de la même chose lors de la sortie du Galaxy S3 de Samsung (je n'ai pas suivi la sortie du S4) ou lors de la plus récente sortie du Nexus 5 ?

De même, autant pour Apple que pour Samsung ou Google, cela représente une partie des utilisateurs, qui n'est pas une majorité. Il va y avoir une forte demande du dernier modèle sortie, au moment de sa sortie, mais la majorité des gens qui vont changer n'ont pas le dernier modèle depuis 6 mois.

Je suis concerné par cette dernière affirmation, puisque j'ai acheté un iPhone 4S à sa sortie, et je compte m'acheter le 6 dès qu'il sera sorti, mais je serais donc passé d'un iPhone 3G à un 4S, puis d'un 4S à un 6, soit à chaque fois 2 modèles totalement ignorés.

Bref, pour en revenir au sujet initial, nous faisons tous des choix, c'est ce qui nous construit et qui fait de nous une personne unique au monde. Mais vivons avec nos choix et nos idées, pour nous, nos proches. N'attaquons pas les idées et les choix des autres pour se donner l'impression d'être "mieux" ou "supérieur".

Au revoir CleverAge

Certes, ce titre est vu et revu, mais il parle toujours de la même chose.

Donc, pour la troisième fois en 2 ans 1/2, je change d'employeur.

Toutefois, autant j'ai quitté Prestaconcept pour me lancer un nouveau défi et j'ai quitté TEA parce que je ne m'y sentais pas à ma place, autant cette fois ci, c'est plutôt pour assainir ma situation.

Depuis le mois de juin 2013, je suis un employé de CleverAge, mais je suis en délégation chez M6Web. Du coup, je ne me sens pas complètement intégré dans cette incroyable famille qu'est CleverAge, tout en étant pas un employé de M6Web, pour qui je m'investi jour après jour.

J'en étais à ce stade de réflexion quand M6Web a décidé d'ouvrir des postes de lead-developpeur. Comme dans les faits, je travaille pour M6Web depuis 1 an, et je trouvais donc qu'il était plus naturel de faire le choix de M6Web. Et c'est ainsi que, début octobre, je quitte CleverAge pour devenir interne M6Web.

Je tiens tout de même à insister sur le fait que CleverAge est une excellente société, avec de très bons projets et des collaborateurs de qualité. Si vous êtes à la recherche d'une société qui sait prendre soin de ses collaborateurs, je ne peux que vous encourager à prendre contact avec eux.

Mais maintenant, je suis pleinement tourné vers l'avenir avec M6Web, et sur le projet RisingStar pour commencer ;)

Code reviews : just do it

Ce titre est volontairement repris sur l'article d'Éric, car il s'agit d'une réponse/complément que je ne me voyais pas faire en commentaire.

Ayant travaillé chez TEA par le passé, j'ai donc la connaissance de la manière dont se passent les code reviews chez TEA, et je suis en phase complète avec les avantages listés par Éric : augmentation de la qualité et partage de l'information.
Il y a non seulement le fait que plusieurs yeux, plusieurs esprits passent sur un code, une problématique, et il y a donc un échange constant sur ce qui est fait, pourquoi et comment. Mais il y a aussi et surtout une vraie communication qui se met en place entre les développeurs, réduisant l'effet de chapelle (une seule personne capable d'intervenir sur un code) et augmentant la cohérence générale d'un projet.

J'ai également constaté un effet de bord plutôt sympathique, car lorsque l'on sait que son code va être relu, on s'oblige à le faire beaucoup plus propre et on s'interdit les petits raccourcis crades qu'on pourrait utiliser dans un moment de flemme, d'une manière semblable à ce qui se passe quand on code pour un projet open-source.

Depuis, je travaille en délégation chez M6Web, dans l'équipe Replay, et nous avons mis en place le même système : tout développement se passe dans sa branche propre, amène à la création d'une PR, et il faut la validation de 2 personnes de l'équipe (sur 8 personnes) pour que la PR soit mergeable.
Toutefois, ce système peut rapidement trouver ses limites. Chez M6Web, La focalisation par projet est moindre, du fait du nombre de personnes composant l'équipe et de l'organisation de la structure, ce qui implique que nous travaillons sur une grosse dizaine de projets en parallèle et cela a des impacts :

  • Il est souvent compliqué intellectuellement de switcher de projet et de problématique pour relire le code de quelqu'un d'autre.
  • Savoir quelles sont les PR en attente sur une dizaine de projets est un vrai exercice d'équilibriste qui demande, à l'état brut, de parcourir les PR en attente sur tous les projets pour voir celles qui sont en attente.

Au final, nous avons un phénomène d'empilement des PR qui pénalise l'avancement quotidien.

Toutefois, tout ceci n'est qu'un problème d'organisation, et il vaut mieux trouver comment contourner les limites plutôt que de faire marche arrière sur la code review automatique.

Je ne manquerai pas de vous faire un retour des solutions que nous avons mises en place.

La critique est aisée, mais l'art est difficile

A force de vous le répéter, je pense que vous savez tous maintenant que je m'ocupe de l'AFUP Lyon.

Nous sommes 3, Adrien Gallou, Sarah Haïm-Lubczanski et moi-même, à prendre chaque jour sur notre temps personnel pour vous proposer des événements de tout type : apéroPHP, ateliers, conférences.
Et, pour certains événements, nous faisons appel à d'autres bénévoles, qui sont moins impliqués, mais qui répondent présents lorsque nous avons besoin d'eux.

Tout ce travail est purement bénévole.

Tout ça pour vous dire que le but commun qui nous anime tous, c'est de proposer des événements techniques autour de PHP à Lyon, et permettre une émulation de notre petit monde dans notre ville, rien de plus.
Les seuls moments où nous parlons d'argent, c'est pour payer les frais engagés, rien de plus.

Alors, quand je vois un commentaire laconique, nous accusant d'avoir fait volontairement un plagiat, ça me touche beaucoup.
Je ne sais pas si c'est de la sur-sensibilité, mais j'ai lu "ah bah bravo les gars, vous faites pas chier, prenez le travail des autres sans trop vous embêter, c'est super intelligent les gars".

Est-ce que cette personne a envisagée que nous ayons pu choisir ce logo sans savoir qu'une équipe de NFL l'avais choisi ? Est-ce que cette personne a pu envisager que nous n'avions pas de mauvaises pensées ?
Est-ce si dur de ne pas commencer en agressant les gens, mais en les avertissants ?

Et cette personne, qui nous met le nez dans nos déjections, est-ce qu'elle a fait une proposition pour corriger ?

Comme le disais Philippe Néricault Destouches :

La critique est aisée, mais l'art est difficile