Cette newsletter n'est pas aussi régulière que j'aimerais mais je vais essayer de reprendre le rythme d'un envoi par semaine. Peut-être avec un peu moins de contenu à chaque fois ?

Laravel 5.8

Laravel 5.8 est enfin disponible. Plusieurs nouveautés intéressantes :

• La bibliothèque DotEnv, chargée de lire les fichiers .env, a été mise à jour en version 3, avec quelques améliorations et modifications. En particulier, les valeurs ne sont plus trim, cela veut dire que si vous avez des espaces à la fin de vos lignes, vous pouvez avoir quelques problèmes.
• Laravel est maintenant compatible avec Carbon v2 en charge de gérer les dates. Ce qui m'intéresse le plus cette mise à jour c'est l'ajout d'une version immuable des dates, plus besoin de jouer avec les ->copy() !
• Lors de l'ajout d'une valeur en cache, Laravel utilise maintenant les secondes à la place de minutes pour définir la durée de validité du cache. Sans changement, votre cache durera donc maintenant beaucoup moins longtemps (5 secondes à la place de 5 minutes par exemple). Sauf si vous utilisez une date Carbon pour définir la durée du cache ! (voir la newsletter du 11 février)
• Les fonctions array_* et str_* ont été marquées comme dépréciées, une nouvelle bibliothèque officielle laravel/helpers a été créée pour les conserver dans nos projets.
• Plus besoin de renseigner la liste des Policy dans notre AuthServiceProvider si nous respectons la convention de localisation, elles seront automatiquement découvertes et utilisables par le framework.

Repositories avec Laravel

Nous avons longuement discuté des "repositories" sur le Discord ce week-end, et c'est un sujet clivant dans la communauté Laravel avec du pour et du contre.

Comme je le dis souvent, tous les projets informatiques sont différents. Je ne pense pas qu'une solution universelle soit une bonne chose. Il n'y a donc pas de réponse à apporter à la question de l'utilisation des "repositories" en Laravel. Par contre, il y a de nombreuses questions à se poser (questions qui peuvent également convenir à la majorité des problèmes en informatique).

Tout d'abord : « Pourquoi fais-je ça ? ». Cela peut sembler évident, mais pour des débutants, ou même des personnes plus expérimentées la mauvaise réponse pourrait être « parce que l'on m'a dit que c'était la bonne pratique ». Personne n'a étudié votre projet autant que vous, et vous seul être à même de définir vos bonnes pratiques en fonction de vos besoins. L'idée de cette question est également de déterminer le vrai problème (s'il y en a un).

Ensuite, nous pouvons nous demander : « Comment pourrais-je faire autrement ? ». Il y a rarement une seule solution à un problème en informatique, et le fait de lister plusieurs solutions permet de mieux comparer, mettre en évidence des points négatifs et également des points positifs. Concernant notre discussion sur le Discord, les problèmes à résoudre étaient les requêtes complexes et la mise en cache. Pour les requêtes complexes, une autre solution pourrait être les "scopes" d'Eloquent. Pour la mise en cache, une autre solution pourrait être de créer une méthode allCached() sur notre modèle de base, afin de pouvoir rapidement récupérer la totalité d'une table depuis un cache. Ces deux solutions sont pleines de problèmes, mais le fait de les envisager permet un choix plus éclairé.

« Est-ce que ma solution est plus simple ? ». Je cherche souvent la simplicité dans mon code. Je suis un partisan du fait qu'un code plus simple permet d'être mieux compris à la relecture, mais également d'être modifié plus rapidement. C'est un critère plutôt subjectif, d'autres personnes penseront qu'une architecture « standard » permet d'être mieux compris par tous et d'être plus facilement modifiable. Les deux positions se défendent.

Vous pouvez également vous demander « Est-ce que ma solution sera modifiable/supprimable en fonction de la quantité d'évolution prévue ? ». Habituellement, il est difficile de prévoir les évolutions futures (personne ne peut lire l'avenir), mais savoir si notre projet va être modifié par 10 personnes à temps plein pendant 5 ans, ou si notre projet va être déployé en production puis modifié de temps en temps par une personne sur son temps libre, nous donne une indication sur le volume de changements à prévoir. Beaucoup de personnes pensent qu'avoir beaucoup de classes qui ne font qu'une seule chose rend le code plus simple à modifier, ce n'est pas toujours le cas, donc se poser cette question est assez important à mon avis.

Sortir de notre bulle

Nous sommes tous dans des bulles plus ou moins grandes : la bulle des développeurs Laravel, des développeurs PHP, des développeurs web, et même des personnes travaillant dans l'informatique. Ces bulles posent de nombreux problèmes, car nous avons tendance à prendre pour vérité absolue ce qui se dit à l'intérieur.

Lorsque je n'ai pas de contrat de formation ou de consulting en Laravel, je ne passe pas mes journées à apprendre de nouvelles choses sur le framework, je préfère largement changer de cadre pour remettre en question mes à priori. Ces changements de cadre permettent de revenir avec de nouvelles idées et d'apporter une plus-value intéressante à mes clients.

Il y a deux ans, j'ai appris à développer en Haskell, un langage purement fonctionnel. Ce langage ne possède ni boucle, ni réelle condition if et nous oblige à repenser notre façon de développer (avec des map, des filter, des reduce, du pattern matching…). De plus, les développeurs Haskell sont souvent très attachés à la théorie des types, quelque chose d'inconnu aux développeurs PHP. Pour eux, le développement PHP est archaïque et ils ne se voient pas ne pas avoir accès au "Higher Kinded Types", aux "Functors", aux "Modads"… Nous travaillons pourtant très bien sans, mais après avoir étudié tous ces concepts, je comprends très bien leur puissance. Mais je comprends aussi très bien l'avantage de PHP avec sa communauté et ses bibliothèques/frameworks extrêmement aboutis.

En ce moment, je m'intéresse au développement de jeux vidéo : sans doute l'un des domaines de développement le plus complexe actuellement. Saviez-vous que dans le jeu Uncharted 4, lorsque vous conduisez sans soucis votre 4x4, votre ordinateur modélise le moteur à explosion de façon assez réaliste, calcule le couple créé, les forces de rotation sur les essieux, la friction des roues contre le sol et les forces appliqées aux amortisseurs pour en déduire l'accélération finale de la voiture ? Johnatan Blow, l'un des premiers développeurs indépendants de jeux vidéo (Braid, The Witness), travaille aujourd'hui sur un jeu de puzzle d'une dizaine de milliers de lignes de code, il navigue de façon assez efficace parmi les 3 fichiers principaux sokoban.jai, simulate.jai et render.jai, chacuns comptant plusieurs milliers de lignes de code, avec uniquement des fonctions, aucun objet, aucune interface, aucun trait… Cela ne l'empêche pas de travailler sur ce projet depuis plusieurs années avec une équipe de plusieurs développeurs et de faire régulièrement des modifications radicales sur le fonctionnement interne du jeu, de développer son propre langage de programmation et d'avoir une compilation en moins d'une seconde pour une dizaine de milliers de lignes de code (là où nous devons attendre 5 minutes à chaque npm install).

Chose intéressante, Johnathan Blow pense sans doute que le langage Haskell n'est pas du tout adapté à la programmation moderne car trop stricte et pas assez performant. Les développeurs Haskell penseraient sans doute que son nouveau langage, Jai, n'est absolument pas adapté à la programmation moderne car il est trop permissif. Et beaucoup de gens critiquent PHP sur ses performances et sur ses types. Pourtant, nous créons tous des logiciels utiles, les objectifs de ces logiciels étant différents (performances, robustesse, fonctionnalités…), nous utilisons des outils différents.

J'espère que cette nouvelle newsletter vous aura permis de réfléchir en dehors des bonnes pratiques et des « on m'a dit » et que vous aurez de nouvelles idées pour vos projets ! N'hésitez pas à venir en discuter sur le Discord, ou de me répondre par mail si vous avez des questions ou des remarques sur le contenu.

Bonne fin de semaine à tous !

Thibaud