Au coeur du Forum PHP Paris 2012

Chargement de la carte ....

Date(s) et heure(s)
Date(s) - 05/06/2012 - 06/06/2012
8 h 30 min - 17 h 30 min

Localisation
Cité Universitaire Internationale

Categorie


Forum PHP Paris 2012 - Logo du Forum

Absent du calendrier depuis novembre 2010, le Forum PHP Paris est très attendu et courtisé par les nombreux développeurs. Le Forum PHP Paris est qualifié comme le plus grand événement national consacré à la plateforme PHP et aux technologies Web.

Et cette année encore, le programme va en ce sens ! Pour cette édition, les organisateurs ont choisi les thématiques principales suivantes : « la performance, la qualité et les nouveaux usages ».

Note : Vous pouvez retrouver également l’évènement sur Twitter à l’aide du hashtag : #forumphp

Mardi 05 juin 2012

PHP in 2012

Par Rasmus LERDORF

  • PHP = scaling
  • « PHP has 100% market share in the porn industry. And that makes a lot of PHP »
  • Support Vector Machine : http://fr.php.net/svm
  • Découverte ou rappel sur les nouveautés de PHP 5.4
  • Pensez-y : « default charset is UTF-8«  !
  • Future !
    • Improved Unicode
    • Web Trends
    • Language Trends
    • Young Blood
  • N’oubliez pas de contribuer : https://bugs.php.net, https://qa.php.net/ (Note : si vous voyez « windows xp » dans un bug, regardez le suivant)
  • Accès en ligne à un éditeur pour la documentation : https://edit.php.net/
  • Attention si vous utilisez encore PHP < 5.3, pensez à mettre à jour votre version !

Tirer parti de Postgresql en PHP avec Pomm

Par Grégoire HUBERT

  • Découverte de Pomm
  • Attention, Pomm n’est pas un ORM
  • Il dispose d’une structure souple
  • Il est souple …
  • Facilité d’accès aux données dans la partie vue
  • … et puissant : fonctions Window sont indispensables, CTE permet de créer des sous ensembles aliasés et peuvent s’appeler les uns et les autres

Pour en savoir davantage, consultez la présentation de Grégoire : http://pomm.coolkeums.org/phpforum/build/01-introduction.html

Coup de pied dans la LAMP

Par Benjamin CLAY & Damien ALEXANDRE

Pour en savoir davantage, consultez la présentation de Benjamin & Damien : http://ternel.net/forumphp/Slideshow/#/title

Anatomie du test

Par Frédéric HARDY & Ivan ENDERLIN

  • Un test compare théorie et pratique
  • Les tests unitaires valident les briques de base
  • Un framework simplifie la création de l’exécution des tests, et permet en général la génération des rapports et collecte possiblement des métriques
  • Expérimenter pour trouver un framework de tests ! Le bon choix est dès vous le maitrisez et que vous êtes efficace avec !
  • Cependant, attention le changement de framework de tests unitaires peut être délicat =>ces derniers sont souvent incompatibles
  • Le test à postériori génère des API inadaptées
  • TDD : réaliser le test avant de coder => « la barre est rouge » on peut commencer à écrire ! « la barre passe au vert »
  • L’écriture des tests s’arrête lorsque le résultat désiré est obtenu
  • Le test valide aussi le comportement du code en cas d’erreur
  • Couverture du code => produit la qualité des tests
  • En binôme, le ping-pong est l’idéal ! Une personnes code en premier le test, le second la méthode ! Attention par contre, le ping-pong peut être fatiguant.
  • Cela permet de connaître complètement le code source
  • « Mock » => simuler un comportement et améliore la portabilité des tests
  • De plus, le mock permet d’exécuter rapidement un programme : il ne dépend seulement de la machine qui exécute le mock
  • Autrement dit, un mock permet d’accélérer le développement !
  • TDD => réduire les coûts !
  • Test d’intégration valide l’interaction entre les dépendances
  • Le test fonctionnel vérifie que l’objectif du code est atteint
  • Quelques outils
    • Atoum
    • PHPUnit
    • Praspel
    • Behat
    • Jenkins

Pour en savoir davantage, consultez la présentation de Frédéric & Ivan : http://keynote.hoa-project.net/ForumPHP12/

Monitoring applicatif : Pourquoi et comment ?

Par Kenny DITS

  • Pourquoi monitorer ?
    • Être alerter d’une panne
    • Mieux supporter la charge
    • Trouver la ou les RootCause lors d’un incident
  • => vue globale des projets
  • … et donner cette vue aux développeurs
  • Que doit-on monitorer ? Tout !
  • Exemples de métriques : appels aux services applicatifs, gestion des utilisateurs, utilisation et temps SQL, conso CPU, temps d’affichage des pages, erreurs applicatives, utilisation des caches…
  • Comment monitorer ?
  • StatsD => protocole UDP : Fire & Forget ! Attention à bien gérer les paquets UDP à envoyer => possiblement saturation des frontaux
  • Graphite : stocke des métriques dans le temps, et à la demande
  • Graphite, un dashboard complet !
    • Possibilité de faire son propre dashboard
  • Possibilité de sortie des métriques brutes
  • Possibilité de cibler très précisément les sites qui ont été mis à jour, et de savoir très exactement d’où vient l’erreur
  • ==> Beaucoup moins d’anomalies applicatives ressenties
  • MTTD / MMTR beaucoup plus court

Pour en savoir davantage, consultez la présentation de Kenny : À venir …

Anatomie, fonctionnement et performances de PHP

Par Julien PAULI

  • PHP n’est pas responsable de la lenteur, seulement si l’on code mal !
  • PHP de l’intérieur : Machine virtuelle / Gestion auto. de la mémoire
  • Le générateur Re2c est beaucoup plus performant que flex !
  • Analyse lexicale + analyse syntaxique + compilation => exécution
  • la fonction print est plus lent qu’un simple echo puisqu’il y aura besoin de stocker une variable qui contient le retour du print
  • Améliorer les performances
    • Cache d’OPCode permet de stocker l’OPCode en mémoire, et ressert l’OPCode (évite la recompilation)
    • Trouver la partie lente : profiling => Xdebug, XHPROF, …
    • Analyse bas niveau : Callgrind, grpof, …
    • Attention au @ !
  • Alléger empreinte mémoire de Mémoire : désactiver les extensions inutiles
  • Que dois-je faire, pas faire ?
    • Évitez les regex lorsque c’est possible
    • Même avec @ ou error_reporting = 0, le moteur de gestion des erreurs est quand même branché
    • Ne mettez pas de références partout croyant « optimiser » : utilisez des références lorsque c’est utile !
    • Préférez l’utilisation de « fonctions » qui ne sont pas des « fonctions »
  • Il ne sert à rien d’optimiser tout tout le temps ! => restez pragmatique

Pour en savoir davantage, consultez la présentation de Julien : http://www.slideshare.net/jpauli/anatomie-et-performances-de-php

Gestion des dépendances dans un projet PHP

Par Jean-Marc FONTAINE

  • Gestion manuelle
    • Impact sur le dépôt de code
    • Mise à jour parfois difficile
  • Paquets liés à l’OS :
    • + : Ils sont simples à utiliser
    • - : Partager pour tout l’OS
    • - : Peu de paquet PHP disponible (seulement 30 librairies)
    • - : Les versions sont souvent anciennes
    • => généralement aucun intérêt donc !
  • svn:externals avec Subversion
    • Pensez à indiquer le « -r » dans la propriété pour bloquer l’update à une version spécifique
    • + : Facile à déployer
  • Git
    • - : quelques commandes pour y arriver
    • +/- : vous allez récupérer un projet complet et non une branche spécifique
  • Archives PHAR
    • + : simplicité d’emploi => drag & drop !
    • +/- : comme Git, vous allez récupérer un projet complet et non une branche spécifique
    • - : peu de projet distribué sous ce format
    • - : la configuration par défaut de PHP peut poser parfois problème
  • PEAR
    • + : éprouvé / un installeur indépendant et bien vivant !
    • - : qualité des projets inégale
    • Pear Package Manager 
    • Pirium : Héberger votre propre serveur PEAR
  • Composer

    • Projet récent et très actif aujourd’hui
    • 3 outils principaux : Gestionnaire de paquet en ligne de commande (comme pear, apt-get, …), Packagist, toutes les librairies majeures se retrouvent intégrées à ce dernier (adoption croissante, sources variées : Git, SVN, Mercurial, …), Satis, distribution de nos propres paquets (version stable en vue)
    • Côté client : simpliste
    • Côté distributeur : Utilisation du composer.json, possibilité de créer à partir d’un modèle

Pour en savoir davantage, consultez la présentation de Jean-Marc : À venir …

Modélisation des menaces d’une application web : étude de cas

Par Antonio FONTES

Pour en savoir davantage, consultez la présentation d’Antonio : http://www.slideshare.net/starbuck3000/modliser-les-menaces-dune-application-web

Fonctions avancés du driver MySQL natif pour PHP

Par Serge FREZEFOND

  • MySQL est un écosystème très vivant
  • mysqlnd

    • Compression
    • Encryption (protocole crypté)
    • Character Sets
    • Prepared Statements
  • Driver natif dans le cœur de PHP
    • Amélioration de la connexion persistante
    • mysqli_fetch_all()
    • Support SSL (5.3.3)
    • Gestion asynchrone (mysqli_poll)
  • Le driver em>mysqlndest extensible grâce à des extensions (actuellement seulement en C)
    • Catching
    • Load Balancing (mysql_ms)
    • Possibilité de facilement créer une extension
  • Framework ouvert pour le connecteur (API standard) !

Pour en savoir davantage, consultez la présentation de Serge : À venir …

Comment Phing est devenu mon meilleur ami

Par Gerald CROES

Pour en savoir davantage, consultez la présentation de Gerald : http://www.croes.org/gerald/conf/php/paris/2011/comment_phing_est_devenu_mon_meilleur_ami.pdf

Bilan de la première journée

Retrouvez mon retour sur cette premier journée du forum PHP en cliquant sur ce lien : http://www.blog-nouvelles-technologies.fr/14451/mon-retour-sur-le-forum-php-2012-premiere-journee/

Mercredi 06 juin 2012

Varnish pour le développeur PHP

Par Jérôme RENARD

  • Que peut-on mettre en cache ?
    • Tout ce qui est en GET  : Expires (CSS, JS, fichiers binaires, PDF, images, …), Cache-Control, Vary, Age (durée de vie de l’objet cache)
  • En PHP on utilise la méthode header
  • VCL : Varnish Configuration Language : on programme la façon dont on veut mettre en cache les objets => flexibilité
  • La fonction la plus importante : vcl_recv => la première fonction qui est appelé lors de chaque appel (choisir un backend, accès du contrôle, contrôles de sécurité, normalisation des requêtes, …)
    • Exemple : Détecter les user_agent, Réécriture d’URL, dédier des serveurs Web à des traitements spécifiques
  • vcl_fetch: Fonction appelée une fois que le serveur Web a retourné la réponse
    • Exemple : Surcharger les headers HTTP, en revanche impossible d’accéder au contenu HTML
  • Purges : Il est possible de supprimer des éléments du cache, et même depuis PHP !
  •  Test :
    • Curl : curl -i
    • Firebug : Attention sur Firefox le rafraichissement est complexe puisqu’il envoie un max-age:0 ce qui indique que Varnish va ne pas déclencher le cache…
  • Truc & Astuces
    • Regarder si le cache fonctionne : il suffit de vérifier si l’identifiant du cache est égal ou différent (différents user_agent)

Pour en savoir davantage, consultez la présentation de Jérôme : http://jrenard.info/blog/varnish-for-php-developers-the-slides.html

Maitrisez les structures de données 102

Par Patrick ALLAERT

  • Les « Arrays » PHP ne sont pas de vrais tableaux
  • Avantages / Inconvénients : Un objet en PHP 5.4 utilise moins de mémoire qu’un array
  • Tableaux : SplFixedArray ! Utilise beaucoup moins de mémoire => OO
  • SplQueue / SplStack : File FIFO / Pile LIFO => utilise également moins de mémoire que l’array
  • switch plus efficace que in_array
  • spl_object_hash : permet de faire des hashs avec des objets en clés
  • Ensemble avec des bitsets très efficaces mais pas toujours possible
  • Possibilité de remplacer des arguments booléens des fonctions par des bitsets
  • N’utilisez pas array_unique(), array_search() et in_array() pour rechercher dans des ensembles
  • Heap, beaucoup plus rapide que de devoir réordonner un array à chaque itération => uniquement utile si vous avez besoin de quelque-chose de triée
  • Recommandations

    • Utilisez des structures de données appropriées
    • Pensez à la complexité en termes de temps et d’espaces
    • Nommez vos variables

Pour en savoir davantage, consultez la présentation de Patrick : http://www.slideshare.net/patrick.allaert/maitriser-les-structures-de-donnes-php-102-forum-paris-2012

La qualité au-delà du code

Par Jean-Marc FONTAINE

  • 70% du temps consacré à un applicatif l’est dans sa maintenance !
  • Compréhensibilité
    • Documentation : qualité, exhaustive et à jour !
    • Commentaires : clarifier, pas paraphraser, précis et exhaustif ! Essayez de définir une langue unique (Anglais ou Français suivant le type du projet) => PHP CodeSniffer peut vous aider
  • Complexité : Aussi simple que possible, mais pas plus ! >
    • Mise en forme du code : Attention à ne pas perturber la compréhension du fond => choisissez un standard (PHP CodeSniffer peut vous aider)
  • Cohérence
    • Nommage : Logique, cohérent et pertinent pour les variables ! Qualifier les choses. Sur les variables on va plutôt mettre un nom, une fonction un verbe (voir verbe + nom)
    • Documentation : clair
    • Mise en forme du code : Suivre les règles de codage
  • Exhaustivité
    • Application complète ?
    • Éléments temporaires doivent être absent de la version finale
    • Ne jamais commiter un code commenté !!!
    • Interfaces externes ? disponibles ? S’assurer que tout est conforme avec les autres partenaires
    • Données nécessaires présentes ?
  • Concision
    • Documentation : Éviter les longueurs inutiles
    • Librairies externes, utilité ? Moins de possibilité de failles
    • Code mort : Augmente inutilement la taille de l’application (code inutile) Xdebug peut vous aider (ligne grise code pas testé), PHP DCD
    • Code dupliqué : Factorisation => indispensable ! Dans le long terme c’est indispensable (PHP CPD peut vous aider)
  • Portabilité
    • Nouveaux environnements : penser à configurer l’application pour permettre de déployer de nouveaux environnements
    • Dépendances logicielles : Essayez d’avoir un minimum de dépendances (PHP Compat Info => savoir les versions de PHP pour lesquelles votre application doit utiliser) ! Éviter d’être dépendant à une distribution
  • Scalabilité
    • Critères d’acceptation : Connaissez les critères du client
    • Code testable : Code fonctionnel n’est pas forcement un cas testable
    • Injection de dépendance = à creuser !
  • Tests
    • unitaires
    • fonctionnels
    • de charge
    • de sécurité
  • Fiabilité
    • Tolérance aux erreurs : Éviter que l’application ne tombe pas à la première erreur (redondance BDD, cache, …
    • Mode dégradé : Définir en amont les cercles d’importances et trouver des alternatives (feature flipping)
    • Sécurité : pensez-y !
  • Maintenabilité
    • Installation / Mise à jour : simplifiée
    • Logs : Permet de comprendre la vie interne de l’application
    • Débogage : Évitez les @ !

Pour en savoir davantage, consultez la présentation de Jean-Marc : http://www.slideshare.net/JMF/la-qualit-au-del-du-code-forum-php-2012

Automatiser la qualité

Par Damien SEGUY

  • Automation de la qualité du code (bons réflexes au début du projet, suivi continu, fixer des objectifs aux développeurs, …)
  • Comment le valoriser auprès des clients ?
  • Contraintes : données utilisables par les développeurs (listes), bilan lisible aux clients (graphiques)
  • Solutions : outils standards du marché, publier des objectifs , …
  • phploc (pear) : compte les lignes de code=> indique les structures, les fichiers, …
    • Phase de développement : augmentation du nombre de classes
    • Phase de débogage : stabilité des classes
  • PHP_CodeSniffer : ça intéresse personne !
  • Validateur HTML (validateur W3C)
  • Validateur CSS (validateur W3C)
  • Vérifier la compression des images (ImageMagic)
  • Évitez de modifier un framework existant : idée => outil qui va regarder le SVN du fichier md5 et le fichier en local => listing des fichiers ajoutés, modifiés et effacés
  • Performance ab : On peut avoir une dégradation des performances depuis le projet initial ! 0,9s à 1,3s est-ce vraiment acceptable en phase de développement ?
  • Capture d’écran : phantomjs capture de la home page => parfait pour produire aux clients un rendu !
  • phantomjs + jslint => rapport en JSON de la page capturé
  • Fuzzing => tests automatique des formulaires, injection de valeurs au hasard, vérification …
  • Analyse des logs PHP

Pour en savoir davantage, consultez la présentation de Damien : À venir …

Démons en PHP, de inetd à ZeroMQ

Par Amaury BOUCHARD

  • Démon réseau : Apache, Impression, ..
  • Démon applicatif : crontab, x server
  • Avantages : développement rapide, Bonnes performances, réutilisation du code
  • Inconvénients : connaissances requises, Consommation mémoire
  • x-inetd : super-démon => développement rapide, aucune dépendance, isolation des processus
  • multi-processus : rapide mais consomme beaucoup de mémoire
  • mono-processus : gourmand pour le CPU !
  • ZeroMQ: bibliothèque de fonctions réseau, redéfinition des concepts réseau
    • Socket multi-connexion
    • Polling (TCP / ZMQ, STDIN)
    • REQ/REP, PUSH/PULL, PUB/SUB, Load-balancing
    • installation : pear
    • Code serveur : possibilité de mettre n bind()
  • Démons en PHP : faciles et rapides à coder, vraiment performant !

Pour en savoir davantage, consultez la présentation d’Amaury : http://www.slideshare.net/geekcto/dmons-en-php-de-inetd-zeromq

Accès concurrents et scalabilité

Par Jérôme VIEILLEDENT

  • PHP synchrone => processus isolé
  • Appels concurrentiels
    • Conséquences : Accès lent, indisponible
    • Solutions : Pré-génération du cache, CDN, Reverse-proxy
  • Stale Cache : Ne pas écraser le cache qui a été expiré, et on sert aux visiteurs le contenu pendant la génération du nouveau
  • Synchronisation : NFS (pas très copain avec PHP), SAN (cher), rsync (lent), DRBD
  • Cluster PHP : stream wrapper (ajouter propre flux de données)
  • X-SENDFILE : Demande pour service un fichier spécifique
  • Varnish
    • Externe à l’application
    • Basé sur des TTL
    • Tout ne peut pas être caché
    • Gestion des ESI

Pour en savoir davantage, consultez la présentation de Jérôme : http://www.slideshare.net/lolautruche/accs-concurrents-et-scalabilit

TDD avec atoum

Par Frédéric HARDY

  • TDD : méthode itérative
  • atoum
    • Mise sur la simplicité
    • Moderne : PHP 5.3 requis car utilisation des éléments spécifiques à cette version (5.4 en test …)
    • Intuitif
  • Installation : Github / Phar / Composer
  • Exécution en ligne de commande mais également à l’aide d’un autorun (require_once du Phar dans le script PHP du test) ! Un mot « loop » existe évitant ainsi de relancer à chaque fois la ligne de commande
  • Entièrement configurable en PHP
  • Possibilité de taguer les tests afin de choisir ceux que l’on souhaite tester (ex : uniquement tester les méthodes get)
  • Les mock sont générés automatiquement !

Pour en savoir davantage, consultez la présentation de Frédéric : À venir …

Note : Je reviendrais plus en détail sur ce projet !

Bilan de la seconde journée

À venir …