Il y a sans doute un juste milieu entre « triste, vieillot et peu avenant » et « mettre des animations partout ». Un concept du genre « accueillant et lisible », sans doute.
L'avantage des polices web, c'est qu'on a pas à se demander si elles sont disponibles sur tel ou tel OS. Malgré son nom, je pense que LinuxFR est visualisé depuis autre chose que des distrib' Linux, et là aussi le rendu devrait être bon.
Un collègue qui passait par là m'a fait une remarque sur le design, qu'il trouve triste et vieux. C'est vrai que j'en ai l'habitude à force de trainer ici (et qu'on est loin d'un developpez.com), mais il y a probablement quelque chose à faire pour rendre le site visuellement plus attractif aux nouveaux venus.
Ça pourrait être aussi l'occasion de retravailler l'ergonomie, avec par exemple des contenus aux lignes moins longues, une police plus lisible (personnellement j'ai un faible pour Merriweather) et sans doute des tas de trucs auxquels je ne pense pas car n'étant pas ergonome.
Je crois que tu te retrouvera avec les même problématique. Et tenter d'adapter un outil existant pour qu'il fasse ce que tu veux et qui n'est pas forcément prévu par cette outil n'est pas plus facile que de développer du code spécifique.
Je ne suis pas spécialement convaincu par cet argument, pour plusieurs raisons :
Tu peux choisir ton outil pour qu'il convienne au mieux à ton besoin (et mis à part l'espace de rédaction qui est particulier, je n'ai pas l'impression que les besoins de LinuxFR soient très particuliers).
Tu peux adapter une partie du besoin pour qu'il rentre dans l'outil.
En admettant que l'effort soit effectivement identique pour adapter que pour développer depuis 0, utiliser un outil tiers te permet d'avoir ce qui est fait par l'upstream en bonus.
Inversement, ça permet aussi de faire vivre cet outil, parce qu'avec un peu de chance il y aura des patches remontés à l'upstream.
Disons qu'en l'état, j'ai l'impression qu'aujourd'hui la décision de développer une plateforme spécifique se fait sur un à priori dont je n'ai pas vu de justification. Sans doute existe-t-il de bonnes raisons de réimplémenter un forum, un outil de suivi, un wiki, mais elles ne me paraissent pas évidentes.
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.
[^] # Re: Un coup de polish sur le design ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 4.
Il y a sans doute un juste milieu entre « triste, vieillot et peu avenant » et « mettre des animations partout ». Un concept du genre « accueillant et lisible », sans doute.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Titre en français
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 0.
Hop, un superbe exemple : https://linuxfr.org/users/alexandre--2/journaux/le-canada-publie-un-cadriciel-libre-d-analyse-de-maliciels
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un coup de polish sur le design ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 1.
L'avantage des polices web, c'est qu'on a pas à se demander si elles sont disponibles sur tel ou tel OS. Malgré son nom, je pense que LinuxFR est visualisé depuis autre chose que des distrib' Linux, et là aussi le rendu devrait être bon.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Un coup de polish sur le design ?
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.
Sans doute qu'avec les feuille de style alternatives ont trouve du plus joli, mais je pense à tous les visiteurs qui découvrent le site.
La connaissance libre : https://zestedesavoir.com
# Un coup de polish sur le design ?
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 4. Dernière modification le 25 octobre 2017 à 11:29.
Un collègue qui passait par là m'a fait une remarque sur le design, qu'il trouve triste et vieux. C'est vrai que j'en ai l'habitude à force de trainer ici (et qu'on est loin d'un developpez.com), mais il y a probablement quelque chose à faire pour rendre le site visuellement plus attractif aux nouveaux venus.
Ça pourrait être aussi l'occasion de retravailler l'ergonomie, avec par exemple des contenus aux lignes moins longues, une police plus lisible (personnellement j'ai un faible pour Merriweather) et sans doute des tas de trucs auxquels je ne pense pas car n'étant pas ergonome.
La connaissance libre : https://zestedesavoir.com
[^] # Re: 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é à 2. Dernière modification le 23 octobre 2017 à 11:37.
Je ne suis pas spécialement convaincu par cet argument, pour plusieurs raisons :
Disons qu'en l'état, j'ai l'impression qu'aujourd'hui la décision de développer une plateforme spécifique se fait sur un à priori dont je n'ai pas vu de justification. Sans doute existe-t-il de bonnes raisons de réimplémenter un forum, un outil de suivi, un wiki, mais elles ne me paraissent pas évidentes.
La connaissance libre : https://zestedesavoir.com
# 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