barmic 🦦 a écrit 5946 commentaires

A contrario je n'ai pas l'impression que Java ait été pensé mais que c'est plus un mille-feuille résultats d'années de baston entre entreprises qui veulent rajouter leur truc à eux par dessus. Et dans ce cas la faire du bon java c'est savoir faire le tri dans tout ce bordel.

Je ne pense pas que ça vienne de ça. Java a 20 ans et essai de garder la compatibilité la plus longue possible. Tu retrouve donc des API qui ont été pensées à divers moments entre le milieu des années 90 et aujourd'hui. Il me semble que python hésite moins à casser la compatibilité (je crois que ça a été surtout le cas sur la branche 2 et au passage à python 3).

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

Comment est-ce que cette conclusion peut intégrer le fait que j'ai décidé d'appeler quelqu'un ce soir par exemple ? Il y a pleins de décision/choix que l'on prend des heures/jours/mois avant leur exécution.

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

Je pense que ça n'est pas du tout le cas. D'une part je suis toujours septique quand on invoque la richesse des langage. Qu'étant qu'un en France, on sait écrire des encyclopédies tout de même. Ça ne représente pas une difficulté insoutenable. Le français a eu ses lettres de noblesse en tant que langue diplomatique. C'est qu'il doit bien être possible de s'en servir sans créer de guerre. Et si vraiment c'était si difficile, c'est une langue vivante on la fait évoluer donc les locuteurs de ses dernières décennies auraient pu la faire tendre vers autre chose. Bref je ne crois pas que notre langue soit handicapée.

Je pense que c'est plutôt une question de culture. Tu peux trouver des groupes francophones qui ne se mettent jamais sur la gueule et qui ne parlent que de fond. Mieux encore ils peuvent accepter des désaccords tout en restant bons amis. À mon avis il faut rapprocher ça d'une culture bien française assez égocentrique pour parler de joute et de faire avancer son point de vue (tu en as des tas d'exemples sur cette page) au lieu de voir le débat comme un sujet a faire avancer et qui est enrichi par tous les participants (c'est un choix de considérer l'autre comme un détracteur). Je suis le premier à ne pas respecter ça, l'idée n'est pas de montrer du doigt des gens.

Marina Rollman avait fait une chronique sur la conversation à la française. Ça se transcrit très mal sur internet. L'écrit perd le non verbal, l'asynchrone fait que l'ambiance n'aide pas, il y a des différences de ressenti entre les gens (certains se sentent prochent alors que l'autre non).

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

Tu as l'air de mal prendre la question ? Ça me parait pertinent pour savoir si on veut se lancer, non ?

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

Alors pour des raisons historiques. On peut voir les SMS à la base plus comme le ICMP de SS7 que comme un protocole de mail. Il y a énormément d'inertie sur ses stack.

Ensuite pour IMAP et SMTP, même à changer ça ne serait probablement pas une bonne idée. Des protocoles en mode connectés, avec de gros volumes d'échange (format texte avec beaucoup de données et de méta données) et plusieurs aller-retour pour faire chaque étape,…

J'ai pas l'impression que ça corresponde au cas d'usage du SMS.

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

Il doit exister quelques cas surtout si ça inclut des assets et des scripts de déploiement voir des données. Mais l'argument, j'ai vu une appli comme ça en langage X donc je préfère le langage Y ne me paraît pas très solide.

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

Mais imagine le cas d'une famille où tout le monde stocke n'importe où au petit bonheur. Tu te vois expliquer qu'il faut stocker les photos ici et les vidéo là et les fichier ici ?

Tu exagère. D'une part tu décris quelque chose de plus complexe que ce que moi j'ai décris. D'autre part c'est automatisé dans l'énorme majorité des cas. Donc non ça n'est même pas une question de connaître une règle et de s'y tenir, mais d'avoir mis en place une règle et de l'oublier.

Tu peux aussi tenter le coup dans une entreprise : dans mon entreprise, on avait le même principe que toi (un disque réseau pour les fichiers importants, un répertoire local pour les fichiers temporaires, etc.). Au final tu as toujours des utilisateurs qui râlent car ils ont perdu des semaines de travail car ils ont pas stocké au bon endroit.

Pareil tu exagère, mon setup ne permet pas que cela se produise (ou alors il faut supprimer ton travail et t'en rendre compte plus de 2 semaines après).

Si le logiciel doit être au service de l'utilisateur dépenser des centaines d'euros et des megawatt pour éviter à l'utilisateur une étape de formation est un non sens dans le cadre du travail. Il faut que les règles fasses du sens, mais passer son temps à gérer des Tio de données pour rien n'est bon pour personne¹. Après ça peut être de leur expliquer qu'on va bien tout sauvegarder, mais que du coup ils ont 20Gio de quota sur leur machine.

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

Ok je n'avais pas compris que c'était incrémental cependant :

La plupart du temps, le méchanisme de sauvegarde les ignore car elles n'ont pas changé (sauvegarde incrémentale).

Quel est le moment où il y a une bonne raison que ça arrive ? À mon avis aucun.

Personnellement ce genre de sauvegarde je le gère séparément. Je ne fais qu'une détection des fichiers, je ne cherche pas à regarder leur contenu. Donc rsync en lui disant bien de ne jamais supprimer de fichier, il crée juste de nouveau, il ne met pas à jour un fichier existant. Distant génération d'un index de checksum (et son contrôle avec le précédent) et d'une archive par2. C'est à la fois très simple et très fiable.

c'est plus compliqué pour y accéder

Tu mélange les besoin. La sauvegarde et la mise à disposition sont 2 choses différentes. La sauvegarde ne s'intéresse à l'accès que pour réduire le temps de recovery. L'accès normal aux données n'a rien à voir. Justement si ton disque explose tu n'a probablement pas besoin que ces données soient les premières restaurées. Si tu sais qu'elles sont sauves tu peux te permettre d'attendre un peu je pense. Alors que le fichier sur le quel tu as travaillé 8h hier, tu as besoin de le récupérer rapidement.

Déjà la sauvegarde c'est pénible, donc le but c'est de rendre le truc le plus simple et automatisé possible.

Segmenter ses sauvegardes simplifie énormément tes sauvegardes car tu utilise les critères qui conviennent pour chaque données. Chercher à sauvegarder de la même façon des fichiers que tu veux garder à vie et des fichiers qui n'ont plus aucun intérêt dans 6 mois rend vraiment les choses plus difficile à gérer.

---

Ce sera peut être plus clair avec un exemple.

Catégories de données

Moi je sépare mes données en 3 groupes :

• les données froides : ce sont les photos, vidéos et quelques documents
  • elles ne vivent pas
  • elles ont une durée de rétention infini
  • elles représentent un volume important au final (pour moi)
  • je n'y accède que très peu, je n'ai pas besoin d'y accéder tous les jours
• les données chaudes : qui sont ce sur quoi je travail tous les jours
  • elles bougent continuellement
  • je n'ai pas besoin d'une rétention très grande (j'ai pris 15 jours, mais je pourrais ne les garder que 7)
  • elles sont assez peu volumineuses au final
• les données que j'accepte de perdre : tout un tas de trucs dont je me fou, je peux les retrouver

Méthodes de sauvegarde

Pour les premières c'est un rsync+checksum+par2. Je ne l'ai pas décri t tout à l'heure, mais je roll le par2. Une fois que j'ai construit le nouveau et que je sais que les données dedans sont cohérente je détruis l'ancien.

Pour le second j'utilise tarsnap, mais grosso modo je pourrais utiliser plus ou moins n'importe quelle solution. Limiter les volumes ici me permet d'alléger les sauvegardes, c'est particulièrement intéressant quand tu paie comme moi mais c'est toujours utile, même chez toi sur ton réseau local.

Pour les troisième OSEF.

À l'usage

Les première ne sont pas stockées sur mon ordinateur local, mais uniquement sur un VPC OVH, elles sont accessibles en web (j'ai un moteur de galerie statique dont j'ai oublié le nom). C'est depuis le serveur quelles sont sauvegardées. C'est utile surtout pour pouvoir envoyer des données directement depuis mon téléphone et voir mes données aussi depuis ma tv ou une tablette. Ça ne m'embête pas de ne pas pouvoir y accéder hors ligne, sinon j'en ferais une synchro sur un disque local périodiquement (aucune notion de backup là dedans c'est juste une copie donc rien de complexe ou autre juste besoin d'un rsync croné).

Les deuxièmes c'est mon dossier home à l'exception de quelques exceptions (mon dossier de téléchargement, le cache des applications et quelques trucs comme ça).

Les troisième c'est le reste.

Au final ça ne me paraît pas aussi compliqué que tu semble le penser. En tout cas je vis bien avec (et c'est l'essentiel). Ça m'a demandé un peu d'outillage pour mes données long terme, mais ça me simplifie tellement la vie je trouve.

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

C'est dommage de réécrire toutes les semaines ces données, non ? Ça augmente le risque sans en avoir d'intérêt particulier (et potentiellement ça prend de la place, du temps pour les resauvegarder,…).

Idem pour des vieux fichiers (bulletin de paie par exemple) que je ne regarde jamais mais dont on peut avoir besoin.

Pour des données comme ça, au lieu de multiplier les itérations de sauvegarde, utiliser quelque chose comme par2 me parait plus approprié.

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

C'est bizarre, moi je vois un journal dont le sujet est la perte de données dû à des erreurs silencieuses de disque.

D'ailleurs cette erreur a eu lieu sur le client de sauvegarde, mais ça peut se produire sur le serveur de sauvegarde (joie et félicité en perspective).

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

Je ne comprends pas tout. Un disque que tu sauvegarde régulièrement a beaucoup d'erreurs, mais c'est silencieux ? Si tu te sers de ses données tu devrais voir le problème, non ?

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

Je ne sais pas la difficulté que rencontre les profs de collèges sur ce point mais, pour ma part, les premiers algorithmes que j'ai appris étant enfant sont hautement récursifs et totalement fonctionnels dans leurs principes, et il en est de même de tous les écoliers de France depuis des décennies. Je veux parler des algorithmes d'addition et de multiplication avec retenue, ainsi que celui de la division euclidienne (celui où l'on pose la division). Tu as peut être oublié ce que tu faisais étant enfant à l'école primaire.

Je ne vais reprendre qu'une partie car il me semble que c'est le nœud de notre désaccord. Appliquer une recette n'a aucun rapport avec en comprendre le fondement (surtout que ton exemple est généralement présenté comme itératif et non fonctionnel). Ce n'est pas parce qu'on a vu un objet tomber qu'on comprends la relativité générale.

Réellement tu compare utiliser une méthode dans un cas précis qui t'a était dicté et en comprendre suffisamment sa mécanique pour la réutiliser. Savoir faire cette addition sur les entiers va devoir être réappris pour l'appliquer à une représentation binaire, octale ou hexadécimale des nombres, pourtant l'algo est le même. Ça montre bien qu'il n'y a pas de compréhension de cet algo il est appliquer tel quel. C'est comme mélanger la farine et les œufs sans savoir la chimie qui se cache derrière.

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

Parle pour toi, l'impératif rempli d'effets de bords je n'y comprends strictement rien dès que le programme devient trop gros. C'est un paradigme qui m'est totalement incompréhensible.

C'est comme ça que fonctionne un ordinateur et les cours de programmation commencent tous par expliquer le fonctionnement d'un ordinateur. La relation entre ce que tu écris dans ton code et ce qui est exécuté par la machine est largement plus simple que ce qu'implique le fonctionnel.

Les débutants ne commencent pas par faire de grands programmes. Comme dans toutes choses tu commence simple et tu progresse.

Qu'est ce qu'il y a de compliqué là-dedans ? Prenons le reduce (ou fold) : c'est un peu comme une boucle de rétroaction.

Je ne sais pas quoi répondre. On est pas dans le même monde.

Comment fonctionne-t-il ? C'est simple

Pour faire un type d'opération tu as ressenti le besoin de parler de boucle de rétroaction (concept de mécanique sophistiqué). Son implémentation simple implique de la récursivité. Tu verrais la difficulté pour les prof de collèges pour expliquer la récursivité aux élèves…

Peut être que l'on ne comprends pas le mot simple de la même façon. Je parle de facilité d'accès et pas de simplicité algorithmique. La programmation fonctionnel permet d'obtenir des

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

Mon dispositif fait déjà de la sauvegarde incrémentale que ça soit avec mon script ou avec unison, mais vu le volume de données aujourd'hui je ne peux guère remonter qu'à une semaine.

Tu produit tant de données ? Ou tu roll tant de données que ça par semaine ?

Quand on commence à avoir beaucoup de données (beaucoup c'est à l'appréciation de chacun, mais je pense que c'est quand tu commence à te demander si tu a la place pour faire ce que tu veux), il est important de segmenter tes données en te demandant combien de temps tu souhaite les garder, quelle fréquence tu les met à jour, quel volume ça représente,…

Personnellement je n'applique pas du tout le même backup aux données « vivantes » de mon dossier personnel et aux données que je souhaite garder aussi longtemps que possible avec mes photos et vidéos. Je ne sauvegarde pas de la même façon, je n'y accède pas de la même façon, etc.

Ça peut grandement aider et simplifier.

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

Ben non. Tu peux pas dire « ben fais exactement ce que fais le leader et on en parle ». Ça ne fonctionne pas comme ça.

• la marche est beaucoup trop haute, il faut choisir ce qu'on fait maintenant pas à terme, ça doit être dirigé par les besoins
• on ne crée pas de l'innovation en reproduisant exactement ce qui est déjà fait. Les 5 ans que tu aura dépensé (à perte) pour rejoindre le leader, il aura passé 5 ans à prendre de l'avance et même si tu le rejoins quel intérêt de venir vers toi si tu n'es qu'une copie

Tu remarquera par exemple que GCP, AWS et Azure ont des approches différentes. Azure et l'écosystème firebase par exemple sont à un très haut niveau de valeur ajoutée pour des besoins particulier Azure pour de l'IoT et Firebase pour du web/mobile. Il y a une tentative en Europe pour créer dans la même orientation mais pour l'industriel car c'est un domaine pas encore beaucoup passé au cloud. Bien sûr il est possible de tout faire avec AWS, mais AWS pour de l'IoT à coté d'Azure fais figure de simple hébergeur à l'ancienne.

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

Tu montre des expressions d'une ligne. En une ligne quasiment tout langage qui n'est pas volontairement abscons sera simple.

Mais il est bien plus intuitif de décrire un programme de manière impérative, il est aussi bien plus confortable d'avoir un accès direct aux effets de bords.

Qui y a-t-il de compliquer à comprendre dans tout cela ?

Avoir le bon niveau d'abstraction est quelque chose de véritablement complexe. Ça impact la lisibilité, la compréhension et l'évolutivité du code sachant que lisibilité et compréhension sont des notions tout à fait subjective et que ce ne sera pas la même chose d'un développeur à l'autre. Affirmer que l'abstraction c'est simple c'est comme dire que l'escalade c'est facile, il suffit d'attraper des prises et de se hisser dessus. Il y a beaucoup de subtilité derrière cette abstraction et non ça n'est pas simple.

Autre chose manipuler des listes ne demande pas de notions particulières, là où la programmation fonctionnelle va te demander de comprendre des notions comme la reduction, fold, zip,… C'est élégant, mais c'est des notions plus sophistiquées.

Enfin l'impératif va simplifier grandement le print debugging et l'élaboration incrémentale. Tu ne peux pas découper un code où tu le veux en fonctionnel ou plus exactement les primitives sont de plus haut niveau donc tu ne peux pas les étudier pas à pas. Bien sûr c'est possible, mais tu va avoir besoin de bien maitriser ce que tu fais pour pouvoir faire quelque chose qui intéresse surtout les débutants.

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

La réalité est que construire cette independence cloud doit se faire d'abord, afin qu'un cloud européen soit non pas équivalent mais proche des capacités US, afin que l'effort de construire dessus puisse être justifiable.

C'est exactement ce qui a déjà été tenté, mais ça ne marche pas comme ça. Ce n'est pas comme ça que les choses fonctionnent. Il faut diriger par les besoins sinon tu crée un truc hors sol. Sur un modèle économique très dangereux (dépenser ton capital avant de dégager des revenus) et tu te plante.

Non ce qu'il faut c'est investir dans des projets. L'État peut très bien le faire. Sur ce projet là ou sur de plus petits. Mais ça ne se construit pas tout seul.

Mais pour ça il faut comprendre l'enjeu et l'état du marché. Quand on pense que c'est déjà perdu, il est évident qu'on imagine pas créer quelque chose. Alors que tout montre que le marché est encore petit et qu'il y a encore des perspectives de croissance importantes. Tous les acteurs du cloud sont en croissance, c'est qu'il y a encore de la place.

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

Je n'ai jamais vu ce genre de problème et s'il arrive tu peux annuler le merge ajouter un commit de auto reindent et faire ton merge. Je fais peux de python, mais sur du yaml, j'ai déjà souffert. Les exemples qui peuvent devenir bien relou, c'est de merger des changements d'indentation. En yaml c'est pire, mais de ce que je m'en suis servi ça m'a déjà un peu embêté.

Tu peux même le détecter avant si tu préfère, tu peux aussi refuser le commit si tu le détecte ou avoir un linter qui rapport ça ou ajouter un hook git et le problème est probablement plus le non respect des règles parce que python ne va pas non plus apprécier des indentations inconsistantes.

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

Comment sont gérés les pertes ? Ce qui ne peux pas être reproduit dans tuleap ?

Jira (que je n'utilise plus depuis pas mal de temps) et surtout intéressant s'il est beaucoup customisé :

• la création de rapport (et de mon souvenir c'est siffisament chiant à faire pour ne pas trop vouloir y revenir)
• création workflow avec tout ce qui va avec comme gestion des rôles et gestion de formulaires pour chaque étapes du workflow
• l'utilisation de divers plugin
• la possibilité de scripter pas mal de chose en groovy (par exemple pour ajouter un champ calculé qui pourra ensuite être pris en compte dans les workflow)

Je me doute que tuleap ne reproduit pas tout (c'est même pas forcément souhaitable).

Est-ce qu'il est possible de :

• faire du dry-run, rollback ou une quelconque manière de revenir en arrière pour s'y retrouver ?
• avoir un listing de tout ce qui n'est pas importé pour pouvoir le gérer d'une manière ou d'une autre ?

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

Un peu plus haut tu as la doc qui explique très bien dans un anglais assez simple pour que même moi je puisse le lire sans trop me prendre la tête. Je te met le lien vers l'endroit où il en est question PEP 635: Motivation.

Je ne suis pas familier avec le parcourt d'AST en python, mais ça peut servir quand tu utilise un tuple comme objet ad-hoc à le déstructurer de manière plus concise et lisible.

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

C'est pour faire de la déconstruction de ce qui est décris dans le PEP au dessus. Tu peux matcher les valeurs d'une liste ou déconstruire un objet :

a=["foo", "bar"]
match a:
    case ["foo", param]:
        print(param)

match event.get():
    case Click(position=(x, y)):
        handle_click_at(x, y)

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

La rupture en question c'est une partie de la bibliothèque standard qui a était déplacée dans une bibliothèque. Tu ajoute cette bibliothèque dans ton classpath et sans même avoir à rebuild le code.

Par contre JavaEEJakarta EE a/va bien péter la compatibilité et ça ça va être couteux

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

1) Le pattern matching n'est pas juste un switch.

Je le sais bien, mais à l'époque ça complexifiait le langage. Le pattern matchin est bien plus complexe.

2) La syntaxe Python permet (dans certains cas) d'introduire des nouveaux mots-clefs sans casser l'utilisation du mot en question dans des noms de variables existants, car le contexte est différent. Ex: on peut introduire la syntaxe match: sans casser, re.match(…) ou une variable qui s'appelerait match.

C'est l'utilisation des soft keyword ? Je ne connaissais pas et j'ai beaucoup de mal à trouver de la doc dessus, mais je comprends l'idée. Ça me parait bizarre de gérer case et case différemment de tous les autres mots clefs de structure de contrôle, par contre.

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

Par contre pourquoi Ruby n'a t il pas connu la même popularité ?

Parce que python.

La progression de python en big data/data science (c'est assez générique je parle de numpy à sparc en passant par panda et les notebooks) et dans l'enseignement lui ont donné un coup de projecteur qui limite beaucoup la place pour ses alternatives.

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

Enfin, une interrogation similaire ressort de l'index TIOBE : pourquoi Java, qui semble universellement décrié, a t'il toujours eu un classement aussi élevé ?

Tu confond la bulle qui t’entoure avec l'univers ;)

Java est un langage qui trouve très bien sa place en programmation de service :

• l'indépendance vis à vis du système d'exploitation (dans le langage, le binaire et le packaging) sont intéressant pour développer depuis un système d'exploitation
• son temps de démarrage et de chauffe ont moins d'importance que la qualité du code généré par le JIT et du garbage collector
• un écosystème très complet et très mature avec des standardisations qui apportent de la valeur. Je ne dit pas quelles en apportent toutes, mais quelque chose comme JDBC soit une API pour interroger des bases de données SQL, non limitant, avec une implémentation pour toutes les bases de données, etc c'est vraiment agréable
• un outillage vraiment très cool, l'IDE peut donner énormément d'information, des outils d'analyse statiques comme sonarqube qui font un super job
• le langage évolue dans la bonne direction, pour remplacer quelque chose d'en place il faut :
  • que tu apporte une valeur suffisante pour compenser la migration
  • que tu tes chances d'être pérenne pour éviter un blocage dans quelques années
  • que la valeur que tu apporte se maintienne dans le temps, si la solution initiale t'aura rattrapée dans 3 ans faire une migration qui prend 2 ans, ne vaut probablement pas le coût

Évidement il y a d'autres raisons bien plus dommage comme l'inertie ou le fait qu'on ne reprochera pas à un décideur de partir sur java que sur le dernier langage sorti le week-end dernier.

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