Bienvenue à l'AFUP Day 2020 Nantes !

Quand on débute en PHP, on tombe très vite dans l’usage intensif des tableaux associatifs, puis on s’oriente progressivement vers des hiérarchies de classes, value objects, itérateurs. Pourtant, il existe tout un ensemble de classes dans la bibliothèque standard PHP (SPL) qui semble être boudé par les développeurs, pourquoi ? Peut-être parce que ces classes ne sont pas très pratiques à utiliser ou apporte peu de chose. C’est de ce constat qu’est née l’extension PHP-DS pour PHP 7. Petit tour d’horizon.

L'email existe depuis le début de l'Internet, et il a peu évolué. Une fois envoyé il ne change plus et les interactions sont limitées.

Mais cela va changer, avec la nouvelle norme AMP for e-mail, qui est en test dans Gmail et sera ensuite implémenté par Outlook et Yahoo. Les mails pourront charger des données d'un site à l'ouverture (s'il y a eu des changements depuis l'envoi du mail), s'adapter au différentes résolutions, avoir des interactions (carrousel, animations).

Et tout cela de manière sécurisée (pas de JavaScript, validation de l'envoyeur, même URL que l'email...).

Manual testing, c'est déja ca ;-) Automated Unit Testing, c'est un bon début Integration Testing, un cran plus haut niveau et après ?

Lors de ces procédure de tests il est (trop) souvent mis en avant qu'une des metrics reine est le code-coverage. Cependant, c'est plutot le nombre d'assertions qui prime au final, le coverage étant surtout le nombre de lignes ayant été exécutées durant les tests. En poussant à l'extrême, on peut facilement imaginer un code 100% "couvert" par les tests, mais avec 0 assertion, ces tests "blancs" (passeront donc quelques soient les entrées) mais à fort coverage, semble avoir une valeur ajoutée.

Une deuxième hantise du testeur est de "Ne jamais faire confiance à 1 test que l'on a jamais vu FAIL".

C'est là que le Mutation Testing entre en scene.

Des frameworks existent (en PHP il y a Infection https://infection.github.io ) qui vont prendre les 2 "artifacts" existants déjà dans votre projet (le code source et vos tests) et va tout simplement

1. modifier votre code (1 seule modification ! ceci étant 1 mutation)
2. faire tourner les tests
3. s'attendre à ce que vos tests "détectent" cette mutation en reportant au moins 1 test FAIL.
4. répéter avec 1 nouvelle mutation

Une approche simple, mais coûteuse sur le temps de build, d'avoir un bon retour sur la qualité et valeur réelle de vos tests, et ce avec un cout d'entrée vraiment faible.

Une approche où finalement le but est d'avoir des tests qui FAIL ! mais aussi surtout pour le plaisir de tuer des mutants ;-)

L’informatique se veut actuellement plus verte pour mieux respecter notre planète. Le GreenIT a fait son apparition depuis quelques années mais comment est-il possible concrètement d’éco-concevoir son site internet ?

À l’heure actuelle, notre société devient de plus en plus numérique (démarches administratives, échanges sociaux, achats…). L’accessibilité d’un site internet est importante, si l’on souhaite que personne ne soit exclu de cet univers numérique. Différents types de handicap (visuel, moteur…) sont à prendre en considération pour qu’un site internet soit accessible à tous.

Bien évidemment, un site internet se doit également d’être bien référencé et performant.

Au regard de ces quatre points de vue, sont évoquées différentes pratiques à réaliser ou à bannir lors de la conception ou de l’évolution de sites internet.

PHP 5.5 a introduit les générateurs, permettant de créer des itérateurs de manière plus simple.

Mais les générateurs sont bien plus puissants que de simples générateurs, permettant de créer de nouvelles manières d'écrire du PHP : corroutine, PHP asynchrone et plein d'autres manières originales de faire du PHP !

Lors du PHP Tour 2017 Nantes, nous avions vu la présentation du composant akeneo/batch. Revenons sur 3 ans supplémentaires d'usage, de réflexions et de refactorisation qui ont abouti à la création d'un framework spécialisé.

Dans des environnement de plus en plus interconnectés, de plus en plus hétéroclites, nous voyons apparaitre l'usage des PWA, la généralisation des API et des tâches en files d'attentes asynchrones. Là où les solutions pour interroger des petits volumes de données dans des bases distantes commencent à atteindre une certaine maturité.

Où en sommes-nous sur les synchronisations en grand volume et aux formats de données hétéroclites ?

Ah ! le code «legacy», comme on l’aime ! Ce moment merveilleux où l’on vous présente le projet avec un petit sourire en coin : «bon ça n’est pas basé sur la dernière techno à la mode, mais ça marche !». Alors on commence à prendre «ça» par un bout et on réalise le désastre :

• Pas de versionning
• Fichiers de plus de 3000 lignes que même les anciens n’osent plus toucher
• Code tiers inclus dans le projet
• Framework qui fait de la magie noire
• Code mort J’en passe, et des meilleures !

J’ai moi-même connu ce type d’aventure en boulot et en perso, et j’aimerais partager avec vous quelques bonnes idées, et des mauvaises à éviter. On va parler de refactoring, de transition douce, d’amélioration continue, d’arbitrages techniques… Et c’est l’occasion de prendre un peu de recul aussi, pour penser global, mais agir local ! Pas pour la planète, mais pour le projet !

Beaucoup de sites web n'ont pas besoin de proposer d'interactions complexes avec l'utilisateur. Des solutions comme WordPress permettent de créer de tels sites sans savoir programmer, mais ont quelques limites : peu de contrôle sur le code généré, lenteurs, sécurité, ... Ces dernières années, j'ai développé plusieurs sites pro et perso en testant diverses solutions qui n'ont pas ces problèmes : les générateurs de sites statiques. Je propose de partager mon expérience et de montrer qu'on peut réaliser des sites modernes avec la qualité de l'artisanat tout en permettant à des non-développeurs de les alimenter !

Etre une équipe auto-organisée et pluri-disciplinaire implique une forte cohérence : il faut bien s'entendre, mais oser se dire les choses, il faut se compléter et se soutenir autant humainement que techniquement. Cette valeur forte de l'agilité est souvent mise à rude épreuve selon la manière dont sont constituées les équipes. Et à la base de la constitution des équipe, il y a l'embauche même des collègues.

Dans ma boite, nous nous embauchons les un·e·s, les autres, du coup nous travaillons notre cohésion dès l'embauche et ça fonctionne ! On aime travailler ensemble et on se tire vers le haut.

Dans cette conf, je vous propose de détailler notre process de recrutement pas si courant et pourtant plein de bon sens, en espérant qu'il fasse germer des idées pour que vous aussi, vous choisissiez vos futur·e·s collègues !

On se donne rendez-vous l'année prochaine ?