Antichesse (o ^ω^ o)
@Lou fait bien de remonter ce problème car il est bien moins triviale qu'il ne le paraît !
En résumé, l'article de Pink relate le fait qu'Eloise, une femme cis dite "butch lesbian", c'est-à-dire une femme née femme et s'identifiant comme étant une femme, qui aime les autres femmes mais dont l'apparence est très masculine, rencontre des difficultés pour utiliser les toilettes publics. Pour faire simple Eloise est une lesbienne à l'apparence d'homme.
Et il ne s'agit pas là d'un handicap mais de son rapport aux autres et surtout du rapport des autres à elle !
En effet Eloise ressemble vraiment à s'y méprendre à un homme, en tout cas les codes vestimentaires et visuels qu'elle arbore, si l'image ci-dessous est bien la sienne, rendent difficile sa distinction avec les hommes d'une manière générale.
Du coup quels toilettes doit-elle utiliser ?
Celui des hommes ? Mais Eloise est une femme, ce serait donc l'apparence qui devrait primer sur le sexe ? Sur ce point je ne suis pas d'accord car bon nombre de pervers d'hommes n'auraient qu'à se travestir pour s'introduire dans les toilettes des femmes... Ce n'est juste pas possible.
Alors Eloise devrait utiliser les toilettes des femmes ? Mais dans ce cas, et moi-même je me serai faite avoir tant l'apparence d'Eloise est masculine, je lui aurai signifié qu'elle s'était trompée de toilettes et que ceux des hommes étaient à côté. Et là nous retombons dans le problème de départ où ce doit être épuisant pour elle de devoir s'expliquer, se justifier, encore et toujours, sur quelque chose qui finalement relève de l'intime et dont elle ne devrait pas avoir à parler auprès d'inconnus ; imaginez qu'à cette heure elle en est rendue de se faire accompagner par quelqu'un comme si elle était encore une enfant. (> <)
Reste la solution de toilettes triples. C'est-à-dire ayant un coin femmes, un coin mixte et un coin hommes.
Ceux gênés par l'autre sexe pourraient toujours choisir leurs toilettes non-mixtes et tous ceux qui ne rentrent pas dans les grandes cases des critères sociaux-culturels classiques pourraient utiliser sans peine ce qui devrait toujours être utilisé sans peine.
Ce n'est pas une solution miracle mais ce serait déjà un petit début je pense.
Il y a quelques années, lorsque je passais un entretien dans une grosse banque pour intégrer dans une équipe de coachs crafts, deux coachs m'avaient demandé comment j'assurais ma veille technologique. J'avais alors énuméré tout un tas de sites web dont développez.com et là... Je les ai vu grincer des dents mais genre fort fort fort...
Aujourd'hui, je vois un article qui s'intitule : Tutoriel pour apprendre à développer des objets Java et pas simplement des classes de données et dès le second écran je peux lire ceci :
public final class Assert {
private Assert() {}
public static void notNull(String fieldName, Object input) {
if (input == null) {
throw MissingMandatoryValueException.forNullValue(fieldName);
}
}
public static void notBlank(String fieldName, String input) {
if (input == null) {
throw MissingMandatoryValueException.forNullValue(fieldName);
}
if (input.isBlank()) {
throw MissingMandatoryValueException.forBlankValue(fieldName);
}
}
public static StringAsserter field(String fieldName, String value) {
return new StringAsserter(fieldName, value);
}
public static class StringAsserter {
private final String fieldName;
private final String value;
private StringAsserter(String fieldName, String value) {
this.fieldName = fieldName;
this.value = value;
}
public StringAsserter notBlank() {
Assert.notBlank(fieldName, value);
return this;
}
public StringAsserter maxLength(int maxLength) {
if (value != null && value.length() > maxLength) {
throw StringSizeExceededException
.builder()
.field(fieldName)
.currentLength(value.length())
.maxLength(maxLength).build();
}
return this;
}
}
}Que des méthodes statiques, un constructeur privé pour bien empêcher les instances, aucun état représenté... Donc sans critiquer l'auteur et son envie de bien faire (car il a le mérite d'avoir écrit quelque chose), cet article rappelle effectivement des principes de l'OOP mais sans jamais les comprendre ni même en illustrer ne serait-ce qu'un seul exemple valable.
L'objet est aux antipodes du static, si vous avez du code statique c'est foncièrement que vous ne codez pas en objet. Et là, le seul exemple de l'article est basé sur ça... Bref, article à mettre à la corbeille, navrée pour son auteur.
Un article à charge sur le langage Go qui est factuel sur ses arguments et... C'est vrai !
Go se voulant extrêmement simple le langage ne propose juste rien. Pas de génériques, pas de gestion des types d'encoding, pas de stack trace, bref simple mais parce que vide.
Développer en Go - et j'en ai fait l'expérience - c'est coder vite et maintenir longtemps, d'où mon choix de privilégier Kotlin en (1) et Rust en (2).
Je cite le meilleur commentaire de l'année tant il résume parfaitement et en une phrase la pensée des sénateurs américains et la bêtise de leur question :
"Bonjour, nous aimerions un bunker anti-atomique, mais avec une porte ouverte."
L33tige
Les types de connexions internet permettant la data sur nos mobiles se classent de la moins rapide à la plus rapide de la façon suivante : GSM < 2G < 3G < 3G+ < H < H+ < 4G < 4G+ < 5G.
En les regroupant par grandes catégories de débits, nous avons la répartition suivante :
(Graphique fourni par imagekit.io)
On constate qu'environ 50% des requêtes se font avec une connexion d'une qualité inférieure ou égale à de la 3G, aussi à quelle vitesse vont chacune de ces connexions ? Selon le site kenstechtips.com les types de connexions offrent les taux théoriques de transfert suivants :
- 2G -> 12,5 Ko / sec
- 3G -> 1 Mo / sec
- 4G -> 7,5Mo / sec
- 5G -> 125 Mo / sec
En considérant que le réseau n'est jamais optimal, ces ratios de transferts ne sont jamais à leur maximum non plus, aussi nous pouvons leur retrancher sans trop de risque 80% de leur capacité (eg. lorsque nous déplaçons en voiture ou dans le métro, lorsque trop de monde utilise la même antenne, ou encore que nous sommes dans une pièce avec beaucoup d'armatures métalliques), ce qui donnerait après ajustement les débits "réels" suivants :
- 2G -> 2,5 Ko / sec
- 3G -> 200 Ko / sec
- 4G -> 1,5 Mo / sec
- 5G -> 62,5 Mo / sec
Valeurs qui sont assez proche de ce que je constate en région parisienne. En calculant une moyenne pondérée des débits inférieurs ou égale à de la 3G on obtient un débit moyen affleurant les 95 Ko / sec à peine pour 50% des internautes fin 2019 !
Et comme pour ce calcul j'ai pris tous les maximum (certes après ma bidouille d'ajustement au réel) je pense qu'il est raisonnable de considérer que le débit de nos utilisateurs depuis une connexion mobile tourne autour de 50 Ko / sec, soit entre 10 et 20 secondes de temps chargement juste pour une SPA Aurelia (~500 Ko) / Angular (~1 Mo) si l'on ne compresse pas les fichiers statiques (ie. HTTP + GZIP).
Et même avec une compression GZIP de dingue (disons d'un facteur 10), il faut encore charger l'intégralité des images qui pèsent au moins l'équivalent de deux fois le bundle JS non compressé à laquelle s'ajoute les temps de connexions HTTP à consommer pour récupérer chaque fichiers.
Typiquement et même pour une SPA bien conçue, le temps minimal de chargement sera de 5 secondes si les images ne sont pas différées correctement, voire 10 secondes si le JS est bloquant (cf. utilisation de l'attribut "defer"). Cela remet en question l'intérêt de la technologie SPA pour des connexions mobiles avant la mise en cache ou pis encore si la SPA est mise à jour très fréquemment (via du Continuous Deployment) !
Un article très intéressant sur la notion de corruption dans l'informatique et son parallèle avec la société civile et la biologie.
Via Riduidel.
@Chlouchloutte as-tu des remarques sur le sujet ?
Je relais le post de @animal pour une simple raison qui réside dans ce passage au sujet des Antifas (qui sont selon moi, un groupuscule violent agressant sur commande et sans réfléchir tout ce qu'un pouvoir issu des plus hautes classes sociales a désigné comme ennemi) :
The ANTIFA
Wherever people gather, Antifa groups may pursue their indiscriminate search to root out “fascists”. In Bordeaux last Saturday, Yellow Vests had to fight off an attack by Antifa.
It is now completely clear (as indeed it always has been) that the self-styled “Antifascists” are the watch dogs of the status quo. In their tireless search for “fascists”, the Antifa attack anything that moves. In effect, they protect stagnation. And curiously enough, Antifa violence is tolerated by the same State and the same police who insult, attack and arrest more peaceful demonstrators. In short, the Antifa are the storm troopers of the current system.
Le premier article critique que je peux enfin lire sur la Blockchain. Je relais pour Chlouchloutte
En fait je viens de tiquer... J'ai presque 2500 liens sur mon Shaarli et référencer un site fait que je doive payer l'auteur de la page que j'ai partagée... Bah je suis grave dans la merde !
Enfin, comme le dit Chlouchloutte : les mecs veulent qu'on revienne à la télé ! #TaGueuleEtConsomme
Je l'ai dit, encore et encore, l'Article 13 qui est passé, l'a été via lobbying qui s'est fait au niveau de cette foutue Union Européenne... Pas d'Union Europénne = Pas de Lobbying ni de lois de merde !
Il est temps : il faut sortir de cette saloperie d'UE, de cette saloperie de "Démocratie Représentative" et voter les lois nous-mêmes.
Ohhh mais attentez... Avoir des représentants qui écrient et votent Les lois à notre place c'est la démocratie nan ? Ah bah non en fait... Ohhhhh my Gaaaaad.
Les Pays-Bas ne sont pas une démocratie, la France n'est pas une démocratie et l'Union Européenne est l'institutionnalisation qui vise à supprimer tout pouvoir aux citoyens en offrant les 4 principaux pouvoir d'une nation (ndr. Législatif, Judiciaire, Exécutif et Création Monétaire) à des personnes non-élues... Mais bon, il paraît que vouloir sortir de l'UE ou encore refonder des institutions justes, honnêtes et démocratiques, c'est être un vilain nationnaliste-raciste-nazi-qui-vote-fn...
Pour ceux qui ont envie de comprendre le fonctionnement de nos institutions, il y a heureusement l'UPR.
Rendre son site web accessible. Bon article
Types de requêtes SQL avec la requête en dessous de son schéma pour mieux la comprendre.
Rapide, simple, efficace, pertinent.
Je ressors ce post qui date d'il y a 3 ans (septembre 2014) et il faut l'avouer, la communauté Scala semble être vraiment d'une mauvaise foi redoutable !
Qu'est-ce qui me permet de dire cela ? Regardez cet extrait (et il n'est pas le seul) :
// Java:
List<Integer> ints = new ArrayList<Integer>();
for (String s : list) {
ints.add(Integer.parseInt(s));
}
// Scala:
val ints = list.map(s => s.toInt)Pour rappel, Java 8 est sorti en MARS 2014, soit près de 6 mois AVANT cet article. Le mec compare encore Java 6 qui passait en support étendu à Scala et non Java 8 qui était ce que le langage savait faire de mieux.
Deux remarques :
1) Le code Java présenté est falacieux puisque le mec instancie sa liste en Java mais pas en Scala histoire de gratter quelques lignes.
2) Que pense-t-il de ce code Java 8:
// En considérant que la variable ints existe, sinon il faut ajouter List<Integer> devant :
ints = list.map((s) -> parseInt(s));Bref, de la pure mauvaise foi. Cela fait quelques semaines que je me suis mise à Scala et non seulement les arguments de la communauté Scala par rapport à Java 8 ne tiennent pas debout, mais l'ensemble des outils, des libs, des éditeurs, bref l'ensemble de l'éco-système Scala est misérable à côté de Java. Les temps de build sont atrocement longs (et je pèse mes mots, passer de Java 8 à Scala multiplie littéralement vos temps de build par 300 ; de quelques secondes à quelques quarts d'heure). Pis encore, vos libs ne seront plus compatibles d'une version du compilateur à une autre (seriously, un langage ose encore péter la compatibilité du bytecode en 2017 , dafuq les mecs !???)
Enfin, au vu des features de Java 8, il n'y a aucune raison valable de passer de Java 8 à Scala SAUF, si vous êtes un aficionados de la programmation fonctionnelle pure (qui reste une immense connerie d'académiciens AMHA).
En parallèle je suis en train de me mettre à Kotlin, et par rapport à Scala, c'est le jour et la nuit.
La syntaxe est meilleure que Java ET Scala (toujours de mon point de vue, peu de symboles obscur mais des mots-clefs simples et clairs, le paradigme Objet domine mais laisse place de manière pragmatique au paradigme Fonctionnel, les temps de builds sont semblables à ceux de Java 8, la compatibilité avec les versions plus anciennes de Kotlin est garantie et les binaires générés depuis un code Kotlin peuvent être utilisez de Java 6 à Java 8 et vice et versa ; sans parler de l'écosystème, de la doc et des IDE, des outils de build qui sont les mêmes qu'en Java 8.
Bref, je maintiens, Scala est un langage d'académiciens fait par des académiciens pour des académiciens, il est particulièrement difficile de couvrir des besoins industriels sérieusement avec quelque chose d'aussi peu mature.
En espérant en avoir aidé certains et agacé d'autres.
Rappelez-vous :
- L'argent liquide protège votre vie privée.
- L'argent liquide limite l'activité spéculative à cause du principe de montant de réserve.
- Sans argent liquide, plus de risque de bankrun puis de bankrout pour les banques, donc activités open-bar pour elles.
- Sans argent liquide, la saisie de 10% à 15% de votre argent sur vos comptes devient possible (comme le suggère le FMI et la Commission Européenne pour faire rembourser la dette française de force - alors que celle-ci ne devrait pas exister sans la perte de la création monétaire ex-nihilo que détenait l'État).
L'article traitant du sujet sur LME
Très très bel articles sur http://www.les-crises.fr relatant le fait qu'Asselineau avait bien raison : Jean Monet fût bien un agent de la CIA. Et très très belle analyse expliquant pourquoi Jean Monet était ce qu'il était, avec une remise en contexte, ce qui nous permet de comprendre qu'il y avait un homme derrière et non un simple traître à la patrie.
Quand les journalistes de grands médias comme Le Monde ou TF1 parviendront-ils à fournir ce genre d'article avec un tel niveau de qualité ?
Outch ! Je peux vous assurer qu'entre la programmation asynchrone, les générateurs, les itérateurs, les call-backs imbriqué et le mot-clef yield (qui à mon sens est un goto déguisé), cela va être de plus en plus compliqué d'appréhender JS pour le chaland.
Il faut vraiment s'y mettre maintenant, dans deux ans il sera trop tard.
Ou pourquoi les développements sont de mauvaise qualité et pourquoi il y a beaucoup de non-compétence chez les développeurs.
Voici l'une de mes bonnes résolutions de l'année : faire des articles se servant de la mise en forme Markdown de mon Shaarli. Celui-ci sera la première partie - de ce qui je l'espère - sera d'une longue lignée.
NPM C'est quoi donc ?
NPM c'est d'abord un acronyme signifiant Node Package Manager ce que l'on peut traduire par "gestionnaire de package de Node JS".
Le fichier 'package.json' c'est quoi donc ?
Tout comme il existe chez Maven, un fichier pom.xml qui décrit un projet, il existe un fichier package.json qui fait la même chose en Node JS.
Ok donc dois-je me servir de NPM comme outil de build ?
Eh bien non, désolé. En réalité vous pourriez, cependant JavaScript étant ce qu'il est, l'écosystème bouge tellement vite que la norme à adopter c'est YARN.
Ok mais qu'est-ce que YARN aurait de plus que NPM et justifiant son usage ?
Pour comprendre cela, il faut comprendre ce que fait NPM
- NPM va d'une part gérer (c'est-à-dire télécharger et mettre à jour) vos dépendances et les dépendances de vos dépendances. Nous parlerons alors de *gestion transitive des dépendances.
- NPM est également en mesure d'exécuter des commandes que vous lui aurez indiquer. Cela vous permettre par exemple de transpiler une application, de la packager ou encore de la déployer.
Parfait mais qu'est-ce que ne fait pas NPM alors ?
Eh bien deux choses :
1) Il ne met rien en cache, c'est-à-dire que NPM va retélécharger encore et toujours chacune des librairies que vous avez utilisé dans vos projets ; contrairement à Maven qui stocke dans le répertoire
$HOME/.m2/repositoryl'ensemble des librairies dont vous vous êtes servi au moins une fois.
2) Il gère votre build de manière séquentielle, ce qui est dommageable en termes de performances étant donné que nos processeurs sont tous multi-cœurs voire multi-cœurs et hyper-threads à ce jour.
Et YARN est une surcouche de NPM qui répond tout simplement à ces deux besoins.
Très bon article. Je sais combien je devrai mettre de côté l'année prochain. C'est toujours douloureux de se dire que l'impôt sur le revenu ne sert qu'à financer les intérêts de la dette de l'état que celui-ci n'aurait pas s'il créait sa monnaie lui-même... Mais bon