11
DEC

FORUM PHP 2013 - Retours sur le premier jour de conférences

Publié le 11/12/13 à 12h28 par Ckimn

Les 21 et 22 novembre 2013 s’est déroulé le Forum PHP 2013. La Ferme du Web était là pour couvrir l’événement. C’est aussi les 2 premiers jours de neige de l’année, qui ont entrainé quelques retards de train, empêchant les lyonnais que nous sommes d’assister aux premières conférences de la journée notamment la keynote d'ouverture et la présentation de PHP 5.5 par Julien Pauli. Voici donc résumé malheureusement incomplet de ce premier jour.

Forum PHP 2013

 

Pourquoi faire simple quand on peut faire compliqué

Slides : https://joind.in/9348

Frédéric Bouchery nous fait pour cette conférence un retour d’experience global sur une décennie de développement PHP, mettant l’accent sur le fait que la complexité dans un projet de développement est un sujet … complexe.

Loin de se limiter au code même, la complexité d’un projet PHP est liée à plusieurs vecteurs.
Tout d’abord l’expression du besoin, que ce soit au niveau de la clarté, de la quantité ou encore de la faisabilité, pas toujours bien étudiée.
Deuxième point clé, la conception. Beaucoup d’architectes expérimentés essayent d’imposer des outils suite à des traumatismes ou au syndrome NIH (Not Invented Here). A l’inverse, PHP étant un langage facilement abordable, on trouve également beaucoup de novices ayant peu de notions des bonnes pratiques.

La solution pour palier la complexité des projets est avant tout de miser sur les compétences de chacun, d’accorder de l’importance aux développeurs (métier souvent mal vu dans pas mal de grandes entreprises / sociétés de services).

On dit que les outils doivent s’adapter aux besoins, mais c’est également vrai dans l’autre sens. Le coût de mise en place d’un nouveau framework vaut-il la peine de l’utiliser ? Dans la plupart des cas, le meilleur framework pour un projet est celui que l’on maitrise déjà. Il faut d’ailleurs se méfier des démos naives (« Regardez comme c’est facile de faire un Hello Word ») d’outils qui s’avèrent au final difficile à manipuler.

Les bonnes pratiques ne sont pas des lois ! Si un projet gagne à les contourner, il faut le faire. Attention tout de même à bien communiquer dessus, expliquer les raisons de ce choix.

Surveiller le code, développer en binôme, former les développeurs, combattre vos automatismes, sont autant de conseils qui vous permettront de « simplifier » la réalisation vos projets PHP (ça marche aussi pour d'autres langages).

 

3 millions d'utilisateurs dans 10 pays : l'histoire technique de BlablaCar

Slides : https://joind.in/9349

3 MILLIONS D'UTILISATEURS DANS 10 PAYS : L'HISTOIRE TECHNIQUE DE BLABLACAR

Retour d'expérience d’Olivier Dolbeau, sur l'évolution technique de BlablaCar désormais présent dans dix pays avec environ cinq millions d’utilisateurs.

BlaBlaCar, anciennement covoiturage.fr est lancé en 2006 dans sa première version sur Mambo (dont Joomla est un fork).

En 2008, commence le développement de la V2. La décision est prise de tout recoder à la main, en PHP pur. Seule la base de données de la première version est gardée. Septembre 2008, la V2 sort en France, puis en Espagne, en Angleterre et en Italie les trois années suivantes.
A ce moment, un million d’utilisateurs utilisent le site tous les mois, mais le code « fait maison » n'est pas scalable (recherche en SQL par exemple), difficile à maintenir, et plus aucun test n’est effectué.

Pour faire évoluer le projet sans laisser la version actuelle, l’équipe décide de s’appuyer sur les composants du framework Symfony 2, utilisables indépendamment. La convention de codage PSR-2 ainsi que des revues de codes sont adoptés.

Pour la fiabilité du code, PHPUnit est choisi pour les tests unitaires, Behat pour les tests fonctionnels et Bamboo pour l’intégration continue.

Une architecture SOA est mise en place, les traitements sont désormais asynchrones.
ElasticSearch a été mis en place pour les recherches et RabbitMQ pour le traitement des événements.
Redis est également utilisé dans la lignée du mouvement NoSQL.

L’accès à la base de données se fait désormais en Java afin de travailler avec plusieurs backends (MySQL, ElasticSearch, CouchBase, …) et de ne plus avoir d’accès PHP direct à cette dernière.

Niveau AdminSys, Chef à été utilisé afin de ne plus faire d’installation manuelle, New Relic est mis en place pour le monitoring.

Afin de rendre l’application plus maintenable, elle a été découpée en plusieurs applications qui réalisent des tâches bien précises tel que l’envoi de mail, de sms, etc, …

En un peu plus de six mois, l’équipe de BlaBlaCar a migré la plupart de ses sites vers la V3.
La V3 est désormais plus rapide que la V2, le code est plus propre et plus fiable.
Et surtout, il est désormais beaucoup plus simple pour un nouveau développeur de comprendre et de se mettre rapidement dans le projet.

 

DIY et happy hacking avec PHP & Raspberry Pi

Slides : https://joind.in/9350

L’écosystème PHP a consacré ces dernières années à montrer que c’est un langage qui a sa place dans un milieu professionnel. Ronan Guilloux prends ici le contre-pied en montrant qu’on peu aussi s’amuser avec PHP si l’on aime la bidouille.

A l’instar de son cousin italien l’Arduino, le Raspberry Pi est un projet universitaire partant du constat que beaucoup d’ingénieurs en informatique manquent de connaissance du hardware. C’est un device de la taille d’une carte de crédit, à faible coût, conçu pour hacker et apprendre.

Le raspberry est vraiment fait pour s’amuser en DIY, il n’est pas scalable et pas prévu pour la prod, c’est vraiment un outil « pour le fun ».

Raspberry Pi peut embarquer un système linux, et pour linux, tout est fichier, et comme PHP peut lire et écrire des fichiers, il peut ainsi contrôler les éléments matériel du Raspberry. Parmi ces éléments, le contrôleur GPIO est une fiche d’entrées/sorties qui va nous permettre de gérer des composants comme des capteurs, des LED, et réaliser ainsi plein de petits projets domotiques.

Malgré une introduction très intéressante, on reste un peu sur notre faim quand aux possibilités présentées du combo PHP/Raspberry Pi. On fait confiance à l’imagination des développeurs dans la salle pour remplir leur GitHub de tas de projets funky.

 

OpenStreetMap for the Web

Slides : https://joind.in/9351

Open Street Map

Derick Rethans enchaine avec une présentation d’OpenStreet Maps, ses possibilités, ses données.

Petite introduction sur la complexité de faire de la cartographie, à commencer par le simple fait de fournir une image plate du globe terrestre. Il existe en effet différents algorithmes, et suivant celui utilisé on peut avoir une différence de plusieurs centaines de mètres sur la position du méridien de Greenwitch.
Il existe également de différences de représentation suivant les pays et cultures, il suffit de regarder la carte du monde australienne pour s’en rendre compte (http://static.lolyard.com/lol/australian-world-map.jpg).

OpenStreet Map ne se place pas comme un concurrent à Google Maps, mais plutôt comme un Wikipedia de la cartographie. Son objectif est de fournir un maximum de données cartographiques de façon libre. Un très grand nombre de ces données n’est d’ailleurs pas accessible via une interface Web.

Il n’y a d’ailleurs pas d’API OpenStreetMap, mais plusieurs projets annexes permettent d’en extraire les données de façon utilisable. Leaflet par exemple est un script JS offrant un rendu visuel des cartes. Nomatim est une API de Geocoding et Reverse Geocoding.

Le contenu d’OpenStreetMap est disponible dans un énorme fichier XML de plus de 33Go (après compression) mais on a la possibilité d’en récupérer facilement une partie spécifique. A l’instar de Wikipedia, n’importe qui peut participer et remplir ce XML, il existe des conventions de tag et il est possible de créer ses propres types de données (On peut créer un type arbre si on veut localiser tous les arbres de la planète). Il existe par exemple un type Pub, très exhaustif à Londre, beaucoup moins à Paris.>

Derick conclut sa présentation en expliquant que même si le mapping de tous les pubs londoniens peut paraitre superflus, cela reste une discipline importante par exemple dans les pays en voie de développement, ou encore dans le cas de catastrophes naturelles (OpensStreetMaps a été très utilisé après le passage du typhon aux Philippines pour localiser les hôpitaux et les routes praticables).

 

Vis ma vie de sysadmin avec des développeurs PHP

Slides : https://joind.in/9353

Après la pause déjeuner, Baptiste Dupain vient nous parler d’admin système dans le cadre de projets PHP, un sujet qu’il connait bien car chez M6 Web ce sont des habitués des retours d’antenne, ces grosses variations dans la charge du serveur, communément appelées « Effet Capital ».

Exemple de charge d'un serveur chez M6

Dans le fameux débat des performances Framework versus PHP pur, Baptise nous explique que les différences sont négligeables, par contre les problèmes sont plus prévisibles avec l’utilisation d’un Framework.

L’automatisation est nécessaire pour que les développeurs puissent publier facilement, mais surtout, ils faut que les rollback de ces publications soient eux aussi automatisés, afin que les développeurs ne soient pas en stress de tout casser à chaque mise en production.

Au niveau organisationnel, les dashboard de reporting doivent être accessibles et compréhensibles par tout le monde.

Lorsqu’il y a un bug critique, l’équipe d’M6 Web s’enferme dans une salle avec une seule personne pour faire la liaison avec l’extérieur.

Au niveau technique, il est important de mettre des timeout dans tout ce qui est appel extérieur au code (que ce soir un webservice, une base SQL ou même un fichier local). Ne jamais enregistrer les logs en bases de donnée, au risque de mourir instantanément en cas de retour d’antenne. Préférer Redis pour les logs.

Une question intéressante a été posée concernant l’utilisation de serveur Cloud comme AWS comme solution aux charges impromptues. D’après Baptise, l’auto-scalling met bien 15 minutes à se mettre en route, ce qui est trop long pour un retour d’antenne.Chez M6Web, ils préfèrent gonfler leur machines virtuelles avant les émissions entrainant généralement un important trafic web.

Chaque dernier vendredi du mois, ils organisent des "Last Friday Talks", sous forme de petites sessions

Grosse déception tout de même, Baptiste ne sais malheureusement pas où Dominique Chapatte achète ses blousons en cuir.

 

Stack: a PHP interface for framework-agnostic code sharing

Slides https://joind.in/9355

Stack

La conférence d’Igor Wiedler sur Stack était assez perturbante, dans le sens où elle ne parlait que très peu de Stack. Le coeur de la présentation a été consacré à un historique (très intéressant) des communications entre process informatiques, pour partir du pipe linux et arriver au composant HttpKernelInterface de symfony.

Pipe Linux - Stack

Stack est un composant indépendant de Symfony, mais utilisant ce composant HttpKernelInterface pour exécuter des action avant ou après le passage de la Request et ou de la Response HTTP, tels que l’authentification, la gestion des sessions …

Stack permet à tout un chacun de construire ses briques et de les partager, et on commence à trovuer des briques intéressantes, par exemple pour gérer Oauth, pour afficher une page de maintenance facilement , …

 

eZ Publish : un CMS pour créer un site orienté contenu en 45 minutes

Slides http://j.mp/ez-from-scratch

Afin de mieux comprendre et de voir les nouvelles possibilités de ce CMS, la conférence se déroule sous forme de live coding en prenant l’exemple d’un site comme celui du forum PHP.

Parmi les nouveauté d’eZ Publish 5, on trouve le support NoSQL ainsi que la gestion du cache.
Cette nouvelle version se base sur plusieurs composants du framework Symfony 2 comme par exemple l'Injection de dépendance, HttpFoundation, HttpKernel, le Routing, … La plupart des bundles existants peuvent être utilisés.

Le core de l’ancienne version a été refactoré entièrement.
Le cœur de la création d’un site avec eZ Publish 5 repose sur trois points important :
- les types de contenu qui peuvent être assimilés à des classes mais qui sont créés directement dans la partie d’administration, pas de code à écrire.
- Le moteur de template Twig est utilisé, du coup l’override de template est beaucoup plus simple. De plus des fonctions propres à eZ Publish ont été ajoutées, par exemple pour afficher le titre d’une conférence dans une vue on fera {{ ez_render_field(content, ‘titre’) }}.

La démonstration a été concluante, eZ Publish est facile en prendre en main, surtout si l’on connait déjà Symfony 2, et la mise en place d’un site orienté contenu peut se faire très rapidement.

Le code de la démo est disponible sur GitHub : (https://github.com/dpobel/ForumPhp2013DemoBundle).

 

En dev exactement comme en prod : créez un environnement de développement devops

Slides https://joind.in/9357

Devops

Benjamin Grandfond vient nous parler de la philosophie Devops, ce mode de fonctionnement tendance qui rapproche le travail des développeurs et des sysadmin.

A l’arrivée de la méthode de gestion de projet agile/Scrum, aujourd’hui largement présente dans les projets informatiques, la notion de démo régulières pour éviter l’effet tunnel d’un projet a été l’un des principaux facteur d’adoption. La philosophie Devops va plus loin en offrant au développeur la possibilité de déployer à chaque fonctionnalité implémentée/bug corrigé.

Cette méthode commence à être adoptée par les grandes entreprises. Amazon, emploie des milliers de développeurs qui ensemble déploient en moyenne 1079 fois par heure ! Chez Etsy (250 « commiters ») on compte 30 déploiements par jour, et tout ingénieur recruté doit déployer le premier jour.

La philosophie Devops à pour objectif de dé-diaboliser la fameuse « Mise en prod ». Mais cela ne se fait pas sans un cadre de travail et des outils permettant au développeur d’être totalement serein et confiant dans ce qu’il fait. Voici quelques conseil de mise en place que nous a donné Benjamin.

 

  • Automatiser complètement les déploiement. Même si l’époque des copies FTP est majoritairement révolue, une commande Git Pull reste sensible à l’erreur humaine. Préférer des outils comme Capistrano ou Fabric.
  • Monitorer en permanence l’application (New Relic, App Dynamics … ). Cela permet de se rendre vite compte d’une explosion d’erreurs 500, mais aussi de connaitre les performances de l’application.
  • Alerter quand il y a un problème (Pingdom, PagerDuty …). Monitorer c’est bien, mais ça ne doit pas faire perdre de temps.
  • Agréger tous les logs, qu’ils soient applicatifs, serveur, BDD, … dans des outils comme Logstash ou Graylog
  • Automatiser les test (Jenkins, TravisCI…). Les tests augmentent la confiance qu’on les développeurs en leur code.
  • Faciliter l’installation. Pas d’application magique dans ce cas, mais il est important de maintenir un Readme contenant les dépendances à installer, les troubleshooting, etc … C’est long mais on y gagne du temps sur le long terme.
  • Normaliser les environnements avec Vagrant, qui permet d’avoir des configurations de machines virtuelles partagées avec tous les développeurs. Vagrant réduit énormément les erreurs liées aux différentes configuration des environnements.
  • Distribuer la configuration du serveur avec Puppet (ou Chef, Saltstack …), compatible avec Vagrant, il permet de configurer de façon automatique des serveurs.
  • Créer des serveurs à la demande, avec Amazon AWS ou OpenStack. Avec ces instances de serveur, un développeurs peut en quelques minutes créer un serveur de staging pour faire tester une fonctionnalité à un client, et détruire le serveur une fois la fonctionnalité validée.
  • Partager les compétences entre Dev et Ops, pour éviter le fameux « Ca marche chez moi »
  • Faire du management visuel. Afficher les graphes relatifs à l’application visible de tous, et de loin. Considérer que la performance est nécessaire pour cocher la case « Fait » d’une fonctionnalité.
  • Etre toujours plus rapide. Itérer, teste, mesurer, améliorer, recommencer.

 

 

Symfony2 CMF - la gestion de contenu bas-niveau

Slides https://joind.in/9359

David Buchmann vient nous parler de Symfony CMF, conçu pour répondre à la problématique des sites de contenu sur mesure, où le client a besoin de pouvoir remplir le site à mesure qu’il est développé.

Avec ce CMF, l’utilisateur à plus de contrôle sur l’application que sur un site Symfony classique. Il a par exemple la main sur le routing. Néamoins, l’une des problématique était de pouvoir le faire sans casser le site.

Plusieurs partie on été revues, comme le routing maintenant dynamique, et fortement lié au Model, amélioré par le composant PHPCR.

Architecture du CMF

Coté front, createjs (complété par du code PHP spécifique) rend le contenu éditable en live. Coté back, Sonata est utilisé pour administrer rapidement le site.

Le stockage est donné est réalisé en NoSQL orienté arborescence, avec gestion du versionning et de l’internationalisation.

Alexis Janvier nous propose un retour d’expérience dans l’implémentation de ce CMF. Pour lui, le contenu sous forme d’arbre permet d’avoir des blocs très facilement éditable et réutilisable. L’efficacité de createjs est un gros point fort.

Le fait d’être basé sur Symfony offre une bonne souplesse d’évolution du site.

Pour lui, les points faibles se situent principalement dans la jeunesse du projet, et donc la difficulté de trouver des développeurs qui maitrisent l’outil.

 

La 2ème journée est à suivre prochainement !

Personne n'a baraguiné de chtite phrase pour le moment !


Ajouter un Commentaire

Pour poster un commentaire, vous devez être identifié. Vous pouvez choisir parmi ces trois méthodes d'identification:

Compte la Ferme du Web

Identifiez-vous
Inscrivez-vous

Compte Facebook

Connexion avec Facebook

Compte Twitter

Connexion avec votre compte twitter
Rechercher sur la Ferme du web