PROJET AUTOBLOG


Sam & Max: Python, Django, Git et du cul

Site original : Sam & Max: Python, Django, Git et du cul

⇐ retour index

Sheepit – Le rendering pour tous, accessible sans trop de difficultés et gratos 6   Recently updated !

mardi 18 avril 2017 à 12:20

Entre deux bars à putes et les restaux faut bien prendre un peu de temps pour se relaxer, il y a les salons de massage branlette vous me direz, mais pas que.

Dans une galaxie lointaine il y a fort fort longtemps je m’amusais à faire de la 3D, je vous parle d’un temps que les jeunes ne peuvent pas connaître…
A l’époque régnaient en maîtres absolus 3DS MAX, MAYA, CINEMA 4D, etc. et les outils maisons des studios Pixar. Pour les simples mortels comme moi on avait droit à Truespace, Vue D’esprit, Poser et sûrement d’autres dont j’ai oublié le nom. Truespace était mon favori, plutôt sympa, pas compliqué à prendre en main et pas cher (voir gratos quand on se démerdait).

Pour faire mumuse c’était super mais voilà, c’était long, long, longggggg………..

De nos jours on a droit à de supers cartes graphiques comme les Titans X  et pas mal de logiciels de 3D gratuits aussi, certes on peut faire dans le warez et se procurer Maya, 3D Studio, Cinema4D et plein de nouveaux que je ne connais pas mais restons dans le légal pour une fois car ce qui se passe est intéressant.

Donc le monde du gratos a super bien évolué, il y a plein de tutos sur YouTube, des logiciels gratuits concurrencent les plus gros softs de 3D sur le marché et si ses derniers ont du succès c’est surtout parce que les studios en ont fait leur standard.

Je vais vous parler de Blender, c’est un projet open source que je suis de très loin mais qui a attiré mon attention depuis peu avec quelques superbes vidéos sur YouTube sur lesquelles je suis tombé:
https://www.youtube.com/watch?v=-TksegJETqI
https://www.youtube.com/watch?v=kSp3pHA_tRM
https://www.youtube.com/watch?v=7lY9SlQ8gjY
https://www.youtube.com/watch?v=Q1VCLFJY250
https://www.youtube.com/watch?v=143k1fqPukk
https://www.youtube.com/watch?v=LcCQKuWPhXk

Il y a vraiment une bonne communauté.

Des milliers de tutos sur YouTube pour s’en sortir avec les millions d’options que possède le logiciel.

Bref tout ça c’est merveilleux, pour perdre son temps y’a pas mieux. Mais il y a un hic, le temps de rendu justement. Je me souviens de cette époque où j’attendais 1 heure, voire 2 pour rendre une seule image et m’apercevoir que le résultat était moyen.
Et de ce côté ça n’a pas changé ! C’est même plus long avec toutes les nouvelles options de raytracing possibles même avec des cartes graphiques surpuissantes comme cité plus haut. Alors une animation….

Blender possède un plugin de network rendering, à savoir partager le temps de calcul sur plusieurs serveurs du réseau, c’est sympa mais c’est pas tout le monde qui a 10 ordis à la maison…

Une solution a vu le jour il y a quelques années et quelques milliers de membres font vivre une véritable ferme de rendu.

Le principe de la ferme de rendu:
Via un réseau d’ordinateurs on partage le temps cpu entre plusieurs machines, accélérant ainsi le temps de rendu.

Cette solution c’est Sheepit.

Ok on décolle ! Vous installez leur app. java sur un serveur qui traîne au garage ou sur votre ordi et vous avez droit à des points en fonction du temps machine que vous consacrez à l’application. Ces points vont vous permettre “d’acheter” du temps de calcul parmi tous les participants.
Ainsi un projet d’animation qui d’ordinaire me prend 5 jours est rendu en quelques heures, gratos en plus !

Je trouve le concept très sympa, tout est gratuit, il y a une admin avec le nombres de personnes qui partagent vos calculs, on peut former des équipes pour se tirer la bourre ou privilégier les cpu à ses coéquipiers, bref c’est bien pensé et je voulais en parler pour, qui sait, leur ramener un peu de monde.

Aux dernières nouvelles il y a environ 350 machines connectées en permanence, vous imaginez le temps de calcul offert !

Une petite ligne de code pour mettre un serveur dans la pool:

inscrivez-vous sur sheepit : https://www.sheepit-renderfarm.com/getstarted.php
Il y a une version applet java pour le navigateur mais je n’ai pas testé, je préfère laisser tourner leur app. sur un serveur h24:
téléchargez l’app. java: https://www.sheepit-renderfarm.com/media/applet/sheepit-client-5.366.2818.jar

Sur CentOS j’ai créé un user “sheepit” pour pas lancer leur app. en “root”:

useradd sheepit

ensuite dans un screen je lance l’app. avec les paramètres suivants:

sudo -u sheepit java -jar /sheepit/sheepit-client-5.366.2818.jar -ui text -login mon_login_sheepit -password mon_pass_sheepit -cores 3 -compute-method CPU

-ui text : Pour lancer l’app. java en headless (pour les serveur sans GUI)
-login mon_login_sheepit : Le login que vous avez choisi lors de l’inscription à sheepit
-password mon_pass_sheepit : Le mot de passe que vous avez choisi lors de l’inscription à sheepit
-cores 3 : Le nombres de processeurs que vous voulez dédier à Sheepit, plus vous en dédiez plus vous gagnerez des points et plus vos projet passeront en priorité dans la pool de rendu.
-compute-method CPU: N’utilise que le cpu de votre serveur, vous pouvez mettre GPU si vous en avez.

Ce système a beaucoup d’avantages, il vous permet enfin de faire de supers rendus en peu de temps, sans dépenser d’argent, c’est vraiment magique. (je ne vous partagerais pas les merdes que j’ai faites car je suis une quiche en 3D). L’inconvénient c’est qu’il faut ensuite télécharger toutes les frames du projet, là j’ai 24 Go de frames à télécharger, ça fait lourd si on a pas la fibre.

Ils ont un forum qui ne demande qu’à grandir.

Il y a des artistes en herbe qui n’ont pas les moyens de s’offrir des cartes graphiques à 2000€ et je trouve ce système juste fantastique pour eux et même pour les gros projets. J’espère que vous ferez passer le mot et si vous avez un serveur ou deux soyez cool, ça prend 5 minutes.

Allez le meilleur pour la fin:

A poil les putes!

Django, une app à la fois, mis à jour

lundi 20 mars 2017 à 09:23

Django, une app à la fois fonctionnait avec une vielle version de Django, donc je l’ai mis à jour pour marcher avec la 1.10.

J’ai trop attendu et le travail a été plus long que prévu car plein de choses avaient du coup changé dans le framework. Des petits détails, mais déjà tout le routing ne marchait plus.

N’oubliez pas que la branche master est en anglais, mais il y a une branche traduite en français. Les deux sont téléchargeables sous forme de zip sur la page d’accueil du projet github si vous ne souhaitez pas utiliser git. Il n’y a rien à installer : unzip, lire, lancer.

D’une manière générale, le projet est toujours très pratique pour enseigner ou apprendre les bases de django en complément des supports traditionnels. Il faudra que je rajoute la partie ORM un de ces 4.

Dites non aux DSL 12

vendredi 17 mars 2017 à 13:11

Un Domain Specific Language est un langage créé pour une tache très particulière. CSS, HTML et SQL sont des bons exemples de DSL populaires. Moins connus: ReactQL, QML, Less, Latex, XPath, Graphviz… Les plus connus sont encore là car ils sont utiles, alors créer le vôtre pourrait être tentant.

Suite à ce tuto sur la fabrication d’un DSL en Python, je réalise que quelques personnes recommandent encore de créer des DSL.

Il faut absolument que je vous empêche de commettre cette erreur irréparable !

Une API n’est pas un DSL

Ruby, qui a des parenthèses optionnelles et la capacité d’intercepter les accès d’attributs à la volée, a lancé la mode du mot DSL à tout va. Sauf que la plupart des DSL en Ruby n’en sont pas. Ce sont juste des API écrites en Ruby.

You keep using that world, I don't think it means what you think it means

You killed my project, prepare to die

Enchaîner les méthodes et opérateurs overloadés dans un langage populaire n’est pas utiliser un DSL. foo.bar().baz() n’est PAS un DSL si ça tourne dans la VM du langage. Quel que soit l’enrobage syntaxique qu’on a rajouté.

Un format de sérialisation générique n’est pas un DSL: XML et YAML n’en sont pas, contrairement à ce qu’on peut lire. Car ils sont généralistes, et donc pas “domain specific” par nature.

Par contre on peut écrire un DSL en JSON, XML ou YAML, et il en existe d’ailleurs pas mal. MathML et SVG sont des exemples de DSL écrits en XML.

Ne créez jamais un DSL

Pourquoi avez vous besoin d’un nouveau langage ? Il existe des centaines de langages et encore plus de formats de sérialisation. Aucun d’entre eux ne peut répondre à votre besoin ? Vraiment ? Vous avez tout testé pendant un mois ?

The world is the problem, the atomic bombs the answer

Choisir le bon outil, Civ style

Créer un DSL , donc un nouveau langage, implique vous avez besoin:

Et il faut tenir tout ça à jour.

Ah. Ah. Ah.

Personne ne le fait jamais, ce qui fait de l’usage de la plupart des DSL un enfer, sans parler de la maintenance des projets qui l’utilisent sur le long terme. Mais les créateurs de DSL s’en effeuillent amoureusement les génitoires car ils seront dans une nouvelle boîte quand ça arrivera. Eux ils se sont bien amusés à créer un parseur pour le fun. D’ailleurs ça fait classe sur le CV.

Fuck everything

Réponse standardisée aux propositions de DSL. Aussi valable pour l’introduction d’une nouvelle stack JavaScript

Créez une API

Votre langage de prédilection est turing complet. Il est donc capable de gérer ce que fait le DSL. Libérez l’anus de cette mouche et traitez votre problème avec un langage supporté, éprouvé, avec un large écosystème et qui résout déjà tout un tas de problèmes.

Ce qu’il vous faut, c’est faire une belle API, pour rendre la tache agréable:

Rayon bien rangé

Avec une belle présentation, un truc standard ennuyeux devient soudainement très attractif

Si créer une API n’aide pas assez, par exemple vous faites un outil avec un langage haut niveau et avez besoin d’un langage haut niveau pour le scripting ou la configuration, embarquez un langage haut niveau connu. Par exemple Lua ou Python. Ne faites pas comme varnish ou nginx qui ont des fichiers de configuration dans un langage imbitable, indébuggable et mal documenté.

Quelques bonnes raisons de créer un DSL

Allez, il ne faut jamais dire jamais, et comme toujours en informatique, il y a parfois une bonne raison de faire quelque chose. Voici donc la liste des RARES cas où écrire un DSL a du sens:

Mais dans tous ces cas, ne faites un DSL que si:

Special snowflake award

“Mais moi c’est pas pareil”, le hello word du DSL pour prendre des mauvaises décisions dans la vie

devpy, outils de dev à l’arrache 4

mercredi 1 mars 2017 à 17:21

Je le publie en coup de vent car je me dis que ça peut servir à des gens, mais j’ai pas l’intention d’y passer des heures… vu que je fais ça pour me faire gagner du temps en mission.

J’ai créé devpy, un outil pour me faciliter le développement.

Dans sa forme la plus simple:

pip install devpy

Ca donne automatiquement:

En gros quand on commence à bosser on fait:

import devpy.develop as log

Et on peut logguer comme avec les logs python habituels (log.info, log.debug, etc).

On peut facilement retirer devpy une fois qu’on a fini et le remplacer par un log Python traditionnel type:

log = logging.getLogger(__name__)

Donc utiliser devpy ne coûte rien car on peut le retirer facilement une fois qu’on a fini: c’est 100% compat avec le log de la stdlib.

Ça tombe bien, car c’est pas un truc qu’on met en prod en théorie (même si ça peut pas abîmer le serveur).

C’est juste un outil que j’ai fait car j’en avais marre:

Je sais, il existe une tetra chiées d’outils de logging pour Python. Mais c’est pas ce que je veux. Je ne veux pas choisir une solution ou configurer un truc. Ca je le ferai plus tard, proprement. Je veux juste un log essentiel et à coût zero pour démarrer mes projets et pouvoir switcher plus tard.

Je vais sûrement rajouter des trucs dans devpy au fur et à mesure mais pour le moment ça fait ce que je veux.

Je l’ai mis compatible uniquement 3.6 car j’ai pas envie de me faire chier à tester ailleurs. D’ailleurs j’ai même pas de tests.

Et si vous êtes pas contents, vous pouvez vous mettre ma deadline là où je pense.

“BlockingIOError: [Errno 11] Resource temporarily unavailable” pour Python 3.6 6

mardi 28 février 2017 à 10:39

La toute première version de Python 3.6 avait un bug assez vicieux qui ne se manifestait que sous certaines conditions, généralement dans un daemon sur un serveur, et en important certains modules qui finissent par déclencher par réaction en chaîne l’usage de random.

django est concerné.

On tombait dessus généralement assez tard, à la mise en prod, avec un message cryptique:

 
BlockingIOError: [Errno 11] Resource temporarily unavailable 
  
 The above exception was the direct cause of the following exception: 

Traceback (most recent call last): 
   .... <- des imports de votre code qui ne font rien de mal
   File "/usr/local/lib/python3.6/site-packages/pkg_resources/__init__.py", line 36, in  
     import email.parser 
   File "/usr/local/lib/python3.6/email/parser.py", line 12, in  
     from email.feedparser import FeedParser, BytesFeedParser 
   File "/usr/local/lib/python3.6/email/feedparser.py", line 27, in  
     from email._policybase import compat32 
   File "/usr/local/lib/python3.6/email/_policybase.py", line 9, in  
     from email.utils import _has_surrogates 
   File "/usr/local/lib/python3.6/email/utils.py", line 28, in  
     import random 
   File "/usr/local/lib/python3.6/random.py", line 742, in  
     _inst = Random() 
 SystemError:  returned a result with an error set 

Cela a été corrigé rapidement, et le binaire patché ajoute juste un “+” à sa version:

$ python --version
Python 3.6.0+

En théorie vous ne pouvez pas tomber dessus, tous les liens de téléchargement ont été mis à jour, les distributions ont changé leurs dépôts, etc.

Mais hier je me suis fait bien niqué, et j’ai perdu 1h à debugguer cette surprise qui n’avait aucun sens (puisque mon code allait bien) : les bugs dans les binaires officiels sont rares et c’est le dernier endroit où je cherche.

En effet, certaines sources non-officielles pour installer Python n’ont pas été mises à jour, et c’est le cas du très populaire PPA deadsnakes.

Si vous avez installé Python 3.6 en faisant :

sudo add-apt-repository ppa:fkrull/deadsnakes
sudo apt-get update
sudo apt-get install python3.6

vous l’avez dans le cul.

Il existe un PPA plus à jour si vous avez besoin de corriger le tir :

sudo add-apt-repository ppa:jonathonf/python-3.6
sudo apt-get update
sudo apt-get install python3.6

Donc si vous avez compilé Python à la main ou utilisé un PPA, assurez-vous bien d’avoir la bonne version, et sinon upgradez. En attendant j’ai un bug report à faire à deadsnakes