Tous les articles
-
Le RGAA sans s'y perdre : six réflexes pour une application Phoenix accessible
Ce qu'il faut garder en tête du RGAA, le référentiel français d'accessibilité, puis six sujets qui reviennent dans toute application : le contraste, le titre de page, les liens qui ouvrent un nouvel onglet, les images, les vidéos et les raccourcis clavier. Pour chacun, ce que demande le référentiel, comment le faire simplement avec Phoenix, et comment le vérifier. -
Phoenix.LiveView.JS : ouvrir un panneau sans aller-retour serveur et sans écrire de hook
Pour ouvrir un panneau, on passe d'habitude par le serveur ou par un hook. LiveView propose une troisième voie : décrire en Elixir ce que le navigateur doit faire. On construit avec elle un panneau de filtres et une fenêtre de confirmation, lisibles au clavier et par un lecteur d'écran, avec un notebook pour voir ce que sont ces commandes. -
Ouvrir son API à un client sans navigateur : le jeton Bearer, du mot de passe au scope
phx.gen.auth reconnaît les visiteurs qui ont un cookie, phx.gen.json expose des routes JSON, et il manque le pont entre les deux : la reconnaissance d'un script, d'une application mobile ou d'un autre service. Un jeton qui existe déjà, deux plugs de dix lignes, une porte d'entrée, et les 135 tests passent. Avec un notebook qui rejoue tout sans base de données. -
Les uploads LiveView : déclarer ce qu'on accepte, et laisser le fichier arriver
Ajouter un justificatif à une note de frais tient en trois lignes qui déclarent ce que la page accepte. LiveView fournit le reste : une route dédiée par fichier, la validation avant le premier octet, la progression, le ménage, et un seul moment où le fichier nous est remis. Une découverte guidée, avec un test à chaque étape et un notebook pour la rejouer sans navigateur. -
Qui est là ? Découvrir Phoenix.Presence
Afficher « trois personnes regardent ce document » semble demander une base, un cache et une ronde de nettoyage. Avec Phoenix.Presence, c'est une dizaine de lignes dans une LiveView, et les départs, même brutaux, sont détectés sans qu'on écrive une ligne pour eux. Une découverte guidée, avec un notebook pour la rejouer. -
Mettre une application Phoenix en français : qui décide de quoi
Une application Phoenix peut être entièrement écrite en français sans être réellement francisée : les dates restent anglaises, les nombres prennent les mauvais séparateurs, les erreurs de formulaire suivent une autre langue. Derrière le mot « localisation » se cachent plusieurs sujets distincts. Voici comment les découper, quelle bibliothèque décide de quoi, et comment la locale circule dans l'application. -
Deux cents liens à vérifier
Un dépôt de documentation contient beaucoup de liens, et personne ne les surveille. C'est une bonne occasion de découvrir Req en construisant quelque chose : un vérificateur de liens d'une vingtaine de lignes, et trois problèmes en chemin qui font apparaître ce que la bibliothèque sait déjà faire. -
Un million de processus
« Elixir lance des millions de processus » : la phrase se répète sans jamais s'accompagner d'un chiffre. En voici. Un million de processus lancés, mesurés, mis sous une charge qui devrait tout geler — et qui ne gèle rien, pour une raison précise. Puis cinq millions, parce que le million n'était qu'un palier. -
Qui fait le café ? Une interface Livebook en quatre étapes
Kino a une trentaine de composants et aucune porte d'entrée évidente. On va donc construire une seule chose idiote — un tirage au sort avec roulement de tambour — et découvrir au passage la seule règle qui compte. En annexe : la transformer en application que l'équipe ouvre dans un navigateur, sans voir une ligne de code. -
Ash : décrire la ressource, et laisser le reste se déduire
Dans une application Phoenix classique, la même entité est décrite quatre ou cinq fois. Ash propose de ne la décrire qu'une seule fois, et d'en déduire le reste. Voici ce que ça donne, sur un exemple qui tourne en trente lignes, puis ce que ça coûte. -
mix release : ce qui est figé, ce qui se lit au démarrage, et les trois erreurs qu'on rencontre dans l'ordre
Un release Phoenix construit, démarré, arrêté, et fait échouer trois fois de suite pour de bonnes raisons. Chaque message d'erreur est reproduit tel quel — dont celui qui explique pourquoi éditer config/dev.exs ne change pas le port. -
Oban : la file d'attente est une table, et c'est toute la différence
Trois expériences sur Oban 2.24 : un job qui réussit, un job qui échoue et se replanifie, un doublon refusé. Chaque fois, la réponse est dans une ligne de la table oban_jobs — et c'est ce qui rend cette approche plus lisible qu'un Redis. -
Vous faites déjà de la télémétrie : ce que Phoenix émet sans qu'on lui demande
Seize gestionnaires d'événements tournent dans un projet Phoenix vierge. Les voir, brancher le sien sur une vraie requête, et lire ce que Phoenix et Ecto y mettent — en unités natives, ce qui est le premier piège. -
Les scopes de Phoenix 1.8 : le même générateur, avant et après
Lancez phx.gen.live avant d'avoir généré l'authentification, puis après. Le code produit n'est plus le même : chaque fonction de contexte reçoit un scope, chaque requête filtre, chaque diffusion PubSub est cloisonnée. Voici le diff, ligne par ligne. -
phx.gen.auth en 1.8 : le lien magique d'abord, et pourquoi le mot de passe devient optionnel
Le générateur d'authentification de Phoenix 1.8 ne demande plus de mot de passe à l'inscription. Ce que ça change dans le schéma, dans les jetons, et dans une clause de code qui refuse de s'exécuter pour une raison de sécurité précise. -
Une API REST avec Phoenix : ce que le générateur écrit à votre place
mix phx.gen.json produit six fichiers en une commande. Les lire, c'est comprendre comment Phoenix transforme un tuple d'erreur en 422 — et découvrir que la réponse vue en développement n'est pas celle que reçoivent les clients. -
Pourquoi mes erreurs de formulaire ne s'affichent pas
Un changeset invalide, des erreurs bien présentes, et rien à l'écran. Il y a deux portes entre une erreur Ecto et son affichage, et la plupart des gens n'en connaissent qu'une. -
Arrêter de déboguer avec des Logger.info : iex, IO.inspect, dbg, pry
Le réflexe Logger.info(inspect(truc)) a trois défauts qu'on ne voit qu'après avoir essayé autre chose. Petite échelle d'outils, du shell interactif au point d'arrêt, mesurée sur Elixir 1.19.5. -
La liste chaînée n'est pas le mauvais outil, c'est la matière première
Une file d'attente construite avec deux listes bat la liste native d'un facteur 2 600. Un zipper, d'un facteur 10 000. Aucune de ces structures ne remplace la liste : elles la réarrangent. -
Des tests concurrents avec une base de données : comment, et jusqu'où
async: true est possible en Elixir là où d'autres langages y renoncent. La sandbox Ecto explique pourquoi — et connaître ses limites évite le test vert qui masque un bug de production. -
« Let it crash » ne veut pas dire ce que vous croyez
La formule la plus citée d'Elixir est aussi la plus mal comprise. Elle ne dit pas d'ignorer les erreurs : elle dit de séparer le travail de la reprise. Avec ce que ça coûte, mesuré. -
Les hooks JavaScript de LiveView : la frontière et ses règles
Écrire son premier hook, comprendre ses six moments de vie, faire circuler l'information dans les deux sens — et surtout répondre à la seule question qui compte : qui possède ce morceau de DOM ? -
Les pannes silencieuses de LiveView
Trois défaillances dont l'information se perd entre le navigateur et le serveur — l'une ne laisse aucune trace, une autre accuse le mauvais module, et la première laisse même les tests au vert. -
L'immutabilité ne coûte pas ce que vous croyez
Si toute modification crée une nouvelle valeur, comment un langage immuable peut-il être rapide ? Réponse mesurée : parce que rien n'est copié. Le partage structurel, ses limites, et là où l'immutabilité coûte vraiment. -
Structurer un projet Elixir : ce que le compilateur ne vérifie pas
Presque toutes les conventions d'un projet Elixir sont facultatives — rien ne casse si vous les ignorez. Sauf à un endroit, où Elixir refuse de démarrer. Voici lequel, et pourquoi les autres méritent quand même d'être suivies. -
Brancher un notebook sur une application qui tourne
Les journaux ne disent pas tout, et un iex distant s'oublie à mesure qu'on tape. Livebook sait se connecter à un nœud Elixir vivant — voici les deux mécanismes, ce qu'ils permettent, et les précautions qu'ils exigent. -
Un outil interne en trente lignes, dans un notebook
Le petit script qu'on écrit dans iex, qu'on lit une fois et qu'on reperd. Livebook en fait un outil qui se garde, se partage et s'utilise sans lire le code — voici comment, et ce que ça ne remplace pas. -
Le HTML en base de données est un piège
Stocker la sortie d'un éditeur de texte riche paraît évident, jusqu'au jour où il faut interroger, migrer, ou signer une URL. Ce qui change quand on stocke l'arbre du document plutôt que son rendu. -
Aja : quand la liste chaînée n'est plus le bon outil
Les listes Elixir sont des listes chaînées : accéder au 5000e élément coûte 5000 sauts, et y ajouter à la fin recopie tout. Aja apporte des vecteurs et des maps ordonnées — voici quand ça vaut le détour, et quand ça n'en vaut pas. -
Composer des requêtes Ecto : la fonction qui prend une query et en renvoie une
Une requête Ecto est une donnée, pas une chaîne SQL. Ce seul fait permet des filtres réutilisables et testables — à condition de connaître le piège des bindings positionnels. -
Lire une stacktrace Elixir sans paniquer
Une erreur Elixir suit toujours la même structure : le type dit pourquoi, la trace dit où. Anatomie, les sept erreurs qui couvrent presque tout, et le cas tordu du GenServer qui meurt. -
Les streams LiveView : arrêter de garder 500 lignes en mémoire
Un assign qui contient une liste, c'est cette liste conservée sur le serveur pour chaque visiteur connecté. Les streams déplacent la collection dans le DOM — avec quelques contreparties qu'il vaut mieux connaître avant. -
Ecto.Multi : composer une transaction sans se noyer dans les with
Enchaîner plusieurs écritures en base avec Ecto.Multi plutôt qu'avec des with imbriqués : composition, rollback automatique, et des erreurs qu'on peut enfin exploiter.