Journal Le sophisme du meilleur outil

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
43
12
nov.
2023

Aujourd'hui, un journal qui dénonce grave (ça faisait longtemps, tiens).

Je tiens à m'élever, que dis-je, à m'insurger, contre ces ayatollahs qui se drapent dans leurs chevaux et montent sur leurs grands principes pour forcer sur nous autres tout un tas de technos à la mode, peut-être de bonne foi, ou peut-être afin d’étoffer leur CV quand sera venu pour eux le temps de déployer leurs ailes pour semer le chaos dans d’autres équipes avec le sentiment du devoir accompli, et nous laissent avec moult scories fumantes impossibles à extirper, parce qu’elles sont, objectivement et sans aucun contexte, le meilleur outil (oui, je me suis mis à Proust récemment, ça se voit tant que ça ?).

Parce que oui, avoir un script en Perl tout seul dans son coin et qui sort de nulle part pour extraire un rapport depuis logs de tests unitaires (parce que Perl, c'est le meilleur outil pour bidouiller du texte, voyons !), décider d'utiliser KDB (vade retro !) parce que tu vois, faut faire des requêtes hyper rapides, y'a au moins 10 000 lignes, SQL il sait pas faire, hein, ou encore coller du Java (parce qu'on veut gérer des flux de données, et les flux c'est Flink), du Python (parce que c’est le meilleur outil pour faire des services web), du C++ (parce que la bibliothèque tierce à intégrer est en C++), du C# (parce que de la GUI), du SQL et du noSQL et leurs divers cadriciels afférents dans un bête petit service maintenu par une équipe de 3 personnes, c’est peut-être (je dis bien peut-être) bon pour la productivité immédiate, mais à moyen ou à long terme, c’est la bataille permanente pour modifier un simple truc.

Tenez, encore un exemple : nous avions besoin de construire une petite interface Windows pour un service en C++ tournant sous Unix (accès et modification de données), usage interne, rien de méchant. Ah mais attention, le meilleur outil pour faire des interfaces sous Windows, c’est C#. Alors bonjour, voici un dev C# qui va faire le boulot, faites lui une petite API en managed C++, on galère un peu mais on finit par y arriver. Et puis, mauvais résultats financiers, dégraissage, le type est viré, et on reste avec une GUI que personne ne sait maintenir, et qu’on voit pourrir sous nos yeux au fur et à mesure que l’on change le service. Il en a fallu, des efforts, pour convaincre le management d'utiliser Wt, un cadriciel Web en C++ inspiré de QT, et qui nous a permis de tout intégrer. Alors oui, faut un peu se battre avec, c’est pas hyper joli, et c’est pas hyper mode, mais ça fait le boulot, et les devs C++ backend, comme on dit, arrivent à être autonomes et à garder l'interface alignée. Si je démarrais de zéro, je n’utiliserais certes pas Wt pour faire un site web, mais étant donné la taille et les connaissances de l’équipe, le timing, les priorités, et les contraintes matérielles, c'était une bonne solution, et ça a marché si bien qu'on a oublié à quel point c'était pénible avant.

Il y a un curseur entre cohérence et fonctionnalités, et j'ai tendance à le diriger fermement vers la cohérence. Tant pis s'il me faut écrire un peu plus de code, tant pis si je passe un peu plus de temps à intégrer une nouvelle fonctionnalité : si elle s'intègre de manière cohérente au projet, en utilisant le même langage, les mêmes conventions, les mêmes dépendances, alors elle s'intègrera au CI, aux tests unitaires, au format de logs, elle pourra être maintenue par l'équipe.

Voilà, c'est tout pour moi, je retourne remplacer les 1 liners en python dans des scripts bash par des des 1 liners en bash.

  • # tête de clou

    Posté par  (site web personnel) . Évalué à 10.

    Devient Rust evangelist et ta vie sera plus simple: le meilleur outil sera toujours rouillé.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

  • # Ouais

    Posté par  (site web personnel) . Évalué à 10.

    Comme toujours, le problème c'est le bus factor, 1 gus pour 1 composant sur 1 techno que les 10 autres ne connaissent pas = c'est la merde !

    • [^] # Re: Ouais

      Posté par  . Évalué à 6.

      Et aussi la difficulté croissante à trouver des programmeurs et des programmeuses polyglottes qui savent un minimum chacune des technos employées.

      • [^] # Re: Ouais

        Posté par  . Évalué à 4.

        Mais non voyons, un.e dev full stack full DSI à lui tout seul.e

      • [^] # Re: Ouais

        Posté par  . Évalué à 10.

        Tu prends un monoglotte de bangalore avec un copilote en chatGPT.

      • [^] # Re: Ouais

        Posté par  (site web personnel) . Évalué à 6.

        Moui, m'enfin, le nombre de techno à connaitre en 2023, n'a rien à avoir avec le nombre de techno qui existait en 2010.

        "La première sécurité est la liberté"

        • [^] # Re: Ouais

          Posté par  (Mastodon) . Évalué à 5.

          C'est ce qui me fait "peur" : je vois de plus en plus de gens qui survolent les technos et de moins en moins qui maitrisent des technos [emploi de "je" car il n'y aucun idée de généraliser ou de faire croire à une généralité / distinguo volontaire d'usage entre "les" et puis "des"]

          Ceci mène à des situations totalement ubuesques, où des survols de technos suffisent à faire des choix. Si ceci est parfois possible, c'est rare et encore plus rares sont ceux sachant le faire et dire quant ce n'est pas faisable.

          Le vernis de connaissances tends à remplacer la connaissance.

          • [^] # Re: Ouais

            Posté par  (site web personnel) . Évalué à 7.

            On a pas le temps non plus de faire 3 PoCs pour comparer.

            La facilité d'une techno va devenir un critère principal.

            "La première sécurité est la liberté"

          • [^] # Re: Ouais

            Posté par  . Évalué à 6.

            Ceci mène à des situations totalement ubuesques, où des survols de technos suffisent à faire des choix.

            Personnellement je me demande ce qui est pire : survoler une techno pour faire des choix ou s'enfermer dans les technos que l'on connaît et faire le choix de l'immobilisme ?

            Je caricature un peu, mais la question parfois est là. Et en France je pense que l'un des problèmes est le rapport que l'on a à l' "échec": quand on fait un choix, c'est souvent mal vu d'admettre que l'on s'est trompé. J'ai vu des projets ou les choix initiaux étaient mauvais (mais pris en toute bonne foi ), mais sur lesquels personne n'a voulu revenir parce que ça aurait été mal vu. Et plus les projets prennent de l'ampleur, plus le changement de direction est compliqué à faire. L'agilité est censée pouvoir se rendre compte pus vite de ce genre de problème, et elle le permet, mais je remarque que bien souvent on a tendance à mettre la poussière sous le tapis plutôt que de prendre des mesures pour corriger les problèmes.

  • # tout est question d'équilibrre et de besoin.

    Posté par  . Évalué à 6.

    je suis assez d'accord avec ça mais jusqu'à une certaine limite :

    Il y a un curseur entre cohérence et fonctionnalités, et j'ai tendance à le diriger fermement vers la cohérence. Tant pis s'il me faut écrire un peu plus de code, tant pis si je passe un peu plus de temps à intégrer une nouvelle fonctionnalité : si elle s'intègre de manière cohérente au projet, en utilisant le même langage, les mêmes conventions, les mêmes dépendances, alors elle s'intègrera au CI, aux tests unitaires, au format de logs, elle pourra être maintenue par l'équipe.

    Le promblème, lorsque ce raisonnement est poussé, c'est qu'on en arrive à utiliser des outils mal adaptés au besoin, qui deviennenet difficilement maintenables, ou qui t'enferment dans un carcan. Et sans tomber dans l'effet de mode, il est parfois utile de remettre en question les choix qui ont été faits à un instant T pour se tourner vers un outil mieux adapté (mais en évitant de choisir une techno pas assez mature qui risque de tomber en dessuétude des mois plus tard).

    • [^] # Re: tout est question d'équilibrre et de besoin.

      Posté par  . Évalué à 4. Dernière modification le 13 novembre 2023 à 00:51.

      Je confirme, d'expérience personnelle : j'avais rejoint un projet visant à développer un logiciel métier avec un gros potentiel d'abstraction, le logiciel visant à optimiser des flux logistiques. Tout était codé en C89, pour des raisons pas forcément mauvaises :

      • L'IDE que les devs devaient utiliser ne gérait pas les versions ultérieures de C,
      • Toute l'équipe savait coder en C,
      • Des devs C, c'est facile à trouver, on peut donc mettre l'accent sur d'autres compétences au recrutement
      • Le C, c'est performant,
      • Changer de langage, c'est un coût et une prise de risque,
      • Le chef de projet, qui avait créé le projet il y a bien longtemps et ne s'occupait plus du code, ne maîtrisait pas d'autres langages potentiels.

      Mais les inconvénients étaient aussi bien sensibles :

      • Un temps de développement bien plus important,
      • Davantage de bugs,
      • Une dette technique croissante,
      • Le sentiment permanent et frustrant de ne pas utiliser le bon outil.

      Comme d'autre choses, il faut garder l'outil qu'on maîtrise quand on peut, et le changer quand on le doit.

      • [^] # Re: tout est question d'équilibrre et de besoin.

        Posté par  (Mastodon) . Évalué à 10.

        L'IDE que les devs devaient utiliser ne gérait pas les versions ultérieures de C,

        Qui a eu l'idée idiote d'imposer un IDE aux devs?

        • [^] # Re: tout est question d'équilibrre et de besoin.

          Posté par  . Évalué à 3.

          Le même type de personnes qui veulent imposer une seule interface graphique à un OS par exemple. Peut-être que l'idée de base serait par exemple une configuration et des plugins qui permettraient une certaine cohérence dans le format d'écriture de code, et une bonne intégration aux outils de build, test, ou autre, mais pour moi ce n'est pas prendre le problème du bon sens.

    • [^] # Re: tout est question d'équilibrre et de besoin.

      Posté par  . Évalué à 4.

      en évitant de choisir une techno pas assez mature qui risque de tomber en désuétude des mois plus tard

      C'est pourtant la règle sur le Web. Resume Driven Development

  • # De la pertinence du KISS et d l’anticipation des besoins futurs

    Posté par  . Évalué à 10.

    Je ne suis pas développeur mais devops.

    Le choix d’une solution « tournée vers le futur et prenant en compte des besoins non encore exprimés mais qui à coup sûr ne manqueront pas de survenir, tout en minimisant le risque de créer de la dette technique » plutôt qu’une solution « ad-hoc, minimale et sans la moindre de nouveauté par rapport aux solutions déjà mises en œuvre par ailleurs » me laisse toujours songeur quant aux attentes de ses promoteurs.

    Pour prendre un exemple (à peine fictif) que je trouve représentatif : un besoin qui pourrait être adressé à l’aide d’un simple script shell/Perl qui fait deux requêtes SQL et trois appels API, va sembler à certains être une bonne occasion de mettre en œuvre un flux de messages (parce qu’ajouter un SPOF est toujours bon è prendre ?), choisir d’implémenter cela en Go (parce qu’en 202X le shell/Perl est obsolète ?) quand bien même il sait parfaitement que bien que le Go puisse être plus facile à maintenir que le shell dans l’absolue, il n’est dans le contexte maîtrisé que par deux personnes dont une part à la retraite dans un an. Sans oublier de mettre en place une chaîne de CI exprès pour ce « projet », en prétextant qu’elle pourra servir pour les futurs outils qu’enfin grâce à lui auront un pied dans l’avenir au lieu de reposer sur des technologies « obsolètes » puisque dépréciées par Google ou Amazon il y a déjà six long mois ! Le fait que telle ou telle brique logiciel n’existe qu’en version 0.X et ait deux chances sur trois d’être abandonnée au profit du nouvel outil « qui fait l’unanimité chez les spécialistes et rend caduc l’intégralité des méthodes mises en œuvre ces cinquante dernières années » n’est pas une source de questionnement mais au contraire le signe indiscutable de la pertinence de leur choix. sans oublier pour finir de déployer ça sur une une plateforme Kubernetes, pas qu’un besoin identifié l’exige, mais parce, mais parce qu’ « Aujourd’hui Kubernetes rend toutes les solutions actuelles obsolètes.

    Je peux admettre que je suis probablement touché par un excès inverse, et que je suis amené de ce fait à négliger des solutions réellement avantageuses pour tous à moyen terme. Mais je constate régulièrement que les promoteurs des solutions que j’évoque semblent considérer que la « modernité » elle-même est un argument indiscutable qui valide leur choix en rendant tous les autres choix caducs par principe.

    Jeune j’étais persuadé que les « vieux cons » pouvaient parfois avoir raison, maintenant que j’ai ce rôle je suis au moins heureux de découvrir que j’aurais eût tort de penser autrement à l’époque.

    • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

      Posté par  (Mastodon) . Évalué à 10.

      Pour aller un peu dans ton sens (moi je suis dev), je me méfie des usines à gaz conçues pour la réutilisabilité : on crée bcp de couches et d'indirections, comme ça "si on change de matériel il n'y a plus qu'à changer la HAL et tout marche". Bon, et quand on change de matériel on en profite pour finalement tout réécrire de zéro parce que l'usine à gaz devenait insupportable :)

      Alors certes il faut savoir anticiper l'avenir un minimum et concevoir dès le début un logiciel qui sera capable d'évoluer, mais comme personne n'a de boule de cristal, restons modestes dans les projections futures.

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

        Posté par  . Évalué à 4. Dernière modification le 13 novembre 2023 à 13:44.

        Ton commentaire et mon expérience récente avec un logiciel en PHP m’incite à te poser la question suivante : Dans le cas où tu connais bien-sûr, même de réputation seulement, as-tu un avis sur le framework PHP nommé Symfony ?

    • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

      Posté par  (Mastodon) . Évalué à 4. Dernière modification le 13 novembre 2023 à 13:07.

      Chez nous comme chez beaucoup d'entreprises, on a ce techradar/technology lighthouse. Une sorte de diagramme qui est censé éviter les dettes techniques en te disant qu'elle techno est en:

      • PENDING: en cours d'évaluation peux être testé/utilisé sur des poc/petits projets
      • BUY: une techno de choix pour un nouveau projet
      • HOLD: on tolère de continuer à utiliser ces technos mais on ne peut pas les choisir pour de nouveaux projets
      • SELL: on doit préparer la migration vers une techno qui est en BUY

      Ça s'applique tant aux langages de programmations, que frameworks, DB, outils de développement ou business.

      Dans les fait il y a moultes langages de programmations et frameworks qui terminent en HOLD ou SELL et qui sont toujours maintenus et probablement bien plus pérennes que certains frameworks ou outils qui sont en BUY actuellement. Perl en est un bon exemple.

      Bon après je ne suis pas sûr qu'il y ait beaucoup de monde à consulter ces listes et elles ont du mal à être maintenues réellement.

      • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

        Posté par  (Mastodon) . Évalué à 5.

        Intéressant et/mais incomplet alors j'essaie de compléter un peu :

        En rebondissant sur la nécessité d'avoir une matrice complémentaire qui tient compte du contexte d'usage, de la cible d'usage : en la classifiant selon la vie de l'outil. De type "SHORT : pour POC et études de faisabilité et courte durée de vie" / "MIDDLE : pour une cible de cycle de vie de 3 à 7 ans" / "LONG : pour une nécessité de maintenance de vie au delà de 7 ans."

        En croisant ainsi avec le premier tableau, on va sortir un premier choix par élection éliminatoire. Exemple : Rocky Linux (je prends un exemple de ma partie, pas un langage ou une techno) est en BUY, et l'incertitude sur son devenir entre OpenELA et lui par l'analyse des contributeurs communs et du transport de l'effort de l'un à l'autre, place Rocky Linux en SHORT, ce n'est pas une certitude mais une assurance. BUY+SHORT, on a un cadre d'usages max et on élimine "rocky" de tout futur projet dont la durée de vie et/ou de maintenance doit dépasser les 3 ans.

        Cela se ressent d'ailleurs avec le "peux être testé/utilisé sur des poc/petits projets" qui n'est présent que dans le PENDING, et ceci mène à un étonnement que le contexte soit absent des autres.

        enfin on peut compléter par un troisième tableau, à croise : celui des RH, qui tient compte de la disponibilité actuelle de maitrise de la techno, de l'effort d'intégration de la maitrise de la techno, de l'intérêt d'entreprise à moyen terme de cette intégration et de l'intérêt pour la ressource RH et son évolution sur la techno. Mais c'est un autre sujet.

    • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

      Posté par  . Évalué à 3.

      Je suis pas forcément en désaccord avec toi sur le sentiment, mais y’a 2 points qui me font tiquer.

      parce qu’en 202X le shell/Perl est obsolète ?

      Honnêtement? Oui. C’est dur à lire, dur à maintenir, super casse gueule, et les compétences court pas foule. Quand on a Ruby et python aussi largement déployé, qui viennent avec un eco système aussi gros, y’a vraiment aucune excuse pour faire du Shell. Perl est « moins pire », grâce à son eco système, mais ça reste un langage super aride et casse gueule.

      evidement, y’a toujours des exceptions. Pour citer un exemple, booking.com notamment à beaucoup (trop) de Perl dans son backend, mais c’est plus de la dette technique qu’autre chose à ce niveau si t’en parles avec eux.

      Sans oublier de mettre en place une chaîne de CI exprès pour ce « projet »

      Eh. On est plus en 97. La CI, c’est la base de la base. Et ça fait bien 10 ans que les outils sont suffisamment avancés pour faire du self service à coup plus que raisonnable.

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

      • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

        Posté par  . Évalué à 5.

        C’est dur à lire, dur à maintenir, super casse gueule, et les compétences court pas foule.

        Que ce soit plus dur à lire et plus casse gueule que Python je peux l’admettre sans problème, mais pour ce qui est des compétences… Dans la structure dans laquelle je bosse il y a nettement plus de gens qui ont des rudiments de shell (Bash/KSH) que de gens qui connaissent Python.Je suis ptetre dans une structure exceptionnelle(ment retardée), chacun jugera.

        qui viennent avec un eco système aussi gros

        Alors cet argument il me fera toujours autant marrer… Le shell, par exemple Bash, vient avec un « éco système » qui n’a rien à envier à celui de Perl ou celui de Python : il est composé de binaires tels que "curl", "bc", etc…. Et note bien que cet « éco-système », mais tu veux peut-être dire « environnement » (?) est déjà disponible par défaut sur tout système Unix-like, pas besoin d’aborder des installations additionnelles qui viennent avec leur lot de subtilités telles que "Virtualenv", "CPAN", ou autre joyeuseté de ce type. Donc celui qui a le plus gros c’est sans conteste le shell !

        J’irai pas coder une suite bureautique WYSIWYG ou un simulateur de vol en Bash on est d’accord, maintenant, pour la plupart des besoins de devops, voire tout ce qui est informatique de gestion, c’est souvent le meilleur choix.

        Ceci dit, je kiffe Python, j’en ai écrit pas mal, j’aime bien. Mais quand je vois des outils écrits en Python il y a quelques années qui nécessitent cinq ou six libs Python à des versions bien précises pour fonctionner (bonjour la procédure de déploiement du bignou…), et que je compare à un script shell qu’on peut juste copier d’une RHEL 7 à une RHEL 8 (c’est un exemple) et roule ma poule, sans te prendre plus la tête, bah perso les pièges du shell (et ils sont vicieux !) je me les coltine sans trop de remord.

        La CI, c’est la base de la base.

        Ah ah ha… si tu as la chance de bosser dans une structure qui applique sans exceptions les principes de la CI, du gitops, etc, systématiquement, bah tant mieux pour toi…

        Les shells « POSIXoïde » oserais-je dire, sont aussi obsolètes de nos jours que le langage C pourrait l’être dans le domaine des langages compilés, soit : absolument pas. Même si d’autres langages les surpassent sur certains points, pour certaines applications.

        • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

          Posté par  . Évalué à 3.

          Le shell, par exemple Bash, vient avec un « éco système » qui n’a rien à envier à celui de Perl ou celui de Python : il est composé de binaires tels que "curl", "bc", etc….

          Je vais pas parler de python que je ne connais pas. Mais je peux parler de Ruby, que je connais essentiellement en remplacement de bash/rakefile.

          Ton argument ne fait aucun sens. Lancer une ligne de commande en Ruby c’est une ligne (backtick ou system, en fonction d’où tu veux faire aller le stdout), avec la grosse, grosse, grosse différence va te permettre d’éviter les conneries du bash. Du genre « oups, y’avait un espace dans le path et paf la commande rm », pour citer la plus connue. Tu parles de curl, une requête http c’est aussi une ligne en Ruby, et pas besoin de jq à la truelle pour ressortir le champ que tu veux. Et t’auras ton champ typé correctement. En gros, l’approche de base c’est d’écrire du code natif Ruby, et si quelque chose devient relou, tu peux toujours ressortir ta ligne de commande sur le point précis qui est relou. Mais au moins, t’aurais acces à des trucs « moderne », genre des tableaux, des maps, et même des nombres. Perso, je m’en sert pour scripter les builds en ligne de commande Xcode, ce qui au final inclue un peu plus que juste lancer xcodebuild.

          Tout ça pour dire, l’écosystème bash est pour ainsi dire inexistant (et honnêtement, c’est pas pour rien). Ruby te donneras la même chose avec un typage qui date pas de 1974, et une base solide de base dans l’interpreteur (sans gem externes).

          Ah ah ha… si tu as la chance de bosser dans une structure qui applique sans exceptions les principes de la CI, du gitops, etc, systématiquement, bah tant mieux pour toi

          Je suis pas sur de comprendre ou tu veux en venir. Une instance Jenkins, c’est grosso modo une heure à mettre en place, avec discovery des pull requests, ping back à GitHub etc. Et demander de ne pas builder/packager/déployer depuis le laptop de jean rené, c’est pas le bout du monde quand même?

          Linuxfr, le portail francais du logiciel libre et du neo nazisme.

          • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

            Posté par  . Évalué à 2.

            Ton argument ne fait aucun sens. Lancer une ligne de commande en Ruby c’est une ligne (backtick ou system, en fonction d’où tu veux faire aller le stdout), avec la grosse, grosse, grosse différence va te permettre d’éviter les conneries du bash. Du genre « oups, y’avait un espace dans le path et paf la commande rm », pour citer la plus connue.

            mkdir '/tmpt/ toto'
touch '/tmpt/ toto/success'
irb
> a = "/tmpt/ toto"
> `ls #{a}`

            Qu'est-ce qui va s'afficher d'après toi ?

            Une partie non négligeable des défauts imputés au shell se retrouve ailleurs.

            https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

              Posté par  . Évalué à 2.

              Si on ne fait que du Ruby:

              $ irb
> a = '/tmp/ toto'
> Dir.mkdir(a)
> File.write("#{a}/success", '')
> Dir.children(a)
["success"]

              Sinon, on peut utiliser aussi la bibliothèque Shellwords qui fait partie de la lib standard:

              $ mkdir '/tmp/ toto'
$ touch '/tmp/ toto/success'
$ irb
> require 'shellwords'
> a = '/tmp/ toto'
> `ls #{Shellwords.escape(a)}`
"success\n"

              Il existe certainement d'autres façons de faire en Ruby encore meilleure que celles proposées ici

              • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                Posté par  . Évalué à 2.

                La question n'est pas de savoir s'il est possible d'écrire du code sans bug, mais que reprocher au shell un piège en présentant comme alternative une API qui a le même problème est une erreur.

                D'ailleurs je n'ai pas l'impression que cette bibliothèque soit d'une grande utilité pour gérer les fichiers dont les noms ressemblent à des options. Un fichier nommé -f par exemple.

                https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                  Posté par  . Évalué à 2.

                  Oui, c'est sur que rm -rf / toto avec des backticks, ca va pas donner le résultat escompté, vu que c'est un passthrough direct sur le shell. Ruby ne va pas magiquement échapper les paths. Ce qui était précisément le point de mon message: a un cout presque nul, tu peux éviter les plus gros pièges du shell. Au pire, tu te retrouves avec les meme problèmes que le shell, tout en ayant probablement une solution qui te prendrait 20 minutes a trouver.

                  D'ou l'intérêt d'utiliser les packages natifs, genre FileUtils. Les methods sont meme nommées apres les commande de base.

                  Ce bout de code fait exactement ce que tu veux qu'il fasse (plutot que d'effacer tout /tmp)

                  require 'fileutils'

FileUtils.mkdir_p("/tmp/ toto")
FileUtils.rm_rf("/tmp/ toto")

                  Idem avec ton -f: 

                  require 'fileutils'

FileUtils.chdir("/tmp")
FileUtils.touch("-f")

# plus loin dans un shell:
ll /tmp/
-rw-r--r--   1 groumly  wheel     0B 20 nov 11:45 -f

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                  • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                    Posté par  . Évalué à 3.

                    Ce qui était précisément le point de mon message:

                    Je lis précisément l'inverse dans ton message. Tu avais l'air de présenter les backticks comme une alternative meilleure que le shell.

                    De mon expérience, ce qui crée ce genre de bug ce n'est pas la difficulté à les éviter, mais le fait d'y penser et même certaines solutions qui ne sont pas des pass-through sont sensibles à certains problèmes (par exemple utiliser exec ne protège pas des fichiers qui ressemblent à des options).

                    Je sais très bien que ruby a des tonnes de façons de faire, mais il faut bien faire attention et ne pas se sentir immunisé si on ne l'est pas (comme avec le commentaire précédent).

                    Croire que ces problèmes sont des problèmes de shell et qu'utiliser un autre langage protège de facto contre ça est une erreur.

                    Je dis ça j'utilise pas mal et par plaisir bash, zsh, python et perl (je suis pas un grand fan de ruby j'y vois pas un intérêt fou par rapport aux 2 précédents).

                    https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

            Posté par  . Évalué à 3. Dernière modification le 21 novembre 2023 à 23:22.

            Je suis pas sur de comprendre ou tu veux en venir. Une instance Jenkins, c’est grosso modo une heure à mettre en place, avec discovery des pull requests, ping back à GitHub etc. Et demander de ne pas builder/packager/déployer depuis le laptop de jean rené, c’est pas le bout du monde quand même?

            De mon expérience, très limitée donc peut-être pas représentative, dans une petite ou moyenne entreprise avec un service informatique réduit, tu peux réussir à imposer des choses.

            Dans une structure avec environ 250 employé⋅es pour le seul service informatique à lui tout seul, dont l’informatique n’est pas le métier premier, et qui est le fruit de multiples fusions successives depuis plus de vingt ans, oui, tu peux demander une VM et y coller un Jenkins, le configurer dans les règles de l’art. Au final il y a une possibilité que tout ton service (et si tu es technique, TON service, c’est pas 50 gus, plutôt une dizaine grand max…) adhère au concept, mais bien plus de chance que tu finisses à être seul à l’utiliser.

            Nous avons des développeurs, nous avons une CI, Jenkins en fait d’ailleurs partie, mais je pense que tu n’as pas conscience de ce que ça représente comme architecture logicielle et procédures associées. Je ne peux malheureusement pas t’en dire davantage, ce ne serait pas professionnel de ma part, mais franchement tant mieux ! ^^

            et pas besoin de jq à la truelle

            Pourquoi « à la truelle » ? Ce sera probablement plus long à écrire, moins facile à lire mais c’est loin d‘être un inconvénient franchement insurmontable.

            genre des tableaux, des maps, et même des nombres.

            Des tableaux (liste ou hash) tu as ça aussi en bash, tu as des nameref, des pipes nommés, des descripteurs de fichier, la programmation multi-thread est native (&, wait), tout comme l’usage de signaux (kill, trap)… Je t’accorde que c’est un paradigme assez particulier, et clairement pas des plus intuitif, mais ça ne fait vraiment pas de bash un outil obsolète pour autant. Je pourrais te citer encore d’autres avantages mais il se fait tard.

            Et pour les inconvénients, le dernier piège dans lequel je suis tombé (et dans lequel on ne tombe qu’une fois…) et qui m’a fait perdre pas mal de temps, c’était il y a déjà un moment, et ça concerne les fonctionnalités natives pour l’arithmétique de bash, qui sont je te l’accorde une source de critiques justifiées : le fait que de manière absolument contre intuitive, un nombre entier commençant par un 0 est interprété comme étant de l’octal. Dans mon cas je me retrouvait donc avec un bug survenant seulement pendant 2 semaines sur les 52 que compte une année… l’exemple typique du bug qui peut faire exploser en vol un traitement au terme de plusieurs mois d’exécution sans faute, et qui peut facilement être source d’une hécatombe capillaire certaine si on ne l’a jamais rencontré auparavant. Depuis je considère volontiers qu’utiliser bc (ou dc) systématiquement et réserver le recours à l’arithmétique native lors d’une éventuelle phase d’optimisation du code est une sage décision. Cela permet en outre de disposer d’une précision arbitraire automatiquement sans avoir à prévoir l’utilisation d’un type différent d’entier.

            • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

              Posté par  . Évalué à 3. Dernière modification le 23 novembre 2023 à 05:38.

              Pourquoi « à la truelle » ?

              Genre si t’as besoin de récupérer 2 champs de ton json, ça commence à devenir plutôt compliqué. Ou extraire un tableau. Ou si un champs est null. Fin ça devient super limité dès que tu sort de la base de la base du chemin content.

              Des tableaux (liste ou hash) tu as ça aussi en bash

              multidimensionnels, les arrays? Ou c’est juste un bon gros hack de chez mémé, avec une syntaxe absolument imbitable? Et t’as des sets aussi? Qu’est ce qu’il se passe si tu traites un tableau comme une map, il se passe des choses bizarres parce que le language ne connaît qu’un seul type, les chaînes, et que donc array[1] est la même chose que array["1"] bien que ça ne veuille pas du tout dire la même chose?

              la programmation multi-thread est native (&, wait), tout comme l’usage de signaux (kill, trap)

              oui, bon a ce compte la, l’assembleur aussi est multi thread.

              Linuxfr, le portail francais du logiciel libre et du neo nazisme.

              • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                Posté par  . Évalué à 4. Dernière modification le 23 novembre 2023 à 16:12.

                Genre si t’as besoin de récupérer 2 champs de ton json, ça commence à devenir plutôt compliqué.

                Sur ce point je te dirais qu’un outil qui produit du JSON (tel que par exemple un kubectl ou n’importe quelle API REST) mais qui ne dispose pas du nécessaire pour fournir un JSON simple avec seulement les informations pertinentes dont tu as besoin, c’est un outil mal foutu. Le problème est en amont là.

                Et pour quand tu n’as pas le choix tu peux trouver le bon outil, exemple https://github.com/TomNomNom/gron. Alors, oui, c’est du Go, pas de Bash, mais c’est bien là toute la force de Bash, être une sorte de « glue language » qui excelle précisément à faire travailler ensemble les outils les plus adaptés aux tâches données.

                Et je rappelle tout de même que jq peut avoir une syntaxe compliquée, il n’y a aucun besoin en traitement du JSON qui lui soit inatteignable.

                multidimensionnels, les arrays? Ou c’est juste un bon gros hack de chez mémé, avec une syntaxe absolument imbitable?

                Tu as des array indexés (ce que Python appelle très pertinemment des « list »), ainsi que des arrays associatifs (« dict » en Python). À partir de là si tu as besoin d’objets plus complexe, et bah tu fais avec ces types de base. Est-ce qu’on reproche au C ces types natifs limités ? Ou a Perl de ne pouvoir avoir des arrays de pointeurs ? Même en Python les types d’objets « complexes » sont basés sur les trois types de base : scalaire, list et dict (sachant que tout scalaire peut être considéré comme une liste selon le besoin.

                et que donc array[1] est la même chose que array["1"] bien que ça ne veuille pas du tout dire la même chose

                Bash n’est pas une exception sur ce point. C’est le principe du typage dynamique/faible : le type dépend du contexte. Perl, Python et d’autres fonctionnent pareil. Un scalaire "chaîne de caractères" n’est pas conceptuellement différent d’une liste de caractères.

                une syntaxe absolument imbitable

                T’as déjà eu affaire à du PowerShell ? :)

                oui, bon a ce compte la, l’assembleur aussi est multi thread.

                Oui, et ? Tu dirais que l’assembleur est obsolète ?

                Entendons nous bien, je suis loin de dire que Bash est un langage supérieurs aux autres, il a ses avantages et ses inconvénients, comme absolument tous les langages. Ce que je dis c’est que le considérer comme un langage obsolète qui n’aurait donc plus aucun avantage est une connerie. Qu’on aime pas sa philosophie, ses paradigmes ou sa syntaxe, soit, mais faut arrêter le « Bash bashing > ! ^^

                • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                  Posté par  . Évalué à 2.

                  Et je rappelle tout de même que jq peut avoir une syntaxe compliquée, il n’y a aucun besoin en traitement du JSON qui lui soit inatteignable

                  le problème c’est pas jq, le problème c’est de récupérer la sortie de jq de façon utilisable.

                  Le json est pas mal foutu, si 2 champs ont une semantique différente, tu les sépares. Mais bash est tellement limité que tu peux pas récupérer plus d’un champ à la fois sans rentrer dans un champ de mines. Utiliser des séparateurs magique (genré \n, ou une virgule, ou que sais je) ne marche pas, parce que ces caractères peuvent être dans ta valeur. A moins que tu veuilles te fader un parseur csv compliant avec toute la spec en bash, ou échapper tes valeurs de partout, pour ensuite les desechapper, mais tu reviens au même problème: c’est affreusement compliqué et casse gueule.

                  Et surtout, à ce compte là, autant écrire un parseur json en premier lieu. A ben zut, c’est physiquement pas possible à cause du typage. Tu le vois, le problème?

                  Est-ce qu’on reproche au C ces types natifs limités ? Ou a Perl de ne pouvoir avoir des arrays de pointeurs ? Même en Python les types d’objets « complexes » sont basés sur les trois types de base : scalaire, list et dict (sachant que tout scalaire peut être considéré comme une liste selon le besoin.

                  Le problème c’est pas les types de bases limites. Enfin, si, c’est un problème. Mais c’est pas mon point. Les tableaux en bash ne peuvent que contenir des chaînes. Pas de null, parce que ça existe pas en bash, pas un autre tableaux, rien. Des tableaux à 2 dimensions, c’est pas particulièrement rare, quand même. A plus forte raison quand les tableaux associatifs sont la seule structure de données que t’as.

                  Le concept du bash, c’est d’orchestrer des binaires en renvoyant la sortie de l’un vers l’entrée de l’autre, de manipuler de façon légère le système de fichier. Commencer à scripter du Kukes à coup de jq sort très largement de ce champ. Ruby/python feront ça les doigts dans le nez par contre.

                  T’as déjà eu affaire à du PowerShell ? :)

                  Sorti de survoler des scripts internes, non. Après, powershell a au moins le bon goût d’être typé, et te donner un output structuré (sans avoir besoin de te prendre les pieds dans le tapis avec sed et awk). Mais surtout, c’est pas le sujet.

                  Oui, et ? Tu dirais que l’assembleur est obsolète ?

                  Euh, ben, un petit peu quand même. C’est pas exactement un langage qui a le vent en poupe. C’est une niche de chez niche, quand t’as pas d’autre choix disponible.

                  Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                  • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                    Posté par  . Évalué à 3. Dernière modification le 23 novembre 2023 à 21:52.

                    genré \n, ou une virgule, ou que sais je) ne marche pas, parce que ces caractères peuvent être dans ta valeur.

                    Les outils Unix offrent généralement la possibilité d’utiliser facilement le caractère \0 (NULL) comme séparateur (options -0, --null, etc…), caractère que tu as quand même peu de chance de trouver dans les valeurs que tu dois manipuler. Et un des rares caractères que tu es sûr de ne pas trouver dans un nom de fichier au passage. Après c’est sûr que si tu comptes « parser » un fichier binaire ça va être compliqué…

                    Ignorerais-tu par ailleurs qu’il existe depuis la création d’ASCII des caractères précisément destinés à servir de séparateur ? Typiquement \x1c, \x1d, \x1e et \x1f ? Rien de magique…

                    bash est tellement limité

                    Bash est un langage dit « Turing complet », donc si limitation il y a, c’est celle de ta connaissance de ce langage.

                    A ben zut, c’est physiquement pas possible à cause du typage. Tu le vois, le problème?

                    Le problème c’est que tu racontes n’importe quoi.

                    Les tableaux en bash ne peuvent que contenir des chaînes. Pas de null, parce que ça existe pas en bash

                    C’est quoi pour toi un "null" ?

                    Un valeur qui doit nécessairement être différente de 0 ? Dans cas, doit-elle être inférieure à 0 ? Ou lui être supérieure ? Et un tableau qui a une de ses valeurs "null", par exemple [0, 1, 2, NULL, 3] il a 4 éléments ou 5 selon toi ?

                    Tu réalises que si on prétend ne faire aucune abstraction, toute donnée numérique n’est que chaînes de bits ? Et qu’en conséquence des concepts tels que "NULL" ou encore "NaN" ou "∞" n’ont strictement pas le moindre de sens en dehors d’une convention arbitraire ?

                    Tu dirais que l’assembleur est obsolète ?

                    Euh, ben, un petit peu quand même. C’est pas exactement un langage qui a le vent en poupe. C’est une niche de chez niche, quand t’as pas d’autre choix disponible.

                    Ben voyons…

                    J’ai l’impression que tu n’as pas conscience qu’un « langage informatique » est nécessairement une abstraction et que cette abstraction peut être de différent degré. La lecture de https://cs-lmu-edu.translate.goog/~ray/notes/pltypes/?_x_tr_sl=en&_x_tr_tl=fr&_x_tr_hl=fr&_x_tr_pto=rq peut éventuellement t’aider à visualiser le concept de niveau d’abstraction.

                    Il n’est pas question de niche. Sans l’assembleur/langage machine qui offre une abstraction des circuits électronique sous-jacents, tu peux oublier ton « Ruby/Python qui script du Kukes (?) les doigts dans le nez »

                    Commencer à scripter du Kukes à coup de jq sort très largement de ce champ. Ruby/python feront ça les doigts dans le nez par contre.

                    Je vais supposer que "Kukes" ça fait référence à Kubernetes ? Et bien dans ce cas je te dirais que « scripter du Kukes » c’est déjà commencer à faire de la merde, parce que si tu veux automatiser quelques choses sur un cluster Kubernetes tu implémentes un opérateur, tu écris ni du Bash, ni du Python ni du Ruby, mais du Yaml…

                    • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                      Posté par  . Évalué à 4.

                      Tu réalises que si on prétend ne faire aucune abstraction, toute donnée numérique n’est que chaînes de bits ?

                      Oui, et l’univers entier (et donc les bits aussi) se réduit à 4 types de particules élémentaires plus la gravité. C’est pas pour autant qu’on écrit du code dans le modèle standard. La façon dont on modélise l’information en science de l’information (aka informatique) me paraît être assez importante.

                      l’assembleur est peut être partout, mais on a des bootstrapping compiler depuis les années 50, et c’est pas pour rien que personne a écrit un langage en assembleur (ou en bash) ces 50 dernières années.

                      Je vais arrêter la, parce que si la discussion en arrive à « c’est quoi la différence entre l’absence de valeur et 0 » et « de toutes façons c’est qu’un voltage dans un circuit électronique », je suis pas sur qu’on aille très loin. La prochaine étape c’est «  brainfuck et white space aussi sont Turing complet ».

                      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                      • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                        Posté par  . Évalué à 2.

                        c’est pas pour rien que personne a écrit un langage en assembleur (ou en bash) ces 50 dernières années.

                        C’est simplement faux.

                        Figure toi qu’en 2023 des gens écrivent un OS et des applications de haut-niveau en assembleur : http://menuetos.net/ . Et ce n’est pas par pur plaisir intellectuel comme le Brainfuck.

                        Le Brainfuck est non seulement Turing complet mais ce qui est plus remarquable c’est que c’est le langage le plus simple qui puisse l’être (avec le nombre d’instructions le plus petit possible). Mais le Brainfuck est un langage « pour le fun/l’éducation », oui, mais ce n’est pas le cas des langages assembleurs.

                        Des gens ont même écrit un assembleur en Bash en 2001. : (Mais comme le brain fuck l’utilité est uniquement didactique/récréatif)

                        https://lists.gnu.org/archive/html/bug-bash/2001-02/msg00054.html

                        On peut effectivement cesser ce débat. J’ai compris ton point de vue avec lequel je ne suis absolument pas d’accord mais qui est tout aussi respectable que le miens.

                        Bon aprèm’ _o/

                        • [^] # Re: De la pertinence du KISS et d l’anticipation des besoins futurs

                          Posté par  . Évalué à 3.

                          C’est simplement faux.

                          Tu parlais de l’écriture d’un langage certes, donc à part l’assembleur écrit en bash, tu n’as pas complètement tort. par contre je te ferai remarquer que l’interpréteur Python (officiel) est écrit en C, un langage très ancien, mais donc absolumment pas obsolète. Je ne sais pas pour Ruby.

                          Cordialement.

  • # la fin du site central…

    Posté par  . Évalué à 5. Dernière modification le 13 novembre 2023 à 09:53.

    Et c’est comme ça qu’on arrive à « bazarder » des applications focntionnelles pour « se mettre à la mode », parce que le futur « on va pas l’affronter avec une Traban ».

    Cette dernière phrase est véridique : en gros, COBOL, IMS, DB2, JCL, JES2 et tout le toutim ça affiche peut-être 99,99 % de disponibilité, MAIS c’est pas hype !

    Entendons-nous bien : IBM, c’est du (très gros) privateur, et passer d’un privateur à l’autre, ça change rien à la philosophie de mon environnement de travail.

    Par contre, quand je vois à combien d’année-lumière se situe la galaxie cloud (parce qu’en fait on va passer de « l’antédiluvien » site central au cloud « moderne », ce qui au final fera qu’on bossera sur des machines distantes comme aujourd’hui en fait) en terme de simplicité de déploiement et de cohérence globale, ça m’attriste.

    Ça m’attriste parce que je remarque, les années passant, que ce vers quoi tend le cloud, c’est la « site-centralisation ».

    Ben oui, la différence entre cloud et site central, c’est que la plupart des problèmes ont trouvé une solution (qui n’est certainement pas parfaite, mais qui existe) il y a au moins 40 ans…

    On aurait pu nous reprocher que nos applications, soient mal gaulées, peu performantes, buggées, ou chères, mais non, elles juste « pas hype ! ».

    PS : pour donner un ordre d’idée du délire, on parle d’un budget de transformation de 150 millions d’euros !

    « Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »

    • [^] # Re: la fin du site central…

      Posté par  (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 13 novembre 2023 à 12:29.

      Inversement, refuser obstinément de se mettre un minimum à la page « parce que ça fonctionne en l’état », c’est prendre le risque réel de commencer à réagir quand on est déjà dans le mur. Et quand le produit ne se vends plus « parce qu’il est trop moche » et qu’on ne sait plus le redesigner en un temps raisonnable, parce qu’il utilise des techniques qui sont bloquées par défaut – à raison – par les navigateurs modernes, quand la concurrence arrive et fait mieux fonctionnellement avec 10x moins de boulot de paramétrage et 10x moins de boulot d’administration, c’est trop tard.

      La vraie difficulté dans un projet à long terme – vraiment long pour de l’informatique, sur plus de 10 ans – c’est pas de « suivre la hype » ou de « rester conservateur ». C’est de bien découpler les différentes parties de son projet, d’identifier ce qu’il est pertinent de mettre à jour et de réussir à le faire, et ce en permanence, sans laisser un morceau pourrir dans un coin, et surtout sans re-créer du couplage inutile.

      Une technologie moderne et qui apporte d’énormes avantages à un instant T (comme les JSP en 2000) peut devenir un boulet 20 ans plus tard (comme les JSP en 2020). De même, le code de 20 ans d’âge peut avoir été conçu selon des contraintes complètement obsolètes : toutes ces contorsions pour que le code puisse s’exécuter sur un serveur doté de 128 Mo de RAM peuvent être remplacées par quelque chose de plus rapide et plus facile à maintenir. Un LEFT OUTER JOIN sera plus lisible qu’un table1 = table2 (+). Etc.

      Je ne dis pas que c’est facile à faire, au contraire : la maintenance, c’est toujours risqué (régressions…), c’est un cout difficile à justifier, ça peut être long pour un résultat pas évident à court terme, et identifier quelles technologies sont à l’agonie et par quoi les remplacer est un exercice délicat. Mais un code qu’on a laissé pourrir dans un coin « parce que c’est fonctionnel » est tout aussi mauvais qu’un code qu’on passe son temps à modifier « pour suivre la hype ».

      La connaissance libre : https://zestedesavoir.com

      • [^] # Re: la fin du site central…

        Posté par  . Évalué à 2.

        On est bien d’accord. Ceci qui compte, c’est comment le code est écrit, pas en quoi.

        « Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »

        • [^] # Re: la fin du site central…

          Posté par  (site web personnel, Mastodon) . Évalué à 2.

          Attention : « en quoi » peut faire partie du problème.

          Par exemple, on peut se demander si maintenir du code en Pro*C ou en Progress 4GL OpenEdge Advanced Buisness Language est toujours pertinent, quand bien même ces deux langages sont toujours officiellement supportés. Parce que ces langages répondent principalement à des problématiques qui n’ont plus lieu d’être, qu’il est difficile de trouver des personnes qui les maîtrisent, et que l’outillage (au sens large : bibliothèque, outils de développement, de CI/CD…) associé n’est pas au niveau de langages plus utilisés.

          La connaissance libre : https://zestedesavoir.com

          • [^] # Re: la fin du site central…

            Posté par  . Évalué à 2.

            C’est plus compliqué que ça je pense.

            Par exemple, Je suis par confronté « régulièrement » à des soucis sur des modules assembleurs.

            Le manque de développeurs n’est pas tant liés au manque de hype de ce vénérable langage que :
            - l’incapacité des entreprises à entretenir les compétences (je parle de boite de 50 000+ d’employés dont plusieurs centaines d’informaticiens), pas de la « PME-du-coin » ;
            - l’incapacité des entreprises quand elles choisissent de plus entretenir les compétences dans un langage de se débarrasser des composants dans ledit langage.

            Et même pour des langages « non-abandonnés », on peut se retrouver avec des applicatifs critiques (j’ai en tête un module qui compte plusieurs dizaine de millions d’appel par jour) avec 1 seule personne compétente qui commence à prendre de l’âge…

            « Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »

            • [^] # Re: la fin du site central…

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Ce que tu décris est encore un autre problème : aucune procédure n’est décision-stupide-proof (pas même « ne rien faire »). Mais c’est ce que tu décris ici : des décisions stupides, pas des problématiques subies.

              La connaissance libre : https://zestedesavoir.com

            • [^] # Re: la fin du site central…

              Posté par  . Évalué à 3.

              modules assembleurs […] de ce vénérable langage

              Bien qu’il y ait un évident point commun, quand on parle d’assembleur, il y en a presque autant que d’architectures CPU/micro-contrôleur, non ? Ou bien est-ce qu’il y a quelques « standards » qui s’imposent ?

              Je me souviens en avoir fait un peu au lycée, pour programmer un micro-contrôleurs. Pour caricaturer je dirais que ça s’apparente plus à du Brainfuck qu’à un « langage » de programmation digne de ce nom ^^ . Ça me semble plus appartenir au domaine hardware que software. J’ai tort je sais, car il faut bien admettre que c’est incontournable pour le fonctionnement d’un ordinateur, et de tout logiciel un peu plus évolué.

              Quand je vois aujourd’hui le projet MenuetOS, qui montre qu’il est possible d’écrire un OS et des applications de « haut niveau » en se limitant à l’assembleur, je ne peux avoir qu’une immense admiration pour les gens qui s’emploient à cela. Il doit falloir une sacrée motivation et les compétences qui vont bien.

              C’est dommage que MenuetOS ne soit plus libre depuis sa version 64bits (la version 32bits l’est), je me souviens l’avoir testé il y a pas mal d’années sur un PC, et effectivement la rapidité d’exécution était impressionnante. Ça me fait plaisir de voir qu’un projet comme celui-ci est toujours actif, j’espère qu’un jour il sera libre à nouveau. Je me demande quels sont ses domaines d’application, je suppose qu’il doit y avoir quelques « niches », ce qui explique que le projet survive.

              • [^] # Re: la fin du site central…

                Posté par  (site web personnel) . Évalué à 5.

                Bien qu’il y ait un évident point commun, quand on parle d’assembleur, il y en a presque autant que d’architectures CPU/micro-contrôleur, non ?

                Oui, le langage assembleur n'existe pas en tant que tel.
                Tu peux même imaginer pour un même CPU avoir des assembleurs radicalement différents avec des macros dans tous les sens si tu veux pour aboutir au même résultat à la fin.

                Ou bien est-ce qu’il y a quelques « standards » qui s’imposent ?

                Cependant il y a quand même des caractéristiques souvent partagés et qui sont implicites derrière cette terminologie. On se limite +/- aux instructions du processeur cible. Peu d'abstractions de haut niveau, les instructions écrites par le développeur sont juste les instructions que le CPU met à disposition avec un nom plus joli que les simples valeurs hexadécimales. Les structures de contrôles sont donc rudimentaires, souvent des équivalents de GOTO, il faut gérer tous les aspects bas niveau pour l'initialisation du code (création de la pile et du tas mémoire), gestion bas niveau du matériel quand c'est pertinent avec écriture directe dans les registres qui vont bien, etc.

                Ça me semble plus appartenir au domaine hardware que software. J’ai tort je sais,

                En effet, tu as tort.
                Un ingénieur matériel ne codera pas souvent de l'assembleur dans sa vie car ce n'est pas son métier. C'est plutôt un ingénieur logiciel bas niveau qui s'en occupera dans un projet. Ou quelqu'un qui a une double spécialité dans l'intégration logicielle et matérielle. Je n'ai jamais croisé un ingénieur matériel qui en était responsable dans un projet. Ou à la marge pour tester un concept rapidement.

  • # Curseur à géométrie variable

    Posté par  . Évalué à 5.

    Le problème d'un curseur, c'est forcément que tout le monde ne va pas le mettre au même endroit et qu'il y a une grosse part de sensibilité dans les choix qui seront faits. Que celui qui prétend être objectif prenne un peu de recul, ou regarde 3/4 ans après le résultat de ses choix… et si il n'a pas de doutes, c'est que c'est un crétin aveugle.

    Personnellement, je me suis souvent battu contre l'écriture de script en Perl, parce que j'avais personne sous la main pour les maintenir, et que les besoins étaient ultra rudimentaires, donc on privilégiait Shell + AWK. Cette partie, je l'ai rarement regrettée.

    Et quand c'était plus compliqué, effectivement on poussait vers java, parce que toute notre équipe codait en java. Parfois, ça s'est avéré être un poison.

    Sur les arguments autour du Mainframe, c'est à double tranchant. On repousse continuellement les migrations, mais IBM se goinfre de plus en plus sur les factures. Et trouver de la compétence est de plus en plus dur. Personne ne peut contester la fiabilité du bouzin, mais on se retrouve avec de plus en plus de surcouches. Quelqu'un a essayé de faire communiquer du Mainframe avec autre chose que du transfert de fichier ou du messaging ? De faire du reporting évolué et personnalisable par le end-user ? Du web un peu sérieux ?

    Et pourtant, je suis le premier à dire qu'une interface texte, même pour des utilisateurs lambda, et du code backend en Cobol, c'est le truc qui marche pendant 20 ans avec pratiquement que des évolutions fonctionnelles, pas de la maintenance de framework à la mords-moi-le-noeud ou du contournement de bug mystérieux.

    Mais tout ça, c'est des détails. Plein de détails, dans un océan de merdes. Une autre merde, c'est que quand on prévoit un budget pour une refonte de plateforme, on prévoit la migration initiale (je vais passer de Cobol à Java/Angular), mais on oublie de prévoir les 2/3 ETPs sur les 20 ans à venir qui ne vont faire que la mise à jour des cadriciels… Du coup, c'est pas fait, et au bout de 3 ans, parfois avant la fin du projet de migration, tu as déjà une pile logicielle obsolète… Et si tu arrives avec 2/3 ETPs, on te retoque en t'expliquant que la plateforme actuelle est très stable, et fonctionne avec moins de personnes… Le chien qui se mord la queue…

    Et comme dit par ailleurs, les choix pris "par projet" dans une organisation qui compte des milliers de plateformes, ça va 5 minutes ; la cohérence est également importante au niveau global. Mais ne doit pas empêcher de basculer de techno quand ça a du sens. Sans basculer trop vite pour ne pas se retrouver dans des impasses.

    Si quelqu'un a la formule magique, je suis preneur.

    • [^] # Re: Curseur à géométrie variable

      Posté par  . Évalué à 2.

      Quelqu'un a essayé de faire communiquer du Mainframe avec autre chose que du transfert de fichier ou du messaging ? De faire du reporting évolué et personnalisable par le end-user ? Du web un peu sérieux ?

      Je ne sais pas ce que c’est « du web un peu sérieux », mais je sais que :
      - derrière de la souscription de crédit avec virement instantanée, front-end mobile, middle qui attaque le site central en API REST, ça tourne comme un moulin 24/7 ;
      - des alimentations d’ELK par le site central ça marche juste ;
      - qu’au passage le reporting, c’est l’essence du site central : considérer que chacun doit pouvoir choisir l’ordre des colonnes d’un rapport, c’est un peu du caprice : il n’y a pas 36 façon de faire parler pertinemment une même source de données (si on ne compte pas les besoins cosmétiques) ;
      - pour finir que le reporting en site central ça doit se faire par DFSORT et pas par des multitudes de programmes COBOL dont on peut-être sûr qu’au moins un comporte une erreur de rupture… (et en plus DFSORT ça consomme quasi-rien).

      « Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »

      • [^] # Re: Curseur à géométrie variable

        Posté par  . Évalué à 4. Dernière modification le 14 novembre 2023 à 14:27.

        Je ne sais pas ce que c’est « du web un peu sérieux », mais je sais que :
        - derrière de la souscription de crédit avec virement instantanée, front-end mobile, middle qui attaque le site central en API REST, ça tourne comme un moulin 24/7 ;

        On parle de mainframe IBM ? Avec du zOS/Connect derrière ou autre chose ? Sans contrainte sur la taille maximum de la réponse (limite à 64KB - oui c'est déjà gros mais des fois c'est pas assez - Bill Gates peut en témoigner).

      • [^] # Re: Curseur à géométrie variable

        Posté par  . Évalué à 6. Dernière modification le 14 novembre 2023 à 14:58.

        le reporting, c’est l’essence du site central : considérer que chacun doit pouvoir choisir l’ordre des colonnes d’un rapport, c’est un peu du caprice : il n’y a pas 36 façon de faire parler pertinemment une même source de données (si on ne compte pas les besoins cosmétiques) ;

        Suis-je le seul à être "choqué" par cette partie de l'argumentaire ?

        Qui n'a jamais eu besoin de masquer ou de déplacer des colonnes dans un fichier tableur ou de faire une requête en BDD avec un ordre de colonnes qui lui permet de mettre rapidement en évidence un certain nombre de choses ?

        Après tu veux peut-être dire que le site central devrait diffuser les colonnes dans l'ordre qui l'intéresse et laisser à d'autres applis frontend ou middle le soin de les mettre en forme ( et là je serais plus en phase avec toi), mais dit comme c'est dit dans ton commentaire ça me gène un peu.

    • [^] # Re: Curseur à géométrie variable

      Posté par  . Évalué à 2.

      Et pourtant, je suis le premier à dire qu'une interface texte, même pour des utilisateurs lambda, et du code backend en Cobol, c'est le truc qui marche pendant 20 ans avec pratiquement que des évolutions fonctionnelles, pas de la maintenance de framework à la mords-moi-le-noeud ou du contournement de bug mystérieux.

      \o/

      Je suis tout-à-fait d’accord : rien ne vaut en terme de productivité une interface texte bien foutue !

      « Y a même des gens qui ont l’air vivant, mais ils sont morts depuis longtemps ! »

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.