KrISS feed 8 - Un simple et superbe (ou stupide) lecteur de flux. Par Tontof
  • Friday 28 April 2017 - 15:02

    Arg, j’ai plein de commentaires sans réponse sur le blog, indexerror aussi. Des tickets millénaires sur 0bin et les impôts qui arrivent. Des fois ce qu’il faut c’est une petit victoire pour relativiser.

    Du coup, un petit post pour me donner l’impression de ne pas être inutile à l’humanité.

    De toutes les recommandations du PEP8, garder des lignes courtes, souvent moins de 80 caractères, est celle qui fait le plus râler.

    On rétorque parfois que c’est une règle qui n’a pas de sens de nos jours avec nos grands écrans HD.

    Sauf que:

    • L’œil humain fonctionne par micro sauts, et peut donc bien plus efficacement scanner de longues colonnes que de longues lignes.
    • Il est très courant de pouvoir mettre du code côte à côte sur un même écran pour comparer, merger ou avoir plusieurs vues sur un fichier.
    • Vous ne savez pas sur quoi sera lu votre code. Au bureau vous avez peut être un setup à triple écran 4K, mais les autres n’ont peut être pas cette chance. Les chats, les pastebins, les blogs posts, un slide show, un remote ssh, des comments, des tickets, ou un retro projecteur basse résolution sont autant de supports sur lesquels votre code finira probablement. Et ils ne sont pas larges.
    • Un diff sur de longues lignes c’est dégueulasse.
    • Le debug pas à pas qui s’arrête sur une ligne de 3km ça donne des envies de meurtre.

    D’une manière générale, garder des lignes courtes est une bonne habitude et incitera à écrire un code sain. Le processus de réduire la taille des lignes passe par l’expressivité, la clarté, le refactoring, etc. Au final, c’est excellent pour la santé du projet.

    N’oubliez pas non plus que le PEP8 indique clairement qu’il ne faut jamais suivre une règle de manière rigide. Si votre ligne est absolument plus adéquate sur une ligne, alors mettez là sur une ligne.

    Maintenant qu’on a expliqué le pourquoi, parlons du comment. En effet beaucoup de bonnes pratiques ne sont pas appliquées parce qu’on ne sait pas faire. Faire des lignes courtes demande une certaine connaissance, et un peu de pratique.

    Voici quelques pistes pour vous aider dans vos prochaines sessions.

    Python est fait pour ça

    Python force à indenter, et c’est une de ses meilleures caractéristiques. Jamais vous ne vous retrouverez comme dans d’autres langages face au code de votre collègue, ce gros porc, qui aligne ses accolades avec le groin.

    Mais pour garder des lignes courtes, l’indentation joue contre vous.

    Python vient heureusement avec tout un tas d’outils pour rendre votre code court, rapide et peu gourmand on mémoire. C’est tout bénef.

    itertools, all(), any(), filter(), map(), collections, les listes en intension, functools et les générateurs sont tous d’excellents moyens de créer un code plus beau, plus court, et plus efficace. Apprenez à les utilisez ! Vous serez un meilleur programmeur, plus productif, et les lignes seront naturellement plus courtes.

    Exemples…

    Le module itertools permet de faire un tas de choses, comme remplacer les boucles imbriquées.

    Remplaçons :

    >>> for lettre in "abc":
    ...     for chiffre in (1, 2, 3):
    ...         print(lettre, chiffre)
    ...
    a 1
    a 2
    a 3
    b 1
    b 2
    b 3
    c 1
    c 2
    c 3

    Par :

    >>> from itertools import product
    >>> products = product("abc", (1, 2, 3))
    >>> for lettre, chiffre in products:
    ...     print(lettre, chiffre)

    Les built-ins ont un tas d’outils pour pour manipuler les données.

    Si vous avez des collections dont vous voulez vérifier tout le contenu:

    >>> from random import randint
    >>> data = [randint(0, 10) for x in range(0, randint(0, 10))]
    >>> max(data)  # pas besoin de boucler pour trouver le max
    9
    >>> if any(x > 3 for x in data): # any est un super "or"
    ...    print('Un élément est supérieur à 3')

    Le module collections possède d’ailleurs tout un tas d’outils pour faire le travail à votre place :

    >>> from collections import Counter
    >>> Counter("aaaaaaaaabbbbbbccccc")
    Counter({'a': 9, 'b': 6, 'c': 5})

    On peut éviter un tas de try/except avec les helpers qui retournent une valeur par défaut:

    >>> {"foo": 1}.get('bar', 3)  # et next, iter, setdefault... 
    3

    Sans parler de l’unpacking, le slicing, le paramétrage dynamique, etc.

    Bref, si votre ligne est trop longue, c’est peut être parce que vous être en train de sous-utiliser Python.

    De même, apprenez les libs les plus célèbres en Python.

    pytest, pendulum, request, pandas…

    Dès qu’un usage particulier intervient, elles seront généralement plus efficaces que la stdlib. Moins de code !

    Refactorisez

    Un bloc de code qui commence à être long sera avantageusement déplacé dans une méthode ou une fonction. Avec un joli nom bien explicite qui va naturellement rendre votre code mieux documenté, et testable.

    Tant qu’on y est, faites usages des variables intermédiaires.

    res = [foo for foo in objet.attribut['cle'] if foo > wololo]

    Gagnera à devenir:

    nom_explicite = objet.attribut['cle']
    res = [foo for foo in nom_explicite if foo > wololo]

    Les parenthèses pour les sauts de ligne

    Les parenthèses en Python, c’est magique.

    Avant :

    from module_de_la_mort_qui_tue import foo, bar, et, toute, la, clique

    Après

    from module_de_la_mort_qui_tue import (
    	foo, 
    	bar, 
    	et, 
    	toute, 
    	la, 
    	clique
    )

    Ca marche partout, dans les appels de fonctions, l’accès des attributs, les chaînes de caractères…

    On part de :

    queryset = ModelDeDjango.objects.filter(attribut=val).first()

    Et bim :

    queryset = (ModelDeDjango.objects
                             .filter(attribut=val)
                             .first())

    Si des parenthèses sont déjà là, inutile d’en rajouter:

    Aller :

    raise OverkillError("Arrrrrrrrrrrrrrrrrrrrrrrrrrrrggggggg")

    Hop :

    raise OverkillError(
    	"Arrrrrrrrrrrrrrrrr"
    	"rrrrrrrrrrrggggggg"
    )

    Aidez-vous de l’environnement

    Vous outils sont là pour vous faciliter la vie. Votre éditeur par exemple, a certainement un moyen d’afficher un indicateur vertical pour symboliser la limite de 80 caractères.

    Les bons IDES et les linters vous signaleront le dépassement. Ca vaut le coup d’investir dedans. Si votre éditeur ne le supporte pas par défaut, il a peut être un plugin pour utiliser un linter.

    VSCode et Sublime Text ont tous deux des plugins pour Python qui permettent cela. Notamment ils peuvent exploiter l’excellent linter flake8, qui sinon peut s’utiliser à la main.

    Pour certains lignes, vous allez dépasser. Ce n’est pas la mer à boire tant que c’est un choix conscient et pas de la flemme.

    Par exemple, les commentaires avec des URLs dedans dépassent souvent. Beaucoup de linters ont un réglage pour les autoriser (ou un pattern au choix), activez le.

    Si vous avez une ligne qui dépasse et que le signalement de votre IDE/linter vous casse les couilles, il est souvent possible de le désactiver en ajoutant en fin de ligne le commentaire:

    # noqa

    Qui signifie tantôt “no question asked” ou “no quality assessment”.

  • Tuesday 18 April 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 n’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!