Non, PHP n’est pas « OK boomer »

Il y a quelques jours je suis tombée sur cet article, réponse à un tout autre billet de blog que j’avais plutôt trouvé pertinent.

J’ai été à la fois dev et lead dev. J’ai pu me confronter à des problématiques de gestion d’équipe dans une structure où il y avait quelques soucis qui ne dépendaient pas de moi, et ça retraçait assez fidèlement ce qu’une boite doit faire pour garder une bonne équipe. Ce n’est pas uniquement une affaire de garder un dev, mais garder une vraie équipe soudée et productive dans la satisfaction. A mes yeux, une boite qui comprend ces points a un gage de qualité. Mais passons, ce n’est pas le sujet. Le sujet a été une seule phrase, tellement absurde que je n’ai pu m’empêcher de la twitter : « Twitter a démarré avec Ruby; Facebook avec PHP ; deux technologies bien pourries et so OK Boomer aujourd’hui. » (sic).

Déjà, ça manque d’argument, pourquoi « pourries », et puis ce « ok boomer » tellement dénué de sens …

Je n’ai pas d’affinité particulière avec Ruby, j’ai déjà bidouillé avec Ruby On Rails, que j’ai trouvé pas mal … mais sans plus.

Pour moi PHP représente tout la dynamique du web, et pour preuve, c’est le rare qui tienne encore debout et qui ait autant de popularité depuis 25 ans. Je ne parlerai pas de Go, qui a sa côte de popularité, mais tout frais, ou de Javascript qui a engendré NodeJS qui pour moi est plus une mode. Javascript n’a son intérêt qu’en front-end, à mes yeux.

Au commencement … il y avait … juste du script pour page HTML en fait …

Je me suis mise en premier à PHP car c’était à mes yeux celui qui allait pérenniser, j’ai eu comme une intuition qui me disait de foncer dedans. Car ce n’était pas gagné, au début des années 2000, les entreprises préféraient embaucher des développeurs ASP ou J2EE pour leur back-end et applications web. Fraîchement sortie des bancs de fac, je ne pouvais pas payer et investir pour apprendre ASP sur un serveur dédié, alors que PHP est disponible gratuitement.
Je passe cette discussion avec le « petit Gregory du Japon » (il se reconnaîtra) qui m’avait balancé en 2000 : « si tu fais un jour du PHP je me ferai nonne. Oui, tu as bien lu : NONNE ». Challenge accepted. J’attends toujours que tu mettes le voile, Greg.
Donc j’ai continué à me pencher sur le vilain petit canard, ce PHP qui pouvait « additionner des salades avec des macaronis ». Et il suffit de regarder du code legacy pour se rendre compte de ses faiblesses … le PHP 4 objet avec ses constructeurs spéciaux (car le langage n’avait pas au départ été conçu pour le modèle objet), il fallait parfois réinventer la roue pour faire des itérateurs, ses noms de fonctions natives à la one-again (on a str_​getcsv et puis après strchr, un coup underscore, un coup pas, logique les gars ?) et surtout son faible typage (toujours d’actualité mais en voie de progrès. Mais n’est-ce pas un bon point, aussi ?). Mais PHP était un langage facile à apprendre, et il l’est toujours : pour ceux qui veulent se faire la main en programmation, c’est un bon début.

Le souci de qualité

Pourtant 25 ans après, PHP est on ne peut plus présent, ASP ne fait plus parler de lui et J2EE se raréfie. Il est même devenu plus costaud qu’avant … son modèle objet se peaufine, le typage se fait de plus en plus strict, et puis les librairies évoluent de plus en plus notamment avec l’apparition de SPL, mais également des librairies. Vanilla PHP n’est plus trop d’actualité, on a vu apparaître PECL, PEAR, et aujourd’hui la star c’est Composer, qui permet d’installer à la volée bon nombre de bibliothèques, et d’analyseurs syntaxiques. Car le développeur PHP d’aujourd’hui est soucieux de la qualité de son code : il fait appel à des analyseurs (notamment PHP-Stan) et produit des tests unitaires et des tests fonctionnels (Behat …).

La puissance des frameworks et des design patterns

La force de PHP, après avoir proposé moult CMS tels que SPIP, Joomla … dans les années 2000, a résidé dans l’apparition des frameworks, qui ont solidifié les bases du langage pour permettre non seulement aux devs de coder plus proprement, mais également de pouvoir définir des architectures évoluées en fonction des design patterns (ce qui fait de plus en plus penser à une structure type JAVA) : Zend Framework, Symfony et Laravel en tête de liste. Des architectures qui évoluent et peuvent solliciter efficacement des API REST pour permettre une mobilité des données, segmenter le code en multi-repositories pour permettre une meilleure maintenabilité du code. Et par ce biais, a permis aux CMS d’évoluer, on pense à Drupal ou Prestashop qui ont intégré Symfony dans leur code.

PHP a également gagné en performance et scalabilité grâce à FPM, qui permet de pouvoir lancer plusieurs versions du serveur. Et by the way, Facebook utilise toujours PHP … en sous-marin mais toujours …

Toujours en évolution !

A ce jour, PHP 8 est en prévision, avec plein d’améliorations, notamment le Just In Time. Et j’avoue avoir bien reçu PHP 7.4, car je l’avais attendue longtemps depuis des années, cette feature : PHP 7.4 intègre les déclarations de type d’argument. Enfin on peut typer les propriétés d’une classe !!! Yes we can ! Yalla !

Aujourd’hui PHP est devenu plus qu’un simple outil de scriptage pour sites web :
– il permet de réaliser des scripts en ligne de commandes et tâches automatisées, et on peut même créer des exécutables !
– il permet de programmer de vraies applications web
– il permet efficacement de se connecter avec une base de données, de manière de plus en plus sécurisée via les requêtes préparées

Il est PARTOUT, et même Microsoft, qui avait lancé ASP, le soutient dans les séminaires. Les débutants peuvent facilement l’appréhender en manipulant progressivement leurs pages HTML, et en guise de cerise sur le gâteau, la communauté des développeurs PHP est LARGE, depuis toujours. Vous séchez ? Vous avez obligatoirement des forums, des sites, la doc officielle régulièrement mise à jour, des Slacks pour vous aiguiller. Et il reste open-source et gratuit !

Alors sérieusement, PHP, un langage pourri et OK Boomer ?

Devs : on a tous débuté …

Rappelez-vous : dans mon article « Fuck you Masterboy », je mentionnais ce fameux site où j’avais crée mes premières lignes en PHP. C’était vers 2002-2003. Et comme je le mentionne dans « Comment archiver sans trop pleurer », je suis en train de gratter dans mes sources pour déterrer mes vieux projets.

Et ça tombe bien, j’ai trouvé les sources de ce site, que je mets à dispo sur Github : amelaye/MasterboyForEver . Alors pourquoi je fais ceci car en fait, c’est assez difficile de le faire marcher, peut-être même impossible pour certains.

J’y suis à peu près arrivée avec de la patience …

Parce qu’il y a eu beaucoup de mes élèves, lors des cours que j’ai menés, qui ont pas mal culpabilisé. Entre autres une jeune femme remplie de détermination et de bonne volonté, mais également dotée d’une faible confiance en elle, que j’avais mentorée pour Openclassrooms. J’avais énormément apprécié cette mission, car elle avançait vite et elle voulait réussir son année, des qualités qu’on prof/mentor ne peut qu’admirer. Elle (ainsi que d’autres) tenait hélas parfois une petite moue, et un œil triste « mais non je fais de la m…, la preuve je peux pas être autonome, je pompe des scripts par ci par là, je comprends pas pourquoi ci pas pourquoi ça, toi tu sais le faire, je voudrais coder comme toi. » … Et là, en position de lotus dans ma toge blanche, je lui répondais systématiquement « de temps et de patience tu necessiteras … ». Car ses doutes étaient normaux, je les avais traversés. Du coup j’ai eu envie de raconter l’histoire de ce site et de son affreux code qui marchait quand même.

Pour contextualiser le projet, en fin 2002 j’étais en licence pro internet, sortant d’un BTS qui n’avait rien à voir, et n’ayant à mon actif que des sites full HTML et bidouillages JS. La programmation, je n’en avais aucune notion, et la pire des surprises que cette licence m’avait faite a été de commencer par l’apprentissage de …

… JAVA …
Oui. Ils ont fait ça.

Bon bref, inutile de dire que j’avais complètement décroché cette partie-là, et que ce qui avait sauvé mon année a été le HTML, les bases de données et la communication. Dans le lot il y avait du PHP, le langage que je voulais absolument apprendre, bien que découragée par les cours. Dans ce cas, il n’y a pas de secret, il me fallait trouver un projet qui puisse à la fois me motiver et me permettre d’utiliser et comprendre PHP. A l’époque je tenais un site sur Masterboy, qui marchait plutôt bien, car il était le seul site francophone qui parlait à ce point du groupe, du coup c’est ainsi j’ai voulu sortir de ma zone de confort.

J’ai commencé par prendre un script existant pour faire une « fan-zone » dans laquelle on pouvait s’inscrire et partager dans cet espace. Puis quand j’ai fait mon stage, j’ai voulu mettre un peu plus les mains dans le cambouis, mais tout en piochant par-ci par là des bouts de code que je trouvais sur le web (sérieusement il n’y a pas mieux pour comprendre). C’est vraiment du taf de débutant, on y remarque entre autres :

  1. Les shorts tags. Bon à l’époque ça se faisait pas mal d’utiliser les shorts tags, je me souviens qu’en licence on ne nous avait pas déconseillé de les utiliser.
  2. Les multiples appels aux scripts de connexion. Au cas où le premier ne marchait pas, les autres peuvent mieux marcher, pensais-je.
  3. Douce époque où les requêtes n’étaient pas préparées. A cette époque je pensais aussi qu’il fallait faire des mysql_num_rows() après chaque requête même si on n’en avait pas besoin. On ne sait jamais qui peut le plus peut le moins, nesspa. D’ailleurs sur admin/liste.php la requête y est deux fois … on ne sait jamais, je vous dis.
  4. Ne me parlez pas de la programmation objet, je n’ai rien compris à ça.
  5. C’était bien de récupérer les variables en get du genre « num= » en $num, register_globals c’était la belle vie … puis PHP5 est arrivé et ça a changé.
  6. Gros embrouillamini sur mboy.php mais comme ça marchait, je ne me suis pas soucié de ça (j’ai hélas été longtemps adepte du « tant que ça marche casse pas les noix de coco. » à mes dépens …).
  7. Le camelCase ? Nan connais pas …
  8. L’indentation ? Mais ça marche, donc casse pas les noix de coco.
  9. Ha les die() avec des erreurs bien explicites … et puis la profusion de @ devant les fonctions au cas où il y aurait un bug mais chut …

ET SURTOUT : Je bidouillais parfois direct « en prod », surtout les bases de données. Et donc un jour, en voulant exécuter le script qui effaçait un post, bien ça m’a … TOUT effacé 🙂 j’étais sans filet, je n’avais aucun utilitaire pour sauvegarder mes bases (en même temps je ne maîtrisais à l’époque pas du tout Linux donc j’étais en mutualisé), et je n’avais même pas pensé à l’utilité d’un dump avant toute manipulation #lalose … ce qui explique le joli message en rouge sur la page d’accueil 😀 … voilà voilà …

Donc voilà ce que j’avais pondu à l’époque. Mais je m’auto-pardonne, parce que je sais que je devais commencer et on fait tous des choses moches quand on commence. Du coup comment puis-je flageller mes élèves qui sont de bonne volonté mais culpabilisent de leur rendu ?

Rendez-vous dans 10 ans pour que je voie votre super-code, les amis 😉

Comment monter un serveur d’archives PHP sans pleurer …

Mine de rien, concernant mon métier j’ai fait mes premiers pas en commençant mes études, ce qui commence à faire … un petit paquet d’années. Du coup en fait j’ai gardé (presque) toutes mes archives … ce qui n’est pas problématique quand on est en « full HTML » mais quand on passe en PHP, là c’est plus touchy. Parce que mes premiers sites sont en PHP4, en sachant qu’on se dirige vers la version 8, il y a eu pas mal de chemin depuis : renforcement de la rigueur, changements dans la conception objet, méthodes deprecated et j’en passe.

Essayez de faire marcher un site crée en 2003 sur un PHP 7 … ça m’étonnerait que vous puissiez faire quelque chose de concret. Du coup, pour faire comme moi, trouver des trucs de geek à faire en étant confiné (même si j’ai la chance de pouvoir continuer à travailler, il faut s’occuper le soir 😉 ) et faire tourner un serveur d’archives sur une Ubuntu récente, que faire ?

PHP 5.6 avec FPM

Il y a une solution pour les sites les plus récents : PHP-FPM, qui permet de faire tourner PHP en service indépendamment d’Apache (oui désolée je suis Apache-addict, question d’habitude), ce qui vous permet de pouvoir faire tourner un PHP5.6. C’est assez simple …

En premier lieu, on prépare le terrain, on se base déjà sur le fait que vous avec déjà Apache installé dans votre système.

Quelques librairies de base

Puis il vous faut ajouter le fameux repository d’Ondřej Surý, qui a fait un travail remarquable à ce sujet :

Et hop, magie !

N’oubliez pas d’ajouter les librairies MySQL au besoin. Une fois les installations bien terminées, faites un petit service status, histoire de bien vérifier que les services tournent :

Donc si vous avez un message de ce style, c’est que tout va bien 🙂

Donc là, vous pouvez faire tourner non seulement des sites tout neufs, mais également des sites que vous avez conçu il y a au moins trois-quatre ans. Il suffit après de configurer votre vhost comme suit pour switcher de version :

Vérifiez bien que les services suivants soient activés :
actions proxy_fcgi alias
Et les librairies suivantes installées pour PHP 5.6 au risque de voir une belle page blanche qui ne logge rien de pertinent :
php5.6-xml php5.6-gd php5.6-mcrypt php5.6-mysql php5.6-pdo

Et pour les versions antérieures à PHP 5.6 ?

Après, les choses se compliquent. Ne cherchez pas à installer ne serait-ce que PHP 5.2 à la mano, rien n’est compatible avec les versions actuelles d’OpenSSL et vous risquez de casser pas mal de trucs comme ça m’est arrivé. Et ainsi d’avoir à vous repalucher les installs d’Apache et OpenSSL, les joies de l’admin sys et de l’expérimentation, en somme 🙂 … – note : ce serveur n’est pas celui que j’utilise pour mes sites importants mais pour mon « bac à sable » 😉 …

Du coup j’ai opté pour un bel outil bien tendance qui a le vent en poupe chez les devOps, et qui est vraiment pratique, j’ai nommé : Docker ! J’ai finallement consenti à créer donc un conteneur qui ne servira qu’à mes plus anciens sites, et la bonne nouvelle, c’est qu’il n’y a pas tant de différences entre les dernières versions de PHP 4 et PHP 5.2 (au niveau du fait de pouvoir faire fonctionner un site en PHP 4 sur un serveur PHP 5.2, l’inverse ne sera pas forcément possible – et même fortement impossible), ce qui signifie que mes plus vieux sites tournent avec sans souci, et que je n’ai donc pas à créer de conteneurs supplémentaires (du moins, pour ma part ! ) !

Comme je suis une nana sympa, j’ai mis sur GitHub l’image que j’utilise, que vous pouvez déployer avec docker-compose, vous pouvez même définir un répertoire mysqldump pour alimenter la base directement en ligne de commande. Il y a également un PhpMyAdmin pour se simplifier la vie. Il faut juste modifier les vhosts pour que ça pointe sur vos sites à vous, qui seront accessible par défaut sur le port 8052 (80 port par défaut d’Apache et 52 comme PHP 5.2 😉 )

N’oubliez pas de préciser au besoin comme dans mon exemple, si vos extensions sont .php3, je sais ça fait super bizarre de retrouver ce genre d’extension …

Pour le plaisir, je vous montre une petite capture d’écran de ma page de garde, où je peux naviguer de site en site … c’est amusant de replonger dans le passé, comme ça :

Après, c’est un projet qui donne plein d’idées : par exemple vous voyez les petits screenshots ? Ils sont en réalité bien moches quand on passe en responsive, car dimensionnés assez petits (je pensais qu’à l’époque, ça suffisait). Bien là j’ai mis en place un process sous Puppeteer qui permet de faire des captures d’écran automatiquement ! Je pense que je vais pas mal trouver d’idées inspirantes que je vous partagerai par la suite 😉