Le coin des codeurs :nerd:

[Mortal]

De ce que j’en ai entendu (y compris par qqn que je connais très bien chez Gandi), c’est un peu la merde…

L’acheteur a l’habitude d’augmenter considérablement les prix et de dézinguer tout ce qui n’est pas assez rentable à son goût. Donc je pense que les VPS de Gandi (activité peu rentable a priori), vont sauter rapidement et les prix vont probablement grimper de ouf.

Pour les « gros » clients, ça ne posera certainement pas de souci particulier (d’autant plus qu’il y a une sacrée inertie dans ce domain, ça coûte de changer de registrar), pour les petits, ça va être compliqué.

[meduz']

“The new X button doesn't close the website”

[Konino]

J'ai mis 2 minutes à comprendre tant l'actualité du truc me passe à côté... Et puis !

[meduz']

https://github.com/hxu296/tariff

[Golden cube]

Genius

[MectonLaFlemme]

[meduz']

Lu ailleurs :

"Un ingénieur QA entre dans un bar. Il commande une bière. Il commande 0 bières. Il commande 999999999999 bières. Il commande un lézard. Il commande -1 bières. Il commande un ueicbcksjdh. Le premier vrai client entre et demande où se trouvent les toilettes. Le bar prend feu, tuant tout le monde."

[P@B]

[KirbyX]

[Banjo]

Pareil que KirbyX

[Chunky]

J’avais la flemme de l’expliquer alors j’ai demandé à Copilot:

Cette blague joue sur le travail d'un ingénieur QA (Quality Assurance), c'est-à-dire quelqu'un qui teste les logiciels pour s'assurer qu'ils fonctionnent correctement. Voici pourquoi c'est drôle :

1. **L'ingénieur QA teste toutes les possibilités** : Il ne se contente pas de commander une bière normale, mais essaie des cas extrêmes et absurdes pour voir si le bar (qui représente le logiciel) est bien programmé. Il teste :
- Une commande normale (« une bière »).
- Une quantité absurde (« 999999999999 bières »).
- Un type incorrect (« un lézard »).
- Un nombre négatif (« -1 bières »).
- Une chaîne de caractères aléatoire (« ueicbcksjdh »).

2. **Le vrai client arrive et fait une demande simple** : Il veut simplement savoir où sont les toilettes. Mais comme le bar (le logiciel) n'a été testé que sur les commandes de boissons et non sur les autres interactions, il « plante » de façon dramatique : il prend feu et tue tout le monde.

C'est une exagération humoristique du fait que tester uniquement des cas extrêmes, sans penser aux vrais besoins des utilisateurs, peut laisser passer des failles critiques dans un logiciel. Résultat ? Catastrophe !

[Benny]

...

Et c'est drôle ?

[P@B]

Dans le milieu du développement, oui.

Le plus connu du genre, c'est ça :

[Le poussin]

Quels que soient les cas auxquels les développpeurs et testeurs auront pensé, il y aura toujours un utilisateur pour tomber dans un cas d'utilisation pas du tout prévu, et parfois c'est un cas qui a du sens.

[nazlurf]

...

Et c'est drôle ?

Non ... j'ai beau comprendre et faire parti du milieu, non c'est pas drôle (enfin, ça ne m'a pas fait rire )

D'autant que là, l'analogie, c'est une fonctionnalité manquante, que tu ne peux donc pas faire avec le logiciel, donc ça ne va pas planter. Sauf s'ils ont bien mis la porte des toilettes dans le bar, mais qu'ils n'ont pas construit les toilettes derrière la porte. ça ferait plus sens si le client avait demandé un jus de fruit (un autre type valide).

[MectonLaFlemme]

(ca marche toujours ici... Le grand classique, c'est le double click dans un champ de saisie. Généralement... Popcorn !)

[Golden cube]

Oui oui c'est des voix IA, oui oui la synchro labiale est aux fraises mais c'est tellement vrai :')

[MectonLaFlemme]

Surprendre une conversation entre 2 stagiaires, qui se plaignent de leur tâche et critique les choix de la boite, et les choix de leur coordinateur (qui coordonne en plus d'autres tâches).
Et...
Se sentir bien vieux d'un coup xD

[KirbyX]

Pourquoi ? Parce que tu ne le fais plus, toi ?

Spoiler:

Ou bien parce que leur coordinateur, c'est toi... ?

[meduz']

Putain le bug relou à comprendre au taf. On pousse des données dans une API à laquelle on passe un timestamp (précision à la seconde), qui parfois correspond à « maintenant ».

Pourquoi est-ce que l'API le fait pas elle-même si c'est toujours « maintenant » ? J'en sais rien, prendre des décisions de merde est un sport populaire dans les services publiques.

Pour la première fois, le serveur dit « yo ton timestamp est dans le turfu là, çay illégal ».

En remontant le truc comme je pouvais, il se trouve que le serveur API doit avoir genre quelques millisecondes de retard sur le nôtre, et donc il était 10 h 30 pile chez nous et probablement encore 10 h 29 : 59 et des brouettes côté API.

1 h 30 pour remonter ce bordel.

[MectonLaFlemme]

Un prof nous disait : "L'erreur est humaine, mais un véritable désastre nécessite un ordinateur"

[Golden cube]

Là l'erreur est surement humaine façon.
Horodater à la source c'est assez classique et sain, ce qui peut expliquer pourquoi ça passe un timestamp.
Mais en général c'est une bonne idée de tout synchro NTP.
Pour de ce qui est de refuser la data si l'horodate est foireuse ça dépend de la stratégie mise en place.
Ça peut potentiellement être valide dans ce cas précis va savoir.

Du coup à part le NTP inexistant ou qui a sauté il n'y a potentiellement pas de problème

[Cyrare]

Refuser si le timestamp est 1 seconde dans le futur, ça me parait pas une bonne idée.

[Golden cube]

Ça dépend de ce qui envoie et quel système reçoit.
Si c'est une bête historisation avec horodatage à la source où l'exactitude de la date n'est pas critique clairement.
Au pire tu fais une action comme quoi la date est foireuse mais tu ne refuse pas.

Sur un truc ou tu as du séquencement d'action avec un ordonnancement strict des commandes pouvant provenir de plusieurs commanditaires par exemple refuser toute commande d'une machine hors sychro horaire peut être pertinent.

Après on est surement dans le cas plus classique que l'excès de zèle

[meduz']

Ici ouais, ça sert juste à rien. Une précision sous la minute est inutile, et sauf cas très particulier, ça sert même certainement à rien d'avoir une précision sous le quart d’heure.

J'ai pas encore décidé si j'allais envoyer un timestamp systématiquement une minute dans le passé ou suivre la méthode recommandée du mainteneur de l'API qui dit « yo y'a un endpoint pour connaître le timestamp du serveur avant que t'envoies les données* ».

* qui peuvent pas être envoyées en batch, donc ça fait vraiment chier d'ajouter un appel API par dessus 3 à 10 appels successifs .

J'ai que des merdes stupides non documentées de ce type à gérer en ce moment, j'avance sur aucun truc concrêt. J'ai mal à mon argent public.