ErrorNot: Une application pour être sûr(e) que toutes vos erreurs seront vues et corrigées

Posté par virtuo le 29 mars 2010 à 20:09. Modéré par Mouns.

Étiquettes :

mar.

2010

ErrorNot est une application Web Rails qui vous permettra de collecter les différentes erreurs de vos projets, pour être sûr qu'aucune n'échappera à votre attention et que toutes seront corrigées. Il s'agit d'un "must have" qui vous rendra meilleur(e) en terme de gestion de qualité. Combien d'entre-nous vont régulièrement scruter les logs de leurs applications à la recherche d'erreurs ? Pour ceux qui le font, le faites-vous suffisamment sérieusement (à intervalles réguliers, en scrutant bien toutes les lignes, éventuellement en regardant si l'erreur a déjà eu lieu) ? Pour ceux qui scrutent leurs logs et pensent le faire suffisamment sérieusement, n'êtes-vous pas fatigués de faire ça ?

Si vous avez répondu oui ou non à l'une des questions précédentes, alors ErrorNot est fait pour vous ! ErrorNot collecte les erreurs de votre application à l'aide d'un greffon (pour l'instant disponible en Ruby, PHP ou Python). Le greffon que vous intégrez à votre application va attraper les erreurs levées par celle-ci et les envoyer sur ErrorNot. ErrorNot se charge alors de classer les erreurs de chaque projet selon différents critères (erreur résolue ou non, nombre d'erreurs similaires...), et de vous présenter le tout de manière conviviale. ErrorNot peut même vous notifier par email à chaque fois qu'un nouveau type d'erreur est reçu (type, pas erreur, sinon vous ne liriez plus vos emails).

ErrorNot n'est pas un bug tracker. Aussi, ses fonctionnalités sont limitées à la collecte des erreurs et informations relatives (dont commentaires des développeurs) et à la restitution du tout (ce qui inclut bien évidemment la notification). Et c'est précisément ce qui fait son attrait : un outil simple pour un problème simple.

Aller plus loin

GitHub ErrorNot (16 clics)
Demo (12 clics)
Annonce de lancement (avec copies d'écran) (10 clics)
ErrorNot Ruby notifier (3 clics)
ErrorNot PHP notifier (9 clics)
ErrorNot Python notifier (2 clics)

# sinon faut bien coder aussi

Posté par lsmod le 29 mars 2010 à 21:41. Évalué à 2.

Personnellement en PHP je met des assertions (surtout pour vérifier le type des variables dans la construction de requêtes SQL). Je les désactive une fois que je passe en production.
Des exceptions, et je catch les exception au plus au niveau du programme je récupère le détails et l'envois dans un logs (date/heure, utilisateur, page appelée, referer, numéro de la ligne, message et la trace) .
Aussi sur option je peux log mes requêtes SQL.
Après j'ai eu la flemme de me faire un système d'alerte.

Mais pour avoir un prog de bonne qualité moi je penche pour les assertions. Vérification qu'on a bien récupérer toute les variable $_POST ou $_GET avant de faire quoi que ce soit, pareil pour la construction de requêtes, toujours faire des cast sur le paramètre $_POST et $_GET.

De cette manière l'assertion me bloque à la moindre connerie que je fait pendant le développement je peux ignorer l'erreur.
- [^] # Re: sinon faut bien coder aussi
  
  Posté par jjl (site web personnel) le 29 mars 2010 à 23:13. Évalué à 10.
  
  A programmer who uses assertions during testing and turns them off during production is like a sailor who wears a life vest while drilling on shore and takes it off at sea.
  Tony Hoare
  
  ce qu'on pourrais traduire par :
  Un programmeur qui utilise des assertions pendant les tests et les désactives en production est comme un navigateur qui porte un gilet de sauvetage pendant les manœuvres à terre et l'enlève en mer.
  
  et avant que quelqu'un ne me réponde:
  La faculté de citer est un substitut commode à l'intelligence.
  Sommerset Maugham
  ;)
  - [^] # Re: sinon faut bien coder aussi
    
    Posté par lsmod le 30 mars 2010 à 04:30. Évalué à 2.
    
    marrant la comparaisons avec le marin et son gilet, ça veux pas dire grand chose n'ont plus.
    
    Une fois le boat en mer j'ai les exception en cas de tempête (on s'en fous du gilet). Les assertion c'est pour vérifier automatiquement derrière l'humain un minimum l'étanchéité du beaucoup avant de le foutre à l'eau (l'erreur est humaine) .
    Parce que pour une erreur stupide t'as plus cas ressortir ton boat de l'eau à moitié remplis de flotte (et pfff c'est à ce pèter le dos).
    Et là t'as un bon paquet d'heure pour le sortir de l'eau tout ça parce que t'avait oublier de collematter entre deux planches...
    - [^] # Re: sinon faut bien coder aussi
      
      Posté par Maxime (site web personnel) le 30 mars 2010 à 12:24. Évalué à 2.
      
      "n'ont plus" :D
      
      C'est pas parce que tu utilises des assertions que ton code devient sans bug... Oui c'est bien d'en utiliser mais je doute que ça suffise.
    - [^] # Re: sinon faut bien coder aussi
      
      Posté par monde_de_merde le 30 mars 2010 à 15:36. Évalué à 4.
      
      Ton mode de développement suppose juste que durant ta phase de test (la navigation près des côtes) tu as envisagé et testé toutes les situations que ton application est susceptible de rencontrer en production (la navigation en mer).
      
      C'est juste impossible.
      - [^] # Re: sinon faut bien coder aussi
        
        Posté par Gniarf le 30 mars 2010 à 16:02. Évalué à 3.
        
        et euh comment on fait pour lancer les fusées et autres navettes, comment on fait pour concevoir des sondes qui iront photographier les satellites de Saturne ?
        
        ça a beau être impossible de tout prévoir, il faut le faire quand même.
        
        [^] # Re: sinon faut bien coder aussi
        
        Posté par Jean B le 30 mars 2010 à 16:23. Évalué à 4.
        
        Ben justement les fusées et autres navettes ne désactivent pas leurs capteurs et systèmes de sécurité lors du lancement final. Ça permet de corriger le problème au lancement suivant ...
        
        [^] # Re: sinon faut bien coder aussi
        
        Posté par lsmod le 30 mars 2010 à 18:43. Évalué à 2.
        
        c'est bien pour ça qu'il y a les exception et vérification avec les code d'erreurs. De plus on peux très bien laisser les assertions en production cependant les assertion comme je dit sont surtout la pour détecter les erreur de la part du programmeur, c'est à dire exécuter une fonction dans les mauvaises conditions.
        L'assertion bloque le développeur dans ce cas il n'a plus quand mettre en place les vérifications nécessaire pour que cela n'arrive jamais.
        Moi je part du principe que tous les programmeur font des erreurs alors sur des projet une peu grand autant ce mettre des garde fou.
        
        Après pour faire les tests je crois que le meilleur c'est de faire du fuzzing même si j'ai jamais essayer.
        
        [^] # Re: sinon faut bien coder aussi
        
        Posté par claudex le 30 mars 2010 à 20:37. Évalué à 6.
        
        C'est pour ça qu'il arrive que des fusées explosent au décollage, que des sondes loupent leur cible, ou s'écrasent au lieu d'atterrir. La conquête spatiale montre justement qu'on ne peut pas tout prévoir.
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Et avec des IDs dans l'erreur ?

Posté par Vincent le 29 mars 2010 à 22:59. Évalué à 2.

Que se passe t'il avec 1000 fois la même erreur mais contenant un id de produit par exemple ? 1000 types sont créés ?

Il faudrait pour cela je pense ajouter la possibilité de pouvoir remplacer un morceau de l'erreur par une regex ...
- [^] # Re: Et avec des IDs dans l'erreur ?
  
  Posté par claudex le 29 mars 2010 à 23:21. Évalué à 5.
  
  On peut faire 1000 fois 1 erreurs. Euh non, on peut faire 1000 erreurs 1 fois. Je ne sais plus, je vais prendre un chewing-gum plutôt (l'ami le chien de mickey).
  « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
- [^] # Re: Et avec des IDs dans l'erreur ?
  
  Posté par virtuo le 30 mars 2010 à 11:39. Évalué à 2.
  
  Si l'erreur est la même, elle devrait avoir la même stack trace (et message), et juste une variable change (l'id du produit, que ce soit dans les paramètres, la session...), donc l'erreur devrait être considérée comme la même...
# Un must have, oui !

Posté par Patrick Fratczak le 29 mars 2010 à 23:05. Évalué à 5.

Je l'ai installé récemment pour un de mes projets rails et c'est vraiment un must have !
Des erreurs, sur un projet Rails en production, ne se voient que dans les logs... les visiteurs ne voient que la partie immergée de l'iceberg ... heu du bug et ne savent pas forcément quoi relever, quoi dire quand l'erreur leur tombe dessus .... sans compter les erreurs qu'on ne voit pas.
ErrorNot est là ! Et ErrorNot est intelligent... il reconnait les erreurs redondantes en ne vous assaillent pas de mails insultants ... non, il remonte toutes les infos : session, environnement, url, request, .... tout tout tout ce qu'il faut pour agir avant d'avoir le coup de fil ou le mail de l'utilisateur en colère !
Je l'ai mis en place et je ne m'en séparerai plus !
Maintenant, à faire évoluer ! Mais déjà là, ça roule ! Merci !

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.