lundi 8 janvier 2018

Les outils sont-ils la solution à nos problèmes ?

Frédéric Menou a écrit un très bon article à propos de la programmation fonctionnel et d’Haskell, dans lequel il décrit notamment les raisons qui l’ont amené à apprendre ce paradigme et ce langage.

Je n’ai pas d’avis sur son choix d’Haskell pour son activité, car je ne connais pas ce langage et encore moins son métier.

Par contre, je connais relativement bien la problématique qui l’a mené vers cette solution, car j’ai rencontré exactement la même.

En effet, si je résume (certainement très grossièrement) sa démarche, Frédéric s’est tourné vers Haskell essentiellement parce qu’il cherche à écrire le moins de bogues possible lorsqu’il code, et il pense que le formalisme offert par le langage lui permet d’y parvenir, tout en améliorant la communication avec l’ensemble des parties prenantes dans un développement informatique.

Or, cela fait au moins maintenant presque 12 ans que je cherche à atteindre le même objectif.

De plus, j’ai commencé à développer de la même façon que Frédéric, en me consacrant sur les algorithmes et l’aspect technique, en renforçant ma maîtrise de PHP et des outils afférents grâce à une veille technologique quotidienne.

Notre parcours concernant les éditeurs de code a également été très similaire.

Pourtant, malgré une problématique similaire, nous sommes parvenus à des solutions très différentes.

Frédéric a remis en cause ses outils et en a sélectionné d’autres qui lui semblent plus adaptés pour atteindre son objectif.

De mon côté, au lieu de remettre en cause mes outils, j’ai choisi de me remettre en cause et de mieux comprendre les principes fondamentaux du paradigme que j’utilise, ce qui m’a amené à faire évoluer très fortement mes méthodes de développement.

À mon avis, celui qui peut dire lequel de nous deux a la meilleure stratégie pour atteindre son objectif n’est pas encore né, et je n’en ai donc pas la prétention, mais son billet m’a tout de même inspiré une réflexion que j’aimerai maintenant vous faire partager.

L’être humain a une tendance naturelle à incriminer ses outils lorsqu’il ne parvient pas à réaliser correctement quelque chose.

C’est un fait, et c’est bien normal, puisqu’il est bien plus simple et agréable pour nous de remettre en cause l’outillage que de se remettre en cause.

Donc, lorsqu’il est en situation d’échec, l’Homme adopte principalement deux stratégies.

La première consiste à changer d’outils, la seconde à les modifier dans l’espoir qu’une fois « améliorés », ils permettront de réussir.

Et parfois (et j’insiste sur ce « parfois »), je pense que cela a des effets très pervers, et je vais donner trois exemples, certes très caricaturaux, mais qui sont également à mes yeux très représentatifs.

Autrefois, dans des temps fort fort lointains, le développeur devait gérer lui-même la mémoire utilisée pour son programme, ce qui parfois, provoquait des erreurs de segmentations.

Une couche de complexité a donc été ajoutée aux langages informatiques afin de décharger les développeurs de cette tâche et ainsi éviter ces erreurs, et aujourd’hui, ils n'ont plus à se soucier de la mémoire vive, ou de quoi que ce soit d’autre relatifs au matériel sur lequel sera exécuté le code, d’ailleurs.

Mais qui, aujourd’hui, connait encore le fonctionnement de la mémoire vive d’un ordinateur ?

Pour ce que je peux en constater, il n’y a plus que les vieux barbus et les spécialistes de l’embarqué qui possèdent encore cette connaissance, alors qu’il s’agit de l’une des bases de la technologie sur laquelle repose le métier de développeur.

De plus, si autrefois, il pouvait y avoir des erreurs de segmentations, en contrepartie, la mémoire était généralement gérée aux petits oignons, car il s’agissait en plus d’une ressource comptée qu’il ne fallait pas gaspiller.

Mais aujourd’hui, il suffit qu’un onglet inactif dans un navigateur ne consomme pas plus de 80 Mo pour que nous soyons heureux…

Le quotidien du développeur a donc été « amélioré » grâce à une évolution de ses outils, mais en contrepartie, il a perdu de la connaissance et les programmes ont perdu en efficacité.

Quant à la stratégie du changement total d’outil pour palier à une défaillance, l’une des plus belles illustrations est justement la démarche décrite par Frédéric dans son billet (ce qui ne veut pas dire que je pense qu’il a fait une erreur, encore une fois, son billet n’a été qu’une source d’inspiration pour écrire celui-ci).

Nombre de développeurs passent en effet de la programmation orientée objet vers la programmation fonctionnelle, car ils pensent qu’elle est plus apte à répondre à leurs besoins, sans se poser de question par rapport à leur pratique et à leur compréhension de la programmation orientée objet.

Or, pour la plupart, ils pratiquent cette dernière sous une forme « diminuée » qui ne leur permet pas d’en tirer la quintessence.

Et le monde du logiciel n’est pas le seul à être concerné, celui du matériel l’est tout autant.

Les bases de l’architecture x86 ont été posées par Intel à la fin des années 1970, mais pour autant, elle est toujours massivement utilisée aujourd’hui.

Pourtant, je connais assez peu de personnes compétentes dans le domaine qui pense que cette architecture est la panacée.

Mais il faut dire qu’Intel a tout fait pour contrebalancer cela par une évolution à marche forcée des performances, en ajoutant de la complexité couche après couche afin de respecter la loi de Moore.

Et aujourd’hui, nous faisons face à Meltdown et Spectre, et l’avenir ne semble pas radieux.

Et comme tous les fondeurs sont pris dans la course à la performance sous la pression du marché, les concurrents d’Intel ont fait de même en utilisant les mêmes concepts, ce qui fait qu’aujourd’hui, la quasi-totalité des CPU actuellement en activité est plus ou moins vulnérable à ces attaques d’un nouveau genre (même si elles ne semblent pas si nouvelles que cela).

D’ailleurs, j’aime beaucoup ce commentaire de Linus Torvald à ce sujet :

I think somebody inside of Intel needs to really take a long hard look at their CPU’s, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

Plutôt que de repartir à la table à dessin et se creuser la tête, Intel a en effet préféré spéculer le plus longtemps possible sur l’architecture x86 en la faisant évoluer aux forceps pour pallier ses défaillances grâce à une augmentation vertigineuse des performances, sans jamais en remettre en cause la philosophie et les fondamentaux.

Pour conclure, il peut être sain de changer d’outils ou de les rendre plus complexes afin de se simplifier la vie, mais il ne faut surtout pas oublier qu’il y a toujours un prix à payer, et par conséquent, il ne faut surtout pas penser qu’un tel changement vous permettra systématiquement d’atteindre votre objectif plus vite ou plus efficacement.

Le chemin que vous aurez à parcourir pourra en être simplifié, mais il pourra également vous emmener vers un précipice, une voie de garage, ou bien encore vous faire faire bien des détours tortueux et dangereux.

Pour preuve, malgré la simplicité apparente de son exemple pour illustrer le typage algébrique, malgré les fonctionnalités d’Haskell qui sont censées lui permettre d’esquiver les bugs, Frédéric a introduit un bug dans le code présent dans son billet…

Alors parfois, faire preuve d’humilité, d’honnêteté, en remettant en question ses pratiques afin de repartir sur des bases plus saines peut valoir le coût, plutôt que de déléguer à des outils la charge de nous rendre meilleurs, ce qui leur est impossible par nature.

La solution est rarement dans les outils, mais l’Homme est toujours à l’origine des problèmes.

mercredi 25 octobre 2017

Je serais au forum PHP 2017 !

Grâce à Norsys, je serais une nouvelle fois au forum PHP qui débutera demain, et en compagnie de 6 collègues.

J’y serais en « presque » simple visiteur, puisque je me contenterais d’y présenter un « lightning talk » de 5 minutes à propos du RGPD, ce qui va me laisser du temps pour profiter pleinement de l’événement.

Je me suis donc mitonné un programme aux petits oignons, car je trouve la sélection de conférences effectuée par l’AFUP est très attrayante.

Lire la suite

lundi 6 mars 2017

Combien de temps pour préparer une conférence (ou peindre la Joconde) ?

J’ai écrit ce billet à la suite d’une demande de Pascal et de la discussion qui s'en est suivie avec Éric.

Je fais des conférences depuis plus de 10 ans.

J’ai toujours passé énormément de temps à les préparer, et si je regarde dans le rétroviseur, je dirais que j’y passe de plus en plus de temps, car je suis de plus en plus exigeant avec moi-même.

Aujourd’hui, je pense que je mets en moyenne une dizaine de jours pour formaliser un sujet sur lequel j’ai déjà à minima au moins une vague idée de la façon dont je veux faire passer mon message, ce qui comprend :

  1. La création du plan ;
  2. La création des diapositives correspondantes avec en commentaire le texte correspondant qui sera utilisé pour la mise en ligne de la conférence ;
  3. La recherche des éléments multimédia permettant de transporter le plus rapidement possible l’idée ;
  4. Les répétitions.

Cependant, ce temps ne tient absolument pas compte du temps de maturation du sujet, à partir du moment où j’en ai eu l’idée jusqu’aux prémisses de sa formalisation.

Lire la suite

vendredi 16 décembre 2016

Nous ne sommes pas que du code

Dois-je faire du libre, avoir un compte sur Github et passer mes soirées et mes week-ends à coder dans le dernier langage à la mode pour pouvoir être reconnu comme un passionné de la programmation, comme faisant partie des meilleurs développeurs au monde, et donc pour être digne d’être embauché ?

Celui qui pose implicitement cette question est Ezekiel Buchheit, et il est Software Dev Engineer II, d’après son compte linkedin.

Il travaille aux USA, chez Amazon, et d’après son parcours, il est l’équivalent de ce que l’on appelle un développeur senior en France.

Et je ne sais pas ce que cette question provoque comme réaction chez vous, mais dans mon cas, son existence me fait peur.

Pourquoi ?

Lire la suite

mardi 22 novembre 2016

Rencontre d’un troisième type

32.jpg

Lorsque j’ai dit dans ma conférence au dernier forum PHP que nos rencontres nous rendent unique, c’est parce que j’en suis persuadé, car je l’ai vécu.

J’ai aujourd’hui un peu plus de 40 ans, et je ne serais pas celui que je suis et je ne ferais pas ce que je fais de la façon dont je le fais si je n’avais pas croisé au cours de ces années un certain nombre de personnes qui m’ont apporté une part d’eux-mêmes ou des valeurs qui sont venues se mettre en symbiose avec les miennes.

Ces personnes se connaissent parfois (après tout, qui se ressemble s’assemble, et c’est peu de le dire pour certaine), mais parfois elles n’ont absolument aucune relation.

J’ai pu les croiser quotidiennement des années durant… ou bien une seule et unique fois, pendant quelques minutes.

Elles s’appellent Christophe, Élodie, Yannick, Jean-Marc, Fabien, Julien, François… ou Philippe.

Lire la suite

vendredi 18 novembre 2016

À propos du forum PHP 2016

J’ai participé une fois encore au forum PHP cette année. Cependant, cette édition a eu pour moi une saveur particulière, pour plusieurs raisons. Tout d’abord, pour la première fois en presque 10 ans, je n’ai pas participé à l’intégralité de l’événement à cause de contraintes professionnelles. Je  […]

Lire la suite

mercredi 16 novembre 2016

À propos de l’USB-C des nouveaux MacBook Pro

Beaucoup de choses sont dites à propos des ordinateurs portables présentés dernièrement par la firme à la pomme, et notamment qu’ils sont trop chers et trop limités pour un usage professionnel.

Je ne vais pas entrer dans cette polémique, car j’ai mieux à faire de mon temps, et je vais donc me contenter de vous présenter ma réflexion personnelle sur le sujet.

Lorsqu’est sorti l’iMac sans lecteur de disquette, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sorti le premier iPod, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sorti le MacBook sans lecteur optique, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sorti le premier iPhone, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sortie la première version du MacBook Air sans port Ethernet, je me suis dit qu’Apple était devenue folle.

Lorsqu’est sorti l’iPhone 7 sans port « jack », je me suis dit qu’Apple était devenue folle.

Lorsque j'ai regardé les spécifications des nouveaux MacBook Pro, je me suis dit qu’Apple était devenue folle… et puis, j’ai regardé dans le rétroviseur.

Lire la suite

vendredi 23 septembre 2016

Mettre l'Installateur de macOS Sierra sur une clef USB

Trouver une clef USB d'une capacité ≥ à 8 Go ; L'insérer dans un port USB disponible ; Télécharger macOS Sierra à partir de l'App Store ; Ne pas lancer l'installation de macOS Sierra ; Ouvrir un terminal ; Exécuter `sudo /Applications/Install\ macOS\ Sierra.app/Contents/Resources/createinstallmedia  […]

Lire la suite

mardi 21 juin 2016

Alan Kay about object

I've been constantly surprised about how what I called object-oriented and system-oriented got neutered into Abstract Data Types, etc. I think because people wanted to retain the old ways of programming with procedures, assignment statements, and data structures. These don't scale well, but enormous  […]

Lire la suite

mercredi 17 février 2016

C'est l'histoire d'un mec

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  […]

Lire la suite

mardi 1 décembre 2015

PHP et ./configure

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).

Lire la suite

vendredi 6 novembre 2015

J'ai oublié de vous dire… #2

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.

Lire la suite

jeudi 29 octobre 2015

Chronique sur mon voyage vers l'est, quatrième !

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.

Lire la suite

mercredi 28 octobre 2015

J'ai oublié de vous dire… #1

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  […]

Lire la suite

mardi 27 octobre 2015

J'ai un emploi !

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 ?

Lire la suite

mercredi 8 avril 2015

Je cherche un emploi !

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  […]

Lire la suite

mardi 9 septembre 2014

Spécifiez agile !

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.

Lire la suite

vendredi 29 août 2014

À propos de phpng et de PHP 7

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…

Lire la suite

lundi 11 août 2014

Réussir dans la vie…

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  […]

Lire la suite

vendredi 18 avril 2014

À propos de la programmation orientée objet #2

J’ai eu quelques commentaires à propos de mon dernier billet dans lequel je dis qu’il n’est pas prudent, lorsqu’on fait de la programmation orientée objet, de se baser à l’intérieur d’une méthode de classe sur une valeur retournée par ce qui est communément appelé un « getter » pour prendre une décision.

Étant donné que je suis un peu masochiste, j’ai pris le temps de coder quelques lignes pour démontrer qu’il s’agit d’une mauvaise pratique.

Étant amateur de (bonne) bière, je me suis permis de choisir comme cas d’usage la réalisation d’une commande par un client dans un bar à bière, de la demande au paiement.

De plus, afin de limiter la portée de l’exemple, j’ai fait quelques concessions sur la réalisation technique.

Ainsi, mon code ne contient pas d’interface, alors que dans un cas réel, afin d’augmenter le niveau d’abstraction, il faudrait y recourir afin de pouvoir par exemple remplacer le barman par une pompe à bière automatique, ou bien le client par un Autrichien sachant parler le français et payer en euro.

De plus, je n’ai pas utilisé d’injection de dépendance pour la création de mes objets et au moins une méthode assure une méthode qui ne devrait pas être de la responsabilité de la classe, mais j'ai choisi dans ce cas la facilité, car la méthode concernée est périphérique et n'apporte rien au propos.

Lire la suite

- page 1 de 95