KrISS feed 8.7 - A simple and smart (or stupid) feed reader. By Tontof
  • Monday 11 August 2014 - 15:08

    Il faut que tu travailles bien à l’école pour réussir dans la vie.

    Il faut que tu travailles bien et beaucoup pour réussir ta carrière.

    Il faut que tu aies une Rolex à ton poignet avant 50 ans pour réussir ta vie.

    Il faut… pour réussir…

    Je pense que nous avons tous entendu cette ritournelle à minima une fois dans notre vie, même si parfois, elle est exprimée de manière presque subliminale.

    Pendant longtemps, je me suis interrogé sur la signification de ce « réussir » que nos parents, les politiques et la société nous servent à toutes les sauces sous une forme ou sous une autre.

    En effet, je ne me sentais pas à l’aise avec la définition implicite qui émane de tous ces leitmotivs récurrents qui semblent systématiquement attacher à la notion de réussite l’argent, le travail et le matérialisme.

    Et puis, au détour d’un film, j’ai eu « ma » définition de la réussite, celle qui correspond à mes valeurs, qui est en accord avec mes convictions et avec laquelle je suis parfaitement en phase :

    Réussir, ce n’est pas toujours ce qu’on croit.

    Ce n’est pas devenir célèbre, ni riche ou encore puissant.

    Réussir, c’est sortir de son lit le matin et être heureux de ce que l’on va faire durant la journée, si heureux qu’on a l’impression de s’envoler.

    C’est travailler avec des gens qu’on aime.

    Réussir, c’est être en contact avec le monde, et communiquer sa passion.

    C’est trouver une façon de rassembler des gens qui n’ont peut-être rien d’autre en commun qu’un rêve.

    C’est se coucher le soir en se disant qu’on a fait du mieux qu’on a pu.

    Réussir, c’est connaître la joie, la liberté et l’amitié.

    Je dirais que réussir, c’est aimer.

    Et si je me base sur cette définition, aujourd’hui, je n’ai pas réussi, et malheureusement à plus d’un titre.

    Il est donc plus que temps que je fasse en sorte d’y parvenir !

  • Monday 01 September 2014 - 08:33

    Il y a quelques jours, Johannes Shlüter a donné une conférence à propos du fonctionnement de phpng.

    Pour ceux qui l’ignorerait, Johannes a été le « release master » de la version 5.3 du langage, et phpng sera le remplaçant du Zend Engine 2 dans ce qui sera PHP 7, qui correspond à la prochaine version majeure du système et qui prendra donc la suite de PHP 5.

    Vous avez bien tout suivi ? Si ce n’est pas le cas, relisez le paragraphe précédent en faisant abstraction de vos connaissances en arithmétique élémentaire…

    Le mariage de PHP 7 et de phpng devrait être consommé dans approximativement un an, d’après Zeev Suraski.

    Grâce à phpng, PHP 7 devrait donc apporter un gain de performance très significatif, comme d’habitude avec chaque nouvelle version du langage…

    Or, cette date de livraison de PHP 7 a plus ou moins été décidée arbitrairement par les promoteurs de phpng, et d’autres développeurs, à commencer par ceux qui mettent quotidiennement les mains dans le code du langage, doute très fortement qu’un tel délai soit tenable.

    Et comme à ma connaissance, la feuille de route fonctionnelle relative à PHP 7 est inexistante même si beaucoup ont des idées sur ce qui devrait être son contenu, je ne peux que partager leur opinion, car je vois mal comment une date de livraison peut avoir été définie alors que la masse de travail à réaliser est inconnue.

    Comme le disent si bien deux comiques français, il y a en qui ont essayé, et ils ont eu des problèmes.

    De plus, phpng est apparemment lui-même loin d’être finalisé, puisqu’il semble manquer de cohérence et que sa documentation est succincte pour un code de cette complexité.

    There is almost no documentation, the APIs are not clean or inconsistent […] but having two separate zpp, same area's functions mixing use of zend_char and char (creating hard to catch bugs, not always catch-able at compile time f.e.)

    Et enfin, même si ce délai de livraison était réaliste, il faudrait à minima que les développeurs du langage produisent une version 5.7 du langage pour respecter le rythme prévu.

    Durant un an à minima, si tout se passe bien, les développeurs de PHP devront donc travailler sur deux versions divergentes du code techniquement parlant puisque l’une utilisera la dernière version du Zend Engine 2 et l’autre phpng.

    Et de plus, phpng évoluera certainement pendant ce temps de son côté, car même s’il a énormément progressé depuis qu’il a été présenté par Zend, il subira encore des évolutions significatives, ne serait-ce que pour rester compatible avec les modifications apportées au Zend Engine 2.

    Or, le fiasco de PHP 6 a, entre autres choses, démontré que la gestion de deux branches très différentes du code du langage est un exercice plus que périlleux pour les développeurs.

    J’ai donc l’impression que contrairement à ce que je pensais, ces derniers n’ont pas vraiment tiré les leçons de l’échec du développement de PHP 6, et que malheureusement l’histoire va une nouvelle fois se répéter, d'autant que les luttes d'influences au sein d'internals@ ont été plus qu'intense à ce sujet.

    Et même si je peux comprendre la pression et le danger économique que représente le développement de HHVM pour Zend, j’ai à contrario vraiment du mal à comprendre que la plupart des développeurs du langage ne voient pas le danger que représente cette stratégie.

    Donc, lorsque j’apprends que Johannes donne des conférences à propos de phpng, un produit non finalisé qui ne sera intégré au sein du langage que probablement dans plusieurs années, je ne peux m’empêcher de rire un peu jaune, et j’espère que cela intéressera suffisamment les développeurs présents à sa conférence pour qu’ils décident de participer au mariage de phpng avec PHP 7 pour que je n’ai pas à faire dans trois ans sa nécrologie.

  • Tuesday 09 September 2014 - 13:28

    Si les livres relatifs à l’agilité du point de vue du développeur sont légion, ceux l’abordant du point de vue fonctionnel sont assez rares.

    Or, l’agilité mise avant tout sur la bonne collaboration de toutes les parties prenantes d’un projet pour parvenir à sa concrétisation.

    Il est donc primordial que chaque intervenant dispose d’une vision claire des concepts agiles et sache les exploiter au mieux dans son domaine de compétence.

    Le livre de Thierry Cros intitulé Spécifiez agile a donc éveillé très fortement ma curiosité lorsque j’ai découvert son existence, à tel point que je me le suis offert en me disant que cela me permettrait peut être de mieux faire passer l’agilité auprès des experts fonctionnels avec lesquels je tentais de travailler à l’époque.

    Voici donc ma critique de ce livre qui, je l’espère, permettra à Thierry d’améliorer son ouvrage.

    Il commence d’ailleurs son livre en nous expliquant la façon dont il a été conçu, c’est-à-dire de manière agile, et donc en nous encourageant à lui fournir un retour afin qu’il puisse l’améliorer.

    L’existence de ce billet implique que cette explication atteint parfaitement son objectif, en plus d’humaniser l’ouvrage puisque Thierry nous explique en prime ce qui l’a poussé à se lancer dans l’écriture de ce livre et le chemin qu’il a suivi pour parvenir à sa publication.

    Cette humanisation se poursuit d’ailleurs dans les deux chapitres suivants, Thierry nous y expliquant dans le premier le rôle du « product owner » tandis qu’il pose les bases d’une mise en application de l’agilité en terme fonctionnel dans le cadre d’un cas pratique théorique.

    Mais malheureusement, son discours devient beaucoup plus académique dans les chapitres suivants, et je le regrette.

    En effet, je pense que la transmission de son message aurait été beaucoup plus efficace s’il s’était servi de cette base de départ pour illustrer au moins une partie des concepts présentés par la suite de son livre, sinon la totalité.

    Ainsi, la digestion de cette masse d’information serait certainement plus facile et accessoirement favoriserait potentiellement sa mémorisation en offrant des repères mnémoniques.

    Cela ne veut cependant pas dire que les chapitres suivants sont pour autant inintéressants, bien au contraire.

    Le vocabulaire agile relatif à l’aspect fonctionnel du développement d’un logiciel est parfaitement expliqué, associé à une dose pertinente de concept psychologique relatif à la communication dans le cadre d’un groupe.

    Malheureusement, les références illustrant ces concepts sont bien souvent succinctes, mais je pense avoir été handicapé à ce sujet par le fait que je n’utilisais pas la version numérique du livre qui doit, contrairement à la version papier, contenir des liens vers les articles correspondants.

    Les chapitres relatifs à la « valeur métier » ainsi qu’à la « vision » du produit sont ceux qui m’ont le plus interpellé, et pas uniquement parce que dans mon contexte de l’époque, ces deux concepts étaient complètement ignorés.

    En effet, d’après ce que j’ai pu constater au cours de ma carrière ou des discussions que j’ai pu avoir à ce sujet, les développeurs savent bien souvent plus ou moins approximativement ce qu’ils doivent faire, mais ne savent en général pas pourquoi ils doivent le faire. En clair, ils n’ont que trop rarement connaissance de l’objectif que leur travail est censé permettre d’atteindre à un niveau plus global (bien souvent parce que le client n’en a lui même qu’une vague idée, mais c’est un autre débat).

    Or, je suis persuadé qu’un développeur doit savoir à la fois ce qu’il doit faire et pourquoi il doit le faire afin de pouvoir trouver dans la combinaison de ces deux informations la motivation pour sortir de sa zone de confort, se surpasser, évoluer et ainsi ne plus être juste un « pisseur de code » bête et méchant.

    Ainsi, le client y trouve son compte, car son produit répond mieux à ses besoins et le développeur gagne en compétence et en estime de soi, car il sait à la fois à quoi et comment il a contribué.

    Et enfin, la vision peut permettre aux développeurs de résoudre leur problème en plus d’être pour eux un redoutable outil d’aide à la décision.

    Ainsi, si la vision du produit met en avant la performance, ils choisiront les technologies qu’ils mettront en œuvre en conséquence, et lorsqu’un consensus ne peut être atteint au sein des développeurs sur un point ou un autre, se référer à la vision peut permettre de dénouer la situation en remettant les choses en perspective par rapport à l’objectif à atteindre.

    Il est donc important que les fonctionnels et les développeurs disposent d’une vision commune du produit correspondant à celle du client, et Thierry insiste donc à juste titre sur ces deux notions bien souvent trop occultées durant la vie d’un projet.

    Et pour le coup, j’aurais trouvé très pertinent d’illustrer à minima ce chapitre relatif à la vision à l’aide du cas pratique mis en place dans le second chapitre.

    J’ai également aimé que Thierry évoque dans son ouvrage la problématique de la prise de décision et présente une méthode permettant d’y parvenir en y impliquant tous ceux devant y prendre part, tout en n’occultant pas le fait que cela n’est pas simple pour autant, tant s’en faut.

    Au passage, pour ceux que la problématique de la prise de décision intéresse, la conférence d’Olivier Sibony à ce sujet est remarquable.

    L’un dans l’autre, j’ai donc trouvé mon compte en lisant le livre de Thierry, et je ne peux donc qu’en recommander la lecture aux développeurs ou aux fonctionnels qui veulent améliorer leur façon de travailler avec « celui d’en face », qu’il soit développeur ou fonctionnel, ne serait-ce que parce qu’il permet à un développeur de mieux comprendre les contraintes et la façon de travailler d’un fonctionnel dans un tel contexte, et réciproquement.

    En effet, si la forme du livre serait à mon avis beaucoup plus agréable si l’ambiance des deux premiers chapitres était propagée aux autres, reste que son fond est plus qu’intéressant puisqu’il propose des solutions et des pistes à suivre pour résoudre des problèmes que l’on rencontre communément lorsque l’on développe un logiciel.

    Alors, à 23 € ou à partir de 7 € au format numérique, faites-vous une faveur, offrez ou offrez-vous Spécifiez agile  (et non, ce billet n'est pas sponsorisé) !

  • Wednesday 08 April 2015 - 11:47

    Je sais bien que cela peut sembler un peu mesquin de sortir ce blog de son sommeil pour faire savoir qu’à la suite d’un licenciement économique, je suis à la recherche d’un travail sur Lyon et ses alentours, mais comme le dit l’adage populaire : aux grands maux, les grands remèdes.

    Donc, si d’aventure vous cherchez un développeur PHP agile avec 15 ans d’expérience, qui pratique le TDD, qui dispose de solides bases en architecture logiciel et en qualité logiciel, qui a envie de faire partager ses connaissances et qui aime relever des défis techniques, je suis votre homme !

  • Wednesday 28 October 2015 - 09:15

    Le dernier billet de ce blog a été pendant bien trop longtemps je suis à la recherche d’un emploi.

    Je dis bien trop longtemps, car depuis maintenant pratiquement six mois, je travaille pour la société Norsys.

    Ceux qui me connaissent, qui prendraient la peine de faire une recherche sur cette entreprise et qui s’arrêteraient aux premiers résultats retournés par leur moteur de recherche favori seront potentiellement surpris de mon choix.

    En effet, Norsys est ce que le Syntec Numérique a décidé de pudiquement renommer il y a deux ans Entreprise de Services du Numérique, ou ESN, l’abréviation SSII pour Société de Service en Ingénierie et Informatique étant certainement devenu trop négativement connotée à son goût.

    Et ce n’est un secret pour personne, je ne porte vraiment pas ce type de société dans mon cœur, pour tout un tas de raisons dont je suis prêt à débattre autour de plusieurs bières (si c’est vous qui les offrez, parce qu’il me faudra une motivation assez forte pour que j’accepte de me lancer dans ce type de discussion).

    Mais alors, pourquoi ai-je décidé de rejoindre cette société, me direz-vous ?

    Il y a deux réponses à cette question.

    Tout d’abord, j’ai constaté « in situ » que Norsys est très loin de l’idée que je me fais des SSII « classiques », car elle ne considère pas ses salariés comme des ressources consommables et n’est pas prête à tout sacrifier pour le compte de la sacro-sainte rentabilité.

    Au contraire, l’entreprise cherche à faire au mieux pour tout le monde, et lorsque je dis « tout le monde », cela englobe aussi bien le collaborateur que l’entreprise, le client, la société civile, ainsi que l’environnement et la planète.

    Ensuite, j’avoue que j’ai eu de très gros doutes lorsque j’ai entendu ce discours, mais mon arrivée chez Norsys est également le résultat d’une rencontre avec une personne qui a une vision claire de son objectif, de ceux de son entreprise et des moyens nécessaires pour les atteindre. De plus, il m’a donné suffisamment d’informations pour comprendre comment je pouvais aider à atteindre ces objectifs et m’a raconté suffisamment d’anecdotes pour susciter en moi l’envie de savoir si tout cela n’était pas juste un discours marketing bien rodé.

    L’un dans l’autre, j’ai donc décidé d’être payé pour voir, et j’avoue que depuis, je n’ai pas été déçu puisque j’ai pu constater que tout cela n’était pas que du vent et que les nœuds borroméens qui servent de logo à Norsys n'ont pas été choisis uniquement pour leur esthétisme puisqu’ils incarnent effectivement les valeurs de la société et surtout la façon dont elle souhaite les concilier aujourd’hui et demain.

    Tout n’est évidemment pas parfait, mais Norsys a une réelle volonté de faire progresser l’intérêt commun en s’améliorant à l’aide de l’expérimentation et du feed-back de ses employés et de ses clients.

    Et ça fait du bien !

    Après 15 ans d’expérience professionnelle durant lesquelles je me suis toujours refusé à travailler pour une SSII, car elles étaient pour moi le Mal incarné, je me sens à nouveau à ma place au sein de l’une d’elles, et avec en prime des perspectives d’évolution correspondant à mes convictions et mes envies.

    S’il y a une leçon à retenir de tout cela, c’est qu’il faut vraiment ne jamais préjuger de rien (et qu’accessoirement, qu’il n’y a que les cons qui ne changent pas d’avis).

  • Wednesday 28 October 2015 - 14:13

    J’ai oublié de vous dire que je donnerais demain une conférence à la Blend Web Mix à propos de la programmation orientée « vers l’est », également connue sous le nom de programmation orientée objet.

    Cette conférence est la synthèse du (long et difficile) chemin que j’ai parcouru en 18 mois lorsque j’ai remis en question radicalement ma façon de programmer et elle représente donc à mes yeux un retour d’expérience très intéressant pour tous les développeurs.

    Si vous pensez que la programmation orientée objet ne tient pas ses promesses ou qu’elle est parfois (ou souvent) un frein ou un obstacle plutôt qu’un outil qui facilite votre quotidien de développeur, je vous invite donc à venir m’écouter et à en discuter demain 29 octobre à partir de 12 h en salle « Gratte Ciel ».

    Il y aura une moustache, un mémé, une paire de menotte, Sangoku, des verres d'une marque suédoise ainsi qu’un soupçon de biologie et nous aurons faim, il n'y aura pas de chat et aucune blague à propos de Retour vers le futur, mais j’ai vraiment une histoire intéressante à vous raconter !

  • Thursday 29 October 2015 - 16:23

    Comme je l’ai annoncé dans mon précédent billet, je viens de donner pour la quatrième fois ma conférence à propos de la programmation orientée objet « vers l’est » dans le cadre de Blend Web Mix.

    La forme a légèrement évolué au cours de ces quatre itérations, mais le fond est resté exactement le même et ceux qui n’ont pu y assister pourront donc consulter l’histoire correspondante que j’avais publiée après le PHP Tour luxembourgeois.

    J'avoue être assez satisfait de ma prestation, car malgré un format imposé plus court que celui pour lequel la conférence a été conçue, je suis parvenu à ne pas dépasser le temps imparti et même à avoir suffisamment de temps pour répondre à quelques questions.

    Évidemment, pour y parvenir, j'ai du instiller plus d'énergie et aller plus rapidement à l'essentiel que lors de mes précédentes prestations, mais j'ai l'impression que cela a eu un impact positif.

    J'ai été relativement surpris par l'importance de l'auditoire puisque j'estime au doigt mouillé qu'une soixantaine de personne sont venues écouter ce que j'avais à raconter, alors que mon auditoire habituel était d'une vingtaine de personnes.

    Renseignement pris, il semble que le fait de passer après une conférence technique sans réelle alternative au niveau de la programmation a aidé, ainsi que le titre de ma conférence qui semble avoir à minima intrigué, même si quelqu'un m'a avoué qu'il s'attendait à un retour d'expérience sur un voyage en asie et non à une réflexion sur la pratique de la programmation orientée objet.

    Il est vrai que le titre est particulier et à double tranchant, car il peut rebuter autant qu'attirer, mais j'aime son originalité et je n'ai pas envie de tomber dans le classicisme souvent de mise pour ce type de conférence.

    J'ai aussi une nouvelle fois constaté qu'il y a un vrai point de rupture dans ma conférence au moment ou je passe de l'introduction à la présentation du concept, et j'en ai eu la confirmation par l'un des auditeurs qui était déjà présent lors de la première itération et qui avait également ressentie le décalage qui se produit à ce moment à l'époque.

    En soi, ce n'est pas un problème car la conférence a été construite en fonction de ce point de rupture et j'ai vraiment eu l'impression que tout le monde parvenait à raccrocher ses wagons par la suite grâce à cela, mais peut-être faudrait-il que je trouve un moyen d'en atténuer l'effet pour la prochaine itération… peut-être à Lyon, dans le cadre d'un apéro PHP ou d'un cycle de conférence !

  • Friday 06 November 2015 - 16:13

    J’ai oublié de vous dire que je vais me livrer à un exercice inédit pour moi lors du prochain forum PHP les 23 et 24 novembre 2015.

    En effet, l’AFUP, traditionnelle organisatrice de l’événement, me renouvelle à cette occasion sa confiance puisqu’elle a retenu ma proposition de conférence concernant atoum.

    Cependant, cette conférence sera très différente de celle que j’ai déjà eu l’occasion de donner à son sujet, puisque contrairement aux précédentes, elle ne se focalisera pas sur l’outil en tant que tel, mais sur ce qu’il s’est passé au cours de son développement depuis sa naissance à aujourd’hui.

    Je souhaite en effet parvenir à réaliser au cours de ma conférence ce que l’on pourrait appeler une rétrospective agile du projet de sa naissance à aujourd’hui, en temps réel et avec la participation active du public, dans l’optique de parvenir à définir collectivement les actions à mener pour l’améliorer à tout point de vue.

    Ce sera aussi l’occasion pour moi d’expliquer ma vision du projet, les objectifs que je m’étais fixés, l’impact qu’il a eu sur ma vie personnelle et professionnelle et également le bon moment pour préciser très officiellement mon positionnement actuel en son sein.

    L’objectif de cette conférence estdonc ambitieux et même si sa forme est encore loin d’être figée, je sais déjà que j’ai besoin de l’aide de tous ceux qui s’intéressent de près ou de loin à atoum.

    Une bonne rétrospective nécessite en effet la présence des développeurs du produit (je peux déjà vous dire que certains seront dans la salle) mais aussi celle du client, et le client d’atoum, c’est vous.

    Si vous n’avez pas déjà réservé votre place pour ce forum PHP qui se déroulera à Paris au Beffroi de Montrouge, je vous invite donc à le faire au plus vite pour que nous puissions discuter ensemble, en tête à tête et en toute franchise, de ce que représente atoum aujourd’hui et de ce qu’il sera potentiellement demain, sachant qu'en plus, il y a plein d'autres conférences semblant très intéressantes au programme, avec notamment un cycle intégralement dédié à PHP 7.

    Et si pour une raison ou une autre, vous ne pouvez vous y rendre, ce n’est pas grave, car une rétrospective agile est basée sur le feedback.

    Or, le feedback peut prendre bien des formes, et en conséquence, si vous souhaitez participer à cette conférence, je vous propose d’aider le projet de deux façons différentes et non exclusives.

    Si votre entreprise utilise atoum, vous pouvez m’envoyer son nom via mon compte twitter et #atoum (en sachant que soit elle sera citée durant la conférence, soit son nom figurera sur mes supports).

    Vous pouvez également m’envoyer, toujours par le même canal de communication, un ou plusieurs mots qui représente l’outil de votre point de vue, qu’il soit positif ou négatif, par exemple « inutile », « PHPUnit rocks » ou « facile à utiliser » (un troll est caché parmi ces exemples, saurez-vous le débusquer ?).

    Et si vous avez un feedback à me donner qui ne peut prendre l’une de ces deux formes, mon adresse de courrier électronique n’est pas très difficile à trouver.

    On se voit le 23 novembre à 15 h 30 à Paris pour reparler de tout cela ?

  • Wednesday 02 December 2015 - 18:17

    Aujourd’hui, j’ai fait un brew install (je sais, je suis un dingue) qui a mis à jour la bibliothèque icu, utilisée par l’extension int de PHP.

    Du coup, PHP est devenu inutilisable sur mon poste de travail puisque j’obtenais systématiquement la sympathique erreur suivante :

    # php -v
    dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.55.dylib
    Referenced from: /usr/local/bin/php
    Reason: image not found
    Trace/BPT trap : 5
    

    L’erreur peut semble quelque peu incompréhensible au premier abord, mais l’expérience m’a appris qu’elle veut tout simplement dire que l’exécutable PHP n’est pas capable de localiser la bibliothèque libicui18n.55.dylib à l’emplacement indiqué lors de sa compilation, ce qui est logique vu que brew a supprimé le fichier concerné au profit de libicui18n.56.dylib (et oui, les bibliothèques qui contiennent leur numéro de version dans leur nom sont une plaie).

    Et la solution est très simple, puisqu’il suffit de compiler une nouvelle fois PHP depuis ses sources en indiquant le nouveau chemin d’accès à la bibliothèque concernée lors de l’appel à ./configure.

    En effet, pour ceux qui ne le sauraient pas, une compilation classique de PHP sous UNIX se fait en trois étapes :

    1. Un appel à ./configure avec diverses options permettant de définir les chemins d’accès aux fichiers ou répertoires nécessaires à la compilation, l’installation et l’exécution de PHP ainsi que les extensions qui doivent être intégrées dans les binaires créés (au passage, ./configure --help est l’ami de ceux qui se lancent dans l'exercice pour la première fois) et qui génère le fichier Makefile correspondant ;
    2. Un appel à make qui utilise le fichier Makefile précédemment généré qui génère les différends binaires ;
    3. Un appel à make install qui provoque l’installation des binaires créés à l’étape précédente ainsi que celle de la documentation et des différents utilitaires associés à PHP (comme phpize qui permet de configurer les extensions PHP pour la version de PHP qui vient d’être installée).

    Sauf que je fais une configuration très spécifique de PHP lorsque je le compile et mon appel à `./configure` est donc relativement complexe.

    Lorsque je dois compiler PHP, j’utilise donc systématiquement la commande php -i | grep configure pour récupérer la commande configure qui a été utilisée pour compiler la version de PHP actuellement installée sur mon poste.

    Mais aujourd’hui, cette version était inutilisable et que PHP n’était donc plus en mesure de me fournir la commande configure que j’avais utilisé pour le compiler.

    Mais heureusement pour moi, configure génère dans le répertoire contenant les sources à compiler un journal nommé ./config.log qui contient entre autres le détail du dernier appel à configure.

    J’ai donc pu compiler PHP sans devoir reconstruire de zéro la commande suivante :

    ./configure --disable-all --sysconfdir=/private/etc --enable-xml --enable-cli --with-config-file-path=/etc --enable-type --with-libxml-dir=/usr --with-pare-regex --enable-pear --enable-hash --enable-json --enable-libxml --enable-session --enable-dom --enable-sockets --enable-tokenizer --enable-simpleml --enable-soap --enable-posix --enable-pcntl --with-libedit --enable-filter --with-sqlite3 --enable-mbstring --with-mysqli=mysqlnd --with-curl --with-openssl --with-ldap --enable-xmlwriter --enable-pod --with-pod-mysql --enable-into --with-apxs2 --with-icu-dir=/usr/local/Cellar/icu4c/56.1 --with-glib --with-crypt --enablte-opcache --enable-phpdbg
    
  • Wednesday 17 February 2016 - 11:07

    C'est l'histoire d'un mec qui exécute dans son terminal la commande phpmetrics --report-html=~/metrics src, qui se retrouve en conséquence avec un répertoire ~/ dans son répertoire courant et qui fait donc un rm -rf ~/ pour le supprimer, pour aller ensuite faire une offrande à Steve Jobs pour avoir permis le développement et la commercialisation de Time Machine.

    Évidemment, toute ressemblance avec des faits réels ne serait que pure et fortuite coïncidence, et ne faites surtout pas cela chez vous (ou alors, ayez une sauvegarde récente de votre répertoire d'accueil sous la main).