• Perte de données Gitlab

Perte de 300Go de données mais information très bien suivie

---

Déboguer une appli rails quand on débute

Ronan : contrôle du code paiement KO en prod, 3000€ de manque à gagner en abonnements. À l’époque, déployer en prod c’était uploader sur un FTP.

Guirec : bons outils pour monitorer l’application. Reprodution du bug : étapes précises et minimales pour reproduire le bug. Le mieux c’est d’ajouter un test, voir le KO, puis faire le fix.

• Monitoring
• Tests (quand tu codes, quand tu livres, non-régression)
• Rapport de bug

Sylvain : Quelle différence entre le debug durant le dev, et durant la prod ?

Guirec : NewRelic pour les erreurs, la perf, le JS Notification d’erreur (mail, notif, etc.) avant que le manager / le user voie.

Ronan : pour ça nous sommes sur HoneyBadger Gros problème de “s’habituer à l’erreur” et ne plus faire attention. On ne fait pas attention et une erreur proche peut passer à la trappe. Le signal ne doit pas se transformer en bruit.

Guirec et Bob : et un filtre/script pour cacher la misère

Céline : Rollbar pour les logs en prod

Céline, Bob et Ronan : puts c’est le meilleur outil de debug :)

Céline : j’ai plusieurs niveaux, et avant d’arriver au niveau Danger, j’ai déjà plusieurs logs d’avertissement que le fonctionnement ne semble pas normal.

Bob : OK mais du coup le code arrive parfait et on n’a que des bugs de prod ? Que faites-vous en dev ?

Ronan : on ne fait pas HoneyBadger en dev, mais en staging pour la dépréciation. Pour le reste, je mets des puts et je regarde où j’en suis.

J’ai piqué l’astuce de @kytrinynx et je mets raise hell.

Céline : j’utilise beaucoup puts et la gem pry pour interagir avec le flux. J’arrête, je teste, j’inspecte les variables, je remonte les appels…

Guirec : j’ai piqué une astuce à @tenderlove dans son blog I am a puts debuggerer

Ronan : le post est super intéressant même hors débug pour la métaprog utilisée.

Guirec : quand tu veux savoir ce qui se passe, c’est pratique.

Agathe : j’utilise aussi des gems, mais un outil plus costaud : Rubymine. Je peux aller en profondeur dans le code, les statuts etc. On peut associer les endpoints précis directement dans Rubymine.

Bob : ça lance Rails ou ça se connecte à une instance ailleurs ?

Agathe : c’est au choix !

Céline : j’utilise aussi RubyMine et ça me permet de naviguer vite, de lire le code de Rails.

Ronan : je pleure un peu, ça me rappelle Visual Studio, donc pour les vieux de la vieille qui préfèrent un Textmate, il y a bundle open.

Agathe : et ça te permet d’inspecter ?

Ronan : non, mais c’est déjà pas mal comme usage low-tech.

Bob : oui, moi aussi j’utilise encore better_errors et c’est très bien.

Ronan : en gros plus tu es vieux plus tu utilises de vieux outils. Et toi Guirec ?

Guirec : je suis sous vim, low-tech aussi. Il y a aussi CTAGS dans plusieurs éditeurs pour naviguer dans le code.

Ronan : pour ce qui est d’un “vrai” débuggueur, si je dois l’utiliser en Ruby je me dis que c’est mon code qui m’échappe, mais pour du Javascript dans le navigateur, c’est vrai que j’utilise le debugger des navigateurs. Mais c’est peut-être que je ne connais pas assez bien mon JS.

Guirec : non, pas forcément, quand c’est complexe tu peux avoir besoin. On ne peut pas connaître par coeur tout ce qui se passe dans l’appli.

Par exemple sur une appli d’il y a 3 ans, par exemple, etc.

Agathe : je suis d’accord, j’utilise surtout le debugger quand je ne comprends pas bien le bug. Ça finit en général par être un problème dans Rails.

Bob : j’ai rarement un souci avec Rails.

Sylvain : j’en ai très rarement aussi. J’ai dû trouver une dizaine de bugs ActiveRecord. En général c’est moi qui ai mal appelé ActiveRecord. Je m’inquiète si ça vous arrive souvent, c’est peut-être un abus de métaprogrammation ? À l’école j’ai vraiment fait du C, gdb, valgrind, mais j’ai pas trop besoin.

L’avantage du très-low-tech c’est que tu peux le faire en prod. (terreur dans l’auditoire) En fait c’est dommage de devoir intervenir en prod et se sentir coupé de la plupart de ses outils. Du coup j’essaie de coder en pensant “et si je devais intervenir en prod, je veux que mon code soit simple”.

Ronan : j’aime beaucoup la similarité dev/prod aussi, mais le souci avec ça quand on s’énerve tard le soir, c’est de mettre des gros mots dans le code et le message d’erreur, et puis un jour on se fait appeler par un client “je comprends pas, quand j’ai une erreur il m’insulte”.

Céline : tu parlais de JS, c’est hallucinant de voir le nombre de log qui restent en prod dans un front JS.

Sylvain : l’avantage quand tu connais bien les gens, c’est que tu sais que tu peux grepper ça dans la codebase ;) En fait j’ai un dashboard où je déclare le niveau de maturité de chaque bout de code, et où je sors ça pour cibler les relectures et détecter les soucis de qualité. Idem, quand une méthode est dépréciée on ajoute des logs etc.

Au lieu des gros mots on aura plutôt FIXME, UGLY TODO ou PERF, et du coup je peux facilement rechercher des chaînes dans ton code.

Ronan : rails notes permet ça aussi Bob: il y a même des plugins pour ajouter ça dans des tickets GitHub. Céline : RubyMine aussi fait ça :)

Agathe : nous on utilise SumoLogic qui ajoute des codes pour tracer l’événement.

Ronan : j’aime beaucoup depuis Rails4, l’ajout d’un UID de requête.

Sylvain : c’est un sujet assez proche des analyses et audits de sécu. Sur la sécu : il faut que toute intrusion soit détectée et fasse du bruit. Sur les audits : tu as parfois des infos réglementaires ou l’obligation de fournir une rétrospective de ce qui s’est passé. C’est un événement métier à part entière donc on l’ajoute comme n’importe quelle fonctionnalité : le log de ce qui se passe et bien classifié. Ça marche aussi pour convaincre votre chef, le mot magique audit/dashboard ;)

Guirec : du code sans bug ça n’existe pas.

Ronan : je parlais avec Ori Pekelman de ça : pour lui, il compte chaque ligne de code comme une ligne de bug. Chaque ligne est une dette.

Céline : oui je fais du bug-driven development, il vaut mieux que ça arrive en dev qu’en prod.

Ronan : quand on tombe sur un bug, faire un test de non-régression. D’abord c’est plus simple pour reproduire, et le cas spécial est géré.

Sylvain : c’est aussi un côté de récupération avec grâce. Au bout d’un moment il faut prévenir le client. Il faut demander au métier de spécifier ces cas-là. J’ai beaucoup moins de bugs depuis que je pense toujours à “si ça rate, comment je préviens l’utilisateur” voire plus avancé encore “si l’utilisateur lui-même se rate en faisant un truc important (mauvais email, mauvais numéro de CB), comment peut-il revenir en arrière ?”

C’est rassurant car on accompagne, on propose, et on retire énormément de tickets de bug, et aussi de frustration de l’utilisateur qui pourrait se sentir pieds et poing lié.

Bob : le client montre le bug et le développeur idiot regarde le doigt.

Guirec : bien faire ses tests avant, procédure rigoureuse. Moi je les fais le matin, car j’ai eu le temps d’oublier ce que j’ai fait la veille. Je pense que la revue de code permet d’avoir un oeil plus critique sur ce que tu as suivi.

Bob : on peut tout à fait parler de pair programming ou de TDD dans un prochain épisode.

---

Découvertes des invités

• Sylvain Abélard

Moteur de recherche pratique, contextuel, respectueux de la vie privée. Business model basé sur le partenariat et les recommendations, Amazon notamment. – DuckDuckGo

• Agathe Begault

Moteur de recherche français (cocorico) sans tracking/historique. Business model basé sur rétrocommissions sur les achats aussi – Qwant

• Ronan Limon Duparcmeur

Thriller de Ben Winters, mais l'esclavage est autorisé, le racisme est onmiprésent. C'était un coup qui fait bien réfléchir. – Underground Airlines

• Céline Martinet Sanchez

Actus Internet, tech et gadgets, toutes les deux semaines – Le Rendez-vous Tech

• Bob Maerten

Pour apprendre Vue.js - traduction récente en français – Maîtrise de Vue.js

• Guirec Corbel

Pour gérer mon temps depuis que je suis en télétravail – Technique Pomodoro