barmic 🦦 a écrit 5211 commentaires

Tu crois sincèrement ce que tu dis ?

Je suis entrain de faire traiter quelques millions de document avec elasticsearch et kibana ce qui donne des résultats que tu ne peux même pas envisager avec ce que tu viens de décrire, mais faut être conscient que les gens peuvent avoir des points de vu et des connaissances différentes des tiennes. En principe on acquière cette capacité vers 3 ou 4 ans. Dans les tech, c'est plus vers 35~40 ans en moyenne.

mais bon si les commerciaux savait utiliser SQL ils ne seraient plus commerciaux ;)

Et si un technos s'intéressait au point de vu des utilisateurs il serait pas techos, mais testeur qualité.

Du coup avec nos outils Libre

Il n'y a aucune raison technique que quelque chose de simple avec excel demande de maîtriser 3 à 4 langages turing complet pour le faire en plus moche. Vraiment aucune.

Et le "nos outils Libre" (avec un grand L majuscule monsieur) LibO, gnumeric et consor ça n'est pas libre ? Qu'est-ce qu'il ne faut pas lire même pour un vendredi…

Reste à cheval sur tes principes sans chercher à comprendre les besoins, mais ne te plains pas que les autres ne se servent pas de tes outils. Restons éternels incompris (sans chercher à comprendre les besoins)

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

D'ailleurs des recherches sont toujours effectuées dans ce domaine, tout intéret n'est pas perdu. Quoique ? Ce n'est plus un thème majeur.

Il continue à y avoir des travaux dessus. Mais pour ce qui prend le plus de place et qui grossi le plus avec le temps il faut un algo avec perte dédié comme les h265 et autres av1. On découle pas mal les formats d'images de ses formats de vidéo, mais jpeg n'a pas dit son dernier mot il me semble.

Pour les compressions généralistes, j'ai l'impression d'avoir surtout vu passer des choses pour accélérer la compression plus que pour la plus compressif. Je pense par exemple à snappy.

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

Ce truc c'est quelques d'aluminium. Même une corde en 7mm va galérer à passer dedans. C'est un porte clef bon moi mon porte clef est un mousqueton d'assurage, mais c'est un autre délire :p

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

SQLite Studio ou DB Browser pour SQLite

Des 2 en regardant rapidement, seul le second cherche des usages sur les platebandes d'excel (tracer des courbes¹, formater l'affichage,…) par contre c'est entregistré dans un fichier projet qui doit pointer sur une base, c'est casse-gueule (d'autant qu'ils ont l'air d'utiliser des chemins depuis la racine).

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

À aucun moment tu ne me contredis. Je rappelle simplement qu’il est possible de concevoir une spécification qui repose sur une autre spécification pour décrire le format des champs, et d’autres spécifications pour décrire tel ou tel type de donnée. On ne compare pas un format comme SQLite à CSV ou ASCII Delimited Text. Là si quelqu’un compare SQLite à CSV ou ASCII Delimited Text, il va avoir des problèmes. CSV ou ASCII Delimited Text c’est le format pour les champs, pas l’ensemble.

Mais ce que je dis c'est que la dépendance est forte. Vraiment très forte. Prendre SGML et se demander si c'est bien ou mal n'a pas de sens. C'est un format qui a des propriétés (dont certaines ne sont pas intrinsèques). Il faut voir si ça convient ou non à ton usage.

Croire que pointer le format de base suffit est un leurre, croire qu'un format est intrinsèquement bon ou mauvais aussi.

Ce fil de discussion tourne autour d’un problème de partie et de tout. Qu’au moins les comparaisons soient faites avec ce qui est comparable !

Les formats ne sont pas vraiment comparables en soit ou alors il s'agit de paraphraser wikipedia. Parce que sinon tu ne peux pas jauger l'expressivité des formats hors c'est le principal intérêt de tout ce qui sort des csv-like.

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

Un tel argumentaire suppose que le JSON généré par un logiciel est immédiatement lu par un autre logiciel, […]

Pas du tout. Il te permet d'utiliser que tu souhaite, même si ce n'est pas un ordre alphabétique tout en te garantissant que ça n'en change pas la sémantique.

Si l'outil de diff utilisé par ton gestionnaire de version te pose problème c'est un autre débat qui peut avoir diverse solution. Le besoin de versionné du json n'est qu'une part très faible de l'usage de json parce que son usage dans l'exécution javascript et en rest le dépasse amplement.

Il faut savoir que maintenir un ordre dans les clefs est réellement quelque chose de couteux et ne répond qu'en partie à la problématique du diff. Faire un formattage précommit ou avoir un outil de diff qui comprend json sera une solution plus complète (ça permet entre autre de gérer les divers indentation non signifiantes).

C'est le même genre d'argument qui pousse à autoriser les virgules trailling pour faire des documents de la forme :

{
  "a": "b",
  "c": "d",

Parce que tu comprend si ajouter un troisième champ fait un diff d'une ligne en plus c'est pas bien.

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

Pour un outil critique a son activité?
Je suis débile de chercher a maîtriser ce que je fais et comment je le fais?

C'est pas parce que beaucoup de monde fais quelque chose que faire autrement est débile.
Il faut être conscient qu'une chose est critique, il faut savoir qu'il peut exister des limites. Aujourd'hui il est tout à fait possible que ton activité repose sur du logiciel sans que tu ne soit connaisseur en la matière.

Et de toute façon, si on utilise le mauvais outil pour une tâche, est-ce normal d'accuser l'outil de ne pas être fait pour, ou d'avoir des limitations dans un usage non prévu?

Je ne sais pas, ça dépend probablement des cas et du reproche. On peut trouver ça débile mais je ne compte le nombre de mousqueton qui ont l'inscription "not for climbing" :

Quand tu tiens un truc comme celui là en main, tu te doute qu'il ne va pas supporter ton poids.

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

Qui utilisent des outils sans en comprendre le rôle et les limitations?

Tout le monde ?

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

Donc tu liste le nom des colonnes ("prix" ce n'est pas "Prix" ou "priX"), que leur ordre est fixé ou non, que vous utilisé une virgule comme séparateur entre les unités et les dixièmes, que le prix est en euro, quel colonnes sont nécessaires ou pas, que tu accepte les commentaires et qu'il s'agit de ligne commençant par le caractère # s'il n'est pas protégé,…

Mais sinon on peut continuer à danser autour de la question et "prendre du recul pour évaluer le besoin dans sa globalité".

C'est pourtant assez simple. Prend ta spec et écris le bout de code pour produire une structure utilisable dans ton code (→ qui ne nécessite plus de se protéger ou de nouvelle étape de parsing) et regarde la liste des hypothèses que tu aura formulée. Chaque hypothèse que tu aura formulée et qui n'est pas explicite dans la spec (soit en le décrivant directement soit en faisant référence à autre chose), c'est un cas d'erreur potentiel.

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

Ben écoute si tu veux bien y passer 3 minutes, je veux bien exemple de spec CSV qui tienne la route pour échanger un simple tableau comme celui-là:
https://sebsauvage.net/wiki/doku.php?id=csv
(hormis le coup des commentaires dans le fichier, là c'est un peu trop tarabiscoté)

Tu n'a pas compris son commentaire. Il ne dis rien de particulier sur csv. Mais il ne parle surtout de spécifier son format et pas d'écrire une RFC sur csv. Donc le boulot ce n'est pas d'écrire tous les cas de l'univers, mais de décrire tes cas. Ça n'a pas de sens de décrire les cas de cette page, on ne pars pas d'un résultat pour renverse une spec, mais on pars d'un besoin. Si tu galère à spécifier ton besoin avec un format donné, ça peut être intéressant de se demander si l'expressivité de format n'est pas un problème pour toi.

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

Bien sûr que c'est lié. Tu as des formats qui peuvent exprimer directement tout cela ça montre bien que ça va avec. Faire l'un sans l'autre c'est ce qui peut mener au problème présenté.

Ne pas systématiquement prendre l'ensemble ça peut mener pas mal de problème et générer de la complexité là où il n'y en a pas besoin.

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

D'ailleurs ce que tu gagne sur cette boucle tu la perds largement dans les 3 boucles de la lecture du fichier

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

Le problème de ton article n'est pas un problème de format, c'est un problème d'échange de données.

Choisir son format avant de savoir ce qu'on va mettre dedans et les propriétés attendues n'a pas de sens.

Sinon c'est du plaisir intellectuel sans chercher de mise en pratique, mais alors il y a des formats plus stimulants qu'utiliser les délimiteurs ascii je trouve.

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

C'est pour cela que j'ai utilisé le module CSV en changeant… la notion de fin de ligne ! Surprenant non ?

J'ai bien compris mais ta documentation argpars parle de csv, c'est trompeur, non ?

Pour la list comprehension, c'est une optimisation à deux sous j'en conviens. J'ai cru lire quelque part qu'une boucle dans une list comprehension est plus rapide qu'une boucle sans. Ce n'est peut-être plus valable avec les dernières versions de Python.

Mais tu créé une liste potentiellement grande. C'est de l'optimisation prématurée je trouve

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

Un périmètre fonctionnel c'est la limite entre ce que fait et ce que ne fait pas un logiciel. Dans le sens ce qui fait parti de son job qui tu préfère.

Peut être que parler de fonctionnel fait penser aux SS2I/ESN, mais ça ne me paraît pas être sale. Tu préfère parler de métier ou tu as un autre terme pour parler de ce qui est non technique dans un logiciel ? Par exemple si tu fais un logiciel de bord le pilotage, c'est le métier ou le fonctionnel, c'est la connaissance non informatique que tu dois inclure dans le logiciel.

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

C'est marrant parce que ton script a peut être les même limite que l'article → des limites du nombre de lignes.

• readlines l'API de csv peut consommer un générateur de ligne, ça éviterait de prendre tout le fichier en mémoire une première fois
• [ws.append(row) for i,row in enumerate(reader)] les list comprehension c'est fait pour construire des listes plus que pour itérer, ici tu construit une liste du nombre de lignes pour rien

Tu parle de ASCII Delimited Text, mais dans ton script tu ne fais référence qu'à csv.

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

Quelle est la longueur maximale de tes lignes ?
Quels données sont nécessaires ou pas ?
Ton format de dates, c'est quoi (avec la précision, la nécessité ou non d'une timezone) ?
Les unités de tes chiffres ? Leur précision ?
L'ordre des colonnes est-il portant ?
Tu as des numéros de téléphone quel formats ?
Tu as des données géographiques ?
Tu as des données binaires ?
Tu as un nombre variable d'adresse par ligne ? Tu les mes dans des colonnes séparées, tu fusionne tout dans une colonne ? Avec quoi comme séparateur ?
…

Encore une fois l'important c'est de se mettre d'accord (ou d'accepter le fait de ne pas se mettre d'accord), le format derrière c'est un détail.

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

Et donc ? Utiliser le format superformat3000 va mécaniquement changer quelque chose à ça ?

Si personne dans la boucle ne s'intéresse à la spécification du format tu n'aura pas mieux. Les DTD peuvent donner des données aussi impossibles à reconstruire qu'un csv.

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

ça marche assez bien mais il y a toujours plusieurs manières de faire.

Faire une regex sur un fichier qu'on ne maitrise pas, sans plus de vérification préalable c'est vraiment plus sujet aux erreurs. Demain les mainteneurs de l'image se basent sur des dépôts qui n'ont que la section main par exemple, ton build va exploser. Moins violent S'ils ajoutent divers dépôts ayant des section contrib et non-free, ton temps de build va augmenter pour rien.

Si vraiment créer un fichier te pose problème (mais séparer ce qui fait parti de l'image de base de ce qui est de ton ajout n'est jamais vraiment une mauvaise idée amha), tu peux ajouter une ligne en fin de fichier.

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

Mais je suis aussi à blâmer: j'ai souvent utilisé Excel ou CSV pour échanger des données alors que je sais pertinemment que c'est mal.

Peut être, peut être pas. Les choses ne sont pas mauvaises ou bonnes en soit. On parle d'échange, le médium n'est qu'un détail. Si possible on retarde son choix. L'important c'est de mettre d'accord l'expéditeur et le destinataire. C'est ça qui fait que ça marche ou pas. Le format ne va pas sauver miraculeusement un projet qui ne fait pas de tests.

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

JSON/xml/autres languages a balises sont plutôt mauvais pour le transfert de données brutes à large échelle.

Tu entends quoi par données brutes ?
C'est quoi ce que tu appel large échelle ?

CSV, c’est une ligne une donnée, donc trivial a streamer, le parseur est très simple à écrire, ça se parallélise très bien

Non ? Une ligne n'est pas forcément une donnée complète. Le parseur est très simple à écrire effectivement (tu lis caractère par caractère et tu maintiens une pile d'état pour gérer les niveaux de protection), mais ça ne se parallélise pas vraiment. Tu es obligé d'avoir déterminé la fin de la donnée précédente pour savoir commence la suivante.

tu sais combien de données t’es censé avoir d’entree de jeu

Je sais pas ce que tu as voulu dire ?

trivial de se rappeler ou tu t’es arrêté.

Ça c'est vrai, tu prends l'offset du début de la dernière donnée que tu as lu.

Tout ça est très avantageux quand il s’agit de faire un dump d’une db et le réimporter dans une autre.

Bof beaucoup évitent je pense que csv est un format trop simple :

• une partie est paramétrable (séparateur, protection,…)
• csv ne permet que de gérer une partie de ton formalisme, tu es obligé de reconstruire un format par dessus

Je pense que c'est pour ça par exemple qu'on voit des exports sous forme de requêtes SQL, c'est vachement plus simple puisque c'est un format qu'ils connaissent déjà, qui a donc tout ce dont ils ont besoin, qui va permettre de gérer des trucs impossibles avec csv (la création d’index, le commit de la transaction,…). J'ai l'impression que les bidouilles csv est plutôt fais par des outils tiers.

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

# ---environnement d'exécution
from debian:10

run apt-get -y update
run sed -i -e 's/main/& contrib non-free/' /etc/apt/sources.list && apt-get update

Il y a un update en trop, mais surtout je trouve cette façon d'ajouter un dépôt assez fragile. Ajouter un fichier dans /etc/apt/sources.list.d me paraît plus fiable.

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

Aucun des GAFAM (ou même ici, DO) ne serait où il en est sans les logiciels Libres et le travail, principalement bénévole, des contributeurs.

Déjà pour Microsoft je suis pas certain que ça s'applique. Ils sont devenu énorme grâce à des logiciels interne. Windows, MS Office et même DOS ne doivent rien au libre de ce que j'en sais.

Mais les GAFAM sont d'énormes contributeurs au libre. Google, Microsoft et Facebook sont vraiment d'énorme contributeurs (en infrastructures fourni, en patch proposés et en techno mise à disposition, la mise en place d'évènement pour développer du libre). Je pense qu'en terme de non redistribution c'est les entreprises un peu plus petites qui sont les moins redistributrices.

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

Tout à fait c'est pour ça qu'on a abandonné la taxe GAFA par exemple.

Vous énoncez des idées de manière hyper partisanes, on plonge allègrement dans les arguments FUD, puis complotistes, puis tous pourris,… en extrapolant à partir de rien ou pas loin. Mentir, se mettre des œillères ne sert jamais la cause que l'on croit défendre. Ce n'est pas en inventant des tares que l'on peu remettre en cause la dominance des GAFA, s'appuyer sur ce qui est parfaitement indéniable suffit.

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

La sanction maximum, on en rediscutera le jour où elle tombera.

Mais… Euh… Comment expliquer ? Elle tombera s'ils ne se mettent pas en conformité c'est comme ça que fonctionne toutes les lois quelque soit le domaine. Comme je l'ai dis, ils peuvent retarder, mitiger, mais pas ignorer.

Pour le reste je laisse les arguments complotistes aux complotistes. Je ne vois pas ce qu'il est possible de répondre à des arguments comme :

Quoiqu'il en soit, le truc pratique avec la corruption, c'est que quand c'est bien fait, ça ne se voit pas. Donc je ne peux pas affirmer que c'est pratiqué ou non par Google.

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