Ça c’est au moins un problème qu’on a plus.

Bah ça fait chier, d'autant qu'en plus pour le coup c'est pas trop dégueulasse ce qu'il fait, mais bon.
Le vent est en train de tourner dans le monde du jeu vidéo où chaque annonce de NFT se prend un backlash tel que les studios abandonnent direct, sauf Ubisoft vu que l'ADN de la boîte c'est d'être plus intelligent que tout le monde et c'est les autres qui sont cons.

Bon, dernier sms reçu de madame qui est partie voir sa mère à l’hôpital : « Je vais rester plus longtemps que prévu, c’est la fin et je veux rester auprès d’elle »
Je suis en train de préparer le dîner, les grosses jouent dans leur chambre, je sais pas trop comment lancer la conversation a table

Question pour les vieux pervers qui utilisent des makefiles pour leur automatisation (genre much ou harko): vous gérez ça comment quand vous avez besoin d’utilitaires one-shot pour des tasks trop compliquées pour être du make(1) ou du sh(1)?

Pareil pour mon grand-père, ma mère m'a appelé hier matin pour me prévenir qu'ils avaient arrêté les soins

Python

 
Pareil pour mon grand-père, ma mère m'a appelé hier matin pour me prévenir qu'ils avaient arrêté les soins

Question pour les vieux pervers qui utilisent des makefiles pour leur automatisation (genre much ou harko): vous gérez ça comment quand vous avez besoin d’utilitaires one-shot pour des tasks trop compliquées pour être du make(1) ou du sh(1)?

Non mais genre spécifiquement: comment ces sous-scripts sont organisés et appelés, où ils sont rangés, etc…

Ca manque de contexte. Il n'y a pas une seule réponse possible.

La coutume linux c'est pas simplement d'augmenter ton PATH avec le dossier de tes outils ? (et/ou de les déployer dans un /usr/local ou /opt quelconque) Et après make peut les appeler pis basta.

Enfin plutôt: pourquoi on achèterait un NFT alors qu'on pourrait avoir l'original sur ses murs.

je soupçonne que certains acheteurs ne se déplacent même pas pour aller chercher les originaux.

Les “outils” en question c’est pas des trucs qui sortent de binutils ou quoi, ce sont des morceaux de tâches qui rentrent pas (décemment[0]) dans un makefile, genre aller appeler des APIs externes, ou parser des fichiers toml ou json ou xml.

[0] genre techniquement ça pourrait probablement être fait avec une combinaison natassique de curl, jq, et je sais pas quoi pour le xml et le toml, mais je vais pas faire ça.

Les “outils” en question c’est pas des trucs qui sortent de binutils ou quoi, ce sont des morceaux de tâches qui rentrent pas (décemment[0]) dans un makefile, genre aller appeler des APIs externes, ou parser des fichiers toml ou json ou xml.
 
[0] genre techniquement ça pourrait probablement être fait avec une combinaison natassique de curl, jq, et je sais pas quoi pour le xml et le toml, mais je vais pas faire ça.

Pour l'art classique ou pour les NFT ? Parce que pour les NFT il n'y a aucun original à aller chercher.

Question plus légère :
Avec Plex pro est ce que je peux streamer depuis mon n'as sur mon réseau local ?
Pour que loulou puisse accéder aux films

Question plus légère :
Avec Plex pro est ce que je peux streamer depuis mon n'as sur mon réseau local ?
Pour que loulou puisse accéder aux films

Ça c’est au moins un problème qu’on a plus.

Question plus légère :
Avec Plex pro est ce que je peux streamer depuis mon n'as sur mon réseau local ?
Pour que loulou puisse accéder aux films

Je ne te suis pas. Un makefile peut appeler n'importe quel outil externe, et sous linux un outil externe = n'importe quel binaire/shell script/python script/java/brol, aka n'importe quoi qui se chmod+x.

Ca me semble être un use case parfait pour du Python, ton truc. Après, vu que ça n'a pas l'air très défini, je ne me poserais pas trop de questions, je commencerais par un prototype, et les itérations viendront avec l'expression des besoins.

comment ces sous-scripts sont organisés et appelés, où ils sont rangés, etc…

Dans ces conditions là est-ce que tu peux expliciter un exemple de trucs qui ne "rentrent pas dans un makefile"   Pour moi on y met ce qu'on veut (pareil pour un Jenkins quoi, tant que ça peut s'appeler...), j'ai déja vu des makefile qui lancent des jobs d'impression, qui déploient côté serveur à coup de rsync, etc

Donc comment est-ce que les gens qui ont besoin de sheller à des utilitaires custom organisent généralement ça. Je présume que c’est pas vomi dans le même répertoire que le makefile au petit bonheur la chance (d’ailleurs comment est-ce que make bricole son path?), est-ce qu’il y a des conventions d’organisation?

On a une distribution custom dans /usr/local/${COMPANY_NAME}/{bin,doc,etc,lib} et les outils maisons bossent en général dans un tmp folder dans lequel ils unpack tout ce dont ils ont besoin le temps du process.

ces popups existent justement parce que l'UE les a rendues obligatoires via la GDPR

1. Non.
 
2. C’est pas parce-que le besoin est légitime (ce qu’il n’est souvent pas) que l’implémentation est légale.
 
Pour (2), l’UE est pas fan du foutage de gueule et des “dark patterns”, et chiée de ces popups en sont bourrées.

Ça c’est au moins un problème qu’on a plus.

Bref, ils ont raison et c'est plus moi qui ait eu les mauvaises expériences, ou ils sont encore jeunes & naïfs ?
 

Question philo dev, parce que je me "bas" (sans violence) avec deux de mes devs sur un point, et du coup je veux savoir si c'est moi qui suis à l'ouest ou pas, ayant un peu de mal à les convaincre. Notre point de divergence est sur la "factorisation", ou plutôt le découpage en "fonctions" et "sous fonctions". Globalement ils ont une approche un peu "extrême", et voudraient mettre en place des règles type "pas de fonction de plus de X lignes" (X étant relativement faible, genre 10 ou 15 - on est en Python ou TS- ), interdiction du copier/coller, "on va sortir ça dans une fonction parce qu'on en aura peut être besoin plus tard", "on va encapsuler tel appel à telle lib" etc... Bon je caricature un poil la position, mais vous voyez l'idée.

De mon coté, j'ai une position plus... nuancée sur la question et plus une approche en mode "ça dépend" (plutôt que des guidelines super strict). Contrairement j'ai l'impression aux deux devs en question, je pars déjà du principe que créer une fonction c'est pas "gratuit", ça a un "coût" (je parle pas en terme de performance): ça implique de créer une nouvelle "interface" (au sens large du terme), et faire des bonnes interfaces, c'est compliqué. Rien que le naming de la fonction, de quels paramètres tu prends et leurs noms également, ce que tu renvoies en retour, comment tu gères les éventuelles erreurs etc... C'est loin d'être toujours simple et si à la relecture le dev doit systématiquement aller lire le code de la sous fonction pour comprendre ce qu'il se passe... Bin t'as pas gagné grand chose, à part une indirection de plus.

Alors oui, en théorie le dev est censé y réfléchir, t'as la review qui est censée aussi catcher ce genre de problèmes... Sauf que dans mon expérience, c'est en pratique loin d'être toujours évident, ne serait-ce que parce que y a des choix (de naming par exemple) dont tu t'aperçois qu'ils sont "mauvais" que plusieurs mois/années plus tard des fois, parce qu'ils entraînent une confusion avec un autre concept par exemple. Vous allez me dire que dans ce cas il faut refactorer et renommer ta fonction/paramètre pour ajuster, certes...mais qui ici a bossé avec un code "pro" sans aucune dette technique ?

Bref, ils ont raison et c'est plus moi qui ait eu les mauvaises expériences, ou ils sont encore jeunes & naïfs ?

Mais ça c’est plus pour les trucs globaux sur toute la boite no? Si t’as besoin d’un truc compliqué pour un projet en particulier, ou bien c’est un projet que vous publiez OSS (imaginons que vous zopen sorcier des trucs) c’est aussi déployé sur le truc global de la boite?

Question philo dev, parce que je me "bas" (sans violence) avec deux de mes devs sur un point, et du coup je veux savoir si c'est moi qui suis à l'ouest ou pas, ayant un peu de mal à les convaincre. Notre point de divergence est sur la "factorisation", ou plutôt le découpage en "fonctions" et "sous fonctions". Globalement ils ont une approche un peu "extrême", et voudraient mettre en place des règles type "pas de fonction de plus de X lignes" (X étant relativement faible, genre 10 ou 15 - on est en Python ou TS- ), interdiction du copier/coller, "on va sortir ça dans une fonction parce qu'on en aura peut être besoin plus tard", "on va encapsuler tel appel à telle lib" etc... Bon je caricature un poil la position, mais vous voyez l'idée.
 
De mon coté, j'ai une position plus... nuancée sur la question et plus une approche en mode "ça dépend" (plutôt que des guidelines super strict). Contrairement j'ai l'impression aux deux devs en question, je pars déjà du principe que créer une fonction c'est pas "gratuit", ça a un "coût" (je parle pas en terme de performance): ça implique de créer une nouvelle "interface" (au sens large du terme), et faire des bonnes interfaces, c'est compliqué. Rien que le naming de la fonction, de quels paramètres tu prends et leurs noms également, ce que tu renvoies en retour, comment tu gères les éventuelles erreurs etc... C'est loin d'être toujours simple et si à la relecture le dev doit systématiquement aller lire le code de la sous fonction pour comprendre ce qu'il se passe... Bin t'as pas gagné grand chose, à part une indirection de plus.
 
Alors oui, en théorie le dev est censé y réfléchir, t'as la review qui est censée aussi catcher ce genre de problèmes... Sauf que dans mon expérience, c'est en pratique loin d'être toujours évident, ne serait-ce que parce que y a des choix (de naming par exemple) dont tu t'aperçois qu'ils sont "mauvais" que plusieurs mois/années plus tard des fois, parce qu'ils entraînent une confusion avec un autre concept par exemple. Vous allez me dire que dans ce cas il faut refactorer et renommer ta fonction/paramètre pour ajuster, certes...mais qui ici a bossé avec un code "pro" sans aucune dette technique ?
 
Bref, ils ont raison et c'est plus moi qui ait eu les mauvaises expériences, ou ils sont encore jeunes & naïfs ?
 

Question philo dev, parce que je me "bas" (sans violence) avec deux de mes devs sur un point, et du coup je veux savoir si c'est moi qui suis à l'ouest ou pas, ayant un peu de mal à les convaincre. Notre point de divergence est sur la "factorisation", ou plutôt le découpage en "fonctions" et "sous fonctions". Globalement ils ont une approche un peu "extrême", et voudraient mettre en place des règles type "pas de fonction de plus de X lignes" (X étant relativement faible, genre 10 ou 15 - on est en Python ou TS- ), interdiction du copier/coller, "on va sortir ça dans une fonction parce qu'on en aura peut être besoin plus tard", "on va encapsuler tel appel à telle lib" etc... Bon je caricature un poil la position, mais vous voyez l'idée.
 
De mon coté, j'ai une position plus... nuancée sur la question et plus une approche en mode "ça dépend" (plutôt que des guidelines super strict). Contrairement j'ai l'impression aux deux devs en question, je pars déjà du principe que créer une fonction c'est pas "gratuit", ça a un "coût" (je parle pas en terme de performance): ça implique de créer une nouvelle "interface" (au sens large du terme), et faire des bonnes interfaces, c'est compliqué. Rien que le naming de la fonction, de quels paramètres tu prends et leurs noms également, ce que tu renvoies en retour, comment tu gères les éventuelles erreurs etc... C'est loin d'être toujours simple et si à la relecture le dev doit systématiquement aller lire le code de la sous fonction pour comprendre ce qu'il se passe... Bin t'as pas gagné grand chose, à part une indirection de plus.
 
Alors oui, en théorie le dev est censé y réfléchir, t'as la review qui est censée aussi catcher ce genre de problèmes... Sauf que dans mon expérience, c'est en pratique loin d'être toujours évident, ne serait-ce que parce que y a des choix (de naming par exemple) dont tu t'aperçois qu'ils sont "mauvais" que plusieurs mois/années plus tard des fois, parce qu'ils entraînent une confusion avec un autre concept par exemple. Vous allez me dire que dans ce cas il faut refactorer et renommer ta fonction/paramètre pour ajuster, certes...mais qui ici a bossé avec un code "pro" sans aucune dette technique ?
 
Bref, ils ont raison et c'est plus moi qui ait eu les mauvaises expériences, ou ils sont encore jeunes & naïfs ?

Question philo dev, parce que je me "bas" (sans violence) avec deux de mes devs sur un point, et du coup je veux savoir si c'est moi qui suis à l'ouest ou pas, ayant un peu de mal à les convaincre. Notre point de divergence est sur la "factorisation", ou plutôt le découpage en "fonctions" et "sous fonctions". Globalement ils ont une approche un peu "extrême", et voudraient mettre en place des règles type "pas de fonction de plus de X lignes" (X étant relativement faible, genre 10 ou 15 - on est en Python ou TS- ), interdiction du copier/coller, "on va sortir ça dans une fonction parce qu'on en aura peut être besoin plus tard", "on va encapsuler tel appel à telle lib" etc... Bon je caricature un poil la position, mais vous voyez l'idée.

Il n'y a pas de projet qui ne finira pas versionné et partagé avec un ou plusieurs autres dev à un moment ou un autre. Donc les outils dont ton projet dépend doivent rejoindre un dépôt binaire commun et être facilement 'déployable' localement chez tout un chacun.

Il est parti faire ça, il a tout extrait dans des helpers, et c’était également illisible, parce que c’était tellement plein de helpers que t’arrêtais pas de sauter d’un bout de code à l’autre pour essayer de comprendre ce qui se passe.
 
Et sa conclusion est la même que la tienne
 
Après c’est pas facile à faire, et il y a beaucoup de “taste” qui est impliqué.

Mais c’est pas possible vous êtes des poissons rouges

Pas besoin d’un truc pro, Plex tout court le fait ?

Chandler Carruth

Genre le répertoire du projet?

Tu récupères un projet OSS, tu t’attends à devoir aller télécharger tous les scripts liés séparément?