Oui, pour l'apprentissage, les péchés capitaux des interfaces contemporaines sont :
- Le flat design. Pour mieux comprendre ce que l'on voit, il faut des grosses lignes qui tachent ;
- L'alternance entre double-clic et simple-clic, sur des opérations qui sont souvent sémantiquement extrêmement proches. Pour les débutants, c'est la loterie à chaque clic ;
- Le manque de standardisation de l'ergonomie des sites web. Je rêve d'un web où la structure visuelle des sites serait aussi standardisée que celle des logiciel de bureau ;
- l'abondance de pubs et de popups RGPD, qui créent de la confusion et empêchent les utilisateurs de rester concentrés.
En plus, ces défauts n'apportent pas de bénéfice tangible à la productivité ou au confort de travail pour ceux qui maîtrisent davantage leurs outils.
Oui, le comportement historique est encore possible, mais :
- ça implique de faire la modif pour chaque type MIME, donc c'est hyper long
- j'évite autant que possible de toucher à la configuration des gens que j'accompagne : d'une part ça crée une relation de dépendance qui ne bénéficie à personne, et d'autre part, sur la durée, ça me donne un rôle de dépanneur d'ordinateur dont je me passe volontiers.
Ces deux bibliothèques font beaucoup plus de choses et bien mieux que ma petite preuve de concept :) Elles me donnent même l'impression de faire le café, ce qui, dans une certaine perspective, est un défaut : ma motivation était d'intégrer l'analyse dimensionnelle au langage. Pint peut permettre de parser des chaînes de caractère écrites en langage naturel, intègre des unités exotiques (enfin, le système impérial, quoi), gère la localisation, … C'est super, mais c'est bien trop pour être intégré à un langage.
Je cherchais surtout à avoir une syntaxe plus légère pour les unités composées. Avec Pint, on doit écrire des choses comme :
>>>v1=ureg.Quantity(20,'m/s')
ou bien :
>>>v1=20*ureg.m/ureg.s
De mon côté, on écrit :
>>>v1=20*SI.m.s(-1)
On peut ainsi composer ad libidem les unités :
>>>deux_farad=2*SI.m(-2).kg(-1).s(4).A(2)# Lire 2 m²·kg⁻¹·s⁴·A²>>>deux_farad==2*Si.FTrue>>>grandeur_farfelue=42*SI.hm(2).µs(-3).Gpa.mHz(-1)# Des hectomètres carrés par micromètre cube par miliHertz multipliés par des gigaPascal
L'utilisateur ne manipule jamais de chaînes de caractère pour désigner des unités : le but est faciliter la possibilité de tout contrôler à la compilation et, éventuellement, d'avoir un surcoût quasi-nul à l'exécution. Je ne suis pas allé jusque là dans mon projet, mais peut-être qu'un jour, si je me remotive…
La fonctionnalité de Pint et Turbopy que je jalouse, c'est la gestion des unités logarithmiques. Par conception, c'est impossible avec ma bibliothèque.
Ton commentaire m'interpelle : tu as des exemples de logiciels qui tournent comme ça ? Les logiciels de CAO, par exemple, n'utilisent pas les unités du Système International ? Quelles unités utilisent-ils ?
Les unités naturelles, je vois bien que c'est génial en théorie, par exemple en cosmologie. Mais dans des problématiques à échelle humaine, ça doit amener à manipuler des nombres immensément grands ou petits, ce n'est pas gênant ?
Il s'agit d'une liste de cas d'usage, ça ne signifie pas que l'on entre toujours dans chacun de ces cas :) Parfois, le codeur peut pouvoir ajouter des km/h à des m/s, par confort. D'autres fois, il peut vouloir éviter que ça arrive, par sécurité.
Un exemple de solution pourrait être que, lors d'une telle addition, le compilateur lève un warning. Le codeur aura ensuite la liberté de dire au compilateur si ces warnings doivent être ignorés ou s'ils doivent être bloquants.
je pense que si en interne tout est en SI, le reste est de la conversion d'affichage.
Je suis d'accord, c'est juste plus confortable de laisser ce travail à la bibliothèque.
C'est une bonne idée ! Pour moi, la dimension des grandeurs manipulées est un gros angle mort de la plupart des langages de programmation. On peut distinguer 3 cas d'usage :
* Le contrôle de dimension : lancer une erreur de compilation quand on ajoute une masse à un temps
* Le contrôle d'unités : même si les dimensions sont cohérentes, ajouter des km/h à des m/s est le signe d'une erreur potentielle
* La conversion automatique : passer de manière transparente de kg·m·s⁻² à 10 Newton
Certaines librairies gère une partie de ce travail, je pense en particulier à Pint en Python, mais c'est souvent syntaxiquement assez lourd. J'avais codé une preuve de concept qui permettait une syntaxe assez légère, et qui peut parser toutes les unités du Système International (SI). On peut écrire des choses telles que :
ma_force=10*SI.kg.m.s(-2)# une force de 10 kg·m·s⁻²ma_force<20*Si.N# La force est inférieure à 20 Newtonma_force>10*Si.m# On compare une force à une distance, ça soulève une erreur
Ma preuve de concept ne prend en charge que les unités du Système International, c'est un choix idéologique et d'économie de travail : j'ai tendance à penser que les librairies qui passent par une déclaration préalable des unités répondent à des problématiques essentiellement anglo-américaines. Mais on peut aussi s'adapter en écrivant :
pied_romain=296.3*SI.mmma_distance=10*pied_romain
Je n'ai jamais osé publier cette librairie, entre autres par ce que je soupçonne que le surcoût à l'exécution n'est pas toujours négligeable. L'idéal serait de pouvoir faire ça dans un langage compilé, de manière à ce qu'il n'y ait quasiment plus de surcoût à l'exécution.
Félicitation en tout cas, tu viens de capter toute mon attention pour ton projet :)
Je suis allé voir la vidéo. Le passage qui soutient la thèse "les non vaccinés ne saturent pas les réas" commence à 1:01:00.
L'intervenant commence par un point de rigueur utile : les statistiques utilisées concernent les soins intensifs, et pas seulement les réas.
Tout le monde se base sur les mêmes données qui disent en gros qu'il y a 10 % de non vaccinés en France et 50 % de non vaccinés en soins intensifs. Ces chiffres concernent toutes les causes d'hospitalisation : covid, accidents, autres maladies…
Les personnes non vaccinées sont donc bien surreprésentées en soins intensifs, et il est très tentant de faire une hypothèse sur la cause de leur hospitalisation : ils ont fait un mauvais covid.
Sur 100 lits occupés, 40 lits sont donc occupés par des personnes non vaccinées qui ont fait un covid grave qu'un vaccin aurait évité. Autrement dit, les soins intensifs connaissent une baisse de capacité de 40 % par rapport à leur fonctionnement habituel, pour traiter cette surreprésentation.
Je laisse chacun apprécier si on peut appeler ça une saturation. Personnellement, j'essaie d'apprécier ça via une comparaison : si une usine fonctionne à 60 % de sa productivité normale à cause d'un problème quelconque, j'aurais tendance à considérer cette situation comme catastrophique, surtout elle s'éternise.
Un peu plus loin dans la vidéo, à 1:08:20, l'intervenant indique un taux de patients covid en soins intensifs de 18 %. J'aimerais bien savoir d'où il sort ce chiffre, car il est en contradiction avec mon analyse, et d'autres sources indiquent plutôt un taux de 43 %.
Pour conclure, je ne sais pas sur qui il faut jeter la responsabilité : ceux qui refusent de se faire vacciner ou ceux qui suppriment des lits.
Oui, ça marche aussi chez moi avec le code :) Mais d'une part, je n'ai plus assez de place sur mon écran pour mettre un post-it avec un code de de plus. Et on ne peut pas le changer, donc c'est plus chiant à mémoriser quand on ne fait pas un achat en ligne tous les 4 matins (solidarité avec Mme Michu). Et puis ça me navre de voir la sécurité assurée par un code alphanumérique permanent de 4 caractères et un appareil que je trimballe partout avec moi.
Mais surtout, j'ai l'impression qu'il faut avoir l'esprit tordu pour considérer qu'un smartphone rooté est moins sûr qu'un autre : je ne crois pas qu'on puisse les rooter par accident, si on le fait, c'est qu'on en a les compétences et qu'on veut bien en assumer la responsabilité. A l'inverse, on n'a pas besoin de rooter un téléphone pour installer un logiciel espion. Pégasus en est l'exemple le plus frappant, mais on peut aussi penser à des choses plus ordinaires et tout aussi problématiques : les téléphones Android espionnent constamment leurs utilisateurs et transmettent des informations sensibles au développeur du système d'exploitation.
C'est surtout ça l'objet de mon message : comprendre comment ils peuvent raisonner ainsi, juger de la pertinence de leur position, et le cas échéant développer un argumentaire adapté. Parce que ça me gêne de voir mon banquier faire involontairement et inadéquatement la promotion d'Android et iOS.
Merci pour cette réponse complète, je suis content de voir que je ne suis pas le seul à qui ces décisions posent un problème. Je n'envisage pas d'engager une procédure hostile contre ma banque (quoiqu'un recours collectif…).
Une solution technique ne me satisferait que moyennement : faire tourner leur logiciel à leur insu serait certes une petite victoire, mais j'aspire plutôt à leur faire entendre raison ou à comprendre pourquoi ils ont raison :)
[^] # Re: Malheureusement, ça va plus loin que les fichiers
Posté par sobriquet . En réponse au message Comment évitez-vous le capharnaüm des documents téléchargés sur le web ?. Évalué à 7.
Oui, pour l'apprentissage, les péchés capitaux des interfaces contemporaines sont :
- Le flat design. Pour mieux comprendre ce que l'on voit, il faut des grosses lignes qui tachent ;
- L'alternance entre double-clic et simple-clic, sur des opérations qui sont souvent sémantiquement extrêmement proches. Pour les débutants, c'est la loterie à chaque clic ;
- Le manque de standardisation de l'ergonomie des sites web. Je rêve d'un web où la structure visuelle des sites serait aussi standardisée que celle des logiciel de bureau ;
- l'abondance de pubs et de popups RGPD, qui créent de la confusion et empêchent les utilisateurs de rester concentrés.
En plus, ces défauts n'apportent pas de bénéfice tangible à la productivité ou au confort de travail pour ceux qui maîtrisent davantage leurs outils.
[^] # Re: À tester ...
Posté par sobriquet . En réponse au message Comment évitez-vous le capharnaüm des documents téléchargés sur le web ?. Évalué à 3.
Oui, le comportement historique est encore possible, mais :
- ça implique de faire la modif pour chaque type MIME, donc c'est hyper long
- j'évite autant que possible de toucher à la configuration des gens que j'accompagne : d'une part ça crée une relation de dépendance qui ne bénéficie à personne, et d'autre part, sur la durée, ça me donne un rôle de dépanneur d'ordinateur dont je me passe volontiers.
[^] # Re: Angle mort des langages de programmation
Posté par sobriquet . En réponse au journal [Letlang] Faire la différence entre un nombre et une quantité. Évalué à 2.
Je ne connaissais pas Astropy, merci !
Ces deux bibliothèques font beaucoup plus de choses et bien mieux que ma petite preuve de concept :) Elles me donnent même l'impression de faire le café, ce qui, dans une certaine perspective, est un défaut : ma motivation était d'intégrer l'analyse dimensionnelle au langage. Pint peut permettre de parser des chaînes de caractère écrites en langage naturel, intègre des unités exotiques (enfin, le système impérial, quoi), gère la localisation, … C'est super, mais c'est bien trop pour être intégré à un langage.
Je cherchais surtout à avoir une syntaxe plus légère pour les unités composées. Avec Pint, on doit écrire des choses comme :
ou bien :
De mon côté, on écrit :
On peut ainsi composer ad libidem les unités :
L'utilisateur ne manipule jamais de chaînes de caractère pour désigner des unités : le but est faciliter la possibilité de tout contrôler à la compilation et, éventuellement, d'avoir un surcoût quasi-nul à l'exécution. Je ne suis pas allé jusque là dans mon projet, mais peut-être qu'un jour, si je me remotive…
La fonctionnalité de Pint et Turbopy que je jalouse, c'est la gestion des unités logarithmiques. Par conception, c'est impossible avec ma bibliothèque.
[^] # Re: Angle mort des langages de programmation
Posté par sobriquet . En réponse au journal [Letlang] Faire la différence entre un nombre et une quantité. Évalué à 1.
Ton commentaire m'interpelle : tu as des exemples de logiciels qui tournent comme ça ? Les logiciels de CAO, par exemple, n'utilisent pas les unités du Système International ? Quelles unités utilisent-ils ?
Les unités naturelles, je vois bien que c'est génial en théorie, par exemple en cosmologie. Mais dans des problématiques à échelle humaine, ça doit amener à manipuler des nombres immensément grands ou petits, ce n'est pas gênant ?
[^] # Re: Angle mort des langages de programmation
Posté par sobriquet . En réponse au journal [Letlang] Faire la différence entre un nombre et une quantité. Évalué à 1.
Il s'agit d'une liste de cas d'usage, ça ne signifie pas que l'on entre toujours dans chacun de ces cas :) Parfois, le codeur peut pouvoir ajouter des km/h à des m/s, par confort. D'autres fois, il peut vouloir éviter que ça arrive, par sécurité.
Un exemple de solution pourrait être que, lors d'une telle addition, le compilateur lève un warning. Le codeur aura ensuite la liberté de dire au compilateur si ces warnings doivent être ignorés ou s'ils doivent être bloquants.
Je suis d'accord, c'est juste plus confortable de laisser ce travail à la bibliothèque.
# Angle mort des langages de programmation
Posté par sobriquet . En réponse au journal [Letlang] Faire la différence entre un nombre et une quantité. Évalué à 2.
C'est une bonne idée ! Pour moi, la dimension des grandeurs manipulées est un gros angle mort de la plupart des langages de programmation. On peut distinguer 3 cas d'usage :
* Le contrôle de dimension : lancer une erreur de compilation quand on ajoute une masse à un temps
* Le contrôle d'unités : même si les dimensions sont cohérentes, ajouter des km/h à des m/s est le signe d'une erreur potentielle
* La conversion automatique : passer de manière transparente de kg·m·s⁻² à 10 Newton
Certaines librairies gère une partie de ce travail, je pense en particulier à Pint en Python, mais c'est souvent syntaxiquement assez lourd. J'avais codé une preuve de concept qui permettait une syntaxe assez légère, et qui peut parser toutes les unités du Système International (SI). On peut écrire des choses telles que :
Ma preuve de concept ne prend en charge que les unités du Système International, c'est un choix idéologique et d'économie de travail : j'ai tendance à penser que les librairies qui passent par une déclaration préalable des unités répondent à des problématiques essentiellement anglo-américaines. Mais on peut aussi s'adapter en écrivant :
Je n'ai jamais osé publier cette librairie, entre autres par ce que je soupçonne que le surcoût à l'exécution n'est pas toujours négligeable. L'idéal serait de pouvoir faire ça dans un langage compilé, de manière à ce qu'il n'y ait quasiment plus de surcoût à l'exécution.
Félicitation en tout cas, tu viens de capter toute mon attention pour ton projet :)
[^] # Re: La console developpeur a la rescousse
Posté par sobriquet . En réponse au message Télécharger le contenu d'un site pas commode. Évalué à 3. Dernière modification le 20 février 2022 à 20:56.
Super, ça répond à l'essentiel de mon problème ! pour les curieux, la totalités des réponses est accessible ici en JSON :
https://open.efsa.europa.eu/api/calendar/getConsultationCommentSection?consultationId=a0c1v00000HePrzAAF&offset=0&limit=500
Pour les pièces jointes, ça a l'air un peu plus compliqué, mais ça devient faisable. Merci !
[^] # Re: Assumer sa bêtise
Posté par sobriquet . En réponse au message JDLL de Lyon - le Libre est incompatible avec l'obligation vaccinale !. Évalué à 5.
Je suis allé voir la vidéo. Le passage qui soutient la thèse "les non vaccinés ne saturent pas les réas" commence à 1:01:00.
L'intervenant commence par un point de rigueur utile : les statistiques utilisées concernent les soins intensifs, et pas seulement les réas.
Tout le monde se base sur les mêmes données qui disent en gros qu'il y a 10 % de non vaccinés en France et 50 % de non vaccinés en soins intensifs. Ces chiffres concernent toutes les causes d'hospitalisation : covid, accidents, autres maladies…
Les personnes non vaccinées sont donc bien surreprésentées en soins intensifs, et il est très tentant de faire une hypothèse sur la cause de leur hospitalisation : ils ont fait un mauvais covid.
Sur 100 lits occupés, 40 lits sont donc occupés par des personnes non vaccinées qui ont fait un covid grave qu'un vaccin aurait évité. Autrement dit, les soins intensifs connaissent une baisse de capacité de 40 % par rapport à leur fonctionnement habituel, pour traiter cette surreprésentation.
Je laisse chacun apprécier si on peut appeler ça une saturation. Personnellement, j'essaie d'apprécier ça via une comparaison : si une usine fonctionne à 60 % de sa productivité normale à cause d'un problème quelconque, j'aurais tendance à considérer cette situation comme catastrophique, surtout elle s'éternise.
Un peu plus loin dans la vidéo, à 1:08:20, l'intervenant indique un taux de patients covid en soins intensifs de 18 %. J'aimerais bien savoir d'où il sort ce chiffre, car il est en contradiction avec mon analyse, et d'autres sources indiquent plutôt un taux de 43 %.
Pour conclure, je ne sais pas sur qui il faut jeter la responsabilité : ceux qui refusent de se faire vacciner ou ceux qui suppriment des lits.
[^] # Re: Pour moi, toujours pas d'appli.
Posté par sobriquet . En réponse au message Paiement sécurisé sur un téléphone rooté. Évalué à 5.
Oui, ça marche aussi chez moi avec le code :) Mais d'une part, je n'ai plus assez de place sur mon écran pour mettre un post-it avec un code de de plus. Et on ne peut pas le changer, donc c'est plus chiant à mémoriser quand on ne fait pas un achat en ligne tous les 4 matins (solidarité avec Mme Michu). Et puis ça me navre de voir la sécurité assurée par un code alphanumérique permanent de 4 caractères et un appareil que je trimballe partout avec moi.
Mais surtout, j'ai l'impression qu'il faut avoir l'esprit tordu pour considérer qu'un smartphone rooté est moins sûr qu'un autre : je ne crois pas qu'on puisse les rooter par accident, si on le fait, c'est qu'on en a les compétences et qu'on veut bien en assumer la responsabilité. A l'inverse, on n'a pas besoin de rooter un téléphone pour installer un logiciel espion. Pégasus en est l'exemple le plus frappant, mais on peut aussi penser à des choses plus ordinaires et tout aussi problématiques : les téléphones Android espionnent constamment leurs utilisateurs et transmettent des informations sensibles au développeur du système d'exploitation.
C'est surtout ça l'objet de mon message : comprendre comment ils peuvent raisonner ainsi, juger de la pertinence de leur position, et le cas échéant développer un argumentaire adapté. Parce que ça me gêne de voir mon banquier faire involontairement et inadéquatement la promotion d'Android et iOS.
[^] # Re: Un cas quasi similaire au tien
Posté par sobriquet . En réponse au message Paiement sécurisé sur un téléphone rooté. Évalué à 2.
Merci pour cette réponse complète, je suis content de voir que je ne suis pas le seul à qui ces décisions posent un problème. Je n'envisage pas d'engager une procédure hostile contre ma banque (quoiqu'un recours collectif…).
Une solution technique ne me satisferait que moyennement : faire tourner leur logiciel à leur insu serait certes une petite victoire, mais j'aspire plutôt à leur faire entendre raison ou à comprendre pourquoi ils ont raison :)