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 😉

Mon projet de refacto BioPHP – Partie 2 (du design pattern)

Le souci de la librairie d’origine de BioPHP, c’est son absence de design pattern. Le code d’origine prévoyait d’inclure deux systèmes de bases de données (Genbank et Swissprot en l’occurence) voire d’autres, car j’ai vu une dizaine d’autres formats.

Or le but du jeu c’est d’avoir une structure assez carrée pour pouvoir ensuite manipuler les données.

Tout se joue dans le fichier d’origine seqdb.php, je vous laisse regarder la tambouille. Dans ce cas-là, il faut surtout comprendre la logique, la garder et tout casser en même temps. A coups de massue.

La première des choses que j’ai faite, c’est compartimenter une classe par fichier, et un fichier par classe : donc on a trois fichiers, SeqDB, et des fonctions parse_swissprot et parse_id que je ramène dans une classe chacune, et que je renomme au passage car sinon on n’y comprend pas grand-chose. Je passe l’étape de « nettoyage », remplacement des fonctionnalités obsolètes, découpage du code en méthodes privées, simple, basique.

Deuxièmement, c’est d’utiliser un Iterator pour le flux des fichiers car le script réinvente la roue avec les next() et les prev().

Ensuite j’ai refactorisé en gardant l’ancienne structure de seq.php, pour arriver à comprendre petit à petit la logique, à quoi correspond chaque champ du fichier qui est envoyé. Avant le grand coup d’envoi, puisque les structures qui correspondent aux séquences vont être factorisées à leur tour, pour cela je me suis inspirée du modèle de données qui avait été proposé par l’équipe, en y mettant deux trois ajustements :

Rien de bien sorcier, c’est du MVC et du Doctrine de base.

Une fois que c’est établi, que ça marche et parse, il faut intégrer ce système au parsing des fichiers tout en permettant à l’utilisateur de lui simplifier un maximum le travail.

Il fera appel à une interface. Une seule. Et la librairie se chargera du reste. Voici comment (le travail n’est pas terminé ce qui explique pourquoi ParseSwissProt est vide mais c’est en cours) :

Diagramme réalisé avec le superbe outil PlantUML

Utiliser l’interface DatabaseInterface fera appel via l’injection de dépendances à DatabaseManager qui se charge de vérifier si le fichier existe en base, ou d’aller chercher de la donnée. Suivant le cas de figure, ce sont des factory qui seront appelées et qui joueront les aiguilleurs en appelant les services correspondants. Ces services « final class » ont une notion d’héritage sur un autre service, abstrait, ParseDbAbstractManager, qui contient l’architecture de la donnée qui sera renvoyée dans le controller de l’utilisateur.

Ce qui permet dans tous les cas de renvoyer une donnée, qui, quel que soit le schéma de départ, sera uniforme. Et ce grâce à deux design pattern : Factory et Abstract.

Du coup, si on veut ajouter une autre structure de fichier, il suffira de modifier les factory et d’ajouter un service qui sera chargé uniquement de parser la donnée. Ceci dit, je pense qu’il est même possible de passer outre la modification des factory, je dois réfléchir sur ce point.

Je crois que cette partie est la plus complexe de mon projet, car je ne suis pas familiarisée avec les bases de données textuelles propres à la bioinformatique, et le script de départ contenait pas mal de bugs. Du coup si des biologistes chevronnés constatent des bugs à l’utilisation, ils peuvent me contacter, ce sera volontiers que je procèderai aux ajustements.

Mon projet de refacto BioPHP – Partie 1

J’aime bien la biologie, depuis ma tendre enfance. Je pensais même pouvoir un jour pouvoir faire de la bioinformatique mais j’ai vite été lassée des études en fac, donc j’ai dû faire un peu une croix sur ce projet.

Then, I left to Marseille, tout ça …

Mais dernièrement, j’ai eu pas mal de remous professionnels, quitté la dernière entreprise où j’étais en CDI (plutôt rageusement). J’ai donc passé quelques mois à construire des relations avec des clients, privilégiant l’approche freelance, et j’ai également trouvé un projet perso qui puisse m’occuper et approfondir mes connaissances en Symfony. Parce que depuis Spark, j’ai horreur d’être inoccupée. Et puis quand mon chat est mort, il a fallu un échappatoire pour penser à autre chose. Et puis j’avais une revanche perso à relever (n’est-ce pas, Guillaume ?).

J’ai trouvé donc le projet BioPHP (qui est sans URL Fixe, y’a un site ici aussi), cherchant une librairie de bioinformatique en PHP, par curiosité après avoir vu que des librairies du genre existaient en GO. Et … comment dire ? Voir des 2003, dernières mises à jour en 2009 peut-être, des fonctionnalités en PHP4, du HTML, du PHP, des data mélangées dans le code. Aucun design pattern, du code spaghetti, des fonctionnalités qui se retrouvent un peu partout. Ouch. Pourtant les fonctionnalités sont intéressantes et offrent du potentiel, les algorithmes sont hyper poussés. Cette librairie a été développée par d’excellents biologistes qui ne sont pas familiarisés avec le dev. D’ailleurs en poussant la recherche, le projet est critiqué et mal noté.

L’idée de départ des gars était super sympa : intégrer une librairie pour créer des applis de bioinformatique (plutôt orientées génétique) en PHP, comme il en existe en PERL, Go, Python … Mais il est vrai qu’à l’époque, à moins de télécharger bêtement et utiliser les fonctions require, on ne pouvait pas faire grand-chose d’autre. A part peut-être les intégrer dans PEAR ou PECL, chose que je n’ai jamais faite, donc je ne connais pas le process. PHP était vraiment à l’époque le vilain petit canard du monde des langages, et c’est à ce niveau qu’on voit son évolution fulgurante. Car aujourd’hui les outils ont évolué, nous avons les frameworks, Composer, Packager, Github, les tests unitaires et fonctionnels … en un coup de « composer install », on peut intégrer une librairie.

Comment procéder quand on est face à ce genre de challenges ? A vrai dire je n’ai pas vraiment établi de plan d’action dès le départ, peut-être une mauvaise idée, mais je me suis dit que c’était un projet pour lequel j’avais tout mon temps, et le droit à l’erreur. Car ce projet pris sur mon temps perso a été commencé en février dernier. En gros voici comment je suis en train de procéder :

Fonctionnement global de la librairie est des éléments-satellites après la refacto
  1. Installation de Symfony, création de 3 bundles : AppBundle (core de l’appli, MinitoolsBundle (qui intègre des outils qui pouvaient utiliser la librairie), et DatabaseBundle, qui m’a servi de « bundle temporaire » pour créer mes classes entités, raccordées avec Doctrine (parce que franchement, la classe seq.php … non, non, et non).
  2. Premier coup de machette dans le code. Nettoyage des fonctionnalités, renommage des variables suivant leur type, restructuration des classes originales. Séparation des classes-entités de ce qui sera intégré dans des services.
  3. Mise de côté des data. D’abord j’avais pensé à les inclure en YAML dans des paramètres, très mauvaise idée. Base de données ? Je voudrais plus la réserver à l’appli, pour moi la BDD ne doit servir qu’au stockage des séquences. Reste une idée sympa, les intégrer dans une API, ce que je voulais construire depuis longtemps pour utiliser API-Platform, un outil performant qui permet de pouvoir créer facilement ses propres API Rest. Le plus : on peut créer une couche interface qui permettra de créer un adapter, et donc de changer d’API, au cas où, tout en implémentant le modèle requis. Même si le CRUD n’est pas à 100% respecté. Les données de l’API ne sont pas destinées à être modifiées, dans l’immédiat.
  4. Refacto des « Minitools » pour bien m’imprégner de la logique de ces outils, création de l’interface web en TWIG, des services correspondants : je repère les duplicatas, crée de nouveaux services qui pourront être utiles dans le core. Car à la base, ces tools devaient intégrer les fonctionnalités de BioPHP. De mon côté ils me permettent aussi de me replonger dans les fondamentaux de la biologie : qu’est-ce qu’une protéine ? un acide aminé ? un enzyme etc …
  5. Refacto en test manuel : depuis le temps, les fonctionnalités sont en friche, donc je les fais remarcher, petit à petit, en continuant le labeur de nettoyage et de refacto. Je repère ainsi les fonctionnalités qui seront intégrées dans les « Minitools ». Cette partie sera désolidarisée (renommée en BioTools, pour caler au nommage général) du package à terme, pour des raisons logiques : le multi-repo c’est le bien, je vous dis.
  6. Tests unitaires du core : maintenant que je sais que ça marche, je repasse en mode « semi-TDD » et intègre les tests unitaires. Car un gros travail de refacto m’attend : la définition des différents design patterns de AppBundle. -> je suis ici \o/ .
  7. Découpage du projet pour en créer un projet Packagist. Et certainement montée en version de Symfony, redéfinition des dépendances d’injection etc …
  8. Création des tests unitaires et fonctionnels (avec Behat) de BioTools, refacto et envoi à Packagist.

Au prochain épisode, je rentrerai plus en détails sur la refacto d’AppBundle et des design patterns choisis.

Ha oui, et sinon, toutes les infos du projet sont là … Amelaye’s BioPHP.

Retour d’expérience sur la certification ZCPE …

A la base, j’ignorais que ce genre de certifications existait jusqu’à peu, lorsque je suis allée fouiner sur le site de Zend, pour regarder ce que l’entreprise offrait en termes de formation Zend Framework 2 (parce que même si ça se casse la figure par rapport à Symfony, ça reste quand même un système assez badass …). Entre autres Zend propose une certification Zend Certified PHP Engineer.

Et là, je me suis dit … pourquoi pas ? Parce que. Parce que déjà ça me conforterait dans mon moi profond sur mes compétences PHP. Parce que ça me ferait un plus sur mon CV.

Alors comment ça se passe de prime abord ?

Déjà, il faut acheter un voucher sur le site de Zend (170 euros à peu près). Une fois votre emplette terminée, vous allez ensuite repérer un centre « Pearson Vue » où passer l’examen et choisir un créneau horaire. J’ai passé ma session à Aix-les-Milles.

Et ensuite, il n’y a pas de secret (très bateau ce que je dis là, pas grave) : il faut réviser, bachoter, potasser la doc de PHP. Il faut savoir le programme spécifié sur le bout des doigts. Vous pouvez acheter le petit guide proposé sur le site de Zend, il ne coûte qu’une vingtaine d’euros et il fournit un bon syllabus. En un peu plus d’un mois – deux mois de préparation, en travaillant à côté, ça peut le faire.

C’est en soi la partie la plus intéressante, car j’ai appris des concepts que je n’avais jamais l’occasion d’appréhender en pratique. Par exemple, je n’avais pas trop manipulé SPL dans le passé, les traits, les générateurs. On a beau avoir plus de dix ans de pratique, on passe forcément à côté de certaines choses.

Et pendant ?

Le moment venu, il faut vous rendre au centre d’examen, au moins quinze minutes en avance pour vous préparer. Après présentation de deux pièces d’identité, vous devrez signer un formulaire qui prévoit une clause de confidentialité, ça veut dire qu’il vous est interdit de dévoiler les questions après l’examen. Dans une pièce isolée, vous devez déposer toutes vos affaires, sacs, manteaux, et même votre montre ! Eux vous donnent une ardoise et un stabilo en guise de brouillon.

A ce moment là, vous reviennent en mémoire de vieux souvenirs de lycée ou de fac au moment de passer les oraux. Le rythme cardiaque augmente, vous commencez à transpirer. C’est normal.

L’examen se passe dans une petite salle, avec plusieurs postes informatiques. Si vous avez de la chance, vous pouvez être tout seul. L’examinatrice lance le programme avec lequel tout va se jouer, et ferme la porte derrière vous. ça y est, vous y êtes. 90 minutes pour répondre à 70 questions (en anglais s’il vous plaît). TOP !

La seule chose que je dirai à propos des questions, c’est un ressenti personnel : elles m’ont semblé moins dures que je ne l’avais prévu.

Et après ?

Après avoir bien répondu à toutes les questions (on peut flager et revenir sur les éventuels doutes), il faut soumettre vos réponses. Et là …

Pour ma part, comme je l’ai eu, ça a juste affiché la phrase « Congratulations, you have passed the ZCPE exam ! ». Si vous êtes dans ce cas, et si vous êtes tout seul, vous pouvez : bondir de votre chaise, hurler de joie, vous rouler par terre, rêver à vos nouveaux plans de carrière, et vous re-rouler par terre. La dame de l’organisme de formation, de son côté, vous imprimera un récépissé qui atteste de votre réussite (ou votre échec).

Il parait que si on n’a pas réussi, le tableau des erreurs est affiché avec votre score. Ceux qui ont réussi ne connaissent pas leur score, et ne le sauront jamais.

Et encore après ?

Il suffit juste d’attendre votre facteur, qui au bout de quelques semaines vous amène une grande enveloppe venant de Cupertino (rien que ça), et qui contient votre diplôme, ainsi qu’un sticker à coller sur votre laptop. Entretemps, Zend aura mis à jour ses Yellow Pages avec votre nom, et vous fournira une licence pour le logiciel Zend Studio (qui est pas mal en soi, même si je trouve PHP-Storm très puissant).

Après, si vous trouvez que Zend Framework est badass en soi, vous pouvez passez la certification pour ce framework. Perso, j’ai acheté mon voucher … verdict dans quelques mois … 🙂

 

Ce post est dédicacé à : Patrick E, Thomas B, Cédric et surtout le petit Grégory du Japon. <3