INI directives are evil!

April 28, 2016 php, english, configuration, ini

Cet article est aussi disponible en français.

A few times, while evolutions were discussed for PHP 7, someone suggested a new feature could be optionnal1, depending on an INI configuration directive — the idea being each user could then enable it or not.

Still, the idea of directives that could change, sometimes deeply, the behavior of a programming langague… It scares me!


For a moment, let’s think about a language2 developped to facilitate creating HTML forms and dealing with their data.

To help beginners who know nothing about security, and as using MySQL to store data is what people do, this language’s developpers set up an option that, once enabled, automatically causes an \ to be added in front of all ' quotes passed as input3 (GET/POST/…).

Of course, some sysadmins immediately enable this directive, as it considerably improves security4 by preventing some SQL injections. But other admins disable it, as dealing with their data is each developper’s responsibility: the language must not modify those on the fly!

And now, a given application works flawlessly on one server, but will totally screw up on another one — either injecting some \ everywhere, or exploding on half SQL queries! All that because it won’t have been specifically developped to take into account different combinations of configuration options.

You were dreaming about this? Welcome to magic quotes5 hell!

In the same way, do you remember register_globals, with variables magically appearing in your scripts, when that directive was enabled? Wasn’t it hell too?


Let’s come back to this century: each time a configuration directive is added to PHP6, it means:

  • Several code branches must be tested, debugged and maintained. Maintenance, for a feature in a language as used PHP, goes for 10 years. And more!
  • More documentation to write, on one hand — and to read and understand, on the other hand.
  • More work, to ensure each application7 works with each combination of parameters.
  • In case of a problem, how long before realising some strange behavior is caused by an unusual or unexpected value for a specific configuration directive? Or, worse, by an unusual combination of values for several odd configuration directives?

Good thing is, developpers working on PHP know about those problems and tend to avoid adding new INI directives (of this kind) without solid reasons. They also provide two php.ini-development and php.ini-production files, with good configuration values — and you should stay close to those.


In any case, before suggesting « but they could allow us to enable or not this feature with a simple INI directive » for ideas as critical as a weak or strict typing mecanism, ask yourself: do you really want two languages with very distinct behaviors, and applications and libraries that work only on some combinations of configuration values?

And now, let’s repeat after me: « INI directives are evil! »



  1. Because it might break backward-compatibility, because it would change the way of the language, because some don’t like it, because some don’t want it… 

  2. I’ll let you guess which language I’m thinking about ^^. But what I’m writing here, maybe generalizing a bit, can be applied to others! 

  3. Please note this is my interpretation of things, many years after the events: I’m not sure I even knew about PHP when these choices were made. Maybe things happenned a bit differently! But the effect (and perception some have of the language) remains! 

  4. Or not (that much?), actually… 

  5. As PHP aims to minimize BC-break between each successive version, years have been necessary before we could get rid of this good-bad idea — and the accompagnying configuration and behavior differences! 

  6. It’s also true for pretty much any piece of software, BTW ;-) 

  7. Especially for software, open-source or not, that can be downloaded and installed on many servers — with sysadmins who all have their own way of configuring them! 

Le manque de sommeil, cette autre forme de dette

26 avril 2016 travail, humeur

En tant qu’individus et en tant que profession, nous avons trop souvent tendance à oublier les bienfaits de bonnes nuits de sommeil, ainsi que les effets néfastes de la fatigue sur notre productivité et sur la qualité de nos réalisations — ou sur notre santé !

Week 1: Needs Recharging
Photo par Christopher Rodriguez sur Flickr, CC-BY-NC-ND.


Arriver au bureau fort tôt le matin, en n’ayant donc dormi que quelques heures, pour réaliser une mise en production majeure en évitant du down-time sur les heures « importantes » de la journée1, signifie :

  • Qu’il faut avoir une équipe de taille suffisamment importante pour être en mesure de garder en réserve quelques personnes qui soient fraiches et disponibles en heures « normales » pour ensuite gérer les éventuels problèmes liés à cette mise en prod.
  • Envoyer dormir2 ceux qui étaient là tôt — sinon, ils seront peu efficaces jusqu’à la fin de la semaine.

Ou alors, il faut accepter d’être sous-efficace pendant les jours suivants — ce qui peut être gênant si quelques imprévus surviennent suite à cette opération majeure3.


Commencer une mise en production à 22h après une journée de travail, qu’elle dure toute la nuit puis toute la journée4, et ensuite s’attendre à ce que les équipes soient opérationnelles le lendemain et jusqu’à la fin de la semaine ?

Il ne faut pas ensuite s’étonner s’il y en a un ou deux qui sont un peu ronchons en revenant au boulot à 9h après deux jours et une nuit au boulot sans dormir5, suivis seulement d’une courte nuit — sans avoir rien fait d’autre pendant pas loin de 48h que bosser et trop peu dormir !


Après ces cas sortant heureusement de l’ordinaire, passons à une idée trop classique : demander aux équipes de bosser de longues journées, de manière régulière et/ou pendant une longue durée6 ?

Cela signifie souvent qu’il y a un réel problème au niveau de la gestion du projet ou de la manière dont il a été vendu — et ça ne devrait carrément pas être aux équipes de développement de sacrifier leur santé et leur vie personnelle/familliale pour compenser !

J’ajouterais que, au bout d’un moment, la productivité baisse. Elle va même jusqu’à tomber plus bas que celle correspondant à des journées normales… Et il devient alors nécessaire d’aligner encore plus d’heures pour compenser. Et donc la productivité baisse à cause de la fatigue (et de la lassitude) et donc…

D’une certaine manière, travailler trop pendant quelques jours, c’est une forme d’investissement — et ne pas dormir assez et la fatigue qui s’accumule, c’est la dette correspondant. Dette qu’il faudra impérativement rembourser pour revenir à un bon niveau d’efficacité !


À l’inverse, c’est également à nous de savoir être raisonnables : arriver régulièrement au bureau en sachant à peine garder les yeux ouverts parce qu’on a joué à WOW7 ou regardé des séries jusqu’à 3h du matin, ce n’est pas très correct.

À mi-chemin entre la vie professionnelle et la vie personnelle, je pense également aux hackatons d’un week-end, où la tentation de dormir le moins possible peut être forte… Voire même où ne pas dormir est encouragé et considéré comme un acte héroïque… Alors qu’une bonne nuit de sommeil entre deux journées intenses fait tellement de bien !


Bien sûr, à chacun de connaître ses limites et de savoir de combien d’heures de sommeil par nuit il a besoin pour fonctionner. Mais ensuite, à lui de s’y tenir pour être en forme pour la journée !

Et, pour finir : oui, des fois, de temps en temps et occasionnellement, bosser / coder / écrire / jouer jusqu’à l’épuisement, ça peut être sympa aussi ;-)


  1. Les heures où une partie importante du CA de la journée se fait, ou les heures où un site down serait remarqué par les clients et utilisateurs — ce qui sont des définitions tout à fait valables de « heures importantes ». 

  2. Et qu’ils dorment, pas qu’ils aillent faire la fête toute la journée ! 

  3. Même si, bien sûr, nous savons tous qu’il n’y a jamais d’imprévus dans nos métiers ^^. 

  4. À la réflexion quelques années après et avec un peu plus d’expérience, nous aurions peut-être pu procéder autrement, de manière un peu plus souple (ou « agile »), pour peut-être réduire la durée de cette mise en production et éviter qu’elle ne dure près de 24h — en même temps, il s’agissait réellement d’une migration majeure, et pas d’un simple déploiement quotidien ;-) 

  5. Je garde néanmoins un fort bon souvenir de cette expérience : j’étais avec des collègues qui savaient ce qu’ils faisaient — et le sentiment d’accomplissement à la fin (ou le lendemain ^^) est tellement agréable ! 

  6. Quelques jours de rush de temps en temps, ça arrive, je n’ai pas de problème avec ça. Mais quand ça se transforme en tous les jours pendant plusieurs semaines, ça me chagrine un peu plus ;-) 

  7. Ou à un autre jeu à la mode en ce moment : je n’ai jamais tellement joué et je ne suis plus réellement au fait des jeux qui occupent les soirées de certains d’entre nous, à présent. Mais ça vaut aussi pour coder la moitié de la nuit ;-) 

Un intersticiel, un overlay, une popin ? « Fermer l'onglet » et au-revoir !

18 avril 2016 humeur, publicité

Mon processus de découverte et de lecture d’articles — une partie de mon activité de veille — est le suivant :

  1. Quand j’ai un moment devant moi1, je parcoure en diagonale les titres qui remontent dans mon aggrégateur de flux RSS ou dans mon historique Twitter. J’ouvre dans de nouveaux onglets ceux qui attirent mon attention.
  2. Pour chacun de ces onglets, soit l’article est court ou semble particulièrement intéressant et je le lis de suite, soit je l’empile dans Pocket pour lecture quand j’aurai un plus long moment devant moi.
  3. Je dépile les articles qui m’attendent dans Pocket2.

La première étape signifie qu’un titre ou commentaire sympa est indispensable. Et la troisième a pour conséquence malheureuse la perte régulière de quelques articles qui finissent par rejoindre les milliers de posts en attente3 au fond de mon Pocket… Mais c’est du second point que je souhaite parler aujourd’hui.


J’ai ouvert, selon les jours, entre 5 et 30 onglets, chacun abritant un article peut-être intéressant — ou peut-être pas.

Arrivé sur celui de votre site, au lieu d’avoir un article à lire, je suis accueilli par une page couverte de gris, avec au milieu de l’écran une boite de dialogue me demandant de saisir un mail ou de cliquer sur je ne sais trop quoi ou d’installer une application mobile. Sans aucun bouton « fermer » évident à trouver. Et cliquer sur le fond de la page est sans effet.

À votre avis, que fais-je ? Rappelez-vous, je suis arrivé là presque par hasard.
Très juste : « Fermer l’onglet ! » : c’est rapide, le raccourci clavier ou le geste à la souris tombent sous les doigts !

Ou pire encore, au lieu d’arriver sur un article à lire, j’ai un écran intersticiel, avec au milieu de la page une image qui ressemble à un message publicitaire et à peine un petit lien « continuer vers le site », pas évident à repérer, dans un coin.

Là encore, je suis arrivé sur votre site presque par hasard et je n’ai pas la moindre idée du sujet de l’article qui, peut-être, se trouverait au bout du chemin. Quoi qu’il en soit, c’est trop tard : « Fermer l’onglet ! »

Après tout : je viens (d’essayer) d’arriver sur votre site, je ne sais pas si l’article visé sera effectivement intéressant… Pourquoi est-ce que je m’emmerderais4 à chercher comment fermer cette *u*a*i* de popin ?

Et une vidéo qui se lance toute seule, avec du son qui vient heurter mes tympans (si j’ai un casque sur les oreilles) ou retentir sur tout l’open-space en dérangeant mes collègues au passage ? Là encore, au plus vite : « Fermer l’onglet ! »5


Et c’est dommage : le titre de l’article, ou le bref commentaire l’accompagnant sur Twitter, m’avait convaincu de cliquer ! Vous aviez (presque) un lecteur. Et j’ai consommé un pouillème de votre CPU et de votre bande passante pour charger votre site !

Sauf que vous avez échoué dans votre mission : me permettre de lire votre article6.


Pour finir, j’anticipe quelques questions :

  • Et si je suis sur mobile ? L’effet « Fermer l’onglet ! » est encore plus fort. Idem pour la fenêtre qui me demande si je veux installer votre application Android : non, je ne veux pas installer votre …… d’application !
  • Non, attendre que j’ai scrollé un peu avant d’afficher un overlay n’est pas une bonne idée ! Au contraire, cela interrompt ma lecture et provoque un sentiment de frustration encore plus violent ! Votre article, sur lequel je suis arrivé presque par hasard, n’est pas assez intéressant pour surpasser la frustration. Et hop, « Fermer l’onglet ! ».
  • Et, définitivement : recharger la page au bout de quelques minutes, en perdant ma position de lecture au passage, n’est pas acceptable et provoque un « Fermer l’onglet ! » — là aussi, même en milieu d’article !

Et pour finir en élargissant un peu le sujet : vous avez entendu parler du Banner blindness ?


Oui, vous cherchez des revenus, je le comprends bien.
Mais, non, assaillir vos visiteurs n’est pas la bonne solution.



  1. En arrivant (tôt) au bureau et buvant mon premier café de la matinée — et en début de pause midi et/ou en fin de journée si j’ai le temps. 

  2. Je vise, à terme, à remplacer Pocket par une autre solution (probablement wallabag), que je pourrais héberger moi-même. Objectif : dépendre d’un service externe (qui peut toujours fermer ou changer ses conditions d’utilisation) de moins. J’abordais le sujet il y a quelques jours : Dépendre d’un service externe, un choix à assumer

  3. J’ai des articles qui sont, pour certains, en attente dans Pocket depuis plusieurs années. Et, parmi plus de 5000 articles, je sais très bien qu’il y en a une bonne partie que je ne lirai jamais. 

  4. Pardonnez-moi ce terme grossier… Mais il correspond plutôt bien à mon sentiment quand je me retrouve dans cette situation ! 

  5. Ou même « fermer les onglets » un par un, jusqu’à ce que le son s’arrête enfin ! Heureusement, on s’y retrouve mieux et c’est plus facilement maintenant, avec les navigateurs qui affichent une icône sur l’onglet désagréablement bruyant ! 

  6. Enfin, à vous de voir — et c’est une vraie question, fondamentale — quelle est votre mission : afficher de la publicité ? Récolter des adresses mail ? Incrémenter un compteur de vues pour vos annonceurs ? Ou proposer du contenu utile et de qualité à vos utilisateurs ? 

Les directives INI, c'est le mal !

14 avril 2016 php, configuration, ini

This post is also available in English.

Plusieurs fois, alors que des évolutions étaient discutées pour PHP 7, j’ai assisté à des échanges où un intervenant proposait de rendre optionnelle une nouvelle fonctionnalité1, par le biais d’une directive de configuration INI — l’idée étant que chacun pourrait alors l’activer ou non.

Mais le principe même de directives permettant de changer, parfois en profondeur, le comportement d’un langage de programmation… J’en ai des frissons !


Imaginez un langage2 créé pour faciliter la mise en place de formulaires HTML et le traitement des données saisies.

Pour aider les débutants n’ayant aucune notion de sécurité, et puisque l’utilisation de MySQL pour le stockage de données est à la mode, les développeurs de ce langage mettent en place une option qui, une fois activée, entraine l’ajout automatique d’un \ devant tous les guillemets ' arrivant en entrée3 (GET/POST/…).

Bien sûr, une partie des administrateurs système active immédiatement cette directive, puisqu’elle améliore considérablement la sécurité4 en empêchant certaines injections SQL. Mais d’autres administrateurs la désactivent, puisque c’est à chaque développeur de savoir gérer ses données : le langage ne doit pas les modifier à la volée !

Et là, une application donnée fonctionnera parfaitement sur un serveur, alors qu’elle fera n’importe quoi sur un autre — soit en injectant des \ partout, soit en explosant violemment sur la moitié de ses requêtes SQL ! Elle n’aura en effet pas été spécifiquement développée pour tenir compte des différentes combinaisons d’options de configurations.

Vous en rêviez ? Bienvenue dans l’enfer des magic quotes5 !

Dans le même genre, vous vous souvenez de register_globals, où des variables apparaissaient par magie dans vos scripts, pour peu que cette directive soit activée ? C’était d’enfer !


Revenons à une période un peu plus proche : chaque fois qu’une directive de configuration est ajoutée à PHP6, cela signifie :

  • Plusieurs branches de code à tester, déboguer, maintenir. La maintenance d’une fonctionnalité introduite dans un langage aussi répandu que PHP, c’est sur 10 ans. Et plus !
  • Plus de documentation à rédiger, d’une part — et à lire et à comprendre, d’autre part.
  • Plus de travail à fournir pour s’assurer que chaque application7 fonctionne avec chaque combinaison de paramètres.
  • En cas de problème, combien de temps avant de réaliser qu’un comportement étrange est dû à une valeur inhabituelle ou inattendue pour une directive de configuration bien spécifique ? Ou, pire, à une combinaison inhabituelle de valeurs pour quelques directives de configuration tordues ?

Heureusement, les développeurs qui travaillent sur PHP sont conscients de ces problèmes et limitent donc autant que possible les ajouts de nouvelles directives INI. Ils fournissent également deux fichiers php.ini-development et php.ini-production, qui contiennent des valeurs assez appropriées, dont il est bon de rester proche.


Quoi qu’il en soit, avant de suggérer « mais ils pourraient permettre d’activer ou non cette fonctionnalité via une simple directive INI » pour des points aussi critiques qu’un système de typage souple ou strict, demandez-vous si vous souhaitez véritablement arriver à deux langages se comportant de manière complètement différente, avec des applications et bibliothèques fonctionnant uniquement sur certaines combinaisons de configurations et pas d’autres…

Et maintenant, répétez après moi : « les directives INI, c’est le mal ! »



  1. Parce qu’elle risquait de casser la compatibilité antérieure, parce qu’elle changeait certains aspects de la façon d’être du langage, parce qu’elle n’était pas appréciée par tous, parce que certains n’en voulaient pas… 

  2. Je vous laisse deviner à quel langage je peux penser ^^. Mais mes propos, quitte à les généraliser un peu, s’appliquent pour de nombreux autres ! 

  3. Notez qu’il s’agit de l’interprétation que j’en ai plusieurs années après : je ne sais même pas si je connaissais déjà PHP quand ces choix ont été faits. Les choses se sont peut-être quelque peu passées différemment ! Mais l’effet (et la perception que certains ont du langage) reste bien là ! 

  4. Ou pas (tellement ?), en fait… 

  5. PHP visant à réduire au maximum les ruptures de compatibilité, il a fallu des années avant d’être enfin débarrassé de cette mauvaise-bonne idée — et des différences de configurations et de comportements allant avec ! 

  6. C’est vrai également pour à peu près n’importe quel logiciel, d’ailleurs ;-) 

  7. En particulier, pour les logiciels, open-source ou non, distribués pour être installés sur différents serveurs gérés par des administrateurs aux pratiques différentes. 

Dépendre d'un service externe, un choix à assumer

12 avril 2016 saas, opinion, humeur

Quand j’ai découvert le principe des flux RSS, j’ai commencé à en suivre quelques-uns en utilisant un logiciel installé sur mon unique PC1. Je suis rapidement passé à un service en ligne, réalisant que cela me permettrait de m’occuper entre les cours, en prenant la suite de ce que je lisais chez moi.

À ce moment là, le service d’agrégation de flux RSS s’appelait Bloglines, si j’ai bonne mémoire. Je ne saurais plus en parler en détail, mais il fonctionnait plutôt pas mal et n’était pas désagréable à utiliser. Après un ou deux rachats, il a fini par fermer.

J’ai alors basculé vers le service d’agrégation de flux RSS du moment : Google Reader. Il fonctionnait plutôt pas mal, il était somme toute agréable à utiliser. Après avoir arrêté d’évoluer, il a fini par fermer. Oui, même avec « Google » dans le nom.

Finalement, j’utilise désormais un logiciel que j’héberge moi-même. Ça représente un léger investissement financier et, surtout, plus de travail pour l’administrer et le tenir à jour, mais, au moins, il ne fermera pas demain !


Pour l’hébergement de projets, en particulier libres, il y a pas mal d’années de cela, SourceForge était le service où il fallait être. Quelques années après, Google Code était le service à la mode. J’en ai également utilisé ou vu utilisés quelques autres, plus confidentiels.

Le second a annoncé il y a un an, qu’il basculerait en lecture-seule fin août 2015 et fermerait début 2016 — ici encore, oui, même avec « Google » dans le nom. Le premier s’est transformé en guirlande de Noël blindée de publicités — ou a même injecté pendant un temps des composants douteux dans les paquets logiciels proposés au téléchargement.


Et si, demain, c’était Github, sur lequel vous hébergez le code-source de vos projets (ou tout leur historique d’issues) ou votre blog personnel, qui fermait ? Ou Gmail ? Ou le FAI chez qui vous avez vos mails ? Ou un diffuseur de musique avec DRM requêrant un accès au serveur pour permettre l’écoute de morceaux achetés ?

Un service qui ferme, une entreprise qui cesse son activité, cela arrive et c’est normal, après tout. Je ne dis pas le contraire. Mais il est important d’en être conscient et de savoir mesurer et anticiper les risques.


Utiliser Github comme hébergement pour le code-source de votre entreprise et Google Apps pour vos documents et mails ? Pourquoi pas : ce sont des solutions pratiques, de qualité, simples à mettre en place et ne demandant quasiment aucune admistration ni réelle gestion de backups de votre part2. De plus, tant que vous vous basez sur une version payante et dont le modèle n’est pas basé sur la publicité, vous avez des chances d’être le client et pas le produit ;-).

Mais, dans tous les cas, veillez à avoir des possibilités d’export pour migrer vers une autre solution, ainsi qu’à conserver la propriété du nom de domaine que n’aurez pas manqué de configurer pour pointer vers le service que vous utilisez — au lieu de passer par une URL lui appartenant !

Une possibilité, en particulier pour les projets Open Source disposant d’un minimum de moyens, peut être d’utiliser leur propre hébergement, notamment pour leur code-source… Quitte à mettre en place un miroir sur Github pour faciliter les contributions3 ;-)



  1. J’étais étudiant : je n’avais pas 36 ordinateurs, les « smartphones » comme nous les connaissons aujourd’hui (et encore, on parlait plus de « PDA », façon Psion ou Palm, qui ne faisaient pas également téléphone !) existaient à peine et leur prix les réservaient à un public fortuné et/ou professionnel. 

  2. Bon, la NSA passera sur tout ce que vous faites, mais si vous ne restez pas en local au sein de votre entreprise (et donc, dès que vous échangez le moindre mail), c’est peut-être déjà le cas. Les boites noires installées chez vos FAI feront probablement pareil, d’ailleurs. 

  3. C’est par exemple l’approche retenue pour le développement de PHP, où le dépôt officiel est hébergé par php.net, avec un miroir sur Github qui permet de bénéficier des interfaces correspondantes, dont le mécanisme de pull-requests.