Dans la vie, il n'y a pas que Symfony — Un collègue-
Les frameworks sont indispensables au monde des entreprises, mais occultent parfois les évolutions d'un langage. C'est le cas de PHP 7, qui même si sa sortie est largement relayée, est caché derrière d'autres projets portés par le langage. À l'aube d'un changement potentiellement radical dans la façon de développer en PHP, il est important de souligner les évolutions apportées et leurs conséquences.
-En premier lieu, évoquons le fait que nous soyons passés de PHP 5 à PHP 7.
-PHP 6 a existé de 2005 à 2014.
Parmi les fonctionnalités prévues dans cette version on peut évoquer :
-Néanmoins, aucune version stable n'est jamais sortie, même si de nombreux livres sur le sujet sont sortis durant ces quelques années. Afin d'éviter toute confusion avec PHP 6, la nouvelle version de PHP est donc passée à 7.
-Afin de comprendre l'origine de PHP 7, il est nécessaire de parler des problèmes de performance de l'interpréteur PHP. Clairement orienté pour le web, le langage souffre néanmoins de nombreux défauts, notamment lorsqu'il est question de performance et de rapidité d'exécution.
-Confrontés à ces problèmes, la société Facebook ; reposant sur PHP ; lance en 2008 l'initiative d'un projet basé sur PHP avec plusieurs améliorations, autant situées au niveau des paradigmes du langage, que sur son exécution. Le projet viendra finalement à terme sous le nom de HHVM, et sera utilisé en production par la société, en multipliant par deux la vitesse d'exécution du langage, via une transformation en bytecode du code source.
-Étant distribué librement, HHVM fait son chemin depuis quelques années comme alternative non-officielle au moteur PHP, employé ça et là par quelques sociétés, mais également cité dans de nombreux benchmarks.
-Afin d'endiguer la montée d'HHVM, la communauté des développeurs du moteur PHP se doit de répondre avec une solution officielle. S'il s'agit au départ d'un nettoyage des API, la branche dérive rapidement sur une refonte du moteur nommé "PHP-NG" (New Generation). Cette branche sera par la suite réintégrée à la branche principale du projet en 2014. Au même moment, PHP 6 sera officiellement annulé et l'intégration de ce nouveau moteur permettra la création de PHP 7.
-La refonte du moteur est une des nouveautés majeures de PHP 7 puisqu'il multiple par deux la vitesse d'exécution du code source. Mais de nombreuses fonctionnalités ont été proposées, parfois acceptées, et parfois refusées. Cet article se veut être un résumé des changements majeurs et non une liste exhaustive.
-Non sans humour, l'opérateur de comparaison introduit a en effet une ressemble visuelle importante avec un vaisseau spatial : <=> . Son intérêt est néanmoins tout autre, il permet de comparer deux variables d'une façon beaucoup plus simplifiée que ce qui était proposé auparavant. Si les deux opérandes sont égales, l'opérateur renverra 0, 1 si l'opérande de gauche est plus grande, -1 sinon.
-<?php
-// PHP 5
-usort($r, function($a, $b) {
- if ($a < $b) {
- return -1;
- } elseif ($a > $b) {
- return 1;
- }
-
- return 0;
-});
-// PHP 7
-usort($r, function($a, $b) {
- return $a <=> $b;
-});
-Un opérateur qui simplifie donc la vie des développeurs. Cependant, l'importance de cet opérateur est négligeable sur du code orienté objet, celui-ci se contentant de comparer les valeurs des attributs. Il aurait été intéressant de créer une interface de type Comparable comme ce qu'il existe en Java, afin de mieux gérer la comparaison entre objets.
-Autre opérateur ajouté, il sert deux buts : les tests et l'affectation. Jusqu'ici, il fallait tester l'existence d'une variable avant de l'affecter à une autre par le biais d'une condition (en général un ternaire). Ici, l'opérateur simplifie encore une fois le travail des développeurs :
-<?php
-// PHP 5
-$foo = isset($bar) ? $bar : 'baz';
-// or
-$foo = 'baz';
-if (isset($bar)) {
- $foo = $bar;
-}
-// PHP 7
-$foo = $bar ?? $baz;
-Largement inspiré de Java, les classes anonymes font leur entrée en PHP 7. Une suite logique à l'introduction des fonctions anonymes en PHP 5.3. Tout comme les classes définies, elle acceptent l'héritage, l'implémentation et l'usage des traits. L'avantage est multiple mais reste spécifique.
-On peut évoquer une simplification des mocks dans les tests unitaires, ou une alternative à la lourdeur de la norme PSR (qui recommande la création d'un fichier par classe) dans certains cas :
<?php
-use Psr\Log\LoggerInterface,
-
-$foo->setLogger(new class implements LoggerInterface {
- public function log($level, $message, array $context = array()) {
- // do something
- }
-
- // etc.
-});
-PHP a toujours été reconnu pour son typage faible et sa permissivité parfois extrême, qui peut mener à des incohérences et de nombreuses heures de debug. Dans cette nouvelle version de PHP, le typage fort est probablement l'une des plus importantes évolutions du langage, et ce n'est pas sans débats que celle-ci a été intégrée. Il aura en effet fallu pas moins de 5 propositions pour faire accepter cette fonctionnalité.
-Le but est d'autoriser le typage des types primitifs (ou scalaires) en argument des méthodes ou fonctions, comme c'est déjà le cas pour les objets, les tableaux et les fonctions anonymes. Étant donné le changement majeur apporté, il a été décidé que ce typage fort serait optionnel. Pour l'activer, il faudra utiliser l'instruction : "declare(strict_types=1);". Par ailleurs cette instruction doit être la première après avoir déclaré le tag "
-Il est important de préciser que de l'autocast peut-être réalisé dans certains cas par le moteur, et qu'il reste possible de forcer le cast manuellement lors de l'appel d'une fonction ou méthode.
-Un exemple de contournement :
-<?php
-declare(strict_types=1);
-
-function mySum(float $a, float $b)
-{
- return $a + $b;
-}
-
-echo mySum((float) "1.0", (float) "2");
-Souvent associée au Scalar Type Hinting, cette fonctionnalité est pourtant différente et fonctionne en toute circonstances, quelque soit la valeur ou la présence du "declare(strict_types=1|0)". Il s'agit ici d'une nouvelle implémentation et non d'une amélioration de l'existant comme pour le typage d'arguments. Sont supportés en retour de méthodes les types primitifs ainsi que les différentes classes, mais également les mots-clé "self" et "parent".
-Nous noterons deux choses supplémentaires qui sont importantes à prendre en compte :
-Exemple de syntaxe :
-<?php
-
-// pas de typage en entrée, cela peut donc lever une erreur
-// (cf. le nouveau système d'exception plus bas)
-function bar($a, $b) : int
-{
- return $a + $b;
-}
-Enfin, dernière modification majeure, le changement du système d'exceptions.
-Jusqu'ici tout était géré par exceptions, en PHP 7, le mécanisme a été scindé en deux : exceptions d'un côté (Exception), erreur de l'autre (Error), les deux implémentant l'interface Throwable. Le but étant de pouvoir catcher certaines erreurs propres au moteur, par exemple une division par 0, ou encore un problème de typage comme nous avons pu le voir plus haut. On peut donc faire l'hypothèse que la plupart des exceptions relèveront du code métier.
Un point important est qu'il est impossible d'implémenter directement l'interface Throwable, il faudra impérativement hériter d'Exception, mais il sera possible d'utiliser l'interface lors du typage, pour catcher les erreurs et les exceptions de la même manière. Vous pouvez consulter la liste des erreurs prédéfinies ici.
-La première release stable est sortie le 3 décembre 2015, et un premier patch correctif (7.0.1) a été diffusé le 17 décembre. Étant donné les nombreux changements apportés par cette nouvelle version, il reste à savoir combien de temps l'adoption de PHP 7 prendra par le monde professionnel. Sachant que certains systèmes d'informations tournant encore sur PHP 4, d'autres sur des versions de PHP plus récentes, mais souvent obsolètes, il n'est pas improbable que la migration prenne plusieurs années.
--{% endraw %} diff --git a/_drafts/2016-03-23-obtenir-apporter-de-laide-sur-symfony.html b/_drafts/2016-03-23-obtenir-apporter-de-laide-sur-symfony.html deleted file mode 100644 index 382a7e3c3..000000000 --- a/_drafts/2016-03-23-obtenir-apporter-de-laide-sur-symfony.html +++ /dev/null @@ -1,52 +0,0 @@ ---- -layout: post -title: Obtenir et apporter de l'aide sur Symfony -author: aandre -date: '2016-03-23 16:56:43 +0100' -date_gmt: '2016-03-23 15:56:43 +0100' -categories: -- Symfony -tags: -- symfony -- irc -- stackoverflow -- opensource ---- -{% raw %} -
Aujourd'hui, je vous propose un article -qui s'adresse plutôt aux débutants- sur les mécaniques pour obtenir et apporter de l’aide sur Symfony. Une grande partie des informations sont applicables à n'importe quel framework ou librairie.
-Toute bonne recherche d’informations commence par une recherche en anglais sur Google. Et quand je parle de ça, je ne parle pas d’une recherche en français sur Lycos, ou d’une recherche en chinois sur Bing, je parle d’une recherche en anglais sur Google. Rechercher dans une langue qui n’est pas l’anglais, sur un moteur de recherche exotique, c’est se fermer des milliers de portes quant aux opportunités de résultats.
-Aucune excuse n’est à trouver, les recherches tout comme le code se font en anglais. Symfony comme de nombreux projets Open Source regroupent de nombreuses nationalités tant dans leur développeurs, la communauté proche, que nous autres utilisateurs de Symfony 2. Le standard, c’est l’anglais. Et de surcroît, sur Google, c’est primordial, leur système d’indexation et algos ne sont plus à prouver, que ce soit à court, moyen ou long terme. En d’autres termes “Google, English, Deal with it”.
-
Je ne peux que retourner le couteau dans la plaie pour ceux qui n’utilisent pas cette méthode en citant les différents intervenants de Symfony.
-Sans langue commune, les projets ne seraient pas ce qu’ils sont ! Qui sait, bientôt peut-être serez-vous porteur d’un projet à vocation internationale, ne négligez donc pas votre anglais, ni la portée de celui-ci sur vos recherches. À noter par ailleurs que les traductions de la documentation Symfony dans d'autres langues que l'anglais ne sont officiellement plus supportées depuis octobre 2015.
-Pour ma part, quand mes recherches sont assez simples, je tombe bien souvent sur la même chose : la documentation de Symfony. Les faits sont là, les documentations encadrant Symfony 2 sont relativement complètes, à jour, couvrent de nombreux sujets et son généralement assez bien faites. Pour des oublis typiques, c’est souvent le point qui suit la recherche Google. J’ai en favoris les différents types de form Symfony 2 existants, ainsi que le basic-mapping doctrine, chose que je ne tiens pas à connaître par coeur, et pourtant parmi les choses que j’utilise très souvent. Notez par ailleurs, que la documentation officielle de Symfony est versionnée, ça peut paraître anodin, mais ça vous évitera peut-être 15mn de debug sur une doc qui ne correspond pas à la version de Symfony que vous utilisez :)
-La documentation répond donc à de nombreuses questions, il suffit de se donner les moyens de chercher. Outre cette doc, de nombreuses news Sf2 concernant les changelogs entre versions sont très intéressants à lire (j’ai en tête la news concernant le changement du security component, avec la nouvelle implémentation des voters).
-Parmis les recherches Google, c’est sûrement le lien qui revient le plus souvent, peu importe la technicité de la question. Et pour cause, StackOverflow est leader en terme de questionnement informatique quel qu’il soit, et la communauté est là pour aider. Je tiens néanmoins à mettre en exergue l’importance des votes sur les réponses. Ces derniers sont souvent gage de qualité, mais il faut établir un ratio rapide des votes, et comprendre l’importance de la solution proposée. En effet, elle peut ne pas répondre à la question à laquelle vous tentiez de répondre parce qu’algorithmiquement différente, ou que sais-je. Vérifiez-bien votre problème avant d’accepter une solution.
-En général, les réponses les plus acceptées de la communauté remontent le plus vite en tête, je dois avouer ne pas connaître le fonctionnement de StackOverflow concernant les réponses les plus proches de la question posée, mais il faut parfois se méfier. Dans les cas simples, effectivement une potentielle réponse fait unanimité et suffit. Dans des cas plus complexes, les réponses sont souvent hétérogènes et prendre parti ou accepter une réponse est souvent difficile et laissé à l'appréciation du principal concerné, à savoir l'auteur de la question.
-Quand parcourir Google et StackOverflow ne suffit plus, il faut bien aller directement à la source du problème et comprendre le pourquoi du comment. C'est un exercice assez difficile au départ, étant donné la complexité du framework (pas compliqué mais complexe, la nuance est importante).
-Un avantage néanmoins, c'est la modularité de Symfony découpé et pensé en composants plus ou moins complexes (Yaml Component est plus simple à assimiler que le Security Component). Vous pouvez donc vous focaliser plus rapidement sur votre problème, et faire abstraction du reste.
-En bref, c’est un exercice poussé mais absolument nécessaire pour comprendre les rouages de Symfony.
-Lorsque même parcourir le code n’a fait que vous rendre fou, ou lorsque vous avez besoin d’une réponse rapide, IRC est souvent oublié, parce qu’IRC il faut l’avouer, ça devient sacrément old-school (je ne sais pas s'il y a un Slack dédié Symfony). Il y a par ailleurs des règles à respecter (don’t ask to ask) et c’est parfois élitiste (quoique la communauté Symfony est plutôt sympa). C’est aussi assez mal vu de se présenter sur un channel IRC, demander de l’aide, et de partir aussi vite, c’est courant, mais c’est malpoli sachez-le. Intéressez-vous si vous en avez la possibilité à la communauté, et aidez si vous le pouvez en retour sur IRC. Il y a aussi l’avantage de l’outil d’échange direct, on est bien loin des formalités d’usage et de la distance que l’on peut retrouver sur les forums.
-Pour résumer, vous venez sur IRC pour obtenir de l’aide, mais ne lésinez pas sur l’aide que vous pouvez apporter en retour. L’échange et le partage sont à la base de tous les projets open-source et sont à la portée de tout le monde.
-Pour les détails, c'est par ici : http://symfony.com/irc
-Un bug qui traîne ? Ne négligez jamais votre capacité à comprendre ou ne pas comprendre quelque chose ! On peut tous contribuer, pas uniquement sur symfony, mais sur tout l'écosystème autour (les bundles sont nombreux). Et c’est grâce à cela que la communauté se forme et anticipe des besoins, chacun amenant sa pierre à l’édifice. En bref, c’est comme cela que Symfony (et tout projet open source) avance. Certains se démarquent des autres par leur volonté et leur attachement et finissent core-dev, mais pour les autres (utilisateurs du framework au final), nous soulevons des points qui permettent aux projets d’avancer et d'évoluer.
-Symfony propose par ailleurs des Virtual Hacking Days, des jours dédiés à la correction de bug. Certains sont triviaux, d'autres moins, et certains sont carrément prémachés grâce au travail de Javier Eguiluz. Vous n'avez plus d'excuse :D
-Contribuer c'est aussi améliorer la doc (https://github.com/symfony/symfony-docs/commit/8a0297ffe50c213c50bd4d1ef267765696cc86ad), c'est aussi faire des articles sur un blog, ou des tutoriels pour partager votre savoir.
-Voilà donc ce qui clos ce petit guide d’obtention d’aide utile lorsque vous êtes bloqués (mais sentez être proche de la solution). J’ai essayé de définir les différentes parties de ce guide en fonction de la difficulté du problème. Chacun travaille à sa propre façon mais la démarche restera plus ou moins la même.
-{% endraw %} diff --git a/_drafts/2016-04-22-kernel-terminate.html b/_drafts/2016-04-22-kernel-terminate.html deleted file mode 100644 index 07225716b..000000000 --- a/_drafts/2016-04-22-kernel-terminate.html +++ /dev/null @@ -1,58 +0,0 @@ ---- -layout: post -title: Kernel Terminate -author: aandre -date: '2016-04-22 16:30:30 +0200' -date_gmt: '2016-04-22 14:30:30 +0200' -categories: -- Symfony -- Php -tags: [] ---- -{% raw %} -Symfony 2 c'est plusieurs composants -dont le domaine d'application est spécifique- qui forment les parpaings d'une maison ; pour assembler tout ça, un autre composant existe, à la fois le parpaing et le ciment : l'EventDispatcher. Son rôle est de distribuer des événements qui seront traités par les divers composants.
-Il ne s'agit pas dans cet article de revenir sur le fonctionnement de l'EventDispatcher, mais d'expliquer le rôle d'un événement mal connu, l'event "kernel.terminate".
-Sachez tout d'abord qu'aucun code n'est exposé ici, je vous laisse cette démarche. D'autre part, si l'exemple est pris avec Symfony (qui simplifie le problème), ce n'est pas Symfony qui permet ce que nous allons étudier ici, mais l'implémentation du serveur PHP.
-Avant de rentrer dans le vif du sujet, profitons-en pour rappeler les différents types d'événements kernel.* qui sont dispatchés. Bien entendu, une liste exhaustive et bien plus complète existe en anglais dans la documentation officielle (et une version très détaillée). Dans leur ordre d'apparition dans le cycle d'une requête HTTP jusqu'à sa réponse.
-Si vous ouvrez votre arborescence Symfony 2, et plus particulièrement le fichier web/app.php -à savoir le point d'entrée de votre application- vous verrez très peu de lignes :
-Deux étapes exposées précédemment devraient vous interroger. Je vous laisse réfléchir desquelles il s'agit 2 minutes, pendant que je mets un petit gif de chat.
-
Alors, trouvé ? Une fois la réponse envoyée ($response->send();) l'exécution du processus de votre serveur HTTP devrait se terminer étant donné que la réponse à été envoyée et probablement reçue par le client. Pourtant, on a de nouveau une instruction ensuite.
-La vérité est un peu plus complexe en fait. Il existe plusieurs implémentations du serveur PHP. Comme je suis un peu oldschool, j'utilise toujours Apache, qui pour moi a toujours fait l'affaire dans mes projets personnels. D'autant plus que mon travail chez les clients n'est pas de m'occuper de l'administration système des serveurs. Dans le cadre d'Apache il a existé et existe encore la librairie mod_php. Le problème de celle-ci est de terminer l'exécution du processus une fois que la réponse HTTP a été renvoyée. Mais il existe une autre implémentation : PHP-FPM. Je ne prétends pas faire un article orienté admin', étant donné que ce n'est pas mon domaine. Mais pour simplifier, la plupart des handler PHP pour HTTP actuels, peuvent renvoyer une réponse HTTP puis continuer le traitement du script PHP impliqué (sauf mod_php sur Apache). Et ça, ça peut être très utile, d'où l'event kernel.terminate.
-Cet événement est dispatché lorsque la réponse HTTP à été transmise au client. L'intérêt étant de pouvoir effectuer des traitements coûteux en temps. Si ces traitements étaient fait en amont de l'envoi de la réponse, l'utilisateur le ressentirait sur le délai de réponse de la page. Et à mon sens, cet événement est bien souvent sous-estimé.
-Vous ne voyez toujours pas l'intérêt ? Un petit exemple pour vous l'expliquer pourrait vous aider à comprendre.
-Prenons le cas suivant. Vous gérez un service d'upload de photos qui ajoute des filtres (comme sur Snapchat ou Instagram). Pour ces photos vous fournissez des liens à intégrer sur les différents supports numériques (sites, forums, réseaux sociaux, etc.). Vous gérez toute cette manipulation d'image en PHP via une surcouche Symfony ; ce n'est peut-être pas la meilleure solution, mais nous prendrons cet exemple. Naturellement, vous seriez obligés de passer par l'une des extensions PHP que sont GD ou ImageMagick pour manipuler les images.
-Une première idée pourrait être de faire ce traitement dans votre contrôleur. Puis une fois celui-ci fait, retourner la réponse HTTP avec l'image et les liens. Admettons que ce traitement d'image nécessite 20 secondes. Cela implique à vos utilisateurs de s'impatienter pendant 20 longues secondes avec une page blanche. Vous même développeurs ne supportez pas d'attendre tout ce temps.
-Alors pourquoi ne pas duper l'utilisateur ? 20 secondes pour une tâche informatique c'est assez long, ça l'est également pour l'utilisateur devant une page blanche. Pourquoi ne pas aborder le problème dans l'autre sens, donner gratification à l'utilisateur en lui affichant une page rapidement, tout en pariant sur sa non-réactivité. À la place de lui afficher directement l'image et tous les liens, pourquoi ne pas afficher que les liens et parier sur la non-réactivité de l'utilisateur. Un utilisateur c'est lent, très lent. Pourquoi ne pas lui donner le Kinder Surprise, sans le jouet dans la boîte jaune parce que vous n'aviez pas fini de le fabriquer. Et pendant qu'il mange tranquillement son Kinder, pourquoi ne pas profiter de son inattention pour insérer le jouet dans la boîte jaune une fois fabriqué ? Le principe est le même ici.
-Ce pari, il a été pris par de nombreuses entreprises, qui anticipent vos déplacements sur leurs sites pour vous faire croire que celui-ci est fluide et réactif, et pour cacher certaines lenteurs dû à des processus parfois complexes. Et ça marche plutôt bien, alors pourquoi ne pas en profiter dans vos projets ? Pour plus d'informations, je vous renvoie une fois de plus à la documentation officielle pour cet événement.
-Dans des grosses structures, telles que LinkedIn par exemple, on préférera utiliser des solutions asynchrones qui passent par des queues manager (exemple : RabbitMQ, Kafka, etc.) qui sont beaucoup plus scalables sur de larges architectures. Mais dans des projets de petite à moyenne envergure, dans les PME notamment, il n'est pas toujours simple de mettre en place ces solutions qui répondent à des problématiques de grande envergure. Ce serait comme pêcher du poisson avec un lance-roquettes.
-Or ici, dans de plus petits projets, le fait de jouer avec cette notion de kernel.terminate prend tout son sens. De plus, il est très simple à mettre en place avec Symfony, il suffit de créer un listener ou un subscriber dessus.
-Il y a des cas où l'événement ne peut pas être utilisé, il cible des problèmes particuliers. En effet parfois, vous aurez besoin d'attendre que votre traitement coûteux soit terminé pour fournir une réponse HTTP, car celle-ci dépend de votre traitement. Dans ce cas vous ne pourrez pas utiliser cet événement. Ce sera à vous donc d'optimiser au mieux votre algorithme, pour qu'il prenne le moins de temps possible dans votre contrôleur ; et ainsi retourner une réponse dans les meilleurs délais.
-Notez aussi que si vous tournez sur Apache + mod_php, toute la logique liée à l'événement sera quand même exécutée, mais avant d'envoyer la réponse.
-PHP n'est pas le langage le plus rapide du monde, mais il s'en sort quand même plutôt bien avec ce genre de petites optimisations, pour peu qu'on sache l'appréhender. Avec Symfony, cela rajoute un peu de complexité pour configurer l'optimisation aux petits oignons, mais c'est du devoir du développeur d'anticiper ces problèmes. J'ai pris l'exemple ici avec Symfony qui mâche le travail avec l'event kernel.terminate, mais sachez que c'est possible en PHP natif comme je le disais grâce à la fonction fastcgi_finish_request.
-N'hésitez pas à faire un retour dans les commentaires, si vous constatez des inexactitudes, des améliorations à apporter, ou simplement si vous avez des questions sur des points un peu obscurs ;)
-{% endraw %} diff --git a/_drafts/2016-09-07-php-7-1-pour-les-null.html b/_drafts/2016-09-07-php-7-1-pour-les-null.html deleted file mode 100644 index 6c6d7f73c..000000000 --- a/_drafts/2016-09-07-php-7-1-pour-les-null.html +++ /dev/null @@ -1,64 +0,0 @@ ---- -layout: post -title: PHP 7.1 - Pour les null -author: aandre -date: '2016-09-07 11:39:10 +0200' -date_gmt: '2016-09-07 09:39:10 +0200' -categories: -- Php -tags: [] ---- -{% raw %} -Il y a quelques temps, pour ainsi dire un an (le temps passe vite ! ), je parlais de la sortie de PHP 7.0. Dix mois plus tard, les choses évoluent à nouveau : PHP 7.1 est en RC1.
-Cet article n'a pas pour vocation d'être exhaustif, mais uniquement de présenter les changements intéressants (vous trouverez en bas de page un lien vers les RFC de PHP 7.1 qui m'ont servi de socle pour cet article). Par ailleurs, cela nécessite d'avoir pris connaissance des features de PHP 7.0 que vous pouvez retrouver dans le précédent article.
-RC prévaut pour "Release Candidate". Dans le processus de développement on a souvent une alpha, une beta et une Release Candidate. Il s'agit là de versions majeures dans le processus de développement. Et pour chaque version majeure, comme en cycle normal, il y a plusieurs versions mineures. La RC1 est donc une version mineure. Si des bugs (en règle générale mineurs) sont détectés, ceux-ci seront corrigés puis une RC2 verra le jour.
-Dans l'idée, PHP 7.1 sortira donc incessamment sous peu, en tout cas, avant la fin de l'année.
-Il s'agit selon moi de l'implémentation la plus intéressante de PHP 7.1. En effet, PHP 7.0 a permis l'ajout du Scalar Type Hinting en paramètres des fonctions, mais il est également possible de typer le retour (classes & scalaires). Cependant, le problème se pose lorsque l'on a potentiellement un paramètre ou un retour null.
-Comme un exemple vaut mieux qu'un long discours, voici le comportement en PHP 7.0 (c'est également le cas pour php ~5 lorsque l'on passe ou renvoie null :
-
Voyons maintenant le workaround pour les paramètres, mais qui ne résout pas le problème pour le type de retour :
-
Adaptons maintenant ce code pour PHP 7.1, et voyons ce que cela donne :
-
Comme on peut le constater, nous pouvons dorénavant sans utiliser les paramètres par défaut, passer ou retourner des valeurs nulles grâce au type préfixé "?".
-Il est déjà possible depuis bien longtemps de faire du multi-catch avec plusieurs blocs catch, les uns à la suite des autres. Néanmoins, cela peut être parfois redondant, lorsque l'on veut gérer de la même manière deux types d'exceptions qui n'ont rien en commun. Voici comment l'utiliser :
-
Notez que je n'utilise que deux exceptions ici, mais j'aurais pu les chaîner avec d'autres.
-Un nouveau type de retour a également été introduit, il s'agit du type "void". Voici son comportement :
-
Comme on peut le voir, il est possible d'utiliser un return. Mais il faut noter que retourner null n'est pas permis, ce qui m'a amené à me poser une question farfelue et en même temps totalement inutile : est-il possible de préfixer le type void avec notre opérateur de nullité ? Comme vous pouvez le voir dans l'animation, la réponse est non, et heureusement d'ailleurs !
-De prime abord, son utilisation peut paraître inutile (surtout dans le cadre de cet exemple) mais est pourtant bien réel, appliqué dans une interface par exemple, il permet de ne pas faire dévier les multiples implémentations de cette interface.
-De la même manière que pour le type void, un autre type a été introduit, le type "iterable". Là encore, son utilité peut paraître trouble, puisqu'il existe pour cela l'interface native Traversable. Cependant, étant donné le retour à un typage des scalaires, les tableaux et les objets pouvant être itérés de la même manière, il fallait pouvoir englober à la fois tableaux scalaires, et objets traversable, ce à quoi répond ce type.
-Encore une fois, il est utilisable aussi bien pour typer un paramètre, que dans le typage de retour.
-Quelque chose qui manquait à mon sens dans les classes, et qui est enfin résolu. Il n'était pas possible jusqu'ici d'appliquer une visibilité à une constante de classe. Ce problème est résolu, et évitera à bon nombre d'utiliser des variables statiques pour contourner le problème.
-Notez tout de même, que la portée par défaut si vous ne la spécifiez pas reste publique, afin de garder un minimum de cohérence avec les anciennes versions.
-Nous pouvons également citer en vrac d'autres features :
-Avant toute chose, il ne s'agit que d'une RC, donc mon conseil reste de ne l'utiliser que sur vos environnements de développement. Et pour répondre, vous avez deux solutions :
-Je préconise d'utiliser la seconde méthode sur vos environnements de développement, il n'est pas rare dans un environnement professionnel d'être confronté à des projets nécessitant différentes versions de PHP. PHPEnv permettant de faire tourner plusieurs versions de PHP en console selon le projet. Je détaillerai dans un article comment utiliser Nginx et PHPEnv pour pouvoir faire tourner plusieurs versions de PHP en HTTP toujours sur vos environnements de développement, nous ne sommes pas des barbares !
-Cette version, même mineure, apporte un lot de nouveautés non négligeable.
-Bien entendu PHP est encore loin d'être un langage parfait, et souffre encore de lacunes. Mais ne désespérons pas de voir apparaître un jour les annotations ou les énumérations par exemple. La communauté est sans cesse en mouvement, et tend à améliorer le projet, afin que PHP aie une meilleure réputation dans le monde du développement.
-Si vous souhaitez en savoir plus, je vous invite à lire les différentes RFC qui concernent PHP 7.1.
-À plus tard pour un article sur PHP 7.2, si les features se prêtent au jeu ;)
-
Some time ago, well almost one year ago (time just flies!), I wrote about PHP 7.0. Ten months later, things are moving again: PHP 7.1 is in RC1 stage.
-This article doesn't pretend to be a list of all the modifications, but points out the new interesting features (you'll find at the bottom a link to all PHP 7.1 RFC's which have been used to write this article). Moreover, you need to know and understand all features introduced in PHP 7.0.
-RC means "Release Candidate". In the development process we often have alphas, betas, and release candidates. Those are major versions in development process. And for every major versions, there are also minor versions, just as in the normal process. Consequently, RC1 is a minor version. If bugs are spotted (generally minor ones), a RC2 will be... well... released.
-As far as we know, PHP 7.1 should be released anytime soon, at least before the end of the year!
-In my opinion, it's the most interesting feature of PHP 7.1. As you might know (I hope so!), PHP 7.0 allowed to type hint scalar in parameters of functions, but also type hint returns (both classes and scalars). However, there was something missing: the ability to pass or return null when using type hinting.
-Since an image (ok it's a video) is worth a thousand words, you can see above the behavior of PHP 7.0 when giving null to type hinted methods or functions (it's also the case with PHP5):
-
Now, let's see a simple workaround for parameters, which is not solving the problem when it's about type hinted returns:
-
And now, we will adapt our code, to make it work with PHP 7.1, and completely solve our problem:
-
As you can see, we can now, without using default parameters (such as = null), give or return null values thanks to our type prefixed with the operator "?".
-It has long been possible to do multi-catching with the use of multiple catch blocks, one by one. Yet, it can be redundant, especially when we want to handle the same way two exceptions which have nothing in common. Here is how you should use it:
-
As you can see, I only used two exceptions, but I could have used much more if needed.
-Another new type has been introduced, the void type. Here is its behavior:
-
As shown in this video, it's okay to use a return with nothing behind, but it's strictly forbidden to return null. From this previous test, I asked myself a weird and useless question: is it possible to prefix our void type with our nullable operator? The video proves that it luckily can't be.
-At first sight, the use of void may seem useless (mainly in this precise exemple) but it is not. Used in an interface, it ensures that implementations deflect too much from the original purpose of the interface.
-Following the same pattern of void, an iterable type has also been introduced. Again, its use might not be obvious at first sight because we have the native Traversable interface. Since we move forward type hinting (and embrace it right ? RIGHT ?!), we had no solution to represent both scalar arrays and traversable objects. It was inconsistent since then, because we could pass arrays or traversable objects the same way before type hinting.
-It's usable in type hinting of parameters and returns.
-Something I found missing the whole time, and which is now solved. Class constant visibility allows us to set a visibility to class constants (yeah I know, it's in the name, deal with it!). From now on, you'll avoid static to restrict visibility of things you should have called constants.
-You might want to know that if you don't indicate visibility, it will be public by default, to be compliant with older versions of PHP behaviors.
-We can also add randomly in the list of interesting features the following:
-You first want to know that you shouldn't use it in production environments! It's a RC for duck's sake! And to answer:
-I recommend using the second solution on dev environments since it's not rare professionnally to handle projects not using same PHP versions. PHPEnv allows you to run multiple versions of PHP in CLI, based on the project. I'll certainly do a post to explain how to plug Nginx, PHP-FPM and PHPEnv to have multiple versions of PHP in a HTTP way (on dev env, right ? RIGHT ?!).
-This version, even being minor, comes with a lot of changes.
-I'm aware that PHP is not the perfect language, and has many missing features. But we can hope that, one day, we will have native annotations or enumerations for example. The community is constantly moving, and tries really hard to improve PHP and its reputation.
-If you want to know more about PHP 7.1 features, I invite you to read RFC's.
-See you later for an article on PHP 7.2, if features are good enough to be listed ;)
-
Dans un contexte professionnel, il n'est pas rare de travailler sur divers projets. Sur ces divers projets, il n'est pas rare non plus que ceux-ci ne fonctionnent pas avec les mêmes versions de PHP. C'est d'ailleurs pour cette raison que les IDE vous proposent de sélectionner la version de PHP (et c'est le cas pour de nombreux langages), afin de vous informer si vous utilisez une fonctionnalité qui n'est pas encore supportée, ou à l'inverse dépréciée, ou voire même inexistante.
-Quid de la partie tests ? Dans cet article, je vous propose de faire cohabiter plusieurs versions de PHP, avec une granularité par projet, aussi bien en console qu'au travers d'un serveur HTTP.
-Avant toute chose, sachez qu'il existe de nombreux outils qui permettent de faire cohabiter plusieurs versions de PHP. Le but n'est pas de faire un listing de tous les outils. Pour ma part j'ai choisi PHPEnv, dans une ancienne version, étant donné que la nouvelle ne semble pas fonctionner sur ma machine.
-Selon votre OS et vos préférences, vous aurez peut-être donc des adaptations à faire. Dans tous les cas le fonctionnement est toujours assez similaire, ces outils vont automatiser la compilation de PHP depuis les sources. Sur une machine décente, cela prendra une quinzaine de minutes.
-Clonez le projet dans votre home (ou l'outil le plus récent, comme je l'expliquais : https://github.com/phpenv/phpenv) :
-$ git clone git://github.com/humanshell/phpenv.git ~/.phpenv --
Lister les versions PHP disponibles à la compilation, c'est toujours à jour puisque l'outil analyse directement les dépôts git de PHP :
-$ cd .phpenv -$ ./bin/phpenv install --releases-
Dans mon cas, au moment où j'écris ces lignes, nous avons :
-... -php-7.0.9RC1 -php-7.1.0RC1 -php-7.1.0RC2 -php-7.1.0RC3 -php-7.1.0alpha1 -php-7.1.0alpha2 -php-7.1.0alpha3 -php-7.1.0beta1 -php-7.1.0beta2 -php-7.1.0beta3-
La dernière fois que j'évoquais PHP 7.1 c'était la première RC, donc je vais en profiter pour installer la beta 3, c'est tout simple (j'ai précédé les logs par les horaires, pour que vous voyiez le temps que ça peut prendre) :
-$ ./bin/phpenv install php-7.1.0beta3 -(12h19) - [Cloning]: source from php-src Github repo -(12h23) -php.ini-development gets used as php.ini - -Building php-7.1.0beta3 - - [Fetching]: latest code from Github repo - [Branching]: for a clean build environment - [Configuring]: build options for selected release -BUILD ERROR -Switched to a new branch 'build' configure: WARNING: unrecognized options: --with-mysql configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers. configure: error: Cannot find OpenSSL's <evp.h> - -The full Log is available here /tmp/phpenv-install-php-7.1.0beta3.20160929122243.log --
J'ai volontairement affiché le log précédent parce qu'il y a une première erreur à gérer : PHPEnv utilise d'anciennes options qui ne sont plus forcément supportées. Et c'est justement l'occasion de voir comment les modifier.
-On va donc éditer le script PHPEnv en charge de l'installation (à l'arrache, c'est fait pour du dev' pas pour de la prod') :
-$ vim libexec/phpenv-install-
Pour supprimer la ligne --with-mysql=mysqlnd \
-J'ai eu bien sûr d'autres erreurs, je vous laisse chercher, la plupart du temps il s'agit de librairies de développement manquantes ou pas à jour (comme libssl-dev dans mon cas). La compilation n'a jamais été une science exacte tant cela dépend de nombreux facteurs.
-Nous pouvons relancer l'installation :
-$ ./bin/phpenv install php-7.1.0beta3 -(12h31) - [Fetching]: latest code from Github repo - [Branching]: for a clean build environment - [Configuring]: build options for selected release - [Compiling]: /home/alexception/tmp/.phpenv/versions/7.1.0beta3-
J'ai le temps d'aller prendre un café :
-
(12h40, le ventilateur se met en route, ça compile beaucoup) - -(12h45) - [Info]: The Log File is not empty, but the build did not fail. - Maybe just warnings got logged? - You can review the log at /tmp/phpenv-install-php-7.1.0beta3.20160929123438.log - [Success]: Built php-7.1.0beta3 successfully.-
J'ai vraisemblablement eu des warnings, mais étant donné que je suis en local, c'est largement suffisant. À vous d'affiner si vous préférez optimiser.
-Et nous pouvons donc exécuter la commande suivante :
-$ ./versions/7.1.0beta3/bin/php -v - -PHP 7.1.0beta3 (cli) (built: Sep 29 2016 12:44:17) ( NTS ) -Copyright (c) 1997-2016 The PHP Group -Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies --
Où l'on peut constater que nous avons bien la version PHP 7.1.0beta3.
-Cette première étape de l'utilisation de PHPEnv vous permet déjà d'avoir plusieurs versions de PHP sur vos projets en CLI aussi bien que via un serveur HTTP, puisque PHP 5.4 sortait avec un serveur HTTP interne. On pourrait aller un peu plus loin dans l'utilisation de cet outil, mais pour ça il y a la documentation de l'outil. Il est bon de rappeler que c'est un outil de développement à utiliser en local ou sur un serveur de développement, et non sur un serveur de production, surtout si vous ne configurez pas les options de PHP, ou compilez des versions non finales (RC/alpha/beta). Vous vous exposeriez potentiellement à des bugs ou des failles de sécurité. Donc ne vous amusez pas à binder votre configuration Nginx sur php-fpm en version beta :)
-Si toutefois vous veniez à compiler vos versions de PHP pour la production, ce qui est totalement justifié pour des raisons de performances en affinant la granularité des options, faites le correctement en utilisant le manuel.
--
Crédits photo : Nick Brandt (http://visualattraction.fr/nick-brandt)
-{% endraw %} diff --git a/_posts/2015-12-21-php-7-petit-guide-qui-ne-trompe-pas.md b/_posts/2015-12-21-php-7-petit-guide-qui-ne-trompe-pas.md new file mode 100644 index 000000000..4223f1be8 --- /dev/null +++ b/_posts/2015-12-21-php-7-petit-guide-qui-ne-trompe-pas.md @@ -0,0 +1,156 @@ +--- +layout: post +title: PHP 7 - Le petit guide qui ne trompe pas +author: aandre +date: '2015-12-21 18:33:37 +0100' +date_gmt: '2015-12-21 17:33:37 +0100' +categories: +- Php +tags: +- php +- migration +--- +> Dans la vie, il n'y a pas que Symfony — Un collègue + +Les frameworks sont indispensables au monde des entreprises, mais occultent parfois les évolutions d'un langage. C'est le cas de PHP 7, qui même si sa sortie est largement relayée, est caché derrière d'autres projets portés par le langage. À l'aube d'un changement potentiellement radical dans la façon de développer en PHP, il est important de souligner les évolutions apportées et leurs conséquences. + +# PHP 6 + +En premier lieu, évoquons le fait que nous soyons passés de PHP 5 à PHP 7. +PHP 6 a existé de 2005 à 2014. + +Parmi les fonctionnalités prévues dans cette version on peut évoquer : + +* Support de l'UTF-8 +* Support natif des annotations +* Multi-thread & meilleur support 64 bits + +Néanmoins, aucune version stable n'est jamais sortie, même si de nombreux livres sur le sujet sont sortis durant ces quelques années. Afin d'éviter toute confusion avec PHP 6, la nouvelle version de PHP est donc passée à 7. + +# Les origines de PHP 7 + +Afin de comprendre l'origine de PHP 7, il est nécessaire de parler des problèmes de performance de l'interpréteur PHP. Clairement orienté pour le web, le langage souffre néanmoins de nombreux défauts, notamment lorsqu'il est question de performance et de rapidité d'exécution. + +Confrontés à ces problèmes, la société Facebook ; reposant sur PHP ; lance en 2008 l'initiative d'un projet basé sur PHP avec plusieurs améliorations, autant situées au niveau des paradigmes du langage, que sur son exécution. Le projet viendra finalement à terme sous le nom de HHVM, et sera utilisé en production par la société, en multipliant par deux la vitesse d'exécution du langage, via une transformation en [bytecode](https://en.wikipedia.org/wiki/Bytecode) du code source. + +Étant distribué librement, HHVM fait son chemin depuis quelques années comme alternative non-officielle au moteur PHP, employé ça et là par quelques sociétés, mais également cité dans de nombreux benchmarks. + +Afin d'endiguer la montée d'HHVM, la communauté des développeurs du moteur PHP se doit de répondre avec une solution officielle. S'il s'agit au départ d'un nettoyage des API, la branche dérive rapidement sur une refonte du moteur nommé "PHP-NG" (New Generation). Cette branche sera par la suite réintégrée à la branche principale du projet en 2014. Au même moment, PHP 6 sera officiellement annulé et l'intégration de ce nouveau moteur permettra la création de PHP 7. + +# Les nouveautés + +La refonte du moteur est une des nouveautés majeures de PHP 7 puisqu'il multiple par deux la vitesse d'exécution du code source. Mais de nombreuses fonctionnalités ont été proposées, parfois acceptées, et parfois refusées. Cet article se veut être un résumé des changements majeurs et non une liste exhaustive. + +## Spaceship operator + +Non sans humour, l'opérateur de comparaison introduit a en effet une ressemble visuelle importante avec un vaisseau spatial : <=> . Son intérêt est néanmoins tout autre, il permet de comparer deux variables d'une façon beaucoup plus simplifiée que ce qui était proposé auparavant. Si les deux opérandes sont égales, l'opérateur renverra 0, 1 si l'opérande de gauche est plus grande, -1 sinon. + +```php + $b) { + return 1; + } + + return 0; +}); +// PHP 7 +usort($r, function($a, $b) { + return $a <=> $b; +}); +``` + +Un opérateur qui simplifie donc la vie des développeurs. Cependant, l'importance de cet opérateur est négligeable sur du code orienté objet, celui-ci se contentant de comparer les valeurs des attributs. Il aurait été intéressant de créer une interface de type Comparable comme ce qu'il existe en Java, afin de mieux gérer la comparaison entre objets. + +## Null coalesce operator + +Autre opérateur ajouté, il sert deux buts : les tests et l'affectation. Jusqu'ici, il fallait tester l'existence d'une variable avant de l'affecter à une autre par le biais d'une condition (en général un ternaire). Ici, l'opérateur simplifie encore une fois le travail des développeurs : + +```php +setLogger(new class implements LoggerInterface { + public function log($level, $message, array $context = array()) { + // do something + } + + // etc. +}); +``` + +## Scalar Type Hinting + +PHP a toujours été reconnu pour son typage faible et sa permissivité parfois extrême, qui peut mener à des incohérences et de nombreuses heures de debug. Dans cette nouvelle version de PHP, le typage fort est probablement l'une des plus importantes évolutions du langage, et ce n'est pas sans débats que celle-ci a été intégrée. Il aura en effet fallu pas moins de 5 propositions pour faire accepter cette fonctionnalité. + +Le but est d'autoriser le typage des types primitifs (ou scalaires) en argument des méthodes ou fonctions, comme c'est déjà le cas pour les objets, les tableaux et les fonctions anonymes. Étant donné le changement majeur apporté, il a été décidé que ce typage fort serait optionnel. Pour l'activer, il faudra utiliser l'instruction : "declare(strict_types=1);". Par ailleurs cette instruction doit être la première après avoir déclaré le tag " + +Il est important de préciser que de l'autocast peut-être réalisé dans certains cas par le moteur, et qu'il reste possible de forcer le cast manuellement lors de l'appel d'une fonction ou méthode. + +Un exemple de contournement : + +```php +send();_ +* et enfin un : _$kernel->terminate($request, $response)_ + +Deux étapes exposées précédemment devraient vous interroger. Je vous laisse réfléchir desquelles il s'agit 2 minutes, pendant que je mets un petit gif de chat. + +[](http://blog.eleven-labs.com/wp-content/uploads/2016/04/catbeer.gif) + +Alors, trouvé ? Une fois la réponse envoyée (_$response->send();_) l'exécution du processus de votre serveur HTTP devrait se terminer étant donné que la réponse à été envoyée et probablement reçue par le client. Pourtant, on a de nouveau une instruction ensuite. + +La vérité est un peu plus complexe en fait. Il existe plusieurs implémentations du serveur PHP. Comme je suis un peu oldschool, j'utilise toujours Apache, qui pour moi a toujours fait l'affaire dans mes projets personnels. D'autant plus que mon travail chez les clients n'est pas de m'occuper de l'administration système des serveurs. Dans le cadre d'Apache il a existé et existe encore la librairie mod_php. Le problème de celle-ci est de terminer l'exécution du processus une fois que la réponse HTTP a été renvoyée. Mais il existe une autre implémentation : PHP-FPM. Je ne prétends pas faire un article orienté admin', étant donné que ce n'est pas mon domaine. Mais pour simplifier, la plupart des handler PHP pour HTTP actuels, peuvent renvoyer une réponse HTTP puis continuer le traitement du script PHP impliqué (sauf mod_php sur Apache). Et ça, ça peut être très utile, d'où l'event kernel.terminate. + +# kernel.terminate + +Cet événement est dispatché lorsque la réponse HTTP à été transmise au client. L'intérêt étant de pouvoir effectuer des traitements coûteux en temps. Si ces traitements étaient fait en amont de l'envoi de la réponse, l'utilisateur le ressentirait sur le délai de réponse de la page. Et à mon sens, cet événement est bien souvent sous-estimé. + +## Exemple concret + +Vous ne voyez toujours pas l'intérêt ? Un petit exemple pour vous l'expliquer pourrait vous aider à comprendre. + +Prenons le cas suivant. Vous gérez un service d'upload de photos qui ajoute des filtres (comme sur Snapchat ou Instagram). Pour ces photos vous fournissez des liens à intégrer sur les différents supports numériques (sites, forums, réseaux sociaux, etc.). Vous gérez toute cette manipulation d'image en PHP via une surcouche Symfony ; ce n'est peut-être pas la meilleure solution, mais nous prendrons cet exemple. Naturellement, vous seriez obligés de passer par l'une des extensions PHP que sont GD ou ImageMagick pour manipuler les images. + +### L'idée bof-bof + +Une première idée pourrait être de faire ce traitement dans votre contrôleur. Puis une fois celui-ci fait, retourner la réponse HTTP avec l'image et les liens. Admettons que ce traitement d'image nécessite 20 secondes. Cela implique à vos utilisateurs de s'impatienter pendant 20 longues secondes avec une page blanche. Vous même développeurs ne supportez pas d'attendre tout ce temps. + +### L'idée plus optimisée + +Alors pourquoi ne pas duper l'utilisateur ? 20 secondes pour une tâche informatique c'est assez long, ça l'est également pour l'utilisateur devant une page blanche. Pourquoi ne pas aborder le problème dans l'autre sens, donner gratification à l'utilisateur en lui affichant une page rapidement, tout en pariant sur sa non-réactivité. À la place de lui afficher directement l'image et tous les liens, pourquoi ne pas afficher que les liens et parier sur la non-réactivité de l'utilisateur. Un utilisateur c'est lent, très lent. Pourquoi ne pas lui donner le Kinder Surprise, sans le jouet dans la boîte jaune parce que vous n'aviez pas fini de le fabriquer. Et pendant qu'il mange tranquillement son Kinder, pourquoi ne pas profiter de son inattention pour insérer le jouet dans la boîte jaune une fois fabriqué ? Le principe est le même ici. + +Ce pari, il a été pris par de nombreuses entreprises, qui anticipent vos déplacements sur leurs sites pour vous faire croire que celui-ci est fluide et réactif, et pour cacher certaines lenteurs dû à des processus parfois complexes. Et ça marche plutôt bien, alors pourquoi ne pas en profiter dans vos projets ? Pour plus d'informations, je vous renvoie une fois de plus à la documentation officielle pour cet [événement](http://symfony.com/doc/current/components/http_kernel/introduction.html#the-kernel-terminate-event). + +## Est-ce vraiment utile ? + +Dans des grosses structures, telles que LinkedIn par exemple, on préférera utiliser des solutions asynchrones qui passent par des queues manager (exemple : RabbitMQ, Kafka, etc.) qui sont beaucoup plus scalables sur de larges architectures. Mais dans des projets de petite à moyenne envergure, dans les PME notamment, il n'est pas toujours simple de mettre en place ces solutions qui répondent à des problématiques de grande envergure. Ce serait comme pêcher du poisson avec un lance-roquettes. + +Or ici, dans de plus petits projets, le fait de jouer avec cette notion de kernel.terminate prend tout son sens. De plus, il est très simple à mettre en place avec Symfony, il suffit de créer un [listener](http://symfony.com/doc/current/cookbook/event_dispatcher/event_listener.html#creating-an-event-listener) ou un [subscriber](http://symfony.com/doc/current/cookbook/event_dispatcher/event_listener.html#creating-an-event-subscriber) dessus. + +## Ce n'est pas la réponse à tous les problèmes + +Il y a des cas où l'événement ne peut pas être utilisé, il cible des problèmes particuliers. En effet parfois, vous aurez besoin d'attendre que votre traitement coûteux soit terminé pour fournir une réponse HTTP, car celle-ci dépend de votre traitement. Dans ce cas vous ne pourrez pas utiliser cet événement. Ce sera à vous donc d'optimiser au mieux votre algorithme, pour qu'il prenne le moins de temps possible dans votre contrôleur ; et ainsi retourner une réponse dans les meilleurs délais. + +Notez aussi que si vous tournez sur Apache + mod_php, toute la logique liée à l'événement sera quand même exécutée, mais avant d'envoyer la réponse. + +# Conclusion + +PHP n'est pas le langage le plus rapide du monde, mais il s'en sort quand même plutôt bien avec ce genre de petites optimisations, pour peu qu'on sache l'appréhender. Avec Symfony, cela rajoute un peu de complexité pour configurer l'optimisation aux petits oignons, mais c'est du devoir du développeur d'anticiper ces problèmes. J'ai pris l'exemple ici avec Symfony qui mâche le travail avec l'event kernel.terminate, mais sachez que c'est possible en PHP natif comme je le disais grâce à la fonction [fastcgi_finish_request](http://php.net/manual/en/function.fastcgi-finish-request.php). + +N'hésitez pas à faire un retour dans les commentaires, si vous constatez des inexactitudes, des améliorations à apporter, ou simplement si vous avez des questions sur des points un peu obscurs ;) \ No newline at end of file diff --git a/_posts/2016-09-07-php-7-1-pour-les-null.md b/_posts/2016-09-07-php-7-1-pour-les-null.md new file mode 100644 index 000000000..bcc994e54 --- /dev/null +++ b/_posts/2016-09-07-php-7-1-pour-les-null.md @@ -0,0 +1,94 @@ +--- +layout: post +title: PHP 7.1 - Pour les null +author: aandre +date: '2016-09-07 11:39:10 +0200' +date_gmt: '2016-09-07 09:39:10 +0200' +categories: +- Php +tags: [] +--- +Il y a quelques temps, pour ainsi dire un an (le temps passe vite ! ), je parlais de la sortie de PHP 7.0. Dix mois plus tard, les choses évoluent à nouveau : PHP 7.1 est en RC1. + +Cet article n'a pas pour vocation d'être exhaustif, mais uniquement de présenter les changements intéressants (vous trouverez en bas de page un lien vers les RFC de PHP 7.1 qui m'ont servi de socle pour cet article). Par ailleurs, cela nécessite d'avoir pris connaissance des features de PHP 7.0 que vous pouvez retrouver dans le [précédent article](http://blog.eleven-labs.com/fr/php-7-petit-guide-qui-ne-trompe-pas/). + +# RC1 ? + +RC prévaut pour "Release Candidate". Dans le processus de développement on a souvent une alpha, une beta et une Release Candidate. Il s'agit là de versions majeures dans le processus de développement. Et pour chaque version majeure, comme en cycle normal, il y a plusieurs versions mineures. La RC1 est donc une version mineure. Si des bugs (en règle générale mineurs) sont détectés, ceux-ci seront corrigés puis une RC2 verra le jour. + +Dans l'idée, PHP 7.1 sortira donc incessamment sous peu, en tout cas, avant la fin de l'année. + +# Les features + +## Nullable types + +Il s'agit selon moi de l'implémentation la plus intéressante de PHP 7.1. En effet, PHP 7.0 a permis l'ajout du Scalar Type Hinting en paramètres des fonctions, mais il est également possible de typer le retour (classes & scalaires). Cependant, le problème se pose lorsque l'on a potentiellement un paramètre ou un retour null. + +Comme un exemple vaut mieux qu'un long discours, voici le comportement en PHP 7.0 (c'est également le cas pour php ~5 lorsque l'on passe ou renvoie null) : +[](https://asciinema.org/a/84925) + +Voyons maintenant le workaround pour les paramètres, mais qui ne résout pas le problème pour le type de retour : +[](https://asciinema.org/a/84927) + +Adaptons maintenant ce code pour PHP 7.1, et voyons ce que cela donne : +[](https://asciinema.org/a/84926) + +Comme on peut le constater, nous pouvons dorénavant sans utiliser les paramètres par défaut, passer ou retourner des valeurs nulles grâce au type préfixé "?". + +## Multi-catch + +Il est déjà possible depuis bien longtemps de faire du multi-catch avec plusieurs blocs catch, les uns à la suite des autres. Néanmoins, cela peut être parfois redondant, lorsque l'on veut gérer de la même manière deux types d'exceptions qui n'ont rien en commun. Voici comment l'utiliser : +[](https://asciinema.org/a/84954) + +Notez que je n'utilise que deux exceptions ici, mais j'aurais pu les chaîner avec d'autres. + +## Void type + +Un nouveau type de retour a également été introduit, il s'agit du type "void". Voici son comportement : +[](https://asciinema.org/a/84952) + +Comme on peut le voir, il est possible d'utiliser un return. Mais il faut noter que retourner null n'est pas permis, ce qui m'a amené à me poser une question farfelue et en même temps totalement inutile : est-il possible de préfixer le type void avec notre opérateur de nullité ? Comme vous pouvez le voir dans l'animation, la réponse est non, et heureusement d'ailleurs ! + +De prime abord, son utilisation peut paraître inutile (surtout dans le cadre de cet exemple) mais est pourtant bien réel, appliqué dans une interface par exemple, il permet de ne pas faire dévier les multiples implémentations de cette interface. + +## Iterable type + +De la même manière que pour le type void, un autre type a été introduit, le type "iterable". Là encore, son utilité peut paraître trouble, puisqu'il existe pour cela l'interface native Traversable. Cependant, étant donné le retour à un typage des scalaires, les tableaux et les objets pouvant être itérés de la même manière, il fallait pouvoir englober à la fois tableaux scalaires, et objets traversable, ce à quoi répond ce type. + +Encore une fois, il est utilisable aussi bien pour typer un paramètre, que dans le typage de retour. + +## Class constant visibility + +Quelque chose qui manquait à mon sens dans les classes, et qui est enfin résolu. Il n'était pas possible jusqu'ici d'appliquer une visibilité à une constante de classe. Ce problème est résolu, et évitera à bon nombre d'utiliser des variables statiques pour contourner le problème. + +Notez tout de même, que la portée par défaut si vous ne la spécifiez pas reste publique, afin de garder un minimum de cohérence avec les anciennes versions. + +## Miscellaneous + +Nous pouvons également citer **en vrac** d'autres features : +- la short syntax pour list($foo, $bar, $baz) => [$foo, $bar, $baz], qui va dans la continuité de ce qui avait été fait sur les tableau en 5.4 ; +- le support des clés dans list, pour les tableaux de type clé-valeur ; +- une meilleure gestion des nombres octaux ; +- une quasi-interdiction de l'usage de $this dans les classes pour éviter des effets de bords dus à des réassignations hasardeuses ; +- etc. + +# Comment qu'on teste ? + +Avant toute chose, il ne s'agit que d'une RC, donc mon conseil reste de ne l'utiliser que sur vos environnements de développement. Et pour répondre, vous avez deux solutions : + +- compiler PHP 7.1 RC1 à la main, je vous renvoie à la [documentation officielle](http://php.net/manual/fr/install.windows.building.php) ; +- utiliser phpenv, qui de toute manière compile également les sources (mais de façon plus automatisée). + +Je préconise d'utiliser la seconde méthode sur vos environnements de développement, il n'est pas rare dans un environnement professionnel d'être confronté à des projets nécessitant différentes versions de PHP. PHPEnv permettant de faire tourner plusieurs versions de PHP en console selon le projet. Je détaillerai dans un article comment utiliser Nginx et PHPEnv pour pouvoir faire tourner plusieurs versions de PHP en HTTP toujours sur vos environnements de développement, nous ne sommes pas des barbares ! + +# Conclusion + +Cette version, même mineure, apporte un lot de nouveautés non négligeable. + +Bien entendu PHP est encore loin d'être un langage parfait, et souffre encore de lacunes. Mais ne désespérons pas de voir apparaître un jour les annotations ou les énumérations par exemple. La communauté est sans cesse en mouvement, et tend à améliorer le projet, afin que PHP aie une meilleure réputation dans le monde du développement. + +Si vous souhaitez en savoir plus, je vous invite à lire les différentes [RFC](https://wiki.php.net/rfc#php_71) qui concernent PHP 7.1. + +À plus tard pour un article sur PHP 7.2, si les features se prêtent au jeu ;) + + \ No newline at end of file diff --git a/_posts/2016-09-08-php-7-1-dummies-candidates.md b/_posts/2016-09-08-php-7-1-dummies-candidates.md new file mode 100644 index 000000000..7aecc2206 --- /dev/null +++ b/_posts/2016-09-08-php-7-1-dummies-candidates.md @@ -0,0 +1,101 @@ +--- +layout: post +title: PHP 7.1 - For dummies candidates +author: aandre +date: '2016-09-08 15:00:05 +0200' +date_gmt: '2016-09-08 13:00:05 +0200' +categories: +- Non classé +tags: +- php +--- +Some time ago, well almost one year ago (time just flies!), I wrote about PHP 7.0\. Ten months later, things are moving again: PHP 7.1 is in RC1 stage. + +This article doesn't pretend to be a list of all the modifications, but points out the new interesting features (you'll find at the bottom a link to all PHP 7.1 RFC's which have been used to write this article). Moreover, you need to know and understand all features introduced in PHP 7.0. + +# RC1? + +RC means "Release Candidate". In the development process we often have alphas, betas, and release candidates. Those are major versions in development process. And for every major versions, there are also minor versions, just as in the normal process. Consequently, RC1 is a minor version. If bugs are spotted (generally minor ones), a RC2 will be... well... released. + +As far as we know, PHP 7.1 should be released anytime soon, at least before the end of the year! + +# Features + +## Nullable types + +In my opinion, it's the most interesting feature of PHP 7.1\. As you might know (I hope so!), PHP 7.0 allowed to type hint scalar in parameters of functions, but also type hint returns (both classes and scalars). However, there was something missing: the ability to pass or return null when using type hinting. + +Since an image (ok it's a video) is worth a thousand words, you can see above the behavior of PHP 7.0 when giving null to type hinted methods or functions (it's also the case with PHP5): + +[](https://asciinema.org/a/84925) + +Now, let's see a simple workaround for parameters, which is not solving the problem when it's about type hinted returns: + +[](https://asciinema.org/a/84927) + +And now, we will adapt our code, to make it work with PHP 7.1, and completely solve our problem: + +[](https://asciinema.org/a/84926) + +As you can see, we can now, without using default parameters (such as = null), give or return null values thanks to our type prefixed with the operator "?". + +## Multi-Catch + +It has long been possible to do multi-catching with the use of multiple catch blocks, one by one. Yet, it can be redundant, especially when we want to handle the same way two exceptions which have nothing in common. Here is how you should use it: + +[](https://asciinema.org/a/84954) + +As you can see, I only used two exceptions, but I could have used much more if needed. + +## Void type + +Another new type has been introduced, the void type. Here is its behavior: + +[](https://asciinema.org/a/84952) + +As shown in this video, it's okay to use a return with nothing behind, but it's strictly forbidden to return null. From this previous test, I asked myself a weird and useless question: is it possible to prefix our void type with our nullable operator? The video proves that it luckily can't be. + +At first sight, the use of void may seem useless (mainly in this precise exemple) but it is not. Used in an interface, it ensures that implementations deflect too much from the original purpose of the interface. + +## Iterable type + +Following the same pattern of void, an iterable type has also been introduced. Again, its use might not be obvious at first sight because we have the native Traversable interface. Since we move forward type hinting (and embrace it right ? RIGHT ?!), we had no solution to represent both scalar arrays and traversable objects. It was inconsistent since then, because we could pass arrays or traversable objects the same way before type hinting. + +It's usable in type hinting of parameters and returns. + +## Class constant visibility + +Something I found missing the whole time, and which is now solved. Class constant visibility allows us to set a visibility to class constants (yeah I know, it's in the name, deal with it!). From now on, you'll avoid static to restrict visibility of things you should have called constants. + +You might want to know that if you don't indicate visibility, it will be public by default, to be compliant with older versions of PHP behaviors. + +## Miscellaneous + +We can also add randomly in the list of interesting features the following: + +* the short syntax for list($foo, $bar, $baz) => [$foo, $bar, $baz], which goes in the continuity of improvements done in PHP 5.4 for arrays; +* support of keys in list, for key-values arrays; +* a better way to handle octal representation; +* a very restrictive use of $this in class to avoid side effects due to random-weird reassignements; +* etc. + +# Okay, how can I test those wonderful things? + +You first want to know that you shouldn't use it in production environments! It's a RC for duck's sake! And to answer: + +* compile it from source, this [guide](http://php.net/manual/fr/install.windows.building.php) explains it very clearly; +* use phpenv, which is basically compiling it from source in an automated way. + +I recommend using the second solution on dev environments since it's not rare professionnally to handle projects not using same PHP versions. PHPEnv allows you to run multiple versions of PHP in CLI, based on the project. I'll certainly do a post to explain how to plug Nginx, PHP-FPM and PHPEnv to have multiple versions of PHP in a HTTP way (on dev env, right ? RIGHT ?!). + +# Conclusion + +This version, even being minor, comes with a lot of changes. + +I'm aware that PHP is not the perfect language, and has many missing features. But we can hope that, one day, we will have native annotations or enumerations for example. The community is constantly moving, and tries really hard to improve PHP and its reputation. + +If you want to know more about PHP 7.1 features, I invite you to read [RFC's](https://wiki.php.net/rfc#php_71). + +See you later for an article on PHP 7.2, if features are good enough to be listed ;) + + \ No newline at end of file diff --git a/_posts/2016-10-05-cohabitation-de-plusieurs-versions-de-php.md b/_posts/2016-10-05-cohabitation-de-plusieurs-versions-de-php.md new file mode 100644 index 000000000..a59ed66f7 --- /dev/null +++ b/_posts/2016-10-05-cohabitation-de-plusieurs-versions-de-php.md @@ -0,0 +1,137 @@ +--- +layout: post +title: Cohabitation de plusieurs versions de PHP +author: aandre +date: '2016-10-05 10:23:54 +0200' +date_gmt: '2016-10-05 08:23:54 +0200' +categories: +- Php +tags: [] +--- +Dans un contexte professionnel, il n'est pas rare de travailler sur divers projets. Sur ces divers projets, il n'est pas rare non plus que ceux-ci ne fonctionnent pas avec les mêmes versions de PHP. C'est d'ailleurs pour cette raison que les IDE vous proposent de sélectionner la version de PHP (et c'est le cas pour de nombreux langages), afin de vous informer si vous utilisez une fonctionnalité qui n'est pas encore supportée, ou à l'inverse dépréciée, ou voire même inexistante. + +Quid de la partie tests ? Dans cet article, je vous propose de faire cohabiter plusieurs versions de PHP, avec une granularité par projet, aussi bien en console qu'au travers d'un serveur HTTP. + +# Étape 1 : installer PHPEnv + +Avant toute chose, sachez qu'il existe de nombreux outils qui permettent de faire cohabiter plusieurs versions de PHP. Le but n'est pas de faire un listing de tous les outils. Pour ma part j'ai choisi PHPEnv, dans une ancienne version, étant donné que la nouvelle ne semble pas fonctionner sur ma machine. + +Selon votre OS et vos préférences, vous aurez peut-être donc des adaptations à faire. Dans tous les cas le fonctionnement est toujours assez similaire, ces outils vont automatiser la compilation de PHP depuis les sources. Sur une machine décente, cela prendra une quinzaine de minutes. + +Clonez le projet dans votre home (ou l'outil le plus récent, comme je l'expliquais : https://github.com/phpenv/phpenv) : + +```bash +$ git clone git://github.com/humanshell/phpenv.git ~/.phpenv +``` + +# Étape 2 : lister les versions de PHP + +Lister les versions PHP disponibles à la compilation, c'est toujours à jour puisque l'outil analyse directement les dépôts git de PHP : + +```bash +$ cd .phpenv +$ ./bin/phpenv install --releases +``` + +Dans mon cas, au moment où j'écris ces lignes, nous avons : + +```bash +... +php-7.0.9RC1 +php-7.1.0RC1 +php-7.1.0RC2 +php-7.1.0RC3 +php-7.1.0alpha1 +php-7.1.0alpha2 +php-7.1.0alpha3 +php-7.1.0beta1 +php-7.1.0beta2 +php-7.1.0beta3 +``` + +# Étape 3 : compiler une version de PHP + +La dernière fois que j'évoquais [PHP 7.1](http://blog.eleven-labs.com/fr/php-7-1-pour-les-null/) c'était la première RC, donc je vais en profiter pour installer la beta 3, c'est tout simple (j'ai précédé les logs par les horaires, pour que vous voyiez le temps que ça peut prendre) : + +```bash +$ ./bin/phpenv install php-7.1.0beta3 +(12h19) + [Cloning]: source from php-src Github repo +(12h23) +php.ini-development gets used as php.ini + +Building php-7.1.0beta3 + + [Fetching]: latest code from Github repo + [Branching]: for a clean build environment + [Configuring]: build options for selected release +BUILD ERROR +Switched to a new branch 'build' configure: WARNING: unrecognized options: --with-mysql configure: WARNING: You will need re2c 0.13.4 or later if you want to regenerate PHP parsers. configure: error: Cannot find OpenSSL's