StyMaar a écrit 111 commentaires

Heureusement, il y a Grammalecte !

En fait en Breton il n'y a qu'un seul mot krampouezh.

Sauf que le Breton[1] n'est qu'une des 2 langues de Bretagne avec le Gallo, mais les bas-bretons ont tendance à oublier qu'ils ne sont pas les seuls bretons ;)

[1] en admettant qu'il n'y en ait qu'un seul.

Je confirme la galette n'existe pas dans le Finistère : son équivalent est la crêpe de blé noir. Mais attention ce n'est pas la même chose : la crêpe de blé noir est fine et croustillante, impossible d'en faire une galette-saucisse. La page Wikipédia de la crêpe mentionne d'ailleurs cette différence

Dans mon ancienne boite, des gens utilisaient influx et ils n'en n'étaient pas très contents.

Principaux griefs:
- très instable: pas mal de bugs, et les mises à jour apportant les correctifs entrainent souvent des régressions. Ils ont du rester très longtemps sur une vieille version malgré le fait que les plus récentes avaient des fonctionnalités dont ils avaient besoin, simplement parce-que les versions récentes avaient toutes des bugs critiques (quand tu ne peux pas remonter tes back-ups, c'est quand-même un peu chaud).
- scalabilité pas au rendez-vous : l'un des arguments d'influx c'est de tenir super bien la charge en écriture mais les résultats n'étaient pas du tout conformes aux attentes. Mes collègues avaient du faire leur propre agrégateur maison en amont d'influx pour envoyer moins de points sinon la base ne suivait pas.

Après, ça fait 1 an que j'ai quitté cette boite, donc Influx s'est peut-être améliorée depuis.

Pour la petite histoire, ils se traînaient influx qui avait été introduit dans la boîte par un ancien salarié au tout début de la boite, fanboy de Go (le langage) il avait décidé d'utiliser influx parce-que c'était écrit en Go (bonjour la décision technique éclairée).

Je rappelle pour ceux qui lisent que OCaml ou Haskell déduisent les types et vérifient leur cohérence sans aucune annotation de l'utilisateur.

Ils peuvent le faire, mais (dans la communauté Haskell du moins) il est généralement recommandé de mettre des annotations de type au niveau des fonctions, dans un but de documentation du code et pour expliciter les invariants, même si le compilateur serait capable de s'en passer.

Par exemple :

When writing our own functions, we can choose to give them an explicit type declaration. This is generally considered to be good practice except when writing very short functions.

http://learnyouahaskell.com/types-and-typeclasses
Qu'on peut traduire par : En écrivant nos propres fonctions, on peut choisir de déclarer explicitement leur type. C'est généralement considéré comme une bonne pratique, sauf dans le cas de fonctions très courtes.

Sinon, à mi-chemin entre Coq et des langages de programmation généralistes, tu as Idris. En plus il vient juste de sortir en version 1.0, ce qui stabilise pas mal de trucs.

Si tu veux du typage statique en Node (ou JavaScript en général), tu peux utiliser flow: tu rajoutes juste des annotations de type à ton JavaScript et un compilateur (écrit en OCaml) va vérifier que ton typage est correcte. Il est même capable de faire un peu d'inférence de type (mais pas dans tous les cas je crois). Le système de type est assez complet, avec des génériques, des types sommes et des objets non-nullables par défaut. Ce qui est bien c'est que ton code reste du JavaScript, contrairement a TypeScript, qui t'oblige à changer ton utilisation du langage.

contient exactement la même information que le message en Python :

Cette phrase était en réponse à Dinosaure qui disait :

Oui enfin Python n'a pas un algorithme d'unification derrière … Il faut comparer ce qui est comparable aussi (c'est pour ça que je compare pas cette problématique spécifique avec OCaml).

Mon argument était juste de dire que du point de vue de l'information disponible (pour le compilateur qui va générer le message) il n'y a rien qui manque en Rust qui lui permette de générer un message plus compréhensible.

Parce que clairement on est d'accord, le message en Rust est abscons tandis que le message Python est très clair.

Ce n'est pas pour autant impossible de faire un message clair: en pratique le message de Rust

the trait bound _: std::ops::Add<&str> is not satisfied [E0277]

contient exactement la même information que le message en Python :

TypeError: unsupported operand type(s) for +: 'int' and 'str'

À savoir qu'il n'y a pas d'opérateur défini pour l'opération entre un nombre et une string. On pourrait donc imaginer un message d'erreur dans ce style là :

TypeError: unsupported operand type(s) for +: {integer} and '&str'
the trait bound {integer}: std::ops::Add<&str> is not satisfied [E0277]

La côte bretonne n'est pas mal dans le genre aussi, même si elle est un peu moins régulière qu'un chou Romanesco (un peu comme l'ensemble de Mandelbrot est moins régulier que le flocon de Koch).

C'est vrai, mais en cas de fuite de la DB, même avec un seul hash, 10⁶ combinaison à tester c'est trivial à péter (même avec bcrypt ou pbkdf2).

Moi là où j'ai vraiment du mal avec mon FP2, c'est que je suis obligé de subir Android. L'UX est tellement pénible …

J'avais déjà entendu des gens venir d'iOS se plaindre de ça, moi je viens de FirefoxOS et c'est le jour et la nuit. Il faut en moyenne 2 fois plus d'opération à l'écran pour faire la même chose, le bouton retour a un comportement pas cohérent selon l'application dans laquelle on se trouve, toutes les animations sont lentes et pénibles, etc.

Maintenant je comprends pourquoi tous les constructeurs Android ont leur sur-couche maison !

Et oui, je pourrais mettre un autre OS dessus (j'ai cru voir quelque par qu'Ubuntu supporte explicitement le FP2) mais jusqu'à présent j'ai eu la flemme …

Sinon dans l'ensemble je ne suis pas mécontent de mon téléphone, même si le bouton de contrôle du volume m'a lâché (c'est un problème courant semble-t-il, il faut que je renvoie mon téléphone au SAV).

de creer une plateforme web qui s'inspire des principes de github

Au vu des screenshot, vous n'y êtes pas allés à moitié en vous inspirant de github, avec juste un petit croisement avec Twitter pour la page d'accueil. Au moins les gens ne seront pas perdus :).

J'aime bien l'idée du truc en tout cas. Par contre je n'ai pas bien compris à quelle stade vous en étiez de ce projet : dans ton journal tu parles de mockup (que je comprends comme croquis/maquette) mais après tu donne le lien vers un dépôt github qui a déjà une cinquantaine de commits et 9000 lignes de code depuis 2 mois. Du coup, vous en êtes où aujourd'hui ?

Je pense que le nombre de request est monstrueux et du coup les 0.00003% peuvent devenir significatifs.

0.00003% sur 1 Milliard ou 0.00003% sur 1 Trillard reste 0.00003% non significatif.
La valeur absolue n'a d’intérêt que pour ceux qui veulent trouver quelque chose de significatif en tordant la réalité.

Juste pour relativiser : 0.00003%, c'est 1000x moins que, par exemple, le pourcentage de femmes qui meurent en accouchant

Ce raisonnement est assez bête en fait, ce qui importe ce n'est ni le nombre total de requête affecté ni le ratio, ce qui compte c'est le nombre (ou le ratio) de personnes affecté. Comme très peu de françaises accouchent plus de 10 fois, la probabilité de mourir d'un accouchement dans sa vie est du même ordre de grandeur que la probabilité de mourir lors d'un accouchement en particulier.

Dans le cas d'HTTP la situation est bien différente: si je vais sur https://korben.info, mon navigateur fait une centaine de requête vers ce domaine par page chargée, admettons que j'aille 1 fois par jour sur ce site et que j'ouvre en moyenne 2 page, ça fait 200 requêtes effectuée par jours sur ce domaine. En 5 mois d'existence de la faille, ça fait donc 30 000 requêtes effectuées vers ce domaine. Là, d'un coup la probabilité qu'une de mes requêtes se soit retrouvée dans la nature avec un cookie d’authentification valide s'approche de 1%.

Bon OK pour Korben.info je m'en tape un peu. Si je regarde la liste des sites potentiellement affectés je vois des sites un peu moins anodins tels que transferwise.com, uber.com ou encore okcupid.com. OK les gens passent plus de temps à glander sur le net qu'à transférer de l'argent ou à commander des VTC, mais en 5 mois à raison de 2 courses en uber par semaine, ça fait encore plus d'une chance sur mille, et cela pour chacun des sites affectés : c'est clairement loin d'être négligeable.

Il y a donc bien un problème et il vient du fait que le nombre de requête effectuées par chaque personne est monstrueux.

Cette nouvelle m'a vraiment attristé.

Par contre je n'ai pas bien compris la position de Quicksaver dans cette histoire: lorsqu'il a repris le projet panorama abandonné par mozilla pour en faire une extension, les webExtension avaient déjà été annoncées, or il n'avait jamais parlé en public du problème que ça poserait à terme pour cet addon. Naïvement je pensais que qu'il avait prévu le coup et qu'il était tranquillement en train de faire le portage …

Ça me rassure un peu, j'avais du mal le lien entre e10s et la carte graphique. Par contre le passage à skia au lieu de Cairo pourrait poser ce genre de problèmes …

e10s était sur Nightly 1 an avant la version grand public

Bien plus longtemps que ça ! e10s est arrivé sur Nightly en début d'année 2014 ;)

Il faut dire que ça a été un chantier super long ce truc, j'espère que Quantum prendra moins de 8 ans à voir le jour !

(y en a toujours pour râler)

Heureusement qu'il y a des gens comme toi qui râlent, parce qu'après des gens leur répondent et du coup on est plein à avoir appris un truc aujourd'hui :D

Si tu appuies sur la touche MAJ de ton clavier en cliquant, c'est le menu contextuel de Firefox qui s'affichera, pas celui imposé par la page.

Effectivement, on dirait bien que Mozilla a un peu joué les Lucky Luke en sortant WebGL 2 avant que la spec soit officiellement ratifiée

Malheureusement c'est toujours comme ça que ça se passe sur le web, les trucs sont implémentés avant que la spec ne soit finalisée …

Pour webCrypto par exemple, quand j'avais eu à m'en servir (fin 2014) Firefox et Chrome implémentaient la même dernière version du brouillon mais IE 11 supportait une ancienne version (basée sur des callback et non des promise).

Pour webRTC ça donne une espèce de situation bizarre ou Chrome et Firefox supportent chacun une version différente de la spec' (elles sont inter-opérable mais l'API est légèrement différente) et aucun des deux n'implémente la dernière version en date du brouillon de spec' (et personne ne sait d'ailleurs quelle version exacte de la spec' est implémentée par chacun des navigateurs).

Évidemment, les navigateurs ne se privent pas pour rattraper la spécification de temps en temps quitte à abandonner la compatibilité avec l'existant. Pour Firefox c'est assez bien documenté et on sait à peu près à quoi s'attendre grâce aux canaux de distributions (nightly, devEdition et Beta) mais avec Chrome c'est le gros bordel: ce genre de changement n'est pas souvent documenté et il peut surgir d'un coup en version stable sans être passé par la beta …

Bref c'est à se demander à quoi servent les spécifications du W3C et ça donne envie de continuer à bosser dans le web …

je suis content de voir une deuxième réalisation concrète en Rust après Servo.

Je ne suis pas sûr qu'on puisse parler de Servo comme d'une «réalisation concrète», c'est avant tout un projet de recherche qui vise à expérimenter sur le parallélisme dans le navigateur, on est encore très loin d'avoir un vrai navigateur fonctionnel.

Firefox utilisant du Rust pour l'analyse des fichiers mp4 c'est un vrai projet concret par contre.

Niveau truc concret écrit en Rust, il y a aussi ripgrep qui est cool.

D'après le fil de discussion reddit d'où je tire le cloc, il semblerait que oui.

Bien vu ! Le bon lien était celui-ci : https://people.gnome.org/~federico/news-2016-10.html#25

Par contre je me demande comment j'ai fait pour mettre un lien vers le journal que j'étais en train d'écrire (et qui n'existait donc pas encore) …

Si un modérateur passe par là il peut aussi corriger ça :

s'est lancé dans une vaste chantier

une => un

La possibilité d'exécuter une commande, après chaque commit, lors d'un rebase, grâce à l'option -x : git rebase -x 'make test'

J'ai été assez surpris en voyant l'annonce[1], parce que ça laisse sous-entendre que l'option -x est une nouveauté, alors que ça n'est pas du tout le cas (sur ce PC par exemple j'ai la 1.9.1 et l'option est déjà présente).

J'ai l'impression (mais je peux me planter, je n'ai pas creusé plus que ça) que la nouveauté c'est la possibilité d'utiliser l'option -x même sans être en mode interactif : git rebase -x 'make test' n'est pas une commande valide sous git 1.9.1, il faut faire git rebase -i -x 'make test' et ça ouvre l'éditeur de rebase interactif.

[1] l'annonce officielle, pour sa part l'article en Français listé dans le journal donne bien la bonne explication.

J'ai répondu trop vite, j'avais pas vu la dernière proposition

Ce qui est bien c'est qu'avec 2-3 bricolages on peut aussi utiliser son serveur comme laptop. :p