Webaaz

L'année 2021 aura été l'occasion pour moi de retourner chez un éditeur de logiciel, poste que j'affectionne particulièrement pour la démarche produit plus qualitative, et la proximité avec les utilisateurs.

Cette expérience, riche en apprentissages (environnement multilingue, infra AWS, formation de référent qualité web avec opquast...) aura été de courte durée, toutes les start-ups ne deviennent pas des licornes...

Je suis donc sur le marché de l'emploi, et immédiatement disponible pour une nouvelle aventure !

Si vous recherchez quelqu'un pour piloter de la technique, pour gérer une équipe, ou pour faire mûrir l'assurance qualité web de votre projet, sur Nantes ou en remote, je suis à votre écoute !

Devops, la démarche vous parle, c’est à la mode. Mais savez-vous communiquer entre devs front et devs back ? Comprenez-vous les enjeux du travail de vos collègues ? Quand vous créez une url, pensez-vous aux impacts SEO ? Quand vous nommez un fichier PDF, savez-vous que cela aura un impact sur l’expérience utilisateur ? Le dev back n’est pas cantonné à traiter des sujets techniques, il a son mot à dire sur le résultat final et pour cela il doit connaître les impacts de son travail et savoir communiquer avec les devs front, le Product-Owner ou le client.En pratique, les développeurs et équipes front, les product owners et équipes SEO sont de plus en souvent amenés à travailler avec des checklists de bonnes pratiques et notamment celle proposée par Opquast, disponible sous licence creative Commons BY-SA. Cette checklist très orientée vers les utilisateurs et donc plutôt vers les équipes front peut à tort être réservée à ces équipes. Pourtant, de nombreuses règles orientées front ou expérience utilisateur devraient directement être gérées par des développeurs back. À travers des exemples issus de thématiques évidemment orientées back comme la sécurité ou les performances, nous montrerons que non seulement les bonnes pratiques front sont directement utiles aux développeurs back, mais qu’elles ont un impact direct sur la qualité de leur travail quotidien, et que cela fait aussi partie de leur responsabilité et de la qualité de leur travail.

De la découverte...

J'ai commencé dans le web un peu par hasard, en autodidacte. J'ai bossé pour des assos, je me suis formé dans mon coin mais pas seul.

À l'époque j'ai eu la chance de tomber sur les bonnes ressources sur le net, et j'ai vite laissé tombé Dreamweaver4 pour me concentrer sur l’essence même du code. C'est à cette époque là que j'ai découvert Openweb puis de blog en blog, j'ai rempli mes flux RSS de tout un tas de gens bien...

Il a bien fallu se former pour mettre en forme toutes connaissances et pouvoir débuter « professionnellement ». Première expérience avec un maître de stage top, ça motive, et j'apprends plein de choses. Des projets perso en parallèle, la découverte des frameworks PHP, une autre révélation... J'enchaîne quelques belles expériences autour de PHP, des sites e-commerce, les premières missions de conseil autour de PHP, et je découvre l'AFUP, premier Forum PHP en 2007, et tant d'autres ensuite... Je découvre cet échange permanent rendu possible par une asso au top, des bénévoles motivés, l'idéal pour progresser et découvrir de nouveaux sujet comme la webperf par exemple.

Clever Age décide à ce moment d'ouvrir une agence à Nantes, je les connais de réputation et je postule directement, hors de question de passer à côté. Ce sera un festival de belles rencontres, des gens passionnés qui font les choses bien, qui partagent, qui ont le goût des choses bien faîtes. Quand on est bien entouré on progresse vite. C'est à ce moment là que je participe à l'élaboration de la v2 du référentiel Opquast, un travail passionnant qui oblige à réfléchir beaucoup et remettre en cause sa façon de travailler. je donne aussi mes premières formations, et je découvre Paris-Web, ou j'aide bénévolement pendant un an. Je donne ma première conférence au PHPTour à Lille et j'enchaîne avec la création de l'antenne de Nantaise de l'AFUP, ou je croise plein de bénévoles passionnés avec qui nous allons organiser un premier puis un second PHPTour, avec des conférenciers internationaux et 250 personnes. Puis pour compléter cette aventure je deviens trésorier de l'AFUP pendant 2/3 ans. Avec un bureau efficace nous menons de beaux projets pour aider l'asso à se développer encore et faire toujours plus pour partager les connaissances et faire vivre PHP. Je garde aujourd'hui de très bon souvenirs de ce passage chez Clever Age, et toujours beaucoup de contacts qui comptent.

À l'expérience...

Un petit passage en start-up et ensuite retour chez un éditeur, Jack in the box, une très belle aventure avec une super équipe; c'est plus facile d'avoir une super équipe quand on la choisit soit-même ;-). Un beau projet fait dans les règles de l'art, du test, de la doc, de l'automatisation, des bonnes pratiques, de l'humain... L'occasion de faire bosser des gens que j'apprécie en presta et qui vont nous apporter énormément. Au final, un produit dont je suis fier, une équipe dont je suis fier, une très belle expérience enrichissante en tous points.

Un nouveau passage en ESN chez Conserto; dont j'étais client, et que je connaissais déjà un peu, avec l'envie de revenir à de l'expertise, de la formation, du conseil, d'aider à mettre en place des process, d'intervenir de façons transversale sur les projets PHP, d'aider les alternants à se former... Ce sera l'occasion de monter en compétences sur la partie DevOps, sur de très beaux projets et de travailler avec des gens biens dans une ambiance apaisée et féerique (oui c’est possible), pleine de bonne humeur avec un encadrement au top qui a su gérer la crise COVID parfaitement. Du temps pour se former et progresser et l'occasion de passer enfin ma certification Opquast et de donner à nouveau quelques meetups et conférences seul ou en duo.

Et maintenant ?

Aujourd'hui c'est une nouvelle aventure qui se profile pour le mois de janvier. Retour chez un éditeur, une start-up avec un produit dédié à la gestion de communauté. Ça a du sens avec mes expériences et mes envies. je rejoins l'équipe de Wenity pour piloter la partie technique, et apporter mon savoir-faire sur un projet centré sur l'utilisateur.

L'opportunité de faire enfin du JS, et toujours du PHP, de mettre en pratique ma vision globale sur les métiers du web, de mettre en œuvre ce que j'ai appris durant toutes ces années en côtoyant tous ces experts web !

Merci à tous ceux avec qui je travaille depuis 20 ans, collègues, développeurs, clients, experts, bénévoles, recruteurs, stagiaires, prestataires... Merci pour tous vos retours, vos messages d’encouragement, vos remerciements, c'est grâce à ces rencontres, et aux opportunités que j'ai pu saisir si tous les jours je fais ce métier merveilleux qui me passionne toujours autant. Merci à tous ceux prêts à prendre du temps pour échanger, progresser, s'entraider, c'est le web que j'aime, c'est grâce à vous que nous ferons un web de meilleure qualité !

Alors surtout, n’hésitez pas à me solliciter, je serais très heureux d’échanger avec vous, de parler du web ou de mille autres choses !

Et puis si vous faites du PHP et/ou du JS, et que vous avez envie de travailler avec moi, dites le moi !

PHP c’est vous, et vous pouvez contribuer !

Quand nous posons la question « qui contribue à PHP ? » lors des évènements que nous organisons ou auxquels nous participons, nous n’obtenons que très peu de réponses. Est-ce parce que peu d’entre nous savent ou aiment coder en C ? Pourtant, participer et contribuer ne se limite pas à des lignes de code, loin de là !

Avez-vous trouvé l’éditeur en ligne de la documentation de PHP ? Avez-vous soumis des patchs à composer et symfony ou même à magento et wordpress, qui sont open-source et attendent vos contributions ? Avez-vous testé les versions alpha de PHP 8 ? Voyez-vous comment organiser un Apéro PHP ou un meetup ? Ou même un AFUP Day ou le Forum PHP ? Savez-vous que l’AFUP a besoin de vous ? Que c’est une association qui est là pour vous aider et ce qu’elle peut vous apporter ?

Avec mille et une façons de contribuer, venez faire un tour d’horizon de modes de contribution que vous n’aviez peut-être pas encore envisagés, ou dont vous vous étiez dit qu’ils n’étaient pas pour vous. Vous verrez que, vous aussi, vous pouvez contribuer à PHP ;-)

Your job is not to write code!

Ne faites surtout pas ce que vous demande votre client ! C'est un brin provocateur mais si le client est roi, vous êtes à son service pour l'écouter ! Vous n'êtes pas juste un robot payé à la ligne pour écrire du code. Vos qualités humaines, vos conseils et le bon sens vous permettent d'aller plus loin et de rendre votre travail plus épanouissant et plus gratifiant.

Voyons comment rendre la meilleure copie possible pour votre client en l'accompagnant, de l'expression du besoin jusqu'au développement.

Faisons un état des lieux complet sur le support des différentes version de Symfony. Vous y verrez plus clair sur les enjeux réels pour VOTRE projet.

Introduction

Un projet web est un projet vivant. C’est une évidence pour certains, mais on trouve énormément de projets sans aucun suivi, sur lesquels intervenir sans tout refondre est compliqué, long et coûteux.

Une fois la phase de réalisation terminée, la mise en production ne signe pas la fin du projet. C’est juste une étape dans la vie du logiciel. Commence alors une phase de maintenance.

C’est une étape cruciale, qui se doit d’être proactive pour identifier :

les risques (bugs, fin de maintenance, failles de sécurité…)

les opportunités (nouvelles fonctionnalités, amélioration des performances…)

On peut ainsi se prémunir des risques les plus évidents, préparer les développements à venir, planifier les mises à jour dans une période plus creuse et maintenir son projet à jour tout en maîtrisant son budget.

Voyons le cas courant d’un projet PHP développé avec le framework Symfony.

J’ai un nouveau projet à développer

Pour un nouveau projet, plusieurs possibilités s’offrent à vous, en fonction de votre contexte, l’équipe technique saura vous guider vers l’un de ces choix.

symfony 4.4 LTS

C’est la version LTS (Long-Term Support), son support est garanti jusqu’en novembre 2022, et les bugs de sécurité pendant encore un an de plus.

Ce choix apporte de la stabilité sur une période confortable, si vous vous lancez dans un petit projet, qui n’évoluera pas et dont la durée de vie tient dans les délais indiqués, cela peut se justifier.

Le nombre de librairies disponibles sur Packagist est très important, en revanche le risque est de ne plus avoir de mises à jour.

symfony 5.x

Dans la plupart des cas, votre projet est vivant et amené à évoluer. Partez sur la 5.x, c’est le meilleur choix possible. Sa durée de vie étant plus courte, vous vous engagez à faire évoluer les versions au fur et à mesure de leurs sorties. Vous êtes gagnants ! En effet, votre projet est à jour, sécurisé, et les développeurs peuvent utiliser les toutes dernières fonctionnalités du framework.

Point positif, une migration coûte moins cher si elle est faite au fil de l’eau plutôt que dans l’urgence.

Par contre, partir sur une version trop récente, c’est prendre le risque de ne pas avoir encore toutes les librairies disponibles.

La solution réside dans une juste analyse des besoins, et un suivi des versions dès que possible. Sur beaucoup de projets, une mise à jour est d’ailleurs possible avant même la mise en production. Adaptez-vous !

J’ai un projet à maintenir

Nous rencontrons encore aujourd’hui trop de projets qui ne sont pas mis à jour, parfois depuis plus de 10 ans ! Fatalement, un jour, un nouveau besoin, ou des problèmes de performance impliquent des développements longs et fastidieux, qui auraient pû être simplifiés avec un projet maintenu.

Imaginez un commerce qui ne referait jamais sa devanture, et construirait un nouveau magasin quand l’ancien ne ferait plus l’affaire. C’est tout de même plus simple et moins coûteux de mettre un coup de peinture. Une migration c’est juste un coup de jeune !

symfony 3.x

Si votre projet est encore en version 3 il est grand temps de penser à faire quelque chose. Notons que symfony 3.4 est encore maintenu, mais pas les releases précédentes. Il vous reste donc au plus quelques mois avant de prendre du retard, et puis pensez à toutes les fonctionnalités que vous n’avez pas à votre disposition : https://blog.sensiolabs.com/fr/2018/01/09/symfony-4-migration-projet-sensiolabs/

symfony 4.x

Avec un projet en symfony 4, il est important d’avoir bien en tête le calendrier. Si vous êtes encore en 4.1 ou 4.2, même sanction, vous prenez des risques ! Passez d’urgence en 4.4 minimum ! Si vous êtes en 4.3, vous avez encore quelques mois de répit, mais ne tardez pas.

Symfony 4.4, finalement c’est déjà presque symfony 5, vous avez les mêmes fonctionnalités mais avec le code déprécié des versions 4. En suivant les versions au fur et à mesure, les marches sont plus petites à chaque fois.

Évidemment, la migration en symfony 5 sera plus simple depuis la 4. Migrer depuis la version 3 implique de mettre à niveau vers la version 4 puis vers la version 5. Rien d’impossible à priori, mais un travail plus conséquent à prévoir. Votre code à déjà quelques années et les guidelines ou les process ont évolué positivement depuis.

De plus, nombre de bundles de symfony 3 n’existent plus vous mettant dans l’obligation d’une réécriture bien plus complexe avec des changements de librairies.

Un code migré n’est pas synonyme d’un projet parfaitement maîtrisé, la qualité ne se mesure pas juste avec le numéro de version ! Mais connaissez-vous les étapes d’une migration ?

Comment se passe une migration ?

Quelle que soit la migration, (PHP, Framework, librairies) les étapes sont similaires.

Lecture du changelog

C’est le point de départ. Le changelog contient toutes les informations sur la nouvelle version. Il précise les nouveautés, mais ce qui nous intéresse particulièrement, ce sont les méthode dépréciées. C’est à dire tout ce qui est obsolète et ne doit plus être utilisé. Cela peut être un appel de méthode, ou une façon de faire, d’organiser ou d’architecturer son code.

Analyse du projet / étude d’impact

Une revue de code va permettre d’identifier tous les cas d’utilisation du framework à refactoriser. Cela donnera une idée de la difficulté et du temps à investir. À cette étape, on peut aussi remarquer des effets de bord en cascade, et se rendre compte que le passage à une version plus récente impose de mettre à jour la moitié des librairies du projet. Si l’une d’entre elle n’est pas à jour, cela peut être bloquant.

On recherche avant tout la stabilité, et parfois une période d’attente s’impose avant d’entreprendre la migration.

Mise à jour du langage, du framework et des dépendances

La mise à jour du framework viendra avec la mise à jour du langage, et des dépendances. Ou l’inverse. C’est parfois la mise à jour du langage qui est le moteur de la migration, ou une nouvelle version d’une librairie qui apporte une nouvelle fonctionnalité. Dans tous les cas, c’est l’occasion de se mettre à jour, autant faire les choses bien et tout mettre à jour régulièrement.

On met donc à jour les différents composants en s’appuyant sur leur changelog pour étudier les impacts potentiels. Une fois un ensemble de composants figé dans une version stable, on peut entrer dans la phase de réécriture.

Réécriture du code déprécié

À ce moment là, souvent, plus rien ne fonctionne, et l’étape de refactorisation du code va permettre de tout réécrire. On remplace les appels de méthode dépréciées par les nouvelles recommandations. Et si certaines librairies ont changé, c’est à cette étape qu’il va falloir intégrer les ces nouvelles dépendances en lieu et place des anciennes.

Réécriture suivant les nouvelles guidelines

Mais on ne s’arrête pas là, car au delà du code, l’architecture du projet, ou son arborescence peut changer (passage à Flex par exemple).

D’une génération de framework à une autre, les recommandations changent, de nouvelles normes s’imposent, et il faut absolument en tenir compte pour finaliser la migration.

Conclusion

Plus on tarde à faire des migrations, plus le coût s’envole. C’est exponentiel ! Ne pas faire les mises à jour c’est une prise de risque ! Il faudra assumer la charge de remise en service après l’attaque, la potentielle perte de données, le manque à gagner pour un site marchand ou même l’éventuelle rançon d’un pirate…

Ce titre un brin provocateur va juste me permettre de démontrer que si le client est roi, vous êtes à son service sans pour autant être juste une main d’œuvre dépourvue de conseil et de bon sens.

Il y a quelques années en lisant une interview, je me suis dit « c’est exactement ça, on peut tout faire ! », puis en poussant la réflexion, j’ai pensé que c’était certainement ce que l’on pouvait faire de pire. Nous habituons nos clients à demander tout et n’importe quoi. De fait, nous leur donnons de mauvaises habitudes et surtout nous ne les aidons pas à résoudre leurs problématiques.

Je vous laisse lire l’extrait de l’interview :

Mais il y a quand même eu un vrai déclic. Petit, j’étais fasciné par les dessins animés où Mickey peignait d’un seul coup de pinceau un damier noir et blanc sur son mur. En physique, c’est le comble de l’impossible. Et tout à coup, en 1984, sort le premier Mac, avec MacPaint, qui permet de faire exactement ça sur son écran. Là, je me suis dit : « Ça y est, l’informatique est née et c’est “no limits”. »

Gérard Berry, informaticien et professeur au Collège de France, médaille d’or 2014 du CNRS dans une interview de rue89

https://www.youtube.com/watch?v=2ZjHD3cyb5o&feature=youtu.be&t=297

Du coup c’est « no limit » ?

Alors oui en informatique on peut certainement tout faire, mais est-ce une raison pour faire n’importe quoi ?

Si votre client n’est pas capable d’exprimer son besoin et que la demande n’est pas claire, allez vous vous lancer tête la première dans votre IDE préféré pour faire un POC, ou pire partir dans un magnifique effet tunnel avec un résultat qui ne satisfera personne ?

Et inversement, est-ce normal qu’un client arrive avec déjà une idée précise de la solution technique ? Moi quand je vais voir mon garagiste, je le laisse faire, j’exprime un besoin, il me propose d’y répondre et j’approuve ou non en fonction d’un prix principalement, mais je ne remets pas en cause ni son savoir ni son expertise. C’est lui qui sait, pas moi. D’ailleurs bien souvent je ne connais même pas la panne, juste ce petit bruit agaçant qui m’amène chez lui.

Exemple vécu

J’ai travaillé il y a quelques années pour un constructeur automobile qui avait l’ambition de vendre des voitures personnalisées. Leur designer avait imaginé des variantes, et le client pouvait paramétrer son véhicule à son goût.

Le client nous a demandé de réaliser un outil de paramétrage pour les garagistes, ils pouvaient ainsi sur demande de leur client, choisir le volant cuir, les rétroviseurs noirs, les jantes alu… et ainsi de suite.

L’idée était bonne, mais le diable se cache dans les détails. Et le designer qui avait bon goût, refusait que les clients puissent faire des choix douteux. Ainsi pas possible de prendre le toit rouge si on avait la sellerie blanche, ou les jantes plastique avec l’intérieur cuir… Et bien sûr pas de finition luxe avec un moteur d’entrée de gamme… et ainsi de suite…

L’outil devait donc prendre en compte ces exceptions, très nombreuses exceptions. Des mois de travail pour tout prendre en compte… Même les évolutions futures qui ne verront jamais le jour. Le client avait oublié la simplicité, il voulait tout tout de suite, c’était non négociable.

Au même moment, d’autres constructeurs vantaient les millions de possibilités de personnalisation de leurs véhicules, le chiffre est étonnant, mais finalement ce n’est que le produit cartésien de toutes les options. Leur configurateur de véhicule était d’une simplicité enfantine !

Quand on sait que notre configurateur n’a finalement quasiment pas servi, le modèle étant rapidement abandonné et finalement vendu sans aucune personnalisation pour des flottes d’entreprise… pour un total de quelques milliers de ventes…

Your job is not to write code

Je n’aime pas ce genre de projet où l’équipe n’est là que pour produire du code. Où le travail fournit n’apporte aucune valeur ajoutée, et sert simplement à transformer un cahier des charges en lignes de code. Le travail est lassant, et le résultat rarement probant.

Et comme le dit très bien Laura Klein, « Your job is not to write code ».

Bien sûr que non ! Et le devoir de conseil alors ? Nous devons écouter notre client, mais activement, l’aider à formaliser son besoin, le questionner sur son fonctionnement, l’aider à conceptualiser son besoin et son métier, lui apporter notre expérience, notre regard extérieur pour lui apporter une réponse personnalisée.

On fait quoi alors ?

Je résumerai ma pensée ainsi :

Si c’est compliqué à expliquer, décrire ou réaliser, c’est que c’est peut-être mal pensé.

Et c’est l’occasion de poser les choses et de repenser le métier. Souvent le client n’exprime pas son besoin réel, il n’a pas le recul nécessaire pour cela. Il pense à résoudre les conséquences de son problème mais rarement les causes. Combien de fois ai-je entendu le client demander un outil de plus pour compléter son usine à gaz alors qu’une solution plus simple et plus pérenne était possible ?

C’est là que vous intervenez, votre but devient :

Identifier les vrais problèmes

Simplifier le métier

Réduire les délais et les coûts

Simplifier la maintenance

La technique permet beaucoup de choses que le client n’imagine même pas ! En l’écoutant vous serez force de proposition, et vous pourrez simplifier la demande pour la rendre réalisable et maintenable. Vous allez à l’essentiel, dans une démarche KISS (Keep It Simple Stupid). Votre code sera plus lisible et testable, votre maintenance et les évolutions futures sont possibles !

Tout ne sera pas toujours possible, d’autres enjeux peuvent intervenir, et au final le client tranchera. Mais il choisira en connaissance de cause, et vous aurez contribué à sa réflexion, vous aurez fait un travail de qualité qui vous apportera bien plus de satisfaction, vous comprendrez encore mieux ses enjeux, son métier, en somme une expérience parfaite pour écouter votre prochain client.

Rapporté à la vie du web, PHP existe depuis très longtemps ! Et depuis bien longtemps il enflamme les débats, on l'adore pour sa simplicité, on le déteste pour ses incohérences et ses manquements... Aujourd'hui, les développeurs qui le dénigrent sont bien souvent restés bloqués dans la version 4 ou 5 du langage et n'ont pas suivi son évolution !

De la simplicité

PHP est un langage simple à aborder. Simple à installer sur un poste de développeur, simple à héberger à moindre coût vu l'offre pléthorique... simple à déployer même pour un débutant ! PHP n'impose rien, mais propose un éventail de possibilités pour tous les développeurs. Car PHP est un des seuls langages qui s'adresse à la fois aux développeurs amateurs et aux professionnels. Deux approches différentes cependant, les uns et les autres ne l'utilisant pas du tout de la même façon, mais cela explique en partie son hégémonie.

Des fonctionnalités pointues

La sécurité a été améliorée, les espaces de noms ont fait leur apparition, l'objet permet maintenant un typage plus fort, de nouveaux opérateurs ont fait leur apparition... Ce ne sont pas

des révolutions, mais cela facilite le travail des développeurs au quotidien. Ces améliorations ciblent principalement les développeurs professionnels, les évolutions étant le fait d'entreprises ou de développeurs qui sponsorisent PHP et l'amènent ou sont leurs besoins.

Il faut noter également que PHP ce n’est pas que du web. PHP c’est aussi des outils qui permettent une utilisation en ligne de commande de manière très poussée. Avec l’aide d’un framework, le résultat est performant et parfaitement cadré. Vous pourrez ainsi gérer vos tâches cron, vos files de tâches, vos workers...

Des performances

Chaque version de PHP apporte son lot d'optimisation, et ne pas travailler sur des versions récentes serait une erreur vu les bonds (20 à 30%) qui sont faits à chaque nouvelle mouture du langage. De quoi économiser côté serveur juste en mettant à jour PHP !

Une organisation nouvelle

Entre la nouvelle gouvernance de l'équipe de PHP et la création du PHP-FIG, ces dernières années ont montré une professionnalisation du langage. Elle a suivi la professionnalisation de beaucoup de développeurs et d’entreprises qui étaient en demande de qualité, d'industrialisation et d'outils adaptés. PHP a longtemps avancé sans feuille de route, ce n'est plus le cas, la route est dégagée et PHP avance désormais à un rythme maîtrisé et régulé avec une nouvelle version majeure par an. PHP-FIG permet lui de standardiser les développement et PHP perd petit à petit son côté amateur. Il est composé des équipes techniques des principaux acteurs logiciels de la sphère PHP qui appliquent les bonnes pratiques et garantissent qualité et interopérabilité.

Des développeurs

Le recrutement n'est pas toujours simple, mais pas plus compliqué que pour d'autres langages. Il y a pénurie de développeurs, certes, mais il y a beaucoup de développeurs PHP, il faut parfois filtrer, mais il est possible de trouver d'excellents profils. Il faudra cependant être patient et les motiver avec des projets attractifs sur des frameworks récents en PHP 7. Ajouter une stack récente et adaptée, une couche de bonnes pratiques, des tests unitaires, de l'intégration continue... et votre recrutement sera en bonne voie !

Aujourd’hui les meilleurs cherchent des projets de qualité qui tiennent la route, avec de la méthodologie et des résultats. Ce sont aussi les comportements des développeurs qui font la maturité de PHP.

Des projets

L'écosystème PHP a toujours été riche, mais depuis PHP 5.3 et la sortie de Composer, la gestion des dépendances est plus aisée et la visibilité des projets encore plus forte. Les dépôt Git et notamment Github participent aussi à ce partage et cette émulation autour de PHP. L'open-source a depuis longtemps fait ses preuves dans la communauté PHP ! Les frameworks tels que symfony ont le vent en poupe et servent de base à tout projet sérieux. Ils ont atteint une maturité certaine avec les dernières versions mais attention à passer par la case formation pour en tirer le maximum. Ce sont des outils simples à utiliser pour un usage basique, demandent cependant un investissement initial important si l’on souhaite en tirer le maximum.

Des serveurs

80% de serveurs avec une version de PHP ? soyons honnêtes, ils ne sont pas tous en PHP 7, seulement 20% (Sources : w3techs.com), mais professionnellement, c'est bien cette version qui tire PHP vers le haut et entraîne avec lui ces millions d'utilisateurs de PHP !

Conclusion

J’ai l’habitude de dire que Pomm est le chaînon manquant entre PHP et Postgresql et un outil indispensable à la réalisation d’un site web, je m’en vais ici le démontrer.

La première fois que j’ai utilisé une base de donnée, il y a une quinzaine d’année j’ai été bluffé par la simplicité. Il faut dire que parser du fichier dans un format maison, c’était tout sauf efficace. SQL m’apportait la structure fiable et les normes qui me manquaient. La courbe d’apprentissage de MySQL aidant, après une demi journée j’avais des tables et des requêtes CRUD. Avec le recul, évidemment, c’était perfectible, une dizaine de lignes de code dupliquées pour chaque requêtes c’était peut être pas si magique que cela.

Le temps à passé, j’ai amélioré la technique, factorisé tout cela et c’était pas si mal !

Le mal est arrivé ensuite, sous la forme d’ORM, mais je ne l’ai pas compris tout de suite. Sur le coup c’était génial, plus besoin d’écrire ces requêtes fastidieuses, toujours les mêmes, l’ORM s’en charge à ma place ! Je peux me concentrer sur le reste, sur le métier, je vais être bien plus efficace ! 

La réalité m’a bien vite rattrapé. Je perdais du temps sur la modélisation qu’il fallait reprendre plusieurs fois pour rester dans la logique de l’ORM, je gagnais au final peu de temps sur les requêtes simples, et pas du tout sur les requêtes les plus complexes... Je devais réapprendre un langage, que je trouvais plus complexe et qui limitait les possibilités ou les performances de ma base de données.

Le salut est venu à la fois de Postgresql et de Pomm !

Je ne me suis pas mis à Pomm par hasard. Après avoir vu @chanmix51 en conf sur Postgresql ou Pomm, vous n’avez qu’une envie, c’est de tester ! C’est magique et envoûtant. Les possibilités semblent infinies, on découvre que le SQL c’est aussi des requêtes récursives ou la gestion du type JSON par exemple !

Alors on teste, on a du mal à voir les limites et on entrevoit de nouveaux horizons !

Mais comment utiliser au mieux toutes ces découvertes ?

Refaire des requêtes à la main ? Utiliser PDO ? Un ORM ? Rien de tout cela n’est convaincant, et c’est là que la magie de Pomm opère !

Pomm est une petite librairie open source. La doc permet une prise en main rapide, des plugins existent pour symfony2 et ZF2, mais ils ne sont pas indispensable et on peut l’utiliser avec n’importe quel code PHP en quelques lignes ! Le code est élégant et abordable facilement.

À l’utilisation, j’apprécie que Pomm se comporte surtout comme un cadre de travail avec des fonctionnalités qui organisent mon code et me facilitent la vie sans jamais me brider. Pomm mappe mes type Postgresql avec les types PHP, Pomm gère les requêtes CRUD basiques tout seul, me fournit de quoi gérer mes transactions sereinement... Mais surtout il ne me limite jamais dans mon utilisation de Postgresql ! Toute l’équipe à repris goût à écrire du SQL pur, à se fier tout simplement à la doc, et ça marche :)

Le petit bémol, si il doit y en avoir un sera pour la montée en compétence sur Postgresql, Ceci dit vous pouvez l’utiliser à minima comme MySQL et apprendre au fur et à mesure, mais n’hésitez pas à bien vous faire accompagner sur le sujet. C’est ce que nous avons fait et c’est le choix que je recommande pour découvrir et apprendre à utiliser Postgresql rapidement et efficacement.

En résumé, ne passez pas à Pomm pour Pomm, mais pour Postgresql et ses merveilleuses fonctionnalités. Et utilisez Pomm pour vous simplifier la vie et améliorer encore votre expérience !

Pomm ce n’est pas de la magie mais un outil pensé pour utiliser pleinement Postgresql et ainsi répondre aux besoins d’applications ou sites web pointus. Essayez et vous ne ferez plus un projet ni sans l’un, ni sans l’autre !

En savoir plus :

Utiliser PostgreSQL en 2014 - Dimitri Fontaine - PHP Tour Lyon 2014

Plus de temps pour bloguer, des billets obsolètes, depuis quelques mois je n’avais plus de blog. Pour autant j’ai toujours des choses à dire, alors voilà, on retente l’expérience, avec des billets plus courts peut-être, pour ouvrir la discussion et d’autres plus longs. Peut-être un peu de technique mais surtout des retours d’expériences.