Il s’avère que Django a une particularité. Il optimise les fichiers statiques (JS, CSS, HTML, images?) avec un outil écrit en java. Il faut java pour faire tourner une application Django avec de bonne performances.
Ce n'est pas Django qui fait ça, mais https://pypi.org/project/django-mediagenerator/, une app Django qui a décidé de faire appel à YUI. Et creme utilise cette application. (Qui n'est d'ailleurs pas mise à jour depuis 2015.)
Il s’avère que Django a une deuxième particularité. Il dépend de Pillow, une bibliothèque logicielle de manipulation d’images. Et Pillow doit se compiler sur la machine lors de son installation.
C'est une dépendance optionnelle, en effet. Sous Linux, tu n'as besoin de la compiler que si tu utilises musl (c'est ton cas avec Alpine), sinon avec la glibc les wheels manylinux fournies par le projet Pillow s'installent sans compilation.
Je ne prétends pas que trio soit utile dans le cas de tâches CPU-bound (au contraire), mais je trouvais que c'était intéressant de noter les parallèles.
(Ah et lancer une tâche ou en changer est bien plus rapide que de changer de thread.)
Concernant ta note de bas de page : concurrent.futures est arrivé avec Python 3.2 (2011) avec un backport pour Python 2.7 (https://pypi.org/project/futures/), et la syntaxe async/await est arrivée avec Python 3.5 (2015). Tout ça n'est pas spécifique à Python 3.7, donc.
Je pense que tu aurais à gagner à t'intéresser de plus près au travaux qui sont fait sur async/await, parce que les problématiques sont vraiment les mêmes. En particulier, l'auteur de Trio s'est longuement penché sur les questions d'évaluation en arrière-plan. Trio ne s'occupe pas des fonctions CPU-bound, mais à part ça on retrouve de nombreux points que tu as abordés :
Concernant la taille de la communauté, c'est difficile à quantifier, mais quelle que soit sa taille, c'est contre-productif de ne pas partager le travail. On a la chance en Python de pouvoir implémenter asyncio et Trio dans des librairies, il ne faudrait pas que cette chance se retourne contre nous.
Concernant l'industrie, tout ce que je peux dire c'est que je ne suis pas la seule personne a avoir écrit du code asyncio dans mon équipe, et on a du code Trio en production.
Et enfin, sur le côté théorique, il y a différentes choses qui font que Trio avait de bonnes chances de naître en Python, mais les autres concepteurs de langages de programmation suivent avec intérêt. C'est difficile à montrer, mais ça donne par exemple des discussions un peu techniques sur ce qui différencie exactement les nurseries des autres techniques de programmation concurrente, comme https://twitter.com/graydon_pub/status/989249148288253954.
La communauté Trio (dont je fais partie) est très accueillante : en plus de disposer d'un code de conduite, tous les contributeurs sont invités dans l'organisation Github, même pour des fautes de frappe dans la documentation.
Le principal obstacle pour programmer en Trio aujourd'hui est l'absence de bibliothèques tierces. Il existe bien trio-asyncio, pour utiliser une bibliothèque asyncio dans un programme Trio. Ça fonctionne très bien, mais c'est une rustine en attendant d'avoir mieux : les problèmes inhérents à asyncio sont cachés mais existent encore.
L'objectif n'étant pas de continuer à fragmenter l'écosystème des librairies asynchrone en Python, nous travaillons sur une approche de décoloration qui supporterait à la fois le Python 2/3 synchrone classique mais aussi les différentes solutions asynchrones existantes : Twisted, asyncio, Trio, etc. L'expérimentation se fait sur urllib3 dans le but d'ajouter le support de trio à requests. Si quelqu'un est intéressé, le développement se passe ici : https://github.com/python-trio/urllib3, voir https://github.com/urllib3/urllib3/pull/1335 pour une description de l'approche. Ce qui est enthousiasmant, c'est de voir que les mainteneurs de requests et pip sont intéressés, ce qui l'est un peu moins c'est qu'il reste beaucoup de travail ! :)
Si c'est découpé en de nombreux petits fichiers ce n'est pas pour mettre les bâtons dans les roues, c'est une façon de faire qui est complètement standard même si quelque part on réimplémente une partie de HTTP. Il faut juste utiliser des outils appropriés, ici le magnifique youtube-dl: $ youtube-dl https://www.france.tv/france-5/enquete-de-sante/347201-peut-on-guerir-du-diabete.html.
Pareil pour le CAPES de maths. Pour le prochain oral (en juin/juillet), les élèves ont 2h30 pour rédiger une leçon sous OpenOffice.org 3.4 (bientôt Libre Office ?) et d'autres logiciels en général libres, comme Python 3.2. Du coup ça ne m'étonnerait pas qu'ils continuent à s'en servir une fois titulaires.
Cette année on recrutait aussi quelqu'un qui devait connaître le C++. Le meilleur candidat ne connaissait pas ; je l'ai aidé à apprendre pendant le stage. Au final, c'est un candidat qui se débrouille mieux en C++ que la plupart des gens que j'ai côtoyé en école d'ingénieur. C'est normal : rien de mieux que la pratique pour apprendre.
Donc oui, on cherche un candidat productif et enthousiaste à l'idée de libérer un logiciel, mais ce n'est pas pour ça que 1/ on va trouver le candidat qui a déjà fait ça dix fois 2/ il ne va rien apprendre. C'est un stage qui couvre beaucoup de choses, et je suis convaincu que le contenu pédagogique est fort. Typiquement, écrire des tests unitaires utiles, ça ne s'invente pas. Écrire de la bonne doc c'est pas facile non plus. Changer les ressources linguistiques d'une application existante est aussi un petit challenge technique. Ce n'est peut-être pas ton avis, mais en tout cas je peux t'assurer que le but est vraiment que le stagiaire y trouve aussi son compte.
Tu as raison, j'ai oublié. Comme dit dans les commentaires par un ex-membre du labo, ce n'est pas le laboratoire qui fixe les salaires. Pour un stage long, c'est entre 750€ et 1300€ brut (j'ai vu les deux cas de figure quand j'étais en stage ; ça dépend de la formation). Le net se calcule sur la part au-dessus du minimum légal (un peu plus de 430€).
Les cinq items existent déjà¹, mais ce n'est jamais aussi bien qu'on le voudrait. La libération du code les rend plus important pour une raison simple : quand un développeur ou un utilisateur a une question sur un aspect du logiciel, il ne peut plus demander au collègue ou au support : il faut soit de la bonne documentation soit plonger dans le code.
C'est le genre de choses auxquelles je pensais quand je donnais le lien nommé "les avantages du logiciel libre en entreprise" ; qu'il faut comprendre comme "les avantages de développer un logiciel comme si il était libre, qu'il le soit ou non".
¹ Le plus abouti actuellement, ce sont les tests fonctionnels. C'est très important pour nous : on s'assure que cet assemblage complexe (avec notamment pas mal d'apprentissage automatique) gère toujours les cas qui nous importent, même quand on remplace un composant.
Mandriva SA a fourni quelques ressources et en quelque sorte "imposé" le nom et la forme de l'association (Pour être franc, je ne sais pas qui a choisi le nom, l'actionnaire principal de Rosa et Mandriva SA peut-être, mais au bout du compte, peu importe, […]
Faisant partie de la communauté de MegaGlest, je me permets d'apporter des précisions, parce qu'il y a énormément de confusion sur le sujet.
Glest est le projet de base qui est mort depuis un certain temps (les devs sont partis). Ça a été développé de manière propre et c'est donc très facile de faire des mods (la configuration se fait par du xml, et on peut ajouter ses propres textures, modèles 3D et animations).
Du coup, de nombreux moddeurs ont continué à travailler en utilisant Glest, le moteur. D'autres développeurs ont lancé GAE (qui n'est pas vraiment un fork, plutôt une suite de Glest) pour ajouter des nouvelles fonctionnalités. Tellement de fonctionnalités que des rumeurs disent que c'est très moyennement stable.
Un peu après, un développeur a lancé MegaGlest en partant aussi de Glest, surtout pour s'amuser au début. Un autre développeur l'a rejoint et ils ont apporté le support multijoueur (note : le serveur fait partie des joueurs, ou au moins des observateurs, pas possible de mettre le serveur sur un dédié). C'est quelque chose de très sensible et ils ont corrigé de nombreux bugs subtils qui menaient à des désynchronisations. C'est moins joli que GAE mais c'est beaucoup plus stable et les gens peuvent jouer entre eux.
Les développeurs de MegaGlest ont aussi fait l'effort de réunir différents "factions" et de les équilibrer. Ils ont beaucoup joué pour détecter les unités qui donnaient un avantage. C'est pas du niveau de Starcraft mais c'est un vrai plus pour le multijoueur.
Enfin, GAE et MegaGlest ont effectivement eu le projet de faire une sorte de merge (en commençant par s'emprunter des fonctionnalités) mais ça ne s'est pas concrétisé, la première raison étant que c'est un travail monstre et que les deux projets avaient déjà leur priorités.
TL;DR: on ne peut pas dire "Glest est mort, vive MegaGlest" parce qu'il faut aussi ajouter "Vive Glest Advanced Engine !". Les deux projets ne sont pas vraiment concurrents et aucun n'est prêt à mourir. :)
Au vu de la publication[1] du protocole[2] et d'un code d'exemple[3], ils ont envie que le plus de personnes possibles jouent avec le produit, effectivement. Mais de là à tabler sur une implémentation "concurrente" pour le cas général, il y a un fossé. Je vois plus apparaître tout un tas de petites implémentations spécifiques se concentrant sur des points très particuliers.
La justification se fait aussi d'un niveau conceptuel : beaucoup trop d'applications KDE implémentent leur propre tabbing dans leur application (Konqueror, Konsole, etc.), alors que ça devrait être fait au niveau du window manager.
Certes ça pose des problèmes niveau ergonomie, les tabs de différentes applications peuvent avoir besoin de se comporter différemment. C'est d'ailleurs dans ce sens là que pousse Google Chrome, même si pour le coup ça s'intègre mal aux window managers existants.
Tu noteras que le dernier lien de la dépêche est une capture d'écran, et qu'il y en a même une autre si tu cliques sur le troisième lien.
Quant à la formation des médecins, selon le site officiel le logiciel est « pensé par et pour les utilisateurs », l'ergonomie ayant été « pensée et poussée dans ses derniers retranchements », etc. A-t-on l'avis de personnes éxtérieures aux projets à ce niveau ?
# Deux précisions
Posté par Quentin Pradet . En réponse au journal Ça passe crème. Évalué à 9.
Merci pour ton retour d'expérience !
Ce n'est pas Django qui fait ça, mais https://pypi.org/project/django-mediagenerator/, une app Django qui a décidé de faire appel à YUI. Et creme utilise cette application. (Qui n'est d'ailleurs pas mise à jour depuis 2015.)
C'est une dépendance optionnelle, en effet. Sous Linux, tu n'as besoin de la compiler que si tu utilises musl (c'est ton cas avec Alpine), sinon avec la glibc les wheels manylinux fournies par le projet Pillow s'installent sans compilation.
[^] # Re: Bon exemple jouet
Posté par Quentin Pradet . En réponse au journal machine learning - expérimentation foireuse. Évalué à 2.
Merci, corrigé ! Je ne connaissais pas get_dummies non plus :)
[^] # Re: Bon exemple jouet
Posté par Quentin Pradet . En réponse au journal machine learning - expérimentation foireuse. Évalué à 6.
Merci, j'en ai profité pour faire quelques tests : https://quentin.pradet.me/stuff/vehicule_linuxfr.html
Effectivement, tu manques de données :)
Je t'encourage à faire des tests avec un dataset qui marche mieux : https://scikit-learn.org/stable/datasets/index.html#boston-dataset (sklearn.datasets.load_boston).
[^] # Re: Parallèle avec async/await
Posté par Quentin Pradet . En réponse au journal SeqTools et retour d'expérience sur le traitement de jeux de données en python. Évalué à 2. Dernière modification le 31 octobre 2018 à 12:21.
Je ne prétends pas que trio soit utile dans le cas de tâches CPU-bound (au contraire), mais je trouvais que c'était intéressant de noter les parallèles.
(Ah et lancer une tâche ou en changer est bien plus rapide que de changer de thread.)
# Parallèle avec async/await
Posté par Quentin Pradet . En réponse au journal SeqTools et retour d'expérience sur le traitement de jeux de données en python. Évalué à 6.
Merci pour le partage !
Concernant ta note de bas de page : concurrent.futures est arrivé avec Python 3.2 (2011) avec un backport pour Python 2.7 (https://pypi.org/project/futures/), et la syntaxe async/await est arrivée avec Python 3.5 (2015). Tout ça n'est pas spécifique à Python 3.7, donc.
Je pense que tu aurais à gagner à t'intéresser de plus près au travaux qui sont fait sur async/await, parce que les problématiques sont vraiment les mêmes. En particulier, l'auteur de Trio s'est longuement penché sur les questions d'évaluation en arrière-plan. Trio ne s'occupe pas des fonctions CPU-bound, mais à part ça on retrouve de nombreux points que tu as abordés :
[^] # Re: Communauté et bibliothèques
Posté par Quentin Pradet . En réponse au journal La programmation concurrente en mode Goto. Évalué à 3.
Concernant la taille de la communauté, c'est difficile à quantifier, mais quelle que soit sa taille, c'est contre-productif de ne pas partager le travail. On a la chance en Python de pouvoir implémenter asyncio et Trio dans des librairies, il ne faudrait pas que cette chance se retourne contre nous.
Concernant l'industrie, tout ce que je peux dire c'est que je ne suis pas la seule personne a avoir écrit du code asyncio dans mon équipe, et on a du code Trio en production.
Et enfin, sur le côté théorique, il y a différentes choses qui font que Trio avait de bonnes chances de naître en Python, mais les autres concepteurs de langages de programmation suivent avec intérêt. C'est difficile à montrer, mais ça donne par exemple des discussions un peu techniques sur ce qui différencie exactement les nurseries des autres techniques de programmation concurrente, comme https://twitter.com/graydon_pub/status/989249148288253954.
# Communauté et bibliothèques
Posté par Quentin Pradet . En réponse au journal La programmation concurrente en mode Goto. Évalué à 7.
La communauté Trio (dont je fais partie) est très accueillante : en plus de disposer d'un code de conduite, tous les contributeurs sont invités dans l'organisation Github, même pour des fautes de frappe dans la documentation.
Le principal obstacle pour programmer en Trio aujourd'hui est l'absence de bibliothèques tierces. Il existe bien trio-asyncio, pour utiliser une bibliothèque asyncio dans un programme Trio. Ça fonctionne très bien, mais c'est une rustine en attendant d'avoir mieux : les problèmes inhérents à asyncio sont cachés mais existent encore.
L'objectif n'étant pas de continuer à fragmenter l'écosystème des librairies asynchrone en Python, nous travaillons sur une approche de décoloration qui supporterait à la fois le Python 2/3 synchrone classique mais aussi les différentes solutions asynchrones existantes : Twisted, asyncio, Trio, etc. L'expérimentation se fait sur urllib3 dans le but d'ajouter le support de trio à requests. Si quelqu'un est intéressé, le développement se passe ici : https://github.com/python-trio/urllib3, voir https://github.com/urllib3/urllib3/pull/1335 pour une description de l'approche. Ce qui est enthousiasmant, c'est de voir que les mainteneurs de requests et pip sont intéressés, ce qui l'est un peu moins c'est qu'il reste beaucoup de travail ! :)
[^] # Re: Encore un autre
Posté par Quentin Pradet . En réponse au journal Minage en douce. Évalué à 10.
Si c'est découpé en de nombreux petits fichiers ce n'est pas pour mettre les bâtons dans les roues, c'est une façon de faire qui est complètement standard même si quelque part on réimplémente une partie de HTTP. Il faut juste utiliser des outils appropriés, ici le magnifique youtube-dl:
$ youtube-dl https://www.france.tv/france-5/enquete-de-sante/347201-peut-on-guerir-du-diabete.html.[^] # Re: Warnings
Posté par Quentin Pradet . En réponse à la dépêche La version 4.8 du compilateur GCC est disponible. Évalué à 1.
De toute façon GCC n'utilise pas de couleurs.
[^] # Re: Le service informatique...
Posté par Quentin Pradet . En réponse au journal Lycée et informatique : spécialité ISN en terminale S. Évalué à 2.
Pareil pour le CAPES de maths. Pour le prochain oral (en juin/juillet), les élèves ont 2h30 pour rédiger une leçon sous OpenOffice.org 3.4 (bientôt Libre Office ?) et d'autres logiciels en général libres, comme Python 3.2. Du coup ça ne m'étonnerait pas qu'ils continuent à s'en servir une fois titulaires.
[^] # Re: Shell graphique
Posté par Quentin Pradet . En réponse à la dépêche LiquidPrompt version 1.3. Évalué à 2.
L'auteur a exposé la situation sur reddit, et il a en gros perdu foi en un développement ouvert.
[^] # Re: Ahhh, les stages de 6 mois…
Posté par Quentin Pradet . En réponse au journal Proposition de stage : libération d'un logiciel industriel. Évalué à 2.
Fais un Google Summer of Code si tu n'as que trois mois. :)
[^] # Re: Des dollars !
Posté par Quentin Pradet . En réponse au journal Proposition de stage : libération d'un logiciel industriel. Évalué à 4.
Cette année on recrutait aussi quelqu'un qui devait connaître le C++. Le meilleur candidat ne connaissait pas ; je l'ai aidé à apprendre pendant le stage. Au final, c'est un candidat qui se débrouille mieux en C++ que la plupart des gens que j'ai côtoyé en école d'ingénieur. C'est normal : rien de mieux que la pratique pour apprendre.
Donc oui, on cherche un candidat productif et enthousiaste à l'idée de libérer un logiciel, mais ce n'est pas pour ça que 1/ on va trouver le candidat qui a déjà fait ça dix fois 2/ il ne va rien apprendre. C'est un stage qui couvre beaucoup de choses, et je suis convaincu que le contenu pédagogique est fort. Typiquement, écrire des tests unitaires utiles, ça ne s'invente pas. Écrire de la bonne doc c'est pas facile non plus. Changer les ressources linguistiques d'une application existante est aussi un petit challenge technique. Ce n'est peut-être pas ton avis, mais en tout cas je peux t'assurer que le but est vraiment que le stagiaire y trouve aussi son compte.
[^] # Re: Des dollars !
Posté par Quentin Pradet . En réponse au journal Proposition de stage : libération d'un logiciel industriel. Évalué à 7.
Tu as raison, j'ai oublié. Comme dit dans les commentaires par un ex-membre du labo, ce n'est pas le laboratoire qui fixe les salaires. Pour un stage long, c'est entre 750€ et 1300€ brut (j'ai vu les deux cas de figure quand j'étais en stage ; ça dépend de la formation). Le net se calcule sur la part au-dessus du minimum légal (un peu plus de 430€).
[^] # Re: licence ?
Posté par Quentin Pradet . En réponse au journal Proposition de stage : libération d'un logiciel industriel. Évalué à 7.
Il y a deux possibilités : GPL 3 ou LPGL 3. La décision n'est pas encore prise.
[^] # Re: Hum
Posté par Quentin Pradet . En réponse au journal Proposition de stage : libération d'un logiciel industriel. Évalué à 4.
Les cinq items existent déjà¹, mais ce n'est jamais aussi bien qu'on le voudrait. La libération du code les rend plus important pour une raison simple : quand un développeur ou un utilisateur a une question sur un aspect du logiciel, il ne peut plus demander au collègue ou au support : il faut soit de la bonne documentation soit plonger dans le code.
C'est le genre de choses auxquelles je pensais quand je donnais le lien nommé "les avantages du logiciel libre en entreprise" ; qu'il faut comprendre comme "les avantages de développer un logiciel comme si il était libre, qu'il le soit ou non".
¹ Le plus abouti actuellement, ce sont les tests fonctionnels. C'est très important pour nous : on s'assure que cet assemblage complexe (avec notamment pas mal d'apprentissage automatique) gère toujours les cas qui nous importent, même quand on remplace un composant.
[^] # Re: C'est un sauvetage de face
Posté par Quentin Pradet . En réponse au journal Qu'est supposée être OpenMandriva ?. Évalué à 1.
Même si OpenMandriva était le choix de Mandriva SA, il faut préciser qu'il y a eu un sondage où la communauté a pu valider ce choix.
[^] # Re: Mort du PC de Mme Michu
Posté par Quentin Pradet . En réponse au journal Bientôt la fin de la ligne fixe ?. Évalué à 1.
Bien tenté, mais selon la vidéo on ne voit rien de l'autre côté.
# Quelques précisions. :)
Posté par Quentin Pradet . En réponse au journal Aimez-vous les grosses bagarres ?. Évalué à 4.
Faisant partie de la communauté de MegaGlest, je me permets d'apporter des précisions, parce qu'il y a énormément de confusion sur le sujet.
Glest est le projet de base qui est mort depuis un certain temps (les devs sont partis). Ça a été développé de manière propre et c'est donc très facile de faire des mods (la configuration se fait par du xml, et on peut ajouter ses propres textures, modèles 3D et animations).
Du coup, de nombreux moddeurs ont continué à travailler en utilisant Glest, le moteur. D'autres développeurs ont lancé GAE (qui n'est pas vraiment un fork, plutôt une suite de Glest) pour ajouter des nouvelles fonctionnalités. Tellement de fonctionnalités que des rumeurs disent que c'est très moyennement stable.
Un peu après, un développeur a lancé MegaGlest en partant aussi de Glest, surtout pour s'amuser au début. Un autre développeur l'a rejoint et ils ont apporté le support multijoueur (note : le serveur fait partie des joueurs, ou au moins des observateurs, pas possible de mettre le serveur sur un dédié). C'est quelque chose de très sensible et ils ont corrigé de nombreux bugs subtils qui menaient à des désynchronisations. C'est moins joli que GAE mais c'est beaucoup plus stable et les gens peuvent jouer entre eux.
Les développeurs de MegaGlest ont aussi fait l'effort de réunir différents "factions" et de les équilibrer. Ils ont beaucoup joué pour détecter les unités qui donnaient un avantage. C'est pas du niveau de Starcraft mais c'est un vrai plus pour le multijoueur.
Enfin, GAE et MegaGlest ont effectivement eu le projet de faire une sorte de merge (en commençant par s'emprunter des fonctionnalités) mais ça ne s'est pas concrétisé, la première raison étant que c'est un travail monstre et que les deux projets avaient déjà leur priorités.
TL;DR: on ne peut pas dire "Glest est mort, vive MegaGlest" parce qu'il faut aussi ajouter "Vive Glest Advanced Engine !". Les deux projets ne sont pas vraiment concurrents et aucun n'est prêt à mourir. :)
[^] # Re: Respect de la licence d'utilisation
Posté par Quentin Pradet . En réponse au journal Spotify sans les pubs audio. Évalué à 1.
Même si le son est juste très bas, même si c'est le son système, etc.
[^] # D'autres implémentations ?
Posté par Quentin Pradet . En réponse au journal Google Wave. Évalué à 3.
[1] http://www.waveprotocol.org/
[2] http://www.waveprotocol.org/draft-protocol-spec
[3] http://code.google.com/p/wave-protocol/
[^] # Utilité du tabbing
Posté par Quentin Pradet . En réponse au journal GSOC: Onglets dans Kwin. Évalué à 6.
La justification se fait aussi d'un niveau conceptuel : beaucoup trop d'applications KDE implémentent leur propre tabbing dans leur application (Konqueror, Konsole, etc.), alors que ça devrait être fait au niveau du window manager.
Certes ça pose des problèmes niveau ergonomie, les tabs de différentes applications peuvent avoir besoin de se comporter différemment. C'est d'ailleurs dans ce sens là que pousse Google Chrome, même si pour le coup ça s'intègre mal aux window managers existants.
[^] # Re: $1
Posté par Quentin Pradet . En réponse au message ouvrir un fichier avec des programmes en ligne de commande bash. Évalué à 2.
Exemple de script :
#!/bin/sh
echo $1corrige.mpg
Son utilisation :
./script.sh film
filmcorrige.mpg
[^] # Re: BRA-VO !!
Posté par Quentin Pradet . En réponse à la dépêche Medintux : Médecin, étudiant vous êtes concerné. Évalué à 3.
Quant à la formation des médecins, selon le site officiel le logiciel est « pensé par et pour les utilisateurs », l'ergonomie ayant été « pensée et poussée dans ses derniers retranchements », etc. A-t-on l'avis de personnes éxtérieures aux projets à ce niveau ?