Par exemple, Hypertalk :

set the location of card button x to pos
add 15 to item 1 of pos

Ou encore Perl :

move $this from => $here, to => $there;
print $message if $name eq "Bob" and $age > 10;

Supernova :

I want window and the window title is Hello World.

Pourquoi faire ?

Le but de ces langages est, de manière évidente, de faciliter les développements. En réduisant l’effort cognitif nécessaire pour écrire un programme, on peut raisonnablement penser qu’ils deviendront plus faciles et rapides à écrire.

En fait, c’est surtout en terme d’apprentissage que cette approche montre une quelconque valeur : une personne n’ayant jamais utilisé le moindre langage de programmation sera moins rebutée si elle a l’impression de parler à la machine pour lui dire quoi faire, plutôt que de devoir apprendre les codes cabalistiques que la machine lui impose.

C’est l’une des raisons du succès remporté par Hypercard à la fin des années 80 et au début des années 90. Non seulement il proposait de créer des interfaces graphiques à la souris, mais il permettait ensuite de les contrôler d’une manière plus simple que tout ce qui était connu jusqu’alors. Dans une certaine mesure, le succès du Visual Basic repose sur les mêmes fondamentaux (en remplaçant le langage pseudo-naturel par le langage informatique désigné comme étant le plus simple).

Le culte du cargo

Ça faisait un bout de temps que je voulais parler du culte du cargo. À la base, il s’agit du fait que certaines peuplades du Pacifique, voyant des avions-cargo larguer des vivres après que les soldats américains l’aient demandé à la radio, se sont mis à construire de fausses cabines-radio (voire même de fausses pistes d’atterrissage), espérant pouvoir ainsi faire venir de nouveaux parachutages après le départ des troupes à la fin de la deuxième guerre mondiale.

Par extension, on parle du culte du cargo lorsque quelqu’un observe une chose et tente de la reproduire, sans la comprendre, en espérant que cela générera les mêmes effets.

J’en profite pour en parler, car l’article Wikipédia parle notamment des concepteurs de langages informatiques (en citant le Cobol comme exemple) qui essaient d’imiter l’anglais sans pour autant maîtriser sa construction, et sans l’adapter correctement aux spécificités des langages informatiques.

Verbosité versus concision

Le problème fondamental et évident avec le langage naturel, c’est qu’il manque de concision. Il a été conçu (si je puis dire) pour véhiculer des informations mais aussi des émotions, de la nuance. Ajoutez à cela qu’un langage réel évolue au fil des siècles, ce qui lui apporte toute sa richesse ; c’est d’ailleurs l’une des choses qui − du point de vue des linguistes − différenciera toujours les langues naturelles des langues construites (espéranto, volapük, interlingua, interlingue, idiom neutral, …).

Il faut aussi prendre en compte un aspect important : l’héritage mathématique.
On apprend assez jeune, au collège, les concepts de variables et de fonctions. Et même si je pense les avoir découvert grâce aux langages de programmation plusieurs années avant de les apprendre en cours de math, la logique de cette enseignement est indéniable.

Il faut toutefois différencier ces deux concepts, qui sont au cœur de tous les langages de programmation.
Les variables sont faciles à comprendre et à manipuler. Il est donc inutile de vouloir écrire :

mettre la valeur 27 dans la variable toto

Alors qu’on peut écrire simplement :

toto = 27

Par contre, pour les fonctions (ou les méthodes), c’est un peu différent. Si on y réfléchit bien, elles reflètent un comportement naturel. Un comportement, pas un langage.

Je m’explique. Tous les jours, à tous moments, nous employons des termes qui synthétisent nos idées ; nous utilisons des synonymes qui regroupent plusieurs idées à la fois.
Quand on dit « Monte dans la voiture », on utilise une expression qui est un résumé signifiant « Va jusqu’à la voiture, ouvre la portière, entre dans la voiture, assois-toi sur la banquette, ferme la portière, attache ta ceinture« . Même « attache ta ceinture » peut être décomposé en « lève le bras, attrape la ceinture, descend le bras, fait entrer la boucle dans l’attache, pousse jusqu’à entendre un “clic”, lâche la boucle« .

Quand on y pense, cela est très similaire avec la manière dont on utilise les fonctions et les méthodes. On cache une complexité en lui donnant un nom identifiable, avec une profondeur infinie. Et quand on n’a besoin que de manipuler des concepts globaux, on se s’embarrasse pas à vouloir comprendre ce qu’ils renferment.

Conclusion

Je me rend compte que cet article ne sert pas à grand-chose.  :-)

C’est juste que j’entends régulièrement parler d’efforts de simplification de la programmation. Et quand ces efforts tentent de singer des concepts naturels (le langage naturel en est un exemple, mais il faudrait aussi que je vous parle de la programmation visuelle un de ces jours), on sait d’avance que le résultat ne sera jamais à la hauteur des ambitions « révolutionnaires » qui sont annoncées…

L’essence même de l’informatique implique quelle nous fasse manipuler des notions qui ne sont pas naturelles. Ce qui importe, c’est de pouvoir utiliser l’outil informatique pour créer des choses plus avancées, et cela plus rapidement.
N’importe quel enfant de 3 ans est capable de dire ce qu’il veut. C’est une bonne chose d’offrir à ces enfants la possibilité de se frotter à la programmation. Par contre, il n’est pas nécessaire que les outils de programmation que nous utilisons au quotidien soient ceux que nos enfants pourraient aussi utiliser.

La semaine dernière était donc la semaine de MEP du mois d’avril. Jusqu’ici, on terminait chaque itération en faisant une analyse rapide des problèmes rencontrés. Mais cette fois-ci, j’ai pris le temps d’organiser une vraie réunion avec toute l’équipe.

Faire simplement un tour de table, en demandant à chacun de dire ce qu’il a apprécié ou regretté durant le mois, aurait pu ne pas être efficace. Certains n’auraient pas osé parler, et d’autres auraient peut-être lancé des sujets polémiques.
Pour introduire les choses, j’ai donc démarré la réunion sous forme de niko-niko. J’ai distribué des petits post-it sur lesquels j’avais dessiné des visages. Chaque personne avait en main 5 visages, du plus souriant au plus grimaçant, mais ne pouvait en utiliser qu’un pour exprimer son niveau de satisfaction par rapport au déroulement du mois.

Le choix des visages s’est fait anonymement, et j’ai fait le décompte sur un tableau blanc. Ainsi tout le monde avait une vision du ressenti global de l’équipe.
Ensuite, nous avons fait un tour de table, chacun expliquant le choix qu’il avait fait.

Ce fut vraiment intéressant. Nous avons pu identifier certaines différences d’interprétation, des problèmes de communication, ou encore des éclaircissements à fournir sur les priorités. Le but n’était pas de lancer des réflexions sur comment résoudre les problèmes ou comment améliorer les process, mais juste de lister ce qu’on pouvait améliorer.
À notre charge maintenant d’organiser les réunions nécessaires pour avancer sur les points qui ont été soulevés.

Je sais qu’habituellement le niko-niko est un exercice plus fréquent. Soit tous les jours, soit à la fin de chaque sprint. J’ai préféré une approche mensuelle, mais cela changera peut-être au fil du temps. Là j’ai utilisé le niveau de contentement des uns et de autres comme introduction, comme support à la discussion qui a suivi.
D’ailleurs, la discussion a été enrichissante parce que nous avions une vision sur l’ensemble du mois. Nous avons pu réfléchir à l’amélioration de nos méthodes de travail dans leur ensemble, pas simplement à tel ou tel point de détail ponctuel.

Je ne dis pas qu’il n’y a aucun intérêt à « prendre le pouls » de l’équipe au jour le jour. Je dis juste qu’il faut faire les choses dans l’ordre ; dégrossir avant d’affiner.
Ce qui est certain, c’est que nous allons renouveler l’expérience tous les mois désormais.

Il avait suscité quelques commentaires plutôt positifs, et une réaction très véhémente (avec l’emploi du mot « bullshit » difficile à digérer).

J’en reparle aujourd’hui pour pointer un article intéressant, écrit par David Heinemeier Hansson (créateur de RubyOnRails) et publié sur le blog de 37signals.

Son propos est assez similaire au mien : les tests unitaires, c’est bien ; le test driven development, c’est pratique ; mais chercher à couvrir 100% du code est inutile et coûteux.

Il dresse une liste de sept raisons pour lesquelles il faut se retenir de tester (de son propre aveux, sa liste manque de nuance, mais c’est pour la clarté de son propos) :

• Ne pas chercher à couvrir 100% du code.
• Si votre ratio code/test est de 1:2, ça ne sent pas bon ; s’il est de 1:3, ça pue carrément.
• Si vos tests vous prennent plus d’un tiers de votre temps, vous vous y prenez sûrement mal. Si ça vous prend plus de la moitié de votre temps, vous êtes certain de mal vous y prendre.
• Ne testez pas le comportement normal de votre ORM.
• Gardez les tests d’intégration pour valider les éléments séparés (ne pas faire de tests d’intégration sur des éléments qui peuvent être testés unitairement).
• N’utilisez pas Cucumber à moins de vivre dans le royaume merveilleux des tests-écrits-par-des-non-programmeurs (et envoyez-moi une bouteille de poussière de fée si vous y êtes).
• Ne vous forcez pas à faire du TDD sur tous vos contrôleurs, tous vos modèles et toutes vos vues (mon ratio est typiquement de 20% de code testé avant d’être écrit, 80% testé après avoir été écrit).

Il cite ensuite une remarque faite par Ken Beck (inventeur de l’extrem programming et auteur référent en TDD) en réponse à une question sur le site StackOverflow :

Je suis payé pour faire du code qui fonctionne, pas pour faire des tests, donc ma philosophie est d’écrire aussi peu de tests que nécessaire pour atteindre un certain niveau de confiance (je suspecte que ce niveau est élevé par rapport aux standards industriels, mais ce n’est peut-être que de la fierté mal placée). S’il y a un type d’erreur que je ne fais habituellement pas (comme remplir les mauvaises variables dans un constructeur), je ne le teste pas.

(je vous conseille de lire le fil complet sur StackOverflow)

Au final, mon but n’est pas de fanfaronner (l’avis de David H. Hansson ne vaut pas forcément plus que l’avis d’un autre), mais juste de répéter ce que j’ai toujours dit : Même le meilleur pattern peut devenir un anti-pattern quand il est mal utilisé ou quand il est utilisé à outrance. La réponse est rarement dans les extrêmes ; on vit dans un monde nuancé.
Et il est illusoire de ne pas prendre en compte les coûts induits par les tests − tout comme il est illusoire de ne pas prendre en compte les coûts de maintenance provenant de code non testé.

Cette année, le Forum PHP se tiendra les 5 et 6 juin à la Cité Universitaire Internationale.

J’ai proposé une conférence qui a été retenue, et que je présenterai le mercredi 6 juin, de 14h00 à 14h45. Voici le texte de présentation de cette conférence :

Durant cette présentation, nous passerons en revue les différentes techniques servant à créer des démons en PHP, c’est-à-dire des serveurs logiciels destinés à recevoir des connexions réseau et gérer des communications client-serveur.
Nous verrons les techniques les plus simples, permettant de prototyper rapidement un démon. Ensuite nous nous intéresserons aux contraintes qui s’appliquent à ce type de développement, et les impacts que cela implique sur les choix de design logiciel. Nous aborderons alors les différentes techniques de création de démons autonomes en PHP.
Pour terminer, nous verrons comment utiliser la bibliothèque ZeroMQ pour faire communiquer des programmes en utilisant des paradigmes différents du client-serveur traditionnel.

Programme

1. Rappel client-serveur
2. Démons basés sur (x)inetd
3. Démons multi-processus
4. Démons mono-processus
5. ZéroMQ
1. Présentation
2. Différents types de communications
3. Load-balancing
4. Polling

Ce sera la première conférence que je donnerai en dehors du milieu académique. J’ai quand même donné près d’une quinzaine de conférences dans des universités et des écoles d’ingénieurs, mais là je serai face à des personnes dont certaines sont bien plus expérimentées que moi.

Mais ça devrait bien se passer. J’ai proposé un sujet que je pense maîtriser assez bien. Le projet FineFS est un exemple pointu de développement client-serveur en PHP, et je vous ai déjà parlé plusieurs fois de ZeroMQ.

Venez nombreux !

L’AFUP organise deux grands rendez-vous, le Forum PHP et le PHP Tour, qui sont l’occasion d’assister à des conférences données par des personnages reconnus de la communauté technique internationale (Monty, Rasmus, …) et française (Jean-Marc, Ivan, Nicolas, Fabien, François, Frédéric, …) − oui, je me la pète en les appelant par leurs prénoms  :-)
L’AFUP organise aussi des « rendez-vous », c’est-à-dire des conférences à thème qui se déroulent sur une soirée. Et elle offre un cadre à des apéritifs spontanés.

Depuis quelques temps, l’association cherche à dissocier les activités nationales (Forum PHP et PHP Tour) des activités locales. C’est ainsi que des antennes locales se sont ouvertes à Lille, Lyon, Orléans et Nantes. Bizarrement, aucune antenne locale n’avait été créée sur Paris. La raison est que les membres du bureau organisaient les Rendez-Vous parisiens, mais cela finissait par poser divers problèmes, dont le résultat final est qu’il n’y a eu que deux Rendez-Vous et un apéro sur Paris en 2011.

Cette semaine, nous avons donc créé l’antenne parisienne. Je vais occuper le poste de « coordinateur ». Je ferai équipe avec Raphaëlle Simonney qui tiendra le rôle de « modératrice », et Christophe Villeneuve qui a été désigné comme suppléant.

Les étiquettes importent peu au final. Nous allons essayer de redonner un peu de dynamisme aux évènements PHP parisiens. Je suis certain qu’il suffit de peu pour y arriver, parce qu’il y a sur Paris à la fois les compétences et la volonté d’y arriver, et que nous bénéficions de l’énorme travail effectué par l’AFUP depuis plusieurs années.
Raphaëlle est pleine d’énergie (et d’humour !) ; Christophe a une grande expérience et un carnet d’adresse bien rempli, ainsi qu’un enthousiasme quasi-juvénile. Ça fait plaisir de se lancer avec eux.

Pour le moment, j’ai en tête de tenter un rapprochement avec les nombreuses autres communautés techniques qui organisent des conférences sur des sujets extrêmement proches ; on devrait pouvoir faire en sorte que ces mondes puissent se croiser de temps en temps. On verra bien.

Mais c’est aussi la possibilité d’organiser n’importe quel type d’évènement intéressant autour de PHP. L’exemple donné par Xavier Lacot, le président de l’AFUP, c’est que si on pense pouvoir apporter quelque chose à la communauté PHP en organisant une distribution de stickers, pas de soucis, l’AFUP nous soutiendra.

Alors n’hésitez pas à me partager vos idées et vos envies ! Qu’est-ce qu’une association comme l’AFUP pourrait faire qui soit utile ? Ou marrant (mais quand même un peu utile) ?

Le passé

C’est en fait la troisième fois que je vis un rachat de l’intérieur.

La première fois, j’étais dans une petite boîte qui s’est fait rachetée par une société de taille équivalente, mais filiale d’un plus grand groupe. Les choses ne se sont pas très bien passées ; nous avions été absorbés, nous avons emménagés dans leurs locaux, dans l’idée de tout migrer de notre plate-forme technique vers la leur (ce qui se justifiait pour certains projets, mais pas pour tous). Je pense qu’en fait, c’est notre porte-feuille clients qui les intéressait, et éventuellement le positionnement de certains de nos sites mobiles. Par contre, les hommes et la technologie ne semblaient pas peser lourd dans la balance, à part deux des trois créateurs de la boîte.

La deuxième fois, j’étais dans une entreprise de taille plus importante, qui s’est fait racheter par le plus grand cabinet de conseil au monde. Nous étions leader sur le marché de la musique numérique sur mobile. Le repreneur n’avait pas pour habitude de racheter des entreprises « média », mais nous avions d’importants projets avec les plus grandes majors, ce qui lui permettait de prendre pied dans cet univers. Nous gardions notre indépendance théorique, mais au moment où je suis parti (pour créer mon entreprise actuelle), les employés commençaient tout juste à ressentir l’invasion des décideurs/chefs de projets externes. La technologie était gardée, c’était un actif fondamental. Par contre, je n’ai pas eu l’impression que les ressources humaines valorisaient le personnel en place.

Le présent

Donc, ma boîte a été rachetée. Il y a des choses que je ne peux évidemment pas raconter ici. Soit parce que je n’en ai pas le droit (on a été racheté par une société cotée en bourse), soit parce que je n’en ai pas envie.

Commençons par détendre l’atmosphère : Non, je n’ai malheureusement pas fait fortune. J’ai participé à la création de ma boîte, mais elle ne m’appartenait pas. Mes quelques stock-options m’ont permis d’obtenir une prime qui ne change pas ma vie (je ne peux pas arrêter de travailler, je ne peux pas rembourser mon prêt immobilier). Ça fait juste de l’argent sur un compte, qui m’aidera un jour à payer une partie des études de ma fille ; c’est déjà ça.

Je n’ai pas participé aux discussions qui ont amené au rachat, ni au négociations concernant la valorisation de notre entreprise. Je ne peux malheureusement pas en parler (sinon je raconterais de conneries). Tout ce que je peux dire, c’est que les premières rencontres avaient pour but de réfléchir à des partenariats commerciaux ; de fil en aiguille, on s’est rendu compte qu’un partenariat « avancé » aurait du sens.

Contrairement aux précédents rachats que j’ai connu, les choses se sont passées (et se passent encore) de manière intelligente et sensée. Nous n’avons pas été absorbés, nous sommes une filiale indépendante, avec toujours nos propres projets, nos propres objectifs, notre propre équipe, notre propre budget.
Évidemment, nous avons des nouveaux projets, menés en collaboration avec notre « maison mère » (ça fait bizarre à dire quand a toujours baigné dans la culture start-up). Il faut bien comprendre et prendre en compte que nous avons été racheté pour de bonnes raisons, et que cela peut impliquer de mettre en place des passerelles techniques entre les plate-formes. Dans notre cas, nous fournissons des contenus à travers des webservices, et nous utilisons des applications fournies de l’autre côté, là encore à travers des webservices.

Les observations

Quand une grosse boîte en rachète une petite, il y a forcément une période d’adaptation. Je pense que nous n’avons pas encore fini d’apprendre et de comprendre comment ils fonctionnent.

La première chose à laquelle il faut s’habituer, c’est la différence des cycles de décision et de développement. Chez nous, les cycles sont mensuels, avec une mise en production à la fin de chaque mois. Chez eux, les cycles sont de 6 mois, avec un overlap de 3 mois (c’est-à-dire que les cycles durent 6 mois, mais qu’il y a une livraison tous les 3 mois, avec toujours deux cycles en parallèle). Pour de bonnes raisons, mais aussi quelques mauvaises, cela s’explique. Mais ça fait quand même bizarre.
Le plus gênant, à nos yeux extérieurs, est la « danse de la négociation technique ». Quand un projet doit être évalué, les équipes techniques semblent multiplier les durées par 2 ou 3, ce qui génère énervement et frustration. Pourtant, on ne peut pas leur en vouloir : à chaque fois, on leur demande d’évaluer un projet qui n’est pas spécifié complètement ; à force de se faire avoir, ils se couvrent maintenant systématiquement…

La deuxième chose à laquelle il faut s’acclimater, ce sont toutes les différences de vocabulaire. Les termes fonctionnels et business sont différents, et les premières semaines sont truffées de moments où les visages s’éclairent au fur et à mesure que les gens comprennent ce que les autres veulent dire.
Mais cela se cache même dans le moindre détail : Quand j’ai rencontré un gars qui se présentait comme faisant partie de la « direction technique », j’ai pensé que c’était l’un des directeurs techniques de l’entreprise. Et au bout du sixième directeur technique, j’ai réalisé qu’ils font partie de la direction technique ou de la direction marketing, de la même manière que nous faisons partie de l’équipe technique ou de l’équipe rédactionnelle.
Ah, et un point de détail : Pour moi, le marketing était principalement une activité en rapport avec la promotion d’un produit et l’adéquation de son offre avec son marché. J’ai découvert que le « marketing produit » pouvait consister à penser les fonctionnalités d’un site web. Nous, on appelle ça « le fonctionnel », mais c’est globalement la même chose.

La troisième chose notable, c’est le retour aux jeux politiques. J’en avais été globalement épargné durant ma carrière, principalement parce que j’ai toujours privilégié les petites entreprises. Mais là, il faut bien se rendre compte qu’une entreprise qui compte plusieurs milliers de salariés nécessite une hiérarchisation plus rigide, et un découpage des équipes. Mais à force de bâtir des silos, on finit par devoir mettre en place des « équipes transverses », dont le travail est de favoriser la communication entre les silos.
Vous avez alors la porte ouverte à des conflits de pouvoir, simplement parce que vous avez plusieurs personnes qui font des choses similaires ; et chacun veut être libre de ses mouvement.
Le problème, c’est que les gens qui vivent ça au quotidien finissent par intégrer ce mode de fonctionnement. Et fonctionnent parfois de la même manière dans leurs intégrations avec nous.

Le vrai soucis

Mais j’ai remarqué un problème bien plus important, qui résulte un peu des différents points précédents. Dans une grosse entreprise, le grand patron a des milliards de choses à gérer. Aussi, il est normal qu’il délègue les évolutions du service/produit à ses directeurs. Eux-mêmes ont beaucoup de choses à gérer, chacune déléguée à une ou plusieurs personnes. Et ainsi de suite sur au moins 3 ou 4 niveaux hiérarchiques.

J’ai ainsi assisté à des réunions dont le but était de parler de l’avancement de spécifications fonctionnelles, concernant l’évolution du service de la maison mère. Lors de la réunion qui devait servir à simplement entériner les maquettes, nous nous sommes retrouvés à poser des questions fondamentales sur les choix qu’ils avaient fait, parce que certains points ne nous semblaient pas optimaux (au mieux) voire pas réfléchis du tout (au pire).
A ce moment-là, j’ai vu le big boss se tourner vers son directeur marketing (souvenez-vous, marketing == fonctionnel). Celui-ci, incapable de répondre aux questions, s’est tourné vers sa chef de produit. Et celle-ci a simplement répondu qu’elle ne savait pas, que nos remarques étaient bonnes et qu’ils allaient modifier la maquette.

Le problème, dans une telle organisation, c’est que vous pouvez avoir plusieurs niveaux hiérarchiques, où chaque personne essaye d’avoir une réflexion globale sans jamais s’attacher aux points de détail. Vous pouvez ainsi vous retrouver avec un site web qui offre une mauvaise ergonomie, simplement parce que certains détails n’ont pas été précisés, et donc le stagiaire qui a fait la maquette a placé les éléments comme il le sentait.
Vous voyez le truc. Et quand le travail remonte les couches hiérarchique, chacun vérifie que ça correspond à ce qu’il avait exprimé.

Nous, ça nous fait halluciner. Parce que tout le monde est sensibilisé au fait de reconsidérer chaque détail, pour tenter de converger vers le meilleur produit possible. Du PDG à l’intégrateur HTML, tout le monde participe à cela.
D’un autre côté, virer de cap rapidement est forcément plus facile quand on pilote un jet-ski que lorsqu’on est à la barre d’un paquebot.

Le futur

Cela fait maintenant 8 mois que nous avons été rachetés. Nous avons accompli quelques beaux projets en collaboration, et nous en avons d’autres dans les tuyaux.

J’ai personnellement la satisfaction d’avoir des interlocuteurs techniques de haute qualité, avec qui il est agréable de travailler ; on parle le même langage, on a la même recherche de l’efficacité. C’est loin des personnes avec qui j’ai pu travailler par le passé dans des conditions similaires, qui étaient plus proches de « technico-commerciaux » que de vrais informaticiens compétents.

J’ai aussi la chance de pouvoir faire appel à tout un panel d’expertises, me permettant d’accélérer la montée en expérience de ma propre équipe technique. Inversement, mes alter ego ont l’intelligence de faire appel à moi quand on aborde des domaines sur lesquels j’ai une expertise plus pointue que la leur. C’est important pour se sentir intégré à un grand groupe, qui sinon pourrait sembler complètement impersonnel.

Mon avis

Le rachat d’une entreprise est toujours un moment très anxiogène. Il est notamment très important de rassurer ses collègues, car tout le monde se met naturellement à craindre pour son emploi, son autonomie, ses responsabilités… Il est assez facile de devenir un peu irrationnel, il faut y faire attention.

Un rachat est idéalement une bonne nouvelle pour les investisseurs et le propriétaire de l’entreprise. Mais personne ne veut acheter une boîte qui risque de se vider de ses compétences (à moins de vouloir racheter une techno sans ses techniciens, une base clients sans les commerciaux qui y sont attachés, etc.). Un bon rachat nécessite donc un travail intelligent de préparation et d’accompagnement des salariés.

Les quelques points importants en cas de rachat :

• Ne vous mettez pas dans une position « nous contre eux ». Tout le monde s’en rend compte, c’est improductif, ça vous dessert.
• Essayez d’apprendre rapidement le vocabulaire et le jargon propres à vos nouveaux collègues. Cela réduira grandement les frictions. Mais il faut aussi leur expliquer votre propre jargon, leur faire comprendre qu’ils doivent l’intégrer s’ils veulent comprendre votre métier.
• Distinguez au plus tôt les quelques interlocuteurs-clés avec qui vous allez travailler. Tentez d’en trouver quelques-uns à des postes très différents, qui vous semblent sympas ; vous pourrez les contacter pour qu’ils vous aiguillent vers la bonne personne, quand vous ne saurez pas qui appeler pour avoir la bonne information. Ça, c’est sans prix.

L’URL est simple : https://github.com/Amaury

Voici une rapide présentation des projets en question.

Temma

Le framework que j’ai développé au sein de mon entreprise. C’est un framework MVC écrit en PHP, qui accélère les développements par son fonctionnement très facile à appréhender.

Toute la documentation est disponible sur http://www.temma.net

FineFS

C’est le système de fichier redondé utilisé là aussi dans mon entreprise. Son principe est de permettre l’accès à des fichiers depuis plusieurs machines d’un même cluster, avec un fonctionnement à la fois synchrone et asynchrone. Il est codé en PHP.

En attendant que toute la documentation soit migrée sur GitHub, elle est toujours visible sur GoogleCode : http://finefs.googlecode.com

FineBase

Il s’agit d’une bibliothèque de fonctionnalités basiques, écrite en PHP. C’est la brique de base sur laquelle Temma et FineFS sont fondés. Les fonctionnalités offertes sont :

• Système de lock, pour empêcher plusieurs exécutions concurrentes d’un même programme ou plusieurs accès simultanés à une même ressource.
• Système de log, pour écrire des messages qui vont être publiés (dans un fichier, sur la sortie d’erreur, via syslog, ou transmis à des handlers) en fonction de leur criticité et des seuils de criticité minimale définis pour chaque couche logicielle. Cela permet par exemple d’avoir un programme pour lequel on verra les erreurs des couches les plus basses, et tous les messages de débuggage pour les couches les plus hautes.
• Un objet de gestion unifiée des sessions, un autre pour la base de données, un autre pour l’accès au cache (utilisant Memcache).
• Un wrapper sur HTML Tidy pour nettoyer du code HTML généré par WYSIWYG.
• Une file de messages stockée en base de données.
• Une extension au SoapClient de PHP, pour supporter l’authentification WSSecurity.
• Un chronomètre de temps d’exécution.
• Un objet de registre, un objet d’écriture ANSI sur la ligne de commande, quelques objets d’exception, …

HeaderBrowser

C’est un outil de génération de documentation à partir de code source en C ou en C++. Dans l’idée, il est assez similaire à JavaDoc ou PHPdoc, se basant sur des commentaires contenant des marquages spéciaux. Par contre, la documentation générées est affichée d’une manière qui facilite grandement la navigation ; vous pouvez en trouver un exemple pour la bibliothèque Ylib (voir plus bas).

Écrit en C++, cet outil est maintenant un peu ancien.

Plus d’information sur le site http://www.headerbrowser.org

Ylib

Ce projet propose une bibliothèque de fonctions, écrite en C. Il y a pas mal de choses à l’intérieur :

• Calcul de CRC, encodage/décodage en Base64 et quoted-printable.
• Quelques helpers sur la gestion de la mémoire (malloc/free).
• Gestion du lock et du log.
• Chronomètre de temps d’exécution.
• Décodage d’URL.
• Chaîne de caractère bufferisée, vecteurs bufferisés.
• Gestion simplifiée de scripts CGI.
• Parseurs XML, SAX et DOM, et interprétation XPath.
• Wrapper de connexion réseau, helper de création de démon.
• …

La documentation, générée avec HeaderBrowser : http://ylib.amaury.net/hbresult-html/

Carta Genius

Là il s’agit d’un logiciel servant à créer des documents PDF de qualité professionnelle. Je l’avais créé au début pour faire des planches de cartes de jeu, que je faisais imprimer par des imprimeurs numériques professionnels. Cela demandait un certain nombre de fonctionnalités particulières : réutilisation d’images, transparence, traits de coupe (pour que l’imprimeur sache où couper, sans que les traits n’apparaissent sur les cartes), fond perdu, imposition (faire correspondre le recto et le verso), etc.

Par la suite, j’y ai ajouté pas mal de possibilités, qui permettent de l’utiliser pour générer tout type de PDF. J’y ai notamment ajouté un interpréteur, qui permet de faire des écritures assez poussées.

En conclusion

Je ne suis pas encore opérationnel à 100% avec Git. J’ai tellement l’habitude de Subversion que plusieurs choses me semblent inutilement complexes avec Git. Mais il faut reconnaître que c’est très pratique pour faciliter les contributions sur un projet open-source.

N’hésitez pas à cloner les projets et à faire des « pull requests » pour me proposer vos améliorations. J’y apporterai toute l’attention nécessaire.

Le manifeste

Plutôt que de faire un copier-coller bête et méchant de la version originale, voici une traduction approximative :

Je suis un développeur PHP
Je ne suis pas un développeur Zend Framework ou Symphony ou CakePHP.
Je pense que PHP est déjà suffisamment compliqué.

J’aime créer des choses simples
J’aime créer des choses simples avec des objectifs simples.
J’aime créer des choses qui résolvent des problèmes.
J’aime créer des choses simples qui, mises ensemble, résolvent des problèmes complexes.

Je veux moins de code, pas plus
Je veux écrire moins de code, pas plus.
Je veux gérer moins de code, pas plus.
Je veux maintenir moins de code, pas plus.
Chaque morceau de code que j’ajoute à un projet doit être justifié.

J’aime le code simple et lisible
Je veux écrire du code qui se comprend facilement.
Je veux du code qui se teste facilement.

Le détail

Le créateur de ce manifeste explique sa pensée plus en détail sur son blog. Dans un premier post, il donne sa vision d’ensemble. Mettons de côté sa comparaison musicale (il compare l’installation de deux batteurs, pour dire qu’il se voit comme un codeur punk, et non pas comme un codeur rock-progressif… mais on s’en fout un peu).

Ce qui est intéressant, c’est lorsqu’il donne un exemple de code, censé être typique des applications Zend Framework :

<?php
chdir(dirname(__DIR__));
require_once (getenv('ZF2_PATH') ?: 'vendor/ZendFramework/library') . '/Zend/Loader/AutoloaderFactory.php';
Zend\Loader\AutoloaderFactory::factory(array('Zend\Loader\StandardAutoloader' => array()));

$appConfig = include 'config/application.config.php';

$listenerOptions = new Zend\Module\Listener\ListenerOptions($appConfig['module_listener_options']);
$defaultListeners = new Zend\Module\Listener\DefaultListenerAggregate($listenerOptions);
$defaultListeners->getConfigListener()->addConfigGlobPath('config/autoload/*.config.php');

$moduleManager = new Zend\Module\Manager($appConfig['modules']);
$moduleManager->events()->attachAggregate($defaultListeners);
$moduleManager->loadModules();

// Create application, bootstrap, and run
$bootstrap = new Zend\Mvc\Bootstrap($defaultListeners->getConfigListener()->getMergedConfig());
$application = new Zend\Mvc\Application;
$bootstrap->bootstrap($application);
$application->run()->send();

Et là, je le rejoins complètement. C’est une chose que j’ai déjà rabâchée à plusieurs reprises. À mon sens, un framework doit simplifier le développement, le rendre plus rapide et plus lisible. C’est une évidence pour tout le monde, mais le moyen d’y arriver ne semble pas être commun à tous.

À mes yeux, le code d’une application doit être limpide. Évidemment, on s’attend à avoir un « socle de base », un « moteur » sous-jacent qui est là pour simplifier les choses. L’exemple de code ci-dessus est sans appel. Moi non plus, je ne veux pas avoir à coder des trucs comme ça.

Je peux comprendre qu’il puisse y avoir à choisir entre complexité du code d’un côté, et complexité de la configuration de l’autre. Si un framework rend le code simple, mais au prix d’une configuration plus complexe, cela peut s’expliquer. Ensuite, tout dépend de là où on souhaite mettre le curseur. Une configuration plus simple aura sûrement pour effet de complexifier le code.
Le problème, c’est qu’on se retrouve parfois à avoir du code complexe ET des fichiers de configuration illisibles.

Les micro-frameworks et les micro-bibliothèques

L’auteur du manifeste prend ensuite le parti de dire qu’il existe des micro-frameworks qui font très bien le boulot. Prenant l’exemple de Slim, Epiphany, Breeze et Limonade, il part du principe qu’il sont largement suffisant pour la plupart des besoins, et que son approche est de les enrichir grâce à des bibliothèques de fonctions, plutôt que de vouloir utiliser un framework « full-stack ».

Pour rappel, les micro-frameworks fonctionnent quasiment tous sur le même modèle. Pour illustrer la chose, voici l’exemple de code fourni par Slim :

<?php
require 'Slim/Slim.php';
$app = new Slim();
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name!";
});
$app->run();
?>

Pour finir, l’auteur du manifeste tient à jour une liste de projets, qui sont tous censés être simples à utiliser, qui remplissent une seule fonctionnalité (ou un groupe de fonctionnalités connexes). L’idée est sympa, même si le nombre de projets similaires réduit son utilité.

Mon avis

Je suis complètement d’accord avec ce manifeste. Le code doit être simple ; rapide à écrire, facile à lire, facile à modifier. Je pense que personne ne dira le contraire.

Le seul point sur lequel je suis un peu plus circonspect, c’est en ce qui concerne les micro-frameworks. Je m’y suis intéressé un peu à une époque, et j’ai joué avec Silex, notamment. Et je n’ai pas trouvé que cette approche simplifiait réellement l’écriture de vrais sites.

Je suis peut-être trop formaté par l’approche à laquelle je suis habitué, mais je ne pense pas que la manière dont le routage est imbriqué dans le code soit l’idéal pour avoir du code simple à lire et à maintenir. Et plus le site sera important, plus ce sera vrai.

Cela m’amène à parler un peu du framework Temma.
Comme présenté sur le site du projet, l’idée générale est très simple :

• Pour une URL du type /article/show/123/title
• le framework exécute ArticleController::execShow(123, ‘title’);
• et transmet les données au template article/show.tpl

Et, à part une configuration très succincte (paramétrage de l’accès à la base de données), tout ce qu’on se retrouve à écrire comme code, ce sont simplement des objets dont les méthodes vont répondre aux URL. Nous sommes d’accord qu’il n’y a rien de fondamentalement novateur là-dedans, cette approche est partagée par de nombreux frameworks. Mais le code applicatif n’est pas pollué par le framework.

L’idée générale de Temma est de proposer quelques fonctionnalités de base (il y a quand même un embryon de routage, une gestion des sessions et du cache, de la base de données, …), qui sont extensibles à l’aide de plugins. On en parlait récemment sur le forum de discussion qui lui est consacré. Si vous avez besoin d’un routage élaboré, il suffit d’ajouter un plugin ; si vous voulez gérer un site multilingue, encore un plugin ; et ainsi de suite.
Ça permet de garder un cœur simple à comprendre et à assimiler, tout en gardant la souplesse d’en faire ce qu’on veut en fonction de nos besoins.

Pour en revenir au manifeste micro PHP, je pense qu’il s’agit surtout d’un rappel d’un principe fondamental du développement. Quand on développe, on sépare le code en entités séparées les unes des autres. La programmation orientée objet facilite cette approche en fournissant la brique de base de ce concept ; mais au-dessus de l’objet, il y a les bibliothèques qui regroupent plusieurs objets.

Ces différentes entités s’appellent entre elles pour profiter des fonctionnalités qu’elles offrent. Ce qui fait la différence entre un bonne bibliothèque et une mauvaise, c’est entre autre à quel point elle encapsule sa complexité et réussit à présenter une interface simple et facile à utiliser. Si une bibliothèque impose d’écrire des dizaines de lignes de code pour simplement y faire appel, ou si son API est tellement obscure qu’il faut faire plusieurs appels pour réaliser la moindre action simple, c’est qu’il y a un soucis.

Malgré tout, il y a des cas où ça coince fonctionnellement. Et quand on a besoin de souplesse, il n’y a rien de mieux que de le faire soi-même.
En plus, Adrien semblait dire en commentaire que c’est quelque chose d’assez facile à faire, alors j’ai voulu expérimenter la chose.

Pour l’environnement technique, je suis parti d’un serveur sous Linux, en utilisant la distribution Ubuntu version 11.04. J’ai utilisé le serveur mail Exim, car c’est celui sur lequel j’ai le plus d’expérience ; il y a quelques années, c’était le seul MTA qui proposait une intégration poussée avec le filtre anti-spam SpamAssassin (du moins dans les paquets fournis par Debian/Ubuntu).
Enfin, j’ai fait en sorte que les emails reçus soient traités par un script écrit en PHP (je ne vais pas revenir là-dessus).

Je vais vous expliquer comment j’ai procédé. Pour l’exemple, on va dire que le serveur n’est utilisé que pour le seul domaine toto.com, et que tous les messages reçu sont envoyés au même script PHP, quelle que soit l’adresse email du destinataire (c’est donc un « catch-all » sur le domaine toto.com).

Installation

Pour commencer, j’ai installé PHP en mode ligne de commande :

$ sudo apt-get install php5-cli

Puis Exim et SpamAssassin :

$ sudo apt-get install exim4-daemon-heavy sa-exim spamassassin

Nous allons maintenant voir la configuration d’Exim et de SpamAssassin. Je ne vais pas parler de la configuration de PHP (ce sera peut-être pour un autre article).

Configuration de SpamAssassin

Éditer le fichier /etc/default/spamassassin :

ENABLED=1
CRON=1

Cela lui indique de s’activer, et de mettre ses filtres à jour en utilisant la crontab.

Démarrer de démon spamd :

$ sudo /etc/init.d/spamassassin start

Mise-à-jour des règles de spam :

$ sudo spamassassin -D --lint
$ sudo sa-update
$ sudo sa-compile
$ sudo sa-update -D channel,dns
$ sudo spamassassin -D --lint

Éditer le fichier /etc/spamassassin/local.cf :

report_safe 1
use_bayes 1
bayes_auto_learn 1
bayes_ignore_header X-Bogosity
bayes_ignore_header X-Spam-Flag
bayes_ignore_header X-Spam-Status

Pour activer la détection basique de virus intégrée à SpamAssassin, il faut éditer le fichier /etc/spamassassin/v310.pre et décommenter la ligne suivante :

loadplugin Mail::SpamAssassin::Plugin::AntiVirus

Enfin, redémarrer SpamAssassin :

$ sudo /etc/init.d/spamassassin restart

Configuration d’Exim

Pour que Exim écarte automatiquement les spams, il faut lui dire d’utiliser SpamAssassin. Éditer le fichier /etc/exim4/sa-exim.conf et commenter la ligne suivante :

SAEximRunCond: 0

Éditer le fichier /etc/exim4/update-exim4.conf.conf pour indiquer le nom de domaine local :

dc_other_hostnames='toto.com'

Comme un bourrin, je lui dis d’écouter sur toutes les interfaces réseau, sur le port 25. Il faut éditer le fichier /etc/exim4/conf.d/main/01_exim4-config_listmacrodefs :

local_interfaces = 0.0.0.0.25

Un petit détail qui a son importance, il faut dire à Exim de ne pas essayer de chercher l’identité de l’expéditeur. C’est un truc inutile, qui risque de générer un timeout qui ralenti le traitement de tous les messages reçu. Il faut donc éditer le fichier /etc/exim4/conf.d/main/02_exim4-config_options :

rfc1413_query_timeout = 0s

On va maintenant créer une route qui prendra en compte les messages reçus. On va créer le fichier /etc/exim4/conf.d/router/999_exim4-config_toto :

toto:
  debug_print = "R: toto for $local_part@$domain"
  driver = accept
  domains = +local_domains
  transport = toto_pipe

Il faut ensuite créer une méthode de transport, qui va exécuter la commande spécifiée, ouvrir un « pipe » vers ce programme et y envoyer le contenu du message reçu. On va créer le fichier /etc/exim4/conf.d/transport/999_exim4-config_toto_pipe :

toto_pipe:
  debug_print = "T: toto_pipe for $local_part@$domain"
  driver = pipe
  path = "/bin:/usr/bin:/usr/local/bin"
  command = "/chemin/vers/mon/script.php"
  return_path_add
  delivery_date_add
  envelope_to_add

J’ai mis en gras la partie qui nous intéresse le plus, celle qui détermine le programme qui sera exécuté, et à qui Exim transmettra le contenu de chaque message reçu.

On n’a plus qu’à redémarrer Exim :

$ sudo /etc/init.d/exim4 restart

Programme PHP

Le programme qui va traiter les messages doit simplement lire sur son entrée standard pour récupérer le contenu brut du message.

Voici une première version simpliste qui se contente d’enregistrer le contenu du message dans un fichier :

#!/usr/bin/php
<?php

$email = file_get_contents('php://stdin');
$filename = tempnam('/tmp', 'mail-');
file_put_contents($filename, $email);

?>

J’ai essayé d’envoyer des emails, et j’ai bien récupéré les fichiers correspondant. J’ai même pu vérifier que le filtre anti-spam fonctionnait : J’ai envoyé des emails en mettant comme adresse d’expéditeur un nom de domaine dont le champ SPF indiquait une adresse IP différente de celle que j’utilisais pour envoyer le message (vous avez suivi ? sinon dites-le moi en commentaire, j’expliquerai plus longuement), et le message a directement été refusé par Exim, sans même le transmettre au script PHP.

Pour aller plus loin, il faudrait décoder les parties MIME du message, pour en extraire les différentes informations. Il existe suffisamment de tutoriaux sur ce sujet pour pouvoir s’arrêter là.

Pour le moment, je vais juste reprendre une partie de ce que j’avais écrit, concernant la syntaxe des langages.

Une des caractéristiques essentielles d’un langage de programmation, c’est d’être facile à lire et à relire. On doit pouvoir lire du code source comme un linguiste peut lire un texte écrit dans une langue étrangère.
Cela passe notamment par un syntaxe légère, qui ne se mette pas en travers de la lecture, qui ne soit pas inutilement verbeuse et qui reste sans ambiguïté.

Blocs, labels, accolades et indentation

Pour illustrer mon propos, je vais vous montrer comment on code la factorielle récursive dans plusieurs langages procéduraux. Tout d’abord en Pascal :

FUNCTION factorielle (n: shortint) : integer;
BEGIN
    IF n <= 1 THEN
        BEGIN
            WRITELN('End of loop');
            factorielle := 1
        END
    ELSE
        BEGIN
            WRITELN('Loop');
            factorielle := n * factorielle (n - 1)
        END;
END;

Ensuite en BASIC (VB.net, inspiré par le site Developpez.com, © Philippe Laserre) :

Function Factorielle (ByVal N as Long) As Long
    If N=1 Then
        Console.WriteLine("End of loop")
        Return 1
    End If
    Console.WriteLine("Loop")
    Return N * Factorielle(N - 1)
End Function

Et voici le code équivalent en C :

int factorielle(int n)
{
    if (n <= 1)
    {
        printf("End of loop\n");
        return 1;
    }
    printf("Loop\n");
    return n * factorielle(n - 1);
}

def factorielle(x):
    if x <= 1:
        print("End of loop\n")
        return 1
    print("Loop\n")
    return x * factorielle(x - 1)

ma_liste = [
       "aaa",
                     "bbb",
  "ccc"
]

for i:= 0; i < flag.NArg(); i++ {
    if i > 0 {
        s+= space
    }
    s+= flag.Arg(i)
}

for (i = 0; i < flag.NArg(); i++) {
    if (i > 0)
        s += space;
    s += flag.Arg(i);
}