Ç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.

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.

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.

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.

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.

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.