groumly a écrit 3282 commentaires

Donc tu n'écris aucun test programmatique parce qu'ils peuvent être déjoué ?

Non, le développeur écrit une batterie de test UI automatisés. Ce qui est, comme je le pointait au dessus, une tâche plutôt difficile, donc réservée à quelqu’un qui bouffe du code toute la journée (pas un qa).

Quand il a finit, l’ingénieur qa prend le relai et tente de casser la feature. Il rapporte des bugs, qui partent soit au produit, soit à l’ingé. Si ça part à l’ingé, il rajoute un/des test UI, corrige le bug, et ferme le ticket. Si ça part au mec produit, il change la spec et tu repart au début.

Ce que tu ne peux pas faire c’est dire “on a des UAT, et ils sont implémentés par l’ingénieur, donc on a pas besoin de faire une passe en profondeur manuelle”. En pratique, ta passe manuelle en profondeur va doubler ou tripler le nombre d’uat, et probablement nécessiter des raffinements à la spec.

Quand tu met à jour une bibliothèque/framework, la base de données ou la version du langage, comment tu fais pour qualifier la prochaine version ?

Ça va dépendre de la bibliothèque. Une migration à iOS n+1, on corrige tous les tests automatisés qui foirent (2-3 douzaines en général), et après on fait une passe de regression manuelle sur toute l’appli. On revérifie pas chaque feature a 100%, mais on s’assure de toucher chaque feature, et on passe un peu plus de temps sur les flows les plus importants.

Une bibliothèque plus technique/pas user facing (genre le tracking marketing, ou le client http) va typiquement être mockee, donc les tests automatisés servent pas à grand chose. Validation manuelle par l’ingénieur développement qui fait le changement dans ce cas. En pratique, c’est souvent un scream test malheureusement, le changement est fait, ca compile et on attends que les mecs du marketing se plaignent.

La base données, elle est dans le backend, on parle de tests front end la. Le backend, il a ses propres tests, qui, eux, sont beauuuucoup plus simples à écrire en général. Et le plus souvent unitaire. Cela dit, la db a en général des tests d’intégrations, oui, mais c’est pas un problème super dur à résoudre tant que t’utilise pas oracle ou sqlserver. Une image docker, une bonne couche de colle, et ça roule. Et si ton front end parle à la db directement, y’a pas forcément de mal, ça peut faire du sens. Mais dans ce cas, je doute très fortement que le sujet des tests UI automatisés soit pertinent.

Ce n'est pas de la gruge

La DI n’est pas de la gruge non. Mais c’est le niveau 0 de ce dont tu as besoin pour tester ta UI. Tu vas très vite avoir des problèmes assez fondamentaux de performance si tu gruges pas.

Ça va tres vite finir trop technique/pointu pour une discussion linuxfr, mais mon example de base, c’est l’interaction avec les boutons, ou n’importe quel component. T’as 2 options, soit tu fait ça propre, et tu génères le touch event qu’il faut pour effectivement taper le bouton, soit tu gruges, et ton test appelle directement l’IBAction qui est censée être liée au bouton (encore que, pour les boutons, tu peux faire ça propre, mais pas pour les table view ou beaucoup d’autre components très courants).

La première option va te donner des test flakys, et très, très, très lent. Trop lent pour espérer scaler.

La deuxième option va te donner des résultats fiables et très rapides. Mais tu testes pas exactement ce que tu voudrais. Et techniquement, tu peux te prendre une régression sur le lien entre le bouton et l’ibaction. En pratique, cette régression a très très peu de chance d’arriver, c’est un risque acceptable, et qui te permet de valider des choses qui elles, ont des chances non négligeable d’arriver.

C’est quelque chose que j’ai finit par accepter, les testes doivent d’abord être fiables, ensuite rapide, et ensuite fidèle/précis, dans cet ordre. Si la précision ne te permet pas d’être fiable et rapide, il faut réduire la fidélité/précision.

Donc, si ton bouton est renommé, ton test doit planter, parce que tes spécifications fonctionnelles ont changées. Donc il faut les retoucher.

Oui, tout à fait. Le problème, c’est de trouver quels tests il faut retoucher. Et quand t’as une suite de plusieurs milliers de tests, c’est pas forcément évident comme tâche. D’où l’intérêt d’être très précis dans tes sélecteurs. Y’a un autre aspect aussi, c’est de décrire précisément la semantique du test. Un test qui foire en disant “couldn’t find get started button”, ca t’aide pas forcément à comprendre que c’est le bouton “login to get started” que tu cherches maintenant, alors que “button with id get-started has label login, expected get started”, ca clarifie tout de suite les choses.

La spec c'est par exemple, je dois avoir un bouton nommé bouton dans le panier et je dois avoir un bouton nommé "bouton" dans le menu.

Ce genre de spec reconnaît implicitement le problème, sans permettre de le résoudre proprement. Ton example ici marche, mais c’est un exemple trivial. Une liste avec des doublons va te donner beaucoup de fil à retordre avec cette approche. D’ailleurs, les listes sont typiquement un enfer à gérer dans ces tests, surtout quand tu cherches un élément qui est en dessous du fold (lazy loading/reutilisation de vues).

C'est un fait, ce n'est pas propre à UUV, mais à toute technologie de test E2E à minima. Il faut bien configurer les solutions que l'on utilise y compris les timeouts. Très souvent on laisse la conf par défaut qui n'est pas du tout adapté à notre besoin. Je préfère répondre comme ça, parce quand je lis tes remarque sur cette partie, c'est comme si tu préconisais de ne pas faire de test E2E automatisé du tout :-D

Oula, non, pas du tout. On fait tourner plus de 4000 tests UI sur chaque pull requests. Et même ça, c’est très très très loin d’être assez, ils nous en faudrait probablement 30 à 40000 pour avoir une couverture décente. Et notre approche scale a ce niveau, ça prendrait 15 à 20 minutes pour 40k tests. Et on a très très peu de tests unitaires, je dirais dans les 300 (appli grand publique qui marche pas sans le backend, 99% de notre logique est une logique ux, la logique métier est gérée par le backend).

Je répondais au point de barmic qui disait que ce genre de tests ne sont pas écrits par des développeurs, et ne sont pas à l’intention des développeurs. Je suis passé par cette approche, et je n’y croit absolument pas. Les problèmes techniques ouverts par des tests UI sont beaucoup trop complexe pour laisser cette tâche à des non techniques. Même l’équipe qa n’est pas équipée pour les écrire. C’est un problème d’ingénierie très difficile, qui ne peut être résolu que par des ingénieurs en development.

Les tests automatisés, c'est avant tout automatiser ce qui est facilement automatisable et qui fait gagner du temps à être automatisé.

Pas super convaincu, pour être honnête. Ça reste un effort, et y’a pas grand chose de facilement automatisable sur un service non trivial, le gain est trop petit. Même si tu peux effectivement automatiser qq chose sur ta home page trivial, ça va durer combien de temps avant que les mecs produits rajoutent suffisamment de choses pour avoir un intérêt?

mais ce qui n'est pas top, c'est que certains projets veulent tout automatiser et ça altère la perception vis à vis de ces pratiques de test.

la encore, pas trop d’accord. Pas du tout même. Tu peux quasiment tout automatiser. La encore, j’ai un biais vers iOS, qui a beaucoup de choses littéralement impossible à tester. Genre les api background location qui passent des objets n’ayant pas de constructeurs publique. Si tu peux pas instantier le paramètre passé à ton core location delegate, forcément ça va moins bien marcher maintenant, comme dirais l’autre.

La soluce, c’est de gruger. Ton core location delegate trampoline vers ta méthode à toi, qui prend un objet que tu peux instantier. Et tu gruges dans ton test, en appelant cette fonction la directement. Il va effectivement te manquer un bout dans ton test, mais au moins tu peux garantir que tout ce qui vient après le point d’entrée fonctionne comme il faut.

Le gros problème, c’est de savoir gruger, sans trop gruger. C’est un art. Mais tellement différent de beaucoup d’autre solutions software, surtout quand on parle d’ux.

Je pensais plus aux tests d'acceptance qui sont écrit dans les users stories.

Mouaif. Je suis loin d’être convaincu. Peut être qu’on bosse comme des porcs chez moi, mais au mieux du mieux, tu va avoir peut être 80% de couverture sur des uat dans le ticket, et uniquement sur la logique métier pure. Toute la partie technique (typiquement, si ton backend se ramasse, backward compat pour appli, race conditions, etc) ne sera pas couverte par ces tests. C’est certainement une bonne base pour commencer ton test plan, mais ça gratte juste la surface.

Manuellement ça ne monte pas à l'échelle et c'est sujet à nombre d'erreur.

Pour avoir vu “l’équipe d’en face” à fond dans la mentalité “on test tellement tout via automation qu’on a viré toute la qa”, je suis pas sur si je suis d’accord.

Leur Jira board avait vachement moins de bugs, pour le coup, faut rendre à cesar ce qui appartient à cesar. Mais c’est surtout parce que y’avait personne pour les remonter, en fait. Des bugs, y’en avait absolument partout, et des gros comme le nez. Genre le coup du deuxième bouton get started, ils l’ont eu. Ils auraient du le changer, et ils l’ont pas fait.

apres, je suis pas sur de suivre. Tu dit que c’est pas raisonnable de tester manuellement chaque nouvelle feature que l’équipe pond?

Pour clarifier, ma position c’est que l’automation n’est pas fiable pour valider une nouvelle feature, aussi petite soit elle. Une machine c’est con, et ça rate ce qu’on lui dit pas de capturer. Par contre, c’est super baleze pour vérifier que les tests existants passent toujours, de la régression quoi. Un humain va te trouver plein de petit détails à la con. Alignment off by 1 pixel, copie qui sonne bizarre, intégration de la feature dans le reste de l’écran, label tronqué (bon courage pour faire comprendre ça à une machine, en tout cas sur iOS), tout un paquet de petits trucs qui s’additionnent.

Si tu peux trouver un ingénieur pour écrire le code, tu peux trouver un qa pour le tester. 1 qa pour 3 à 5 développeurs, c’est grosso modo le ratio que tu veux. Ça passe très bien à l’échelle de ce que j’en voit.

C’est un sujet qui me tient à cœur, et dans lequel j’ai passé beaucoup de temps (facile 20% des 12 dernières années). J’ai un peut tout tenté, pour être honnête. Du cucumber et dérivé, du bdd, du pure black box testing, de l’officiel Apple, du à l’arrache, de l’hybride. Du page object model, de l’unitaire pur. Sur iOS spécifiquement, qui est honnêtement un véritable cauchemar à tester de façon fiable.

J’ai même donné un talk y’a pas longtemps la dessus, c’est dire si j’assure (sarcasme, évidemment).

Donc c'est pas le développeur qui les écris ou en tout cas pas celui qui écris le code et il ne sont pas à destination des développeurs.

Ton kilométrage va varier, en fonction de beaucoup de chose, mais en gros, mon opinion c’est absolument pas, pas pour tester une UX utilisateur comme OP le fait dans son naljour.

Pour nuancer le propos, si tu fait ça, tu vas vaguement tester en surface, ça va te coûter un temps fou, avec beaucoup de false positive et false négative, et tu vas dépenser beaucoup d’énergie pour au final très peu. Avec en cadeau bonux une fausse impression de sécurité qui va te retomber sur le coin de la gueule un jour.

Ce que j’ai apprit sur l’automated UI tests (désolé pour l’anglicisme, je cause pas francais professionellement), c’est que c’est un problème super couillu ‘achement dur. Un truc de vrai gars/meuf qui en veut. T’as de l’asynchronicite de partout, 99% des frameworks sont beaucoup trop lent pour espérer avoir une quelconque couverture, le bon vieux problème des mocks, mais puissance 10 parce que tu testes en blackbox, la combinatoire explose très vite sur le moindre service même simple. Beaucoup d’architecture, parce que tout doit être mockable, et contrôlable. Beaucoup de precondition à vérifier, énormément de mock data à injecter, et énormément de sucre syntaxique, parce qu’un flow de base, c’est vite 100-200 test pour une couverture juste passable. Et du coup, énormément de maintenance. Rien que définir ce que chaque test est censé tester, comment les découper et les organiser devient très très vite un problème. Ça prend beaucoup de domaines pas forcément simple, et les combine pour faire un plus gros problème. <insert joining forces meme>

L’exemple numéro 1 est rigolo, il est en plein dedans. Ce test va peter la seconde ou le label va changer. Ou peut être pas, si par malheur t’as un autre bouton nommé get started (que t’as oublié, ou qui est correct, les 2 sont funs, mais de façons différente). Ou si tu fais un a/b test. C’est pas pour rien qu’on test généralement par id. Le test c’est pas de savoir si y’a un bouton qui, par hasard, s’appelle get started, mais de vérifier si ce bouton s’appelle get started. Et que ce bouton est hidden quand t’es connecté, mais en fait non, tout le bloc auquel ce bouton appartient, etc. C’est un example basique de chez basique, qui effleure à peine la moindre logique métier, et c’est déjà pas glorieux.

l’example numero 2 aussi est marrant. Ça marche, peut être. T’as deux options en fait. Une animation est ajoutée, et paf l’asynchronicite, t’as un test de shrodinger. Des fois il passe, des fois il passe pas. Option 2, le framework de test attend. Longtemps. Et la ça passe. Jusqu’à ce que le test capture un vrai problème, tous les test sur cette feature petent, et paf, ton pipeline se prend 15 minutes dans la gueule. Multiplies ca par le nombre d’ingénieurs qui bosse sur le projet en parallèle, et tu te rends compte que ton pipeline passe son temps stallé à attendre que des test fail (je vous l’ai dit, je cause pas la France professionnellement. Appelles moi jcvd si tu veux, ça m’en touche une sans faire bouger l’autre).

Une equipe qa qui roule bien, c’est des gens un peu technique qui arrive à groker pas mal d’outils, lisent du code pas trop aride sans trop de problème, mais galèrent à écrire autre chose que de l’impératif simple. Et surtout, surtout, des sociopathes qui sont obsédés à l’idée de casser leurs jouets (le site web/l’appli), dotés d’un sens de l’observation et une attention au détail redoutables (ok, j’exagère sur le côté sociopathe). C’est une mentalité particulière, et surtout c’est diamétralement opposé à la mentalité classique de l’ingénieur qui essaye de construire quelque chose. Tout ça pour dire, tu vas avoir beaucoup de mal à trouver quelqu’un qui a à la fois la technique pour résoudre des problèmes d’ingénierie pas piqués des hannetons, et qui arrive aussi a penser comme il faut pour tout peter.

Les autres membres de l’équipe, t’oublies. Les mecs produits ne comprennent pas la moitié de ce message, les designers, bah c’est des designers, le project manager sue à grosses gouttes dès que tu le sort d’excel, le manager est trop occupé à se la peter en meeting pour s’approcher d’un compilateur.

Bref, comment tu resoud ça? C’est pas facile. Mais tu prends des ingénieurs doués, tu les motives en leur montrant le côté couillu du problème (carrotte), tu leur prends bien la tête quand y’a une régression (baton), et tu les félicite quand la CI fail un build sur une régression (deuxième 🥕). Tu leur fait écrire la couverture de base quand ils écrivent la feature en premier lieu, ça sera super léger au début, et ensuite ils vont apprendre et s’améliorer. Ensuite t’envoie ça à la qa manuelle. Et chaque bug filé repart au dev, qui ajoute un test d’abord, et ensuite corrige le bug (ça par contre, c’est une bataille en pente qui monte, comme ils disent outre quebin). Ah, et évidemment, en amont, t’as un ou deux gars qui est responsable de mettre en place toute l’infra. Le coeur du harnais de test, la ci, la DevX, les patterns pour à peu près tout, la doc, etc.

bref, les tests automatisés, c’est fait par des développeurs pour des développeurs, et ca sert à 100% à détecter les régressions, certainement pas à valider la feature en premier lieu. La qa c’est manuel, fait par des des profils précis, et c’est 100% pour ta validation initiale.

Ok, mais ça a mit plus de 5 ans pour en arriver là. Le premier crash du 737 max, c’était en 2019, et la faa a pas bronché.

Il a fallu 300 morts sur 2 crash, une compagnie us qui a perdu une porte en plein vol, et un lanceur d’alerte retrouvé suicidé dans un baril de béton au large du vieux port.

tu peux prendre un autre exemple, tesla a tendance à être très silencieux sur leurs pannes. Les autres constructeurs sont pas forcément super bavards non plus, remarque. Ils lancent un recall, disent que la pièce machin marche mal, on va la changer, et pas grand chose de plus.

C’est un peu ce que crowdstrike fait ici.

Par contre, dans l'industrie informatique, c'est loin, voire très loin d'être exemplaire chez la majorité des acteurs.

On va dire que ça dépend pas mal du secteur. Apres, oui, je préférerais de très très loin si c’était la norme.

je ne sais pas si des informations pertinentes sortiront de cette audition.

L’âge moyen/median de la maison est de 58 ans, et ils sont pas franchement technique, donc t’attends pas à voir une analyse technique détaillée qui explique comment ils se sont retrouvé à de référencer un dangling pointer, malheureusement.

Ils vont lui casser les couilles sévère, il va dire pardon, on l’a pas fait exprès, on le fera plus, il va repartir avec son ego froissé et se mettre une caisse le soir pour oublier. Et pas grand chose de plus, parce que le congrès est un corps législatif et ne peut pas faire grand chose d’autre.

Le congress va potentiellement se servir de ça pour créer une nouvelle loi, mais vu comment ils sont complètement bloqués dans des querelles de clocher, et le fric en jeu dans le milieu, je m’attendrais pas à des miracles.

Enfin, je veux dire, chez CS ils savent bien déjà ce qui s'est passé et comment fonctionne leur système ?

4 jours plus tard, oui, j’espère qu’ils ont un post mortem interne bien détaillé, vu la merde qu’ils ont mit :)

Il n'y a que dans notre industrie qu'une telle aberration est possible. Provoquer une panne de cette ampleur et avoir que le strict minimum en terme de communication.

Mouais. Quand les 737 max ont commencé à se mettre au tas en 2019, Boeing savait très bien ce qu’il s’était passé. Idem quand un autre 737 a perdu sa porte en vol. Et ça, c’est dans une industrie super régulée, avec des accidents qui ont fait plus de 300 morts.

Apres, je suis pas sur que leur silence radio leur fasse beaucoup de bien. Je pense que quelques cto/dis sont en train de négocier de façon plutôt sèche un remboursement avec leur commercial, parce que la ils ont poussé le bouchon un peu loin.

Tous les credentials Microsoft du monde ne sont pas super utiles quand il s’agit de savoir ce que crowdstrike fait en pratique.

Y’a un monde entre télécharger du code exécutable (que soit binaire ou recompilé/interprete à la volée), ou paramétrer du code existant à la volée.

J’ai toujours pas vu de détails techniques venant de crowdstrike, donc je doute qui que ce soit en dehors de CS n’a l’autorité de commenter sur ce qu’il s’est réellement passé (autre que « Bestel, il a branché la CiBi sur le kernel, et il a fait pffft »).

La production, c'est avoir le risque de panne, et les pannes, c'est pas juste du lundi au vendredi, de 8h à 17h.

C'est juste que c'est plus simple d'avoir toutes tes équipes sur le pied de guerre un mercredi a midi que ca l'est un vendredi a 17 heures, ce qui évite de retarder la resolution.

Apres c'est aussi souvent parce que ce genre de pratiques sont poussees par des boites grand public, qui ont tendance a voir plus de traffic le week end qu'en semaine. Et que donc, pour eux, ya un plus gros impact un vendredi soir qu'un mardi apres midi.

Si on suit ton raisonnement, on laisse délibérément des centaines de millions de gens avec des truc obsolètes

Mettons android a part (parce que c’est clairement vraiment pas brillant de ce côté là). Mais tu pense vraiment qu’il y’a des centaines de millions de MacBook Pro vieux de plus de 10 ans encore en utilisation? Surtout sur cette génération (on va dire 2012 à 2015, la generarion Retina, mais avant l’usb c).

J’ai bien évidemment pas accès aux chiffres d’Apple, mais je suis prêt à bouffer mon chapeau si y’a plus de 100 000 personnes qui utilisent encore une vieille trapanelle pareille.

La génération apple silicon va probablement mieux tenir dans le temps, donc on va voir un peu ce que ça donne dans 6-7 ans.

Toujours est il que qualifier plus de 10 ans de support (oui, parce que même si séquoia ne tourne pas dessus, sonoma lui est toujours maintenu niveau sécu pour quelques années) d’obsolescence programmée, c’est un peu du grand n’importe quoi. Quelle durée te satisferait? 20 ans? 30 ans?

On va pas pousser mémé dans les orties.

Y’a une faction qui dit « le logiciel doit être libre, parce que ça correspond à nos valeurs morales/ethiques, et on fera tout ce qu’on peut pour que vous adoptiez nos valeurs », et l’autre qui dit « dans l’ensemble, on trouve qu’on a de meilleurs résultats quand on publie tout, mais chacun fait fait fait c’qui lui plaît plaît plaît, nous ce qu’on veut c’est du code qui marche bien ».

Tu peux tenter de prétendre que les seconds sont politique, comme je pourrais prétendre que l’athéisme est une religion, mais ça ne nous mènera pas bien loin.

Tous les acteurs ne le prennent pas sous un angle idéologique.

Mais prétendre que des mecs comme rms, la fsf et une part non négligeable de la communauté, et part conséquent des discussions ici, ne sont pas politiques, c’est quand même très hypocrite.

Pas sociétal, c'est nullement mon intention.

dit le mec qui vient d’écrire le premier gros pavé societal/politique du thread.

et d’autant plus riche sur linuxfr, un site dédié au logiciel libre, mouvement autant politique que technique.

On peut aussi mentionner le fait que les langages étaient beaucoup moins bien foutus et les compilateurs moins performants, mais pareil, ça me semble pas compenser l'augmentation de la complexité des programmes.

Je pense que tu confonds cause et effet. La complexité des programmes a monté, oui, mais c'est surtout une consequence du tooling et des fondations (compilos y compris) qui a vraiment monté en puissance, en parallèle du hardware.

Le multi threading sur un CPU single core, effectivement, ca servait pas forcement a grand chose, a part laisser le main thread redessiner l'interface. Les modèles de programmation reactive servent pas forcement a grand chose sur des applis qui n'ont pas besoin de constamment se mettre a jour sur un flux de données constamment mises a jour (ce qui rejoint ton point sur la prevalence du réseau avant). L'état de l'art était pauvre, et les technique de programmation reflétaient ca. Quand les besoins se sont fait clair, on a tâtonné un peu, et fini par avoir des bases tres solides, qui permettent de se concentrer sur l'essentiel.

Je vais pas prétendre que les bugs de memory management ont disparu, mais ils deviennent des plus a plus dur a écrire (ARC dans le monde apple qui a eliminé 99% des problèmes, java/python etc, meme c++ te met des auto partout).

Le réseau a été abstrait par des couches robustes, t'as maintenant du multipath qui passe d'une interface a l'autre sans que l'application au dessus ne se rende compte de ce qu'il se passe.

Bref, tout ca pour dire, la complexité a monté, oui, mais surtout, elle a muté. On est passé d'une complexité accidentelle (synchroniser l'acces a une variable globale depuis plusieurs thread), a une complexité essentielle (envoyer des closures sur des queues, qui ne modifient qu'un état prive, non partagé). Tu peux toujours te mettre au tas, ou deadlocker, oui, mais dans l'ensemble, c'est vachement plus dur a fair maintenant qu'il y a 10 ans.

Ne pas répondre à cette question au moins une fois ; à mon sens, c'est un manquement majeur.

Ouais, comprendre la chaîne de compilation, c’est important. Mais aussi, pas tant que ça. Sur du java/javascript/python, y’a pas forcément grand chose de subtil, et en 20 ans, j’ai jamais eu un seul problème la dessus. Tout est dynamique, on s’en fout du layout en mémoire (sorti de trucs bizarres comme la serialization, mais c’est assez extrême comme example).

Sur un cours c/c++/objc/swift, la oui, ça me paraît indispensable, parce que ça va très vite te peter à la gueule si tu comprends pas ce qu’il se passe. Je suis le gars de service qui explique pourquoi le build a pété, pourquoi non, on va pas static linker une librairie dans 4 extensions, et pourquoi le runtime gueule comme un putois d’avoir des symboles en double à cause dudit static link de partout. Et me lance pas sur les Bitcode, le simulator meme sur un m1 est une arch différente, et non, tu peux pas juste linker, juste parce que la méthode existe dans les 2, le layout est pas le même et ça va te peter à la gueule.

Mais, aussi, je vois une armée de dev java/js/.net à côté qui s’en battent les steaks de leur chaîne de compilation et ont jamais eu le moindre souci en 15 ans de carrière. Disons que c’est un peu choquant pour les vieux de la vieille, mais dans ce monde moderne de runtime, bytecode et interpreteurs jit, c’est loin d’être le plus important.

Pour être tout à fait honnête, je préférerais de très, très, très loin qu’on arrête d’enseigner que l’oriente objet, c’est l’héritage, parce que ça fait beaucoup plus de dégâts que de ne pas savoir lancer javac à la mano. J’te jure, le prochain nouveau diplômé qui m’explique qu’une voiture c’est un véhicule, et que donc c’est polymorphique avec des camions, des motos et le vélo à petites roue de mon fils, je vais peter une durite.

Sauf intellij et eclipse. Ils tentent d'être plus malins que maven et d'ailleurs ne cherchent pas à être trop lié à ce dernier mais ils ont une bonne intégration et tu n'a pas à savoir ce qu'ils font dans l'énorme majorité des cas. Tu manipule juste des pom.xml et c'est terminé.

Ben, dans l’ensemble, c’est un javac de tout ce qu’il y’a sous main/src et main/test. Le problème, c’est les dépendances, et c’est pas IntelliJ/eclipse qui va les chercher, ça fait juste tourner un mvn.

Je pense que le commentaire au dessus parlait de cas de ne pas savoir ni compiler ni lancer le programme sans l'IDE. Je ne sais pas ce qu'il en serait aujourd'hui mais fut un temps si tu te laissais portait par l'IDE sans chercher à comprendre, tu cliquait juste sur un bouton play et tu n'avais aucune idée de ce qui se passait derrière.

C’est précisément mon point. Ça fait 20 ans que je fais du java professionnellement (la vache, ça pique!), je serais absolument incapable de builder mon appli a la mano. Et par dessus tout, ça serait complètement con.

Idem pour lancer l’appli à la main, mvn exec:java, et encore je vais me ramasser sur la syntaxe (je sais qu’il y’a un exec, mais probablement pas java, et je sais aussi que mes variable -D vont passer à la trappe).

leurs collègues Java qui savent pas compiler sans IDE ("t'en auras jamais besoin").

Ouais, après, je suis pas convaincu qu’il y ait grand monde qui lancé javac directement ces 15 dernières années. C’est même pas une question d’ide, tout le monde (y compris les ide) déléguent cette tâche à maven.

C’est probablement techniquement possible de compiler la plupart des projets Java à la main, mais je suis franchement pas convaincu de l’intérêt.

C’est pas juste l’inflation. Entre l’assurance médicale (dans les 20-25k/an pour une famille de 4), les 401k (retraites, grosso modo 15-19k/an), et le coût des crèches/écoles (20k, voire plus, par enfant/an, en fonction de la ville), les salariés us sont de base 60k plus cher à pouvoir d’achat d’égal que leurs voisins canadiens.

Avec Covid qui a montré que le travail à distance, ça peut marcher, forcément…

Département HR super frileux aussi, qui préfèrent lâcher un chèque décent que de se risquer un procès, les coûts et la mauvaise PR qui va avec.

Enfin, à part pour Elon Musk.

Je lui ait déjà suggéré ça 2 fois, mais non, il a une solution, reste plus qu’à trouver le problème.

Qu’importe que MS, Apple et un certain nombre de projets libres aient tous atteint la même conclusion (système de fichier traditionnel qui nourrit un index) après avoir bossé dessus pendant quelque années.

La question c’est surtout qu’est ce que ça fait, pas si c’est possible.

Si au final, 98% des fichiers du filesystem (pas forcément loin de la réalité, y’a une énorme quantité de fichier systèmes ou applicatifs dont personne n’a rien a faire) on tous un tag correspondant à leur fully qualified path, c’est un peu admettre que le système de tag est un échec, d’une part, et on en droit de se poser la question de savoir si ça en vaut la peine.

D’autre part, ajouter des milliers de tags « systèmes », ça a un coup sur le système d’indexage, et un gros coup sur l’ux, parce que maintenant faut les cacher ces tags. Sauf quand tu les cherche. T’as aussi des problèmes plus fondamentaux. Un path est garanti d’avoir un seul fichier au plus au bout, un tag pas du tout. C’est un peu une recette pour un désastre pour le système si je décide de tagger un fichier /bin/sudo, ou autre joie du style.

Je suis sur que tu peux trouver une approche ou tu peux reconstruire une arborescence à partir de tag, mais c’est à peu près aussi malin que d’essayer de reproduire un système de tags à partir de lien symboliques, comme c’est parfois suggéré.

On en revient à la question de « quel problème t’essayes de résoudre exactement? », et mon petit doigt me dit que la réponse est « tagger quelques dizaines à centaines de fichier utilisateurs, créés en session interactive ». Auquel cas, l’approche d’Apple marche un peu mieux à une fraction du coût.

Y’a beaucoup de fichiers dans un système de fichiers, et tous ne sont pas créés en mode interactif (genre fichiers téléchargé par une appli, ou zip décompressé, ou config auto générée, fichiers de logs, core dump, ce genre de choses). Un système basé exclusivement sur les tags veut dire que beaucoup (la majorité même) de fichiers serait impossible à trouver soit par manque de tag, soit perdu dans le bruit de 200 000 fichiers ayant le même tag. Et c’est sans compter tous les outils qui s’attendent à trouver des fichiers spécifique à des endroits spécifiques, on va pas créer un tag par fichier dans /etc.

C’est pas un système qui marche au quotidien en mode exclusif.

En mode hybride par contre, à savoir système de fichier traditionnel enrichi avec des tags pour ce que l’utilisateur veut spécifiquement tagger, ça marche très bien. macOS fait ça depuis plus d’une décennie, ptetre même plus de 15 ans. Tu tagges ce que tu veux tagger, le Finder te sort ce que tu veux. Tu peux tagger des dossiers et pas t’emmerder à tagger chaque fois dans cette arborescence, ou juste tagger des fichiers individuels. Y’a techniquement un support pour la ligne de commande, mais ça a pas l’air top moumoute, je pense parce que le système de tag se prête mal à la ligne de commande en règle générale.

C'était une pique bonne enfant.

Autant je reconnais a 100% la lutte des genres, et qu'en tant que mec blanc qui a la quarantaine et dans une position de pouvoir, que ma vie est tres differente de celle de la moitié de la population, et tout ca.

Autant, l'écriture inclusive dans une langue fondamentalement genrée, c'est chaud, mec (ou meuf, ca marche aussi). Je suis pas forcement super réceptif a l'argument comme quoi l'écriture inclusive est nécessaire pour changer les mentalités. Je reconnais aussi que si ca me fait mal a l'oreille, les langues vivantes, ca évolue. Ca reste un peu trop gros pour moi. Et ca pique vraiment les oreilles, accessoirement. C'est ptetre un biais professionnel, ou l'ingénieur en moi voit trop de cas a la marge pour que le refactoring marche. Maintient la stack legacy, elle tourne et on arrive a la patcher la ou il faut quand il faut.

Oui, la langue precede la pensée, c'est un peu le point central de 1984, supprimer les idées subversives en supprimant la possibilité de les exprimer. Mais je pense pas que ca s'applique ici.

L'anglais est neutre dans son immense majorité, et pourtant v'la le merdier aux US pour tout ceux qui rentrent pas parfaitement dans le moule niveau identité sexuelle/genre. Dans le genre puritain et obsédé par des trucs qui les concernent pas DU TOUT, genre la bite du fils du president (c'est un cap! Que dis je? C'est une péninsule!), les mecs ils s'imposent (et les meufs aussi).

Pour être tout a fait honnête, j'avancerais qu'a la base, c'est surtout une question de maintenir le pouvoir et a de renforcer son autorité. Un p'ti chef restera un p'ti chef, quelqu'un qui a peur de ce qu'il ne connait/comprends pas aura toujours peur, que sa langue soit genrée ou inclusive. C'est un problème orthogonal. Si c'était pas les trans/non binaires/homos/que sais je encore, ca serait un autre groupe arbitraire qui souffrirait des velléités dominatrices d'une proportion de la population.

Bref, fin de la parenthèse.

iel, celle

Je suis confus :)