XRAYS · Planning commentaires

🔔 🟥 LE DÉFI DU MARDI #01

On a tous écrit cette boucle un jour. Elle parcourt un buffer de ticks à l'envers, du plus récent au plus ancien. Revue de code : OK. Tests sur 3 éléments : OK.

En prod, sur un gros buffer : boucle infinie, puis lecture hors limites. Un mardi à 9h02, évidemment.

Le bug tient en un seul caractère de type, il est sous tes yeux dans l'image 👇

Tu le vois ? Balance ta réponse en commentaire, on épingle la première bonne. Indice juste en dessous, réponse d'ingé demain même heure.

#cpp #lowlatency #cppfr #financedemarche #xraystrading

Indice 👀 De quel type est i ? Et qu'est-ce qu'un std::size_t ne peut JAMAIS valoir ?

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

La réponse du #01 🟥

std::size_t est NON SIGNÉ : i >= 0 est toujours vrai, un unsigned ne peut pas être négatif. Quand i vaut 0, --i ne donne pas -1, il wrap à SIZE_MAX (18 446 744 073 709 551 615 en 64 bits). On lit ticks[SIZE_MAX] (hors limites) et la condition de sortie ne casse jamais.

On l'a compilé et exécuté : i = 2 → 1 → 0 → 18446744073709551615 → ...

Le compilo le voit aussi (GCC : -Wtype-limits, Clang : -Wtautological-compare - « comparison of unsigned expression >= 0 is always true »). Mets tes warnings, ils bossent pour toi.

Le fix idiome : for (std::size_t i = ticks.size(); i-- > 0; ) handle(ticks[i]);
(ou des reverse iterators / std::views::reverse en C++20).

Réf : conversion vers un type non signé = modulo 2^n ([conv.integral]). Défini, déterministe, et ça casse un buffer en prod.

C'est exactement le genre de détail qu'on traque chez XRAYS TRADING : une lecture hors-cache coûte des microsecondes, un crash coûte une session. On recrute des gens qui voient ce caractère 👉 drh@xrays.fr. Rendez-vous mardi prochain pour le #02.

🔔 🟥 LE DÉFI DU MARDI #02

Classique des feed handlers : on normalise un symbole, on le passe en string_view pour éviter une copie sur le hot path. Sauf que ce code la lit de la mémoire morte.

std::string_view v lie le résultat de venue_id() + "_MIC". Question simple : la string_view rendue par sym() pointe sur quoi, et pourquoi c'est cassé ?

Dites-moi en commentaire ce que voit le lecteur en aval.

string_view ne possède rien. Elle ne fait que pointer. Demandez-vous combien de temps vit le std::string temporaire produit par operator+.

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

UB : dangling string_view. operator+ produit un std::string temporaire. v est construite dessus, mais string_view ne possède pas la donnée, elle ne fait que stocker pointeur + longueur ([string.view.template] : un view est non-owning). Le temporaire est détruit à la fin de l'instruction complète ([class.temporary]), bien avant le return. v pointe alors sur de la mémoire libérée : tout accès en aval est un comportement indéfini, pas une 'sortie'. Le fait que v soit liée à un view (et non à une const ref) signifie qu'il n'y a AUCUNE extension de durée de vie : seule la liaison directe d'un temporaire à une référence l'étend, jamais via un view. Fix idiomatique : renvoyer un std::string (possède la donnée), ou garder le std::string vivant dans le scope appelant et n'exposer la view que tant qu'il vit. Sur un feed handler, ne jamais stocker une view au-delà de la durée de vie du buffer source. C'est exactement ce qu'on traque chez XRAYS TRADING, on recrute : drh@xrays.fr

🔔 🟥 LE DÉFI DU MARDI #03

Un quant additionne 3 incréments de prix de 0.1 et son check d'égalité saute en prod. Classique, et pourtant ça pique encore.

Les deux WriteLine, ils affichent quoi exactement (True/False), et dans cet ordre ?

Votre verdict en commentaire, on compare demain.

Indice T0 : double = IEEE 754 binaire, 0.1 n'a pas de représentation exacte en base 2. decimal, lui, est en base 10. La question est : lequel des deux tombe juste ?

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

Réponse d'ingé.

Sortie garantie : False puis True.

Pourquoi c'est normatif : double suit IEEE 754 binary64 (ECMA-334). 0.1 n'a pas de représentation finie en base 2, donc 0.1+0.1+0.1 vaut 0.30000000000000004, distinct de la constante 0.3 la plus proche : le == rend False. decimal est un flottant décimal (ECMA-334) : 0.1m, 0.3m sont représentés exactement en base 10, la somme égale strictement 0.3m, donc True. Aucune dépendance à la culture, au runtime ou à la plateforme.

Fix idiomatique : pour des prix et montants, jamais double. On price en decimal, ou on compare avec une tolérance (Math.Abs(a - b) < epsilon) si on est contraint au binaire.

C'est exactement ce qu'on traque chez XRAYS TRADING, on recrute : drh@xrays.fr

🔔 🟥 LE DÉFI DU MARDI #04

Classique qui pique en prod. On dédup des ordres par leur id en Integer, et un matin deux ids identiques ne matchent plus. Les deux println affichent quoi, et surtout pourquoi pas pareil ?

Votre réponse en commentaire, on débriefe demain.

Indice : la réponse est garantie par la spec, elle ne dépend pas de la JVM. Regardez l'intervalle -128..127 de très près.

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

Réponse : false puis true.

Pourquoi (normatif) : a == b et c == d comparent des RÉFÉRENCES, pas des valeurs. L'autoboxing passe par Integer.valueOf(int). La JLS 5.1.7 impose que valueOf mette en cache et renvoie le MÊME objet pour toute valeur de -128 à 127. Donc 127 == 127 est true (même instance cachée), mais 128 sort du cache garanti : deux instances distinctes, == compare deux références différentes, donc false.

Fix idiomatique : pour comparer des valeurs, on utilise c.equals(d) ou Objects.equals(a, b), jamais == sur des wrappers. Ou on travaille en int primitif.

C'est exactement ce qu'on traque chez XRAYS TRADING, on recrute : drh@xrays.fr

🔔 🟥 LE DÉFI DU MARDI #05

Côté Python du desk : on instancie des millions de Tick pour rejouer un flux. La classe naïve marche, mais la RAM explose et le cache CPU pleure. Quelqu'un propose __slots__ = ('px', 'qty').

Deux effets à nommer précisément : (1) qu'arrive-t-il à la ligne A (t.source = 'X') APRÈS ajout des slots, et exactement quelle exception ? (2) pourquoi la mémoire par instance baisse en CPython ? Soyez précis sur le 'pourquoi'.

À vous.

Indice T0 : sans __slots__, chaque instance porte un __dict__ pour stocker ses attributs, ce qui permet d'en ajouter n'importe lequel à la volée (comme source). Avec __slots__, ce dictionnaire par instance disparaît. Que devient alors un attribut hors liste ?

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

Réponse d'ingé :

(1) Après __slots__ = ('px', 'qty'), la ligne A lève AttributeError : 'Tick' object has no attribute 'source'. En déclarant des slots, on supprime le __dict__ par instance ; les seuls attributs autorisés sont ceux listés. Toute affectation d'un attribut hors liste échoue (sauf si on ajoute explicitement '__dict__' aux slots, ce qui annule l'intérêt).

(2) La mémoire par instance baisse parce qu'on élimine le __dict__ par instance. Sans slots, CPython alloue à chaque instance un dictionnaire (structure de hash avec sur-allocation) pour porter les attributs ; avec slots, les attributs sont rangés dans des descripteurs à offsets fixes directement dans l'objet, comme des champs d'une struct C. Résultat : moins d'octets par instance, et un layout plus compact donc plus cache-friendly quand on en parcourt des millions. Le gain réel dépend de la version de CPython (les key-sharing dicts atténuent l'écart sur les récents), mais le __dict__ supprimé reste la cause directe.

Fix idiomatique : __slots__ sur les objets à forte cardinalité et schéma fixe (Tick, OrderBookLevel), exactement comme on choisit un POD bien aligné en C++. Garder en tête : pas d'attribut dynamique, et interaction à vérifier avec l'héritage et le pickling.

C'est exactement ce qu'on traque chez XRAYS TRADING : le layout mémoire jusque dans le Python de replay et de tooling. On recrute : drh@xrays.fr

🔔 🟥 LE DÉFI DU MARDI #06

Un collègue veut sortir les positions sans P&L calculé. Il pousse ça en prod, le rapport risque tourne, zéro ligne. Pourtant la moitié du book a un pnl NULL. Le serveur ne plante pas, ne renvoie aucune erreur.

Combien de lignes ramène cette requête, et pourquoi ?

À vos commentaires.

Indice T0 : en SQL standard, NULL n'est égal à rien, pas même à un autre NULL. Que vaut le prédicat pnl = NULL pour chaque ligne ?

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

Réponse : 0 ligne, toujours.

Pourquoi : NULL représente une valeur inconnue, et toute comparaison avec = NULL s'évalue à UNKNOWN (jamais TRUE), donc le WHERE ne retient aucune ligne. C'est de la logique ternaire SQL, pas un bug du moteur.

Fix idiomatique : WHERE pnl IS NULL (et IS NOT NULL pour l'inverse). Piège classique en revue de code risk : un = NULL silencieux masque tout un pan du book sans lever d'erreur.

C'est exactement ce qu'on traque chez XRAYS TRADING, on recrute : drh@xrays.fr

🔔 🟥 LE DÉFI DU MARDI #07

Dans le blotter, on additionne deux frais de commission, 0.1 et 0.2. Le test d'égalité à 0.3 part en vrille et le trader hurle que sa ligne de P&L est fausse.

Sans lancer Node : que loggent EXACTEMENT ces deux lignes, et pourquoi ?

Balancez en commentaire.

Indice T0 : pensez en base 2, pas en base 10. 0.1 et 0.2 n'ont pas de représentation finie en flottant binaire. La 2e ligne dévoile les décimales cachées.

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

Réponse : ligne 1 => false, ligne 2 => 0.30000000000000004.

POURQUOI : les doubles IEEE-754 (le seul type Number de JS) stockent en binaire base 2. 0.1 et 0.2 sont des fractions périodiques infinies en base 2, arrondies au plus proche double. Leur somme vaut 0.30000000000000004, distincte du double le plus proche de 0.3. Donc frais === 0.3 est false.

FIX idiomatique : ne jamais comparer des flottants par égalité ni manipuler de l'argent en float. On travaille en entiers (centimes/ticks) : Math.round((0.1+0.2)*100)===30, ou une lib décimale (decimal.js, big.js), ou une comparaison à epsilon Math.abs(a-b)<Number.EPSILON pour le non-monétaire.

C'est exactement ce qu'on traque chez XRAYS TRADING, on recrute : drh@xrays.fr

🔔 🟥 LE DÉFI DU MARDI #08

Un de ces pièges de coercition qui font douter de sa propre santé mentale.

Quelqu'un teste un panier vide avec un == un peu trop optimiste. On compare un tableau [] à sa propre négation ![].

Que valent les deux console.log, et quelle branche du if s'exécute ?

Votre verdict en commentaire 👇

#dev #typescript #javascript #code

Indice du #08 👀 ![] vaut false (un objet est truthy). Ensuite [] == false déclenche une cascade de conversions : objet vers primitive, puis vers nombre.

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

La réponse du #08 🟥

On a exécuté le code. La console affiche :
false
true
Panier traité comme vide

Deux mécanismes se combinent. D'abord ![] : un tableau est un objet, donc truthy, et sa négation vaut false. Ensuite [] == false suit l'algorithme d'égalité abstraite : le booléen false devient le nombre 0, puis le tableau [] est converti en primitive, ce qui donne la chaîne vide "", elle-même convertie en 0. On compare 0 == 0, qui vaut true. La branche "vide" s'exécute, même si panier n'a rien à voir là-dedans : on a comparé panier à false par le même chemin.

La parade : ne jamais utiliser == pour ce genre de test. Vérifier panier.length === 0, et préférer === partout.

C'est exactement le genre de détail qu'on traque chez XRAYS TRADING. Pas besoin de venir de la finance, juste d'être un bon ingé. 👉 drh@xrays.fr

🔔 🟥 LE DÉFI DU MARDI #09

Un pointeur nil rangé dans une interface error. Le err != nil du handler part en vrille alors que la valeur est nil. Vous voyez pourquoi avant le compilo ?

Qu'affiche ce programme ?

#dev #golang #code

Indice 👀 une interface, c'est un couple (type, valeur). Le type est-il nil ?

⏰ Plus qu'une heure pour tenter votre réponse 👇

Je lâche la solution demain, même heure. Postez vos hypothèses en commentaire, on en débat 👀

La réponse du #09 🟥

On a compilé et exécuté : ça affiche true.

Une interface Go n'est nil que si SON type ET SA valeur sont nil. Ici check() range un *ValErr (type concret non nil) pointant sur nil. L'interface error porte donc (*ValErr, nil) : son type n'est pas nil, donc err != nil vaut true. Le bug classique : retourner un *T typé au lieu d'un error nil. La parade, c'est return nil explicite, jamais un pointeur typé nil.

C'est exactement le genre de détail qu'on traque chez XRAYS TRADING. Pas besoin de venir de la finance, juste d'être un bon ingé. 👉 drh@xrays.fr