PROJET AUTOBLOG


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

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

⇐ retour index

La télé crève et veut emporter Internet dans la tombe

jeudi 10 juillet 2014 à 10:22

Ça parle ici et là de ‘la neutralité du net’ et franchement beaucoup de gens n’en ont rien à foutre.

Admettons.

Mais la question n’a pas besoin d’être prise de tête.

Les boites qui fournissent l’accès à Internet veulent faire payer plus les services qui “consomment” le plus. Ils décorent ça en disant qu’ils veulent donner un accès “prioritaire” ou “plus rapide” à ceux qui paieront plus.

Schéma montrant que Youtube a un gros trafic

Ce qu'on essaye de faire gober aux gens

Mais il y a une arnaque.

CE NE SONT PAS LES SERVICES QUI CONSOMMENT INTERNET

C’est vous.

Et vous payez déjà un abonnement qu’on vous a vendu comme illimité. Ce que vous faites de cet abonnement n’est pas le problème de ces boîtes. Que vous passiez votre temps sur youtube, facebook, LOL, wikipedia, IRC ou sametmax, c’est pareil.

Vous utilisez le débit maximum pour lequel vous payez, et l’accumulation de tous ces abos paie pour le trafic utilisé. Si beaucoup utilisent youtube, il y a plus de trafic vers youtube, mais il y a beaucoup d’abos payés de toute manière qui financent ce trafic.

D'où vient le débit de youtube

La somme des débits est proportionelle à la somme des abonnements payés

Quand on envoie une lettre, on paie le prix du timbre en fonction du poids de sa lettre et de sa destination. Pas en fonction du nombre de lettres que le destinataire reçoit tous les jours. Parceque si il y a beaucoup de lettres, il y a beaucoup de timbres, donc c’est payé.

Bref, c’est une entube.

Une entube qui a été dernièrement défendue par le CSA, organisme détestable s’il en est, mais que je croyais hors sujet. En fait pas du tout, la raison est très simple : la télévision est en train de crever, et ils essayent de ralentir l’agonie en mettant des bâtons dans les roues de la concurrence en ligne.

Après l’industrie du disque, les grosses boîtes d’édition et la presse, c’est donc le dinaurorus télétus qui se rend compte qu’il est en voie d’extinction. Et comme tous les autres depuis 20 ans, au lieu de se remettre en question et sauver son cul, il s’accroche à ses rides et fait caca partout.

Bonne chance, maintenant qu’il y a des mobiles dans tous les foyers, pour bloquer la nouvelle génération devant un écran dans le salon à une heure précise. Avec tout le pognon qu’ils ont, la mort sera lente, et chiante pour tout le monde. J’espère néanmoins qu’elle se fera dans beaucoup de souffrances. Pour eux.

flattr this!

Quel niveau peut-on exiger à l’embauche en Python ?

mardi 8 juillet 2014 à 09:19

J’ai répondu récemment à une question sur le niveau qu’on pouvait attendre d’un professionnel en Python. La réponse était en anglais, alors je me fends d’une petite traduction ici.

Cela dépend beaucoup du niveau Python dont la boîte a besoin, et s’ils accordent plus d’importance à celui-ci ou à ta capacité générale à résoudre des problèmes et tes connaissances générales informatiques.

Pour répondre à ta question, je vais ignorer ces deux points puisqu’ils ne sont pas particulièrement liés à Python. Il y a plein d’articles de blog sur ces sujets sur le Web.

En Python, un dev standard devrait :

  • être capable d’écrire du code Pythonique (style idiomatique, syntaxe PEP8…).
  • connaître la stdlib et l’écosystème de Python. Par exemple n’avoir aucun problème avec pip, virtualenv, datetime, os.path, hashlib, uuid, csv, pdb, json, et toutes les collections y compris celles qu’il y a dans le module éponyme ou les sets.
  • connaître les bases de la POO. L’héritage, l’overloading, les propriétés, la composition, etc.

Un développeur Python avancé devrait être capable d’écrire des libs agréables, et donc :

  • être à l’aise avec les générateurs et yield.
  • pouvoir écrire son propre décorateur.
  • pouvoir écrire son propre context manager.
  • pouvoir écrire son propre descripteur.
  • savoir gérer l’héritage multiple, l’injection de dépendance, etc.
  • pouvoir faire une lib de A à Z, incluant un API flexible et extensible, le packaging et la documentation.
  • savoir mettre en place des tests unitaires.

Un expert Python devrait :

  • connaître la plupart des libs tierces parties et frameworks pour la plupart des tâches, leurs qualités et leurs défauts.
  • pouvoir créer sa propre métaclasse.
  • être à l’aise avec l’introspection.
  • savoir contourner la plupart des faiblesses de Python : le GIL, les API bloquantes, créer soit-même un code non bloquant, créer un code compatible V2 et V3, etc.
  • être capable de prendre un projet sans doc, lire le code source, trouver son problème, et le résoudre via monkey patch tout en proposant un patch propre upstream.
  • savoir utiliser des modules difficiles ou peu connus comme heapq, inspect, nmap, etc.

Selon ton domaine, tu auras également peut-être besoin d’être capable :

  • de gérer plusieurs implémentations de Python.
  • d’écrire une extension C.
  • de maîtriser des libs spécifiques comme numpy, scrapy, opencv, etc.

Vous noterez que je n’ai pas mis des évidences comme savoir faire une fonction ou une boucle for. Évidemment qu’il faut savoir écrire du code basique sinon on ne sert à rien.

Gardez aussi en tête que chaque entreprise est différente, et donc peut avoir des besoins qui se situent n’importe où dans l’échelle ci-dessus.

Mais surtout, les connaissances dans un langage, bien qu’importantes, ne sont pas la priorité. Un langage, ça s’apprend. Être une personne qui résout les problèmes, communique, travaille bien en équipe et satisfait les clients, c’est plus difficile à former.

Par ailleurs, il n’existe pas de job avec juste du Python. Un dev backend devrait sans doute aussi travailler avec une base de données, faire du sys admin ou du réseau. Un dev d’UI devra gérer des problématiques multi-plateformes, de l’ergonomie, du packaging avancé. Un dev scientifique devra peut-être écrire du C ou du Fortran. Un dev Web est tenu de gérer le JS/CSS/HTML. Et il y a aussi les outils autour : bug tracking, versioning, peer review, etc.

Bref, dire seulement “je suis bon en Python” ne suffit pas à convaincre quelqu’un qu’il doit vous embaucher.

flattr this!

Oblitérer un fichier de l’historique Git

lundi 7 juillet 2014 à 15:24

Si vous avez commité votre clé privée dans un repo, il existe un moyen de la dégommer de l’historique.

ATTENTION, CECI EST UNE OPERATION DANGEREUSE.

git filter-branch -f --index-filter "git rm -r --cached --ignore-unmatch chemin/vers/fichier" --prune-empty --tag-name-filter cat -- --all

Si le fichier a été dans plusieurs endroits durant sa vie, il faut relancer la commande pour chaque chemin.

Puis :

git push remote branch --force

Cette seconde commande est à lancer pour chaque branche et chaque tag concerné.

Comme tout ce qui change l’historique, il faut que tous les autres repos appliquent aussi cette opération.

Tous vos collègues devront, soit appliquer eux aussi “filter-branch”, soit faire un rebase de toutes les branches basées sur celles modifiées par vous.

La commande peut prendre pas mal de temps à tourner. L’opération totale avec syncro entre collègues, je ne vous en parle pas. Et si vous foirez une étape, je vous garantis que ça va être la merde.

Mais c’est possible, en cas d’extrême urgence.

Pour se simplifier la tâche, il existe un petit soft spécialisé pour ça qui est bien plus rapide et avec moins de risques.

Mais ça reste dangereux, donc mollo.

flattr this!

Little things

samedi 5 juillet 2014 à 06:04
Terminer un stylo bic ou une gomme.

Éclater du papier bulle. Dont quelqu’un a besoin.

Passer une porte en train de se fermer sans la toucher.

Connecter un périphérique USB dans le bon sens d’un seul coup.

Vider une bouteille et remplir pile poil un verre avec. Ni trop, ni pas assez.

Marcher uniquement sur les bandes blanches du passage clouté sans changer de rythme.

Avoir un ascenseur qui s’ouvre et se ferme exactement calqué sur la basse du morceau qu’on écoute.

Coder un snippet d’une traite, sans regarder la doc, et l’exécuter pour voir que ça marche exactement comme prévu.

Mais dans notre métier, rien ne bat le sentiment jubilatoire de gagner 5 secondes en utilisant les raccourcis de son éditeur.

flattr this!

Le merci du jour

jeudi 3 juillet 2014 à 03:30

Régulièrement je relis les commentaires et je me dis qu’on a quand même un public en or.

Alors, je me repète, mais merci.

On a peu de trolls ou de connards.

On a des relecteurs qu’ils sont cool.

Et je note aussi la patience que vous avez à me corriger quand j’écris des conneries. Avec beaucoup de politesse et de cordialité. Et pas juste pour les typos.

J’apprécie également les débats qu’on peut avoir, qui peuvent monter en sauce sans jamais exploser.

Merci, donc.

flattr this!