C'est en général en suivant ce genre de règle que l'on évite de mettre des eval() dans un fichier de configuration, cela parait pratique pour le dev, mais pour la validation, c'est impossible à tester.
Si le temps manque, cela peut se faire par "sampling". Cela mets la pression sur le développeur, et cela évite au testeur de se laisser tenter par un "return true;" dans un tests… (vécu).
La vérification de couverture, cela peut être rapide. Cela permet au minimum de découvrir une zone oubliée. C'est toujours instructif.
"Les tests couvrant de haut niveau peuvent parfois être vite limités par la combinatoire des cas possibles (qui explose). Dans ce cas, on peut couvrir en haut niveau les cas nominaux et les cas d'erreur courants, et laisser les tests de plus bas niveau couvrir les autres cas d'erreur."
C'est vrai, d’où l’intérêt de concevoir en fonction des testes pour ne jamais avoir ce genre cas. Ce cas veut juste dire que tu as une surface énorme de bug potentiel, et je ne parle pas de surface d'attaque de sécurité. J'aime bien aussi les tests avec fuzzers, cela doit permettre de couvrir un paquet de cas.
Concernant vos tests, vous faites de la revue de code de test ? Les tests (non unitaire) sont écrit par des personnes différentes ? La couverture est bien vérifié ?
Je suis tombé sur le Dell XPS13 dont une version est livré avec ubuntu.
Le souci que je vois est qu'il semble chauffer pas mal (jusqu'à 60°C à l'arrière), mais bon, c'est cpu à fond.
Il est difficile de savoir si l'écran est matte ou pas. Cela dépend des sources. Un ultrabook voyage, il a de grande chance d'être utilisé en extérieur, ce qui est quasi impossible avec un écran brillant.
Je cherche toujours un ultrabook supporté sous Linux :
* qui supporte correctement le suspend-to-disk
* avec gpu intel
* 13.3"
* dalle matte
* full HD mini (1000 pixels vertical minimum, en 16/10, c'est le mieux, mais cela n'existe plus)
* < 2kg (et une petite alim !)
* core i3 minimum
* > 5h d'autonomie
* ssd 256Go
* 6/8 Go de Ram
* garantie avec prise en charge du matériel (type Dell), les SAV de 6 semaines, cela me gonfle.
+ prise HDMI et slot SD, si possible, cela dépanne toujours, en plus de l'usb 3.0
J'ai pas encore trouvé (le XPS13 n'a pas de port HDMI et la dalle est à priori brillante).
"le ND ne signifie pas que les modifications ne sont pas autorisées, mais que toute modification doit être soumise à l'auteur,"
Je crois que le prochain qui me sort cet argument, je lui pose un contrat sur sa tête. Cet argument révèle à quel point son auteur n'a rien mais alors, absolument rien, compris au libre et à ses avantages.
"Est-ce réellement choquant ?"
Si le but est d'éviter la confusion, l'auteur peut faire comme Mozilla ou Mageia : déposer une marque !
"Tu peux rarement avoir une couverture superieur a 80%, car juste la gestion des erreurs qui n'arrivent jamais et sont difficile a injecter durant tes tests"
L'avantage de s'obliger à 100% de couverture, c'est que te repenses ton architecture, pour éviter justement tout ces cas, qui n'existent pas. Coder en imaginant le test, peut faire gagner beaucoup de temps.
Concernant les piles logiciels, si chaque bout est correctement testé, l'assemblage est (censé) avoir peu de bugs.
En même temps, les tests unitaires c'est pas super utile, si tu as des vrai tests couvrant de très haut niveau. Il est rare d'avoir un bug de bas niveau non trouvé par un test haut niveau, et il est impossible de trouver un bug de haut niveau avec un test unitaire (problème d'intégration, trou de spec, etc…).
J'ai jamais vu de test LLR qui trouve des bug non trouvé par les tests HLR, en général, il s'agit de mode non utilisé.
Pas une compta, sauf si tu fais celle d'un pays. Avec un double, tu gères des nombres de plusieurs milliards sans perte de précision. Il faut juste éviter de passer en 32 bits pour aller plus vite…
Intégration continue ?
Test automatique au moins partiel ?
Traçabilité avec les exigences ?
Test qui couvre toutes les exigences
bugtracker ?
Revue de code ?
Revue du code des testes ?
De toute façon, il faut définir soi-même le delta. J'aimerais tellement voir un langage de programmation qui gère des réel avec range et prévision. Tout un tas de transformation resterait valide (de mémoire, c'est encore un anneau ou un corps). Une fois simplifié, tout est transformé en code flottant.
"total à diviser en pourcentage (ça fait 1/quelque chose)…)"
C'est vrai, mais si c'est pour un affichage, tu te fou d'une erreur inférieur à 10-3. La division par zéro, c'est encore autre chose. L'erreur existe, avec des maths pure, les entiers, ce n'est pas spécifiques au flottant.
Je me rappelle des discussions de codeurs audio qui vantaient les entiers 64 bits, avec lequel ils faisaient du virgule fixe, avec 16 bit sous la virgule et donc tout un tas de contraintes sur les opérations.(j'ai codé de la trigonométrie en virgule fixe sur µP, c'était pas drôle) Tout cela parce que les float 32 bits, avec 24 bits de mantisse ont forcément des erreurs inclus. Aujourd'hui, vu la demande de puissance, des algos audio peuvent entièrement être codé en double, avec un code beaucoup plus simple.
"(note que je n'ai rien contre le fait d'utiliser les float en science, où il faudra incorporer leur imprécision dans la détermination de l'imprécision du résultat)."
Demande à Alenvers, de mémoire, c'est son boulot, et évidement qu'il en tient compte.
"qu'un centime d'erreur dans un compte de plusieurs centaines de milliers de franc ce n'est rien. Mais mon tympant se souvient encore du mécontentement d'une cliente, qui a passé avec moi des heures au téléphone pour un centime d'erreur, simplement parce que les bons comptes font les bons services publics. :D"
254 (un double), c'est 1016, ce n'est pas une erreur sur 100 000 ! De plus, les erreurs de centimes (toujours dans le même sens) pour faire croire à une erreur informatique, les grosses boites appellent cela du "pricing". On a un prix annoncé de 30€ ttc, puis il donne le prix HT, puis calcul des taxes, et le prix à payé devient 30.01€ et non plus le prix ttc de la pub.
C'est pourtant 2 commentaires au dessus. Les arrondis en question sont très bien définit, et garantisse une sorte d'annulation de l'erreur. Les vrais problèmes se posent lors d'addition/soustraction de nombre de taille très différente.
Ce que tu ne comprends pas, et que pourtant quelqu'un à très bien résumé avec une citation de Linus, est que la plus part du temps, on s'en fout que 1/3*3 != 1.0. En général on veut 1/3*3 - 1.0 < delta, avec delta = 10-6 ou 10-10. Cela dépend des usages. Toutes les maths sont faite ainsi sur ordinateur, regardes comment est codé la libm. Regardes l'astuce de la multiplication par une constante pour Doom pour éviter une division, c'est toujours le même principe : la précision est-elle suffisante ou pas.
L'imprécision est même inclus dans les données d'entrée : il n'existe aucun "capteur absolue", il y a toujours une erreur estimable. Idem pour les effecteurs qui n'ont jamais de précision infini. Même les algorithmes de calcul sont souvent des approximations de la réalité (en simulation par exemple). Quel intérêt de faire des résultats avec 15 chiffres, quand l'algo ne peut en sortir que 6 ?
Dans le cas de calcul monétaire, on veut juste que les résultats de compte finaux soit juste à quelques fractions de centime pret, mais c'est vrai qu'il est plus simple d'utiliser des grand entiers pour y arriver.
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.
C'est en général en suivant ce genre de règle que l'on évite de mettre des eval() dans un fichier de configuration, cela parait pratique pour le dev, mais pour la validation, c'est impossible à tester.
"La première sécurité est la liberté"
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.
Si le temps manque, cela peut se faire par "sampling". Cela mets la pression sur le développeur, et cela évite au testeur de se laisser tenter par un "return true;" dans un tests… (vécu).
La vérification de couverture, cela peut être rapide. Cela permet au minimum de découvrir une zone oubliée. C'est toujours instructif.
"La première sécurité est la liberté"
[^] # Re: qu'est-ce qu'il dit ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 3.
Le munci est un syndicat d'informaticien il me semble. Cela peut aussi servir dans ton cas.
"La première sécurité est la liberté"
[^] # Re: Un Thinkpad
Posté par Nicolas Boulay (site web personnel) . En réponse au message Choix d'un ultrabook. Évalué à 2.
x230 : "Écran LED 12,5 pouces HD (1366x768)"
Pas glop non plus, ça.
"La première sécurité est la liberté"
[^] # Re: LinuxFr chez Vidberg
Posté par Nicolas Boulay (site web personnel) . En réponse au journal tric trac linkeo-isé. Évalué à 6.
On y a apprend que maintenant linuxfr fait peur. sisi.
"La première sécurité est la liberté"
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 3.
"Les tests couvrant de haut niveau peuvent parfois être vite limités par la combinatoire des cas possibles (qui explose). Dans ce cas, on peut couvrir en haut niveau les cas nominaux et les cas d'erreur courants, et laisser les tests de plus bas niveau couvrir les autres cas d'erreur."
C'est vrai, d’où l’intérêt de concevoir en fonction des testes pour ne jamais avoir ce genre cas. Ce cas veut juste dire que tu as une surface énorme de bug potentiel, et je ne parle pas de surface d'attaque de sécurité. J'aime bien aussi les tests avec fuzzers, cela doit permettre de couvrir un paquet de cas.
Concernant vos tests, vous faites de la revue de code de test ? Les tests (non unitaire) sont écrit par des personnes différentes ? La couverture est bien vérifié ?
"La première sécurité est la liberté"
[^] # Re: dell ?
Posté par Nicolas Boulay (site web personnel) . En réponse au message Choix d'un ultrabook. Évalué à 2.
Il m'a l'air très bien comme ultraportable. 14" mais 1.7kg. Cela devrait aller.
Est-ce que le bloc d'alimentation est le même que les autre Dell (gros et lourd donc) ou pas ?
"La première sécurité est la liberté"
[^] # Re: Zareason UltraLap 430
Posté par Nicolas Boulay (site web personnel) . En réponse au message Choix d'un ultrabook. Évalué à 3.
"(1366x768) Glossy"
c'est pas glop du tout ça :/
"La première sécurité est la liberté"
# dell ?
Posté par Nicolas Boulay (site web personnel) . En réponse au message Choix d'un ultrabook. Évalué à 2.
Je cherche aussi un ultrabook supporté par linux.
Je suis tombé sur le Dell XPS13 dont une version est livré avec ubuntu.
Le souci que je vois est qu'il semble chauffer pas mal (jusqu'à 60°C à l'arrière), mais bon, c'est cpu à fond.
Il est difficile de savoir si l'écran est matte ou pas. Cela dépend des sources. Un ultrabook voyage, il a de grande chance d'être utilisé en extérieur, ce qui est quasi impossible avec un écran brillant.
Je cherche toujours un ultrabook supporté sous Linux :
* qui supporte correctement le suspend-to-disk
* avec gpu intel
* 13.3"
* dalle matte
* full HD mini (1000 pixels vertical minimum, en 16/10, c'est le mieux, mais cela n'existe plus)
* < 2kg (et une petite alim !)
* core i3 minimum
* > 5h d'autonomie
* ssd 256Go
* 6/8 Go de Ram
* garantie avec prise en charge du matériel (type Dell), les SAV de 6 semaines, cela me gonfle.
+ prise HDMI et slot SD, si possible, cela dépanne toujours, en plus de l'usb 3.0
J'ai pas encore trouvé (le XPS13 n'a pas de port HDMI et la dalle est à priori brillante).
"La première sécurité est la liberté"
[^] # Re: mias pourquoi diable....
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'éducation nationale publie des polices de caractères cursive libres... de diffusion. Évalué à 5.
"Je pense que le choix de la licence a ete murement reflechi "
Je pense justement que : "pas du tout".
"La première sécurité est la liberté"
[^] # Re: Mais pourquoi diable autoriser les modifications ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal L'éducation nationale publie des polices de caractères cursive libres... de diffusion. Évalué à 3.
"le ND ne signifie pas que les modifications ne sont pas autorisées, mais que toute modification doit être soumise à l'auteur,"
Je crois que le prochain qui me sort cet argument, je lui pose un contrat sur sa tête. Cet argument révèle à quel point son auteur n'a rien mais alors, absolument rien, compris au libre et à ses avantages.
"Est-ce réellement choquant ?"
Si le but est d'éviter la confusion, l'auteur peut faire comme Mozilla ou Mageia : déposer une marque !
"La première sécurité est la liberté"
[^] # Re: Ce qu'on demande à un développeur aujourd'hui...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 2.
"Tu peux rarement avoir une couverture superieur a 80%, car juste la gestion des erreurs qui n'arrivent jamais et sont difficile a injecter durant tes tests"
L'avantage de s'obliger à 100% de couverture, c'est que te repenses ton architecture, pour éviter justement tout ces cas, qui n'existent pas. Coder en imaginant le test, peut faire gagner beaucoup de temps.
Concernant les piles logiciels, si chaque bout est correctement testé, l'assemblage est (censé) avoir peu de bugs.
"La première sécurité est la liberté"
[^] # Re: Les tests unitaires, c'est bon, mangez-en :-)
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 6.
En même temps, les tests unitaires c'est pas super utile, si tu as des vrai tests couvrant de très haut niveau. Il est rare d'avoir un bug de bas niveau non trouvé par un test haut niveau, et il est impossible de trouver un bug de haut niveau avec un test unitaire (problème d'intégration, trou de spec, etc…).
J'ai jamais vu de test LLR qui trouve des bug non trouvé par les tests HLR, en général, il s'agit de mode non utilisé.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
on parle de nombre dans un range entre 0.001 et 1 milliard. Les exposants seront très similaires.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
Pas une compta, sauf si tu fais celle d'un pays. Avec un double, tu gères des nombres de plusieurs milliards sans perte de précision. Il faut juste éviter de passer en 32 bits pour aller plus vite…
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
Si justement :/
"La première sécurité est la liberté"
[^] # Re: qu'est-ce qu'il dit ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Ce qu'on demande à un développeur aujourd'hui. Évalué à 3.
Intégration continue ?
Test automatique au moins partiel ?
Traçabilité avec les exigences ?
Test qui couvre toutes les exigences
bugtracker ?
Revue de code ?
Revue du code des testes ?
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
De toute façon, il faut définir soi-même le delta. J'aimerais tellement voir un langage de programmation qui gère des réel avec range et prévision. Tout un tas de transformation resterait valide (de mémoire, c'est encore un anneau ou un corps). Une fois simplifié, tout est transformé en code flottant.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 4.
Utiliser "==" avec un float ?! Ouch. C'est à éviter.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
"total à diviser en pourcentage (ça fait 1/quelque chose)…)"
C'est vrai, mais si c'est pour un affichage, tu te fou d'une erreur inférieur à 10-3. La division par zéro, c'est encore autre chose. L'erreur existe, avec des maths pure, les entiers, ce n'est pas spécifiques au flottant.
Je me rappelle des discussions de codeurs audio qui vantaient les entiers 64 bits, avec lequel ils faisaient du virgule fixe, avec 16 bit sous la virgule et donc tout un tas de contraintes sur les opérations.(j'ai codé de la trigonométrie en virgule fixe sur µP, c'était pas drôle) Tout cela parce que les float 32 bits, avec 24 bits de mantisse ont forcément des erreurs inclus. Aujourd'hui, vu la demande de puissance, des algos audio peuvent entièrement être codé en double, avec un code beaucoup plus simple.
"La première sécurité est la liberté"
[^] # Re: Mouarf
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Linus is evil…. Évalué à 10.
Il est juste énorme ce poste :)
That's the spirit.
Greg has taught you well. You have controlled your fear. Now, release
your anger. Only your hatred can destroy me.
Come to the dark side, Sarah. We have cookies.
Linus_
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
"(note que je n'ai rien contre le fait d'utiliser les float en science, où il faudra incorporer leur imprécision dans la détermination de l'imprécision du résultat)."
Demande à Alenvers, de mémoire, c'est son boulot, et évidement qu'il en tient compte.
"qu'un centime d'erreur dans un compte de plusieurs centaines de milliers de franc ce n'est rien. Mais mon tympant se souvient encore du mécontentement d'une cliente, qui a passé avec moi des heures au téléphone pour un centime d'erreur, simplement parce que les bons comptes font les bons services publics. :D"
254 (un double), c'est 1016, ce n'est pas une erreur sur 100 000 ! De plus, les erreurs de centimes (toujours dans le même sens) pour faire croire à une erreur informatique, les grosses boites appellent cela du "pricing". On a un prix annoncé de 30€ ttc, puis il donne le prix HT, puis calcul des taxes, et le prix à payé devient 30.01€ et non plus le prix ttc de la pub.
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 3.
"Le problème que tu n'as pas l'air de comprendre (ou qui te semble trop évident), c'est qu'il faut faire des arondi après chaque opération"
http://linuxfr.org/news/de-tout-de-rien-des-bookmarks-du-bla-bla-29#comment-1471335
C'est pourtant 2 commentaires au dessus. Les arrondis en question sont très bien définit, et garantisse une sorte d'annulation de l'erreur. Les vrais problèmes se posent lors d'addition/soustraction de nombre de taille très différente.
Ce que tu ne comprends pas, et que pourtant quelqu'un à très bien résumé avec une citation de Linus, est que la plus part du temps, on s'en fout que 1/3*3 != 1.0. En général on veut 1/3*3 - 1.0 < delta, avec delta = 10-6 ou 10-10. Cela dépend des usages. Toutes les maths sont faite ainsi sur ordinateur, regardes comment est codé la libm. Regardes l'astuce de la multiplication par une constante pour Doom pour éviter une division, c'est toujours le même principe : la précision est-elle suffisante ou pas.
L'imprécision est même inclus dans les données d'entrée : il n'existe aucun "capteur absolue", il y a toujours une erreur estimable. Idem pour les effecteurs qui n'ont jamais de précision infini. Même les algorithmes de calcul sont souvent des approximations de la réalité (en simulation par exemple). Quel intérêt de faire des résultats avec 15 chiffres, quand l'algo ne peut en sortir que 6 ?
Dans le cas de calcul monétaire, on veut juste que les résultats de compte finaux soit juste à quelques fractions de centime pret, mais c'est vrai qu'il est plus simple d'utiliser des grand entiers pour y arriver.
"La première sécurité est la liberté"
[^] # Re: moef
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Et moi qui croyais que le client lourd serait gagnant.... Évalué à 2.
intégrer un truc comme camlistore, c'est trop difficile ? pas assez mature ?
"La première sécurité est la liberté"
[^] # Re: quelques points
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche De tout, de rien, des bookmarks, du bla bla #29. Évalué à 2.
Oui mais dans la réalité, ce n'est pas le cas.
"La première sécurité est la liberté"