En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.
tout le monde ne travaille pas en équipe ou si c'est le cas en inter-dépendance.
une mise en prod n’inclus pas foncièrement un déploiement complexe : à la base, on parle d'un soft en cli donc le déploiement c'est création d'un exécutable.
tous les projets ne sont pas forcément orienté "software as a service".
dans une grande structure, tu as souvent une panoplies de rôles : dba, admin sys, devops, archi etc.
certaines responsabilités porté par des devs dans certaines boites ne le sont pas dans d'autres
les devs ne choisissent que rarement la stack (ou l'intégralité), langage y compris.
un worflow tel que tu le décris (canary release, AB test) a un coût matériel et humain loin d'être négligeable.
c'est quoi un bon dev ? C'est tellement subjectif.
Un workflow bien millimétré, ça nécessite d'embaucher des gens qualifiés (ou les former) donc on peut les classer dans la case des "bons devs".
Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.
et que ce facteur humain va dépendre de leur porte feuille, du processus d'embauche, d'un brin de chance etc.
Tout dépend de ce que tu produits.
Si le dev en question nécessite d'avoir des connaissances métiers très pointus (par exemple médical), le bon dev sera un mélange entre qualité technique et connaissances en rapport.
Si le dev doit interagir avec de la donnée : il faut qu'il soit pointu en SQL, elasticSearch etc sinon la qualité ne pourra pas être au rendez-vous.
Si ça nécessite des connaissances mathématiques, il aura beau savoir suivre un worflow de dingue, ça ne suffira pas.
J'ai et j'ai eu l'occasion de travailler sur des projets seul, avec des petites et des grandes équipes : worflow de malade, dev à l'arrache, langage compilé, interprété, fortement typé ou non.
Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.
Ca veut pas dire qu'on peut pas faire des erreurs de typage avec un langage fortement typé, (genre mettre un string là ou on attend un entier et caster comme un porc un peu partout)
mais on limite vachement les risques, c'est mathématique.
Mieux que ça : dev avec des grosses contraintes m'a mis le nez sur des soucis que je n'aurais jamais anticipé avant.
J'en conçoit, ça n'évite pas les bugs logiques, fonctionnels, métier mais c'est quand même plus valorisant de se concentrer que la dessus, non ?
Il n'est pas impossible d'avoir des erreurs au runtime en Rust (d'ailleurs, aucun langage ne les évites intégralement) mais faut déjà sacrément pousser pour y arriver alors qu'avec d'autres langages, c'est d'une facilité déconcertante.
La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
pourquoi c'est arrivé et comment on évite à l'avenir.
Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.
En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.
Faut avoir un outil de rollback simple mais coder comme si il était impossible.
[quote]
C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité.
[/quote]
Bon, y'a une variété de tests qui existent, je ne t'apprend rien.
Un test pour moi, c'est une forme de doc : ça dit à un instant T ce que ton soft fait ou ne fait pas.
Tout ce qui n'est pas testé n'est pas contractuel.
Je ne vois pas en quoi faire un écrire un test par quelqu'un d'autre que le dev de la fonctionnalité change quoi que ce soit.
La review de code (si c'est possible avec une hiérarchie de reviewer), le pair programming et inclure le code des tests dans cette relecture me semble bien plus vital.
Un reviewer "senior" qui te drive en te disant qu'il manque tel test ou que ce dernier ne sert à rien, n'aura sans doute pas écrit le code mais ce sera tout comme.
Autre constat, plus tu as de doc et moins tu as de chance que ça soit lu, compris, assimilé par tous.
Comme dis, avoir la même rigueur avec un langage interprété nécessite de faire des tests de typage.
Ca prend du temps, ça n'apporte pas grand chose et ça parasite la doc.
Enfin, quand on a un soucis en prod, tu le sais aussi bien que moi, l'enjeu c'est souvent de reproduire.
Limite, c'est un autre métier.
Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.
Je suis bien conscient que dans 10 ans je tomberais encore sur les bugs les plus habituels : date, encodage, dépendances etc. mais je ferais tout pour que ça ne soit pas mon cœur de métier.
En toute franchise, je me considère pas comme le meilleur dev, loin de là : j'écris pas en dvorak avec du 150 MPM, je passe souvent par l'étape papier avant de sortir du syndrome de la page blanche.
Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.
Ca m'a permis de voir certaines choses soit disant acquises avec un autre regard : par exemple la POO.
Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.
La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.
La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)
Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).
Pour des softs comme rigrep, l'objectif de l'auteur était clairement d'avoir un grep le plus rapide qui soit et la promesse est tenu en partie par le langage.
Pour les autres, effectivement, dans l'absolu, Rust ne se justifie sans doute pas.
Après, je pense que beaucoup ont tendance à mettre Rust dans la case "bas niveau" à tord.
De ma propre expérience, c'est pas forcément ce qui m'a attiré en premier.
J'ai voulu m'investir dans un langage robuste il y a 4 ans et je l'ai comparé à Go (et à d'autres) à l'époque.
Malgré sa jeunesse, il présentait des vertus sur le typage, pattern matching, programmation fonctionnel qui me semblait bien plus pointus que ceux de Go.
Je ne connais pas l'état actuel de Go mais vu comment ça a évolué niveau Rust : communauté, évol du langage, doc etc… je pense que je ferais le même choix aujourd'hui.
Crystal, que je ne connais que de nom, me parait plus exotique et Occaml (même constat pour Haskell) reste et restera (malgré son âge et sa maturité) un langage de niche plutôt académique.
A titre pro, j'ai jonglé avec Java et C# et je voulais aussi investir dans un langage qui soit moins piloté par une grosse boite donc difficile de privilégier des "Swift", "Kotlin", "Scala", "Go".
( Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable)
Sur l'aspect utilisateur, je trouve aussi qu'avoir des outils cli qui n'utilise pas de GC est un gros avantage.
Sur du linux, on sait très bien qu'on peut avoir un panel de softs très hétérogènes et que ça peut avoir un impact mémoire non négligeable tout cumulé.
Franchement, me dire que sur un serveur, un rpi etc, je vais avoir des cron avec des scripts en python, en nodejs, en scala, en Go etc… et bien je vais me taper n GC qui consomment de la mémoire inutilement.
En C ou en Rust, ça ne sera pas le cas. (sauf cas de fuite, bien entendu)
Je fais sans doute parti de ses dinosaures qui ont du mal à comprendre pourquoi on gaspille tant de mémoire actuellement pour des trucs basiques.
C'est pas du deep learning mais des pauvres scripts et plus c'est populaire et plus ça devrait être insignifiant en impact mémoire, en temps de démarrage etc.
Effectivement, quand j'ai vu que ça s'emballait… j'ai préféré ne pas répondre par peur que ça soit mal interprété peu importe mes propos.
Bien évidemment, en employant "modérateur", je partais du postulat que ce mot est neutre.
D'apprendre que l'équipe de modération est mixte me réjoui.
J'essaierai (dans la mesure de mes capacités) d'y faire attention à l'avenir.
C'est effectivement quelque chose que j'ai déjà envisagé.
Pour un autre projet, je me suis déjà amusé à mettre le nez dans les sources de grammalecte et parser certains dictionnaires.
Je dirais que l'intérêt pour gSpeech résiderais plus sur les données collectés plutôt que sur les algos qui sont plus dédiés a de la reconnaissance en vue d'un correctif.
En fait, la lib picovox lit déjà naturellement pas mal de texte correctement.
Il y a malheureusement quelques subtilités (que je comble avec les algos énumérés plus haut) et il est très délicat de les appréhender. (à part l'identifier via une lecture)
Je ne suis pas certain qu'il y ai des données tel que de la phonétique dans grammalecte mais si c'est le cas, ça pourrait être du pur caviar pour le second projet : speechtux.
Mais oui, y'a sans doute des pistes à explorer tel qu'une lecture gardé fluide malgré quelques fautes d'orthographes ou de saisie par exemple.
Alors, j'ai fait la même opération que l'auteur mais avec Nix et j'en suis actuellement à 7.3G (du -sh /nix/store) avec la dernière version de gimp, inkscape, geany, guake, une quinzaine de petits utilitaires et sans doute une bonne cinquantaine de doublons lié aux paquets que j'ai empaqueté.
Je pense, le mieux pour te faire une idée est déjà de faire l'install minimal et de surveiller paquet par paquet.
Tout est mis dans /nix/store (ou /gnu/store si tu pars sur guix) et il t'es donc facile de surveiller l'évolution.
Tout d'abord, merci de cet article.
Il n'y a quasiment aucun article francophone sur le sujet donc rien que pour ça, ça nécessite d'être souligné !
Connaissant Nix, je vois bien entendu beaucoup de similitudes.
/gnu/store au lieu de /nix/store mais même principe : des noms de paquet avec des hash.
Même constat que pour Nix : pourquoi diable avoir mis les hash avant les noms…
Pour ce qui est Snap et FlatPak : c'est très orienté user avec des outils graphiques mais dès qu'on regarde un peu de plus prêt… la magie n'opère plus.
Je pense avoir un peu de recul sur la création de paquets : j'ai déjà fait moultes paquets debian, un peu d'archlinux, des paquets Python, Rust et depuis peu Nix et j'ai trouvé (il y a un peu plus d'un an) les tutos et la doc de Snap et Flatpak totalement ridicules.
Dès qu'on sort du hello world avec plus de 2/3 dépendances, ça devient très compliqué à empaqueter et à maintenir.
J'estimes que dans la communauté Linux (tout du moins je l'espère), la qualité technique, la facilité des outils de création, la doc et l'aide ont souvent tout autant voir plus d'importance que l'outil final.
Cqfd : si personne n'est emballé pour empaqueter, le store au final restera vide.
Perso, je préfère engager du temps sur des projets comme apt/nix (guix, je découvre donc j'ai pas encore d'avis) plutôt que perdre mon temps avec snap/flatpak/appimage.
Pour ton comparatif Guix/Nix, 3 points non techniques et totalement subjectifs :
- Le nom Guix est sans doute mieux choisi que Nix car y'a pas d'embrouille pour les moteurs de recherche : point pour Guix.
- Le logo de Nix est une pure merveille d'ingéniosité : des lambdas qui forment un flocon de neige alors que Guix, je cherche toujours (une tête de gnou probablement) : point pour Nix
- les moteurs de recherche web des paquets : point pour Nix même si lent (la requète ajax qui rappatri un gros json avec tous les paquets est juste horrible)
Peux-être une question bête car j'ai peu d'expérience sur l'emquetage de projet en C++ : Les dépendances "boost, openssl, websocketpp, zlib" sont obligatoires ? Qu'elle est ton cheminement pour les trouver ?
Guix me parait sympa mais arrive bien après une version stable de Nix qui présente tous les avantages cités + d'avantages de paquets + 1 plus grande communauté.
Du coup, j'ai de la peine à comprendre l'intérêt autours de Guix (à part pour les barbus RMSiste) et déplore encore de la fragmentation qui ça engendre.
Etant l'auteur de l'aspect graphique et sachant que je n'ai finalisé les détails bien après les 90% de la partie technique, j'en suis pas mal responsable.
Les 2 points évoqués peuvent être corrigés mais je ne vois pas de solution "simple".
Le fait de choisir aléatoirement ou doivent être placé les animaux me semble plutôt bon didactiquement parlant.
Si l'on veut faire les choses bien, il faudrait déplacer les enclos de place je suppose.
Les animaux semble voler au dessus du poulailler : en gros, délimiter des zones ou les animaux peuvent être glissés mais pas déposés.
C'est pas impossible mais mon expérience me fait dire qu'on risque des bugs sournois. (surtout si on envisage le déplacement des enclos)
Pour la suppression d'un animal, c'est bien noté dans la consigne.
C'est l'aspect graphique qui ne te plais pas dans les boutons ?
Si oui, les rendre plus joyeux, ne veux pas forcément dire d'utiliser des images :le css fait des prouesses à faible frais désormais.
La partie démarrage pourrais se faire dans une petite modale qui serait caché une fois l'exercice commencé. (ça laisserais plus de place à l'écran également)
Un bouton d'aide avec un exemple par étapes pourrait rendre la compréhension plus efficace.
En se rappelant que cet applicatif fera partie d'un tout (une liste d'applicatif), ils nous faudra sans doute réfléchir à retrouver des codes communs tout en gardant un peu de souplesse sur des variétés graphiques.
Pour ce qui est d'écouter la consigne : je développe actuellement une refonte de gspeech (https://github.com/mothsART/speechtux) qui ferais office de serveur de synthèse vocale avec une API.
Via un petit greffon, il sera tout à fait possible de rajouter des consignes "sonores".
Néanmoins, à l'usage, je ne suis pas certain que beaucoup de classes seront équipés en casques afin d'éviter la cacophonie.
Ça reste donc une évolution loin d'être prioritaire.
Je ne me suis encore jamais plongé dans le projet Gcompris mais j'ai cru comprendre que c'était dev en QT donc pas forcément compatible avec de la techno web. (mais j'adorerais qu'on me prouve le contraire)
Quand tu parles de la possibilité de se séparer d'électron, y'a bien entendu la possibilité d'utiliser un petit serveur web local.
Dans mon éditeur interactif, j'ai fait le choix d'aller au plus simple : j'utilise l'API HTML5 file.
C'est pas parfait car ça nécessite de charger le fichier en mémoire puis de l'exporter une fois terminé.
Après, y'a sans doute des solutions hybrides possibles : ton soft s'ouvre sur un firefox qui contient une extension assurant la partie sauvegarde par exemple.
On parle aussi beaucoup des Progressives Web App mais j'ai pas encore suffisamment creusé la question.
Pour les exemples, il faudrait sans doute proposer un petit concours ici sur un thème : par exemple, illustrations éducatives pour les enfants des 3 premiers cycles. (Oui, si ça peut servir des projets comme Primtux, c'est encore mieux)
Enfin, j'ai parcourus quelques réalisations qui sont certes sympas mais qui ont manqués de réactivités les premières secondes (https://sozi.baierouge.fr/community/d/43-support-de-conf-rence-culture-libre).
Je vois plusieurs raisons de frustration à mon sens :
- fichier svg non minifié : un coup de svgo pourrait sans doute permettre de gagner quelques Mo précieux
- un chargement progressif : première slides chargés avant et pourquoi pas une barre de chargement
- les animations sont-elles effectués par le css ou le js ?
Une piste de réflexion que je me donne également pour mes futures projets webs : canvas est beaucoup plus réactif que svg.
J'ai effectué des tests de svg avec des animations css que j'ai comparé avec canvas (sur une grande matrice : 2048*2048) avec des animations js.
Eh bin, canvas était à chaque fois au moins 4 à 5 fois moins gourmand.
A creuser sans doute : une conversion du svg en canvas.
Voilà, je sais que la critique est au combien facile. J'espère que celle-ci sera suffisamment constructive.
Vu qu'elles sont intégrés par mes soins, tu peux me faire des remarques directement.
(Je ferais suivre si besoin)
A l'avenir (paquet debian séparé pour l'instant mais je vais sans doute faire pareil pour le dépôt GIT), je souhaites séparer contenu et éditeur pour éviter les amalgames.
Les exemples sont également visible dans l'éditeur. il suffit de les charger puis de les prévisualiser.
J'ai commencé également un paquet debian pour Primtux qui rassemble l'ensemble des illustrations définitives prêt à être utilisé dans le cadre éducatif : https://github.com/mothsART/illustrationsvg
Chaque illustration à son lanceur : .desktop et png
@ElectronLibre63 : Je viens de soumettre une PR : https://framagit.org/marsat/CTparental/merge_requests/1
Toi aussi tu pourrais le faire… ça te prendrais un tout petit peu plus de temps que ce commentaire.
(pour ma part : 10 minutes montre en main)
Je vais sans doute voir pour faire une autre PR pour le « 0 minutes déjà utilisées »
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 6. Dernière modification le 14 mai 2020 à 13:58.
En fait, barmic, tu construis ton argumentaire autours de plusieurs postulats qui ne sont pas forcément vrai.
Je pense plutôt qu'il y a une constante : n'importe quel boite souhaite la meilleur qualité et donc des salariés le plus compétents possibles, agiles, volontaires etc.
et que ce facteur humain va dépendre de leur porte feuille, du processus d'embauche, d'un brin de chance etc.
Tout dépend de ce que tu produits.
Si le dev en question nécessite d'avoir des connaissances métiers très pointus (par exemple médical), le bon dev sera un mélange entre qualité technique et connaissances en rapport.
Si le dev doit interagir avec de la donnée : il faut qu'il soit pointu en SQL, elasticSearch etc sinon la qualité ne pourra pas être au rendez-vous.
Si ça nécessite des connaissances mathématiques, il aura beau savoir suivre un worflow de dingue, ça ne suffira pas.
J'ai et j'ai eu l'occasion de travailler sur des projets seul, avec des petites et des grandes équipes : worflow de malade, dev à l'arrache, langage compilé, interprété, fortement typé ou non.
Mon constat c'est que beaucoup de choses "critiques" (les fameuses 500 qui font tant plaisir) peuvent être évités en amont avec du typage, du pattern matching et de l'immutabilité.
Ca veut pas dire qu'on peut pas faire des erreurs de typage avec un langage fortement typé, (genre mettre un string là ou on attend un entier et caster comme un porc un peu partout)
mais on limite vachement les risques, c'est mathématique.
Mieux que ça : dev avec des grosses contraintes m'a mis le nez sur des soucis que je n'aurais jamais anticipé avant.
J'en conçoit, ça n'évite pas les bugs logiques, fonctionnels, métier mais c'est quand même plus valorisant de se concentrer que la dessus, non ?
Il n'est pas impossible d'avoir des erreurs au runtime en Rust (d'ailleurs, aucun langage ne les évites intégralement) mais faut déjà sacrément pousser pour y arriver alors qu'avec d'autres langages, c'est d'une facilité déconcertante.
La simplicité du rollback, c'est bien mais faut pas que ça devienne une solution de facilité.
Bien entendu qu'il est impossible de livrer en prod sans un dérapage mais ce qui me semble plus important que le rollback en lui-même c'est les mesures prisent après rollback :
pourquoi c'est arrivé et comment on évite à l'avenir.
Avec ça, on réduit leur fréquence graduellement et on peut se permettre d'éviter des dettes techniques : maj des libs régulières, refacto etc.
En plus, il y a tellement de cas ou un rollback n'est pas possible (ou que celui-ci a un coût) que de s'appuyer dessus c'est le désastre assuré.
Faut avoir un outil de rollback simple mais coder comme si il était impossible.
[quote]
C'est parce que les tests sont écrit par un autre développeur (entre autre) que tu obtiens de la qualité.
[/quote]
Bon, y'a une variété de tests qui existent, je ne t'apprend rien.
Un test pour moi, c'est une forme de doc : ça dit à un instant T ce que ton soft fait ou ne fait pas.
Tout ce qui n'est pas testé n'est pas contractuel.
Je ne vois pas en quoi faire un écrire un test par quelqu'un d'autre que le dev de la fonctionnalité change quoi que ce soit.
La review de code (si c'est possible avec une hiérarchie de reviewer), le pair programming et inclure le code des tests dans cette relecture me semble bien plus vital.
Un reviewer "senior" qui te drive en te disant qu'il manque tel test ou que ce dernier ne sert à rien, n'aura sans doute pas écrit le code mais ce sera tout comme.
Autre constat, plus tu as de doc et moins tu as de chance que ça soit lu, compris, assimilé par tous.
Comme dis, avoir la même rigueur avec un langage interprété nécessite de faire des tests de typage.
Ca prend du temps, ça n'apporte pas grand chose et ça parasite la doc.
Enfin, quand on a un soucis en prod, tu le sais aussi bien que moi, l'enjeu c'est souvent de reproduire.
Limite, c'est un autre métier.
Reproduire, c'est souvent 90% du taf et quand je fais le constat amer d'avoir passé des heures a arriver à reproduire un bug qui est lié à du typage, ça me fait rager parce que je sais qu'il pouvait être évité en amont.
Je suis bien conscient que dans 10 ans je tomberais encore sur les bugs les plus habituels : date, encodage, dépendances etc. mais je ferais tout pour que ça ne soit pas mon cœur de métier.
En toute franchise, je me considère pas comme le meilleur dev, loin de là : j'écris pas en dvorak avec du 150 MPM, je passe souvent par l'étape papier avant de sortir du syndrome de la page blanche.
Néanmoins, je pense que l'apprentissage de Rust m'a permis de m'améliorer sur plein de sujets et je recommande vivement de sortir de sa zone de confort avec ce genre de langage.
Ca m'a permis de voir certaines choses soit disant acquises avec un autre regard : par exemple la POO.
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 3. Dernière modification le 13 mai 2020 à 23:50.
Ouais, enfin l'un n'empêche pas l'autre.
Avec un langage fortement typé et qui fait un max de vérifications à la compilation, tu t'évites l'écriture d'une paires de tests (débiles pour la plupart) qu'un langage interprété et faiblement typé t'oblige pour avoir la même rigueur avant déploiement.
La solidité de ton déploiement : c'est pas forcément au dev de gérer ça donc hs.
La simplicité du rollback : si tu rollback, c'est que t'as cassé la prod, non ? (donc pouvoir rollback c'est bien mais éviter de casser la prod, c'est mieux)
Niveau workflow, j'aurais plutôt parlé des logs, des métriques, des envs de recette avec cahiers de tests (tu sais, piloté par des humains : c'est encore ce qui se fait de mieux).
[^] # Re: Flatpak?
Posté par mothsART . En réponse au journal Sortie de ./play.it 2.11.4. Évalué à 2.
Pourquoi Flatpak ? Et pourquoi pas Nix ?
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à -2.
https://www.youtube.com/watch?v=3w5cwBrvtf4
[^] # Re: rust
Posté par mothsART . En réponse à la dépêche Trois utilitaires : Delta, Dust et Watchexec. Évalué à 9.
Pour des softs comme rigrep, l'objectif de l'auteur était clairement d'avoir un grep le plus rapide qui soit et la promesse est tenu en partie par le langage.
Pour les autres, effectivement, dans l'absolu, Rust ne se justifie sans doute pas.
Après, je pense que beaucoup ont tendance à mettre Rust dans la case "bas niveau" à tord.
De ma propre expérience, c'est pas forcément ce qui m'a attiré en premier.
J'ai voulu m'investir dans un langage robuste il y a 4 ans et je l'ai comparé à Go (et à d'autres) à l'époque.
Malgré sa jeunesse, il présentait des vertus sur le typage, pattern matching, programmation fonctionnel qui me semblait bien plus pointus que ceux de Go.
Je ne connais pas l'état actuel de Go mais vu comment ça a évolué niveau Rust : communauté, évol du langage, doc etc… je pense que je ferais le même choix aujourd'hui.
Crystal, que je ne connais que de nom, me parait plus exotique et Occaml (même constat pour Haskell) reste et restera (malgré son âge et sa maturité) un langage de niche plutôt académique.
A titre pro, j'ai jonglé avec Java et C# et je voulais aussi investir dans un langage qui soit moins piloté par une grosse boite donc difficile de privilégier des "Swift", "Kotlin", "Scala", "Go".
( Surtout Google qui n'a aucun scrupule à abandonner une techno dès qu'elle est pas rentable)
Sur l'aspect utilisateur, je trouve aussi qu'avoir des outils cli qui n'utilise pas de GC est un gros avantage.
Sur du linux, on sait très bien qu'on peut avoir un panel de softs très hétérogènes et que ça peut avoir un impact mémoire non négligeable tout cumulé.
Franchement, me dire que sur un serveur, un rpi etc, je vais avoir des cron avec des scripts en python, en nodejs, en scala, en Go etc… et bien je vais me taper n GC qui consomment de la mémoire inutilement.
En C ou en Rust, ça ne sera pas le cas. (sauf cas de fuite, bien entendu)
Je fais sans doute parti de ses dinosaures qui ont du mal à comprendre pourquoi on gaspille tant de mémoire actuellement pour des trucs basiques.
C'est pas du deep learning mais des pauvres scripts et plus c'est populaire et plus ça devrait être insignifiant en impact mémoire, en temps de démarrage etc.
[^] # Re: Ça a l'air intéressant mais on aimerait avoir une présentation du logiciel
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 6.
Effectivement, quand j'ai vu que ça s'emballait… j'ai préféré ne pas répondre par peur que ça soit mal interprété peu importe mes propos.
Bien évidemment, en employant "modérateur", je partais du postulat que ce mot est neutre.
D'apprendre que l'équipe de modération est mixte me réjoui.
J'essaierai (dans la mesure de mes capacités) d'y faire attention à l'avenir.
[^] # Re: synergie ?
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 4.
C'est effectivement quelque chose que j'ai déjà envisagé.
Pour un autre projet, je me suis déjà amusé à mettre le nez dans les sources de grammalecte et parser certains dictionnaires.
Je dirais que l'intérêt pour gSpeech résiderais plus sur les données collectés plutôt que sur les algos qui sont plus dédiés a de la reconnaissance en vue d'un correctif.
En fait, la lib picovox lit déjà naturellement pas mal de texte correctement.
Il y a malheureusement quelques subtilités (que je comble avec les algos énumérés plus haut) et il est très délicat de les appréhender. (à part l'identifier via une lecture)
Je ne suis pas certain qu'il y ai des données tel que de la phonétique dans grammalecte mais si c'est le cas, ça pourrait être du pur caviar pour le second projet : speechtux.
Mais oui, y'a sans doute des pistes à explorer tel qu'une lecture gardé fluide malgré quelques fautes d'orthographes ou de saisie par exemple.
[^] # Re: Common Voice
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 1. Dernière modification le 17 avril 2020 à 15:01.
J'avais un peu oublié ce projet.
Je vais prendre le temps d'y participer.
Qui sait, un jour gSpeech s'interfacera peut-être dessus.
[^] # Re: Ça a l'air intéressant mais on aimerait avoir une présentation du logiciel
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 2. Dernière modification le 16 avril 2020 à 20:40.
Très bien.
Serais-ce possible à un modérateur de rajouter en intro :
Egalement, serait-il possible de remplacer :
par :
[^] # Re: Ça a l'air intéressant mais on aimerait avoir une présentation du logiciel
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 6.
T'as pas à être désolé, il manque effectivement un prélude. (je pensais, à tord que c'était assez connu)
Y'a un peu de doc ici : https://doc.ubuntu-fr.org/svoxpico et je viens d'éditer ça :
https://wiki.primtux.fr/doku.php/gspeech
Je compléterais sans doute mais tu m'as pris de court.
Et oui, c'est bien de la synthèse vocale (et non de la reconnaissance vocal).
# oubli : appli "j'écoute puis j'écrit"
Posté par mothsART . En réponse au journal Lancement de Gspeech 0.8. Évalué à 6.
J'ai oublié de mettre le lien de l'app Primtux "J'écoute puis j'écris" (non finalisé) : https://primtux.fr/applications/ecoute-ecris/
[^] # Re: snap et faltpak : on nous ment sur la marchandise
Posté par mothsART . En réponse à la dépêche Guix pour remplacer mon gestionnaire de paquets APT. Évalué à 1.
Alors, j'ai fait la même opération que l'auteur mais avec Nix et j'en suis actuellement à 7.3G (du -sh /nix/store) avec la dernière version de gimp, inkscape, geany, guake, une quinzaine de petits utilitaires et sans doute une bonne cinquantaine de doublons lié aux paquets que j'ai empaqueté.
Je pense, le mieux pour te faire une idée est déjà de faire l'install minimal et de surveiller paquet par paquet.
Tout est mis dans /nix/store (ou /gnu/store si tu pars sur guix) et il t'es donc facile de surveiller l'évolution.
# snap et faltpak : on nous ment sur la marchandise
Posté par mothsART . En réponse à la dépêche Guix pour remplacer mon gestionnaire de paquets APT. Évalué à 7. Dernière modification le 21 mars 2020 à 21:46.
Tout d'abord, merci de cet article.
Il n'y a quasiment aucun article francophone sur le sujet donc rien que pour ça, ça nécessite d'être souligné !
Connaissant Nix, je vois bien entendu beaucoup de similitudes.
/gnu/store au lieu de /nix/store mais même principe : des noms de paquet avec des hash.
Même constat que pour Nix : pourquoi diable avoir mis les hash avant les noms…
Pour ce qui est Snap et FlatPak : c'est très orienté user avec des outils graphiques mais dès qu'on regarde un peu de plus prêt… la magie n'opère plus.
Je pense avoir un peu de recul sur la création de paquets : j'ai déjà fait moultes paquets debian, un peu d'archlinux, des paquets Python, Rust et depuis peu Nix et j'ai trouvé (il y a un peu plus d'un an) les tutos et la doc de Snap et Flatpak totalement ridicules.
Dès qu'on sort du hello world avec plus de 2/3 dépendances, ça devient très compliqué à empaqueter et à maintenir.
J'estimes que dans la communauté Linux (tout du moins je l'espère), la qualité technique, la facilité des outils de création, la doc et l'aide ont souvent tout autant voir plus d'importance que l'outil final.
Cqfd : si personne n'est emballé pour empaqueter, le store au final restera vide.
Perso, je préfère engager du temps sur des projets comme apt/nix (guix, je découvre donc j'ai pas encore d'avis) plutôt que perdre mon temps avec snap/flatpak/appimage.
Pour ton comparatif Guix/Nix, 3 points non techniques et totalement subjectifs :
- Le nom Guix est sans doute mieux choisi que Nix car y'a pas d'embrouille pour les moteurs de recherche : point pour Guix.
- Le logo de Nix est une pure merveille d'ingéniosité : des lambdas qui forment un flocon de neige alors que Guix, je cherche toujours (une tête de gnou probablement) : point pour Nix
- les moteurs de recherche web des paquets : point pour Nix même si lent (la requète ajax qui rappatri un gros json avec tous les paquets est juste horrible)
# Sympa
Posté par mothsART . En réponse au journal Gestion de paquets et DevOps avec Nix, tour d'horizon sur un cas concret. Évalué à 1. Dernière modification le 24 janvier 2020 à 13:45.
Comme toujours, très édifiant.
Peux-être une question bête car j'ai peu d'expérience sur l'emquetage de projet en C++ : Les dépendances "boost, openssl, websocketpp, zlib" sont obligatoires ? Qu'elle est ton cheminement pour les trouver ?
# intéresssé mais
Posté par mothsART . En réponse au journal Guix : un outil pour les remplacer tous. Évalué à 6.
Guix me parait sympa mais arrive bien après une version stable de Nix qui présente tous les avantages cités + d'avantages de paquets + 1 plus grande communauté.
Du coup, j'ai de la peine à comprendre l'intérêt autours de Guix (à part pour les barbus RMSiste) et déplore encore de la fragmentation qui ça engendre.
[^] # Re: première analyse scientifique
Posté par mothsART . En réponse au journal À la campagne, application éducative javascript. Évalué à 1.
Oui, donc QT5, à part javascript, c'est pas du web.
L'ancienne version c'est du GTK, Python et C.
[^] # Re: première analyse scientifique
Posté par mothsART . En réponse au journal À la campagne, application éducative javascript. Évalué à 1.
Etant l'auteur de l'aspect graphique et sachant que je n'ai finalisé les détails bien après les 90% de la partie technique, j'en suis pas mal responsable.
Les 2 points évoqués peuvent être corrigés mais je ne vois pas de solution "simple".
Le fait de choisir aléatoirement ou doivent être placé les animaux me semble plutôt bon didactiquement parlant.
Si l'on veut faire les choses bien, il faudrait déplacer les enclos de place je suppose.
Les animaux semble voler au dessus du poulailler : en gros, délimiter des zones ou les animaux peuvent être glissés mais pas déposés.
C'est pas impossible mais mon expérience me fait dire qu'on risque des bugs sournois. (surtout si on envisage le déplacement des enclos)
Pour la suppression d'un animal, c'est bien noté dans la consigne.
[^] # Re: première analyse scientifique
Posté par mothsART . En réponse au journal À la campagne, application éducative javascript. Évalué à 1.
C'est l'aspect graphique qui ne te plais pas dans les boutons ?
Si oui, les rendre plus joyeux, ne veux pas forcément dire d'utiliser des images :le css fait des prouesses à faible frais désormais.
La partie démarrage pourrais se faire dans une petite modale qui serait caché une fois l'exercice commencé. (ça laisserais plus de place à l'écran également)
Un bouton d'aide avec un exemple par étapes pourrait rendre la compréhension plus efficace.
En se rappelant que cet applicatif fera partie d'un tout (une liste d'applicatif), ils nous faudra sans doute réfléchir à retrouver des codes communs tout en gardant un peu de souplesse sur des variétés graphiques.
Pour ce qui est d'écouter la consigne : je développe actuellement une refonte de gspeech (https://github.com/mothsART/speechtux) qui ferais office de serveur de synthèse vocale avec une API.
Via un petit greffon, il sera tout à fait possible de rajouter des consignes "sonores".
Néanmoins, à l'usage, je ne suis pas certain que beaucoup de classes seront équipés en casques afin d'éviter la cacophonie.
Ça reste donc une évolution loin d'être prioritaire.
Je ne me suis encore jamais plongé dans le projet Gcompris mais j'ai cru comprendre que c'était dev en QT donc pas forcément compatible avec de la techno web. (mais j'adorerais qu'on me prouve le contraire)
# PWA ?
Posté par mothsART . En réponse à la dépêche De Sozi 12 à Sozi 19. Évalué à 4.
Sympa comme soft!
Quand tu parles de la possibilité de se séparer d'électron, y'a bien entendu la possibilité d'utiliser un petit serveur web local.
Dans mon éditeur interactif, j'ai fait le choix d'aller au plus simple : j'utilise l'API HTML5 file.
C'est pas parfait car ça nécessite de charger le fichier en mémoire puis de l'exporter une fois terminé.
Après, y'a sans doute des solutions hybrides possibles : ton soft s'ouvre sur un firefox qui contient une extension assurant la partie sauvegarde par exemple.
On parle aussi beaucoup des Progressives Web App mais j'ai pas encore suffisamment creusé la question.
Pour les exemples, il faudrait sans doute proposer un petit concours ici sur un thème : par exemple, illustrations éducatives pour les enfants des 3 premiers cycles. (Oui, si ça peut servir des projets comme Primtux, c'est encore mieux)
Enfin, j'ai parcourus quelques réalisations qui sont certes sympas mais qui ont manqués de réactivités les premières secondes (https://sozi.baierouge.fr/community/d/43-support-de-conf-rence-culture-libre).
Je vois plusieurs raisons de frustration à mon sens :
- fichier svg non minifié : un coup de svgo pourrait sans doute permettre de gagner quelques Mo précieux
- un chargement progressif : première slides chargés avant et pourquoi pas une barre de chargement
- les animations sont-elles effectués par le css ou le js ?
Une piste de réflexion que je me donne également pour mes futures projets webs : canvas est beaucoup plus réactif que svg.
J'ai effectué des tests de svg avec des animations css que j'ai comparé avec canvas (sur une grande matrice : 2048*2048) avec des animations js.
Eh bin, canvas était à chaque fois au moins 4 à 5 fois moins gourmand.
A creuser sans doute : une conversion du svg en canvas.
Voilà, je sais que la critique est au combien facile. J'espère que celle-ci sera suffisamment constructive.
[^] # Re: PrimTux démarre la création de contenu pour l'école par des illustrations interactives
Posté par mothsART . En réponse au journal Edit Interactive SVG 1.1. Évalué à 2.
Corrigé, merci.
[^] # Re: PrimTux démarre la création de contenu pour l'école par des illustrations interactives
Posté par mothsART . En réponse au journal Edit Interactive SVG 1.1. Évalué à 1.
Bien sur, tu peux retrouver mes coordonnées dans le changelog
[^] # Re: PrimTux démarre la création de contenu pour l'école par des illustrations interactives
Posté par mothsART . En réponse au journal Edit Interactive SVG 1.1. Évalué à 2.
Vu qu'elles sont intégrés par mes soins, tu peux me faire des remarques directement.
(Je ferais suivre si besoin)
A l'avenir (paquet debian séparé pour l'instant mais je vais sans doute faire pareil pour le dépôt GIT), je souhaites séparer contenu et éditeur pour éviter les amalgames.
[^] # Re: PrimTux démarre la création de contenu pour l'école par des illustrations interactives
Posté par mothsART . En réponse au journal Edit Interactive SVG 1.1. Évalué à 2.
Les exemples sont également visible dans l'éditeur. il suffit de les charger puis de les prévisualiser.
J'ai commencé également un paquet debian pour Primtux qui rassemble l'ensemble des illustrations définitives prêt à être utilisé dans le cadre éducatif : https://github.com/mothsART/illustrationsvg
Chaque illustration à son lanceur : .desktop et png
# commande eg
Posté par mothsART . En réponse au journal Ligne de commande : les 20 mémos d'un « autodidacte ». Évalué à 2.
Faut rassembler tout ton savoir dans un dépôt git utilisable par eg : https://github.com/srsudar/eg
[^] # Re: impressionnant
Posté par mothsART . En réponse à la dépêche PrimTux — nouvelle version pour les écoles. Évalué à 3. Dernière modification le 29 octobre 2018 à 13:58.
@ElectronLibre63 : Je viens de soumettre une PR : https://framagit.org/marsat/CTparental/merge_requests/1
Toi aussi tu pourrais le faire… ça te prendrais un tout petit peu plus de temps que ce commentaire.
(pour ma part : 10 minutes montre en main)
Je vais sans doute voir pour faire une autre PR pour le « 0 minutes déjà utilisées »