Si j'en crois les statistiques du Github, LinuxFR.org semble développé par à peu près une personne (en supposant que ce ne soit pas un artefact de la gestion des commits). C'est un état de fait courant dans le milieu open-source, hélas, quoique je pense un peu surprenant pour un site tel que celui-ci – les compétences dans les membres devraient être légion.
Conséquences : beaucoup d'entrées de suivi non traitées, et si j'en crois une réflexion plus haut, il y a plein de priorités qui ne sont même pas dans ces entrées de suivi.
D'où quelques réflexions :
Est-ce que ce manque de développeurs tiers est problématique ?
Est-ce que la force de développement aujourd'hui suffit à suivre la maintenance et les nouvelles demandes pertinentes ?
En quoi ce développement par environ une personne peut limiter les décisions que l'on pourrait prendre suite à la réflexion amorcée sur ce topic ? (si on a des bonnes idées mais personne pour les développer, ça ne servira à rien).
J'ose le demander : ne serait-il pas pertinent de passer LinuxFR.org sur une plateforme libre tierce (voire plusieurs outils : publication / forum / wiki / suivi…), en remplacement d'un code purement spécifique ? (quitte à faire des adaptations)
Je le trouve même court : je pensais à ce qu'on me demande des détails concernant l'ergonomie dans la suite, au-delà des questions vagues-mais-portant-sur-une-partie-précise de la page 1. Mais en fait non.
Le plus intéressant dans cette histoire (au-delà du fait que l'orthographe « phonétique » est aléatoire, cf par exemple l'utilisation des c et des k) est que l'auteur n'a pas pensé a changer le style. Et pourtant c'est peut-être l'une des évolutions les plus « visibles » du français depuis le début du XXème Siècle – et sans doute l'une des moins prévisibles ?
En cadeau, un extrait du Petit Chaperon Rouge, version d'origine :
Il estoit une fois une petite fille de Village, la plus jolie qu’on eut sçû voir; sa mere en estoit folle, & sa mere grand plus folle encore. Cette bonne femme luy fit faire un petit chaperon rouge, qui luy seïoit si bien, que par tout on l’appelloit le Petit chaperon rouge.
Un jour sa mere ayant cui & fait des galettes, luy dit, va voir comme se porte ta mere-grand, car on m’a dit qu’elle estoit malade, porte luy une galette & ce petit pot de beure. Le petit chaperon rouge partit aussi-tost pour aller chez sa mere-grand, qui demeuroit dans un autre Village. En passant dans un bois elle rencontra compere le Loup, qui eut bien envie de la manger, mais il n’osa, à cause de quelques Bucherons qui estoient dans la Forest. Il luy demanda où elle alloit; la pauvre enfant qui ne sçavoit pas qu’il est dangereux de s’arrester à écouter un Loup, luy dit, je vais voir ma Mere-grand, & luy porter une galette avec un petit pot de beurre, que ma Mere luy envoye. Demeure-t’elle bien loin, lui dit le Loup? Oh ouy, dit le petit chaperon rouge, c’est par de-là le moulin que vous voyez tout là-bas, là-bas, à la premiere maison du Village.
En sachant qu'à l'époque de Perrault, les verbes en -oit se prononçaient déjà comme aujourd'hui.
De plus en plus de programmeuses et programmeurs s'interessent a la théorie des types, a celle des catégories, aux systèmes de types affines (a la rust), etc.
Ce qui est horrible en fait dans la réalité, c'est la quantité de développeurs (dans le sens : des gens qui travaillent ou veulent travaille dans ce boulot) qui ne s'intéressent absolument pas à ce qu'ils font : c'est juste un boulot alimentaire comme un autre (mais qui souvent a nécessité 5 ans d'études, va comprendre).
Dans mon ancienne boite, une SSII correcte dans son genre, une des premières questions qu'on posait en entretient était : « Comment est-ce que vous vous tenez au courant des nouveautés dans le domaine » – question cruciale dans le développement web ou mobile, où tout change très vite. Eh bien un gros tiers des candidats ne se tenait pas à jour du tout, et on était contents de trouver quelqu'un qui s'intéresse un minimum au sujet. Et ce en ne recrutant que des ingénieurs.
C'est un état de fait qui me désole. Mais la triste réalité du terrain, c'est que y'a une part non négligeable de ceux qui produisent n'utilisent les nouveautés technologiques que contraints par le projet. Et ça devient un vrai problème quant ce comportement se retrouve chez des gens expérimentés censément porteurs de projet.
L'exemple de Ceylon est intéressant, parce qu'il ressemble beaucoup à Kotlin par pas mal de points, a lui aussi été conçu et poussé par un industriel (RedHat)… mais a complètement foiré.
Pourquoi ? Mystère.
Mon interprétation personnelle du peu d'expérience que j'en ai, c'est que malgré ses qualités il ne répondait pas à la problématique qu'il cherchait à résoudre :
Quand je fait du Java, j'ai l'impression de passer trop de temps à faire du code « technique » (boilerplate code, les machins qui sont là « pour que ça marche ») et pour peu de code « utile » (la logique de mon application, là où il y a l'intérêt à développer et de la valeur ajoutée).
Quand je fais du Kotlin, j'ai l'impression ne ne faire pratiquement plus que du code « utile ».
Quand je fais du Ceylon, j'ai surtout l'impression d'avoir un meilleur boilerplate code à écrire.
Je ne sais pas s'il y a des recherches qui s'intéressent à l'ergonomie du code, mais ça serait intéressant à creuser.
PS : souvent en programmation, on a : clair != concis.
Jolie interprétation complètement à côté de la plaque de mon commentaire. Du coup, pas la peine de répondre à tes interrogations, vu qu'elles ne correspondent à rien.
Je ne dis pas qu'il faut se passer de théoriciens. Bien sûr qu'ils sont indispensables !
Mon point est que les positions à base de « c'est moche théoriquement, on ne devrait pas faire comme ça » sont, elles, problématiques. L'industrie a besoin des bons langages avec les bons outils au bon moment. Ce fait décorrèle complètement les inventions sur les langages de leur application « grand public ».
Or, je vois encore trop souvent des critiques de langages qui ne se basent que sur leur intérêt théorique, sans tenir compte des problématiques pragmatiques (et politiques aussi : Go est poussé par Google) qui ont fait qu'ils sont arrivés là où ils sont.
J'appuie avec un exemple tout droit sorti de l'industrie. Dans beaucoup de secteurs, l'industrie a des préoccupations à des années-lumières des considérations développées ici. Beaucoup – trop – de code est écrit pour être jetable, et ce de façon tout à fait volontaire : la course effrénée à la nouveauté dans certains domaines (le web, les applications mobiles, qui sont deux secteurs très pourvoyeurs de codes et d'emploi informatique) fait qu'il est souvent plus rentable, en termes financiers, de sortir un produit au code crade, buggué, mais qui fait en gros le boulot, que de concevoir quoi que ce soit d'élégant. Parce que de toutes façons tout sera refait, avec un cycle de vie qui va de quelques mois à quelques années selon les parties du programme.
Les besoins d'une grosse partie de l'industrie, aujourd'hui, ce n'est pas un langage mathématiquement élégant, ou qui a un quelconque rapport avec la recherche même d'il y a 40 ans.
Ce que veut une grosse partie des « consommateurs » de langages de programmation, c'est un langage qui permet de :
Écrire du code vite.
Éviter les bugs triviaux.
Soit simple à comprendre pour qu'on puisse mettre n'importe qui dessus avec le minimum de formation possible.
Or si les langages qui plaisent aux chercheurs peuvent remplir 1 et 2, le 3 est généralement très loin d'être évident, surtout quand on parle d'introduire des paradigmes fonctionnels dans une industrie qui y touche assez peu, ce qui impliquerait une grosse quantité de formation pour le faire admettre.
Un bel exemple concret de l'effet du pragmatisme dans l'utilisation des langages de programmation, c'est le couple Kotlin/Scala, deux langages conçus en réaction aux problèmes de Java et qui ont pour cible de tourner sur la JVM, tout en étant interopérable avec Java.
Scala est intéressant conceptuellement, et a été inventé à l'École polytechnique fédérale de Lausanne. Il a son petit succès dans le monde des langages à JVM, mais n'a jamais été massivement adopté par d'énormes institutions et se traine une réputation de complexité d'approche et conceptuelle.
Kotlin a été conçu par une industrie (JetBrains) et son approche est 100 % pragmatique : « si ça aide le développeur, on prends, sinon tant pis ». Il ressemble donc beaucoup plus à un gros tas de sucre syntaxique sur Java ; mais en dépit de concepts assez inintéressants et de qualité variable, il se développe dans le monde des langages à JVM comme aucun avant lui : https://trends.google.fr/trends/explore?date=all&q=%2Fm%2F0_lcrx4,%2Fm%2F091hdj,%2Fm%2F02js86
Je ne dis pas que l'un est meilleur que l'autre. Mais déconsidérer des langages en se basant sur leur propreté mathématique ou leur rapport à la recherche, c'est faire une erreur d'appréciation monumentale qui ignore une part énorme des besoins et contraintes qui régissent l'utilisation desdits langages. Et c'est une erreur que je croise depuis des années dans la recherche en informatique ou même dans pas mal de communautés qui font des langages fonctionnels ( = censément meilleurs mathématiquement).
En fait pour moi ce que demande Renaud, ça ressemble assez rapidement à un historique de commit de code, et plus à une source. Un exemple concret : les calques d'un dessin sont souvent juste un outil de travail et n'ont pas d'intérêt en tant que « source ».
Sauf que l'ironie ne fonctionne – presque par définition – que si tu ne l'indique pas (ironie --> différence entre l'énoncé et le signifié) ; du coup ce point d'ironie m'a toujours paru un peu étrange conceptuellement.
Je lis plusieurs fois dans le journal et les commentaires qu'il y a eu des problèmes de disques morts à la reconstruction. En fait, avec les capacités et les fiabilités modernes, c'est probablement normal si on a essayé de reconstruire un RAID fait avec des disques « grand public ». Je détaille les calculs ici.
Donc : pour faire du RAID, achetez des disques « spécial RAID » avec une haute fiabilité.
En fait il n'y a pas de parenthèses ou de priorité à reconnaitre, puisque tout l'intérêt de la RPN est justement qu'il n'y a plus besoin de gérer de parenthèses ou de priorité : tous les calculs sont faits instantanément.
Mais c'est à l'utilisateur de rentrer le calcul dans le bon ordre : pour faire le calcul 1 + 2 / 3 en respectant la priorité du calcul écrit ainsi, il faut taper en RPN : 2 3 / 1 +. Mais une erreur sur ce point n'est plus une erreur de l'interpréteur, c'est une erreur d'ICC :)
J'appuie à fond. Dans toutes les entreprises que j'ai fait, la migration SVN --> Git n'a pu se faire que parce qu'il y avait des outils permettant de basculer les projets déjà existants.
C'est une question de performances je suppose : UTF-8 utilise des caractères qui n'ont pas tous la même longueur (en octets), ce qui complexifie pas mal les traitements.
J'ai l'impression que contrairement à ce que laissait entendre ton journal, tu ne l'as pas posté pour essayer de comprendre « pourquoi les types flottants natifs sont très peu utilisés pour faire des calculs financiers » mais plutôt pour tenter de convaincre tes lecteurs que selon toi, dans la majorité des cas, on pourrait très bien utiliser ces fameux flottants natifs. Et ce nonobstant toutes les explications qu'on t'a données. C'est un peu dommage.
Tu parles bien d'éviter d'ajouter « des éléphants et des souris », mais c'est un cas assez classique en finance, où il est fréquent d'avoir plusieurs ordres de grandeur entre les montants sur les comptes et les montants des transactions.
Les calculs d'intérêts, typiquement, se retrouvent très bien dans ces deux points.
Oui, ce que je veux dire c'est que dès qu'il y a des mouvements réels d'argent en jeu, on est définis à 2 décimales : typiquement si tu achètes 1 litre d'essence à 1.298 €/litre, tu vas payer 1.30 €.
Donc, "10.222" sera tronqué à "10.22", ce qui est un arrondit violent.
Si c'est un montant (monétaire) final (et pas un intermédiaire de calcul), sur une monnaie comme l'euro, la troisième décimale et toutes celles au-delà n'ont pas d'existence réelle. D'ailleurs il y a des règles officielles pour arrondir si les calculs donnent un montant à plus de 2 décimales (de mémoire : partie décimale < 0,5 --> inférieur, partie décimale >= 0,5 --> supérieur).
Du coup dans ton cas il n'y a pas réellement de « arrondit violent » : c'est le résultat du calcul qui donne bien, selon les règles de la finance, 10.22 et non 10.222.
D'une manière générale, c'est aussi un domaine où on a besoin autant que faire ce peut de valeurs exactes et pas « avec des approximations qu'on peut normaliser » sur toutes les valeurs finales. D'expérience, pour avoir bossé quelques années dans le e-commerce, utiliser des double au lieu de décimale fixe t'expose à deux types de blagues :
Tu as des erreurs de re-normalisation qui ne se compensent pas (par exemple tu produits un ticket avec HT et TVA qui ne font pas TTC, à 1 ou 2 centimes prêt).
Tu obtiens des arrondis (sur le site web par exemple) qui ne collent pas avec ceux du SI financier et qui foutent la merde dans les calculs.
Utiliser correctement les outils basés sur des décimales fixes permettent d'éviter ces écueils, même si c'est généralement lourd et chiant à faire.
Ça rejoint une conception assez américaine du contrôle scolaire des connaissances, j'ai l'impression – et inversement quelque chose qui a l'air assez spécifique à la France.
De ce que j'en ai discuté avec pas mal d'étudiants étrangers (de tous horizons) pendant mes études, les systèmes à l'américaine ont l'air connus pour utiliser beaucoup de QCM qui font beaucoup appel au « par cœur » de notions précises. Ça se retrouve dans les certifications IBM par exemple, qui consistent exactement en ça (ex : « Donnez le nom et le chemin qui sert à configurer les paramètres X de la fonctionnalité Y – un truc que personne ne touche – entre A, B, C, D et E »).
Le système scolaire français à l'inverse a tendance à miser sur la réflexion, en proposant en guise de contrôle des connaissances la possibilité de faire des rédactions sur à peu près n'importe quel sujet, du français à la biologie en passant par l'histoire et la philosophie. Ou, dans les cas qui s'y prêtent le moins, des exercices à questions ouvertes.
Disclaimer : ça fait 10 ans que j'ai fini mes études et 16 que j'ai fini le lycée, ça a pu changer depuis.
L'article est sous copyright, et même si ce n'était pas le cas, il a une mise en forme compliquée qui m'aurait pris plus de temps à refaire au propre qu'au lecteur de le relire.
# LinuxFR.org semble développé par ~1 personne, des impacts ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 6.
Si j'en crois les statistiques du Github, LinuxFR.org semble développé par à peu près une personne (en supposant que ce ne soit pas un artefact de la gestion des commits). C'est un état de fait courant dans le milieu open-source, hélas, quoique je pense un peu surprenant pour un site tel que celui-ci – les compétences dans les membres devraient être légion.
Conséquences : beaucoup d'entrées de suivi non traitées, et si j'en crois une réflexion plus haut, il y a plein de priorités qui ne sont même pas dans ces entrées de suivi.
D'où quelques réflexions :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas si long
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 2.
Je le trouve même court : je pensais à ce qu'on me demande des détails concernant l'ergonomie dans la suite, au-delà des questions vagues-mais-portant-sur-une-partie-précise de la page 1. Mais en fait non.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Améliorons l'expérience utilisateur !
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 6.
Quoique ça se discute : http://www.gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=8870544
La connaissance libre : https://zestedesavoir.com
# Le style, par contre…
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Une Demande d’Emploi en 2017. Évalué à 1.
Le plus intéressant dans cette histoire (au-delà du fait que l'orthographe « phonétique » est aléatoire, cf par exemple l'utilisation des c et des k) est que l'auteur n'a pas pensé a changer le style. Et pourtant c'est peut-être l'une des évolutions les plus « visibles » du français depuis le début du XXème Siècle – et sans doute l'une des moins prévisibles ?
En cadeau, un extrait du Petit Chaperon Rouge, version d'origine :
En sachant qu'à l'époque de Perrault, les verbes en -oit se prononçaient déjà comme aujourd'hui.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est le futur
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Une Demande d’Emploi en 2017. Évalué à 2.
Oh, ça c'est vieux et leur norme est notoirement bugguée (elle crée des tas d'ambigüités et n'est pas toujours stable).
Cela dit, ce genre d'initiative se retrouve dans le site pour handicapés de la ville de Montréal – mais sans vocation universelle.
La connaissance libre : https://zestedesavoir.com
[^] # Re: go 2.0
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
Ce qui est horrible en fait dans la réalité, c'est la quantité de développeurs (dans le sens : des gens qui travaillent ou veulent travaille dans ce boulot) qui ne s'intéressent absolument pas à ce qu'ils font : c'est juste un boulot alimentaire comme un autre (mais qui souvent a nécessité 5 ans d'études, va comprendre).
Dans mon ancienne boite, une SSII correcte dans son genre, une des premières questions qu'on posait en entretient était : « Comment est-ce que vous vous tenez au courant des nouveautés dans le domaine » – question cruciale dans le développement web ou mobile, où tout change très vite. Eh bien un gros tiers des candidats ne se tenait pas à jour du tout, et on était contents de trouver quelqu'un qui s'intéresse un minimum au sujet. Et ce en ne recrutant que des ingénieurs.
C'est un état de fait qui me désole. Mais la triste réalité du terrain, c'est que y'a une part non négligeable de ceux qui produisent n'utilisent les nouveautés technologiques que contraints par le projet. Et ça devient un vrai problème quant ce comportement se retrouve chez des gens expérimentés censément porteurs de projet.
La connaissance libre : https://zestedesavoir.com
[^] # Re: go 2.0
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 1. Dernière modification le 18 octobre 2017 à 16:46.
L'exemple de Ceylon est intéressant, parce qu'il ressemble beaucoup à Kotlin par pas mal de points, a lui aussi été conçu et poussé par un industriel (RedHat)… mais a complètement foiré.
Pourquoi ? Mystère.
Mon interprétation personnelle du peu d'expérience que j'en ai, c'est que malgré ses qualités il ne répondait pas à la problématique qu'il cherchait à résoudre :
Je ne sais pas s'il y a des recherches qui s'intéressent à l'ergonomie du code, mais ça serait intéressant à creuser.
PS : souvent en programmation, on a : clair != concis.
La connaissance libre : https://zestedesavoir.com
[^] # Re: go 2.0
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 5.
Jolie interprétation complètement à côté de la plaque de mon commentaire. Du coup, pas la peine de répondre à tes interrogations, vu qu'elles ne correspondent à rien.
Je ne dis pas qu'il faut se passer de théoriciens. Bien sûr qu'ils sont indispensables !
Mon point est que les positions à base de « c'est moche théoriquement, on ne devrait pas faire comme ça » sont, elles, problématiques. L'industrie a besoin des bons langages avec les bons outils au bon moment. Ce fait décorrèle complètement les inventions sur les langages de leur application « grand public ».
Or, je vois encore trop souvent des critiques de langages qui ne se basent que sur leur intérêt théorique, sans tenir compte des problématiques pragmatiques (et politiques aussi : Go est poussé par Google) qui ont fait qu'ils sont arrivés là où ils sont.
La connaissance libre : https://zestedesavoir.com
[^] # Re: go 2.0
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 9.
J'appuie avec un exemple tout droit sorti de l'industrie. Dans beaucoup de secteurs, l'industrie a des préoccupations à des années-lumières des considérations développées ici. Beaucoup – trop – de code est écrit pour être jetable, et ce de façon tout à fait volontaire : la course effrénée à la nouveauté dans certains domaines (le web, les applications mobiles, qui sont deux secteurs très pourvoyeurs de codes et d'emploi informatique) fait qu'il est souvent plus rentable, en termes financiers, de sortir un produit au code crade, buggué, mais qui fait en gros le boulot, que de concevoir quoi que ce soit d'élégant. Parce que de toutes façons tout sera refait, avec un cycle de vie qui va de quelques mois à quelques années selon les parties du programme.
Les besoins d'une grosse partie de l'industrie, aujourd'hui, ce n'est pas un langage mathématiquement élégant, ou qui a un quelconque rapport avec la recherche même d'il y a 40 ans.
Ce que veut une grosse partie des « consommateurs » de langages de programmation, c'est un langage qui permet de :
Or si les langages qui plaisent aux chercheurs peuvent remplir 1 et 2, le 3 est généralement très loin d'être évident, surtout quand on parle d'introduire des paradigmes fonctionnels dans une industrie qui y touche assez peu, ce qui impliquerait une grosse quantité de formation pour le faire admettre.
Un bel exemple concret de l'effet du pragmatisme dans l'utilisation des langages de programmation, c'est le couple Kotlin/Scala, deux langages conçus en réaction aux problèmes de Java et qui ont pour cible de tourner sur la JVM, tout en étant interopérable avec Java.
Je ne dis pas que l'un est meilleur que l'autre. Mais déconsidérer des langages en se basant sur leur propreté mathématique ou leur rapport à la recherche, c'est faire une erreur d'appréciation monumentale qui ignore une part énorme des besoins et contraintes qui régissent l'utilisation desdits langages. Et c'est une erreur que je croise depuis des années dans la recherche en informatique ou même dans pas mal de communautés qui font des langages fonctionnels ( = censément meilleurs mathématiquement).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Libération des données
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Comment je suis devenu chef de projet. Évalué à 2.
En fait pour moi ce que demande Renaud, ça ressemble assez rapidement à un historique de commit de code, et plus à une source. Un exemple concret : les calques d'un dessin sont souvent juste un outil de travail et n'ont pas d'intérêt en tant que « source ».
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un éditeur pour terminal NORMAL?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Emacs NU-MODE et ses concurrents. Évalué à 6.
Nano ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: Le·a Tour·e Eiffeil·e
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 6.
Sauf que l'ironie ne fonctionne – presque par définition – que si tu ne l'indique pas (ironie --> différence entre l'énoncé et le signifié) ; du coup ce point d'ironie m'a toujours paru un peu étrange conceptuellement.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Si votre disque dur a cramé à la reconstruction, c'est peut-être que [...]
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal RAID is no Backup!. Évalué à 2.
Merci :)
J'essaierai de mettre l'article à jour dès que j'aurai un peu de temps.
La connaissance libre : https://zestedesavoir.com
# Si votre disque dur a cramé à la reconstruction, c'est peut-être que ce n'était pas le bon disque
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal RAID is no Backup!. Évalué à 1. Dernière modification le 02 octobre 2017 à 09:46.
Je lis plusieurs fois dans le journal et les commentaires qu'il y a eu des problèmes de disques morts à la reconstruction. En fait, avec les capacités et les fiabilités modernes, c'est probablement normal si on a essayé de reconstruire un RAID fait avec des disques « grand public ». Je détaille les calculs ici.
Donc : pour faire du RAID, achetez des disques « spécial RAID » avec une haute fiabilité.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Typo ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Calculs numériques en précision absolue.. Évalué à 2. Dernière modification le 28 septembre 2017 à 18:55.
En fait il n'y a pas de parenthèses ou de priorité à reconnaitre, puisque tout l'intérêt de la RPN est justement qu'il n'y a plus besoin de gérer de parenthèses ou de priorité : tous les calculs sont faits instantanément.
Mais c'est à l'utilisateur de rentrer le calcul dans le bon ordre : pour faire le calcul
1 + 2 / 3en respectant la priorité du calcul écrit ainsi, il faut taper en RPN :2 3 / 1 +. Mais une erreur sur ce point n'est plus une erreur de l'interpréteur, c'est une erreur d'ICC :)La connaissance libre : https://zestedesavoir.com
[^] # Re: suggestions
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Pijul, un nouveau gestionnaire de source. Évalué à 3.
J'appuie à fond. Dans toutes les entreprises que j'ai fait, la migration SVN --> Git n'a pu se faire que parce qu'il y avait des outils permettant de basculer les projets déjà existants.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Latin-1 :'(
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java 9 est dehors. Évalué à 1.
Peut-être, mais il n'y a aucun rapport. Le but du jeu était de gagner en performances et en RAM.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Latin-1 :'(
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Java 9 est dehors. Évalué à 5.
C'est une question de performances je suppose : UTF-8 utilise des caractères qui n'ont pas tous la même longueur (en octets), ce qui complexifie pas mal les traitements.
La connaissance libre : https://zestedesavoir.com
[^] # Re: nan, c'est pas un problème d'arrondi qui te guette
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
J'ai l'impression que contrairement à ce que laissait entendre ton journal, tu ne l'as pas posté pour essayer de comprendre « pourquoi les types flottants natifs sont très peu utilisés pour faire des calculs financiers » mais plutôt pour tenter de convaincre tes lecteurs que selon toi, dans la majorité des cas, on pourrait très bien utiliser ces fameux flottants natifs. Et ce nonobstant toutes les explications qu'on t'a données. C'est un peu dommage.
La connaissance libre : https://zestedesavoir.com
# Propagation d'erreurs, éléphants et souris
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal SQL Decimal vs Double. Évalué à 8.
Tu fais aussi souvent référence au fait que les
doubleportent une précision de 10-16 environ, ce qui devrait être suffisant.Mais c'est oublier deux choses :
Les calculs d'intérêts, typiquement, se retrouvent très bien dans ces deux points.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Cumul des arrondis
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal SQL Decimal vs Double. Évalué à 3.
Ça n'est pas dans les pratiques de re-facturer des erreurs. Il ne doit pas y avoir d'erreur de dérive.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un retour d'expérience
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal SQL Decimal vs Double. Évalué à 2.
Oui, ce que je veux dire c'est que dès qu'il y a des mouvements réels d'argent en jeu, on est définis à 2 décimales : typiquement si tu achètes 1 litre d'essence à 1.298 €/litre, tu vas payer 1.30 €.
La connaissance libre : https://zestedesavoir.com
# Un retour d'expérience
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal SQL Decimal vs Double. Évalué à 10.
Je pense que toute l'astuce est là :
Si c'est un montant (monétaire) final (et pas un intermédiaire de calcul), sur une monnaie comme l'euro, la troisième décimale et toutes celles au-delà n'ont pas d'existence réelle. D'ailleurs il y a des règles officielles pour arrondir si les calculs donnent un montant à plus de 2 décimales (de mémoire : partie décimale < 0,5 --> inférieur, partie décimale >= 0,5 --> supérieur).
Du coup dans ton cas il n'y a pas réellement de « arrondit violent » : c'est le résultat du calcul qui donne bien, selon les règles de la finance, 10.22 et non 10.222.
D'une manière générale, c'est aussi un domaine où on a besoin autant que faire ce peut de valeurs exactes et pas « avec des approximations qu'on peut normaliser » sur toutes les valeurs finales. D'expérience, pour avoir bossé quelques années dans le e-commerce, utiliser des double au lieu de décimale fixe t'expose à deux types de blagues :
Utiliser correctement les outils basés sur des décimales fixes permettent d'éviter ces écueils, même si c'est généralement lourd et chiant à faire.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Le par-cœur est-il vraiment utile?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Recrutons. D'accord, mais sur quels critères ?. Évalué à 3.
Ça rejoint une conception assez américaine du contrôle scolaire des connaissances, j'ai l'impression – et inversement quelque chose qui a l'air assez spécifique à la France.
De ce que j'en ai discuté avec pas mal d'étudiants étrangers (de tous horizons) pendant mes études, les systèmes à l'américaine ont l'air connus pour utiliser beaucoup de QCM qui font beaucoup appel au « par cœur » de notions précises. Ça se retrouve dans les certifications IBM par exemple, qui consistent exactement en ça (ex : « Donnez le nom et le chemin qui sert à configurer les paramètres X de la fonctionnalité Y – un truc que personne ne touche – entre A, B, C, D et E »).
Le système scolaire français à l'inverse a tendance à miser sur la réflexion, en proposant en guise de contrôle des connaissances la possibilité de faire des rédactions sur à peu près n'importe quel sujet, du français à la biologie en passant par l'histoire et la philosophie. Ou, dans les cas qui s'y prêtent le moins, des exercices à questions ouvertes.
Disclaimer : ça fait 10 ans que j'ai fini mes études et 16 que j'ai fini le lycée, ça a pu changer depuis.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Je n'ai pas envie de cliquer
Posté par SpaceFox (site web personnel, Mastodon) . En réponse au journal Recrutons. D'accord, mais sur quels critères ?. Évalué à 9.
L'article est sous copyright, et même si ce n'était pas le cas, il a une mise en forme compliquée qui m'aurait pris plus de temps à refaire au propre qu'au lecteur de le relire.
La connaissance libre : https://zestedesavoir.com