Antichesse (o ^ω^ o)
@Sweet le 9 c'est le plus compliqué quand on vient du procédurale et qu'on essaie de faire de l'OOP (note : l'API Java est procédurale à 99%).
Je l'ai compris grâce à des formations que des copains d'ITAMETIS m'ont offertes (merci @Kysofer pour tout le temps que tu as passé à m'appendre). En substance, dès qu'une classe affiche un getter ou un setter, alors son développeur a violé le principe d'encapsulation, ce qui est "anti-objet" par nature.
Dit autrement, nous mettons des get/set pour avoir bonne conscience mais nous pourrions les remplacer par des attributs public cela reviendrait exactement au même. En ajoutant des getter/setter nous exposons deux choses en les sortant de l'encapsulation :
- La valeur de la donnée
- Le type réel de la donnée (c'est de loin le pire)
Et ce type d'objets s'appelle : une structure de données. Les méthodes des autres objets appelant les get/set n'étant que des procédures décidant quoi mettre et quoi retirer de ces objets structures de données.
Alors cela m'a pris un bon moment avant de comprendre comment coder sans setter (pour l'immutabilité de la programmation fonctionnelle) et sans getter (pour respecter l'encapsulation de la programmation orientée objets) ; et bien sûr sans jamais remplacer l'un ou l'autre par des attributs publics. C'est ce que j'entends lors que j'écris "programmer en interface-first".
Le meilleur bouquin que je puisse te recommander à ce sujet est Elegant Objects de Yegor Bugayenko. C'est un solid 5/7 au niveau de la "disruptivité". Mais si tu fais du Java par exemple, alors tu devrais comprendre pourquoi ceux qui font "du vrai" OOP (pardon pour l'expression mais c'est à prendre au sens "ne violant jamais l'encapsulation") disent que Spring n'est pas orienté objet pour un sou et que le framework pousse à de la programmation procédurale comme en C ou VB.
Après c'est mon côté coach crafts qui incite toujours à mieux comprendre un paradigme de programmation et d'expérience maintenant, la grande majorité des développeurs ne creusent pas plus loin que les 75% d'un concept (ça descend en dessous des 20-25% pour l'objet et le fonctionnel car les "frameworks s'en occupent pour nous") et puis il faut aussi admettre que le procédurale est bien plus accessible quand on veut produire vite, même s'il est nettement moins maintenable.
C'est la première fois que j'entends Bruno Le Salé parler ouvertement de la lutte des classes et j'aime ça ! Je regarde de temps en temps ses vidéos, lui et moi n'étant pas des mêmes bords en politique, c'est souvent difficile de l'écouter mais comme il est un troll dans l'âme et que j'ai grandi entourée de trolls depuis l'enfance, j'arrive à passer outre et à m'en divertir assez facilement.
Depuis quelques temps, il se lance dans l'analyse et même si ça n'est pas parfait, c'est toujours 100 fois + une mieux que BFM TV à mon humble avis. La vidéo vaut le coup d’œil dans le sens où elle recontextualise le mouvement BLM vis-à-vis des enjeux gravitant autour de l'élection présidentielle américaine, des intérêts financiers présents derrière et du fait que le présumé pédophile (selon internet) le tendancieux Joe Biden remonte en flèche dans les sondages face à Trump.
Bref, je vous invite à écouter / regarder cette vidéo. Par contre je colle à Bruno Le Salé un petit -1 pour la flemme qu'il a eu de mettre les sources en commentaire de vidéo (même si comme il le dit lui-même, celles-ci figurent en incrustation dans la vidéo).
J'avais entendu le nom il y a quelques années mais n'ayant pas plus creusé le concept je l'avais oublié. Le hasard du destin me fait retomber dessus aujourd'hui. Bref il s'agit de 9 règles de programmation à appliquer.
En résumé :
- N'utiliser qu'un seul niveau d'indentation
- Ne pas utiliser le mot-clef ELSE
- Encapsuler toutes les primitives et les String dans des objets
- Encapsuler les collections dans des objets
- N'enchaîner qu'un seul point (ou flèche) par ligne
- Ne pas utiliser d’abréviations
- Garder des classes petites (moins de 50 lignes)
- Aucune classe ne doit avoir plus de deux instances en guise de variables
- Ne jamais utiliser de Getter/Setter
Globalement, je le fais sans m'en rendre compte, mes classes sont minuscules (20 lignes en moyennes). Éventuellement le ELSE m'est encore utile mais c'est vrai que programmant en fail-first je lui préfère un throw direct et donc qu'il n'apparaît vraiment pas souvent.
Bon cela faisait quelques temps que je souhaitais ouvrir un compte ailleurs et j'étais plus que tentée par la N26. Aujourd'hui je me réveille enfin motivée et j'y vais, je me lance ! (^__^)/
Première impression : tout est facile, créer un compte est facile, choisir un mot de passe est facile, se déclarer est facile. D'ailleurs enfin une banque qui ne vous impose pas un code pin minable à chiffre sur un clavier virtuel pété pour sécuriser vos comptes faire de la merde comme toutes les autres.
Et puis je m'arrête à la dernière étape car bloquée ! But WHYYYYYY ??? (T_T)
Parce que la banque impose à ses clients une "appli-mobile" pour finaliser leur inscription, "appli-mobile" qui ne peut se récupérer QUE depuis le Google Play Store ou l'App Store. Or je me suis dégooglisée il y a bien longtemps et plutôt crever que d'y retourner.
Après je me dis que j'ai les moyens de m'acheter un téléphone bidon et de l'associer au forfait Free à 0€/mois donc pourquoi pas ? Et puis je commence à lire les CGU... Et là c'est le drame...
On est en 2020 et la N26 gère sa sécurité en liant votre compte à votre mobile... Je vais le dire autrement :
- Votre mobile casse => plus aucun accès à vos comptes.
- Votre mobile est volé => plus aucun accès à vos comptes.
- Votre mobile tombe en panne => plus aucun accès à vos comptes.
- Votre mobile est télé-bloqué => plus aucun accès à vos comptes.
Vous comprenez, ce n'est pas le numéro de mobile mais le périphérique lui-même qui est attaché au compte... Périphérique que nous laissons traîner partout et bien souvent à la durée de vie minime...
Ce fût donc un beau et merveilleux NO GO pour N26 (à la toute dernière étape) parce que la banque-mobile n'est pas capable en 2020 de permettre à ses clients de passer par un site web. D'autant que faire une web-app hybride Android / iOS ça ne coûte rien avec du PhoneGap + Aurelia/React/Angular/Vue/Nimporte-quelle-techno-à-la-mode.
Bref, j'avais pas mal d'argent à leur donner dommage pour eux. En même temps je n'ai pas été très maligne car en lisant l'appellation "banque-mobile" à aucun moment je ne me suis imaginée que la banque n'était QUE sur mobile... Je n'arrive pas bien à comprendre la logique derrière qui consiste à se fermer un marché mais admettons.
P.S : félicitation à Daniel de leur support qui a été d'une grande patience avec moi aujourd'hui.
Note personnelle : je n'aime vraiment pas du tout la syntaxe de Rust, mais vraiment :(. À chaque fois que j'en fais je meurs un petit peu. Après je maintiens qu'il s'agit d'un des meilleurs langages du marché à cette heure et une tendance de fond qui me pousse à prendre la vague.
Bon je vais reprendre le début du kata @Kysofer (qui va me faire intervenir dans ses formations) pour montrer comment il programme en OOP "pure" avec Rust en mettant en place une encapsulation stricte (à la Yegor Bugayenko). Le poste se fera en plusieurs parties, cette première étape consistant à montrer comment fonctionnent les trait, les struct et la notion de value borrowed pour les débutants.
Objectifs du kata :
- Fournir deux structures différentes permettant l'addition.
- Décorer la première structure par la seconde.
- Introduction succincte au
value borrowed.
Code :
#![allow(non_snake_case)] // Oui je viens du monde Java/Kotlin
// Structures
struct Couple {
opA: i32,
opB: i32,
}
struct Triplet {
opA: Couple,
opB: i32,
}
// Interface
trait Addition {
fn add(&self) -> i32;
}
// Implementations
impl Addition for Couple {
fn add(&self) -> i32 {
return self.opA + self.opB;
}
}
impl Addition for Triplet {
fn add(&self) -> i32 {
return self.opA.add() + self.opB;
}
}Exécution :
Pour instancier et exécuter le code il faut écrire ceci. Tout marche, aucun problème.
fn main() {
let additionA = Couple { opA: 1, opB: 2 };
println!("Couple add : [{}]", additionA.add()); // Print 3
let additionB = Triplet {
opA: additionA,
opB: 3,
};
println!("Triplet add : [{}]", additionB.add()); // Print 6
}La petite difficulté (el famoso "value borrowed") arrive dès que l'on initialise les deux structures l'une derrière l'autre :
fn main() {
let additionA = Couple { opA: 1, opB: 2 };
let additionB = Triplet {
opA: additionA,
opB: 3,
};
println!("Couple add : [{}]", additionA.add()); // NE COMPILE PAS
println!("Triplet add : [{}]", additionB.add());
}En réalité, au moment du premier println!(), la variable additionA n'est plus dans l'espace courant mais a été empruntée par Triplet, elle se retrouve donc utilisable mais uniquement par lui. Alors soit on réordonnance le code (ce que j'ai fait dans la première exécution qui fonctionne) soit on indique que Triplet restitue la variable qu'il a emprunté (je montrerai plus tard comment faire).
Bref, jusque là rien de transcendant nous remarquerons quand même que Triplet contient un Couple (c'est-à-dire une structure) et non une Addition (c'est-à-dire une interface) ce qui matérialise un couplage fort entre les types et donc l'impossibilité de programmer par contrat (c'est-à-dire en masquant les implémentations et en protégeant l'encapsulation des données contenues dans la structure Couple).
C'est là qu'arrivera la second difficulté dont je parlerai aussi plus tard : comment calculer dynamiquement les tailles des implémentations des traits pour les utiliser en tant qu'attribut d'une structure.
Avis personnel : depuis quelques mois que je m'amuse avec Rust je peux dire que globalement j'aime ce langage mais cela ne m'empêche pas de le trouver pauvre sur pas mal de ses aspects (au sens paradigme de programmation).
Dans ce qui me déplaît, je mettrais la forte emprunte qu'il retire C et du C++, notamment leur style procédurale omniprésent (on ne code plus comme en Pascal en 2020, damned), l'encapsulation découragée totalement (en ce sens Rust n'est pas objet pour un sous, et la programmation en structure-first est un anti-concept, encore une fois cf. Elegant Objects de Yegor Bugayenko) et pour ma plus grande tragédie, une syntaxe que je trouve lourdingue car s'appuyant sur beaucoup de symboles ou trop peux expressive (je suis navrée pour ceux qui pensent que i32 et u32 sont de bonnes façons d'écrire des entiers signés ou non en 2020).
Encore une fois, la syntaxe de Kotlin (sauf le sucre syntaxique du préfixe get/set et les equals methods), l'API immutable de Kotlin, la gestion des Threads/KoRoutines de Kotlin, le null-check de Kotlin, le tout mêlé au Owernship de Rust, à la performance du binaire produit par son compilateur, à sa capacité à gérer du bas niveau, tout ceci en ferait sûrement l'un des langages les plus efficaces et fiable du siècle.
Je prie pour que Kotlin Native soit un "game changer" notamment pour qu'il parvienne à s'élever au niveau de Rust en terme de performances et de protection contre les race-conditions.
Je me le note, merci à JcFrog pour le lien.
Sans blague... Utiliser un des compilateurs les plus difficiles du marché (ici Kotlin) prévient une grande partie des bugs et réduit leur nombre de 33%, le cas présent sur l'application Google Home depuis Que Goole a remplacé le code en Java par Kotlin.
C'est un peu comme si les langages interprétés et sans contrôles ultra-stricts à la compilation étaient moins efficaces... La surprise est totale ! (Ô__Ô) #Kotlin #Rust
Tiens j'entends comme un écho qui dénigrerait Python... Et quelqu'un d'autre qui tousse très fort JS/NodeJS... Vraiment bizarre, allez savoir pourquoi #TrollInsideOuPas
J'ai retrouvé le "Solid 5/7" de Brendan Sullivan et Robert Graves. C'est tellement méchant que c'en est drôle.
Comprendre comment associer les couleurs entre-elles.
J'apprécie fortement l'effort fait par le vidéaste pour expliquer l'ensemble des types d'associations possibles en les illustrant par des exemples simples.
Sinon je me remets au dessin que j'avais mis en pause depuis quelques temps par manque d'inspiration. Merci à @Strawberry qui fût à l'origine de ce redémarrage même si elle ne se doute de rien.
Je cite le secrétaire d'état Mounir Mahjoubi :
[...] Sur un site de rencontres, je veux bien que tout le monde s’appelle Robert234 ou Angeline2828. Chacun doit pouvoir choisir son pseudo et sa vie virtuelle. Mais quand on est sur un site de démocratie participative, notamment les dispositifs numériques pour que les citoyens puissent s’exprimer régulièrement, faire des pétitions légales, je ne veux plus que ce soit anonyme [...]
Donc si je résume la pensée :
- Pour la drague en ligne qui a peu de conséquence finalement => L'anonymat c'est OK
- Pour tout ce qui est pétition et où l'anonymat empêcherait d'identifier des opposants politiques => L'anonymat c'est KO.
J'ai bon ?
Dans une second mesure, la Démocratie est par essence "participative". Si les citoyens ne participent pas, alors le Kratos n'appartient plus au Demos (le pouvoir n'est plus au peuple).Il faut toujours se méfier des politiques qui usent de la novlangue.
La démocratie, enfin je dirais la "vraie démocratie", c'est voter les lois nous-mêmes et non laisser des représentants d'intérêts privés voter ce qu'ils veulent, sans nous consulter et sans conséquence pour leur carrière.
@Bill2 : j'ai tout écouté ce soir, merci sans toi je serai passée à côté.
Bon le côté suffisant d'AstronoGeek m'a toujours énervée mais honnêtement les deux vidéos sont très bien, l'argumentaire est construit et on comprends parfaitement que le tweet d'origine était un moyen pour AstronoGeek de mener une expérience sociale qui est partie totalement en cacahuète (en même temps Twitter c'est un petit peu la poubelle du net, je ne le blâme pas, il a été aussi malin que les gens dont il se moque à longueur de temps. Je vous ai dit que je n'aimais pas trop le personnage ? Bref).
Par contre, je ne peux m'empêcher de faire le lien avec ce post de HowTommy qui relaie un Tweet répertoriant justement les youtubeurs estampillés #BalanceTonYoutubers. Or AstronoGeek y figure à cause du "vrai-faux-post" qu'il a publié pour "trigger" les SJW et ainsi récupérer suffisamment de données pour mener son expérience sociale.
J'invite ceux qui me lisent à se méfier de plus en plus des reposts de tweets, sans commentaire ni analyse, qui pop sur nos rivers car cela les transforment en Twitter bis et met en avant l'émotionnel, le ressenti au détriment de la raison, la logique et les faits. Après ce n'est que mon humble avis.
En résumé, ne nous twitterisons pas. Un Shaarli est justement un outil parfait pour exprimer un point de vue complet, argumenté, construit et sans censure dont la décentralisation en fait un anti-Twitter par excellence. Reposter des tweets sans recule ni commentaire revient à utiliser Twitter tout en perdant son temps pour administrer l'instance de son Shaarli. Je n'en comprends pas vraiment la raison ni l'utilité. Avoir bonne conscience ? Se sentir différent tout en faisant comme les autres ?
Je ne dis pas que tous les tweets sont stupides et qu'il ne faudrait en reposter aucun, je dis que retweeter un tweet en le croyant sur simple publication, sans le commenter et depuis son Shaarli, revient à utiliser Twitter comme les Twittos (peut-être en se pensant différent mais en agissant pareil sur le fond) ; surtout lorsqu'il s'agit d'un thread purement basé sur le lynchage public de personnes dont nous ne connaissons pas la vraie vie et dont la seule motivation est la destruction totale de quelqu'un. Cette violence abjecte est la caractéristique d'un ressenti façonné à partir d'une morale d'esclave (cf. Nietzsche).
Dans tous les cas, les deux vidéos sont à écouter/voir.
Savoir si votre banque est couverte par le Fond de Garantie des Dépôts et de Résolution (qui est de 100 K€ à cette heure).
Voici un lien vers le PDF des établissements répertoriés.
Edit : pour ING Direct (qui me concerne), la banque n'étant pas française, elle ne dispose pas du FGDR mais elle dispose de son équivalent néerlandais qui fourni les mêmes garanties. Ouf, je suis "sauvée" #AnticiperLaCriseAprèsLeCovid
Edit 2 : en ce qui concerne la N26, tout comme ING Direct celle-ci n'est pas garantie par l'état français mais par la Bundes Bank (banque centrale allemande).
Je traduirai plus tard, je suis sur mobile.
C'est moi ou https://river.libox.fr/ est devenue la river personnelle de Sebsauvage ? Toujours des problèmes suite à la panne d'il y a deux semaines ?
Je résume l'idée :
1) "Will" s'utilise pour les prédictions (il va pleuvoir), l'expression d'une caractéristique (le fer va rouiller sous la pluie) et la volonté (je ne ferai pas ça).
2) "Shall" s'utilise pour exprimer une contrainte (vous ne passerez pas) ou une suggestion (est-ce que tu veux de l'aide).
Prenons deux exemples :
-
Will we see each other again ?
- Traduction : Nous reverrons-nous ?
- Sens : c'est une simple question.
-
Shall we see each other again ?
- Traduction : Est-ce qu'on pourrait se revoir tous les deux ?
- Sens : j'aimerai que nous nous revoyons, est-ce que ce serait possible ? (c'est là qu'émerge la notion de suggestion/contrainte)
En espérant que ça puisse aider quelqu'un.
Alors ce tutoriel est très bien pour ceux qui souhaitent apprendre la syntaxe du langage par contre en aucun cas il ne correspond au titre de l'e-book dont il est un chapitre : "Introduction au langage Kotlin, découvrir les notions avancées de la programmation orientée objet".
En rien l'article ne parle d'OOP et de ses concepts avancés, bien au contraire il met en avant les aspects du langage qui poussent à la programmation procédurale réalisée à partir de structures de données façon C/VB/PL-SQL et je m'explique.
Lorsque vous créez une classe avec des getters et des setters, vous ne faites ni plus ni moins que de créer une structure avec des attributs public déguisés en attributs privés. Fondamentalement, même si c'est au travers d'une méthode, vous permettez à n'importe quelle autre classe de violer l'aspect le plus fondamental de l'OOP : l'encapsulation (je vous invite à suivre les tutos de @Kysofer sur le sujet, c'est un grand gourou du domaine).
D'ailleurs, et pour reprendre l'un de ses cours, l'encapsulation c'est deux composantes :
- Personne d'autre que la classe ne peut connaître (et encore moins modifier) les données qu'elle contient.
- Personne d'autre que la classe ne peut connaître le type réel des données qu'elle contient.
Avec un exemple simple, si j'ai cette horreur (du point de vue de l'OOP) :
val name:String = person.getName()`
person.setName("my-name")`Alors cela revient exactement au même que d'écrire :
val name:String = person.name`
person.name = "my-name"Cela est tellement la même chose que Kotlin l'assume et génère à la compilation, à partir des getters/setters, le code du second exemple pour permettre l'accès en public aux attributs.
Mais là n'est pas le problème, en effet le vrai problème est que si je venais à changer le type interne de name pour le passer d'une String à un nouveau type, par exemple appelé Name, alors il faudra que je modifie TOUS LES APPELS EFFECTUÉS à getName() car les codes appelant s'attendent à une String, rien n'est encapsulé, rien n'est masqué, a contrario toute la représentation interne fuite à travers les getters/setters et les gens appellent cela innocemment de l'OOP alors que ça n'en est pas du tout : ce sont des struct déguisées en objets.
La solution consiste à n'utiliser que des interfaces car par essence, une interface ne peut pas avoir d'attributs. Alors certes les dérives depuis Java 8 et certains anti-patterns de la programmation fonctionnelle (du point de vue de l'OOP toujours) ont eu tendance à modifier le langage mais dans la pratique, c'est vraiment une très mauvaise idée de mettre des attributs/constantes dans une interface.
Je sais que @Kysofer et @Lenny réfléchissaient à faire des tutos sur l'OOP sur Youtube/PeerTube, j'espère que ce post va les motiver à passer à l'acte. D'ailleurs je partagerai toutes vos vidéos mes chéris :) #Waiting
Edit : je complète la liste:
J'ai fait le test et le numéro de TVA de mon entreprise n'est pas le bon. Du coup il faut d'abord que je m'assure que les données soient bien à jour côté greffe avant de remonter un problème côté service.
Pour tout le reste : c'est top ! Je valide !
Via Sebsauvage.
Microsoft qui fait la promotion de Rust (O__O). J'étais passée à côte de ça. Bon bah pour une fois merci à l'un des plus dangereux ennemis du logiciel libre.
Ohhh ! Pardon je veux dire
OHHH !!! (O_O)
Je ne migre pas les projets vers Gradle uniquement parce que le build n'est pas paramétrable et parce que je ne parviens pas à partager plusieurs configs de build entre deux projets (cf. principe de standardisation du processus de build/check dans une entreprise).
Et là @Philou m'apporte un début de solution sur un plateau. On devrait tous avoir un @Philou chez soi (^__^).
Je cite une phrase de l'article :
[...] Slave fait partie des mots à éviter et à remplacer par secondary, subordinate, replica ou follower [...]
Des "mots à éviter"... Peut-être que Dan Williams pense qu'il ne faut pas dire "merde" parce que c'est un "gros mot", ou peut-être pense-t-il même que certains mots devraient être interdits car vous comprenez une onde sonore ça peut être dangereux... Je ne veux pas élaborer ici une homme de paille mais c'est pour vous faire passer l'idée qu'un son reste un son point.
Nos confrères informaticiens outre-atlantique sont en train de créer une novlangue, ou plutôt une langue pure et propre, blanchie pardon je veux dire nettoyée... #ExpressionRaciste Je suis désolée mais j'en ris jaune pardon, je fais semblant d'en rire #ExpressionRaciste2... Avec ces deux exemples, sentez-vous venir la vague de novlangue fondée sur la plus magnifique des "bien-pensances" ? Car oui il y a des gens qui pensent mais ils pensent mal... À quel moment nous sera-t-il confortable de vivre dans un monde où nous devrons être sur le qui-vive pour éviter que notre langue "ne fourche" aux yeux et aux oreilles des autres ?
C'est un petit peu le même problème que la vie privée si vous voulez, car si moi je considère que ce que je fais est légal et juste, comme ce n'est pas moi qui me jugera mais des tiers, rien ne me dit que eux considéreront que ce que j'ai dit soit "normal" et surtout "non-raciste"... Et rien ne me dit qu'ils ne me feront pas payer les conséquences de leurs jugements personnels basés sur leurs ressentis tout aussi personnels et que je ne peux deviner car au cas où vous ne le sauriez pas : NOUS NE SOMMES PAS TÉLÉPATHES !
Je l'ai expliqué dans ce post que je ne voulais plus JAMAIS vivre sous la peur de dire ce qu'il ne fallait pas. Je ne veux plus connaître cette maltraitance psychologique, cette horreur au quotidien. J'en suis limite arrivée au point de troller et de proposer de remplacer les termes "master" et "slave" par "hetero-cis-white-male" et "nigger" histoire de bien montrer la différence entre la volonté de décrire le fonctionnement de quelque chose et la volonté de nuire à quelqu'un par les mots et les références ; parce que vraisemblablement, une minorité très bruyante de personnes ne parvient pas à faire la distinction.
Dans tout cela, je ne pense pas que Dan Williams ait eu spécialement l'envie de changer toutes ces appellations car cela engendra beaucoup de travail pour une valeur quasi nulle. Par contre j'ai l'intime conviction qu'il s'exerce en ce moment une pression colossale sur les épaules des leaders des grands projets. Leur place étant avant tout due au respect et à la réputation qu'ils ont acquis au fil des ans, alors dans cette période tragique, ils ne peuvent que se soumettre au diktat des suprémacistes noirs qui ont gangrenés le mouvement BLM, afin de ne pas être passés au bûcher car ils seraient devenus "politiquement incorrects". Ces leaders risquent en ce moment de perdre l'investissement de toute leur vie de travail bénévole et acharné et donc pour la plupart ils se soumettent car pas d'autre choix que de montrer patte blanche pardon de coopérer. #ExpressionRaciste3 #BienPensance #Morale
Une réputation c'est dix ans pour la construire et quelques minutes pour la briser.
Proverbe
Enfin, et pour ceux qui avanceraient que le concept de suprémacistes noirs n'existe pas, je rappelle que l'idée du racisme systémique a été soutenue par le mouvement des blacks panthers dont certains leaders souhaitaient une inversion du système de domination qu'ils décriaient eux-mêmes. J'ajouterai cette vidéo car peut-être que si un homme noir le dit en commentant une scène où d'autres noirs armés parcours les rues d'une ville en plein jour, scandant "black power", et arrêtant les automobilistes blancs pour les intimider et les menacer alors cela aura plus d'impact que les écrits d'une femme blanche (on en est réduit à cela oui) :
Mais imaginons l'inverse ! Imaginons des blancs faisant pareil et scandant "white power", tout en défilant armes aux poings dans les rues d'une ville et se divertissant à arrêter tous les noirs qui circulent dans leur voiture !? Nous serions tous en train de manifester par soutien et solidarité contre ce racisme évident ! Mais fort pratique, le concept de racisme systémique protège ces suprémacistes noirs qui peuvent faire ce qu'ils veulent sans que l'on puisse ne serait-ce que les critiquer ouvertement (car oui, pour ma part je n'oserais certainement pas écrire cela sans mon pseudonymat, la situation me fait trop peur et pourtant je n'insulte personne). #DeuxPoidsDeuxMesures
Par pitié, n'importons pas sur notre territoire les problèmes du communautarisme américain. Notre pays s'est fondé sur le vivre ensemble, au point que cela est littéralement devenue notre devise nationale : Liberté Égalité FRATERNITÉ. Pas de distinctions dans la couleur, dans la religion, dans le sexe, juste tout le monde ensemble au sein d'une seule et même nation. #Rousseau
Ne nous trompons pas de combat !
EDIT : je n'avais même pas fait attention au titre de l'article « la vision globale des relations entre races ». Comme si plusieurs "races" existaient au sein de l'humanité !!! C'est vraiment un problème importé tout droit des USA. #Soupir