13 posts taggués « afup »

Par Pascal MARTIN le mercredi 17 septembre 2014 1 commentaire

Je serai présent au Forum PHP 2014 les 23 et 24 octobre à Paris !


Cette année, j’animerai une session de questions/réponses autour de PHP, de son état et de son évolution, à laquelle participeront trois intervenants :

  • Jordi Boggiano (Lead Developer de Composer), que je rencontrerai IRL pour la première fois,
  • Pierre Joye (Core Dev PHP, OSS développeur (curl, gd, etc.), Microsoft OSTC), avec qui j’ai longuement discuté lors du PHP Tour à Lyon en juin,
  • Et Julien Pauli (Release Manager de PHP 5.5 et co-RM de PHP 5.6), que je croise régulièrement depuis maintenant plusieurs années.


Comme d’habitude, la liste des conférences est bien fournie.

Au premier coup d’œil, en voici quelques unes qui attirent mon attention et auxquelles il est probable que j’assiste — soit par pure curiosité, soit parce qu’elles pourraient répondre (ou, au moins, fournir des pistes de solutions) à des problématiques que je rencontre fréquemment :

  • PHP dans les distributions RPM : on dit très souvent que l’adoption des nouvelles versions de PHP est freinée par les distributions orientées entreprises, qui ont tendance à rester sur de vieilles versions dites stables. Pour moi qui suis plutôt Debian, je suis curieux de voir comment les choses évoluent à ce niveau côté Redhat.
  • Cohabitation de PHP et Node au Monde, pourquoi et comment : étant souvent en train de jongler entre plusieurs technos en fonction des projets, je suis curieux de voir comment certains problèmes que je rencontre au quotidien ont pu être approchés chez Le Monde.
  • Composer Best Practices : utilisant composer depuis plusieurs années, j’ai parfois l’impression de le subir… Je me dis donc qu’il pourrait être intéressant d’aller écouter son Lead Dev1 !
  • La mesure, ce n’est pas que pour le devops : pour celle-ci, il s’agit principalement de curiosité ;-). J’ai envie de profiter d’un retour d’XP sur le sujet Lean Startup, pour voir en quoi les différences avec une approche plus traditionnelle pourraient être bénéfiques, à la fois pour l’entreprise où je bosse et pour ses clients.
  • Laisse pas traîner ton log ! : avec une grosse dizaine d’applications qui logguent en vrac vers une quantité parfois effrayante de fichiers, j’ai besoin d’une solution qui me permette de les gérer — et surtout, d’en extraire les données importantes ! J’entends parler de stack ELK depuis un moment, sans avoir jusqu’à présent eu le temps de fouiller… Voici l’occasion d’en apprendre plus ;-)
  • Retour d’expérience : tests fonctionnels chez Maisons du Monde : j’ai plusieurs fois vu des batteries de tests fonctionnels, sans que les équipes aient forcément l’impression que ça marchait bien. Je suis donc curieux de voir comment d’autres ont fait et ce que ça leur apporte.
  • VDM, DevOp malgré moi : d’un site perso à des millions de pages vues par jour, ça a dû faire un bon exercice de scalabilité pour une stack PHP. Là où on commence à avoir des solutions assez classiques, ce n’était pas forcément le cas il y a quelques années — j’ai donc envie de voir comment ça s’est passé ici et de comparer avec les approches prises sur des applications sur lesquelles j’ai bossé.

En complément, je ferai peut-être aussi un tour aux conférences suivantes — pas tellement pour ce qu’elles m’apporteraient d’utilisable tout de suite, mais plus parce que j’ai entendu parler des sujets et que j’aimerais en savoir un peu plus, sans pour autant pouvoir y consacrer un week-end ou deux à fouiller par moi-même :

  • An introduction to the Laravel Framework for PHP : quand il s’agit de frameworks, je suis plus symfony… Mais Laravel fait beaucoup parler de lui ces derniers temps (peut-être plus outre-Atlantique qu’ici) ; j’ai donc envie de voir un peu à quoi ça ressemble.
  • Bringing Sculpin to Life : sans forcément être grand fan de générateurs de sites statiques, j’entends de plus en plus souvent parler de Sculpin. Voici donc aussi l’occasion d’en apprendre plus.

Bien sûr, je n’exclue pas la possibilité de changer d’avis au dernier moment avant de rentrer dans une salle… Et de partir vers une autre. Ça ne serait pas tout à fait la première fois ^^


Des ateliers pratiques d’une demi-journée sont organisés en parallèle des conférences.

Je recommande tout particulièrement celui que Julien Pauli va donner sur le développement d’extensions PHP2 : j’ai assisté il y a plusieurs années à une des premières versions de cet atelier et j’en étais ressorti avec plein d’étoiles dans les yeux. Je n’ai donc aucun doute sur le fait qu’il représentera cette année une demi-journée fort instructive pour ceux qui voudraient se lancer dans le sujet !

Pour vous inscrire, c’est par ici. Faites vite, il n’y a que 15 places — et la moitié sont déjà parties !

En fonction de vos préférences, vous pourrez aussi vouloir jeter un coup d’œil aux autres ateliers :


Nous croiserons-nous à ce Forum PHP ?



  1. Cette conférence pourrait compléter la conférence gestion de dépendances et composer qui a eut lieu à Lyon hier soir, qui parlait plus d’industrialisation (j’ai particulièrement été intéressé par le côté Satis pour ne pas dépendre de github). 

  2. Je n’assisterai très probablement pas moi-même à cet atelier : puisque je connais assez bien le sujet, je préfère laisser la place à quelqu’un qui aura plus de choses à découvrir que moi. 

Par Pascal MARTIN le mardi 22 juillet 2014 1 commentaire

J’ai posté il y a quelques jours les notes que j’ai prises lors des conférences auxquelles j’ai assisté le premier jour du PHPTour 2014 à Lyon.

En plus d’avoir pu échanger avec plein de monde et assister à une quinzaine de présentations, j’ai aussi cette année eu la chance de participer à deux conférences — toutes deux basées sur le travail que j’effectue chez TEA, The Ebook Alternative :

  • « Notre environnement de développement n’est plus un bizutage ! » avec Julien Fusco le premier jour,
  • et « PHP 5.3 → PHP 5.6 : no pain but gain ! » le second.

Dans la suite du premier post publié la semaine dernière, voici, encore dans l’ordre chronologique, mes notes du second jour. Notez qu’il s’agit de mes notes, soumises à mon interprétation de chaque intervention.

Les slides de la quasi-totalité des conférences sont disponibles sur joind.in et les vidéos captées lors de l’événement vont peu à peu être diffusées par l’AFUP sur youtube.


Déploiement continu : Click and deploy !

Sophie BeaupuisRésumé, Slides

Après l’apéro communautaire de la veille, Sophie a eu la difficile mission d’animer une des premières conférences de la seconde journée de ce PHPTour. Elle a commencé par rappeler que le but de Zend est de rendre PHP professionnel et accessible aux entreprises — le sujet de sa conférence s’inscrivant dans cette logique.

Le constat initial est que les développeurs ont tendance à perdre du temps : correction de bugs, mise en place d’environnement, écriture de tests qui ne sont pas utilisés (lancés quand on est les écrit et quasiment plus jamais ensuite). Du point de vue des DSI, l’innovation est freinée par la lenteur technique, les pannes répétées impactent le CA, et les mises en production sont compliquées et échouent trop souvent.

Principes pour améliorer tout ça :

  • Automatiser : pas besoin d’un développeur pour faire quelque chose qu’une machine sait faire,
  • Répéter ⇒ meilleure maîtrise + détection des problèmes au plus tôt,
  • Monitorer : la collecte d’informations permet d’améliorer la qualité.

La seconde partie de la présentation était orientée autour d’une démonstration montrant comment déployer en production après chaque commit git — à travers un processus d’intégration continue sous Jenkins chargé de jouer les tests, de créer un package de déploiement, et de déployer celui-ci (cette dernière étape n’étant pour l’instant lancée qu’après validation par un humain).

Sous Jenkins, plusieurs jobs, qui correspondent chacun à des tâches Phing :

  • Un job qui extrait les sources depuis git,
  • Un job pour créer une archive de déploiement (archive qui pourrait alors être déployée sur un ou plusieurs environnement(s), sur un ou plusieurs serveur(s)),
  • Un job pour les tests en analyse statique,
  • Et un job pour le déploiement en lui-même.

Pour résumer : en principe, tout peut — et doit — être automatisé !

Mon avis : Maîtriser ses déploiements (et ne les effectuer que si les tests passent) me semble indispensable, mais plusieurs discussions que j’ai eu après cette conférence montrent que trop de développeurs n’ont pas encore industrialisé cela. Un rappel utile, donc.


Stop Multiplying by 4: Practical software estimation

Reeves CharlesRésumé, Slides

Charles a introduit sa présentation en indiquant qu’il travaille en freelance — et qu’il doit donc facturer ses clients.

Estimer permet de mesurer l’effort à fournir (et pas uniquement de calculer des deadlines) et les estimations devraient être réalisées par les développeurs, qui sont les propriétaires du code et savent quel effort un développement va nécessiter : les PO et CP ne devraient pas estimer, puisque leurs avis vont être biaisés (par exemple : ils connaissent le budget et vont faire en sorte que ça rentre dedans).

Les développeurs peuvent résoudre des problèmes complexes… Mais estimer est parfois à la limite de l’impossible !

Pour parvenir à estimer, il est indispensable d’avoir des requirements : des spécifications précises peuvent permettre de constituer un élément mesurable. Cette notion de précision dans les spécifications est indispensable. Par exemple, s’il est écrit qu’une donnée doit être “validée”, il est indispensable de savoir en quoi consiste cette validation (valider un format ? valider une donnée en appelant un web-service distant ? valider une adresse mail en envoyant un mail contenant un lien prouvant que le mail a été reçu ?).

Quelques autres exemples de modificateurs qui entraînent des spécifications vagues :

  • rapide, efficace ⇒ à reformuler en, par exemple, “5 secondes”
  • valide, etc, incluant mais pas limité à …
  • maximiser, minimiser, optimiser, au moins
  • simple, facile, user-friendly

Il est possible d’utiliser quelques méthodes pour s’aider lors des estimations :

  • Utilisation de données historiques
    • On sait combien de temps quelque chose prend en général ⇒ on réutilise ce temps
    • La vélocité peut aussi donner une idée
  • Partir sur un prototype ou sur les tests unitaires, pour avoir une idée du travail à effectuer
  • Estimer par un intervalle “entre X et Y” : il vaut mieux être à peu près juste que précisément faux
  • Répéter : ré-estimer le lendemain pour vérifier si on est d’accord avec l’estimation de la veille
  • Test absurde : on commence par des estimations “de folie” et on réduit de plus en plus précisément
  • Méthode Wideband Delphi : 3 chiffres successifs avec discussions entre pour affiner

Pour finir : il faut enlever les gens du problème, penser à l’intérêt des fonctionnalités (et pas rester sur les positions de chacun : on vise à arriver au minimum requis et, ensuite seulement, faire la suite). Ne pas négocier les estimations : les développeurs sont ceux qui savent combien de temps ça prend effectivement et ce qui est le mieux pour le code. Ajouter des développeurs ne résout pas forcément le problème. Et il faut itérer et être honnêtes.

Mon avis : Une passe intéressante sur plusieurs approches possibles pour affiner des estimations et arriver à des chiffres réalistes. L’idée que seuls les développeurs doivent chiffrer (et pas le chef de projet ni le product owner) est intéressante : après tout, c’est nous qui construisons l’application et sommes souvent les mieux placés pour déterminer combien de temps il nous faudra.


Everything you always wanted to know about UTF-8 (but never dared to ask)

Juliette Reinders FolmerRésumé, Slides

Pour introduire sa présentation, Juliette a demandé qui avait déjà utilisé UTF-8 et qui avait déjà eu des problèmes avec. Forcément, tout le monde a levé la main. Mais Unicode ≠ UTF-8 ≠ Internationalisation. Pourquoi penser UTF-8 ? Parce que rien n’est local. Même au sein d’une entreprise, on peut avoir des filiales à l’étranger, des fusions, des noms d’employés étrangers, … Et gérer tout ça, c’est plus facile si c’est fait dès le début !

Il existe plus de 7000 langues vivantes, dont plus de 300 parlées par plus d’un million de personnes (et la Nouvelle Guinée compte à elle seule 837 langues différentes). Parmi les 20 langues les plus utilisées, seulement 7 sont en script latin. Plus de 180 scripts d’écriture sont actuellement utilisés (certains sont utilisés pour plusieurs langues ; certaines langues ont plusieurs systèmes d’écriture ; et certains sont utilisés pour la religion, les cérémonies, ou purement pour le fun (Klingon par exemple)).

Character Set = groupe de caractères → code page → code point. Encoding = part du code page et donne le binaire qui stocke le caractère. Unicode (charset) couvre tout, et peut être représenté par plusieurs encodings (UTF-8, 16, 32).

UTF-8 est le plus simple des encodings Unicode :

  • compatible ASCII
  • taille de caractères variable
  • peut encoder tous les caractères Unicode
  • Défaut pour XML et standard pour HTML
  • peut être reconnu assez facilement, faible risque de confusion
  • tri par tableau d’unsigned ⇒ même ordre que le code point Unicode

Le problème est que tout le monde utilise autre chose par défaut et qu’il faut donc être explicite partout !

  • Ordinateur de l’utilisateur : peu de fontes sont capables de gérer plein de trucs Unicode : il faut travailler avec des fontes compatibles Unicode et ne pas réutiliser les codes ASCII pour d’autres caractères !
  • HTML : il faut déclarer l’encodage : en-têtes HTTP et tout en haut du document HTML (utile si l’utilisateur enregistre la page, par exemple — et n’a donc plus les en-têtes HTTP)
  • CSS : encoding sur la première ligne du fichier, utiliser des fontes compatibles Unicode (avec catch-all sur serif / sans-serif à la fin)
  • FTP : transférer les fichiers en binaire !
  • Réception de données depuis le client : utiliser accept-charset="UTF-8" pour les formulaires

Au niveau de PHP, les choses se sont un peu améliorées en PHP 5.3 (arrivée de l’extension Intl) ; et sont de mieux en mieux à chaque version (intl gagne en fonctionnalités). Toutefois, peu de fonctions de base sont en Unicode. Attention aux fonctions qui impactent le processus entier, comme setlocale() ou gettext().

Pour ce qui est de la base de données MySQL, travailler avec des versions raisonnablement récentes (>= 4.1), utiliser set names pour paramétrer l’encodage au niveau de la connexion, tout mettre en UTF-8 au niveau de la configuration du serveur.

Mon avis : Plusieurs rappels utiles ; j’ai bien accroché sur la partie sur les fontes (avec exemples en images sur les slides, illustrant différents types de problèmes), qui est assez éloignée de ce sur quoi je me concentre habituellement. Dommage que la présentation ait été trop longue pour tenir sur la durée allouée et que la fin ait donc été coupée.


L’asynchrone en PHP, c’est possible !

Olivier DolbeauRésumé, Slides

Pour introduire cette conférence, Olivier est parti d’un exemple assez classique : une fonctionnalité “mot de passe oublié” qui envoie un mail à l’utilisateur. Envoyer un e-mail est long et il est dommage de bloquer un processus serveur Web pour effectuer cette manipulation. A la place, il est plus intéressant d’immédiatement afficher un message à l’utilisateur indiquant que le mail est parti, tout en envoyant le mail un peu plus tard, en arrière-plan.

Le principe alors utilisé serait le suivant :

Serveur Web -> Broker --> worker (consumer)
               (AMQP) \-> worker (consumer)
                       \> worker (consumer)

Le broker est chargé de recevoir des messages et de les distribuer aux workers capables de les gérer. Olivier travaille avec RabbitMQ, mais le principe est sensiblement le même pour les différentes alternatives. Au niveau de PHP, l’extension php_amqp est utilisée.

Les workers sont des processus qui doivent tourner en permanence. Il faut donc éviter les Fatal Errors et/ou Exceptions non catchées (par contre, au développeur de logguer ce qui doit l’être, bien sûr). Pour éviter d’éventuels problèmes de fuites mémoire, les workers sont fréquemment redémarrés (après plusieurs minutes ou X messages traités) ; même chose lorsqu’il faut les mettre à jour : ils sont proprement coupés avant d’être mis à jour puis redémarrés.

Sur un projet symfony, il n’est pas forcément utile / recommandé de charger tout le framework pour un worker : chaque worker doit faire son job et rien de plus, ne serait-ce que pour limiter la consommation mémoire.

Quelques points supplémentaires :

  • Utilisation de supervisord pour construire des pools de workers
  • Attention aux outils / bibliothèques qui conservent plein de données en mémoire (comme le logguer finger crossed de Monolog qui, par défaut, garde tous les logs en mémoire)
  • En cas d’échec d’un worker lors du traitement d’un message, ré-essayer plus tard (30 secondes, puis 3 minutes, … de plus en plus longtemps)

Mon avis : J’étais déjà convaincu que sortir des traitements du serveur web pour les effectuer en arrière-plan était une approche viable en PHP (je le fais depuis des années en me basant généralement sur gearman, avec des pools de workers gérés par supervisord). Il était intéressant de voir une solution basée sur une autre brique technique, ainsi que sa mise en pratique sur des applications à forte charge, qui montre ouvertement que c’est possible.


PHP 5.3 → PHP 5.6 : no pain but gain !

Pascal MARTINRésumé, Slides

Pour cette seconde conférence que je donnais au PHPTour, j’ai commencé par rappeler les principales nouveautés qu’avaient apportés PHP 5.3, 5.4 et 5.5 — pour en arriver au fait que PHP 5.3 représente un peu plus de la moitié des installations de PHP 5, alors que PHP 5.5 n’en n’est qu’à environ 2%. D’ailleurs, PHP 5.3 est la version de PHP la plus utilisée actuellement, alors qu’elle va atteindre sa fin de vie cet été ! J’ai aussi passé rapidement en revue quelques-unes de nouveautés de PHP 5.6 (La conférence de Rasmus en ouverture des deux jours du PHPTour entrant plus en détails, avec exemples de code à l’appui, je suis passé rapidement sur cette partie).

En seconde partie, je suis entré dans le vif du sujet, en dressant un tour d’horizon des problèmes potentiels que l’on pouvait rencontrer pendant une montée de version de PHP. J’ai enchaîné avec plusieurs approches que l’on peut utiliser pour faciliter celle-ci, en insistant sur la mise en place d’analyse statique de code (avec PHPCompatibility, qui est un standard pour PHP_CodeSniffer).

Enfin, j’ai donné quelques conseils, basés sur les migrations successives que j’ai eu l’occasion de réaliser ces dernières années — nous sommes d’ailleurs, chez TEA, The Ebook Alternative, en train de finaliser une migration PHP 5.3 → 5.5 et pensons enchaîner sur PHP 5.5 → 5.6 en seconde moitié d’année.

Comme pour la conférence donnée avec Julien Fusco en fin du premier jour, je n’ai pas pris de note pendant la présentation (j’étais un peu occupé ;-) ), mais je vous encourage vivement à parcourir mes slides, en pensant à consulter les notes du présentateur : avant de diffuser ceux-ci, j’ai veillé à rendre ces notes aussi complètes que possibles, afin que les slides apportent un maximum d’informations à ceux qui n’auraient pas pu assister à la présentation.

Mon avis : Je me suis plusieurs fois plongé dans le sujet ces dernières années et il me tient tout particulièrement à cœur (ne serait-ce que parce que je souhaite pouvoir travailler avec les fonctionnalités des versions récentes de PHP — pour moi qui suis régulièrement l’évolution du langage, rester coincé sur une vieille version est parfois quelque peu frustrant ^^ ). J’ai donc beaucoup apprécié pouvoir donner cette seconde présentation lors de ce PHPTour.


Prévenez la dette technique de vos projets

Bastien JaillotRésumé, Slides

Pour cette dernière conférence de la journée, Bastien a commencé par rappeler que la dette technique est un emprunt réalisé sur la qualité en vue d’avancer plus rapidement, tout en sachant qu’on sera par la suite pénalisé. La dette technique est inévitable et n’est pas forcément une mauvaise chose, puisqu’elle permet de sortir des produits plus rapidement, en faisant passer les besoins fonctionnels avant les besoins techniques — il s’agit alors d’un problème plus humain que technique.

Il existe quatre types différents de dette technique :

  • celle causée par un développeur qui découvre une techno,
  • la dette SSII, que l’on trouve quand les développeurs sont payés au nombre de tickets traités,
  • la prise de raccourcis qu’on paiera plus tard,
  • et celle qu’entraîne un développeur qui n’a plus envie de toucher à une vieille techno, au bout de quelques années.

La dette technique a un impact majeur : pour un développeur, elle n’est pas vraiment attirante. Et là où un développeur peut quitter le projet, pour l’entreprise, ce n’est pas bon sur le long terme. En complément, on développe trop de choses : il faut savoir dire “non” et se concentrer sur l’essentiel (après tout, le meilleur code, c’est celui qui n’a pas besoin d’être écrit !).

Au niveau de la prise de décision, les gens ne se comprennent pas vraiment ⇒ on ajoute des intermédiaires et des dépendances à des gens “qui ne veulent pas”. On finit par penser plus à nos intérêts qu’à autre chose. Pour aider, la culture d’entreprise joue : elle pousse à vouloir faire bien (en échange, on fait des trucs fun). Il est important d’expliquer les contraintes et de comprendre les enjeux fonctionnels, sans hésiter à montrer la dette technique.

Pour ce qui est de la gestion du temps, penser qu’on ne peut pas avoir rapide + pas cher + bonne qualité. Le projet peut avancer, mais qu’en est-il de la dette technique et de la frustration des développeurs ? Prévoir la mise en production bien avant la fin de la collaboration et/ou du contrat, effectuer une release le plus tôt possible et les features suivantes arriveront après (et peut-être qu’on réalisera qu’elles n’étaient en fait pas utiles !).

En contre-partie, ne pas oublier que le beau code n’est pas utile s’il ne répond pas à un besoin, que le développeur est un créatif qui a son ego, et que la (sur-)qualité peut aussi être une source importante de dette technique (est-il vraiment utile de mettre en place plein d’outils… pour générer une page statique ?). Une ré-écriture de 0, même si l’idée est plaisante (le 1er jour) est quelque chose de dangereux, aussi !

Pour conclure : l’ennemi de la dette technique, c’est le pragmatisme. A nous de faire le maximum pour qu’on ne nous impose pas de rajouter trop de dette !

Mon avis : Une passe sympathique sur plusieurs causes de dette technique, ainsi qu’un rappel indispensable sur le fait qu’elle est parfois utile, mais aussi que c’est notre boulot de savoir la gérer (à la fois en l’acceptant lorsque c’est judicieux, mais aussi en sachant la rembourser lorsqu’on en a l’occasion).


Lightning talks

Cette seconde journée du PHPTour s’est terminée par 6 lightning talks :


En keynote de cloture, Mikaël Randy et Maxime Teneur ont indiqué que le Forum PHP aurait lieu les 23 et 24 octobre 2014 à Paris — le CFP est d’ailleurs ouvert !

Pour ma part, je suis reparti de ces deux jours épuisé (deux jours à me coucher tard après le diner des conférenciers et l’apéro communautaire, deux conférences préparées et présentées, deux journées sans faire de pause) et en pleine forme (plein de gens rencontrés, beaucoup d’échanges avec les autres conférenciers et avec le public, de nombreuses conférences intéressantes, et plein de bonnes idées en tête !). Vivement la prochaine fois !

Et pour finir, puisque c’est sans aucun doute eux qui ont fait le plus dur : merci à toute l’équipe d’orga qui a fait un super boulot !


Par Pascal MARTIN le mercredi 16 juillet 2014 2 commentaires

Le PHPTour organisé par l’AFUP a cette année eu lieu les 23 et 24 juin, à la Manufacture des Tabacs à Lyon.

Ces deux jours ont été pour moi l’occasion de revoir plein de monde, de mettre des têtes sur des noms et de rencontrer plusieurs personnes avec qui j’échangeais depuis des années sans jamais les avoir vues, ainsi que d’assister à une quinzaine de conférences.

J’ai aussi, cette année, eu l’occasion de participer à deux conférences — toutes deux basées sur le travail que j’effectue chez TEA, The Ebook Alternative :

  • « Notre environnement de développement n’est plus un bizutage ! » le premier jour,
  • et « PHP 5.3 → PHP 5.6 : no pain but gain ! » le second.

J’ai tenté de prendre quelques notes lors de chaque conférence à laquelle j’ai assisté. Voici donc ci-dessous, dans l’ordre chronologique, celles du premier jour. Notez qu’il s’agit de mes notes, soumises à mon interprétation de chaque conférence.

Les slides de la quasi-totalité des conférences sont disponibles sur joind.in et les vidéos captées lors de l’événement vont peu à peu être diffusées par l’AFUP sur youtube.


Coding and Dreaming - PHP in 2014

Rasmus LerdorfRésumé, Slides, Vidéo

Les deux jours de conférences se sont ouverts sur une présentation de Rasmus Lerdorf, qui a commencé par un historique de PHP, avant d’enchainer sur les nouveautés de PHP 5.5 et 5.6, pour conclure sur le fait que ce qui compte dans nos métiers, ce n’est pas tant les applications que nous développons, mais plutôt ce qu’elles apportent.

Au départ, pour développer pour le Web, on écrivait des CGI en C, puis en Perl. Dès 1994, Rasmus aurait voulu quelque chose de plus sympa à utiliser — et PHP a commencé comme ça (avec de la syntaxe alternative pour les structures de contrôles, d’ailleurs). Avoir une syntaxe “HTML + balises” était une bonne approche, puisque ceux qui faisaient du web étaient plus souvent des documentalistes que des développeurs.

En 1996, PHP permettait déjà plein de choses. Et dès 1997, Rasmus a reconnu que PHP était trop large pour un seul mainteneur — il a donc dit à ceux qui ralaient à propos de bugs qu’ils pouvaient se débrouiller pour les corriger (même si ça n’a pas été facile pour lui, qui n’aurait des fois “pas codé ça comme ça”).

Pour qu’un langage fonctionne, c’est son écosystème qui compte : Perl et mod_perl n’étaient pas adapté à de l’hébergement mutualisé et ne satisfaisait donc pas les hébergeurs. PHP, par contre, chargé uniquement du contenu, était plus adapté, avec des gestions de timeouts, de limite mémoire, … La stack LAMP et le mod_php d’Apache, qui évite de forker à chaque requête, a fortement aidé à répondre au “problème du web”.

Des points que l’on considère pour certains comme horribles aujourd’hui ont aussi aidé PHP à démarrer et à se démocratiser :

  • register_globals, par exemple, rendait plus facile l’apprentissage du langage par les débutants,
  • la syntaxe à base de $var pour les variables était plus facile à parser,
  • les magic_quotes étaient pratiques pour la base de données utilisée par Rasmus,
  • et les inconsistances d’API s’expliquent par le fait que PHP est souvent un simple wrapper autour d’une bibliothèque C, en mappant 1-1 les paramètres.

La présentation a continué avec les principales nouveautés apportées l’an dernier par PHP 5.5 et celles qu’apportera bientôt PHP 5.6 — je ne les passe pas en revue ici. Par contre, PHP 5.5 est aujourd’hui la version minimale que nous devrions utiliser !

En dernière partie, Rasmus a expliqué que “Coding”, finalement, n’est pas si important, et qu’il faut un juste milieu avec “Dreaming” : ce qui compte, quand le monde change, c’est lorsque les hackers s’y mettent et que l’on combine des idées avec leur réalisation.

Il a rappelé qu’il venait d’un endroit où tout le monde se fout d’Internet et que ce que l’on fait ne compte pas pour la majorité du monde : nos applications pourraient disparaitre, ça ne serait pas grave. Ce qui compte, c’est de fournir plus de valeur que nous n’en extrayons.

Mon avis : J’avais déjà vu cette conférence (j’avais regardé la vidéo enregistrée à Mexico, où Rasmus avait donné une version plus longue de cette présentation), mais il est malgré tout toujours agréable d’entendre parler de l’histoire de PHP (ça aide à remettre des choses en perspective), et encore plus de la bouche de son créateur.


Extract Till You Drop

Mathias VerraesRésumé, Slides, Vidéo

Pour cette conférence, Mathias a réalisé une session de live-coding où il est parti d’un bout de code un peu legacy pour le modifier à travers plusieurs itérations visant à le rendre plus lisible, plus clair, moins couplé et plus maintenable.

En regardant la portion initiale de code, on pouvait notamment remarquer :

  • des variables peu claires et mal nommées,
  • des conditions imbriquées,
  • des exceptions correspondant à des règles métier,
  • ou encore, des méthodes dont le nom ne reflétait pas le comportement.

Les différentes étapes du refactoring ont globalement été les suivantes :

  • ajout de tests de non-régression avec mocks sur les interfaces,
  • coups d’oeil réguliers au code-coverage (pas dans le sens “métrique de vanité”, mais pour avoir une idée de ce qui est testé et pour vérifier que l’on test ce que l’on pensait qu’on testerait),
  • dés-imbrication des conditions pour diminuer le nombre de niveaux d’indentation,
  • suppression de variables temporaires en in-linant des appels de méthodes,
  • sortie de tests de validité et de levées d’exceptions vers des sous méthodes du genre guardAgainstDuplicate(),
  • déplacement de vérifications directement vers la couche métier (ainsi, accéder directement aux objets métier sans passer par la couche service ne permet plus de sauter de validation)

Au final, il en est ressorti :

  • une méthode principale beaucoup plus courte,
  • des tests correspondant aux règles métier,
  • et du code nettement plus lisible !

Mon avis : une passe sur des principes que l’on commence à connaître, mais que l’on prend trop rarement le temps de mettre en pratique à fond. J’ai réalisé pendant la session de live-coding que j’avais encore pas mal de raccourcis-clavier de PhpStorm à maîtriser ^^


PHP, au cœur de la stratégie Open Source de Microsoft ?

Pierre Joye, Benjamin Moulès, Frederic Aatz — Résumé, Vidéo

En première partie de cette conférence, Frederic a expliqué que l’organisation au sein de Microsoft changeait au niveau de toute la boite et que l’entreprise avait des personnes dans tous les pays pour expliquer ce que fait Microsoft et établir des ponts et passerelles. Le sponsoring du PHPTour à Lyon ou le partenariat avec SensioLabs autour de symfony et d’Azure s’inscrivent dans cette démarche.

Après cela, Pierre a présenté quelques statistiques en rapport avec PHP et a rappelé quel est le cycle de releases suivi par PHP ces dernières années. Le mécanisme d’évolution de PHP a été amélioré ces dernières années (via les RFC, les votes qui sont fait dessus, et une certaine diminution des batailles sur internals@), même s’il est encore parfois difficile de contribuer à cette communauté qui ne semble pas toujours assez ouverte.

PHP a accueilli ces derniers temps bon nombre de nouveaux contributeurs et Pierre souhaiterait voir dans le top 10 uniquement des “nouveaux”. Ajoutons que “participer à PHP” ne veut pas nécessairement dire “coder en C” : le projet a besoin de volontaires pour maintenir la documentation, écrire des tests, … En somme : contribuez !

Microsoft participe activement au développement de projets open-source, dont le noyau Linux, nodejs, samba, Vagrant ou Docker. Pour PHP, en plus de développeurs participant au projet, une plate-forme d’intégration sur des tests autour de PHP a été mise en place (sur une cinquantaine de grosses applications, une fois par jour, en modes NTS et TS).

Enfin, Benjamin et Stéphane ont parlé de déploiement de symfony sur la plate-forme Azure de Microsoft, notamment facilitée par un bundle permettant de travailler directement en ligne de commandes, ainsi que par le biais des fichiers .user.ini ajoutés à PHP >= 5.3.

Mon avis : Microsoft s’ouvre à PHP et aux logiciels libres, de plus en plus depuis quelques années, et c’est une très bonne chose pour la communauté — qui essaye elle-aussi d’avancer petit à petit, en structurant ses processus et se rendant plus accessible.


Comment grapher et visualiser vos data ?

Grégoire PineauRésumé, Slides, Vidéo

Pour la conférence suivante, Grégoire nous a parlé de Graphite et des outils qui vont autour.

Pourquoi grapher les données ? Par exemple, pour voir si une fonctionnalité est utilisée, ou pour voir si une page est lente alors qu’elle est appelée fréquemment.

Quoi grapher ? Les comportements utilisateurs (pages les plus vues, temps de chargements, … ), santé de l’infrastructure (charge, espace disque, … ), mais aussi et surtout : données métier. En fait, tout pourrait être graphé.

Quand on dit “Graphite”, on pense fréquemment à une pile composée de plusieurs éléments :

  • Application (PHP par exemple) qui envoi des données à Carbon
  • Carbon : démon (protocole texte) qui reçoit les données
  • Whisper : base de données stockant celles-ci via des fichiers de taille constante (+ rapide) avec agrégation des anciennes valeurs
  • Graphite : exploitation des time-series via un affichage de graphes brut ou au travers de fonctions (moyenne, différences, … )

Carbon ne garde, sur un intervalle, que la dernière donnée reçue. On positionne donc devant un démon statsd (en node.js, qui écoute en UDP — donc sans blocage, quitte à perdre quelques paquets) chargé de regrouper les données reçues sur cet intervalle pour n’avoir en sortie qu’une seule valeur. Attention à la configuration : les fenêtres de sampling doivent être identiques du côté de statsd et du côté de Carbon, et l’agrégation par défaut de Carbon (moyenne) n’est pas toujours la bonne et est donc parfois à configurer.

La pile devient donc : Application → statsd → Carbon → Whisper → Graphite

Pour les applications en PHP, il existe 36 bibliothèques, dont celle développée par m6web ou celle de berbelei. Pour symfony, il existe un MetricsBundle qui permet de se brancher sur plein de listeners.

Quelques astuces et points à retenir :

  • Nommage : on peut utiliser des * dans les noms des métriques. Pour les compteurs, utiliser des verbes au passé, comme machin.created
  • Graphite fait beaucoup d’I/O ; il est recommandé de l’installer sur un SSD
  • La configuration est écrite à la création des fichiers et ne peut plus être modifiée par la suite

Pour la visualisation des données, le moteur Graphite est directement utilisable mais moche. Il existe plein de moteurs de dashboard, comme Grafana (basé sur Kibana, tout en HTML/JS/CSS, avec auto-refresh, time-range, query-builder, …).

Mon avis : Tout au long de la conférence, je me suis dit “ça, il faut qu’on le fasse ; et ça aussi ; et ça aussi !” — et depuis, j’ai commencé à brancher quelques métriques ici et là dans nos applications qui, aujourd’hui, ne donnent pas assez d’informations sur ce qu’elles font et comment elles sont utilisées.


REST dans le monde Symfony

William DurandRésumé, Slides, Vidéo

William a commencé par présenter les quatre niveaux du Richardon Maturity Model, en vue de nous montrer que ce que nous faisons généralement n’est pas tellement du REST, mais plus du “HTTP++” :

  • Niveau 0 : HTTP est un tunnel ; cela ressemble à du RPC
  • Niveau 1 : notion d’identité d’objet, les ressources distinctes étant identifiées par leur URI
  • Niveau 2 : introduction des verbes HTTP et des codes de statut, méthodes safes (cachables) et idempotentes (résultat indépendant du nombre d’exécutions).
  • Niveau 3 : découverte de services par le biais de relations et de liens. Négociation de contenus (type, contenu, encodage, langue), Hypermedia (Atom, HAL), HATEOAS (permet de trouver son chemin dans une API)

Il a ensuite passé en revue un ensemble de bundle permettant de créer des API REST (ou “HTTP++”) avec symfony :

  • JMSSerializer : graphes d’objets, documents XML ou JSON
  • FOSRestBundle : boite à outils de services et listeners
  • BazingaHateoasBundle : permet d’atteindre le niveau 3, on définit les relations via des annotations
  • TemplatedUriBundle : niveau 3 aussi ; RFC 6570 : URItemplated
  • NelmioApiDocBundle : génération de documents pour les API à partir de la phpdoc, support d’autres bundles connus
  • LiipCacheControlBundle : ajout de fonctionnalités liées au cache, header Cache-Control et aide pour les proxies — rendu obsolète par FOSHttpCacheBundle
  • Pour OAuth (qui est un protocole d’autorisation et pas d’identification / d’authentification) : HWIOAuthBundle et FOSOAuthServerBundle et BazingaOAuthServerBundle

Mon avis : Ne bossant que peu avec symfony en ce moment et ne mettant pas en place tellement d’API REST, j’ai un peu déconnecté pendant la seconde partie de cette présentation.


Transition agile 4 real @ meetic

Nicolas Kalmanovitz, Thomas DiavetRésumé, Slides, Vidéo

Nicolas et Thomas ont commencé par dresser un rapide historique de l’entreprise : en 2001, 20 personnes (avec du PHP/MySQL “codé en prod”), équipe réactive, les choses marchent pas mal. 2005 entrée en bourse, 2006 rachat de la société. 2011 : 400 personnes dont 100 à la DSI (qui ne produit pas plus que lorsqu’ils étaient 10), équipes qui se critiquent les unes les autres, les choses sont compliquées.

Conséquence : en 2011, volonté de rompre avec le cycle en V, de passer à des méthodes agiles en vue d’améliorer la communication et la productivité. En parallèle, beaucoup de dette technique, plate-forme en PHP 4 procédural, monolithique, “pas le temps d’upgrader”, avec des outils maison, des équipes en silos, … Le “modèle startup” ne fonctionne pas avec 400 personnes.

Sur le gros de la présentation, Thomas et Nicolas ont raconté comment Meetic a effectué cette transition :

  • Tout d’abord, aller vers l’agilité, en scrum (donc : sprints, rituels, démos, …) : approche structurée, simple, efficace. Facile à apprendre. Rupture (et volonté de changer) par rapport à l’ancienne méthode.
  • Equipe scrum : Product Owner (duo composé d’un chef de projet et d’un chef de produit), Scrum Master, développeurs, intégrateur, testeur (pour sécuriser le livrable dès le développement) : tout le monde ensemble.
  • Mise en place de 8 équipes scrum et d’une équipe kanban. Approche “on livre peu, mais on livre souvent”
  • Premiers changements : git + branches (au lieu de SVN et cris à travers l’open-space pour dire qui “lockait” un fichier) et tests manuels mutualisés (sur paquet de release, toutes les deux semaines)

Avec ces premiers pas, en 2012, les équipes ont gagné en autonomie, communication, priorisation et qualité ; l’entreprise a retrouvé la croissance.

Toutefois, il reste encore pas mal de problèmes :

  • de l’accompagnement est requis pour aller au bout de la méthode,
  • l’idée de “double-PO” entraine un chevauchement des responsabilités,
  • la méthode agile n’a été mise en place qu’à la R&D, entrainant un fossé qui grandit par rapport aux autres équipes (et finalement, on retombe dans les anciens problèmes),
  • le time to market n’est pas optimal : il est difficile d’itérer, les releases sont longues à tester et chaque problème impacte la release entière.

Pour aller plus loin, passage à Kanban, et pas qu’à la R&D mais à toute la DSI :

  • marche mieux sur les équipes qui étaient déjà agile (en scrum) que sur celles qui ne l’étaient pas du tout,
  • affichage de boards un peu partout dans toutes les équipes ⇒ visibilité de ce qui est en cours,
  • limite de WIP : flux plus rapide et plus fort, pour améliorer le time to market,
  • FIFO (simple, pas de priorisation) + métriques + gestion des points de contention ⇒ livraison continue

Résultat : temps de cycle de dev et de QA divisé par deux, releases plus fréquentes avec moins de bugs (livraisons plus petites).

Et pour aller jusqu’au bout :

  • tout le monde ensemble dans la même salle, avec livraisons quotidiennes, outils collaboratifs et sessions de tests collaboratifs,
  • intervention d’un consultant extérieur : même constat que l’équipe avait déjà fait. Equipes par fonctionnalités, projets pilotes et mesure des résultats, formation et conduite au changement.

Au final, et j’ai beaucoup aimé la conclusion : les équipes travaillent ensemble, en ayant retrouvé ce qui était bien dans la startup il y a dix ans. En bottom-up, c’est possible. Et sinon… La boîte disparait !

Mon avis : Un retour d’expérience intéressant — j’ai reconnu pas mal de points cités, pour les avoir déjà vécu — avec de bonnes pistes d’améliorations, pour peu que chacun ait envie d’avancer (et c’est souvent le cas).


Take a walk on the OPS side

Baptiste DUPAINRésumé, Slides, Vidéo

Baptiste a commencé par indiquer que m6web regroupe de l’ordre de 30 sites, incluant TV online et portails thématiques. Son métier est de faire passer le code de localhost à la production — sur des sites à forte charge.

La première partie de la conférence avait pour but de présenter quelques outils permettant de débugger une application PHP, en production, sans utiliser PHP lui-même :

  • sysdig : enregistre tout ce que fait le système et donc, ce que fait PHP
    • pour enregistrer sysdig -w php.scap (relecture avec -r pour appliquer des filtres)
    • permet aussi d’analyser des requêtes (sql, redis, … ) en live : sysdig -A proc.name=php5-fpm and evt.buffer contains SELECT
  • curl pour regarder les en-têtes HTTP (leurs applications retournent pas mal d’informations sous cette forme) : curl -Iv monsite.com -s | sort

Il est important de surveiller et mesurer ce qu’il se passe sur la plate-forme, typiquement à l’aide d’outils comme statsd et graphite (chez m6web : de l’ordre de 610,000 métriques et plus de 100 dashboard), ou encore :

  • collectd : récupère tout ce qui est système
  • sensu : monitoring distribué, où chaque serveur effectue ses vérifications et les expose à un démon central
  • seyren : alerting basé sur graphite
  • mayday : contextualisation des alertes
  • Oculus (à l’étude) : corrélation entre les problèmes (par exemple : “il y a des erreurs 500 ET un serveur MySQL est tombé”)
  • riemann (à l’étude) : alertes ou actions, en fonction de règles

Il faut aussi donner du sens à ses logs, qui contiennent plein d’informations qui peuvent permettre de comprendre un incident ou de vérifier des comportements :

  • Problématiques de formats : CSV, JSON, pipe-separated, binaire, … + compression dans certains cas
  • Traitement : synchrone ? asynchrone ?
  • Outils de traitement de logs (450 à 750 million de lignes par jour chez m6web. Environ 50% des informations sont utilisées. 40 informations par ligne de log nginx) :
    • Logs HTTP : roadster
    • PHP : scripts Python
    • MySQL : Anemometer
    • Firewall / syslog : Rsyslog central
    • grokdebug.herokuapp.com : pour parser des logs (genre stacktraces PHP) avec des regex
    • En cours d’étude : stack ELK
  • Outillage :
    • ElasticSearch + logstash + Kibana ⇒ pour prendre les logs, les indexer et les présenter
    • R pour les statistiques. En entrée : logs, SQL, CSV, … Quelques exemples d’usage : filtrer les appels lents, statistiques des pays les moins cachés.

En dernière partie, Baptiste a présenté quelques outils permettant de tester son application (si on passe sur Capital, on prend un gros pic de charge) :

  • Tout d’abord, trois types de tests :
    • test de charge = “est-ce que ça tient avec plein d’utilisateurs ?”
    • test de stress = “voir jusqu’où tient l’infra”
    • test de perfs = “qu’est-ce qui est acceptable pour l’expérience utilisateur ?”
  • Quelques outils :
    • Jmeter / gatling, Siege / Wrk, Tsung
    • gor : réplique du traffic (de production par exemple) en temps réel (vers un environnement de test par exemple)

Mon avis : Pas mal d’outils intéressants pour aller plus loin que PHP en lui-même. J’ai découvert sysdig pendant cette conférence et je l’ai déjà utilisé depuis pour trouver la cause d’un problème incompréhensible (sur une appli en JAVA, closed-source, peu documentée et sans log) ^^


Notre environnement de développement n’est plus un bizutage !

Pascal MARTIN, Julien FUSCORésumé, Slides

Pour terminer cette première journée du PHPTour, Julien et moi avons présenté les améliorations qui ont été apportées ces derniers mois à la mise en place de postes de développement chez TEA, The Ebook Alternative, où nous travaillons tous les deux.

Nous sommes parti du constat difficile à accepter que, lorsque j’ai rejoint TEA il y a un peu moins d’un an, il m’a fallu environ deux semaines pour installer mon poste. Nous avons ensuite expliqué comment nous utilisons désormais des outils comme Vagrant, Chef, ou Stow pour rendre cette installation plus facile et beaucoup plus rapide.

Nous avons au final gagné en maitrise de nos environnements, ceux-ci sont plus à jour (ce qui est indispensable si l’on souhaite, par exemple, monter en version de PHP), nous avons plus de liberté d’expérimenter, et l’intégration d’un nouvel arrivant à notre équipe n’est plus perçue comme un bizutage !

Je n’ai pas pris de note pendant la conférence (j’étais un peu occupé ;-) ), mais je vous encourage vivement à parcourir nos slides, en pensant à consulter les notes du présentateur : avant de diffuser ceux-ci, nous avons veillé à rendre ces notes aussi complètes que possibles, afin que les slides apportent un maximum d’informations à ceux qui n’auraient pas pu assister à notre présentation.

Mon avis : Ma première conférence en duo et la première fois que je présentais plus un retour d’expérience qu’un sujet vraiment technique — une expérience plutôt sympa pour moi, que je renouvellerai probablement dans le futur !


Mes notes du second jour de ce PHPTour 2014 devraient être publiées dans quelques jours — le temps de les mettre au propre ;-)


Par Pascal MARTIN le mercredi 25 juin 2014 1 commentaire

Les slides que Julien Fusco et moi avons utilisés comme support pour notre conférence « Notre env. de dév. n’est plus un bizutage ! » au PHPTour 2014 à Lyon sont disponibles en ligne : Notre env. de dév. n’est plus un bizutage !.

Pour ceux qui voudraient plus d’informations que les slides en eux-même, nous avons noté quelques points dans les notes du présentateur, accessibles via la touche s.

Et si vous étiez présent au PHPTour et que vous avez assisté à cette conférence, nous sommes bien entendu preneur de tout retour — vous pouvez retrouver toutes les conférences, dont celle-ci, sur joind.in.

Par Pascal MARTIN le mercredi 25 juin 2014 2 commentaires

Les slides que j’ai utilisés comme support pour ma conférence « PHP 5.3 → 5.6 : No pain but gain ! » au PHPTour 2014 à Lyon sont disponibles en ligne : PHP 5.3 → 5.6 : No pain but gain !.

Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s.

Et si vous étiez présent au PHPTour et que vous avez assisté à cette conférence, je suis bien entendu preneur de tout retour — vous pouvez retrouver toutes les conférences, dont celle-ci, sur joind.in.

Par Pascal MARTIN le lundi 2 juin 2014 1 commentaire

Lors de l’ApéroPHP lyonnais du 27 mai 2014, j’ai eu l’occasion de donner une présentation de HHVM et Hack. Après quelques mots sur le moteur d’exécution HHVM, j’ai passé en revue une partie des points que le langage Hack apporte par rapport à PHP.

Les slides que j’ai utilisés comme support sont disponibles en ligne1 : HHVM et Hack : slides de ma présentation à l’AperoPHP lyonnais du 27 mai.


Puisque le sujet a été abordé après la présentation, je profite de ce post pour rappeler que je publie tous les mois, sur ce blog, une synthèse de la mailing-list internals@ — la mailing-list des développeurs de PHP ; les articles correspondant sont taggés @internals.


Et, aussi pour rappel : toutes les fin de mois2, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.



  1. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s

  2. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

Par Pascal MARTIN le lundi 30 septembre 2013

Toutes les fin de mois1, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

L’apéro du 25 septembre 2013 était un peu particulier, puisqu’il a réuni des développeurs PHP et des développeurs Python, un développeur de chacune des deux communautés présentant son langage aux développeurs de l’autre communauté.

Les slides que j’ai utilisés comme support pour présenter PHP aux développeurs Python sont disponibles en ligne2 : Présentation de PHP, pour des développeurs Python.

Les slides utilisés par Arthur Vuillard, qui a fait la présentation inverse, sont eux aussi disponibles : Python pour les dévs PHP.



  1. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

  2. Pour ceux qui n’ont pas pu assister à la présentation en live et voudraient plus d’informations que les slides en eux-même, j’ai noté plein de choses dans les notes du présentateur, accessibles via la touche [s]

Par Pascal MARTIN le lundi 29 juillet 2013

Toutes les fin de mois1, l’antenne lyonnaise de l’AFUP organise un ApéroPHP ; je cite la description qu’en fait Adrien Gallou, qui s’en occupe depuis quelques mois :

Les apéros PHP sont ouverts à tous, quelque soit le niveau,
le but est de rencontrer d’autres développeurs PHP de la région lyonnaise,
de boire un verre ensemble, de discuter de tout et de rien,
en fonction des envies de tout le monde.

Lors de l’Apéro du 24 juillet 2013, j’ai eu l’occasion de donner une rapide présentation, où j’ai parlé des nouveautés apportées par PHP 5.5, la dernière version stable de notre langage de prédilection, qui a été publiée fin juin.

Les slides que j’ai utilisés comme support sont disponibles en ligne2 : PHP 5.5 : slides de ma présentation à l’AperoPHP lyonnais du 24 juillet.


Et puisque j’ai eu plusieurs discussions à ce sujet après la présentation :

  • Je publie tous les mois, sur ce blog, une synthèse de la mailing-list internals@ — la mailing-list des développeurs de PHP ; les articles correspondant sont taggés @internals.
  • Les articles de mon blog sont bien sûr disponibles via un flux RSS ;-)



  1. En théorie, les ApéroPHP lyonnais ont lieu le 29 de chaque mois. En pratique, la date varie un peu, mais c’est généralement vers la fin du mois. Rendez-vous sur aperophp.net, ou suivez l’AFUP Lyon sur Twitter : @AFUP_lyon

  2. Pour ceux qui voudraient plus d’informations que les slides en eux-même, j’ai noté quelques points dans les notes du présentateur, accessibles via la touche s. Vous pouvez aussi vous reporter à la série d’articles que j’ai rédigée sur PHP 5.5 il y a quelques mois : j’y ai couvert, en détails, la plus grosse partie des nouveautés présentées lors de cet AperoPHP. 

Par Pascal MARTIN le mardi 16 novembre 2010 6 commentaires

Mardi 9 et mercredi 10 novembre avait lieu, à Paris, le Forum PHP 2010, organisé par l’AFUP.

J’y ai donné une conférence intitulée “Ligne de commande sous Linux : effrayant ? Non : indispensable !”.
Voici les slides que j’ai utilisé comme support lors de cette présentation :


Vous pouvez aussi directement télécharger le fichier PDF correspondant.

Bonne lecture !

Les slides des autres conférences ont été mis en ligne sur le site de l’AFUP.
Et vous pouvez poster des commentaires sur l’ensemble des conférences sur Joind.in.


Et, au passage, le photos de ces deux journées ont commencé à apparaitre sur flickr : Photos du groupe Forum PHP.


Par Pascal MARTIN le lundi 13 septembre 2010

Cette année, le Forum PHP organisé par l’AFUP aura lieu les 9 et 10 novembre à la Cité des Sciences et de l’Industrie à Paris.

Il sera organisé autour de quatre thèmes directeurs :

  • PHP de A à Z : Débuter en PHP, Réussir un projet avec PHP, Choisir son hébergement
  • Les outils basés sur PHP : Drupal , outils de e-commerce et de business, CRM et ERP
  • L’industrialisation de PHP : Performances, tests, authentification centralisée, frameworks
  • Technologies autour de PHP : HTML 5, référencement…


Cette année, j’animerai une session intitulée Ligne de commande sous Linux : effrayant ? Non : indispensable !, qui s’inscrit dans le premier de ces quatre thèmes.

Pour résumer en quelques mots : nos applications PHP sont souvent déployées sur des serveurs Linux — et nous savons tous que, un jour ou l’autre, nous aurons besoin de nous connecter à ce serveur…
Alors, pourquoi ne pas anticiper, et découvrir quelques commandes qui vous seront forcément utiles un jour ou l’autre ?


Pour les conférences auxquelles je pense assister, je n’ai pas encore fait un choix définitif, mais une première pré-selectionne me donne au moins celles-ci :

Enfin, bref, encore une fois, un lot de conférences intéressantes — et le choix final va encore être difficile, dans certains cas ;-)


Et, pour finir, voici quelques liens susceptibles d’intéresser ceux qui hésitent encore :

Je suppose que cela sera l’occasion de croiser certains d’entre vous ; à bientôt, donc !