Sinon puisque tu refais ton CV, pour tes futurs entretiens d'embauche: https://twitter.com/baka_neko__/sta [...] 4376624136

J'aime, twitter = love.

Ca va elle est soft, j'aime beacoup le passage ou elle se remet pas en question ("Si on la posait c'est justement car j'ai eu des développeurs dans mon équipe qui refusaient de m'ecouter ou me contredisait tout le temps du fait de mon genre." ) elle s'est jamais dit que peut etre elle avait des idées de merde, alors mettons ca sur le genre ca sera plus facile

Le passage ou elle avoue clairement etre hystérique dans le milieu pro était cocasse aussi.

J'en ai marre du rasoir mécanique pour un rasage quotidien  
 
Je comptais investir dans un de ces genres de rasoir :  

• https://www.amazon.fr/Philips-S7788 [...] r=1-6&th=1
• https://www.amazon.fr/Braun-%C3%89l [...] BQY2L&th=1

Y'en a qui ont déjà essayé ici ? Des retours ?

Vous réalisez que vous vous ambiancez tous seuls sur un tweet d'une inconnue qui ne rencontre aucun soutien et qui a recueilli 262 (deux-cent soixante deux) j'aime ? Mon chien qui fait une roulade fait mieux sur insta.

Et il en a profité pour chier publiquement sur ses équipes qui souhaitaient faire respecter les ToS. On aurait pu penser qu'en plus de six mois il aurait pu les faire évoluer mais non    
Timing intéressant la boss de Trust and safety a démissionnée hier, elle avait le job depuis 7 mois après la démission du précédant bosss de Trust and safety  

Il se place en plateforme de free speech

 
Prend la destination qui génère le plus de CO2  

Quand je dois faire une App ou un composant qui interroge une API je pose cypress systématique, je dois être masochiste.
Mais l'avantage, c'est qu'une fois que tu as fais le parcours dans l'app d'origine, que tu récupères les request/responses, tu poses tout ça dans cypress en mockant les appels, et ensuite tu poses tes tests.
Coder est bonheur, car si on a un parcours à étapes, qu'on teste l'étape 5 qui dépend des 4 précédents, c'est plus facile d'avoir un truc qui clique à ta place et qui retourne des reponses en 1ms, ainsi tu te retrouve à l'étape 5 en 1s.

Vous réalisez que vous vous ambiancez tous seuls sur un tweet d'une inconnue qui ne rencontre aucun soutien et qui a recueilli 262 (deux-cent soixante deux) j'aime ? Mon chien qui fait une roulade fait mieux sur insta.

Bel exposé de l'avantage du e2e.

À la COGIP dans ma première équipe one utilise Sélénium, mais dans ma deuxième équipe on va partir sur Playwright.

Et autre nouvelle tendance :  
Tout projet qui arrive avec du webpack ou du create-react-app, tourne aussi tôt avec viteJS, je divise par 5 à 10 le temps de démarrage du bouzin et de compil.

Pas auprès d'Erdogan et Modi, j'espère tout de même qu'ils apprécient l'effort et le brown-nosing    
 

C’est juste que t’as pas la bonne notion de liberté de parole.

On migre aussi notre app react vers vite vu que cra c'est dead. C'est très long et fastidieux, ça prends la tête.
 
Mais c'est le cas général de la stack JS, en tout cas j'espère que ça ira plus vite et surtout que ça arrêtera de bouffer des centaines de Mo pour simplement tester un composant react avec testing library

en 1 journée la migration est faite, je ne vois pas ce qui a pu être douloureux pour vous et je l'ai fait sur 2 projets dont l'un est assez fat.

À la COGIP dans ma première équipe one utilise Sélénium, mais dans ma deuxième équipe on va partir sur Playwright.

On parle beaucoup des dangers de l'IA ces temps ci, et la je vois qu'on commence à atteindre le dur : https://tech.slashdot.org/story/23/ [...] lated-test      
 
A+,

On parle beaucoup des dangers de l'IA ces temps ci, et la je vois qu'on commence à atteindre le dur : https://tech.slashdot.org/story/23/ [...] lated-test      
 
A+,

La taille du projet, le frontend est gros, on utilise jest pour mock des modules c'est aussi la merde pour migrer ça, le renommage de tous les fichiers en jsx, et des libs internes dont on depends qui ont cassé les bonbons

Vous réalisez que vous vous ambiancez tous seuls sur un tweet d'une inconnue qui ne rencontre aucun soutien et qui a recueilli 262 (deux-cent soixante deux) j'aime ? Mon chien qui fait une roulade fait mieux sur insta.

On parle beaucoup des dangers de l'IA ces temps ci, et la je vois qu'on commence à atteindre le dur : https://tech.slashdot.org/story/23/ [...] lated-test      
 
A+,

je valide, c'est la merde de migrer les tests
et pourquoi renommer les fichiers .tsx ? tu n'as pas les renommer, pas besoin c'est juste une question de conf.

 
C'est pour ca que j'ai pas Twitter, tout ca la, c'est du suréel pour moi
 

complètement prévu
https://www.youtube.com/watch?v=3TYT1QfdfsM
https://youtu.be/92qDfT8pENs?t=290

https://dev.mysql.com/doc/refman/8.0/en/union.html

Question arrachage de tête mysql du jour :
imaginez, vous avez une table de fournitures (id, nom, et plein de caractéristiques)
 
ensuite une personne peut créer un genre de commande de ces fournitures (1 ligne par fourniture choisie, une quantité...)
 
jusque là du très classique...
MAIS vous voulez aussi un moyen pour l'utilisateur de créer des nouvelles fournitures... mais qui ne peuvent pas être stockées dans la table des fournitures, car cette table est écrasée de temps en temps par une nouvelle version, et qu'elle sert à plusieurs utilisateurs différents et vous voulez que chaque utilisateur puisse créer ses fournitures perso.
 
OK, on peut créer une table fourniture_perso avec un id différent
 
Maintenant dans la "commande", il va falloir distinguer les id issus de la table de fournitures commune et la perso (on peut imaginer un booléen quelconque genre perso 0/1).
 
A l'heure de lister le contenu d'une commande, il faut faire une jointure entre le détail de la commande (fourniture_id, perso(0/1), quantité, ...)  et... une table de fourniture pour récupérer le nom de la fourniture par exemple... enfin 2 tables désormais.
 
C'est quoi l'approche pour faire ça ???
jointure conditionnelle ça existe ? genre si perso=1 jointe sur telle table, si perso=0 jointe sur telle autre ???
 
J'ai tout faux dans mon approche et il faut faire différemment ?

 
 
Un champ utilisateur_id en nullable dans la table fourniture sinon ?  
Si c'est NULL c'est une fourniture disponible pour tout le monde sinon c'est spécifique à l'utilisateur spécifié.  
Tu peux ensuite sortir les résultats avec une seule jointure.  
Et pour les reimports réguliers des fournitures communes, tu delete uniquement les lignes à NULL.

J'aurai bien aimé faire ça, mais les id des fournitures sont fixés par un process extérieur sur lequel je n'ai pas la main + c'est plus bordélique pour la mise à jour de la table : jusqu'à présent lorsqu'une nouvelle version est publiée je vide l'ancienne et importe la nouvelle à la place avec un retraitement au passage (faut que je normalise certaines colonnes un peu funky) donc les produits mis à jour réutilisent les mêmes id, et les nouveaux ont un id qui suit le dernier de la version précédente.
 
Ca voudrait dire qu'il faudrait que je gère mes propres id en plus, que ce soit eux qui soient utilisés pour le lien avec mes commandes, mais avec un bon gros bordel pour la mise à jour de la table. Pas facile à expliquer, mais en gros il faudrait pouvoir checker 1 par 1 quel produit est mis à jour, quel produit est nouveau. Pas insurmontable mais ca me semble une fausse bonne idée de merger ça dans la même table.

J'aurai bien aimé faire ça, mais les id des fournitures sont fixés par un process extérieur sur lequel je n'ai pas la main + c'est plus bordélique pour la mise à jour de la table : jusqu'à présent lorsqu'une nouvelle version est publiée je vide l'ancienne et importe la nouvelle à la place avec un retraitement au passage (faut que je normalise certaines colonnes un peu funky) donc les produits mis à jour réutilisent les mêmes id, et les nouveaux ont un id qui suit le dernier de la version précédente.
 
Ca voudrait dire qu'il faudrait que je gère mes propres id en plus, que ce soit eux qui soient utilisés pour le lien avec mes commandes, mais avec un bon gros bordel pour la mise à jour de la table. Pas facile à expliquer, mais en gros il faudrait pouvoir checker 1 par 1 quel produit est mis à jour (pour garder son "id à moi", quel produit est nouveau (il sera inséré et aura un nouvel "id à moi" ). Pas insurmontable mais je ne peux pas m'empêcher de me dire que ça semble une fausse bonne idée de merger ça dans la même table.

Une table des trucs externes / importés, une table des trucs "perso", et une 3eme qui sert juste à pointer vers un des deux? Et c'est l'id de la 3eme qui est utilisée dans ta facture/commande/chéploi...?
Derrière tes requêtes font des trucs du genre

SELECT t.id, case when i.nom IS NULL then p.nom else i.nom; AS nom, bidule
FROM tableCumulee t
LEFT OUTER JOIN tableImportee i ON i.id = t.import_id
LEFT OUTER joint tablePerso p ON p.id = t.perso_id

J'ai pas toute la vue évidemment, mais c'est pas le truc en gras ton plus gros problème ? T'es obligé de vider la table ?
 
Si tu faisais un update au lieu de vider la table, tous les conseils donnés ci-dessus seraient applicables...
 
Si les ID des produits identiques changent pas, qu'est-ce qui t’empêche de faire une itération sur la nouvelle liste, avec une logique :  
- si le produit existe (même ID, même champs clé) ==> marquer un champ genre "last revision" à la date du traitement, ou version de la nouvelle liste, ou whatever
- si le produit n'existe pas, l'insérer dans la table, et mettre le meme champs que ci-dessus à jour
 
ensuite tu vires toutes les lignes de la table qui n'ont pas un date_traitement ou version_liste à jour.
 
si on inclue l'idée d'avoir un champs permettant de savoir si c'est un produit de base ou crée par un utilisateur, ça complexifie un peu si y'a des risques de collisions d'ID
 
je rate un truc ?

C'est en effet la collision d'id le gros souci.
Exemple :
la table importée a des id de 1 à 50000.
l'année d'après elle a des id de 1 à 52000.

Donc je fais quoi pour mes produits perso ? Si entre temps j'en ai créé avec des id du genre 50001, 50002, ça ne va pas le faire.
Donc j'imagine qu'il faudrait ne plus utiliser l'id de la table importée, mais juste le stocker pour faire du recoupement lors de la mise à jour de la table et utiliser par exemple des auto_increment tout bête comme id à utiliser pour ensuite faire les commandes ?

 
C'est en effet la collision d'id le gros souci.
Exemple :  
la table importée a des id de 1 à 50 000.
l'année d'après elle a des id de 1 à 52 000.
 
Donc je fais quoi pour mes produits perso ? Si entre temps j'en ai créé avec des id du genre 50 001, 50 002, ça ne va pas le faire. Et je ne me vois pas faire un truc de gros porchiot genre commencer les id perso avec un nombre très éloignée style 1 000 000. C'est du bricolage dégueu.
 
Donc j'imagine qu'il faudrait ne plus utiliser l'id de la table importée comme référence pour mes commandes, mais juste le stocker pour faire du recoupement lors de l'import l'année d'apprès (update ou ajout et non pas tout virer) et utiliser un autre id, par exemple un auto_increment tout bête, comme référence pour ensuite faire les commandes ?

 
C'est en effet la collision d'id le gros souci.
Exemple :  
la table importée a des id de 1 à 50 000.
l'année d'après elle a des id de 1 à 52 000.
 
Donc je fais quoi pour mes produits perso ? Si entre temps j'en ai créé avec des id du genre 50 001, 50 002, ça ne va pas le faire. Et je ne me vois pas faire un truc de gros porchiot genre commencer les id perso avec un nombre très éloignée style 1 000 000. C'est du bricolage dégueu.
 
Donc j'imagine qu'il faudrait ne plus utiliser l'id de la table importée comme référence pour mes commandes, mais juste le stocker pour faire du recoupement lors de l'import l'année d'apprès (update ou ajout et non pas tout virer) et utiliser un autre id, par exemple un auto_increment tout bête, comme référence pour ensuite faire les commandes ?

Question arrachage de tête mysql du jour :
imaginez, vous avez une table de fournitures (id, nom, et plein de caractéristiques)
 
ensuite une personne peut créer un genre de commande de ces fournitures (1 ligne par fourniture choisie, une quantité...)
 
jusque là du très classique...
MAIS vous voulez aussi un moyen pour l'utilisateur de créer des nouvelles fournitures... mais qui ne peuvent pas être stockées dans la table des fournitures, car cette table est écrasée de temps en temps par une nouvelle version, et qu'elle sert à plusieurs utilisateurs différents et vous voulez que chaque utilisateur puisse créer ses fournitures perso.
 
OK, on peut créer une table fourniture_perso avec un id différent
 
Maintenant dans la "commande", il va falloir distinguer les id issus de la table de fournitures commune et la perso (on peut imaginer un booléen quelconque genre perso 0/1).
 
A l'heure de lister le contenu d'une commande, il faut faire une jointure entre le détail de la commande (fourniture_id, perso(0/1), quantité, ...)  et... une table de fourniture pour récupérer le nom de la fourniture par exemple... enfin 2 tables désormais.
 
C'est quoi l'approche pour faire ça ???
jointure conditionnelle ça existe ? genre si perso=1 jointe sur telle table, si perso=0 jointe sur telle autre ???
 
J'ai tout faux dans mon approche et il faut faire différemment ?