Antichesse (o ^ω^ o)
Je pense qu'il ne faut pas forcément diaboliser la NEF pour les croyances de quelques personnes de sa direction (car oui 100% de ses salariés ne sont pas dans le délire de la mouvance new-age qu'est l'anthroposophie).
Prenons un pas de recul si vous le voulez bien.
Des gens croient que le père-noël a créé l'univers et observe en permanence tout ce que nous faisons pour nous juger parce que c'est un gros creep. Et comme le monsieur interdit de la bouffe, des médocs ou même des transfusions sanguines, bah des personnes meurent (oui les interdits changent en fonction du père-noël parce qu'il y en a plusieurs).
D'ailleurs je connais personnellement des dirigeants de grandes banques qui ne démordent pas de son existence et personne ne sourcille. Bref, une croyance religieuse est pour moi archaïque, fausse et dangereuse et c'est exactement ce qu'est l'anthroposophie mais faire le procès de la NEF juste sur ça c'est ne pas voir la poutre à côté de la paille.
Qu'en est-il du reste alors ?
En face de la NEF il y a les grandes banques institutionnelles qui :
-
Spéculent sur les denrées alimentaires (l'anthroposophie est sans conséquence en comparaison).
-
Accroissent chaque année leurs activités de trading à haute fréquence (et donc de l'augmentation des bulles financières mortifères pour l'économie réelle).
-
Fraudent en continue sur les taux (Libor / Euribo) sans conséquence. Ce qui augmente le poids des dettes publiques et donc la paupérisation du pays.
-
Participent au blanchiment d'argent via des paradis fiscaux.
-
Financent des industries polluantes.
-
Financent des marchands
d'armesde mort. -
etc
Après je comprends que le délire bobo new-age fasse peur, mais un démon tentaculaire bien plus puissance et dangereux se tient juste à côté et l'article aurait dû en parler pour mieux comprendre le choix fait par la ville de Rennes ; plutôt que d'écrire un pamphlet sur la NEF qui pèse même pas 1/100e de la BNP ou la SoGé.
En contrepartie, la NEF fait preuve d'une transparence nette sur tous ses produits, services et agissements depuis des années... Mais certains de ses dirigeants sont dans le délire new-age...
Pour moi il n'y a pas vraiment de dilemme lorsque l'on compte les pour et les contre mais encore une fois, ça touche à du religieux dont le pathos l'emporte sur le logos.
Ça me donne vraiment le sentiment d'un article sponsorisé par une grosse banque, ou s'y serait glisser une réduction ad hitlerium, afin de décrédibiliser un concurrent qui parvient enfin à conquérir un gros marché public bien juteux, autrefois autrefois réservé aux banques institutionnelles.
Je suis tombée sur cet article d'analyse (et d'anticipation) très conspi qui parle du Great Reset et d'un tas d'autres choses qui y sont liées ou en découlent. Une lecture tip-top pour les trajets en rentrant du boulot.
@Animal c'est pour toi, fais toi plaisir :P
Article racoleur mais la réponse à la question est simple à mon avis : aucun.
Quand vous êtes développeur vous codez, les générateurs de code sont là pour des gens qui ne codent pas ou ne veulent pas coder.
Rappel des problèmes inhérents à tout générateur de code :
-
Le code produit par un générateur a une qualité plafonnée par le niveau de compétence du développeur qui a codé le générateur.
-
Pour bénéficier des innovations, des correctifs de sécurité, des améliorations technologique, des nouvelles pratiques de développement, il faudra toujours attendre que le générateur soit patché, ce qui peut ne jamais arriver ou arriver dans un sens qui n'est pas celui que vous espérez.
-
Les "IA" ne fabriquent pas du code mais copient-collent du code tiré des bases de sources gigantesques sur lesquelles elles ont "apprises". Ce faisant le code produit l'est sous licence (coucou copilot).
-
Le code produit par un générateur a une architecture pré-conçue et figée, il est extrêmement difficile d'en extraire des composants (majoritairement tout se fait par couche, coucou JHipster).
-
Le code généré n'est jamais testé (ou alors trèèèès rarement). Donc le patcher / en modifier le comportement implique un énorme risque de régression.
-
Les applications générées souffrent de leurs propres bugs mais également des bugs du générateur.
-
Le code produit par le générateur ne collera jamais "out-of-the-box" aux contraintes techniques ni aux choix de l'entreprise, il faudra toujours l'adapter avec les difficultés citées plus haut.
-
Les choix techniques faits par les développeurs du générateur seront vos choix futurs, vous perdrez tout contrôle sur la technique. Cela revient à outsourcer l'intégralité de ses développements chez un tiers qui n'a aucun compte à vous rendre.
-
Il faut quelqu'un de formé à l'emploi du générateur pour le manipuler correctement, mais il faut en même temps que cette personne ait des compétences en développement pour s'assurer que le code généré convienne a minima aux attentes techniques. Les développeurs sont déjà des ressources rares, avec ce critère en plus ils deviennent des ressources rarissimes et se transformeront naturellement en SPOC (Single Point Of Failure) pour l'entreprise.
Comme le dit l'article, la génération de code n'est pas nouvelle, la grande mode du MDA (Model Driven Architecture) dans les années 2000 s'est terminée par une baffe car rappelons-le : une spécification qui décrit exactement ce que le programme doit faire, ça s'appelle du code.
Tout est dans le titre.
J'ajouterais (s'il le faut) que je ne suis pas d'accord avec la théorie de l'UE dans ce projet de contrôle des masses car cela permettra peut-être (j’insiste sur le peut-être) de protéger les enfants mais que cela permettra assurément de traquer les opposants politiques, religieux, syndicalistes, etc.
La construction européenne actuelle est un projet totalitaire et fasciste. Certains le dénoncent depuis 30 ans, d'autres croient encore au mythe de l'union des peuples aux intérêts divergeant et emportent avec eux tous les autres dans un piège qui se referment sur nous tous.
Dans tous les cas, les oligarques et milliardaires gagnent.
Article très intéressant que m'a proposé @Chlouchoutte sur comment les individus d'une entreprise se passent la patate chaude, à savoir le TAF ici appelé The Monkey.
Je ne peux que vous recommander sa lecture surtout si vous gérez une ou plusieurs équipes, ce qui est mon cas.
A quoi reconnaît-on un article pourri ?
- Il dispose d'un titre provocateur => Check
- Il généralise une population => Check
- Il traite d'un article dont le sujet est volontairement clivant => Check
Réaffirmons certaines choses :
- Tous les Russes ne sont pas Poutine ou des dirigeants Russes.
- Tous les Russes ne sont pas d'accord avec leur gouvernement (mais n'ont pas forcément les moyens de l'exprimer en toute sûreté).
- Les orientations politiques, sexuelles ou religieuses ne regardent pas les licences de logiciel.
- Un logiciel libre qui octroie les 4 libertés en fonction des préférences des gens ou de la géopolitique n'est pas un logiciel libre.
- GitHub appartient à Microsoft qui sert les intérêts des USA mais jamais les nôtres.
- Lorsque les USA attaquent des pays comme la Russie le fait avec l'Ukraine, personne ne se pose ce genre de questions.
Et le plus important : quand vous utilisez un logiciel libre ou un framework libre, backupez les sources chez vous !
Bref encore un article bien clivant comme il faut, tout droit importé des USA et visant à faire monter d'avantage la mayonnaise.
@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.