[blabla@olympe] Le topic du modo, dieu de la fibre et du monde

Recherche :

Sujet(s) à lire :
- Who's who@Programmation

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 25582 25583 25584 .. 27013 27014 27015 27016 27017 27018 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [blabla@olympe] Le topic du modo, dieu de la fibre et du monde

Xavier_OM

Monarchiste régicide (fr quoi)

Reprise du message précédent :
Quand j'ai fini des features (à coup de 'wip' et autres 'tmp fix') et que le résultat est satisfaisant je fais toujours rebase + split des commits, pour séparer en plusieurs thèmes :

les commits liés à la config/organisation du projet
suivis de ceux qui refactorent pour préparer le terrain
suivis de ceux ceux qui ajoutent des nouveaux objets/concepts (plutôt couches basses)
suivis de ceux ceux qui se servent des nouveautés (plutôt couches hautes)

J'aime bien quand ça raconte une histoire la réorganisation se passe bien à partir du moment où t'attends pas la fin pour le faire, mes commits de wip sont souvent assez atomiques donc comme a dit Jubi ça s’agrège pas trop mal

Message cité 1 fois
Message édité par Xavier_OM le 29-08-2023 à 17:56:03

---------------
Il y a autant d'atomes d'oxygène dans une molécule d'eau que d'étoiles dans le système solaire.

Publicité

koskoz

They see me trollin they hatin

Si j'ai un gros refacto je ne vais pas attendre d'avoir terminé la feature, sinon ça va être un enfer les git add -p

---------------
Twitter

Dion

Acceuil

masklinn a écrit :

des fois les gens bossent bien.

masklinn s'est fait tapé son compte HFR

Message cité 1 fois

---------------
When it comes to business/legal topics, just assume almost everyone commenting has no idea what they’re taking about and have no background in these subjects because that’s how it really is. Harkonnen 8-> Elmoricq 8====>

___alt

Dion a écrit :

masklinn s'est fait tapé son compte HFR

Pas faute de demander de la 2FA à M.arc depuis des années [:altherac:1]

---------------
TRIPS RIGHT BUNCH F SHUTTLE TOM AND JERRY RIGHT YELLOW

Xavier_OM

Monarchiste régicide (fr quoi)

masklinn a écrit :

Et splitter autant committer des morceaux de working copy c’est facile, autant splitter un commit existant c’est assez galère. Faudrait que je regarde s’il existe des scripts pour faciliter ça, ou que je m’en monte un.

GitExtensions, right-click, edit commit (ça rebase -i avec edit sur le commit), reset mixed, soit 4 clics pour arriver dans l'état où t'as plus qu'à commit des morceaux de working copy je ne dirais jamais assez de bien de ce client je crois

Message cité 1 fois

---------------
Il y a autant d'atomes d'oxygène dans une molécule d'eau que d'étoiles dans le système solaire.

masklinn

í dag viðrar vel til loftárása

Xavier_OM a écrit :

Bah non c’est pourri.

D’une c’est pas mieux que ce que tu fais en CLI, de deux c’est pas une opération claire, “reset mixed” c’est tout sauf flagrant, et de trois au lieu de faire une opération logique de sortir des trucs d’un commit tu dois nuker tout le commit pour recréer de zéro à partir du cadavre.

Donc c’est une procédure ultra manuelle qui ne fonctionne que si tu la connais d’avance. C’est exactement à chier.

C’est même pire que la CLI parce que tu dois être au courant que “edit commit” c’est en fait un rebase -i qui marque le commit sélectionné comme à éditer, donc t’as toute la sémantique & logique de rebase qui est dispo.

Message cité 1 fois
Message édité par masklinn le 29-08-2023 à 18:21:01

---------------
I mean, true, a cancer will probably destroy its host organism. But what about the cells whose mutations allow them to think outside the box by throwing away the limits imposed by overbearing genetic regulations? Isn't that a good thing?

koskoz

They see me trollin they hatin

C'est bon, on a retrouvé machine, tu nous avais fait peur [:kyjja:5]

Message cité 2 fois

---------------
Twitter

___alt

koskoz a écrit :

C'est bon, on a retrouvé machine, tu nous avais fait peur [:kyjja:5]

[:rofl]

---------------
TRIPS RIGHT BUNCH F SHUTTLE TOM AND JERRY RIGHT YELLOW

masklinn

í dag viðrar vel til loftárása

koskoz a écrit :

C'est bon, on a retrouvé machine, tu nous avais fait peur [:kyjja:5]

J'ai dit que des fois les gens bossent bien, j'ai pas dit tous, et j'ai pas dit souvent, s'pas mon problème si vous comprenez pas bande de boulets [:michel daerden:1]

Message édité par masklinn le 29-08-2023 à 20:13:39

Dion

Acceuil

c'est à peine croyable mais tu te ramollis avec l'âge

Message cité 2 fois

Publicité

masklinn

í dag viðrar vel til loftárása

Dion a écrit :

c'est à peine croyable mais tu te ramollis avec l'âge

C'est normal, les dysfonctions érectiles augmentent avec l'âge.

beel1

koskoz a écrit :

Merge Request [:pingouino dei]

2 milliards de roubles, ou 2 mondial relay, ça doit valoir a peu près pareil

koskoz a écrit :

Je suis censé comprendre quoi ? [:klem3i1]

"normalement" ce bloc d'alim c'est un transfo dans le sens le plus bête : linéaire, pas de régulation (genre 14V à vide, 12V à 700mA sous 230V
et en AC t'es pas censé avoir un + et un -
je vote le copié merdé mais ça reste perturbant car la page du fabricant n'est pas mieux, c'est en engrish : https://www.kreco.com.cn/Chinese_Ad [...] 079_2.html
bref je sais pas trop quoi penser de ce bloc

Message cité 1 fois

frabill

ratibus a écrit :

Changement de contrat EDF pour passer au tarif Tempo : done
Les tarifs sont disponibles ici : https://particulier.edf.fr/content/ [...] f_Bleu.pdf

Au passage voici les plages d'heures creuses chez moi :
1h56 - 7h56
14h56 - 16h56

J'ai toujours pas bien compris suite à mes recherches : les heures creuses définies par Enedis pour Tempo sont-elles les mêmes que pour un abonnement classique HC/HP ?

Sachant qu'actuellement j'ai : Plage : 1H30-7H30;21H00-23H00
mais vieil abonnement HP/HC, et je suis passé sur Linky il y a quelques années...

Visiblement c'est plutôt dynamique par abonné si on a un Linky, et pas par zone géographique :

Citation :

Pour les clients équipés d’un compteur Linky, les heures creuses sont pilotées à la maille nationale. L’une des plages horaires d’heures creuses applicables en France métropolitaine est attribuée de manière aléatoire. Pour connaître vos heures creuses exactes, consultez votre facture ou contactez votre fournisseur d’électricité.

Tu as eu connaissance des HC après souscription ?

Message cité 2 fois

Jubijub

Parce que je le VD bien

Xavier_OM a écrit :

Quand j'ai fini des features (à coup de 'wip' et autres 'tmp fix') et que le résultat est satisfaisant je fais toujours rebase + split des commits, pour séparer en plusieurs thèmes :

les commits liés à la config/organisation du projet
suivis de ceux qui refactorent pour préparer le terrain
suivis de ceux ceux qui ajoutent des nouveaux objets/concepts (plutôt couches basses)
suivis de ceux ceux qui se servent des nouveautés (plutôt couches hautes)

Jean-Francois Piège on te voit

---------------
Jubi Photos : Flickr - 500px

beel1

frabill a écrit :

Citation :

Tu as eu connaissance des HC après souscription ?

Tempo les HC c'est obligatoirement 22h-6h

Message cité 2 fois

el_barbone

too old for this shit ...

Aucune idée si je muchachise ou pas .... Je viens de découvrir ça : https://web-check.xyz/ .... C'est top

Message cité 2 fois

---------------
En théorie, la théorie et la pratique sont identiques, en pratique, non.

frabill

ratibus a écrit :

beel1 a écrit :

Tempo les HC c'est obligatoirement 22h-6h

:??:

nraynaud

lol

Bordel, je viens de révéler l’existence des VVF à ma femme [:ciler]

Message cité 1 fois

---------------
trainoo.com, c'est fini

masklinn

í dag viðrar vel til loftárása

nraynaud a écrit :

Bordel, je viens de révéler l’existence des VVF à ma femme [:ciler]

Les villages vacances de france ou les fistules?

Message cité 1 fois
Message édité par masklinn le 29-08-2023 à 22:22:08

Shinuza

This is unexecpected

Dion a écrit :

c'est à peine croyable mais tu te ramollis avec l'âge

Fin, y'a un moment où plus mou c'est liquide

koskoz a écrit :

C'est bon, on a retrouvé machine, tu nous avais fait peur [:kyjja:5]

Message édité par Shinuza le 29-08-2023 à 23:11:20

---------------
Mains power can kill, and it will hurt the entire time you’re dying from it.

Shinuza

This is unexecpected

- Rédiger un mail assez détaillé avec l'état du projet, le changelog traduit et vulgarisé, avec des vidéos de démo des fonctionnalités avancées, plus les prochains jalons, plus les prochains déplacements liés au projet [:yann39]
- Y passer une heure grâce à la connexion en bois chez ma mère. (ça fait 4 ans qu'ils lui promettent la fibre, elle serait foutue de l'avoir après Harko)
- Editer une liste à puce et faire ctrl + entrée pour créer une sous-liste saufkanfète ça envoie le mail
- Faire "Undo" [:yann39]
- Ne pas retrouver le mail, ni dans les Sent, ni dans les Draft
- Paniquer
- Se connecter au webmail
- Ne pas retrouver le mail, ni dans les Sent, ni dans les Draft
- Paniquer
- Relancer 3 fois emclient
- Retrouver le mail dans les Draft

[:bien]

Message cité 1 fois

---------------
Mains power can kill, and it will hurt the entire time you’re dying from it.

SekYo

Yo, question, je veux savoir si c'est moi qui ait des expectations chelous ou si c'est les autres qui se satisfont trop des trucs moisis

On a un service HTTP A qui fait globalement du CRUD sur un autre service (B). Pour éviter de trop taper sur B, le service A embarque une petite lib qui fournit un petit in memory cache avec la durée de validité du cache configurable. Jusque là rien de trop original, ça fonctionne bien dans les cas classiques.

Mais cette librairie "cache" aussi quand B renvoie une erreur, par exemple quand la resource demandée n'est pas trouvée dans B, avec un mécanisme de backoff non configurable. Du coup si par exemple tu fais en moins d'une seconde sur A :
- get resource blabla (qui n'existe pas)
- create resource blabla
- get resource blabla

Le dernier get resource blabla va renvoyer une erreur, parce que la lib ne forcera pas le refresh vu que la première requete a fail.

Je comprend qu'il puisse y avoir de bonnes raisons de "cacher" même des erreurs (pour éviter des DDoS ou d'atteindre trop vite les rate limit du service B). Mais dans ce cas je m'attends quand même à ce que ce mécanisme soit expliqué dans la doc de ladite librairie, et pas uniquement trouvable au fond du fichier Java de l'implem.
Ca vous parait déconnant comme expectation ? On m'a globalement répondu que c'était "common to cache request, especially for data that is not changing frequently" ( oui merci, je m'attendais juste pas à ce que ça cache aussi les erreurs )

( et non je suis pas du tout énervé parce que je viens de passer une journée à debugger des tests d'intégrations qui foiraient de façon aléatoires à cause de ça § )

Message cité 7 fois
Message édité par SekYo le 29-08-2023 à 23:31:32

ratibus

hephaestos a écrit :

Et laisser les collègues voir comment je code ? Plutôt crever.

beel1 a écrit :

Ce qui veut dire que... tu les as appelés ? [:totoz]

Oui et plusieurs fois car au bout de 30 minutes d'attente lors de mon premier appel, j'en ai eu marre

el muchacho a écrit :

Merci. [:bien] j'en ai vu un autre à 22,60$ sur AliBaba, mais avec une commande de 500 exemplaires mini. Vu qu'il n'en a sûrement pas commandé autant (probablement 10 ou 15 exemplaires de chaque modèle au mieux), il les a p-ê touchés à 35$. Ca lui fait une bonne marge mais loin d'être exceptionnelle dans la maroquinerie.

Ce qui m'importe, c'est la qualité de fabrication, en plus du design très sympa: du vrai cuir, des coutures pas trop merdiques, des boucles qui ne pètent pas. Evidemment, à ce prix-là, on ne peut pas demander la lune, c'est la loterie. La maroquinerie de qualité, made in France, Europe ou USA, c'est 10 ou 15 fois plus cher.

Ce modèle est superbe et très tentant, surtout que le délai de livraison est assez court. Les dimensions le destinent aux déplacements pour le bureau.

Si c'est du dropshipping, il n'a rien commandé d'avance. On ne stocke pas.

frabill a écrit :

Citation :

Tu as eu connaissance des HC après souscription ?

beel1 a écrit :

Tempo les HC c'est obligatoirement 22h-6h

C'est pas ce que la dame d'EDF m'a dit
Je me réjouissais des horaires qu'elle m'avait donnés.

Shinuza a écrit :

Avec Gmail, t'aurais évité la tachycardie

Message cité 3 fois

---------------
Mon blog

beel1

ratibus a écrit :

C'est pas ce que la dame d'EDF m'a dit
Je me réjouissais des horaires qu'elle m'avait donnés.

Vraiment des tanches de compétition.

Citation :

3. Les Heures Pleines de l’option Tempo sont définies par le gestionnaire de réseau de distribution ENEDIS de 6h à 22h et les Heures Creuses de 22h à 6h sur tout le territoire.

https://particulier.edf.fr/fr/accue [...] s.html#fn3

Message cité 1 fois

ratibus

beel1 a écrit :

Vraiment des tanches de compétition.

Citation :

3. Les Heures Pleines de l’option Tempo sont définies par le gestionnaire de réseau de distribution ENEDIS de 6h à 22h et les Heures Creuses de 22h à 6h sur tout le territoire.

https://particulier.edf.fr/fr/accue [...] s.html#fn3

:jap:
Ça ne change pas l'intérêt dans mon cas mais merci de l'info
Je mettrai la PAC à chauffer la nuit Avec l'inertie du plancher chauffant ça devrait tenir le reste de la journée [:zigg]

---------------
Mon blog

Shinuza

This is unexecpected

ratibus a écrit :

Avec Gmail, t'aurais évité la tachycardie

Avec l'internet en carton, ché pa

---------------
Mains power can kill, and it will hurt the entire time you’re dying from it.

flo850

moi je

SekYo a écrit :

Yo, question, je veux savoir si c'est moi qui ait des expectations chelous ou si c'est les autres qui se satisfont trop des trucs moisis

Le dernier get resource blabla va renvoyer une erreur, parce que la lib ne forcera pas le refresh vu que la première requete a fail.

( et non je suis pas du tout énervé parce que je viens de passer une journée à debugger des tests d'intégrations qui foiraient de façon aléatoires à cause de ça § )

Si c'est possible, je m'attends à ce que le cache soit snipé pour chaque enregistrement modifié
C'est pas forcément possible/ facile si, par exemple, lenthread qui modifie n'est pas celui qui lit

Mais sinon je trouve le comportement acceptable, un cache ça ment toujours. Et est ce que c'est pire que de répondre un 200 sur un objet qui a été effacé ?

Message cité 1 fois

---------------

tryptique

Stay hungry, stay foolish

SekYo a écrit :

Yo, question, je veux savoir si c'est moi qui ait des expectations chelous ou si c'est les autres qui se satisfont trop des trucs moisis

Le dernier get resource blabla va renvoyer une erreur, parce que la lib ne forcera pas le refresh vu que la première requete a fail.

( et non je suis pas du tout énervé parce que je viens de passer une journée à debugger des tests d'intégrations qui foiraient de façon aléatoires à cause de ça § )

C'est commun de cacher les erreurs - enfin c'est toujours mieux si c'est explicite - pour éviter de DDOS la dépendance.
Et dans tous les cas, c'est pas forcément garanti que B offre "read after write consistency", si ça se trouve B a le même comportement si tu fais ce genre d'enchaînement de requêtes rapides

Message cité 1 fois

---------------
"J'ai les goûts les plus simples du monde, je me contente du meilleur" O. Wilde - Freedom of time is the new luxury. Time to sleep, work, play, relax, travel, inspire and get inspired. Time to write your story.

hephaestos

Sanctis Recorda, Sanctis deus.

SekYo a écrit :

Yo, question, je veux savoir si c'est moi qui ait des expectations chelous ou si c'est les autres qui se satisfont trop des trucs moisis

Ça me choque pas. C'est le principe du cache, tu gagnes du temps mais tu as des données pas à jour. Il faut un moyen pour se passer du cache, typiquement dans les tests, pour les rendre reproductibles.

hephaestos

Sanctis Recorda, Sanctis deus.

flo850 a écrit :

Si c'est possible, je m'attends à ce que le cache soit snipé pour chaque enregistrement modifié
C'est pas forcément possible/ facile si, par exemple, lenthread qui modifie n'est pas celui qui lit

Mais sinon je trouve le comportement acceptable, un cache ça ment toujours. Et est ce que c'est pire que de répondre un 200 sur un objet qui a été effacé ?

C'est un cache côté client, il sait pas ce qui se passe dans le serveur.

masklinn

í dag viðrar vel til loftárása

SekYo a écrit :

Partant du principe que la communication A->B c’est aussi du HTTP ça se trouve c’est pas le cas.

Non effectivement, cacher une réponse HTTP non-200 me semble pas nécessairement déconnant. Le documenter me semble justifiable, mais pas nécessairement couler de source pour l’auteur non plus, genre j’ai une lib qui fait du caching en interne et je pense pas avoir documenté le comportement des erreurs [:petrus75]

Après une autre question que je me poserais c’est si B configure correctement les réponses & si A prend cette information en compte pour cacher l’info? Genre si la lib suit les informations de réponse et a juste un TTL de fallback, le problème est plus dans B, qui devrait marquer les réponses d’erreur correctement.

Message édité par masklinn le 30-08-2023 à 08:01:11

FlorentG

el_barbone a écrit :

Aucune idée si je muchachise ou pas .... Je viens de découvrir ça : https://web-check.xyz/ .... C'est top

Pas mal effectivement !

flo850

moi je

Ça y est on est a l'hôpital, c'est parti
Bloc dans 1 a 2h

Message cité 10 fois

---------------

Flaie

flo850 a écrit :

Ça y est on est a l'hôpital, c'est parti
Bloc dans 1 a 2h

Ça va le faire [:zedlefou:3]

Message édité par Flaie le 30-08-2023 à 08:49:43

Flaie

Dion a écrit :

non, courage est banni il a dit

éditationné

Dion

Acceuil

bon petit

masklinn

í dag viðrar vel til loftárása

flo850 a écrit :

Ça y est on est a l'hôpital, c'est parti
Bloc dans 1 a 2h

Message édité par masklinn le 30-08-2023 à 08:53:41

el muchacho

Comfortably Numb

SekYo a écrit :

Yo, question, je veux savoir si c'est moi qui ait des expectations chelous ou si c'est les autres qui se satisfont trop des trucs moisis

Le dernier get resource blabla va renvoyer une erreur, parce que la lib ne forcera pas le refresh vu que la première requete a fail.

Un cache coté client, - s'il n'est pas invalidé par un message synchrone du serveur -, est à mon avis toujours problématique et personnellement, je chercherais à m'en passer, quitte à changer l'architecture. Même quand il ne retourne pas une erreur, tu ne sais jamais si le résultat de ta requête est à jour. Cela veut dire que tout ce qui dépend de ta requête va être potentiellement faux. Je ne vois vraiment pas quel problème un tel système résout.
Je préfère nettement un cache coté serveur, qui lui sera invalidé correctement.
Ou alors, comme je l'ai dit, il faut que le cache du client soit invalidé automatiquement par le serveur de façon synchrone, mais si ce dernier a beaucoup d'activité en terme d'écritures, le gain peut être nul, voire négatif en terme de charge réseau.

Message édité par el muchacho le 30-08-2023 à 09:08:30

---------------
Les aéroports où il fait bon attendre, voila un topic qu'il est bien

skeye

SekYo a écrit :

Yo, question, je veux savoir si c'est moi qui ait des expectations chelous ou si c'est les autres qui se satisfont trop des trucs moisis

On a un service HTTP A qui fait globalement du CRUD sur un autre service (B). Pour éviter de trop taper sur B, le service A embarque une petite lib qui fournit un petit in memory cache avec la durée de validité du cache configurable. Jusque là rien de trop original, ça fonctionne bien dans les cas classiques.

Mais cette librairie "cache" aussi quand B renvoie une erreur, par exemple quand la resource demandée n'est pas trouvée dans B, avec un mécanisme de backoff non configurable. Du coup si par exemple tu fais en moins d'une seconde sur A :
- get resource blabla (qui n'existe pas)
- create resource blabla
- get resource blabla

Le dernier get resource blabla va renvoyer une erreur, parce que la lib ne forcera pas le refresh vu que la première requete a fail.

Le fail il est pas dans l'invalidation du cache là plutôt?

Message cité 1 fois

---------------
Can't buy what I want because it's free -