L'opposé de gamin, c'est adulte non ? Quoique quand je vois le comportement de certains « adultes » j'ai un doute (c'est une vérité générale et pas une attaque sur la personne à qui je réponds).
Cela dit, j'aime beaucoup l'image d'un type qui essaierait de programmer en C uniquement à l'aide de ses attributs. Ça doit vite être complexe quand il faut utiliser des combinaisons de touches.
Et douloureux.
Il y a un équivalent du BÉPO optimisé pour couilles ?
Supprimer le journal serait dommage vu les commentaires intéressants qu'il a généré. Mais on pourrait « remplacer la traduction par un résumé » (déjà vu).
J'ai répondu à la FSF que du coup, ça semblait incohérent et pas qu'à moi. Leur réponse :
I can only re-emphasise that we don't support the idea that all
possible kinds of works should be free, or even freely
re-distributable. What we say is that software should be free,
and that its documentation should be free
Eh bien, désolé, mais il va falloir supprimer cette traduction. J'ai posé la question (par mail), auquel ils m'ont répondu que :
Je peux traduire cette page… si je ne la montre à personne d'autre ! (« if you don't show it anybody else. »). Si on veut la publier, il faut suivre cette doc. Ça implique de traduire, de soumettre la traduction à leur propre équipe de traduction, ils la publient sur www.gnu.org et là seulement on peut re-publier leur traduction qui est obligatoirement sous CC BY-ND.
L'explication d'eingousef était la bonne. Pour eux, c'est une opinion, pas un logiciel ou un travail qui a un intérêt pratique, ils conservent le copyright pour éviter les mésinterprétations – et me renvoient vers cette source. Pour eux ce n'est pas incohérent avec leur message général.
En plus de ça, la majorité des eurodéputés a une proportion d'erreurs bien plus basse que ceux incriminés ici. Nos eurodéputés français seraient-ils si mauvais qu'ils n'arrivent pas à s'organiser là où la majorité de leurs collègues y parviennent très bien ?
Le fond de la question est : en quoi aurait-il été dommage de la jeter ?
C'est toujours un peu triste de jeter du travail déjà fait, mais vaut-il mieux publier une dépêche moyennement peu pertinente pour éviter de perdre une traduction, ou se dire que tant pis, ça n'a plus vraiment de sens, et l'abandonner ?
C'est de vraies questions et j'ai l'impression que le cœur de la dispute vient du fait que vous n'y apportez pas les mêmes réponses.
C'est assez vrai. Dans le cas de Java, l'effet est renforcé par :
L'historique du langage (fonctionnalités arrivées tard) que certains n'ont toujours pas intégrés (en réalité / dans leurs reproches)
Un langage (et un moteur d'exécution) qui comporte plus de subtilités qu'on pourrait le croire (comme la gestion mémoire), ou dont le fonctionnement change avec le temps (le garbage collector / le compilateur JIT)
Le fait que c'est un langage orienté Entreprise™ avec tout ce que ça implique comme :
Les équipes ultra-morcelées avec des gens qui bossent 3 mois sur un tout petit bout du code
Les projets très longs et très chers donc impossibles à refacto / réécrire
La faiblesse de la communauté open-source et de l'outillage qui peut arriver avec (ne serait-ce que des règles aussi idiotes qu'un formatage du code par défaut)
PHP me donnait plus l'impression de poser problème à cause de failles intrinsèques au langage (PHP 4 était une jolie collection d'incohérences) ; JS plus à cause de sa communauté et de son mode de fonctionnement ultra-éclaté.
PS : les prérequis éditeurs, par contre c'est une vraie plaie. Dédicace à IBM qui vends des logiciels Java qui ne fonctionnent que sur une JVM IBM (J9, maintenant libéré sous le nom OpenJ9 et propriétés de la fondation Eclipse). Mais c'est généralement des limitations arbitraires.
Ca bouffe un tas de ram puisque tu dois fixer un minimum/maximum
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
ça log comme ça veut et ça ne respecte pas les logrotate
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Ah oui et la tendance naturelle à crasher au moindre pépin, par exemple sur un lag de BDD c'est vraiment génial.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
même Microsoft qui est une grande union (d'actionnaire, de développeurs…) s'y est cassé les dents avec Windows Mobile arrivé trop tard sur le marché du coup déjà saturé.
J'ai eu l'occasion d'avoir un téléphone sous Windows Mobile 5.0 à l'été 2005, soit avant l'arrivée de l'iPhone et de quasiment tous les smartphones. Microsoft ne s'est pas pété les dents sur le marché du smartphone parce qu'ils sont arrivés trop tard avec Windows Mobile, mais parce qu'ils ont fait une collection hallucinante de mauvais choix :
Ergonomie catastrophique (Windows Mobile avait à peu près la tronche d'un Windows de bureau, sur un téléphone bien plus petit qu'un smartphone actuel)
Stabilité inexistante
Performances horribles
N'a pas pris le virage des smartphones tels qu'ils se sont développés à partir de 2008
etc (dont sans doute plein de choix douteux quant à leur intégration et les applications tierces).
Ils ont fini par redresser le tir et Windows Mobile 8 et surtout 10 n'étaient techniquement pas de mauvais produits, mais c'était beaucoup trop tard… par contre, objectivement ils étaient là avant presque tout le monde !
J'ai déjà répondu au gros du message plus bas, avant que tu ne le postes. Je trouves ça triste de vouloir restreindre l'incroyable richesse des langues mondiales, et de vouloir imposer un système d'écriture qui n'est pas celui de l'incroyable majorité de la population mondiale (pas même du français, à cause des diacritiques).
Cela dit :
on devrait utiliser du utf-16 ou utf-32; où les caractères sont de taille fixe.
PS : tu mélanges un peu tout. Unicode a prévu des classes de caractères. Pour la programmation, il suffit de n'accepter comme identifiants que ce qui est un caractère réel, pas un symbole ou une espace etc.
Je ne m'étonne guère de votre intervention. En postant ici, comme d'habitude, je pensais m'attirer la foudre…Et bingo !
Pourquoi tu as posté alors ? Si tu sais qu'on ne veut pas de ta publicité et que tu n'en retireras rien… contentes-toi de ne pas poster. Ça t'éviteras une perte d'énergie, et de venir chouiner en public en faisant des généralités de ton cas particulier.
Et ce sera infiniment plus agréable pour tout le monde.
Déjà l'honnêteté intellectuelle m'oblige à préciser qu'en réalité,tant qu'on parle de la JVM ICU permet déjà ce genre de chose (en plus complet mais avec une API plus compliquée, et sans garantie quant à la gestion des catégories, cf ci-dessous).
Et quelques précisions pour répondre aux commentaires ci-dessus.
Bien évidemment, ce genre d'outil ne doit servir en aucun cas à forcer du simple ASCII. Unicode est un progrès gigantesque dans un monde où les outils de l'état massacrent encore les noms et prénoms de ses propres citoyens (ceux qui ont une diacritique dans leur nom ou prénom savent à quel point elle est souvent supprimée). Ne nous servons pas de ces possibilités pour régresser, merci.
C'est pour ça qu'il y a des outils pour récupérer des alias et surtout des catégories sur les caractères ; et surtout que les outils de gestion des confusions permettent de gérer des catégories de caractères « de base ». Par exemple pour une application en Français, on voudrait d'autoriser / ne détecter les risques de confusion qu'au sein d'une classe de caractères. Par exemple, une application en français voudrait pouvoir éviter les chaines qui contiennent des caractères que l'on peut confondre avec des caractères latins mais qui n'en sont pas (les caractères latins sont considérés comme légitimes). Une application en russe voudrait elle que ce soit les caractères cyrilliques qui sont légitimes. Je vous renvoie à la doc pour plus de détails1
Aujourd'hui ce qu'il manque à confusables-homoglyphs, c'est l'équivalent des skeleton de ICU, c'est-à-dire une fonctionnalité qui permet d'enregistrer une version « normalisée » d'une chaine de caractères. Cette version n'est pas utilisable à l'affichage, mais permet des comparaisons : deux chaines de même squelette peuvent être confondues. En enregistrant le squelette dans un champ ad hoc, on peut autoriser par exemple des pseudonymes avec n'importe quels caractères, tout en interdisant facilement tout autre pseudonyme homoglyphe.
Enfin, tout l'intérêt des exemples était de montrer que dans certains cas, il n'y a absolument aucun moyen graphique de discerner deux homoglyphes. En réalité l'exemple des noms de domaines était repiqué de la doc d'origine, mais est assez mauvais parce que les navigateurs vont afficher le nom de domaine canonique, donc http://www.xn--faebook-6pf.com/ et http://www.xn--microsft-sbh.com/ – en plus du fait que les utilisateurs font rarement attention à ce qu'il y a dans la barre d'URL.
Celle du projet Python d'origine, j'ai oublié de publier la doc Java… ↩
D'autre part, au-delà du troll sur Java, je serais curieux de voir le concept poussé dans d'autres langages, pour voir si ça fonctionne vraiment au-delà de la théorie.
J'ai testé uniquement avec une JVM OpenJDK 11. Si j'y pense, j'essaierai avec une OpenJ9 11 (anciennement IBM, maintenant fondation Eclipse) – mais ça attendra lundi que le PC sur lequel c'est installé soit réparé.
C'est difficilement accessible à certaines personnes. Pour d'autres souffrant par exemple de trouble de l'attention ça peut être salvateur. Ça peut aussi permettre de suivre un cours ou un sujet juste à l'écoute.
La plupart des cours d'informatique que j'ai eu l'occasion de voir sont par nature très à suivre sans support visuel (le code et son rendu).
Youtube permet d'ajouter des overlay assez facilement et bon nombre de youtubeurs font des retouches post prod.
J'ai fait pas mal de validations de contenus pour feu le Site du Zéro, et quelques-unes pour Zeste de Savoir. Et j'ai moi-même écrit plusieurs tutoriels et articles. Ce qu'il en ressort, c'est mon point de vue sur la relecture par les tiers : si tu aimes le travail propre, tu vas avoir beaucoup de modifications par rapport à la v1. Bien plus que ce que tu peux te permettre pour les overlays (qui restent très pratiques pour les coquilles qui sont passées au travers du filet).
Modifier son prompt c'est du développement ?
C'est assez proche pour que la plupart des remarques s'appliquent.
Maintenant, si tu penses que c'est utile, j'ai quelques pistes pour t'améliorer :
La voix : prépare ton texte, et lis-le autant que possible. Ça évitera les hésitations, les sautes de rythme, etc.
Fais du montage. Ici la première seconde tu finis un réglage. C'est la première seconde, la vidéo n'a pas vraiment commencé, et tu nous montres que tu ne maitrises pas ton format.
La caméra en contre-plongée fait un joli plan sur tes trous de nez, mais je pense qu'on peut faire mieux.
Visiblement tu passes ton temps à regarder un deuxième écran, donc à regarder carrément à côté de la caméra. C'est très perturbant.
Attention aux détails dans le décor, comme le panier de linge (?) en bas à gauche, ou le carton qui déborde au-dessus de ta tête.
Quant au contenu, je n'ai pas d'avis, à cause de ce que je détaille dans le lien.
Bon courage à toi si tu décides de continuer dans cette voie !
[^] # Re: Macron
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien Claviers français : 2 dispositions normalisées ! L’Afnor nous propose BÉPO et un nouvel AZERTY. Évalué à 4.
Les maniaques japonophiles qui écrivent Tōkyō vont être contents aussi :)
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 2.
L'opposé de gamin, c'est adulte non ? Quoique quand je vois le comportement de certains « adultes » j'ai un doute (c'est une vérité générale et pas une attaque sur la personne à qui je réponds).
Cela dit, j'aime beaucoup l'image d'un type qui essaierait de programmer en C uniquement à l'aide de ses attributs. Ça doit vite être complexe quand il faut utiliser des combinaisons de touches.
Et douloureux.
Il y a un équivalent du BÉPO optimisé pour couilles ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: leçon de vie
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Festival d'installation : Jusqu'où et comment pactiser avec le diable ?. Évalué à 5.
Supprimer le journal serait dommage vu les commentaires intéressants qu'il a généré. Mais on pourrait « remplacer la traduction par un résumé » (déjà vu).
La connaissance libre : https://zestedesavoir.com
[^] # Re: La FSF m'a répondu, il n'a pas les droits.
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Festival d'installation : Jusqu'où et comment pactiser avec le diable ?. Évalué à 6.
J'ai répondu à la FSF que du coup, ça semblait incohérent et pas qu'à moi. Leur réponse :
La connaissance libre : https://zestedesavoir.com
[^] # La FSF m'a répondu, il n'a pas les droits.
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Festival d'installation : Jusqu'où et comment pactiser avec le diable ?. Évalué à 7. Dernière modification le 01 avril 2019 à 14:54.
Eh bien, désolé, mais il va falloir supprimer cette traduction. J'ai posé la question (par mail), auquel ils m'ont répondu que :
La connaissance libre : https://zestedesavoir.com
[^] # Re: As-tu les droits?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Festival d'installation : Jusqu'où et comment pactiser avec le diable ?. Évalué à 3. Dernière modification le 01 avril 2019 à 11:19.
Tiens, je vais leur demander pourquoi, par curiosité.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 4.
Apparemment pour bien programmer en C, il semble nécessaire de taper au clavier non pas avec ses doigts mais avec ses testicules.
Ce qui m'amène deux remarques :
La connaissance libre : https://zestedesavoir.com
[^] # Re: une explication de Mélenchon
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Félonie au parlement européen. Évalué à 9.
En plus de ça, la majorité des eurodéputés a une proportion d'erreurs bien plus basse que ceux incriminés ici. Nos eurodéputés français seraient-ils si mauvais qu'ils n'arrivent pas à s'organiser là où la majorité de leurs collègues y parviennent très bien ?
La connaissance libre : https://zestedesavoir.com
# Et ça continue…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [HS] Félonie au parlement européen. Évalué à 4.
https://www.nextinpact.com/brief/directive-droit-d-auteur---13-eurodeputes-affirment-s-etre-trompes-lors-du-vote-8264.htm
La connaissance libre : https://zestedesavoir.com
[^] # Re: On se rapproche doucement des types sommes
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 2.
De ce que je vois des dernières fonctionnalités, j'ai plus l'impression qu'ils lorgnent du côté de Kotlin.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Alors ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Il y a six mois Linus décidait de changer, a‐t‐il réussi ?. Évalué à 4.
Le fond de la question est : en quoi aurait-il été dommage de la jeter ?
C'est toujours un peu triste de jeter du travail déjà fait, mais vaut-il mieux publier une dépêche moyennement peu pertinente pour éviter de perdre une traduction, ou se dire que tant pis, ça n'a plus vraiment de sens, et l'abandonner ?
C'est de vraies questions et j'ai l'impression que le cœur de la dispute vient du fait que vous n'y apportez pas les mêmes réponses.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 4.
C'est assez vrai. Dans le cas de Java, l'effet est renforcé par :
PHP me donnait plus l'impression de poser problème à cause de failles intrinsèques au langage (PHP 4 était une jolie collection d'incohérences) ; JS plus à cause de sa communauté et de son mode de fonctionnement ultra-éclaté.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 3.
PS : les prérequis éditeurs, par contre c'est une vraie plaie. Dédicace à IBM qui vends des logiciels Java qui ne fonctionnent que sur une JVM IBM (J9, maintenant libéré sous le nom OpenJ9 et propriétés de la fondation Eclipse). Mais c'est généralement des limitations arbitraires.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Java > 1.8
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java XII est dehors. Évalué à 10.
Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.
Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.
Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.
Là encore, ça dépend principalement de comment tu as codé ton application.
En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.
Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Choix facile
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Navigateur web, l'impossible choix. Évalué à 6.
J'ai eu l'occasion d'avoir un téléphone sous Windows Mobile 5.0 à l'été 2005, soit avant l'arrivée de l'iPhone et de quasiment tous les smartphones. Microsoft ne s'est pas pété les dents sur le marché du smartphone parce qu'ils sont arrivés trop tard avec Windows Mobile, mais parce qu'ils ont fait une collection hallucinante de mauvais choix :
Ils ont fini par redresser le tir et Windows Mobile 8 et surtout 10 n'étaient techniquement pas de mauvais produits, mais c'était beaucoup trop tard… par contre, objectivement ils étaient là avant presque tout le monde !
La connaissance libre : https://zestedesavoir.com
# Langues
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Conférence : «Le logiciel libre face à l'informatique» - Richard Stallman - 29/03 - ISTIC Rennes. Évalué à 5.
Pourquoi le résumé et la bio sont en anglais si la conférence est en français ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est très bien fait
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au lien coloriser avec le deep learning des photos noires et blancs. Évalué à 4.
Une photo noir et blanc d'un paysage sur Mars donne des résultats très étonnants (et ma foi assez jolis).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Microsоft.com, Faϲebook.com
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche confusable-homoglyphs : une bibliothèque pour gérer les caractères qui se ressemblent. Évalué à 2. Dernière modification le 19 mars 2019 à 21:56.
J'ai déjà répondu au gros du message plus bas, avant que tu ne le postes. Je trouves ça triste de vouloir restreindre l'incroyable richesse des langues mondiales, et de vouloir imposer un système d'écriture qui n'est pas celui de l'incroyable majorité de la population mondiale (pas même du français, à cause des diacritiques).
Cela dit :
Les caractères UTF-16 n'ont pas une taille fixe (même si ce n'est pas la même gestion qu'avec UTF-8).
PS : tu mélanges un peu tout. Unicode a prévu des classes de caractères. Pour la programmation, il suffit de n'accepter comme identifiants que ce qui est un caractère réel, pas un symbole ou une espace etc.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Mais bien-sur !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Elphyrecoin : la cryptomonnaie au service de l'opensource. Évalué à 10.
Pourquoi tu as posté alors ? Si tu sais qu'on ne veut pas de ta publicité et que tu n'en retireras rien… contentes-toi de ne pas poster. Ça t'éviteras une perte d'énergie, et de venir chouiner en public en faisant des généralités de ton cas particulier.
Et ce sera infiniment plus agréable pour tout le monde.
La connaissance libre : https://zestedesavoir.com
# Quelques précisions…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche confusable-homoglyphs : une bibliothèque pour gérer les caractères qui se ressemblent. Évalué à 8. Dernière modification le 15 mars 2019 à 17:24.
Hello,
Déjà l'honnêteté intellectuelle m'oblige à préciser qu'en réalité,tant qu'on parle de la JVM ICU permet déjà ce genre de chose (en plus complet mais avec une API plus compliquée, et sans garantie quant à la gestion des catégories, cf ci-dessous).
Et quelques précisions pour répondre aux commentaires ci-dessus.
Je précise que l'outil fait de la détection multi-caractères :
©et(c)vont être considérés comme pouvant être confondus (dans les deux sens).Bien évidemment, ce genre d'outil ne doit servir en aucun cas à forcer du simple ASCII. Unicode est un progrès gigantesque dans un monde où les outils de l'état massacrent encore les noms et prénoms de ses propres citoyens (ceux qui ont une diacritique dans leur nom ou prénom savent à quel point elle est souvent supprimée). Ne nous servons pas de ces possibilités pour régresser, merci.
C'est pour ça qu'il y a des outils pour récupérer des alias et surtout des catégories sur les caractères ; et surtout que les outils de gestion des confusions permettent de gérer des catégories de caractères « de base ». Par exemple pour une application en Français, on voudrait d'autoriser / ne détecter les risques de confusion qu'au sein d'une classe de caractères. Par exemple, une application en français voudrait pouvoir éviter les chaines qui contiennent des caractères que l'on peut confondre avec des caractères latins mais qui n'en sont pas (les caractères latins sont considérés comme légitimes). Une application en russe voudrait elle que ce soit les caractères cyrilliques qui sont légitimes. Je vous renvoie à la doc pour plus de détails1
Aujourd'hui ce qu'il manque à confusables-homoglyphs, c'est l'équivalent des skeleton de ICU, c'est-à-dire une fonctionnalité qui permet d'enregistrer une version « normalisée » d'une chaine de caractères. Cette version n'est pas utilisable à l'affichage, mais permet des comparaisons : deux chaines de même squelette peuvent être confondues. En enregistrant le squelette dans un champ ad hoc, on peut autoriser par exemple des pseudonymes avec n'importe quels caractères, tout en interdisant facilement tout autre pseudonyme homoglyphe.
Enfin, tout l'intérêt des exemples était de montrer que dans certains cas, il n'y a absolument aucun moyen graphique de discerner deux homoglyphes. En réalité l'exemple des noms de domaines était repiqué de la doc d'origine, mais est assez mauvais parce que les navigateurs vont afficher le nom de domaine canonique, donc http://www.xn--faebook-6pf.com/ et http://www.xn--microsft-sbh.com/ – en plus du fait que les utilisateurs font rarement attention à ce qu'il y a dans la barre d'URL.
Celle du projet Python d'origine, j'ai oublié de publier la doc Java… ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: Unicode
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Des emojis en SQL ? C'est possible… et on peut aller au-delà !. Évalué à 2.
D'autre part, au-delà du troll sur Java, je serais curieux de voir le concept poussé dans d'autres langages, pour voir si ça fonctionne vraiment au-delà de la théorie.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Unicode
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Des emojis en SQL ? C'est possible… et on peut aller au-delà !. Évalué à 2.
J'ai testé uniquement avec une JVM OpenJDK 11. Si j'y pense, j'essaierai avec une OpenJ9 11 (anciennement IBM, maintenant fondation Eclipse) – mais ça attendra lundi que le PC sur lequel c'est installé soit réparé.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Des soucis classiques
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Ma première vidéo. Évalué à 2.
La plupart des cours d'informatique que j'ai eu l'occasion de voir sont par nature très à suivre sans support visuel (le code et son rendu).
J'ai fait pas mal de validations de contenus pour feu le Site du Zéro, et quelques-unes pour Zeste de Savoir. Et j'ai moi-même écrit plusieurs tutoriels et articles. Ce qu'il en ressort, c'est mon point de vue sur la relecture par les tiers : si tu aimes le travail propre, tu vas avoir beaucoup de modifications par rapport à la v1. Bien plus que ce que tu peux te permettre pour les overlays (qui restent très pratiques pour les coquilles qui sont passées au travers du filet).
C'est assez proche pour que la plupart des remarques s'appliquent.
La connaissance libre : https://zestedesavoir.com
# Des soucis classiques
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Ma première vidéo. Évalué à 7. Dernière modification le 04 mars 2019 à 16:24.
Avant toute chose, voici mon avis détaillé sur ce genre de vidéo dans leur concept même.
Maintenant, si tu penses que c'est utile, j'ai quelques pistes pour t'améliorer :
Quant au contenu, je n'ai pas d'avis, à cause de ce que je détaille dans le lien.
Bon courage à toi si tu décides de continuer dans cette voie !
La connaissance libre : https://zestedesavoir.com
[^] # Re: En effet, mais on parle aussi de libre parfois ici
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Le Guide du Voyageur Galactique a enfin un successeur : Pixel !. Évalué à 3.
Tu oublies le rôle de promoteur dans la vente ; et c'est très souvent ce rôle qui est complètement oublié par les éditeurs aujourd'hui.
Beaucoup d'éditeurs impriment des dizaines de trucs et n'en assurent aucune promotion, forcément ils ne se vendent pas.
La connaissance libre : https://zestedesavoir.com