Quand j’ai commencé à travailler chez JoliCode, c’est avec beaucoup d’admiration que je regardais les différents conférenciers de la boîte. Et un jour, avec leurs encouragements, j’ai réalisé que moi aussi, je pouvais être conférencière. Pourquoi pas ? Le syndrôme de l’imposteur était bien présent, et je sais qu’il empêche beaucoup de gens de se lancer, même s’ils aimeraient beaucoup.
Si vous faites partie de ces personnes, voici quelques retours d’expérience et conseils, afin que vous sachiez à quoi vous attendre et puissiez vous préparer !
Chez JoliCode, nous avons un repo GitHub dédié aux idées en général, et notamment aux sujets de conférences. Certains ont parfois des idées mais pas de temps à consacrer à la rédaction d’une conférence ; mais sont toujours prêts à aider.
Nous trouvons aussi pertinent de parfois reprendre un article de notre blog dont le sujet nous intéresse – que nous en soyons l’auteur ou non – et de le transformer en conférence.
Vous pouvez aussi choisir de parler d’une technologie que vous utilisez au quotidien, d’une librairie, d’un composant ou n’importe quel outil qui vous intéresse et partager vos conseils de pro. Les retours d’expérience sont aussi très appréciés et permettent de raconter des erreurs commises en conditions réelles et les solutions trouvées, et ce que vous ou votre équipe en a tiré.
Vous n’êtes pas obligés de donner votre première conférence sur un créneau de 50 minutes devant 800 personnes lors d’une conférence internationale (sauf si vous aimez les défis).
Des groupes Meetup sont présents dans de nombreuses villes en France, et dédiés à de nombreuses technologies. Je pense par exemple à l’antenne parisienne de l’Afup, ou aux pots de l’Afsy. Les équipes d’organisation sont accueillantes et toujours heureuses de recevoir de nouveaux conférenciers ! Ces évènements sont assez réguliers, généralement tous les mois, et les créneaux sont généralement de 20 minutes (mais on en voit parfois jusqu’à 45 minutes) avec un public plus restreint, de 10 à 50 personnes, ou plus selon les groupes. Ces formats plus intimistes peuvent être un bon moyen de mettre le pied à l’étrier.
Une autre option est de proposer un "lightning talk" durant une plus grosse conférence : il s’agit de proposer, pendant la conférence, un sujet qui n’était pas prévu et avec un format très court, de 5 à 10 minutes.
Et puis vous pouvez viser de plus grosses conférences : dans le milieu du PHP je pense notamment aux
Bonne nouvelle pour nos membres adhérant en tant que personne physique : le tarif de cotisation ne change pas !
Le tarif de cotisation était de 30€, TVA non-applicable. Depuis le 1er janvier 2024, le tarif est de 30€TTC, qui inclut une TVA à 20%. L'AFUP fait donc son maximum pour que ce changement dans sa comptabilité impacte au minimum ses membres, qui soutiennent l'association par leur adhésion, en prenant ainsi en charge ce passage à la TVA.
Le changement pour les entreprises sera négligeable également !
La cotisation des personnes morales était jusqu'alors de 150€ TVA non-applicable, permettant l'adhésion de 3 de ses employé•e•s. Depuis le 1er janvier, la cotisation est à 150€HT (soit 180€TTC) et donne toujours accès à l'adhésion de 3 employé•e•s : les entreprises étant en capacité de récupérer la TVA, cette modification est donc insensible pour leurs finances.
Dans notre objectif de professionnalisation de notre fonctionnement, nous avons pris la décision de changer de bureau comptable, afin de mieux accompagner notre trésorerie. Lors de ce changement, il nous a été signalé que les associations étaient soumises à la TVA notamment lorsque leur action entre en concurrence avec des actions similaires portées par des entreprises. Il pouvait alors être entendu que nos événements pouvaient entrer en concurrence avec d'autres événéments techniques portés par des entreprises : nous sommes donc soumis à la TVA.
Ces changements liés à la TVA impactent également nos tarifs de billetterie de nos événements, ainsi que le sponsoring. Nous vous présenterons prochainement ces changements dans deux autres articles dédiés à ces sujets.
L’ExpressionLanguage, ça vous parle ? C’est un composant de Symfony qui existe depuis la version 2.4, autant dire qu’il a de la bouteille. Il est très utile pour quelques cas d’utilisation bien précis : je vais vous montrer quand et comment l’utiliser.
L’ExpressionLanguage permet d’évaluer des expressions dynamiques en fonction d’un contexte. C'est particulièrement utile quand vous avez besoin d’interpréter des règles ou des instructions en utilisant un langage algorithmique léger. Ces dernières peuvent contenir des opérations mathématiques, des comparaisons, des conditions, des fonctions personnalisées, etc. Cela permet d’avoir une application plus flexible et configurable sans avoir à modifier le code source en cas de modification des règles.
L’ExpressionLanguage peut être utilisé dans plusieurs cas :
La liste n’est pas exhaustive, mais dans tous les cas il s’agit de la définition de règles dont l’algorithme doit être simple.
Prenons l’exemple du mapping de données qui va nous suivre pour la suite de l’article.
Pour votre projet, vous avez besoin de mapper les données récupérées dans une API pour les transformer pour remplir un document PDF.
Petite précision sur les deux fonctions permettant d’interpréter les règles :
evaluate()
permet d’évaluer sans mettre en cachecompile()
permet de compiler l’expression, et donc de la mettre en cache
On utilisera que
evaluate()
pour notre besoin.
Personnellement, j’aime utiliser l’ExpressionLanguage avec des règles écrites en YAML.
Dans le constructeur de ma classe DataConverter
, je vais récupérer le mapping YAML que j’ai créé dans /config
et initialiser mon service ExpressionLanguage.
private readonly array $mapping;
private readonly ExpressionLanguage $expressionLanguage;
public function __construct()
{
$this->mapping = Yaml::parseFile('config/mapping/data.
Le typage générique, non seulement c'est super, mais en plus, c'est classe. Dans un monde idéal, voilà à quoi ça ressemblerait en PHP :
class Collection<Type> { /* class definition ... */ }
$users = new Collection<User>();
Cela signifie que notre instance de collection $users
ne peut accepter que des objets de type User
.
Nous aurions alors, notamment grâce à nos IDE intelligents, des informations plus strictes sur le type de données admises par une instance de Collection, sans avoir à simplement le déduire par le nom de la variable. L'analyse statique de notre code serait encore plus performante, ce qui est important en PHP qui ne possède pas d'étape de compilation à proprement parler.
Pour de nombreux langages de programmation, cette étape de compilation permet de soulever des erreurs dans le code, voire de parser ces types génériques.
Alors, pourquoi ces types ne sont-ils pas déjà disponibles dans notre langage préféré ?
Comme dit plus haut, PHP n'est pas un langage que l'on compile pour envoyer ensuite un exécutable sur le serveur. PHP est interprété ; lorsque le serveur reçoit une requête, le code PHP est converti en OPCODE, lui-même ensuite exécuté par une machine virtuelle. Si une erreur s'est glissée dans le code, alors le programme plantera à l'exécution.
Or, c'est donc justement au runtime que se font toutes les assertions de type. Rajouter des étapes de vérification de types génériques serait une atteinte à la performance. Encore une fois, aujourd'hui pour la majorité des langages proposant le typage générique toutes ces assertions de type sont effectuées à la compilation avant que le code ne soit exécuté. La perfomance à l'exécution n'est donc pas un problème comme en PHP.
De plus, on estime que rajouter cette gestion des types génériques dans le coeur de PHP demanderait un effort de refactoring très ambitieux, à tel point que le rapport bénéfice / temps passé à l'implémentation n'en vaudrait pas la peine dans le contexte actuel.
PHP a beaucoup évolué ces derniers temps, mais il reste beaucoup de choses à faire, et le nombre de développeurs qui maintiennent le coeur de PHP n'est pas mirobolant, il y a donc également un problème de ressource.
Enfin, proposer une RFC pour les types génériques n'est pas si simple : il faut se mettre d'accord parmi les nombreuses possibilités d'implémentation envisageables, trouver la meilleure, puis prendre le temps de l'implémenter. Des débats sans fin sont à prévoir.
Pour toutes ces raisons, allant du design même du langage à la complexité d'implémentation, les génériques ne sont pas d'actualité pour le moment.
Conférenciers et conférencières bien connus de notre public, comme Kévin Dunglas, Gina Banyard ou Laura Durieux, mais aussi intervenant·e·s rejoignant nos programmes pour la première fois, comme Yann Jacquot, Alexis Stefanski ou Rachid Hammaoui, vous proposeront un programme bien technique mêlant entre autres microservices, applications PHP conteneurisées, API Platform V3 mais aussi Gitlab, Drupal ou projet legacy lors de l'édition lilloise.
La communauté lyonnaise regorge de speakers talentueux, et l'AFUP Day 2024 Lyon en profitera encore une fois ! Programme 100% lyonnais et garanti en progrès pour vos projets, proposant notamment les conférences de Lætitia Avrot sur PostgreSQL, de Benoit Galati sur l'architecture hexagonale, de Florian Bogey sur le feature flipping ou encore de Florian Merle sur l'injection de dépendances... Consultez l'ensemble du programme de l'édition lyonnaise.
La communauté lorraine en a sous le capot, et ce programme donnant la part-belle à de nombreux speakers de la région va vous le prouver ! François Zaninotto présentera un projet open-source devenu profitable, Tiphaine Perra et Anthony Demangel aborderont le sujet de la cohérence entre différentes interfaces web, Arnaud Lahaxe vous expliquera comment scaller une vieille application PHP sans frozen zone, Emilien Bouard proposera un talk sur l'architecture et pattern en mode SaaS... L'édition nancéienne de l'AFUP Day 2024 va vous surprendre.
L'AFUP Day 2024 Poitiers n'est certainement pas en reste : son programme varié porté par une sélection rafraîchissante vous promet une journée d'apprentissages en tout genre. Tests avec Donovan Bourlard, clean code avec Fred Bouchery, chaînes de caractères avec Marion Hurteau, machine learning avec Iana Iatsun, architecture hexagonale et CQRS avec Arnaud Langlade ou encore magie de la communication avec Julien Deroses : l'édition poitevine de l'AFUP Day 2024, portée par l'AFUP Poitiers, va vous prouver qu'elle n'a rien à envier aux plus grandes villes !
Ces 4 programmes sont marqués par une orientation technique franche, mais aussi par l'arrivée de nouveaux profils au sein des événements AFUP. Ainsi, sur les 38 conférencier.e.s au programme, une vingtaine nous fait le plaisir de nous rejoindre pour la première fois ! Bravo à vous et merci de partager votre savoir avec notre communauté.
La billetterie est passée au tarif de croisière ce matin : la place pour l'AFUP Day 2024, à
La mission donnée à nos membres aujourd'hui est d'indiquer leur présence ou de donner leur pouvoir à un.e autre membre qui les représentera le 10 février.
Lors de l'assemblée générale, il sera demandé à nos membres d'approuver le bilan du bureau 2023-2024, de confirmer à leurs postes les nouveaux membres des différents comités et d'orienter les actions pour l'avenir tout comme les règles qui régissent l'association.
Ces décisions ne pourront être entérinées que si le quorum est atteint : membres AFUP, veuillez indiquer votre présence lors de l'AG (que ce soit en ligne ou en présentiel) ou donnez votre pouvoir à un·e autre membre qui portera votre voix. Vous ne savez pas à qui donner votre pouvoir ? Si vous approuvez l'action du bureau 2023-2024 et de son conseil d'administration, nous vous suggérons de donner votre pouvoir à l'un.e de ses membres.
Deux façons sont proposées à nos membres pour assister à l'AG :
Que nos membres suivent l'AG en présentiel ou en ligne, tous les votes se dérouleront via leur espace membre. Nous leur demandons d'anticiper la situation et de prévoir leur accès à leur compte !
Dès 15h, nos membres seront invités à se connecter à leur espace membre. Il suffira ensuite de cliquer sur le bouton rose "Assemblée Générale" : les sujets soumis à approbation apparaîtront dans cet espace, au fur et à mesure qu'ils seront abordés. Les membres pourront voter "OUI" / "NON" / "ABSTENTION" à chaque point soumis au vote.
Dans mon précédent article, j’ai expliqué ce que sont les SSE et comment on peut les utiliser de manière minimale.
Dans l’exemple que je donnais, le serveur envoyait au client des données qu’il générait de lui-même. Mais dans la vraie vie, le serveur va vouloir envoyer au client des données qui ont été générées par d’autres clients. L’exemple habituel, c’est celui des salons de discussion en temps réel : dès qu’un utilisateur écrit un message, on veut qu’il apparaisse sur les écrans des autres utilisateurs.
Les SSE ne sont donc qu’une composante de la solution technique à mettre en place. Voyons maintenant quelle est l’architecture logicielle globale à mettre en place pour créer un système de chat simple. Bien évidemment, plusieurs solutions sont peuvent être utilisées, nous allons voir l’une d’elles, avec une implémentation en PHP basée sur le framework Temma.
L’interface web va être très simple : une liste de messages (qui affichera pour chaque message le nom de son expéditeur et son contenu textuel), et un formulaire pour envoyer des messages (avec un champ pour le nom d’expéditeur et un champ pour le texte du message).
Les messages envoyés seront retournés aux différents clients par SSE.
La question est de savoir comment les différents contrôleurs qui envoient des SSE sont eux-mêmes avertis qu’il y a de nouveaux messages à transmettre.
Il va falloir mettre en place un système pour transmettre les données. On pourrait regarder du côté des files de messages et des traitements asynchrones (voir un précédent article sur le sujet), mais ce serait une erreur : ce dont on a besoin ici, ce n’est pas de traiter des tâches de manière asynchrone, c’est de transmettre rapidement un message à plusieurs clients en même temps.
Il serait possible de stocker les messages en base de données. Chaque contrôleur pourrait ensuite interroger régulièrement la base pour regarder s’il y a de nouveaux messages. Mais plus il y aurait de clients connectés et plus il y aurait de requêtes sur la base, et ces accès incessants tueraient les performances de la base. Sans compter que ce ne serait plus du temps réel, il y aurait un lag à cause du délai entre deux “polling” sur la base.
Nous allons plutôt partir sur une solution à base de communication réseau entre les contrôleurs et un “broker”, un élément central qui reçoit les messages et les redistribue à tous les contrôleurs.
Les Server-Sent Events (SSE en abrégé) sont une technologie Web servant à ouvrir des connexions unidirectionnelles, du serveur vers le client. C’est une normalisation des techniques qui étaient bricolées par le passé pour faire du « server push » (comme le long polling).
Les SSE sont une alternative intéressante aux websockets. En effet, les websockets dépendent d’un protocole spécifique, et donc d’un serveur particulier. En PHP, on utilise habituellement Ratchet pour cela ; mais même s’il existe pas mal de documentation à ce sujet, cela reste une brique technologique supplémentaire à mettre en œuvre, on n’a pas toujours la possibilité − ou l’envie − de l’utiliser.
Il faut néanmoins comprendre la différence majeure entre les deux : les websockets sont bidirectionnelles, le client et le serveur peuvent échanger entre eux dans les deux sens ; les SSE ne permettent que la communication du serveur vers le client.
Mais en pratique on se rend compte que c’est rarement un vrai problème. Si on prend l’exemple typique de la discussion en ligne, l’important est surtout de recevoir en temps réel les nouveaux messages écrits par les autres utilisateurs ; faire une requête AJAX pour envoyer les messages que l’on écrit n’est pas un souci.
Autre chose à prendre en considération : l’utilisation des SSE fait que les clients gardent une connexion HTTP ouverte avec serveur. Il y a donc autant de connexions que d’utilisateurs connectés simultanément, et si le nombre de connexions supporté par le serveur n’est pas suffisant, votre site ne pourra plus répondre aux requêtes.
Par ailleurs, en cas de déconnexion, le client tentera automatiquement de se reconnecter au serveur, vous n’avez pas à gérer cette fonctionnalité.
Enfin, sachez que les SSE sont supportés par tous les navigateurs modernes, et pour les autres il existe un polyfill.
Pour expliquer le fonctionnement des SSE, on va prendre un exemple très très simple : une page web qui affiche une liste, avec un code Javascript qui se connecte à un canal SSE qui va lui envoyer des messages toutes les 2 secondes, chaque message étant ajouté à la liste.
Pour ce Noël 2023, je vous offre un nouveau site pour télécharger les Extensions PHP pré-compilé pour Windows.
Envoyez un email avec l'URL du site et du flux à planetephpfr AT afup POINT org
Gestion