Ben du coup sa présentation est en contradiction avec ce qui est présenté dans ce journal.
Ici, quand on parle de concurrence, on parle de ressources qu'il faut se partager (la gamelle), et pour ça organiser les différents "consommateurs" (les chats) pour que ça se passe au mieux.
Dans sa définition, la présence de ressources à partager est totalement absente. C'est juste "programmer une composition de processus qui s'exécutent indépendamment les uns des autres" :
Concurrency: Programming as the composition of independently executing processes.
Il insiste sur cette indépendance en plus, en faisant une des différences notables avec le parallélisme.
Je sais pas qui a tort, qui a raison, mais clairement c'est pas clair. On a une gamelle ou pas ? Ils bouffent comment les chats ?
Le volet latéral seul n'est pas utilisable, puisqu'il n'offre accès qu'à quelques fonctionnalités. J'attends qu'il évolue pour proposer l'ensemble des fonctions accessibles via les barres d'outils, pour les remplacer. Il y avait une version d'OpenOffice, éditée par IBM, qui faisait ça il y a quelques années ; c'était magique.
Sinon on peut aussi se faire des barres d'icônes personnalisées si on veut s'éviter l'horreur d'aller dans les menus. Bref, faut apprendre à s'en servir.
On peut faire la même chose dans n'importe quelle application bureautique, mais on constate vite que ce qui compte auprès des utilisateurs, c'est la configuration par défaut. Y'en a pas beaucoup qui touchent à ça.
Sinon le jeu Colibre, a été fait par des djeunz justement, et il a une disquette comme symbole d'enregistrement. Il est très frais je trouve (et joliment coloré, ce qui va à l'encontre des tendances mortuaires actuelles).
Je te rejoins sur "les tendances mortuaires actuelles".
Par contre, bien sûr qu'il y a plein de personnes et même des jeunes qui utilisent encore cette icône pour des nouveaux logiciels. Mon propos, c'est de dire que ça n'a plus de sens, et qu'il faut penser à passer à autre chose. Là, les gens qui ont 15 ans ont vu l'ancien PC de leur père avec le lecteur, ou ont lu un magazine, etc. Mais bon, tu dirais quoi si l'icône présentait une carte perforée ?
Y'avait une réponse intéressante, qui signalait qu'à terme, on ne devrait même plus avoir besoin de sauvegarder ; l'opération étant automatique, et la seule chose à faire étant de donner un nom au document.
Le ruban est un non-sens pour l’occupation de l’espace, ou alors les écrans 16/9 sont un non-sens pour des machines destinées à une activité bureautique / développement. Les deux sont envisageables.
Il faut quand même reconnaître que l’interface de LibreOffice pose quelques soucis. Trop de fonctionnalités imposent d’explorer les menus.
J’aime beaucoup leur idée de travailller en parallèle sur plusieurs solutions, et j’aime particulièrement le volet latéral même si il n’est pas encore vraiment utilisable.
De même, je suis content qu’ils n’aient pas cédé à la mode du flat design (contrairement à Gimp hélas), mais qu’ils travaillent quand même à revoir leurs icônes qui n’ont plus de sens pour les djeun’s. Sérieux, une disquette pour « enregistrer » ? Ceux qui ont moins de 20 ans n’en ont jamais utilisé de leur vie.
Bref en terme de design il faut toujours se remettre en cause, s’adapter au monde mais pas n’importe comment.
Dans le développement du noyau, le rôle de l'intégrateur (ou mainteneur officiel) est clair : il reçoit les patchs, il les relit, les valide (ou non) et alors seulement ça rentre dans son repo git. C'est lui que git affiche, et si l'intégrateur a bien fait son travail, il montre l'auteur original dans le log du commit.
C'est plutôt logique : le "coupable" en cas de commit foireux est d'abord l'intégrateur qui a accepté le code, qui se retourne ensuite vers l'auteur original si besoin.
Perso, je vois ça comme une limite de la plupart des gestionnaires de configuration, mais ce n'est pas mon sujet du jour.
Maintenant, regardons comment git est (parfois) utilisé dans les grosses entreprises. Vous avez des équipes, chacune travaille sur un projet, composées de plusieurs développeurs, et en général un intégrateur. Les développeurs travaillent sur leur propre branche, et quand ils sont contents, ils envoient le tout à l'intégrateur, qui merge dans la branche principale. En général, c'est moins rigoureux que pour le noyau, et le log du commit fait référence uniquement à la fiche Jira/Bugzilla/… Et vous n'avez que la version finale du code. L'intégrateur est juste là pour faire le taf d'intégration, il ne comprend pas grand chose au code, et par ailleurs il s'en fout.
Avec un peu de malchance, la branche qui avait servi au développement a été supprimée pour gratter de la place (ou était uniquement sur le poste local du développeur, un presta qui a depuis fini sa mission ; le poste a donc été reformaté).
Du coup, vous avez juste :
- le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
- votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
- perdu le détail des itérations du code
Et là, vous avez un doute. Ce qui semble être un bug à la lecture du code (mal commenté) est peut-être volontaire. Le dev a peut-être été obligé d'écrire ça pour contourner autre chose. Après tout, ce damné soft est un cauchemart, le résultat de plusieurs années de retouches successives que personne ne maîtrise plus depuis bien longtemps.
Bref…
En gros, la question c'est :
- est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
- ou est-il préférable de n'avoir que les commits "finaux", quitte à perdre le ou les auteurs intermédiaires et les versions intermédiaires en cas de stratégie de stockage merdique/très contrainte
- ou avez-vous d'autres approches ?
Je l'ignorais, mais je ne sais pas encore si ça change grand chose. Entre "ça existe" et "c'est utilisé et suffisamment répandu pour que je puisse m'en servir", il y a un pas.
Je vais creuser, merci pour la piste. Ca pourrait permettre de sortir des erreurs plus propres.
Il ne faut pas perdre de vue que, en l'état, le toolkit n'est prévu que pour réaliser du prototypage, donc, à priori, l'application finale n'utilisera pas ce toolkit, rendant, il me semble, ce genre de questionnement superflu.
Un bon prototype c'est - entre autres - un prototype qu'on peut reprendre en grande partie pour construire l'application cible.
Du coup, dans ton modèle, si le proto rend les utilisateurs heureux et qu'on veut aller plus loin, qu'est-ce qui est réutilisable ? Ou, est-ce que de toute façon tu penses faire évoluer ton framework pour fournir à la fois une version "développement/lab/proto", et une version "prod" ?
Autre question. Sur le fond, j'aime bien le principe de framework tout intégré, mais à quel point ton framework est plus intégré que l'existant ? Côté Front, comment je gère la zolie interface graphique ? Côté Back, comment je me connecte à des ressources de type bus de message et base de données ?
D'accord pour dire que "très chiant" c'est exagéré.
Cela dit, XML reste pénible à utiliser/taper/lire, et perso, partout où j'ai le choix pour de la configuration, c'est JSON ou YAML/INI, en fonction de "contexte web ou pas web, complexe/simple".
YAML a l'avantage d'être également utilisé par d'autres outils type Ansible qui ont potentiellement la même base utilisateur. XML reste rare pour tout ce qui est setup du système de base.
Je garde XML pour de l'échange de données inter-systèmes et quand une validation formelle en entrée ou en sortie est nécessaire.
Ça fait des décennies que l'on développe des application avec une interface native,
Comme pour la prose, des fois on fait du MVC sans le savoir. Il y a plein de bibliothèques de création d'interfaces "natives" qui font du MVC. Mais si c'est pas écrit dessus, tu peux passer à côté de l'info.
Plus généralement, pour gérer des listes de très grandes tailes, ça reste la solution la plus simple. Pour réutiliser un max de code, ça reste la solution la plus simple.
Sur un système financier, j'ai créé une boucle infernale en livrant un bugfix, qui est monté en production. Il a fallu bosser 3 jours et 3 nuits avec les ops pour corriger toutes les données et éviter tout impact pour les clients.
Sur un autre système financier, j'ai voulu livrer en environnement dev une mise à jour du paramétrage de contrôle de position titres que j'étais en train de modifier. Je l'ai livré en production. J'ai mis 15 minutes à m'en rendre compte ; le contrôle de position n'a pas été très efficace ce jour-là, puisqu'il a fallu réinitialiser tout et attendre le jour suivant pour retrouver des chiffres corrects.
Tout ça, c'était y'a 15 ans. Maintenant on peut plus faire des livraisons en production à la sauvage, et c'est pas plus mal…
Pour la référence cachée je pense à un morceau de Megadeth. « Captive honour » si ma mémoire est bonne. Mais il est possible qu’elle-même fasse référence a quelques.
En effet, ça ferait un OVNI difficile à diffuser. Je vais réfléchir à la question cette nuit, puis ma procrastination naturelle fera le reste pour oublier tout ça.
J'avoue que c'est pas mal cool, et avec une syntaxe moins barbare.
Le truc chiant avec les devises, c'est qu'elles n'ont pas toutes 2 décimales. Du coup, est-ce que dans ce code la valeur du delta peut être une variable ? Je crains que non.
J'ai l'impression que ton commentaire porte uniquement sur la deuxième partie de la citation ; corrige-moi si je me trompe.
Cela étant dit : note bien que de mon côté je ne proposerai jamais de modifier un langage avec un changement d'une telle ampleur : je pense plutôt au choix fait à la création du langage. Pourquoi tous les nouveaux langages fonctionnent avec, à chaque fois, une interprétation des litéraux à virgules comme étant des floats ou des doubles ?
Pourquoi aucun langage "orienté business" n'est apparu depuis le début du déclin du COBOL ? Et pourquoi on se contente de librairies/paquetages pour supporter les décimaux sur des langages dits généralistes ?
Pourquoi même PHP fonctionne ainsi ? Il y a plus de gens qui font du calcul "scientifique" en PHP que de personnes qui font des calculs "comptables" ? Je ne pense pas - ou alors je vis dans un monde parallèle.
Tes exemples sont intéressants, mais je ne vois pas où tu veux en venir.
En général, si tu appliques une remise, dans une application de gestion, soit :
- tu stockes le montant initial, le taux, et tu recalcules à chaque fois
- tu stockes le montant initial et le montant de la réduction
- tu stockes les 3 informations
Tu ne cherches pas la réversibilité de l'opération ; tu dois juste garder le détail de ce qui a mené au résultat. Pour que ta piste d'audit soit recevable juridiquement et exploitable, entre autres.
Si tu dois couper 100 € en 3, tu divises en 3, et tu fais 100 - (les 3 montants), et soit le reliquat (0,01) va dans un compte spécial, soit il est réaffecté à un des 3 montants suivant une règle pré-déterminée.
Sans cela, je me retrouve avec 3 lignes à 33,33, donc 99.99 et un total à 100, ce qui pose un problème comptable, fait échouer la réconciliation, gueuler le client, pleurer le comptable.
Quand tu fais ton arrondi sur les résultats finaux, tu as régulièrement un problème à l'affichage, avec une incohérence entre le détail et le total. Quelque chose que le client ne comprendra pas ; et quand tu as des milliers de clients, tu ne veux pas avoir à expliquer cette différence.
Mettre l'exactitude mathématique comme but ultime, ce n'est pas toujours ce qui est attendu du programme informatique.
Pour ce type de fonctionnalités, il me semble évident que le modèle objet prend tout son sens.
(…)
La tâche est ardue, mais avec assez d'argent à la clé, quelqu'un le fera sûrement.
Les librairies existent, elles sont là, mais non, ça ne suffit pas. Il y a encore plein de monde qui privilégie les floats, doubles et autres. Notamment parce qu'un litéral représentant un nombre décimal, c'est directement interprété comme un float ou un double.
Je veux un langage qui permette d'exprimer un litéral décimal. Et que ce soit la forme par défaut. Qu'il faille rajouter un "f" ou un "d" pour dire "ah non, là c'est un float/un double".
Le pire (enfin, en Java), c'est les gens qui écrivent ça :
BigDecimalbd=newBigDecimal(5.5);
Bref, qui initient un BigDecimal avec une valeur double ou float, quand le mal est déjà fait. Et alors, on fait quoi ? Ben on passe par une chaîne de caractère, pour dormir sur ses deux oreilles…
BigDecimalbd=newBigDecimal("5.5");
Le truc super économique… Surtout que si on utilise pas une chaîne, il faut préciser séparément le nombre de décimales qui nous intéresse. Si au lieu d'un taux de TVA on manipule un montant, avec une chaîne je précise directement le nombre de chiffres de précision. Avec un double, sachant qu'en plus BigDecimal est immutable, je me tape un :
J'avoue que la référence à l'article était juste un prétexte pour placer ma petite fiction à deux sous.
Tiens, un petit commentaire à propos des "mathématiques de CE2". En CE2, point de nombre à virgule. Et même en CM1, on découvre surtout les fractions ; les virgules n'apparaissent que plus tard. Je me base sur la scolarité de mes enfants (donc les programmes actuels) - je ne me souviens hélas plus du programme de mon enfance.
j'espère que personne n'a traité quelqu'un d'autre d'idiot
D'un côté comme de l'autre, il y a eu des mots un peu durs à mon avis. Mais bon, on est sur Internet… Ce qui me désole, c'est de tout ramener à des notions de mathématiques, en faisant abstraction du besoin de millions de codeurs.
Et puisque je prends un ton sérieux, je peux relancer de 2 et le fer à repasser sur le croissant à la rue du genou gauche.
Dans le monde de la finance, de l’assurance, de la gestion de stock, de la gestion commerciale, des ressources humaines/paye, de la comptabilité (société ou personnelle), la quasi-totalité des calculs sont faits en utilisant le type décimal.
Je serai bien en peine de dire ce que ça représente sur l'informatique mondiale (comparé à toute l'informatique système, mathématique, recherche, graphique, jeux, …), mais je ne pense pas que ce soit négligeable, et je ne suis pas sûr que ce soit minoritaire.
Dans les années soixante, on avait un langage qui était conçu pour tout ça : le COBOL. Depuis, plus rien. Et on se retrouve à travailler avec des langages où il faut passer son temps à instancier une classe dès qu'on veut faire un calcul de base pour contrôler l'arrondi pour soit être cohérent avec les règles légales/réglementaires, soit éviter les centimes perdus.
A quand un nouveau langage spécialisé pour ces usages ? Où une expression litérale genre "123.50" serait interprété comme un type décimal, et pas un float ? Même l'autoboxing de Java, implémenté longtemps après que ce langage soit sorti de la niche de l'embarqué pour lequel il avait été conçu, ne supporte pas le BigDecimal qui reste cloîtré dans son package.
Alors je pousse ici le cri de désespoir partagé par tous les développeurs de la finance ou de la compta : "je veux un langage qui fait ce dont j'ai besoin !". Je m'en fous des intervalles ; je manipule des sous. Un centime, c'est un centime. Je veux pas qu'il prenne son indépendance même si "il y a une bonne raison mathématique" derrière. Je veux que le langage (le compilateur ou l'interpréteur) me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.
J'en ai marre de corriger toujours les mêmes bugs après toutes ces années, du code qui génère une facture dont le total n'est pas égal à la somme des lignes qui la compose, et provoque la consternation de nos clients, et crée des problèmes de réconciliation qui font perdre du temps, et créent parfois des paniques (rigolez, mais quand deux lignes de plusieurs centaines de millions d'euros ne correspondent pas exactement, et qu'en plus il n'y a pas de seuil de tolérance, y'a de la sueur sur les claviers avant de comprendre d'où ça vient).
Alors, je lis plein de gens dire que ce serait super coûteux de tout faire en décimal ((au sens type Decimal python). Ben, c'est ce qu'on fait dans la plupart des applications financières et/ou comptables. Et curieusement, ça tient la route. Le type BigDecimal (et son pendant NUMERIC en SQL) sont quand même "pas mal" utilisés si on m'autorise cet euphémisme. Et l'exemple du COBOL est également rafraîchissant dans cet esprit.
Je lis que ce serait une connerie de passer par défaut l'interprétation des litéraux avec une partie décimale comme des décimaux. Pour les langages de bas niveau (C, C++, Rust, Go), je suis 100% d'accord. Pour les langages orientés débutant ou script, c'est moins évident. Pour le python, c'est encore plus difficile : il est aussi bien utilisé par des débutants pour son côté "je tape et je vois tout de suite le résultat" que pour des applications scientifiques avancées.
Mais au final, je pencherais quand même pour un statu quo ; et si c'est vraiment super perturbant pour les débutants de se retrouver avec un résultat qui parfois surprend, il suffit peut-être de simplement revoir les tutoriels pour soit aborder ces notions plus tôt, soit commencer avec les types décimaux fixes.
[^] # Re: From the past
Posté par Dring . En réponse au journal Microsoft serait en train de développer un navigateur web basé sur Chromium. Évalué à 5.
Tu as une source à ce propos ? Et quelle est leur politique officielle aujourd’hui ?
[^] # Re: Une explication à mon avis plus claire...
Posté par Dring . En réponse au journal Exécution concurrente vs parallèle. Évalué à 2.
Ben du coup sa présentation est en contradiction avec ce qui est présenté dans ce journal.
Ici, quand on parle de concurrence, on parle de ressources qu'il faut se partager (la gamelle), et pour ça organiser les différents "consommateurs" (les chats) pour que ça se passe au mieux.
Dans sa définition, la présence de ressources à partager est totalement absente. C'est juste "programmer une composition de processus qui s'exécutent indépendamment les uns des autres" :
Il insiste sur cette indépendance en plus, en faisant une des différences notables avec le parallélisme.
Je sais pas qui a tort, qui a raison, mais clairement c'est pas clair. On a une gamelle ou pas ? Ils bouffent comment les chats ?
[^] # Re: et si plusieurs return avec différents types
Posté par Dring . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 5.
Plutôt d’accord avec cette approche sauf que le gars qui utilise null pour signifier froid, je propose immédiatement le châtiment à mort par l’empal.
Ce que j’apprecie surtout c’est que ça pose le bon niveau d’abstraction.
[^] # Re: Définition implicites ?
Posté par Dring . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 9. Dernière modification le 22 novembre 2018 à 08:17.
Un superflux, c’est un flux avec une cape et le slip par dessus son pantalon ?
(Pour les histoires de contrat qu’il faut « explicater », j’imagine que c’est le correcteur automatique qui a rajouté sa touche personnelle ?)
[^] # Re: Les priorité
Posté par Dring . En réponse au journal Libre mais.... moche ?. Évalué à 4.
Le volet latéral seul n'est pas utilisable, puisqu'il n'offre accès qu'à quelques fonctionnalités. J'attends qu'il évolue pour proposer l'ensemble des fonctions accessibles via les barres d'outils, pour les remplacer. Il y avait une version d'OpenOffice, éditée par IBM, qui faisait ça il y a quelques années ; c'était magique.
On peut faire la même chose dans n'importe quelle application bureautique, mais on constate vite que ce qui compte auprès des utilisateurs, c'est la configuration par défaut. Y'en a pas beaucoup qui touchent à ça.
Je te rejoins sur "les tendances mortuaires actuelles".
Par contre, bien sûr qu'il y a plein de personnes et même des jeunes qui utilisent encore cette icône pour des nouveaux logiciels. Mon propos, c'est de dire que ça n'a plus de sens, et qu'il faut penser à passer à autre chose. Là, les gens qui ont 15 ans ont vu l'ancien PC de leur père avec le lecteur, ou ont lu un magazine, etc. Mais bon, tu dirais quoi si l'icône présentait une carte perforée ?
D'ailleurs, il y a plein de personnes qui se posent aussi la question, depuis déjà longtemps : tu peux trouver ce thread par exemple (https://graphicdesign.stackexchange.com/questions/323/new-generation-of-save-icon-that-is-not-a-disk) qui a 7 ans déjà !
Y'avait une réponse intéressante, qui signalait qu'à terme, on ne devrait même plus avoir besoin de sauvegarder ; l'opération étant automatique, et la seule chose à faire étant de donner un nom au document.
[^] # Re: Les priorité
Posté par Dring . En réponse au journal Libre mais.... moche ?. Évalué à 9.
Le ruban est un non-sens pour l’occupation de l’espace, ou alors les écrans 16/9 sont un non-sens pour des machines destinées à une activité bureautique / développement. Les deux sont envisageables.
Il faut quand même reconnaître que l’interface de LibreOffice pose quelques soucis. Trop de fonctionnalités imposent d’explorer les menus.
J’aime beaucoup leur idée de travailller en parallèle sur plusieurs solutions, et j’aime particulièrement le volet latéral même si il n’est pas encore vraiment utilisable.
De même, je suis content qu’ils n’aient pas cédé à la mode du flat design (contrairement à Gimp hélas), mais qu’ils travaillent quand même à revoir leurs icônes qui n’ont plus de sens pour les djeun’s. Sérieux, une disquette pour « enregistrer » ? Ceux qui ont moins de 20 ans n’en ont jamais utilisé de leur vie.
Bref en terme de design il faut toujours se remettre en cause, s’adapter au monde mais pas n’importe comment.
# Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par Dring . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 5.
Dans le développement du noyau, le rôle de l'intégrateur (ou mainteneur officiel) est clair : il reçoit les patchs, il les relit, les valide (ou non) et alors seulement ça rentre dans son repo git. C'est lui que git affiche, et si l'intégrateur a bien fait son travail, il montre l'auteur original dans le log du commit.
C'est plutôt logique : le "coupable" en cas de commit foireux est d'abord l'intégrateur qui a accepté le code, qui se retourne ensuite vers l'auteur original si besoin.
Perso, je vois ça comme une limite de la plupart des gestionnaires de configuration, mais ce n'est pas mon sujet du jour.
Maintenant, regardons comment git est (parfois) utilisé dans les grosses entreprises. Vous avez des équipes, chacune travaille sur un projet, composées de plusieurs développeurs, et en général un intégrateur. Les développeurs travaillent sur leur propre branche, et quand ils sont contents, ils envoient le tout à l'intégrateur, qui merge dans la branche principale. En général, c'est moins rigoureux que pour le noyau, et le log du commit fait référence uniquement à la fiche Jira/Bugzilla/… Et vous n'avez que la version finale du code. L'intégrateur est juste là pour faire le taf d'intégration, il ne comprend pas grand chose au code, et par ailleurs il s'en fout.
Avec un peu de malchance, la branche qui avait servi au développement a été supprimée pour gratter de la place (ou était uniquement sur le poste local du développeur, un presta qui a depuis fini sa mission ; le poste a donc été reformaté).
Du coup, vous avez juste :
- le commit qui dit "merge de la fiche XXX-1234 dans le tronc principal"
- votre bug tracker qui indique le nom de la personne assignée au bug, mais sans certitude que ce soit bien elle qui ait produit le code
- perdu le détail des itérations du code
Et là, vous avez un doute. Ce qui semble être un bug à la lecture du code (mal commenté) est peut-être volontaire. Le dev a peut-être été obligé d'écrire ça pour contourner autre chose. Après tout, ce damné soft est un cauchemart, le résultat de plusieurs années de retouches successives que personne ne maîtrise plus depuis bien longtemps.
Bref…
En gros, la question c'est :
- est-il préférable d'avoir tout le détail du code dans un arbre unique, avec tous les micro-commits, mais au moins on garde tout, pour toujours, et on peut tout retrouver
- ou est-il préférable de n'avoir que les commits "finaux", quitte à perdre le ou les auteurs intermédiaires et les versions intermédiaires en cas de stratégie de stockage merdique/très contrainte
- ou avez-vous d'autres approches ?
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Dring . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 2.
Je l'ignorais, mais je ne sais pas encore si ça change grand chose. Entre "ça existe" et "c'est utilisé et suffisamment répandu pour que je puisse m'en servir", il y a un pas.
Je vais creuser, merci pour la piste. Ca pourrait permettre de sortir des erreurs plus propres.
[^] # Re: Montre ton code
Posté par Dring . En réponse au journal Prototypage d'applications web. Évalué à 5.
Un bon prototype c'est - entre autres - un prototype qu'on peut reprendre en grande partie pour construire l'application cible.
Du coup, dans ton modèle, si le proto rend les utilisateurs heureux et qu'on veut aller plus loin, qu'est-ce qui est réutilisable ? Ou, est-ce que de toute façon tu penses faire évoluer ton framework pour fournir à la fois une version "développement/lab/proto", et une version "prod" ?
Autre question. Sur le fond, j'aime bien le principe de framework tout intégré, mais à quel point ton framework est plus intégré que l'existant ? Côté Front, comment je gère la zolie interface graphique ? Côté Back, comment je me connecte à des ressources de type bus de message et base de données ?
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par Dring . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 9.
D'accord pour dire que "très chiant" c'est exagéré.
Cela dit, XML reste pénible à utiliser/taper/lire, et perso, partout où j'ai le choix pour de la configuration, c'est JSON ou YAML/INI, en fonction de "contexte web ou pas web, complexe/simple".
YAML a l'avantage d'être également utilisé par d'autres outils type Ansible qui ont potentiellement la même base utilisateur. XML reste rare pour tout ce qui est setup du système de base.
Je garde XML pour de l'échange de données inter-systèmes et quand une validation formelle en entrée ou en sortie est nécessaire.
[^] # Re: Windows XP
Posté par Dring . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 7.
Pas vraiment, Antédiluvien ça veut juste dire que ça date d’avant le déluge.
[^] # Re: ... et pas qu'un ...
Posté par Dring . En réponse au journal Du développement full-stack en Java. Évalué à 5.
Comme pour la prose, des fois on fait du MVC sans le savoir. Il y a plein de bibliothèques de création d'interfaces "natives" qui font du MVC. Mais si c'est pas écrit dessus, tu peux passer à côté de l'info.
Plus généralement, pour gérer des listes de très grandes tailes, ça reste la solution la plus simple. Pour réutiliser un max de code, ça reste la solution la plus simple.
[^] # Re: Que le temps passe vite
Posté par Dring . En réponse à la dépêche 20 ans de LinuxFr.org. Évalué à 6.
Merde, j'ai plussé. Ca ne peut vouloir dire qu'une seule chose… :'-(
# Mais la vraie questions est...
Posté par Dring . En réponse à la dépêche 20 ans de LinuxFr.org. Évalué à 10.
…à quand la réécriture en J2EE ? Depuis le temps, je commence a vraiment m’inquieter.
# Les deux trucs dont j'ai le plus honte...
Posté par Dring . En réponse au sondage Oui j’avoue, ma plus grosse boulette c’est d’avoir :. Évalué à 3.
Sur un système financier, j'ai créé une boucle infernale en livrant un bugfix, qui est monté en production. Il a fallu bosser 3 jours et 3 nuits avec les ops pour corriger toutes les données et éviter tout impact pour les clients.
Sur un autre système financier, j'ai voulu livrer en environnement dev une mise à jour du paramétrage de contrôle de position titres que j'étais en train de modifier. Je l'ai livré en production. J'ai mis 15 minutes à m'en rendre compte ; le contrôle de position n'a pas été très efficace ce jour-là, puisqu'il a fallu réinitialiser tout et attendre le jour suivant pour retrouver des chiffres corrects.
Tout ça, c'était y'a 15 ans. Maintenant on peut plus faire des livraisons en production à la sauvage, et c'est pas plus mal…
[^] # Re: Pour ceux qui n’aiment pas le pot au feu
Posté par Dring . En réponse au journal Recette du pot au feu. Évalué à 3.
Pour la référence cachée je pense à un morceau de Megadeth. « Captive honour » si ma mémoire est bonne. Mais il est possible qu’elle-même fasse référence a quelques.
Verdict ?
# Coup de gueule !
Posté par Dring . En réponse au journal BranchScope. Évalué à 4.
Ce journal aurait sa place dans les liens !
…
Bon en fait il est un peu trop long pour être complètement qualifié de bookmark, mais quand même, l’occasion était trop belle.
[^] # Re: c'est bien joli, mais…
Posté par Dring . En réponse au journal La recherche en langages de programmation au quotidien. Évalué à 4.
Cela aurait pu être pire, et être ass-bean. Déjà que j'aime pas les haricots…
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Dring . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 4.
En effet, ça ferait un OVNI difficile à diffuser. Je vais réfléchir à la question cette nuit, puis ma procrastination naturelle fera le reste pour oublier tout ça.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Dring . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 2.
J'avoue que c'est pas mal cool, et avec une syntaxe moins barbare.
Le truc chiant avec les devises, c'est qu'elles n'ont pas toutes 2 décimales. Du coup, est-ce que dans ce code la valeur du delta peut être une variable ? Je crains que non.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Dring . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 2.
J'ai l'impression que ton commentaire porte uniquement sur la deuxième partie de la citation ; corrige-moi si je me trompe.
Cela étant dit : note bien que de mon côté je ne proposerai jamais de modifier un langage avec un changement d'une telle ampleur : je pense plutôt au choix fait à la création du langage. Pourquoi tous les nouveaux langages fonctionnent avec, à chaque fois, une interprétation des litéraux à virgules comme étant des floats ou des doubles ?
Pourquoi aucun langage "orienté business" n'est apparu depuis le début du déclin du COBOL ? Et pourquoi on se contente de librairies/paquetages pour supporter les décimaux sur des langages dits généralistes ?
Pourquoi même PHP fonctionne ainsi ? Il y a plus de gens qui font du calcul "scientifique" en PHP que de personnes qui font des calculs "comptables" ? Je ne pense pas - ou alors je vis dans un monde parallèle.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Dring . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 4.
Tes exemples sont intéressants, mais je ne vois pas où tu veux en venir.
En général, si tu appliques une remise, dans une application de gestion, soit :
- tu stockes le montant initial, le taux, et tu recalcules à chaque fois
- tu stockes le montant initial et le montant de la réduction
- tu stockes les 3 informations
Tu ne cherches pas la réversibilité de l'opération ; tu dois juste garder le détail de ce qui a mené au résultat. Pour que ta piste d'audit soit recevable juridiquement et exploitable, entre autres.
Si tu dois couper 100 € en 3, tu divises en 3, et tu fais 100 - (les 3 montants), et soit le reliquat (0,01) va dans un compte spécial, soit il est réaffecté à un des 3 montants suivant une règle pré-déterminée.
Sans cela, je me retrouve avec 3 lignes à 33,33, donc 99.99 et un total à 100, ce qui pose un problème comptable, fait échouer la réconciliation, gueuler le client, pleurer le comptable.
Quand tu fais ton arrondi sur les résultats finaux, tu as régulièrement un problème à l'affichage, avec une incohérence entre le détail et le total. Quelque chose que le client ne comprendra pas ; et quand tu as des milliers de clients, tu ne veux pas avoir à expliquer cette différence.
Mettre l'exactitude mathématique comme but ultime, ce n'est pas toujours ce qui est attendu du programme informatique.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Dring . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 1.
Les librairies existent, elles sont là, mais non, ça ne suffit pas. Il y a encore plein de monde qui privilégie les floats, doubles et autres. Notamment parce qu'un litéral représentant un nombre décimal, c'est directement interprété comme un float ou un double.
Je veux un langage qui permette d'exprimer un litéral décimal. Et que ce soit la forme par défaut. Qu'il faille rajouter un "f" ou un "d" pour dire "ah non, là c'est un float/un double".
Le pire (enfin, en Java), c'est les gens qui écrivent ça :
Bref, qui initient un BigDecimal avec une valeur double ou float, quand le mal est déjà fait. Et alors, on fait quoi ? Ben on passe par une chaîne de caractère, pour dormir sur ses deux oreilles…
Le truc super économique… Surtout que si on utilise pas une chaîne, il faut préciser séparément le nombre de décimales qui nous intéresse. Si au lieu d'un taux de TVA on manipule un montant, avec une chaîne je précise directement le nombre de chiffres de précision. Avec un double, sachant qu'en plus BigDecimal est immutable, je me tape un :
Quand je vous dis que les décimaux sont le parent pauvre, et que c'est au détriment de nou'z'aut', les développeurs financiers.
[^] # Re: Il faut bien lire ce qu'on lit!
Posté par Dring . En réponse au journal Le retour de la vengeance de la virgule flottante. Évalué à 5.
J'avoue que la référence à l'article était juste un prétexte pour placer ma petite fiction à deux sous.
Tiens, un petit commentaire à propos des "mathématiques de CE2". En CE2, point de nombre à virgule. Et même en CM1, on découvre surtout les fractions ; les virgules n'apparaissent que plus tard. Je me base sur la scolarité de mes enfants (donc les programmes actuels) - je ne me souviens hélas plus du programme de mon enfance.
D'un côté comme de l'autre, il y a eu des mots un peu durs à mon avis. Mais bon, on est sur Internet… Ce qui me désole, c'est de tout ramener à des notions de mathématiques, en faisant abstraction du besoin de millions de codeurs.
Et puisque je prends un ton sérieux, je peux relancer de 2 et le fer à repasser sur le croissant à la rue du genou gauche.
Dans le monde de la finance, de l’assurance, de la gestion de stock, de la gestion commerciale, des ressources humaines/paye, de la comptabilité (société ou personnelle), la quasi-totalité des calculs sont faits en utilisant le type décimal.
Je serai bien en peine de dire ce que ça représente sur l'informatique mondiale (comparé à toute l'informatique système, mathématique, recherche, graphique, jeux, …), mais je ne pense pas que ce soit négligeable, et je ne suis pas sûr que ce soit minoritaire.
Dans les années soixante, on avait un langage qui était conçu pour tout ça : le COBOL. Depuis, plus rien. Et on se retrouve à travailler avec des langages où il faut passer son temps à instancier une classe dès qu'on veut faire un calcul de base pour contrôler l'arrondi pour soit être cohérent avec les règles légales/réglementaires, soit éviter les centimes perdus.
A quand un nouveau langage spécialisé pour ces usages ? Où une expression litérale genre "123.50" serait interprété comme un type décimal, et pas un float ? Même l'autoboxing de Java, implémenté longtemps après que ce langage soit sorti de la niche de l'embarqué pour lequel il avait été conçu, ne supporte pas le BigDecimal qui reste cloîtré dans son package.
Alors je pousse ici le cri de désespoir partagé par tous les développeurs de la finance ou de la compta : "je veux un langage qui fait ce dont j'ai besoin !". Je m'en fous des intervalles ; je manipule des sous. Un centime, c'est un centime. Je veux pas qu'il prenne son indépendance même si "il y a une bonne raison mathématique" derrière. Je veux que le langage (le compilateur ou l'interpréteur) me force à me poser la question dès que je risque de créer un problème d'arrondi ou de dépassement.
J'en ai marre de corriger toujours les mêmes bugs après toutes ces années, du code qui génère une facture dont le total n'est pas égal à la somme des lignes qui la compose, et provoque la consternation de nos clients, et crée des problèmes de réconciliation qui font perdre du temps, et créent parfois des paniques (rigolez, mais quand deux lignes de plusieurs centaines de millions d'euros ne correspondent pas exactement, et qu'en plus il n'y a pas de seuil de tolérance, y'a de la sueur sur les claviers avant de comprendre d'où ça vient).
# Puisque tout le monde est sûr de détenir la vérité...
Posté par Dring . En réponse au journal [Humour] vers un monde différent. Évalué à 6.
…je me lance aussi.
Alors, je lis plein de gens dire que ce serait super coûteux de tout faire en décimal ((au sens type Decimal python). Ben, c'est ce qu'on fait dans la plupart des applications financières et/ou comptables. Et curieusement, ça tient la route. Le type BigDecimal (et son pendant NUMERIC en SQL) sont quand même "pas mal" utilisés si on m'autorise cet euphémisme. Et l'exemple du COBOL est également rafraîchissant dans cet esprit.
Je lis que ce serait une connerie de passer par défaut l'interprétation des litéraux avec une partie décimale comme des décimaux. Pour les langages de bas niveau (C, C++, Rust, Go), je suis 100% d'accord. Pour les langages orientés débutant ou script, c'est moins évident. Pour le python, c'est encore plus difficile : il est aussi bien utilisé par des débutants pour son côté "je tape et je vois tout de suite le résultat" que pour des applications scientifiques avancées.
Mais au final, je pencherais quand même pour un statu quo ; et si c'est vraiment super perturbant pour les débutants de se retrouver avec un résultat qui parfois surprend, il suffit peut-être de simplement revoir les tutoriels pour soit aborder ces notions plus tôt, soit commencer avec les types décimaux fixes.