Le Forum PHP 2023 a fait le plein de sujets variés, passionnants, inspirants : afin de donner à chaque conférence la visibilité qu'elle mérite, nous avons choisi de lancer le premier calendrier de l'avent de l'AFUP, en publiant une vidéo par jour entre le 1er décembre et le 25 décembre. Une nouveauté qui viendra rompre les habitudes des années précédentes, où toutes nos vidéos étaient disponibles le même jour quelques semaines après l'événement, mais qui permettra à chaque talk de profiter d'une meilleure mise en avant. Et l'occasion de remercier individuellement chaque conférencier et conférencière pour le temps accordé à notre communauté !
Retrouvez quelle vidéo est publiée chaque jour sur notre chaîne YouTube et via les publications sur tous nos réseaux sociaux. Revivez chaque jour avec nous un moment du Forum PHP 2023 ou attendez le 26 décembre pour binge-watcher toutes les conférences !
L'AFUP vise à favoriser l’échange d’expertises et la diffusion des connaissances auprès de la communauté. La captation des conférences lors de ses événements, lorsque le format le permet, répond donc parfaitement à l'objectif que s'est fixé l'association. Actuellement, ce sont presque 700 vidéos qui sont d'ores et déjà disponibles sur la chaîne YouTube.
Une mission que relève notre partenaire dFusion depuis que le début, et qui nous fournit à chaque fois des vidéos de qualité, en un temps record. Encore merci à toute l'équipe dFusion, on se donne d'ores et déjà rendez-vous pour l'édition 2024 du Forum PHP !
Revivez les conférences qui vous ont le plus plu, partagez-les avec les membres de votre équipe, ou retrouvez les sujets que vous avez manqué lors du Forum PHP 2023, entre le 1er et le 25 décembre !
Retrouvez la version originale de cet article sur cette page.
Depuis maintenant 32 ans, le vénérable protocole HTTP est au cœur du fonctionnement du web. Ce protocole permet de récupérer depuis un serveur des “ressources” (tout ce qui peut être nommé peut être une ressource, mais il s’agit souvent de documents) grâce à leur identifiant unique : leur URL.
Depuis 1991, la popularité du web a explosé, au point qu’il peut désormais être considéré comme l’une des épines dorsales de nos sociétés. Avec cet engouement, de nouveaux usages sont apparus et de nombreuses fonctionnalités ont été ajoutées à “la plateforme web” pour les permettre.
L’un des plus populaires de ces nouveaux usages est la mise à jour en temps réel des ressources affichées à l’utilisateur d’un site ou d’une application web. Les utilisateurs attendent par exemple à pouvoir voir en temps réel les modifications effectuées sur un document partagé (une édition collaborative à la Google Docs), ou encore l’état du stock d’un produit vendu sur un site e-commerce, ou encore des réponses aux messages postés sur un forum de discussion en ligne.
Vous téléchargez donc une “ressource” (le document partagé, la fiche produit ou le message sur le forum) depuis un serveur et elle est affichée par votre navigateur. Mais que se passe t-il si cette ressource est modifiée ou enrichie par son auteur ou par un autre utilisateur après que vous l’ayez téléchargé ? Comment notifier les utilisateurs consultant cette ressource qu’elle a changé. Encore mieux, peut-on envoyer directement aux utilisateurs les modifications qui ont été apportées à cette ressource, afin que leurs navigateurs les affichent en temps réel ?
Malheureusement, même les versions les plus récentes de HTTP (HTTP/3, HTTP/2…) ne proposent pas nativement cette fonctionnalité.
Au fil du temps, plusieurs techniques et protocoles ont été développés pour pouvoir maintenir des connexion persistantes entre le client et le serveur : Comet (1996, maintenant obsolète), Server-Sent Events (2004), WebSocket (2008) ou encore WebTransport (toujours en cours de développement). Toutes ces techniques présentent différents avantages et inconvénients, mais toutes ont le point commun d’être relativement bas-niveau et de ne pas avoir été conçues spécifiquement pour pouvoir envoyer les mises à jour d’une ressource préalablement récupérée par HTTP et de nécessiter des efforts considérables de la part des développeurs pour les utiliser pour répondre à ce cas d’usage.
Lors de la conception de vos interfaces, il est probable que vous ayez déjà eu recours à des bibliothèques de composants.
Cependant, il peut arriver que celles-ci ne répondent pas de manière optimale à des cas particuliers ou à des exigences spécifiques de votre application, notamment dans des contextes métiers spécifiques.
Vous décidez alors de mettre en place un écosystème qui rassemble vos propres composants, typographies, couleurs, documentation et des directives d'utilisation : le Design System.
Dans cet article, nous allons vous expliquer comment construire un Design System robuste avec React.
Avant de plonger dans la mise en place d'un Design System robuste avec React, il est essentiel de comprendre les fondamentaux de ce domaine. Nous n'allons revenir que brièvement dessus, car nos derniers articles parus traitent justement de ces fondamentaux.
Un Design System réunit un ensemble d'éléments graphiques, des typographies, des palettes de couleurs, de la documentation et des directives d'utilisation.
C'est un référenciel qui garantit une cohérence visuelle et fonctionnelle qui apporte un cadre et des règles à respecter.
L'Atomic Design est une approche de conception de systèmes d'interface utilisateur et de design d'interaction. Cette approche consiste à découper les composants en éléments modulaires : Atome, Molecule, Organisme, Templates, et Pages.
Les Design Token sont un ensemble de valeurs ou de variables utilisés pour référencer plusieurs types d'éléments tels que les couleurs, typographies, espacements et bien d'autres.
Ces tokens permettent entre autres, de faciliter la mise à jour des styles et de maîtriser les déclinaisons de thèmes qui partagent des références communes.
La méthodologie BEM donne au CSS une convention de structuration, de nommage et d’organisation pour vos composants.
BEM envisage la composition d’une page web en plusieurs Blocks, qui contiennent des Elements, et ces derniers peuvent varier grâce à des Modifiers.
Les System Props sont une liste de propriétés permettant de personnaliser instantanément le style de vos composants.
Ces System Props sont des raccourcis pratiques pour ajouter des styles complémentaires qui permettent de modifier le comportement et l'apparence de vos composants.
Lors de la soirée communautaire du Forum PHP 2023, l'AFUP souhaitait permettre aux membres du public de se découvrir et d'encourager les rencontres. Pour ce faire, elle a développé un jeu en s'appuyant sur les badges des participant•e•s. En flashant un QR code y figurant, la personne découvrait à quelle équipe, parmi 4, elle avait été secrètement attribuée lors de son inscription au Forum PHP 2023. Sa mission lors du jeu était alors de retrouver le maximum de membres de son équipe, en flashant le QR code des badges des autres membres du public, et participant ainsi au succès global de son équipe.
L’équipe gagnante étant celle qui retrouve un maximum de ses membres sur le temps imparti, tout en multipliant les connexions entre ses membres : l'équipe Axolotl a remporté la partie lors du Forum PHP 2023 ! Le jeu a été salué par le public, avec plus de 80% des gens y participant au cours de la soirée.
Afin de permettre à la communauté de reproduire le jeu, l'équipe AFUP le met à disposition en open source (sous une licence MIT). Il consiste en un projet symfony tout ce qu’il y a de plus classique avec une base MySQL. Les équipes et les flashs entre les personnes se trouvent dans des tables dédiées. Le document des règles du jeu mises en place pour le Forum PHP 2023 est également disponible. Nous espérons que vous pourrez ainsi vous l'approprier et profiter de cet outil qui a mis une bonne ambiance lors du dernier Forum PHP !
Sachez cependant que le code n'a pas été écrit en le pensant de façon pérenne et/ou réutilisable : le but principal était d’avoir un outil fonctionnel pour la soirée. Nous ne comptons pas non plus y faire de modification ni le maintenir.
Un merci tout particulier à Clever Cloud, chez qui nous avons hébergé ce projet et qui a permis d’en simplifier le déploiement et d’en assurer la scalabilité.
Vous avez des questions ? Contactez le pôle outils de l'AFUP pour tout comprendre du code du jeu. Ce genre de défi vous amuse ? Vous aimeriez participer à développer des outils pour l'AFUP ? Le pôle outils est toujours à la recherche de personnes bénévoles pour contribuer aux projets internes. Contactez-nous !
Voici un cas client concret sur lequel nous avons travaillé au sein du Studio Eleven Labs : la refonte d'une application web corporate et e-commerce pour répondre à de nouvelles problématiques.
Commençons par décrire cette application avant de détailler les nouvelles problématiques, puis de présenter nos solutions pour y répondre.
Ce site inclut deux parties fonctionnellement différentes :
Ces deux parties doivent être complètement intégrées pour que l'utilisateur puisse naviguer sans contrainte entre les différentes pages, surtout pour passer des pages de présentation des produits vers les parcours e-commerce lui permettant de les acheter.
Cela implique non seulement d'avoir des liens entre ces deux types de pages mais aussi d'avoir des composants e-commerce sur les pages éditoriales. Par exemple, sur une page éditoriale présentant une famille de produits, on souhaite avoir un composant e-commerce qui affiche les produits de cette famille, sous forme de carrousel, pour permettre l'ajout direct au panier.
Jusqu'à présent, ce site, incluant ces deux parties différentes, était géré dans une seule application web React, construite de manière complètement personnalisée, ce qui permettait d'intégrer comme nous le souhaitions ces contenus éditoriaux servis par un CMS headless et la plateforme e-commerce, comme représenté sur le schéma ci-dessous :
Mais cette approche mise en place par notre équipe il y a quelques années présentait d'autres problématiques que nous allons voir dans la partie suivante.
Pour ce client, l'ensemble des contenus corporate et produits du site sont rédigés par les équipes marketing qui n'ont aucune connaissance technique mais ont des envies de personnalisations bien particulières.
Dans le backoffice du CMS headless existant, ils ont la possibilité d'éditer des blocs de contenus (aussi appelés 'Slices' dans Prismic CMS) qui sont ensuite affichés sur le front au sein de templates prédéfinis. Ces templates ayant été définis il y a plusieurs années, ils ne répondent plus forcément aux nouveaux besoins et de manière générale ils limitent les éditeurs à leur simple utilisation : les éditeurs ne peuvent pas ajouter de nouveaux templates sans faire appel aux développeurs.
Ainsi ces éditeurs aimeraient pouvoir avoir complète liberté sur la création de templates de pages, avec la possibilité de glisser et déposer leur différents blocs de contenus où bon leur semble.
Retrouvez la version originale de cet article sur cette page.
Symfony Messenger est un composant puissant dans l’écosystème Symfony qui permet de gérer l’envoi et la réception de messages dans une application PHP. Il devient particulièrement essentiel à mesure que votre application évolue et nécessite une gestion efficace des messages. Lorsque votre application atteint une certaine échelle, l’efficacité du traitement des messages devient cruciale pour maintenir des performances élevées. C’est là qu’intervient l’idée d’écrire des workers dans un langage autre que PHP. Cela permet de tirer parti des forces spécifiques de chaque langage pour optimiser le traitement des messages.
De son côté, Go, un langage de programmation que nous affectionnons beaucoup chez Les-Tilleuls.coop, se distingue par sa simplicité, sa rapidité d’exécution et sa gestion efficace des concurrences. Ces caractéristiques en font un choix idéal pour le traitement asynchrone de messages, améliorant ainsi les performances globales de votre application.
Gosumer est un package innovant conçu pour améliorer les performances de votre application en consommant efficacement les messages de Symfony Messenger avec l’aide de code Go. Il s’intègre très facilement avec des technologies telles que PostgreSQL, AMQP et Redis, offrant ainsi aux développeuses et développeurs la possibilité d’optimiser le traitement des messages en toute simplicité.
Vous pouvez retrouver le code source de ce package sur GitHub.
Imaginons que vous ayez une application Go qui doit traiter des messages Symfony Messenger de manière efficace :
Dans cet exemple, nous définissons une structure Message représentant les données des messages entrants, la même structure que celle que vous avez définie côté Symfony (PHP). Ensuite, nous écoutons tous les messages avec la fonction gosumer.listen et les traitons avec processMessage. Une fois le message traité et sans erreurs, il est supprimé de la base de données. En cas d’erreur pendant le traitement, le message n’est pas supprimé et sera de nouveau consommé ultérieurement.
N’hésitez pas à vous rendre sur GitHub pour explorer le projet et le tester ! Notre coopérative, spécialisée dans de nombreux langages de programmation, est à votre disposition pour l’optimisation des performances de vos projets.
Dans cet article, nous allons vous présenter le concept de System Props en illustrant leurs avantages avec des exemples concrets d'utilisation. Nous expliquerons aussi comment les mettre en place sur vos projets, comme nous l'avons fait sur les nôtres au sein du Studio Eleven Labs à travers l'implémentation d'un Design System.
Les System Props, également connues sous le nom de System Properties ou Style Props, sont une liste de propriétés spécialement conçues pour personnaliser instantanément le style de vos composants. Contrairement aux props traditionnelles, ces System Props ajoutent des options supplémentaires pour ajuster le comportement et l'apparence de vos composants. Par exemple, des SpacingSystemProps facilitent la définition rapide de l'espacement de vos éléments, tandis que des ColorSystemProps mettent à votre disposition une palette de couleurs prédéfinie pour modifier les fonds, les couleurs de texte, les bordures, et plus encore. En intégrant ces propriétés dans vos composants, vous économisez du temps en utilisant des raccourcis pratiques pour personnaliser leur style. Cela en fait un atout précieux, notamment lors de la création d'un Design System.
Les System Props offrent plusieurs avantages qui contribuent à améliorer la réutilisabilité, la prévisibilité et la standardisation de votre projet. Voici quelques-uns de ses atouts :
Associées aux Design Tokens, elles permettent de personnaliser uniformément un composant tout en gardant la flexibilité nécessaire pour des ajustements. Cette combinaison garantit la cohérence visuelle et la réactivité, en assurant que les composants respectent les normes tout en s'adaptant aux besoins changeants.
La création de standards de personnalisation réutilisables simplifie la maintenance et garantit que des styles similaires ne sont pas recréés de manière redondante. Selon les besoins de votre projet, il est possible d'avoir des variantes de votre composant sans avoir à créer un nouveau composant à chaque fois. Vous pourriez ainsi utiliser le composant Card plusieurs fois avec des couleurs et des espacements différents.
En économisant du temps sur des personnalisations de style mineures et récurrentes, cela permet de se concentrer sur des aspects plus complexes du développement, tels que la logique métier ou les fonctionnalités avancées.
Dans cet article, nous introduirons la notion de "micro frontend" et ses avantages. Ensuite, nous donnerons des cas d'usage concrets et des exemples d'implémentation basés sur notre expérience réelle au sein du Studio Eleven Labs pour des projets internes et des projets clients. Bonne lecture !
À mesure que les applications web évoluent, elles ont tendance à devenir de plus en plus volumineuses et complexes, parfois obsolètes en raison de l'utilisation de frameworks non maintenus. Ces applications posent de nombreux défis, notamment en matière de maintenance et d'évolutivité. Les mises à jour, l'ajout de nouvelles fonctionnalités et la correction des bugs deviennent de plus en plus compliqués.
C'est là que le concept de micro frontend intervient en tant que solution à cette problématique.
Ce concept a été introduit pour la première fois en novembre 2016 dans le ThoughtWorks Technology Radar. Il a ensuite rencontré un fort succès, et de gros acteurs comme Spotify, Ikea, ou Leroy Merlin (ADEO) en France ont pu utiliser cette approche.
Cette architecture s'inspire des principes des microservices et les transpose dans le domaine du développement frontend. Elle repose sur le découpage de l'application web en composants autonomes, les "micro frontends", responsables de domaines et de fonctions spécifiques, qui communiquent et fonctionnent ensemble pour former une seule application frontend.
Chaque micro frontend peut être développé indépendamment, testé, déployé et évolué sans perturber le reste de l'application. De plus, le micro frontend permet d'utiliser divers langages et frameworks sur chaque brique. Cette modularité et cette indépendance de chaque composant offrent une grande flexibilité aux équipes de développement, qui peuvent se concentrer sur des domaines spécifiques de l'application.
Cependant, il est important de noter que dans la réalité, la mise en place du micro frontend peut être complexe, à la fois d'un point de vue technique et organisationnel :
Ainsi, bien que cette approche soit puissante, son succès dépendra d'une planification minutieuse et de l'expertise technique des équipes.
L'enquête a ouvert le 18 septembre 2023, et ce pour une période de 3 mois. À mi-parcours, en ce début novembre, nous enregistrons déjà 617 réponses : pour comparaison, l'édition 2022 avait recueilli 620 participations en tout et pour tout, et l'édition précédente n'avait atteint le même niveau qu'à la fin novembre 2021. D'excellents chiffres de participation qui augurent des résultats précis et circonstanciés, ce qui ne pourra que renforcer encore la crédibilité du baromètre des salaires comme enquête de référence pour notre secteur.
En ce début novembre, certaines tendances se dessinent concernant le profil des participants et participantes :
Grâce au baromètre, la personne salariée ou en indépendant peut se positionner correctement sur le marché du travail, et la direction d'entreprise y trouve un outil précieux pour gérer la carrière de ses équipes et l'évolution de leur rémunération. Le/la dev peut comparer son salaire avec des profils identiques, et l'entreprise découvre un état des lieux du développement PHP. Cette enquête est utile et ses résultats sont riches en enseignements : participez en quelques minutes et en tout anonymat avant le 18 décembre 2023 !
Je vais vous expliquer aujourd'hui dans cet article un cas concret de mise en place d'une architecture orientée événements réalisé pour l'un de nos clients du Studio Eleven Labs. Vous découvrirez dans cet article, ce qu'est concrètement une architecture orientée événements (ou event driven architecture) et comment la mettre en place. Suivez le guide !
L'architecture orientée événements (Event Driven Architecture) utilise des événements pour déclencher et communiquer entre des services découplés.
Elle est courante dans les applications modernes construites avec des microservices.
Un événement correspond à un changement d'état, ou une mise à jour : commande payée, ou utilisateur créé, par exemple.
Les événements transmettent un état à un instant T (le numéro de transaction, le montant et le numéro de commande).
Les architectures orientées événements comportent trois composants clés : les émetteurs (producers), les transmetteurs (routers) et les consommateurs (consumers).
Un producer publie un événement sur le routeur, qui filtre et transmet les événements aux consumers.
Les services émetteurs et les services consommateurs sont découplés, ce qui leur permet d'être modifiés et déployés de manière indépendante.
Découplage : en découplant vos services, ils ne connaissent que le routeur d'événements, ils ne dépendent pas directement les uns des autres.
Cela signifie que vos services sont interopérables : mais si un service tombe en panne, les autres continueront de fonctionner.
Le découplage simplifie le processus d'ajout, de mise à jour ou de suppression de producers et de consumers, permettant des ajustements rapides pour répondre aux nouveaux besoins.
Cela permet également de mettre en place et de respecter les principes SOLID, plus particulièrement le Single Responsability principle.
La maintenabilité : vous n'avez pas besoin d'écrire du code custom pour gérer les événements, le routeur d'événements filtrera et transmettra automatiquement les événements aux consumers.
Le routeur s'occupe également de la coordination entre les producers et consumers.
Ainsi, chaque consumer possède son scope précis. Différentes équipes peuvent maintenir chaque consumer indépendamment, sur des stacks et timelines différentes.
Immutabilité : une fois créés, les événements ne peuvent pas être modifiés, ils peuvent donc être partagés avec plusieurs services sans risque qu'un service modifie ou supprime des informations que d'autres services consommeraient ensuite.
Envoyez un email avec l'URL du site et du flux à planetephpfr AT afup POINT org
Gestion