Christie Poutrelle a écrit 381 commentaires

Je regarde ce projet et lis leur "this week in…" régulièrement, c'est un projet qui à l'air super intéressant, je suis content de voir ce journal ici, je n'avais pas encore vu que le toolkit avait été renommé.

Spoiler: j'ai à peine effleuré les bouquins, mais le monde de Dune est finalement tellement complexe qu'il est impossible à transcrire complètement dans une œuvre audio-visuelle, et pourtant, il y en a des très bien réussies sur le sujet.

Je ne boycotte pas les films américains, certains sont censés, certains sont très bien, tous ne sont pas des besson qui explosent et tirent dans tous les sens. Et de notre côté de l'atlantique on sait aussi faire des grosses daubes.

J'ai regardé le début de la série Fondation (les 2 premiers épisodes) et commencé les livres en même temps. Le début de la série est très réussi (j'ai pas vu la fin), et clairement ne raconte pas la même histoire, ce qui ne me gâche justement pas les livres, et finalement c'est pas plus mal comme ça.

Faut pas tout rejeter en bloc. Quand à l'analyse psychologique, merci, mais c'est à mon avis hors-sujet. Même si la culture américaine est très différente de la notre, le contexte de mondialisation des idées (merci internet, les médias, les réseaux sociaux) ainsi que les très nombreuses personnes qui se déplacent d'un continent à l'autre (ce qui se passe depuis la nuit des temps) a généré un mélange des cultures en tout lieu et tout temps qui fait que toute tentative de manichéisme culturel est un réflexe de survie désuet de vieux réac, au mieux vouée à l'échec, au pire créateur de division (ce l'était déjà il y a 50, 100 ou 1000 ans). Le débat gros sous d'Apple qui pourrit une série est probablement plus pertinent.

Sinon dans le même genre, j'ai pas lu le livre mais des revues de ce dernier, mais la série Man In The high Castle (série Amazon) est très bien. Je déteste Amazon, mais j'ai adoré la série; encore une fois il faut garder en tête qu'elle pose le même décor mais raconte une histoire différente du livre, ne serait-ce que parce qu'elle interprète une histoire plus de 50 ans après son écriture originelle, et que si elle avait été transcrite telle quelle, tout serait tellement obsolète que ça serait un vrai nanard.

Moi je suis d'accord avec toi, le commentaire auquel tu réponds sous-entends que par défaut, un administrateur Windows est moins compétent qu'un administrateur Linux/UNIX, et c'est très clairement un argument inacceptable.

Il y a des gens extrêmement compétents dans le domaine du libre comme dans le domaine du propriétaire, ce sont des choix ou des opportunités professionnelles différentes qui ont mené ces gens sur des spécialisations différentes, mais on ne peut pas juger de la compétence générale des gens selon leur métier comme ça de but en blanc.

C'est extrêmement dangereux d'oser ostraciser tout une frange de gens de la sorte, juste parce qu'ils "n'utilisent pas Linux", c'est tout simplement une insulte. Les populistes et les fascistes utilisent ce genre d'affirmation pour créer du communautarisme.

Je t'ai plussé, que tu aies raison ou pas, tu as eu raison de lui répondre.

PS: Fonctionnellement, SQL server est très avancée, cette base de donnée n'a pas grand chose à envier à PostgreSQL. Et des sites comme Stack Overflow ont pu prouver que c'est une base de donnée qui sait tenir des charges absolument indécentes. C'est un excellent logiciel.

Je suis étonné pour un prof de maths que tu n'aies pas conservé un clavier avec un pavé numérique ! Personnellement (je ne suis pas prof de maths du tout) mais je n'arriverais pas à m'en passer. Y-a-t'il une raison particulière autre que le simple gain d'espace sur le bureau ?

C'est un peu ironique, mais c'est aussi assez pertinent: c'est difficile de faire pire pour la vie privée que Chrome vu qu'il est de facto branché sur Google avec ou sans ton avis, a priori Edge est forcément meilleur de ce point de vue :)

Bon finalement, pourquoi pas, ce n'est qu'un navigateur. En tant que développeur web, je trouve ça cool de l'avoir à disposition pour ma machine Linux.

Et puis ça reste à tester, vu qu'ils utilisent le moteur Blink, ça pourrait être un Chrome avec plus de garanties pour la vie privée.

La partie riche (pour laquelle l'équivalent purement texte est requis) n'est pas forcément du HTML mais peut être tout et n'importe quel autre format de document, comme du RTF ou du PS par exemple.

Oui, la magie du mime permet absolument n'importe quel datatype, c'est ce qui rend ce format de sérialisation merveilleux (je suis vraiment un fan du mime, bien que je ne pense pas que ce soit adapté au mail).

Cependant tous les clients ne prennent pas en charge nativement l'affichage d'un RTF ou d'un PS directement dans le corps du mail sans sortir de l'interface de ton client (par exemple un PDF, Thunderbird ne va pas le lire directement dans le corps du mail, mais (anciennement) l'ouvrir dans une appli tierce ou (nouvellement) l'ouvrir dans un nouvel onglet, ce qui impose à l'utilisateur de sortir du flux de lecture de son thread.

Ouais, c'est vrai tout ça, mais les client mails n'envoient pas toujours de part en textplain, et ça force les clients à procéder à du nettoyage et du reformatage "au mieux" pour avoir une version texte.

J'ai fait un projet perso purement pédagogique, un webmail un peu moderne, et je me suis tombé sur ce problème difficile: beaucoup de mails générés (parfois même provenant d'un client d'un utilisateur final) ne mettent pas le même texte dans la version formatée en HTML et dans la version texte. Du coup, dans le doute, t'as plutôt intérêt à toujours partir de la version formatée en HTML et de le réduire pour le transforme en texte.

Mais faire ça c'est hyper compliqué, ça pose des soucis énorme de filtrage de sécurité, dans mon projet perso je me suis fait avoir à exécuter du JS qui était tellement bien intégré (c'était clairement en provenance d'un spam malveillant) que même le strip total des tags avec une API faite pour s'est faite avoir et m'a injecté le JS dans mon rendu final…

Enfin on retombe toujours sur le même problème, texte WYSIWYG (word et autres) VS texte sémantique (tex et autres), l'humanité n'arrivera jamais à se mettre d'accord sur une sémantique simple et claire pour représenter du texte et laisser le choix au lecteur de la mise en forme.

L'égo surdimensionnée du rédacteur est aussi un problème dans cette histoire, les gens aiment pourrir les yeux des autres en leur imposant leur propre goût pour le texte en majuscules, gras et surligné en jaune pour dire que c'est important (sans tenir compte bien entendu de la couleur du texte et de la couleur de fond par défaut du client en face, qui peut être en blanc sur fond noir pour des raisons d'accessibilité par exemple).

Perso je suis fan du format mime, c'est facile à parser et à générer, tu peux pomper ou crasher des gigas de données sans jamais consommer de mémoire, c'est séquentiel !

Par contre, pour une messagerie, c'est nul. Tous les clients mails font du HTML (WTF pourquoi on met du HTML dans les mails ?).

Du coup, au lieu de laisser le client (c'est à dire le lecteur) choisir sa police et sa taille de police, on laisse le client (ici l'envoyeur) décider ce qu'il met dedans.

Le problème du mail, c'est que c'est un protocole de messagerie dans le sens générique du terme (déposer des trucs) mais pas un protocole de messagerie (dans le sens chat du terme): c'est pas adapté à l'échange de messages genre "bonjour ça va ?", mais au contraire à l'échange de fichier.

Le mail devrait rester dans notre outillage (moyennant sécurité et authentification et chiffrement en plus) comme un transporteur de colis (si on devait faire l'analogie avec la poste) et ne devrait plus être utilisé pour du texte lisible pour un être humain (ou alors, il faudrait s'accorder sur un format de document universel, basé sur une sémantique et pas des balises <font size=12px color=red>COUCOU MAMIE</font>, pas vraiment adapté pour le milieu professionnel, ni pour mamie d'ailleurs.

La Tartiflette, c'est comme TapTempo, c'est un sujet très sérieux qu'il est rigoureusement impossible de traiter dans un seul 'nal.

De ce que j'ai compris, c'est surtout que ça nécessite énormément d'eau pour le miner, le laver, etc… et que parmis les plus gros gisement mondiaux (mexique et bolivie entre autre) certains sont dans des zones désertiques. De plus l'eau qui a servi à laver le lithium et le matériel (tuyaux, etc…) est souvent rejeté dans la nature. C'est pas si différent que pour pas mal d'autres métaux qu'on récolte, mais la demande ayant augmenté de manière fulgurante, les producteurs sont allés au plus vite et pas au plus respectueux pour répondre à la demande. Et comme toutes les mines, différents additifs en tout genre sont utilisés, parfois on combine aussi la production du lithium à d'autres productions (on recycle les déchets de la production pour en faire quelque chose) mais en combinant plusieurs productions différentes, on multiplie aussi les additifs chimiques utilisés, qui se retrouve, une fois consommés, en quantité non négligeable dans l'eau utilisée et rejetée.

Je tiens à préciser que c'est très approximatif, c'est ce que j'ai retenu des différents articles que j'ai lu (il y a longtemps) sur le sujet. Maintenant, c'est clair que je ne suis pas spécialiste, ni en minage, ni en chimie, ni en écologie.

Les voitures électriques. Alors, en dehors du coût prohibitif des modèles haut de gamme, on est là aussi dans l'inconnu écologique. Rouler à l'électrique, c'est zéro émission de CO2 par le véhicule en fonctionnement. Mais la production de l'électricité ?

L'intérêt de la voiture électrique, c'est qu'il n'y a pas qu'une manière de produire cette dernière. Si demain on change radicalement la façon dont on produit l'électricité, nous n'auront pas besoin de changer le parc automobile: polluant ou non, la voiture est complètement agnostique de la provenance de l'énergie, et ça c'est cool.

Perso je mets en place des projets utilisant l'architecture hexagonale, on est en plein dedans: la voiture est le domaine métier du déplacement, elle a besoin de consommer de l'énergie, et on peut y brancher n'importe quel adaptateur; de ce fait, en cas de changement profond de l'infrastructure, on a pas besoin de faire de maintenance dans le domaine métier, et donc de changer de voiture ou de moteur.

La pollution se situe alors, concernant ces voitures, pas dans l'énergie même, mais dans les matériaux utilisés pour sa production. C'est une question de point de vue bien entendu (littéralement) mais un observateur placé dans la voiture ne voit ni n’émet aucune pollution (mis à part l'usure de ses plaquettes de frein, qui tue des gens, mais là c'est encore un autre problème, adopter une conduite souple basée sur l'anticipation peut déjà réduire drastiquement cet effet de bord).

Bon le lithium, c'est carrément l'enfer, j'espère qu'un jour des batteries moins polluantes existeront.

Cependant je reste persuadé qu'avoir un moteur qui consomme de l'énergie quelle que soit sa provenance reste la seule façon de ne pas être dépendant d'une source, et a seule façon d'avoir une lueur d'espoir de se sortir de la pollution un jour.

Bon maintenant, la seule énergie qui ne pollue pas du tout, c'est celle qu'on ne consomme pas, alors au lieu d'aller polluer les hôpitaux avec nos problèmes cardiaques à cause de notre surpoids, on ferait globalement mieux d'utiliser plus le vélo pour consommer toute cette vilaine énergie qu'on a stocké bêtement dans notre ventre, nos cuisses, nos bras et qui s'accumule un peu aussi dans notre cerveau, diminuant ainsi nos capacité cognitives.

Tu vois t'es encore entrain de comparer des choux et des patates. L'un ne stock rien sur disque et est là pour faire de la latence faible a un modèle de stalabilité… particulier. Là où l'autre écrira toujours tout sur disque fourni largement plus de garanties etc. Bon perso je trouve que redis est le roi du goodenought, mais c'est une autre histoire.

C'est faux comme affirmation. Par défaut, Redis écrit tout sur le disque, et de façon synchrone en plus, comme PostgreSQL.

Les deux ont une latence relativement faible, mais Redis est bien plus efficace avec un très grand nombre de connexions.

Redis permet de faire des transactions qui sont (de mémoire) presque ACID. Je n'y a pas retouché depuis 3~4 ans, mais j'ai testé dans tous les sens à l'époque de la version 2.8 et 3, et ça marche.

Redis ce n'est pas goodenought, ça dépend comment tu le configure, mais presque toutes les bases de données quel que soit leur type, te permettent de les configurer pour les rendre plus rapide et moins safe, ou plus lentes et très safe.

On a utilisé Redis sur des productions pendant plusieurs années, on a jamais eu de soucis particulier, ça marche comme c'est écrit.

Oui j'ai remarqué que plusieurs opérateurs avaient effectuée ce changement, dont Orange sur les livebox récentes (adieu le bypass pour Orange, ou bonne chance pour trouver un routeur qui supporte leur ONT en SFP).

C'est pas si open-bar que ça, ça marche, t'as le réseau, ton routeur prend facilement le DHCP etc, c'est cool, par contre adieu téléphonie et TV.

De la meme maniere, un simple reglage software permet a l'operateur de limiter la bande passante au forfait achete, ce qui permet de vendre des forfaits 1Gbps ou 100Mbps selon ce que l'utilisateur souhaite.

Chez SFR (j'ai la fibre chez eux) d'après ce que j'ai compris c'est l'ONT qui fait ça, pas la box, l'ONT gère aussi l'authent. Du coup, la box ne sert vraiment à rien. C'est dommage, l'ONT se branche en RJ45 sur la box, je pourrais presque complètement m'en passer.

Le SQL est un langage standardisé (et d'ailleurs, PostgreSQL est un SGDB qui respecte le standard, presque le seul, hors fonctionnalités qui vont au delà du standard) qui a plus de 40 ans maintenant.

Ça s'apprend, et c'est pas compliqué en vrai. J'en fais depuis des années certes, donc c'est difficile de me mettre dans la peau de quelqu'un qui apprend de zéro, mais je l'ai appris à un moment ou un autre. Le seul changement de paradigme un peu perturbant, je pense, c'est de raisonner de façon ensembliste (bien que le SQL ne soit pas réellement une transposition de la théorie des ensembles, il s'en inspire). Toute personne qui travaille sur un langage qui gère correctement les collections et a un système de typage complet y trouvera beaucoup de choses familières. Enfin, pour des requêtes simples, et même certaines plus complexes, il n'y a définitivement pas besoin d'être mathématicien, ni même de connaître quoi que ce soit à propos de la théorie des ensembles.

En plus, c'est vraiment cool comme langage, parce que c'est spécifié comme étant un langage déclaratif: tu dis ce que tu veux comme résultat, et c'est au serveur de choisir comment l'interpréter, et de choisir la façon optimale pour obtenir le résultat que lui a demandé.

Donc en tant que développeur, le langage t'ôte la responsabilité de devoir penser performance à la place du serveur, ce qui le rend bien plus accessible que la majeure partie de langages qu'on manipule tous les jours, qui vous nous exposer des détails techniques complexes pour permettre de contourner les faiblesses de ton processeur ou te forcer à gérer ta mémoire par toi même. Le SQL s'affranchit complètement de toutes ces contraintes qui polluent la sémantique, et te permet de réfléchir uniquement à tes données. Il te fourni une langue pour exprimer simplement des transformations de collections de données. C'est même bien plus expressif et lisible que les libraries réactive-fonctionnelles très à la mode en ce moment.

PostgreSQL est réputé pour avoir le meilleur moteur d'optimisation de requête SQL au monde (à tel point qu'il est aussi utilisé par d'autres outils) et pour avoir testé et écrit des choses vraiment compliquées avec, mis à part de très rare cas (vraiment très rare) avec les versions récentes de PostgreSQL plus tu écris le SQL simplement et naïvement, et mieux ça se passe.

Des langages qui ont essayé de substituer au SQL, ça existe, mais aucun ne fait consensus, et à mon avis ce n'est pas pour rien: aucun de ceux que j'ai pu rencontrer ne permettait réellement d'être à la fois généraliste et d'abstraire des fonctionnalités avancées du SQL dans quelque chose de plus simple.

Je pense honnêtement, au vu de ce que ça permet de faire, que de concevoir un langage plus simple que le SQL pour le remplacer semble impossible, quant bien même il pourrait sûrement être amélioré (je pense notamment à la syntaxe horrible pour les accès au json). Il y a des cas où c'est possible et ça marche, mais c'est presque systématiquement des langage qui sont en fait des DSL (Domain Specific Language), conçus pour répondre à des problématiques métier, et qui par conséquent ne peuvent être utilisé en dehors.

Après, rien n'empêche d'imaginer un jour écrire un SQL-v2, qui soit une nouvelle langue plus moderne, mais je pense que sa complexité sera au moins équivalente au SQL lui même.

mongo et postgre sont 2 outils très différents

C'est vrai, je suis d'accord, cependant tout dépend du besoin. Quand tu veux faire du CMS, de la vitrine, un site métier mais sans fortes contraintes relationnelles, ou juste quand tu es le commun du mortel, le choix entre un SGBD et une base NoSQL est parfois ambigu: les deux vont fournir les fonctionnalités nécessaires et suffisantes pour le besoin, et les deux vont écrire noir sur blanc dans leur documentation que c'est le bon outil pour implémenter ce besoin. Finalement, tout comme les SGBD, MongoDB est assez polyvalent lui aussi.

La seule différence sera dans la façon de l'utiliser, et souvent la bonne réponse reste le SGBD conventionnel un poil plus polyvalent. C'est juste une question d'échelle, si passer au NoSQL ne déverrouille pas une contrainte que tu aurais avec le SGBD classique (comme par exemple, le besoin de passer à l’échelle horizontalement, et encore que…), autant rester sur l'ennuyeux SGBD classique car c'est souvent un outil plus mature, plus stable, pour lequel on trouvera un meilleur support et plus de gens compétents pour travailler avec.

Je ne comprends pas trop les gens qui disent "j'étais avec X, oulala les galères, je suis passé sur Y (Y ayant rien à voir avec X),

C'est là que je ne suis pas d'accord. À l'époque, et c'était un choix de design logiciel assumé par MongoDB, une lecture et une écriture en même temps sur la collection influaient l'une sur l'autre, et des enregistrements pouvaient simplement ne pas être écrit, des mises à jour pouvaient être ignorées, et la lecture pouvait lire un même document deux fois, etc… C'était des comportements très grave, et impossibles à ignorer dans notre contexte, où on avait beaucoup de lectures et écritures concurrentes.

Maintenant ils semblent avoir implémenté correctement quelque chose qui ressemble enfin à des transactions, mais il leur a fallu du temps, plusieurs années même. Ça refroidit vraiment, c'est devenu pour nous un outil à fuir absolument. Trop de mauvaises surprises, et certains étaient même assumées par ses mainteneurs et marqués comme étant "par design".

Ma machine à laver n'est pas meilleure que mon vélo.

Là, tu es carrément de mauvaise fois, MongoDB est très polyvalent, PostgreSQL l'est encore plus, et les deux sont dans la même niche: des bases de données. Il y a une intersection entre les deux espaces fonctionnels fournis par ces deux outils. Je pourrais dire la même chose avec Cassandra et MSSQL, ou encore bien d'autres bases de données.

tu entends "sauf ma majeure partie des fonctions relationnelles"

Non pas forcément, PostgreSQL va bien au delà, il convient très bien aussi pour faire du clé-valeur (bien que j'ai un faible pour Redis pour ce besoin), pour faire du publish/subscribe (event/notify), pour implémenter de la recherche fulltext, et ses capacités vont encore bien au delà (et sans parler des extensions). MongoDB s'est amélioré avec le temps, je dis pas, seulement, vu son âge finalement peu avancé comparés à beaucoup d'autres bases de données, je lui fais encore pas confiance.

Ouais, ce sont des tests, ça fait très longtemps que j'ai éteint ce blog. Maintenant le certbot n'est malheureusement pas automatique, je n'ai pas pris le temps de faire convenablement la conf de mon haproxy, du coup je dois le down et up manuellement pour faire les maj de certificat.

C'est pas si sûr, d'après des benchmarks que j'avais lus (d'il y a un an ou deux j'arrive pas à les retrouver) PostgreSQL explose MongoDB en performances brutes quand on l'utilise en mode "document" avec du jsonb.

En plus avec PostgreSQL tu peux explicitement créer les indexes comme bon te semble, et profiter de toutes ses autres fonctionnalités.

Donc quant bien même la syntaxe est chiante pour écrire des requêtes qui manipulent le jsonb (elle est vraiment très chiante, je sais de quoi je parle) ça vaut toujours le coup d'évaluer PostgreSQL quand le besoin se pose.

Surtout qu'avec MongoDB, tu peux pas faire de relationnel le jour où tu dis que "merde, en fait j'en ai besoin", alors qu'avec PostgreSQL, tu l'as, et bien plus encore !

Bon, puis j'ai eu beaucoup trop d'emmerdes avec MongoDB, on l'a utilisé sur un site à fort traffic / gros volumes de données, on a fini par le remplacer par un SGBD plus classique et tous nos ennuis se sont évaporés, mais c'était il y a quelques années, peut être que MongoDB s'est sortis les phalanges du fondement depuis.

J'aurais largement préféré qu'on me fasse des retours sur les problèmes rencontrés sur des architectures que je n'ai pas pu tester ou sur les paramètres particuliers d'Apache à surveiller, plutôt qu'entamer un débat sur "Faut-il coder avec moins de 3 indentations ?"

Pour le coup, je trouve que ce thread va un peu loin, je suis sincèrement désolé de l'avoir lancé.

Je suis d'accord avec toi, ces considérations sur le style, ce n'est finalement pas le sujet, fonctionnellement ton outil est intéressant, je n'en ai personnellement pas l'usage (je n'utilise plus apache depuis longtemps). J'espère que d'autres moules vont au moins l'essayer !

Oui, moi aussi, ou a minima je demande une justification et que le code soit explicitement documenté pour expliquer pourquoi.

Bien que je ne sois pas d'accord sur le fond, je t’ai pertinenté parce que j'estime que ton point de vue est tout à fait légitime, je ne pense pas que ça vaille d'être moinssé.

De manière générale, on essaye au boulot de ne pas faire plus de 2 ou 3 niveau max d'indentation, et dès lors qu'un algo déroulé est plus grand que l'écran (alors c'est subjectif parce qu'on est nombreux à avoir des écrans/résolutions/polices de taille différentes) on découpe.

Avoir une fonction qui n'est appelée qu'une unique fois n'est pas un soucis, si ce qu'elle fait est particulièrement technique ou dévie un du peu métier (tout en restant nécessaire), ça permet juste de sortir quelques lignes inutiles à la compréhension de son algo d'origine, afin de fluidifier la lisibilité de ce qui est vraiment "métier".

L'idée ce n'est pas de voir la fonction comme quelque chose de technique, par essence ce n'est pas dédié que à la factorisation, mais juste de séparer un gros problème en un ensemble de plus petits problèmes, parfois décorrélés, parfois non, afin de mettre en valeur, donner une sémantique métier, au code. Par exemple si quelqu'un dit "oui mais un appel de fonction c'est plus lent", il faut bannir cette personne de toute décision architecturale, car même si c'est possiblement vrai, ça ne sera jamais significatif dans un ensemble de code plus gros.

Le découpage unitaire permet aussi le test unitaire, et ça, c'est vraiment cool. Plus les responsabilités sont découpés, plus il aisé d'écrire des tests, aux limites ou non. Mais c'est aussi plus facile de remplacer un bout de code, il suffit de respecter la signature.

Ça permet aussi d'éviter que des variables temporaires se trimballent trop longtemps dans le flux d'exécution, ou dans le flux de code, et permet d'éviter des erreurs bêtes (écrasement de variable, erreur de typo qui fait que tu utilises une variable à la place d'une autre).

Je terminerais avec deux points, qui me semblent importants, dans les deux paragraphes en dessous.

Le premier, c'est que regarder les scripts des autres (qui plus est en perl), n'est pas un bon indicateur pour comparer la qualité du code. Le choix du langage, tout comme la finalité du code, ou tout simplement les conventions choisies vont influer sur le style adopté. De plus, les scripts perl (ou tout autre langage d'ailleurs) de configuration ou de monitoring sont très souvent écrits par des gens dont le métier est l'administration ou la maintenance de parc, et malheureusement, ce n'est absolument pas le même métier que développeur (d'application métier ou tout autre) et de gestion de projet; bien souvent les scripts d'admin sont de piètre qualité. Je ne remets pas en cause leur compétence ici, attention, mais juste développer n'est pas leur métier (je suis résolument contre le discours qu'il faille absolument être un "devops", ce sont deux métier différent, qui demandent des compétences tout à fait différentes).

Le deuxième point, et c'est le dernier, c'est que peu importe l'âge, on est toujours capable d'avancer et d'évoluer, c'est plus un choix qu'une contrainte en réalité. Si tu décides d'être conservateur quant à ton style de code, je ne vais pas aller te critiquer, c'est un choix personnel et légitime, et l'important, encore une fois, c'est que tu te fasses plaisir. Par contre, si tu étais développeur dans mon équipe, je serais sûrement derrière ton dos pour t'aider à avancer, et surtout à comprendre, ces "nouvelles" (qui ne sont pas nouvelles du tout en réalité) méthodes de développement, non pas pour forcer le changement, mais tout simplement pour améliorer la communication entre développeur, en espérant qu'à la fin, tout le monde y prenne du plaisir.

Je ne parlais pas forcément de passer en objet, pour un script comme celui-ci ça ne semble pas indispensable (ce qu'apporte réellement l'objet qui est indispensable pour des gros projets c'est essentiellement l'encapsulation, les interfaces et la composition, afin de rendre le code évolutif, ce qui ici ne serait pas forcément bénéfique), mais plus de plus découper en fonctions. À certains endroits ton code arrive à des niveau de 5 ou 6 indentations successives (entre divers if, while et foreach), ce qui rend le code très profond, et plus difficile à lire. Le cerveau humain est assez bête il aime lire de façon linéaire, et le découpage en fonctions aux endroits opportuns créé une encapsulation qui permet aux algorithmes importants d'évoluer à niveau plus haut ce qui leur donne plus de sémantique et moins de détails techniques, et d'être plus lisibles, car ça les rend plus linéaires.

Les imbrications de if foreach while et autres joyeusetés créé un code avec énormément de branches, c'est souvent là qu'on perd le lecteur. En arrivant à remplacer les branches par du typage et une gestion d'erreur fine dans des fonctions encapsulés, ça permet de mettre en valeur les erreurs évidentes.

Bonjour, le PHP (entre autres) étant mon métier de tous les jours, je me permet de faire quelques remarques sur le code:

• ce script semble être développé "à l'ancienne", un fichier de 1500 lignes avec très peu de fonctions, et quasi-intégralement procédural, c'est un peu lourd à digérer,

• je vois beaucoup de display("[..] Foo bar... ça aurait peut être été judicieux de factoriser le code pour générer le [..],

• tu itères bien souvent avec readdir(), je ne suis pas vraiment sûr que ce soit nécessaire, tu pourrais déduire les noms de fichiers que tu cherches dans la majeure partie des cas et simplement faire un $filename = sprintf('/proc/%d/status', $pid); if (file_exists($filename)) { $status = file_get_contents($filename); /* ... */ },

• tu fais du shell_exec() sans utiliser escapeshellcmd() ni escapeshellarg(), alors le plus souvent c'est un string literal donc c'est pas grave, mais à garder dans un coin de la tête pour plus tard,

• de manière générale le code est très redondant, il pourrait être factorisé,

• tu dis que tu ne trouves pas les regex lisibles, et je suis bien souvent d'accord avec toi, mais je dirais surtout: ça dépend, et dans ton cas en utilisant des regex par endroit, tu aurais du code plus concis (et plutôt lisible je pense, car les regex dont tu aurais besoin serait relativement simples).

Bon sinon l'outil semble fonctionnellement très bien, par contre je trouve ça dangereux de hardcoder les limites acceptables en ce qui concerne, par exemple, le nombre de threads: en effet, un nombre de process/thread sera bien souvent affiné selon le type d'application (I/O-bound ou CPU-bound), selon le nombre de CPU dédiés sur la machine, selon la RAM disponible, etc… Donc j'ai peur que toutes les valeurs soient de facto fausses pour beaucoup d'environnements.

Mais, petite note positive, c'est cool de reprendre ce genre de petit projet, je suis sûr que ça peut servir à beaucoup de monde. Apache est trop souvent bien trop mal configuré, alors c'est une bonne chose, ça permet de sensibiliser les gens à la configuration.

Et puis quant bien même je fais des critiques (que j'espère être constructives) l'important c'est que tu te fasses plaisir à développer cet outil.