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

Partage de configuration git

Depuis que je travaille avec Git, j'ai un problème : "comment partager mes configurations entre mon poste de travail professionnel et mon poste de travail personnel ?"

Jusqu'à ce jour, j'avais trouvé une solution pour beaucoup de mes outils, mais j'avais toujours un soucis avec Git parce que le fichier de configuration contient des éléments qui ne sont pas partageables (l'email du commiteur, par exemple)

J'ai découvert récemment qu'il était possible d'inclure une fichier dans le fichier .gitconfig, et la solution est donc apparue.
J'ai finalement placé les éléments partageables dans une fichier spécifique que je versionne, et dans mon fichier ~/.gitconfig, il me suffit de placer le code suivant :

[include]
    path = ~/path/to/Save/Git/.gitconfig