jben a écrit 847 commentaires

Il a été abordé deux points, dans le sujet du journal et dans les commentaires :

• contribuer aux projets libres est formateur et participe à votre réputation, (du moins, complète de manière très intéressante un CV synthéthique),
• faire ses propres projets de réimplémentation permet de comprendre les choses.

Ces deux points ne sont pas exclusifs et ça a été souligné. Mais il y a un point que j'aimerai mettre en avant il faut que les postulants fassent attention à leur réputation publique. Je pense en particulier à tous les codes de projet étudiants (qui sont des réimplémentations de la roue carré, faits dans un but pédagogique, pas dans un but de réécriture/refactoring/whatever), qui ne doivent pas être public. Cela donne une mauvaise image et cela brouille les vrais contributions.

Je suis enseignant-chercheur dans une école d'ingénieur, et même si mon domaine n'est pas de l'info au sens dev, et que ce n'est pas à moi de faire passer ce genre de message en interne, je suis toujours étonné des profils publics des étudiants. Un exemple flagrant, c'est un étudiant ayant un super bon profil technique (en plus d'un bon profil scientifique) qui était présent sur github. Quand on regarde sa page github, on trouve nombre de projets perso ou contributions sur des projets qui ne sont que des projets étudiants dans le cadre des enseignements, et souvent de pietre intérêt générale et de pauvres qualités techniques. Alors que dans le même temps, cet étudiant avait contribué de manière significative à scikit-learn et à sympy (pour ceux qui ne connaissent pas, deux grosses bibliothèques en python scientifique), et ces contributions étaient invisibles et noyées dans la masse des contributions inutiles et bidons sur des projets étudiants.

J'approuve donc le contenu du journal, contribuez sur des gros projets, mais faîtes attention aussi à votre réputation et que ces contributions ne soient pas noyés dans la masse de contributions qui n'en sont pas quand on fait une recherche sur votre nom.

J'avais essayé à l'époque, je me rend compte que miller est beaucoup plus avancé qu'il l'était. Il pourrait correspondre à une grande partie de mes usages. Les deux points principaux qui manquent, c'est pour moi le fait de pouvoir faire des applications de fonction extrèmement complexes (la puissance de python), et les agrégations complexes.

Il est vrai que maintenant, je ne recommencerai pas csvspoon, et que j'utiliserai miller plus quelques scripts.

Mixer les deux outils me parait improbable, ne serait-ce que csvspoon est en python (et utilise intensivement les générateurs pour faire du traitement par flux), qui est fait dans miller directement en C. La base de code me semble complètement imcompatible. Par contre des bonnes idées peuvent passer d'un coté vers l'autre.

En fait, c'est comme cela que je travaillais avant, j'avais une base de donnée pour chaque enseignement qui me suivait pendant tout le semestre. Et c'est rapidement beaucoup contraignant et pas assez flexible. Je devais absolument tout typer avant d'importer, effacer les tables suivant les versions, écrire des scripts python pour faire des calculs complexes… Bref, les jointures se passaient bien, et c'est tout (même pas les agregations, car en fait les opérateur d'agrégation sont très limités en SQL).

Concernant le volume de donnée, la majorité des usages n'est pas du requetage, mais du traitement de l'ensemble des fichiers. Avec csvspoon, les traitements sont faits de manière pas trop stupide (par exemple pour une jointure de deux fichiers de taille n on a un complexité en O(n·log(n)), ce qui est acceptable. Si on veut récupérer une seule donnée, c'est vrai que écrire un query plan serait plus adapté avec des index dans une base de données, mais ce n'est pas mon cas d'usage.

Après, mon cas d'usage, c'est rarement des fichiers à plus de 1000 lignes, mais j'ai déjà traité des données historique d'inscription aux enseignements sur la totalité de l'université, et j'étais à plus de 50 million de lignes, et c'est passé sans problèmes.

À noter, j'ai oublié de le préciser. Autant que possible les données sont traités en flux, c'est à dire qu'elles sont lue au fur et à mesure sur l'input et écrite au fur et à mesure sur l'output. Permettant de traiter des gros volumes de données dans un pipeline de commandes de manière efficace. (Merci au générateurs en python pour cela).

De la chance, de la chance… c'est à définir. Si j'avais trouvé un outil qui me faisait de manière simple les jointures et les agrégations, il est probable que je n'ai jamais écrit une ligne de code. Après, une fois que j'ai commencé, il est vrai que j'ai continué assez fortement.

Concernant la RFC 4180, le parsing du csv est assuré par le module standard csv de python, et donc oui, cette RFC est respectée. Toutefois, actuellement, le seul truc modifiable c'est le délimiter (-d pour l'input, -u pour l'output). Il pourrait être envisageable de mettre d'autres options pour pouvoir changer le comportement du dialect plus précisément, mais j'en ai pas eu besoin.

Un des trucs que je compte faire, c'est de mettre un argument pour l'encoding d'input et d'output. Actuellement c'est celui de la locale utilisé (et c'est très bien par défaut), mais ça serait bien de pouvoir le spécifier (surtout en input). Les SI de l'université nous retournent des fichiers avec un encodage du passé (et j'en ai marre de passer iconv dessus, mais si il n'y avait que ça comme problème au niveau du SI, je serais heureux).

Tout à fait, mais tu ne réponds pas à la question initiale.

Le problème, c'est que pour George_abitbol la compression est très efficace pour tar, et ne l'est pas pour rsync, c'est incohérent. C'est le même source, la même machine de départ, la même machine de destination entre les différents essais, et à moins que la charge CPU change violement, les rapports de performance devraient être les mêmes. Et si la charge externe CPU change violement entre les tests, alors le test est mal conduit. C'est cette incohérence là qui me dérange.

Je suis étonné de ton résultat. J'ai donc voulu tester.

jben@germaine /tmp $ time tar c linux-5.12-rc4 | ssh remote 'tar x' 
0.30user 1.18system 1:31.22elapsed 1%CPU (0avgtext+0avgdata 3696maxresident)k
880inputs+0outputs (7major+264minor)pagefaults 0swaps

jben@germaine /tmp $ time tar cz linux-5.12-rc4 | ssh remote 'tar xz'
22.69user 1.07system 0:22.73elapsed 104%CPU (0avgtext+0avgdata 3532maxresident)k
0inputs+0outputs (0major+550minor)pagefaults 0swaps

jben@germaine /tmp $ time rsync -a linux-5.12-rc4 remote:
1.96user 1.50system 1:26.94elapsed 3%CPU (0avgtext+0avgdata 34996maxresident)k
1043928inputs+0outputs (1major+10494minor)pagefaults 0swaps

jben@germaine /tmp $ time rsync -az linux-5.12-rc4 remote:
18.92user 0.55system 0:20.28elapsed 96%CPU (0avgtext+0avgdata 38012maxresident)k
5128inputs+0outputs (1major+9494minor)pagefaults 0swaps

Bref, moi je trouve (en triant par vitesse) rsync -z > ssh+tar+gz >> rsync > ssh+tar.

Le fait que rsync et ssh+tar soient dans un mouchoir de poche est normal (de même avec les versions compressées), et le fait que je trouve l'un avant l'autre ne me gène pas. Ce qui me gène c'est que tu trouve que la compression ne change rien pour rsync (ce qui peut être le cas si c'est le CPU qui est limitant), mais change beaucoup pour tar (donc le cpu n'est pas limitant).

A-t'on besoin de l'indexation immédiate de nouveaux contenus ? Est-ce que perdre d'indexation immédiate de nouveaux contenu est acceptable ?

Si la réponse à la première question est non ou si la réponse à la seconde question est oui, alors il serait légitime que le no follow et no index soit positionné si la note est inférieure ou égale à k (avec k=5 ou k=10).

Pour les journaux normaux, ce k serait très vite atteint (il suffit d'aller un peu se balader dans l'historique pour voir), pour les journaux problématiques comme celui-là, ils ne seraient jamais indexés.

Une version plus avancée serait de positionner le no follow et no index si (au moins) une des conditions est remplie:
- le journal a moins de 24h et il a une note inférieure ou égale à 5
- le journal a une note négative.

Avec cette version avancée, même si la note grimpe peu (mais ne passe pas dans le négatif), il sera indexé dans les 24h.

Si tu veux mixer le shell et le python, autant utiliser un shell qui nativement supporte le python, xonsh est vraiment génial pour cela.

Attention. Dans la première version, tu n'utilises pas startswith, et en l'occurence ici, c'est startswith qui est lent.

In [1]: some_list = 'setanéstebnsetanustebnésatenastubnestpnesanuastnbtsnastbnstanstbnsteanutsenbstanstbnstaà' * 1000

In [2]: %%timeit
   ...: 
   ...: list_a = []
   ...: list_b = []
   ...: 
   ...: for s in some_list:
   ...:     if s[0] == 'a':
   ...:         list_a.append(s)
   ...:     elif s[0] == 'b':
   ...:         list_b.append(s)
5.55 ms ± 260 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [3]: %%timeit
   ...: 
   ...: list_a = [s for s in some_list if s.startswith('a')]
   ...: list_b = [s for s in some_list if s.startswith('b')]
10.6 ms ± 253 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

In [4]: %%timeit
   ...: 
   ...: list_a = [s for s in some_list if s[0]=='a']
   ...: list_b = [s for s in some_list if s[0]=='b']
5.89 ms ± 48.9 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

Et comme cela a été dit, la manière la plus pythonique, c'est probablement de se poser la question « ai-je vraiment besoin d'une liste ? Un iterable comme un générateur ou le résultat d'un filter ne me suffirait-il pas ? »

Et c'est la limite de ce genre de truc assez stupide de construction d'objet. Construire une liste n'est pas l'objectif en soit. Et c'est un peu ce que je reproche à nombre de personnes qui font du python qui essaient de mimiquer des constructions classiques alors qu'il faudrait plutôt se poser la question avant. (Même problème dans d'autres langages, en particulier avec le C++ moderne).

Perso j'ai déjà utilisé. C'est très bien. Mais… En fait c'est plutôt fait pour les problèmes simples, et cela permet un accès facile au droit.

Après, j'avoue aimer le droit, aimer me documenter, lire la jurisprudence, etc. Et les quelques fois où j'ai du faire appel à un avocat en temps que conseil, cela dépassait le cadre de ces permanences.

Donc, c'est très bien, mais pas adapté pour tous les conseils. Pour en revenir au sujet du journal, je pense que le sujet du journal est parfaitement dans le cadre de ces permanences, donc c'est une très bonne suggestion.

Il me semble que la consultation pour des conseils est gratuite (et que c'est seulement si il fait une action en ton nom que cela est payant) mais je n'arrive plus à trouver le lien.

Heureusement que non. Le rôle d'un avocat est avant tout d'être un conseil, et lorsqu'une procédure n'est pas nécessaire, il est doit te conseiller de ne pas l'engager. Si il n'était payé que si la procédure était engagée il ne serait plus honnête même avec toute la bonne volonté du monde.

Par ailleurs, dans certains domaines, les avocats font l'essentiel de l'activité en dehors de la procédure judiciaire, je pense au droit des affaires, mais ce n'est pas le seul domaine. Heureusement qu'ils sont payés.

Après, pour de simples conseils, le tarif horaire d'une « consultation » est sensiblement le même que celui d'un médecin (généraliste pour les moins cher, spécialiste pour les plus cher). Attention, le tarif horaire, en moyenne compter 30 minutes pour une consultation avec un avocat contre 15 minutes avec un médecin. Ce n'est pas déraisonnable, mais il n'y a pas de sécurité sociale (il y a bien l'aide juridictionnelle, mais là il faut une procédure de mémoire, ou les assistances juridiques, mais c'est plus comparable à une mutuelle qu'à la sécurité sociale).

Ce qui m'étonne c'est les frais d'opposition et d'émission.

J'ai eu deux fois une aventure similaire:

• avec un DAB, qui, je ne sais toujours pas pourquoi, a planté dès que ma carte a été inséré. Il ne me l'a jamais rendu.
• à un péage d'autoroute, qui m'a demandé un ticket, puis ma carte, puis rebooté… puis demandé un ticket. J'ai appelé l'assistance au péage, j'ai eu le péage gratuit et la société d'autoroute a renvoyé ma carte à la banque.

Les deux fois, ça m'est arrivé lors de périodes de déménagements (je pense que c'est la poisse, je ne déménage pas souvent), et comme on ne peut plus payer par chèque, et que j'ai l'habitude de tout payer en CB ou espèces, dans ces périodes, même si j'ai un stock d'espèce de secours, quand on paie une location de camion de déménagement, un déménageur, etc. ça fond vite.

À chaque fois ma banque ne m'a pas facturé de frais d'opposition et d'émission de nouvelle carte, alors que c'est prévu au contrat, ils font des gestes commerciaux systématiquement. Je serais étonné d'être un client privilégié.

Oui, j'ai cherché dans ma tête, et je n'ai pas trouvé. Ce n'est pas une volonté d'utiliser de l'anglais, juste mon cerveau qui n'a pas voulu fonctionner correctement.

Disons que c'est parfaitement le genre d'expression qui dépend du contexte. Si tu t'adresse à un enfant, le contexte veut que tu parles bien d'une Barbie (ou assimilé). Et si vraiment tu as besoin de lever l’ambiguïté face à un enfant, on doit être dans un cas légitime de visite de la maréchaussée.

un des facteurs expliquant aussi, c'est que l'heading, c'est quelque chose d'absolu qui ne dépend pas du repère de l'avion, parler avec des subdivisions du cadran horaire serait difficilement compréhensible. (oui, le turn left c'est relatif, et c'est justement cela qui permet aux pilotes de vérifier la cohérence de l'information).

Ouais enfin le protocole de Raoult, faut le trouver.

Quand tu lis sa première étude clinique de cas, il traitait 26 patients:

• 14 à l'hydrotruc, pris à des stades variés,
• 6 à l'hydrotruc et antibio, pris à des stades variés,

Oui, il y en a 6, on ne sait pas dans quels cas ils étaient, qui se sont évaporés dans la nature, c'est plus facile d'avoir des résultats intéressants quand on exclue les données qui nous donnerait tort. Cette phrase constitue une accusation, et je l'assume. C'est soit une incompétence crasse, soit une malhonnêteté intellectuelle caractérisée.

Les stades variés, c'est clairement dit (la graisse est un ajout de ma part):

Hospitalized patients with confirmed COVID-19 were included in this study if they fulfilled two primary criteria: i) age >12 years; ii) PCR documented SARS-CoV-2 carriage in nasopharyngeal sample at admission whatever their clinical status.

Et c'est à partir de cela qu'il communique en disant c'est l'hydrotruc + antibio au stade x qui est pertinent. Sérieusement ? Dans cette sous-condition expérimentale là, il n'a rien.

Le seul truc qu'il ressemble de très loin à un vague résultat, c'est son résultat avec l'hydrotruc uniquement. Et il ne montre aucune interaction entre le stade clinique et la date d'administration du traitement.

Donc oui, dans ses vidéos youtube, il dit que c'est à ce moment là qu'il faut traiter, mais même ses torchons ne disent pas cela (et ce qu'ils disent ne repose en plus sur rien). Pour moi, on est clairement dans le cas d'un type qui fait un pari, et qui agit par conviction. Il est convaincu que son traitement est efficace, et si les données et les faits lui donnent tort, ce sont les données et les faits qui ont tort.

donc les risques semblent tout de même vraiment faibles pour une durée de traitement aussi courte. J'ai pris des médicaments (sur prescription) dont les effets secondaires étaient plus effrayants (et je n'ai jamais rien eu de grave pourtant).

Et bien dans ce cas, je t'encourage à lire la littérature, tu verras qu'il y en a, et possiblement des effets secondaires graves.

Je ne suis pas médecin, juste un lecteur d'une partie de la littérature scientifique. Et à ce que j'ai compris, ce qui est grave dans le covid-19, c'est l'inflammation causée plus que la charge virale, et il y a eu des effets de bord de certains AINS sur cette inflammation (d'où les messages forts dans la presse). Une des hypothèses, c'est que même si l'hydrotruc fait diminuer la charge virale (ce qui n'est pas démontré), il est possible que dans le même temps, cela fasse augmenter les inflammations et donc les complications et ainsi augmenter les décès. Il est parfaitement possible pour la communauté médicale d'avoir un médicament qui fasse baisser la charge virale, mais qui augmente la létalité de l'infection.

Donc, parler de ton appréciation des effets secondaires, c'est hors-de-propos. J'en ai marre des débats de comptoir, jusqu'à maintenant sur dlfp le niveau de la discussion était plus élevé que l'anecdote et les rumeurs, mais apparemment c'est vrai que dans le domaine d'expertise des commentateurs. Dès qu'on revient sur des sujets plus généraux, les mêmes travers qu'ailleurs apparaissent.

mais encourage à tester sérieusement la piste de mon point de vu

Ça tombe bien, c'est ce qu'est en cours.

Bon après, de mon point de vue, les travaux de Raoult ne sont même pas un encouragement. Certaines études autres ouvrent une légère pistes sur ce même médoc, mais pas plus que d'autres pistes. Et en aucun cas la généraliser.

Soyons honnêtes, je serais très heureux que cela fonctionne, mais malheureusement je ne vois rien qui ne me montre ne serait-ce qu'un espoir dans les torchons (du point de vue méthodo) de Raoult, ce sont des études de cas. Les études de cas ne sont pas inutiles en médecine, mais elles n'ont pas de valeur probante.

Je l'ai bien compris, mais ton raisonnement le fonctionne que si le risque est faible. Et c'est de ce dernier point dont je ne suis pas certain. Pour moi, c'est le message principal de Raoult (il arrive presque à me convaincre, avant que la raison ne reprenne le dessus, puis je cherche des infos, et dans la littérature, ça m'a l'air moins tranché).

Dans son observational study parue hier (au moins, cette fois, ça porte le nom de ce que c'est, de l'observation, pas de la science, cette fois il assume complétement, il n'a même pas de contrôle) il dit:

Their possible toxicity in combination has been suggested in a few anecdotal reports but, to our knowledge, has never been demonstrated.

Pour moi, c'est assez révélateur. De manière générale, on doit démontrer l'inocuité d'un traitement, ou du moins que le risque est acceptable en regard du bénéfice. Là, il nous balance un renversement de la charge de la preuve, sans frémir. Et non, encore une fois, l'urgence n'est pas une justification.

ça reste un médicament bien connu et avec très très peu de risque d'effet secondaire grave sur une durée de prescription aussi courte

Je ne sais pas. Ça dans le discours de Raoult c'est clair, il le dit le redit et l'appuie. Dans la littérature scientifique, je n'ai pas l'impression qu'il y ait un vrai consensus sur le bénéfice/risque. Et si en effet le risque était très très fabile, alors le bénéfice risque serait élevé, même avec un bénéfice faible, or ça ne semble pas être le consensus.

J'ai bien peur ne pas devoir me fier au discours de Raoult ça ne semble pas cohérent avec la littérature (mais il faudrait l'avis d'un médecin ayant l'habitude de cette littérature). D'autant plus que quand je vois les énormités qu'il dit dans mon domaine (les stats), quand je vois les figures qui ne sont pas les mêmes entre sa communication à la presse et ses versions de son torchon, quand je vois qu'il y a des données dans les tableaux de résultats qui changent entre ses propres versions sans aucune explication, je dois dire qu'en temps que scientifique, je le classe comme quelqu'un pour qui je n'accorde aucune confiance au discours, la seule confiance que je pourrais lui apporter, c'est si il sortait une publi propre (et qu'on ne me sorte pas l'excuse de l'urgence, nombre d'autres équipes ont fait des protocoles propres en urgence, et eux ils ont réussit sans pour autant se brider dans leurs recherches).

Tiens c'est marrant de faire le parallèle avec le scandale du Médiator. Quelles ont été les causes de ce scandales, à la louche :

• Études baclées sur les effets sanitaires à long terme.
• Effets anorexigènes dissimulés.
• Complaisance des autorités sanitaires vis-à-vis des études baclés.
• Prescription hors AMM de ce médicament.

Les deux dernières causes étant probablement liées à de la corruption (certains membres des autorités sanitaires), ou liés à de l'influence (les médecins recevaient des visiteurs médicaux leurs disant de prescrire hors AMM).

Donc prétendre que justement le protocole d’évaluation n'a pas permis de bloquer le Médiator est vrai, mais ce n'est pas de la faute du protocole, mais parce qu'il n'a pas été appliqué.

Ici dans le cas du torchon de Raoult (j'assume le mot de torchon, ce truc n'est pas une étude clinique), et de la polémique autour, justement les autorités sanitaires ne sont pas complaisantes vis-à-vis des études baclés. De plus, vu la littérature scientifique (s'informer par la presse généraliste et par le vidéo de Raoult sur youtube n'est pas ce que j'attends d'un médecin), il est probable que les médecins qui prescrivent hors AMM engagent leurs responsabilité. Et cette fois, ça ne sera pas à cause de l'influence des visiteurs médicaux.

D'un point de vue méthodologie pure, moi j'ai beaucoup apprécié la lecture de ceci (précisions que j'ai lu moi même la publi, le torchon de Raoult avant, et que la majorité des biais me sont directement apparus flagrants avant même de lire cette review, mais ça doit être parce que je suis stateux):

• Dahly, Darren, Gates, Simon, & Morris, Tim. (2020, March 23). Statistical review of Hydroxychloroquine and azithromycin as a treatment of COVID-19: results of an open-label non-randomized clinical trial. (Version 1.0). Zenodo.

C'est une review statistique, qui a les formes de la publi scientifique (car bon, le débat dans l'espace public c'est bien, mais entendre l’opinion de Madame Michu sur ce que doit être une procédure statistique, ça ne m'importe guère). Première partie à lire y compris par des non scientifiques, après ça devient un peu plus spécialisé.

Autrement, avec une forme agréable et poli, qui sied au débat scientifique, il y a le thread sur PubPeer, mais dans le contenu, il est dévastateur.

---

Attention: L'avis argumenté de Mme Michu sur une procédure stat m'intéresse, c'est de son opinion que je me chaut.

Je mets de coté le fait qu'en 2000, la séparation de RTE et d'ERDF du reste d'EDF n'était effective.

C'est marrant comme on a tendance à oublier les liens entre les entreprises.

RTE est une SA détenue à strictement plus de la moitié de sa capitalisation (50.1% pour être exact) par EDF, c'est donc une filiale d'EDF. Donc dire ça concerne RTE, EDF s'en fout, c'est osé.

De plus la tempête en 2000 a touché beaucoup plus violemment le réseau de distribution que le réseau de transport. Le réseau de distribution est géré en grande partie par Enedis (anciennement ERDF) mais pas partout (pas chez moi par exemple). Et Enedis est une filiale à 100% d'EDF.

Leur source c'est exactement la même que la mienne, le twitter de la Gendarmerie. Donc ça confirme, il n'y a pas de source de cette information excepté ce tweet ?

Je ne remets pas en compte la fiabilité et l'honnêteté de la Gendarmerie, je trouve juste dommage de donner les infos que via twitter.

L'article 1 du décret en question dispose:

Les personnes souhaitant bénéficier de l'une de ces exceptions doivent se munir, lors de leurs déplacements hors de leur domicile, d'un document leur permettant de justifier que le déplacement considéré entre dans le champ de l'une de ces exceptions.

Ce munir d'un document, ça veut dire un document, pas un truc à montrer sur un smartphone… Après ça dépend de l'appréciation des forces de l'ordre.

Ce qui est beau de nos jours, c'est qu'on a le droit, et pour comprendre comment il va être appliqué, il faut lire twitter. La Gendarmerie Nationale annonce via twitter, que sur smartphone ça leur va. Mais sur le même thread, on constate que certaines polices municipales ont une interprétation différente. Ça va être le flou jusqu'à que le ministère de l'intérieur donne des consignes précises.

Ah… le monde moderne, où twitter devient plus informatif que legifrance… Je sens que je vieilli.