Je suis de retour du #devoxx 2026 à Paris, pleins de supers présentations, pleins de super discussions... 👍👍

mais hélas je n'ai pas repéré un seul lien vers des comptes mastodon sur les pages des présentateurs 😩

il va falloir évangéliser plus.

Retour sur Devoxx France 2026

https://litote.org/blog/billets/retour-sur-devoxx-france-2026/

Focus sur l'IA générative

#ia #Devoxx

[Devoxx] Tu te mets combien en responsive CSS ? Edition 2026

Jusqu’en 2008, il n’y avait pas besoin de responsive css, parce que les écrans avaient à peu près les mêmes formes. Mais en 2008, avec l’introduction de l’iPhone, on se retroue avec des écrans qui ont des formes très différentes.

En 2010, l’article Responsive Web Design invente la méthode, inspirée de l’architecture. L’idée, c’est de créer un design qui, sans être parfait partout, peut rester fonctionnel dans tous les écrans.

Allez, on commence

La page vide

Julien et Théo ont conçu un éditeur WYSIWYG pour montrer les différents rendus, et ils arrivent bien à afficher leur page blanche.

Le paragraphe

Pour afficher un paragraphe, ça peut être intéressant de limiter la taille du bloc pour qu’il ne prene pas tout l’écran, en donnant en plus une taille maximal. Mais attention, parce que pour l’accessibilité, il faut pouvoir supporter une grande taille. Donc pour ça, il faut passer à une unité basée sur la taille de la police, l’incroyable em.

Le jeu de morpion

C’est une belle grille 3×3, et on voit que sur les grands écrans ça semble bizarre. Et on passe à une width en vmin. Et il faut ajouter une taille minimale, ce qui se fait avec clamp. Les tailles d’écran, ça marche bien sur ordinateur, mais moins bien sur les téléphones pour lesquels des unités complémentaires ont été définies (lvh, svh, dvh). Et c’est utilisable sur la plupart des navigateurs (dont tous les navigateurs récents) !

L’image de fond

Ici, Théo va utiliser du responsive HTML avec une balise picture , l’img de base en mode par défaut, et différentes source selon la taille de l’écran. On peut aussi les écrans de résolution très différents en ajoutant des conditions dans l’attribut media. Et ça marche aussi avec les vidéos.

La documentation

On va faire une page de documentation classique avec trois colonnes.

Et pour l’instant, Julien et Théo ne nous ont pas parlé de media queries. Mais ça change maintenant !

Et il utilise encore une nouvelle unité : le fr. Et en combinant une media query et une grid, ça se fait très facilement.

Mais pourquoi on fait du mobile first ?

Généralement, il faut moins de CSS pour faire l’affichage mobile que pour faire l’affichage de bureau. Et si le design mobile rentre plus facilement sur un écran plus grand.

La galerie de photos

Ils vont faire maintenant une galerie de photos avec des miniatures adaptées à l’écran.

Pour ça, un display: flex, du contenu centré, et ça a l’air sympa. Mais il ya parfois des marges. Ca se comble avec flex-grow qui a l’inconvénient que la dernière ligne contient des images d’une taille incohérente.

Essayons autrement, avec une grid. Et en mettant un autofill, le nombre de colonnes s’adapte à la taille de l’écran, sauf dans certains cas.

La règle d’or chez les front, c’est que flex est plutôt bien adapté quand il faut manipuler une dimension, et grid plutôt adapté quand il faut manipuler deux dimensions.

La plateforme de contenu

C’est une espèce de youtube-like avec des présentations variables. Et pour les afficher, on va utiliser des container queries, qui vont modifier le rendu selon l’espace disponible pour le container. Et ils font des démos qui me font penser à un très vieil article Swing sur les « transmogrifying widgets ». Le résultat est en franchement spectaculaire en terme d’adaptabilité.

Dans les design systems, les container queries sont très utiles (voir par exemple le Karkinos Design System).

Ca vaut le coup de nommer les containers. On peut combiner les container queries et les media queries. En revanche, il faut éviter de trop s’en servir pour éviter l’effet sapin de Noël. Et il existe évidement des unités spécifiques au container qu’il vaut mieux utiliser avec parcimonie.

Le monde réel

Il faut maintenant adapter ces techniques au monde réel. Et utiliser ces techniques vous aidera beaucoup, parce que les agents IA sont incapables pour l’instant de les mettre en oeuvre correctement.

[Devoxx] Eloge de la simplicité

Pour l’orateur, si on pense à un logiciel qu’on déteste, c’est un logiciel professionnel. Parce que dans le monde de l’entreprise, il faut uniformiser. Et si on veut créer un peu de variété, il faut demander à un comité.

Les utilisateurs ne vont pas regarder les roadmaps, la seule chose qui compte, c’est le produit. Pour l’orateur, la définition d’un planning est quasiment une trahison des utilisateurs. Et c’est le quiproquo de l’agilité.

Parce que le but, c’était d’être plus simple. Mais aujourd’hui, on remplace des plannings tous les trois mois par des planning trimestriels. Et souvent les backlogs sont en fait simplement des plannings verticaux.

Le planning, c’est un amas d’informations qui sont inutiles aujourd’hui, et fausses demain. Le planning, c’est un imaginaire qui rassure, un doudou organisationnel. Au contraire, le backlog indique juste ce qu’il faut faire maintenant.

Les organisations qui s’appuient sur es plannings sont dans l’incertitude, mais elles ne le savent pas. Pour le speaker, la transformation agile embrasse l’incertitude.

Si on se concentre sur l’estimation des tâches, on constate que le monde de l’informatique est terriblement mauvais : on ne sait pas estimer le délai, et donc les coûts, ni l’adoption par les utilisateurs, et donc les gains. Ca fait que les estimations sont complètement farfelues. Et c’est comme ça que nous décidons ?! Et pourtant, nous sommes débordés par des nombres construits de manière fantaisiste.

On peut remplacer ces estimations par le fait de demander aux utilisateurs. Les conflits de priorisation se dissolvent par les rencontres avec les utilisateurs. Et les utilisateurs peuvent même proposer des solutions à leurs irritants.

Ca vaut mieux que la méthode qui consiste à réfléchir pour ne pas agir, ce qu’on fait avec les études. Il vaut mieux agir pour apprendre, en l’occurence en écoutant les retours des utilisateurs. C’est l’empathie qui nous fera agir sur les sujets les plus importants. Et pour maximiser le retour sur investissement, il faut aller vers la simplicité et l’amour.

La seule chose qui fait que les gens conservent les plannings, c’est le fait que les gens sont convaincus qu’ils ne peuvent pas fonctionner sans planning.

Le speaker est convaincu que les urgences peuvent aider à comprendre comment une organisation peut être efficace sans planning. Il faut savoir que les urgences sont étudiées scientifiquement dans l’objectif de minimiser le taux de mortalité. Ca marche avec un accueil administratif qui liste les nouveaux arrivants, enchaîné à un accueil infirmier qui priorise les patients. Quand on est patient, on ne sait jamais quand on sera soigné. Mais le maximum de vies sera sauvé, et les cas les plus graves seront forcément traités en premier. Les urgences sont totallement imprédictibles, et pourtant extrêmement efficaces.

Les plannings n’existent pas parce qu’il y a un enjeu, mais parce qu’on ne sait pas faire autrement.

Et ça marche aussi pour la synchronisation : les urgentistes envoient des patients en radiologie qui ont pourtant un planning, et ça marche grâce à la communication permanente.

Dans les organisations qui se basent sur un planning, l’adaptation est impossible.

En fait, il y a une alternative à l’agilité à l’échelle : l’agilité. Le problème, c’est que les gens cherchent à faire des plannings, même en étant agiles. En fait, le vrai défi, c’est de trouver comment travailler sans planning.

[Devoxx] Kubernetes et la JVM

Java sur K8s, c’est plein de préjugés : lent à démarrer, compliqué à exploiter, gourmand en ressources.

Pour commencer, on peut utiliser K8s sur le pote de dév avec des outils comme minikube, k3s, kind, ou flox (qui semble s’inspirer de nix, et permet de créer un environnement de développement reproductible).

Alain nous montre alors comment utiliser flox pour installer kind et démarrer un namespace. On peut même choisir une version spécifique de K8s.

Passons maintenant à la construction des images et aux bonnes pratiques :

• faire de petites images
• utiliser du multistage build
• utiliser Kaniko ou Jib qui optimisent la construction des images

Dans Kubernetes, il ne faut pas oublier d’alimenter les probes, parce que K8s envoie du trafic dès que l’image est démarrée. Et il ne faut pas mettre le même endpoint dans la liveness et la readiness. Pensez aussi à déclarer des requests et des limits pour éviter que le pod soit tué trop facilement.

Dans la suite de la démo, ils vont utiliser une application Java qui se connecte à la Chuck Norris API. Une fois l’application écrite, on peut la déployer dans kind avec un kind deploy docker-image

Son application démarre … en 37 secondes avec 0.2 vCPU, mais instantanément avec 1 vCPU.

Il faut aussi penser à gérer le shutdown hook pour que l’application s’arrête correctement.

Passons à la JVM. Dans cet outil incroyable, deux éléments sont intéressants dans notre cas :

• Le JIT qui améliore l’exécution, une fois que le démarrage est effectué, celui-ci pouvant être assez long. Une méthode est compilée nativement après 10.000 appels par un compilateur de niveau C1, et il sera par la suite optimisé encore plus.
• La gestion de mémoire, et en particulier le garbage collector. La JVM en fournit plusieurs, qui évoluent en performance avec les versions de la JVM. On sélectionne rarement le GC, parce que la JVM le fait automatiquement. C’est fait selon trois critères : throughput, empreinte mémoire, et latence.

Depuis Java 5, les ergonomics permettent d’auto-configurer la JVM selon le nombre de CPU ou d’autres facteurs. On peut néanmoins forcer les valeurs de ces paramètres. On peut aussi les lister, soit par une commande spécifique, soit dans les logs. Dans les ergonomics, il y a aussi le choix de la taille mémoire. Les valeurs par défaut sont bonnes pour les postes de dev, moins pour les environnements conteneurisés. Et de la même manière, ces ergonomics déterminent automatiquement le garbage collector. Et les contraintes de mémoire font que dans les conteneurs, on se retrouve souvent avec SerialGC (qui arrête l’application de temps en temps).

Passons maintenant à l’exécution du code Java dans K8s. Avant Java 10, les ergonomics récupéraient les informations de CPU et de RAM du noeud, et pas celles définies dans le conteneur. Après Java 10, on prend les informations du conteneur. Mais on peut les changer avec XX:MaxRAMPercentage pour lequel la bonne pratique est de mettre 75%.

La JVM a besoin de CPU avec certains pics. Et c’est pour ça que les applications Java deviennent très lentes quand la mémoire est limitée.

Et c’est pire pour la mémoire : si il n’y a pas assez de mémoire, ça tue le conteneur. (OutOfMemoryError par Java ou OOMKill par Kubernetes). Et attention, parce que la JVM n’a pas de mémoire que dans la heap, il y aussi le metaspace, les threads, et la mémoire native. Ca complique bien sûr l’évaluation de la mémoire nécessaire pour faire tourner un conteneur.

On peut améliorer le temps de démarrage de l’application avec différentes techniques. CDS (class data sharing) permet d’accélérer les démarrages successifs des applications. Ca s’appuie sur l’ahead of time compiling, issu des travaux du projet Leyden. On peut aussi utiliser GraalVM qui compile le code Java en code natif. Attention, parce que ça double la charge de test.

Pour finir, Alain nous montre comment compiler une application Java en natif. Le processus n’est pas immédiat, puisque GraalVM vérifie beaucoup de choses.

Pour conclure, Java et K8s sont deux technologies complexes qui, lorsqu’elles sont utilisées ensemble, nécessitent pas mal d’attention, une bonne coordination, et une bonne collaboration.

[Devoxx] Jujutsu, la cerise sur le git, oh !

Jujutsu est un outil de contrôle de source avec lequel on peut utiliser quand même les commandes Git.

Jujutsu n’utilise pas des commits, mais des refsets que jj sait mapper sur des commits Git.

Et Siegfried nous fait ensuite le tour des fonctionnalités de jj, qui sont assez proches de celles git : on peut commiter, on peut merger, et tout le reste, mais avec des éléments assez particuliers, comme par exemple les bookmarks (qui semblent être les branches).

La configuration de jj permet de créer des commandes personnelles, avec une grammaire qui semble bien sympathique.

La gestion des conflits est un peu plus intéressante, puisqu’elle est stockée dans les données du commit, et pas directement dans les fichiers (ce qui rend le conflit non bloquant, contrairement à Git).

jj dispose d’une commande absorb, qui permet en un commit de faire une espèce de git commit --amend, mais potentiellement sur plusieurs branches en même temps (et sur des commits plus anciens).

A noter qu’il n’y a pas à faire de jj add : jj prend toujours tous les fichiers du repository dans ses commits.

Quand on modifie un fichier dans un commit ancien, jj rebase automatiquement les commits basés sur celui qui a été modifié.

Pour apprendre, la documentation est très fournie. Steeve Klabnik a aussi écrit un tutorial. Et il y a aussi un jj-workshop. Et pour partager le code, https://tangled.org/ est une plateforme à la GitHub.

Par défaut, jj limite la taille des fichiers dans le repository à 1 Mb (mais c’est évidement configurable).

Siegfried a par ailleurs repris cette présentation dans un article bien plus complet, disponible sur son blog.

[Devoxx] Stop à la dette documentaire : Industrialisez vos ADRs et READMEs avec Spec-kit

Axel et Alex, consultants de WeScale, viennent nous parler du problème unviersel de la dette documentaire : les projets sans doc, sans adr, sans rien sont encore beaucoup trop courants. Et ils vont nous expliquer comment le spec driven development les a aidé à garantir la documentation. Et en particulier comment spec-kit a pu les aider.

Avec cette méthode, la documentation est produite en premier lieu, et maintenue comme un artefact essentiel.

Dans leur projet, toute modification du domaine doit être accompagnée d’un adr, ce que vérifie un LLM dans la CI. De la même manière, SpecKit génère les spécifications détaillées, les tests d’acceptance à partir de la constitution. On retrouve dans le plan le TDD, qui est rendu obligatoire.

Pour garantir tout ça, 3 agents valident les PR pour vérifier que tout est fait dans le respect de la méthode définie. Et pour ça, les agents scorent les PR selon différents axes afin de la valider.

Et ils nous montrent ensuite comment ça se passe dans 3 cas différents.

Et dans l’ensemble, les agents détectent assez correctement les PR incorrectes (même si les slides sont facilement touffus et que les présentateurs humanisent les LLM).

Pour les présentateurs, le gros intérêt de SpecKit est de permettre aux développeurs d’aggréger des règles de documentation et de les rendre validantes. Et il permet aussi de vérifier que l’intention est clairement transcrite dans le code et dans la doc associée.

[Devoxx] Learning modern Java the playful way

Ca va être un talk en anglais plein de blagues (et c’est tant mieux).

Ils ont un fichier rempli de mèmes pour développeurs Java qui sont particulièrement bons. Marrit et Piotr sont par ailleurs Java Champions (et encore une fois, leur humour est parfait).

Ils savent tous les deux que rester à jour en Java est parfois difficile. Ils vont donc illustrer des fonctionnalités sympas avec des démos. Java 26 apporte … plein de trucs. Et Java 25, livrée 6 mois plus tôt apportait aussi … plein de trucs.

Le hello world Java 26 est maintenant plus court que celui en Python.

Et ils vont nous faire les démos en imaginant un site web de revente d’images obtenues sur des banques gratuites, mais transformées par un encodeur multimodal, et stockées dans une base Elastic (parce que Piotr travaille chez Elastic) sous forme d’embeddings (il faut bien montrer les capacités agentiques d’Elastic).

On commence par les records, pour lesquels Marrit rappelle qu’on peut surcharger les méthodes définies apr défaut.

A partir de Java 25, on peut utiliser des import module qui rendent les imports plus courts.

On peut aussi remplacer le Scanner par IO.readln(...).

Java 24 a aussi amené les stream gatherers (pour lesquels Piotr a déja fait un talk complet). Piotr nous montre comment ça peut simplifier une extraction parallèle de données.

Et maintenant, un peu de structured concurrency, en preview en Java 26 (et sans doute en Java 27). En gros, ça permet d’assurer plus facilement l’exécution et l’annulation synchronisée de tâches parallèles. La syntaxe est très différente, mais beaucoup plus courte. Et ça marchera très bien pour des données qui viennent de caches (potentiellement invalides). L’impact, c’est que CompletableFuture n’a en fait pas de futur.

Un point sur les lazy constants. Elles se créent avec une classe paramétrée LazyConstants qu’on initialise avec une lambda.

En Java 25, on peut écrire la doc en Markdown (en mettant /// devant).

En preview en Java 26, il y a le pattern matching sur les types primitifs.

Il y a encore des trucs en plus : l’API Vector, encore en preview (pour laquelle Marrit fait générer le code par l’agent intégré à IntelliJ).

En conclusion, chaque nouvelle version de Java est plus simple, plus rapide, même meilleure, et toujours gratuite.

[DevoxxFr] Prolog : un langage mature mais sous-estimé pour de l’IA symbolique !

Prolog est connu dans le monde académique, mais pas du tout dans l’industrie.

Pour Didier (malheureusement tout seul), les LLM sont une conclusion de l’approche connexioniste (on apprend à l’ordinateur à agir de manière intelligente) qui a le grand défaut d’être fondamentalement une boîte noire : on ne sait pas pourquoi le système prend une décision. Une autre approche est l’approche symbolique dans laquelle on s’appuie sur la logique. Ca permet par exemple de créer des systèmes experts. Ca a l’avantage de permettre l’analyse et même d’être prouvé mathématiquement.

Didier (et son collègue absent) ont tous les deux fait leur thèse à Toulouse sur Prolog. Comme ce sont des développeurs issus du monde académique, Didier définit d’abord ses termes qui peuvent être

• des littéraux (« a »)
• des atomes (a)
• des foncteurs (f(…))
• des variables (X)

Pattern matching et unification

Les termes peuvent être placés dans des graphes orientés f(X, a), f(g(a,b), a). Comme on a des graphes orientés, on peut faire du pattern matching (pour capturer les valeurs d’un terme à partir d’un motif). Et dans notre cas, X vaut g(a,b). Didier illustre ça avec un exemple en Java (assez tordu puisqu’il part tout de suite dans des histoires de successeur).

Ca a des inconvénients. Par exemple, f(X, X) est interdit. Et on ne peut pas mettre de variable dans le modèle.

Jacques Herbrand a proposé une méthode permettant de créer des substititions pour rendre deux termes identiques. Et normalement, l’unification résoud les problèmes liés au pattern matching.

Avec l’unification, on va donc pouvoir lier f(g(Y, b), Y) et f(X, a). Autrement dit, on « résoud » le système (enfin, je crois). Notez que l’unification se fait de manière incrémentale. Ce qui se complique quand les termes sont récursifs.

Logique du premier ordre

Gottlob Frege a imaginé au XIXème siècle un système formel permettant de raisonner mécaniquement sur les termes. Dans notre cas, ça se matérialise sous la forme d’un langage des termes, et d’un langage des prédicats (les implications logiques et la théorie ensembliste – quelquesoit, et il existe). Ca permet par exemple d’exprimer des phrases logiques comme « toute personne a une mère et un père biologique ». Pour Didier, un LLM pourrait transformer la phrase en français en phrase logique.

On peut ainsi créer du raisonnement en plusieurs parties.

D’abord par la mise en forme prénexe.

Ensuite l’herbrandisation (l’élimination des « quelquesoit »)

Puiss la skolémisation (l’élimination des « il existe »)

Grâce à ça, on simplifie l’expression. Et en fait, tout ça est mécanisable.

Ca permet de produire des solveurs SMT (satisfiabilité modulo théorique). Une première branche qu’on ne va pas suivre.

On va plutôt aller vers des clauses de Horn, des expressions constituées de ou et de négation ayant au plus un littéral positif.

Programmation en logique

Prolog est imaginé dans l’article « Un système de communication homme-machine en Français » en 1972. Prolog repose sur la résolution des clauses de Horn avec le support de l’unification. Une clause s’écrira

b:- a1, a2, ... aN

Qui se lit « b est vrai si a1 est vrai, a2 est vrai, aN est vrai ».

En Prolog, on va utiliser différentes notions

• Les assertions : b (qui dit que b est vrai)
• Les règles : b:- a1, a2
• Le but (ce qu’on doit démontrer) ?- c1, c2

Robinson a montré qu’on pouvat utiliser la résolution SLD pour atteindre le but. C’est en fait assez simple

On va lire les littéraux dans l’ordre. Si une étape échoue, on remonte à l’unification précédente et on tente si c’est possible une autre unification.

Extensions

Il est possible, grâce au cut, de contrôler le retour arrière. Il y en a deux : le green cut (qui ne change pas le résultat) et le red cut (qui peut changer les réponses). On essaye de ne pas l’utiliser.

Grâce au call, Prolog peut manipuler ses termes (je ne suis pas sûr de comprendre cette partie).

En explitant ces deux parties, on peut créer des OR.

La négation est elle aussi une extension, car elle casse l’hypothèse du monde clos de Prolog. Elle repose sur le call et le cut.

La programmation par contrainte est elle aussi une extension de Prolog, dans laquelle on va étendre la résolution avec du calcul.

Prolog en action

Didier a développé un solveur vérifiant la règle définie par l’état français sur le maximum de capacité d’emprunt à 35%.

Pour ça, il définit une règle d’endettement, puis utilise cette règle pour effectuer différents calculs. Il est assez impressionant de voir qu’une règle peut être très facilement utilisée de multiples façons différentes.

Il prend ensuite un exemple d’implémentation d’un système de lambda-calcul basé sur Prolog qui semble simple, mais que je n’ai pas compris.

Conclusion

Il y a énormément de choses extrêmement intéressantes à creuser (et je pense que j’y jetterai un oeil plus approfondi).

[DevoxxFr] Production Troubleshooting : boostez vos skills, une étude de cas

Introduction

Criteo est une boîte qui fait beaucoup de machine learning pour nous convaincre d’acheter des produits divers et variés. Pour ça, il faut beaucoup de données, et des algorithmes puissants, comme par exemple Map/Reduce. William prend donc le temps de nous expliquer cet algorithme sur un exemple très simple de comptage de mots. On peut faire la même chose pour grouper des niveaux de dépense par catégorie.

L’avantage de Map/Reduce sur une base de données classique est que c’est particulièrement résistant aux pannes, puisque le code s’exécute souvent de façon parallèle sans dépendances entre machines.

Evidement, Map/Reduce n’est pas vraiment facile à implémenter. Donc Criteo utilise Apache Spark qui fournit une couche d’abstraction permettant d’exécuter des requêtes SQL sur un cluster complet. Spark permet aussi de mieux surveiller l’exécution du pipeline. Ce pipeline est distribué sur tout un tas de machines, qui stocke des données sur des disques et qui communiquent par un réseau qui peut avoir des problèmes.

Présentation du problème

En production, William a eu un problème de données corrompues récement sur des jobs Spark.

C’est un phénomène récent, intermittent. Ca se passe dans le contexte d’une migration de données d’Amserdam vers Paris. Si Criteo arrête son flot de traitement, les modèles se dégradent très vite. Et ça brasse des sommes d’argent franchement importantes.

Et comme la migration est en cours, un job qui s’exécute à Paris peut avoir besoin de données stockées à Amsterdam. Avec une latence de 40ms, ce qui est très long à l’échelle de Spark. Ils ont donc modifié HDFS pour que les données soient accessibles facilement dans les deux datacenters.

Ce contexte est évidement un coupable parfait pour le problème rencontré. Et selon le rasoir d’Occam, c’est sans doute la bonne explication …

Pour William il y a sans doute soit des problèmes de consistance dans des données, soit des problèmes de timeout dans la lecture des données. Clairement, le problème de consistance est beaucoup plus coûteux en termes d’hypothèses que celui de timeout … qui nécessite toutefois qu’il y ait un bug dans Spark. Et ça, ça va à l’encontre de biais cognitifs (popularité et autorité).

En creusant, William découvre que le problème de timeout se produit dans un cas reproductible.

Bon, dans les détails, ça se cache au fond des « adaptive query execution » et de Kyuuby. Parce qu’avec Spark, on peut se retrouver avec beaucoup de tâches dans un stage, et donc beaucoupn de fichiers. Pour éviter ça, on peut redistribuer les tâches. A priori, ça voudrait dire que Kyuubi devrait disparaître, mais le bug est reproductible avec un flag basique de Spark (sans Kyuubi, donc).

Pour éviter les problèmes de repartition qui introduisent ce bug, on peut utiliser des seeds déterministes et réordonner après, ce qui en fait maintient le bug. Il faut donc maintenant plonger dans le code. Et en regardant bien, il semble qu’une comparaison de tableau introduise ce bug …

Pour vérifier ça, William teste le code Spark modifié avec un cluster Redis local (qui tourne sur un serveur avec 500 Go de RAM). Il trouve que dans certains cas, il y a des collisions sur des nombres à virgules qui sont peu différents.

Et quand Spark aggrège des valeurs numériques dans un job, additionner des grands nombres et des petits nombres ne marche pas (pour les nombres non entiers traditionnels).

Conclusion

Face à un bug, n’extrapolez pas. Répétez vos tests et présentez vos investigations à vos collègues. N’essayez pas de prouver une théorie, mais éliminez les théories invalides. Lisez le code source, et regardez les bug trackers (évidement, évitez les produits où le source n’est pas disponible). Cultivez aussi votre culture informatique, et en particulier les ordres de grandeur. Enfin, prenez le temps de comprendre réellement le problème.

Avec tout ça, la résolution de problème sera réellement satisfaisante.