Reprise du message précédent :

ouai je connais Blitzstream.
D'autres chaînes bien sympa aussi sont celles de GothamChess (le mec est bien marrant ) et celle d'AkaNemsko, par exemple. Il y en a plein d'autres, comme GMHess, GMNaroditsky (on est déjà à un niveau plus élevé), chess.com, ou pour les grosses grosses pointures Hikaru bien sûr et alirezafirouzjia, - probablement les deux plus forts sur Twitch -.

Mais en vrai ça fait très longtemps que je joue plus, donc je suis une brêle. Je crois que le meilleur que j'ai jamais été, c'était quand je jouais de temps en temps avec le champion de La Réunion quand on était ensemble en DEA à la fac. Il me battait environ 3 fois sur 4.

Habiter en ville c'est bien aussi pour les mômes. En particulier une ville comme Grenoble, petite et bien aménagée. Je suis un peu biaisé mais je n'ai jamais envié mes copains qui descendaient en bus de la montagne et se cognaient 45 minutes de car pour aller au lycée. Et pourtant je vivais dans une banlieue grises, comme disait l'autre, mais c'est jamais qu'à 15 minutes de vélo de ce qu'on veut dans le coin.

(Après je conseille pas le collège, mais ça m'étonnerait que Nico ait comme projet d'aller par là-bas.)

C'est surtout qu'avec Google Clips, le nouveau service de vidéo en ligne qui va bientôt remplacer YouTube, on n'a pas trop de ressources à mettre dans la maintenance de vieux produits désuets...

test négatif.

Commentaire intéressant: JDBC et libpq, c'est tout pourri, ça permet pas de faire des requêtes asynchrones et du processing par batches (je ne vois pas bien ce que ce dernier recouvre), et donc pas terrible pour quand le serveur ouaibe est fortement sollicité. Or Postgres supporte ça.

https://news.ycombinator.com/item?id=24315285

\o/

on va attendre que ma femme soit négative aussi (elle se fait tester aujourd'hui) ... et c'est les tests qu'on fera mardi qui finiront de lever définitivement tous les doutes.
en attendant on a pour le moment aucun symptômes tous les 2.  

yeah

pour avoir fait du node ( asynchrone) et du php en mode synchrone : la différence est largement moins grande dans el monde réel : tu auras un peu plus de worker qui vont avoir des connections ouvertes à la base de données, mais à moins de pouvoir continuer l'exécution de ton code sans avoir besoin du résultat de la requête ( ce qui est une situation rare) , ça ne change que les résultats de benchs.
Et si tu attends les résultats de plusieurs requêtes, pourquoi ne pas faire une seule requête ?

 
Après moi je parlais des enfants qui vont à l'école du village, pas des lycéens qui effectivement dans bien des cas doivent prendre un TEC qui la petite ville à côté n'a pas de lycée.
Et durant toute la période 0 à 11 ans, avoir un jardin c'est bien mieux que pouvoir aller au parc. Surtout qu'on est bien d'accord que de nos jours, tu ne laisses pas tes enfants ni même tes pré-ado aller au parc tout seuls.
Après, pour le collège / lycée, oui, ça se discute effectivement.  

Sous pg tu vas aussi avoir le problème qu’une connexion = un worker process, et tu peux naturellement pas multiplexer parce que les connexions sont pleines d’état.

Nous on est cas contact, on a passé un weekend avec quelqu'un testé positif mardi, donc je dois attendre quelques jours pour me faire tester

https://github.com/tpolecat/skunk  
 

Tu peux choisir de vivre dans un pays civilisé et de ne pas avoir une attitude de flippé avec tes gamins.
 
De nos jours ça veut dire quoi? Qu'est-ce qu'il arrive aux gamins qui vont jouer dehors en 2021 qu'il n'arrivait pas quand j'avais 10 ans?

 
Dans une grande ville, je laisserais pas mes enfants de 6 à 10 ans aller au parc tout seuls, traverser des rues etc... (le danger c'est pas forcément les gens qui trainent dans le parc (bien que si, aussi), je pense que rien que la circulation est nettement plus dangereuse) alors que dans mon jardin oui.

c'est exactement la meme chose ici, on etait chez des amis samedi AM (RAS pour eux a ce moment là, symptomes lundi, testé positifs mardi).
on se confine strictement depuis mardi midi.

Tu ne réponds pas à sa question.

Ca recouvre que sous certaines conditions le driver peux recevoir X query dans un certain laps de temps et batcher l'ensemble d'un coup pour réduire le cout réseau pour X requetes.
 
En gros au lieu de faire:
  - req => reseau => pg => response
  - tu as: req + req + req => reseau => pg => response + split
 
Ca ne peux etre avantageux que si tu es en async justement. En sync ca ne fera rien a part ralentir tout. Je suppose que c'est pour ca que libpq n'a pas cette fonctionnalité.
Ca aide un peu postgres et un peu ton serveur qui tous les deux font moins d'efforts pour le meme résultat. Ca casse de beaucoup la latence aussi car tu évites tout un tas de merde entre le req et réseau pour le driver (coté client donc), mais en contre partie ca veut dire que ton PG en face a intéret a etre solide.
Dans les faits c'est assez intéressant, surtout si tu montes en charge, a faible volume c'est transparent dans l'ensemble, donc si tu peux te le permettre fonce
 
 

 
C'est variable je pense, chez nous c'est un net gain, Ruby vs Node: 10x moins de serveurs. Car pendant que la réponse arrive ton node continue sa route, et rien que ca...
 
Enfin c'est assez étonnant ce que tu marques, normalement Node ecrase assez facilement PHP la plupart du temps, justement parce que async couplé au multi-thread (si tu fais bien les choses) va rapidement prendre beaucoup plus la charge que du multi-thread bloquant (logique)...
Cela dit ca fait pas mal de temps que j'ai pas regardé PHP je me suis arreté a la 7 je crois

Enfin Ruby Vs node, je ne suis pas sûr que ce soit le côté asynchrone qui fasse la différence, mais plutôt la quantité de gras  et de magie sur l'ORM Ruby
 
PHP n'est pas si bloquant que ça parcequ'il est multi processus, là ou node est , par défaut mono. Ainsi si un thread est bloqué, les autres travaillent : la gestion des attente est donc fait au niveau de l'OS plutôt qu'au niveau du langage et du code .

Grenoble, en été, c'est une vraie fournaise car c'est dans une cuvette quand même. Mais la ville est bien. Avec le réchauffement climatique, ça va pas s'arranger Ca va être un facteur à prendre en compte de plus en plus dans son choix de ville de résidence.
 
Le bon plan, c'est une ville ni trop petite ni trop grande (genre 15 à 20000 habitants), pas trop loin d'une grande ville (20-30 km) avec des transports en commun pour y aller (train, bus) et qui, vue sa taille, a donc un ou plusieurs collèges et un ou plusieurs lycées. C'est le cas de ma ville : on a 4 collèges (dont 1 privé) + 1 qui va se construire et 2 lycées (dont 1 pro). Du coup, y'aura que pour le post-bac que mes enfants devront aller à Toulouse ou ailleurs.
On a pas mal de parc, la Garonne pas très loin et derrière chez moi, ce sont les champs (même si ça commence à se construire aussi par là ).
Les impôts locaux, ça va. Notre ville fait partie des bons élèves. Il y a quelques années, la dette par habitant était l'une des plus faible (70€ de mémoire). Là, ça a dû un peu augmenter car il y a eu plusieurs investissements mais tout à fait utiles. Et l'eau, c'est la ville qui gère. Ils ont viré Véolia il y a quelques années. Résultat, on paye le m3 environ 2 fois moins cher pour une qualité d'eau identique voire mieux. Donc très content de notre choix de résidence
En plus, j'ai un intermarché juste en face de chez moi.

 
J'ai jamais traversé de rue pour aller au parc. Selon où tu habites, c'est franchement pas un problème (encore une fois, nettement moins que dans la campagne). J'avais un jardin, mais je préférais aller au parc.

 
On est d'accord
 

Tu tournes jamais node en mono thread hein, tu le balances dans PM2 (au minimum) et ca spawn a fond la caisse comme PHP. En gros t'a du non-bloquant en multi-thread.
 
Maintenant, si tu connais ta techno, et que tu maitrises, bloquer un process node faut y aller quand meme... Je vois un cas, qui est le coup ou Node s'écrase tout le temps, a savoir le calcul. Sinon pour un serveur "de base", a savoir, requete => BDD => réponse, la philo de Node est bien plus adapté. Car dans cette boucle, la majorité consiste a attendre
 
En mono thread, sur des codes live, et des machines AWS "standard", genre c5.large, on peut monter assez rapidement entre 1 et 3k requetes/sec par thread (suivant ce que l'on fait ofc). Justement parce que dans les Xms a attendre PG, le code part ailleurs tout simplement, et comme dit, on tourne jamais ca en mono thread en prod (mais on test toujours surtout le mono thread justement pour détecter si certaines parties sont bloquantes/charge trop le thread sans redonner la main).

Faut investir en Bretagne

avec PM2 tu lances par exemple 16 process. Si tu as 16 requetes bloquantes en // , tu es mort

avec PHP tu vas aller jusqu'a ta limite du nombre de worker (1024 par defaut sur nginx de mémoire), qui sont beaucoup plus léger que de dupliquer tout ton process avec son état

donc pour moi l'async est nécessaire sur node avec l'architecture de processus au long court, alors qu'elle est moins nécessaire en PHP. J'invoque ratibus

Yea requêtes blocantes j’ai tendance à présumer que tu t’en rends compte et tu as des utilitaires genre block_on qui te permettent de les bouger sur une threadpool dédiée?
 
Je m’attendrais aussi à ce que le système puisse tracer les requêtes qui bloquent (des requêtes longues mais qui ne yield pas).

 
Oui, enfin, je crois que des requetes bloquantes, qui font que tu es effectivement mort, franchement c'est pas tous les jours hein. Vu la charge qu'on prend ici je peux te garantir que c'est un probleme qui depasse largement la TPE/PME...
En 5 ans dans cette boite je crois que on a un endpoint connu pour etre vraiment bloquant (des GOs en ram, des manip d'array d'array d'array, et un PDF en sortie), et ce endpoint met a peu pres 30sec a sortir. Donc au pire du pire on peut tomber sur une situation ou un client est bloqué pendant max 30 secondes...
 
Mais, dans les faits, il se trouve que process.nextTick fait que ca passe dans le flux sans poser probleme, car au milieu du calcul lourd suffit de release l'event loop pour laisser node tranquile et batcher ce qui est en attente avant de reprendre. Aucun blocage effective sous la seconde avec ca, et le loop "long" met 31 sec au lieu de 30 a cause de ce trick
 
Ca place node dans une situation délicate par contre si 16 personnes sortent ce PDF en meme temps, et encore, ca va monter a une minute ou plus, pas si genant que ca dans les faits (enfin si c'est un burst isolé bien sur).
 
Je pense que, de toute facon, PHP ou Node (ou Ruby ou autre), ca tiens surtout de la connaissance de "comment ce que tu as choisis se comporte", et de ce dont tu as besoin (et ce dont l'équipe maitrise). Pour notre use case, on attends, on attends beaucoup, des webservices, des BDD, des... Donc node est tout indiqué.
Si on était dans du calcul scientifique, ou en tout cas si on avait pas mal d'endpoint "lourd", node serait a fuir, sans aucun doute, pour go, c, rust...
 

 
Sur des outils comme ab ca se détecte car au lieu d'avoir un temps de réponse stable tu te met a avoir un nuage de temps de réponse (car certaines sont bloqués en attendant, d'autre passe en premier & co), c'est assez caractéristique.
 
Donc tu vas avoir une courbe de monté en charge linéaire et a un moment tu vas commencer a voir la courbe ne plus etre sur le meme axe et devenir un nuage de points qui s'étale de plus en plus a mesure que la charge monte. C'est en tout cas comme ca que l'on mesure notre capacité a monter en charge ici, et ca semble cohérent avec les faits.
 
Apres comme dit a 1k requetes/sec/thread, dans les faits on est dans une situation comme ca quand la BDD déconne par exemple, dans un jour normal on est loin de cette limite.

 
Sur PHP t'es en monothread mais multiprocess, si je me goure pas. J'ai jamais vu d'appels asynchrone à des bases de données (je vois pas trop l'intérêt en PHP vu que 1 requête HTTP => 1 process).

 
Youtube et Search sont des machines à imprimer du fric. Même 5min d'outage sur 40% du traffic pique très très fort.
Donc clairement, c'est pas intentionnel. On a absolument AUCUN intéret à péter l'un des 2 trucs qui ramènent du pognon dans la boite, faut etre logique.

bon, on vient de faire offre

En cash  

 
https://www.bois.com/construction-r [...] 20portance

Feloches !

GG

Les achats immo c'est les meilleurs investissements qu'on ait jamais fait.
1er appart acheté en 2002 revendu en 2015
a permit de financer le second acheté en 2016 qui sera fini de payer dans moins de 3ans.

c'est un super investissement si t'achètes au moment où les prix sont bas pour revendre au plus haut, oui. Etonnant, non?

Je pense que je remplirai les critères me permettant d'acheter dans 20 ans Sauf que je serai trop vieux pour qu'on m'accorde un crédit

A oui, clairement node c'est du bonheur sur les traitement longs, ou pour streamer des résultats ( même si c'ets maintenant possible en PHP)
 
Je te rejoins sur le fait qu'il faut surtout connaitre sa plateforme et en exploiter les possibilités

Non, dans ce cas tu délégues la tâche à un truc spécialisé

on sait jamais, les accidents immo ça n'arrive pas qu'aux autres.

https://www.lesnumeriques.com/vie-d [...] 61369.html
Elle est pas mal celle là. Y'en a qui vont prendre cher...

j'avoue qu'ici on delegue a un rabbitmq chargé de controler /distribuer les jobs, et franchement il me fait un peu chier (notamment pour tests)
 
Je deviens un nazi des tests , moi qui ait du en ecrire moins de 100 avant au total.

le plus haut c'etait 2008/2010, j'aurais revendu 20K de plus qu'en 2015, mais oui les prix avaient bien monté.
Les rois du petrole niveau immo c'est ceux qui sont assez vieux pour avoir pu acheter entre 1994 et 1999, les prix etaient au plus bas sur les 40 dernieres années (periode 1980/2020).
Et encore a la base en 2002, je voulais pas acheter, c'est ma femme qui m'a un peu forcer la main (elle a eu grave raison), moi je disais que ça pouvait attendre et qu'on avait le temps.

Pour la prochaine fois qu'on vous demande d'implémenter FizzBuzz en entretien: https://www.morling.dev/blog/fizzbuzz-simd-style/ mais qu'il faut que ça pulse un minimum.
.