Nous au «Python Junior Podcast» - un podcast pour ceux qui veulent mieux comprendre Python - essayons de contribuer de toutes les manières au désir d'apprendre. Nous invitons des experts, posons des questions délicates, obtenons des conseils sur quoi et comment apprendre pour un développeur Python débutant, ou pour un non-débutant, ou pas Python - tout peut arriver.
Aujourd'hui, nous portons à votre attention une version texte de notre conversation avec Arseny Gabdullin, le développeur du magazine Tinkoff, sur le sujet de son futur rapport sur
Moscou Python Conf ++ , mais sans spoilers.
Bien que je dis toujours que les gens vont à des conférences, pas pour étudier, ils ont de nombreux avantages. Comme dans notre podcast.
La conversation a impliqué:
- Grigory Petrov, évangéliste de MoscowPython, chef du comité de programme de Moscow Python Conf ++;
- Arseny Gabdullin, développeur du magazine Tinkoff, conférencier à MoscowPython Conf ++;
- Zlata Obukhovskaya, chef d'équipe Nvidia, évangéliste MoscowPython, membre du comité de programme de Moscow Python Conf ++;
- Valentin Dombrovsky, co-organisateur et co-fondateur de MoscowPython,
Valentin Dombrovsky: Arseny, votre
rapport sans spoilers - que nous direz-vous lors de la conférence?
Comment Arseny est devenu développeur chez TJ
Arseny Gabdullin: En fait, nous parlerons avec le partenaire Vadim Goncharov, le responsable de notre développement. C'est du côté des entreprises et moi du côté du développement. Nous parlerons de la façon de réaliser des projets multimédias à l'aide de Python, de ses avantages pour les entreprises et les médias, de la façon dont nous sommes passés de WordPress à Django, de ce que nous faisons maintenant, des problèmes et du succès que nous avons rencontrés et de nos plans pour l'avenir.
Valentin Dombrovsky: Reculons d'un pas. Dites-moi ce que vous faites et comment vous êtes-vous retrouvé dans une organisation aussi merveilleuse comme Tinkoff? Qu'est-ce qui vous y a amené? Votre parcours professionnel?
Arseny Gabdullin: J'ai vécu et étudié en tant que sociologue à Saint-Pétersbourg. J'avais une étrange spécialité «informatique-sociologue» - apparemment un chercheur, mais en quelque sorte liée au développement et aux systèmes d'information pour la recherche sociale. Pendant un certain temps, je faisais des bases de données et des systèmes d'information pour soutenir les études de cas. En sociologie, Python est souvent utilisé. En même temps, j'ai fait toutes sortes de sites sur WordPress - c'est arrivé.
Sortie d'un collectif lié à WordPress
Grigory Petrov: Il n'y a rien à avoir honte. Tout se passe dans la vie.
Zlata Obukhovskaya: Oui, tout s'est passé.
Valentin Dombrovsky: Eh bien, maintenant ils diront encore que nous empoisonnons les spécialistes PHP.
Zlata Obukhovskaya: Grisha, avez-vous créé des sites WordPress?
Grigory Petrov: Bien sûr!
Zlata Obukhovskaya: Et j'ai créé des sites Web sur WordPress.
Valentin Dombrowski: Et j'ai fait des sites WordPress. Je n'ai même pas développé en Python, mais j'ai fait des sites Web dans WordPress.
Arseny Gabdullin: Oui, j'étais jeune, j'avais besoin d'argent. Puis, à un moment donné, j'ai été appelé dans l'équipe d'impartition qui a fait TJ. Ensuite, nous n'avions pas de développeurs dans l'état, tout était à distance. J'ai commencé par quelques petites tâches, puis elles sont devenues de plus en plus nombreuses. Puis à la fin ils m'ont dit - tu veux rejoindre l'équipe, à l'Etat, à Moscou? J'ai pensé et échangé Petersburg contre Tinkoff Magazine.
Valentin Dombrowski: Et puis c'était WordPress?
Arseny Gabdullin: Oui.
Valentin Dombrovsky: Autrement dit, votre migration vers Python s'est produite directement dans le processus de travail?
Arseny Gabdullin: J'ai déjà écrit en Python, mais fondamentalement, il s'agissait de systèmes sociologiques pour la science, et le développement était sur WordPress.
En 2016, T-F n'était qu'un thème WordPress. Nous avions peu d'articles, et c'était une solution parfaitement adaptée. Jusqu'à un certain point, WordPress est suffisant pour les yeux. Puis, à la fin de 2016, j'ai suggéré d'essayer de déménager à Django, car un certain nombre de problèmes s'étaient accumulés et devaient être résolus.
Expérimentez avec des conférenciers au Python Conf ++ de Moscou le plus proche
Grigory Petrov: Au fait, bien sûr, ce n'est pas habituel, vous devez d'abord tenir une conférence, puis deux mois plus tard pour recueillir les commentaires des intervenants. Noah ne peut rien y faire. Lors de cette conférence, nous menons une expérience pour la première fois -
nous préparons des conférenciers à partir de zéro . Nous n'avons pas simplement invité Arseny avec Vadim. D'abord, ils participent pour la première fois à cette expérience. Et ce sera la première fois pendant l'existence de mon système, lorsque nous l'adapterons à l'histoire de deux locuteurs en même temps.
Savez-vous à quoi ressemblent généralement les histoires de deux orateurs? C'est très triste: une personne raconte, raconte, raconte, la seconde avec une expression triste sur son visage se tient la première derrière son dos. Ensuite, ils changent à peine de place.
Tout ira mal avec nous. Arseny et Vadim transmettront parfaitement l'histoire de l'un à l'autre. Maintenant que tout est prêt, nous avons déjà tous les trois exécuté la performance. C'était amusant.
Arseny, partagez vos premières impressions de notre atelier. Ils sont, je pense, particulièrement précieux maintenant, car vous et Vadim n'avez pas encore joué. Vous êtes au milieu du voyage, mais le rapport est prêt. Comment aimez-vous l'atelier? À quel point c'était fou, compliqué, inhabituel - comment cela correspond-il à votre expérience précédente?
Arseny Gabdullin: Nous avons vraiment aimé préparer avec Vadim. Chaque fois que nous fermions l'ordinateur portable, nous pensions: "Comme c'est cool!" Une approche très sympa qu'en petites portions, mais régulière. Chaque fois que vous réalisez que vous avez fait des progrès, mais dans l'ensemble, un long chemin a déjà été parcouru.
Un système intéressant est un principe apparemment simple au cœur du discours, mais en même temps, vous comprenez immédiatement comment tout est connecté et comment cela fonctionnera à l'avenir. Bien sûr, je n'ai jamais joué avec quelqu'un sur scène. Il est intéressant d'essayer - je ne sais pas ce qui va se passer. J'espère que tout se passe bien.
Grigory Petrov: Cela se passera bien, le système n'échoue pas. Très agréable d'entendre ça. Outre Arseny et Vadim, nous avons onze autres rapports en préparation. La plupart des deux mois précédant la fin de la conférence. C'est ce que cela signifie que
je suis un réassureur paranoïaque - un mois avant la conférence, et les rapports sont prêts.Valentin Dombrovsky: Nous n'avons eu que six mois entre les conférences, la
dernière conférence
Python Conf ++ de Moscou était en octobre.
Grigory Petrov: Aujourd'hui, nous avons une sorte de petite conversation avec un haut-parleur pour notre public.
Le podcast Python Junior est positionné pour les développeurs débutants, bien que je vous dise un secret que non seulement les juniors nous écoutent.
Arseny Gabdullin: Selon les rumeurs, Guido Van Rossum a parfois regardé.
Valentin Dombrowski: Les sous
- titres en anglais incluent - très bien!
Django convient-il comme cadre médiatique en ligne en 2019
Grigory Petrov: Dites-moi, Arseny, d'après votre expérience - pour les développeurs débutants - à quel point vous êtes satisfait de Django. En effet, en principe, Django se positionnait à l'origine comme un cadre pour l'édition, c'est-à-dire les magazines. Mais c'était il y a très longtemps. Depuis, le Web a beaucoup changé et vous avez récemment commencé à utiliser Django pour Tinkoff Magazine. Dites-moi, êtes-vous déçu? Qu'est-ce que Django a aimé pour les systèmes de publication en 2016 et au-delà? Quelle est votre opinion personnelle?
Valentin Dombrovsky: En même temps, sans spoilers! Eh bien, si seulement un peu.
Arseny Gabdullin: L'année dernière, nous avons travaillé sur DevOps, nous avions une grande équipe d'ingénieurs qui font de nous des super-infrastructures directement. Ils sont généralement assez sceptiques vis-à-vis de Python, et en particulier de Django. Nous avions un ping-pong constant.
Zlata Obukhovskaya: Ils n'avaient tout simplement pas à faire le magazine eux-mêmes.
Arseny Gabdullin: Oui, au fait. Ils ont l'habitude de faire des services d'entreprise, maintenant ils font tout sur Node.js. Ils sont juste habitués à tout monter jusqu'à Node.js, mais j'en ai convaincu beaucoup que vous pouvez bien faire à la fois en Python et en Django. Mais, j'insiste, il y a beaucoup d'idées sur le blocage des requêtes - après tout, c'est la
nature synchrone de Django, qui ne peut plus être refaite . Ceci est le point culminant.
Pour ce qui est de travailler avec ORM, je pense que c'est pour les grands projets, où il y a beaucoup de relations, où tout change et où il faut avoir un framework sur lequel le domaine de données sera disposé, Django est très pratique. Nous passons maintenant à l'utilisation de Django en tant qu'API, ce à quoi il est destiné, c'est-à-dire pour distribuer des données.
Quelle est la durée de vie d'un projet de contenu sur le framework Django REST?
Zlata Obukhovskaya: Vous utilisez DRF, vous devez en parler.
Arseniy Gabdullin: Oui,
DRF est une norme de facto . Il existe un modèle Django, en plus de DRF - le bonheur (jusqu'à un certain point).
Zlata Obukhovskaya: Jusqu'à quel point?
Arseny Gabdullin: Jusqu'au moment où les relations complexes imbriquées commencent. Dans notre revue, le système de publication est complexe, mais plutôt linéaire. Nous avons fait un autre service pour la banque à Django - Tinkoff Help, qui est né du magazine. Tout y est beaucoup plus compliqué, car les concepteurs et les produits ont élaboré une hiérarchie très complexe de produits et de sections. À un moment donné, nous sommes arrivés au fait qu'il est difficile à implémenter dans REST, qu'il est difficile de sérialiser et qu'il est difficile d'assurer les performances. Vous pouvez, mais vous devez passer beaucoup de temps et proposer des mouvements non évidents pour l'optimisation.
Zlata Obukhovskaya: Autrement dit, dès que la jointure en trois étapes commence - d'accord, pas une jointure en trois étapes, mais quelque chose d'encore plus profond, c'est probablement déjà difficile.
Arseny Gabdullin: Exactement.
Zlata Obukhovskaya: Il s'avère que l'aide du projet Tinkoff serait préférable de réécrire sur une autre technologie. Avez-vous des idées à utiliser? De votre point de vue personnel?
Valentin Dombrovsky: Présentez-nous un peu, qu'est-ce que l'aide Tinkoff?
Arseniy Gabdullin: Il s'agit d'un service purement bancaire - des informations sur les produits de la banque. Mais il a longtemps vécu dans un magazine. C'était un peu absurde, car il n'a pas grand-chose à voir avec le magazine. Mais nous avions déjà une plate-forme de publication fonctionnelle, des processus de production établis et faire un service séparé à l'époque était hors de propos et hors du temps.
Valentin Dombrovsky: Autrement dit, à Tinkoff, ils ont combiné, grosso modo, un projet de contenu: le magazine et l'aide ont été réalisés sur la même plateforme.
Arseny Gabdullin: C'était une expérience. Nous avons fait Help comme une petite section dans un magazine, puis ça a grandi et il est devenu clair qu'il vivait déjà dans un magazine. Ensuite, nous l'avons amené à un service distinct.
Valentin Dombrovsky: Et vers une nouvelle plateforme technique?
Sinon Django, alors quoi
Zlata Obukhovskaya: J'ai une question: sinon Django - alors quoi? Quelles sont les alternatives?
Arseny Gabdullin: Nous aimons tous Node.js, nous avons été persuadés de faire Node.js. Nous avons refusé, il n'y a aucune envie de travailler avec des données dans Node.js. Oui, bien sûr, il y a les performances, l'asynchronie et plus encore. Mais nous allons tout de même disposer les données dans les modèles.
Zlata Obukhovskaya: Alors, le Python asynchrone se révèle?
Arseny Gabdullin: Oui, si vous voulez écrire en Python, je pense que c'est directement un salut.
Valentin Dombrowski: Ici, la question est donc - Node.js contre Python - qui battra qui. Si nous parlons des habitudes des gens, c'est une chose, mais toujours dans le cas où, qu'est-ce qui fonctionne le mieux? Grisha, Node.js ou Python asynchrone?
Grigory Petrov: C’est juste vous ...
Zlata Obukhovskaya: Ils ont pratiquement ouvert la boîte de Pandore!
À propos de l'arrière-plan du développement synchrone et asynchrone en Python
Grigory Petrov: Je l'ai dit plusieurs fois et je le dirai, car ce sont les principes de base qui sont très bien diffusés à partir du podcast PythonJunior - bonjour, jones et tout le monde!
La programmation asynchrone en général - Event Loop en Python 3.7 et en Node.js 11 - est très similaire.
Mais il y a des couches historiques. Node.js est passé de JavaScript, qui est parti du navigateur. En principe, le navigateur ne peut pas se permettre de bloquer les opérations dans JS, car sinon la page sera bloquée, elle ne défilera pas.
Nous ne pouvons pas autoriser JavaScript à bloquer le défilement de notre page que le navigateur affiche. Par conséquent, JavaScript était à l'origine sur les rappels. Nous ne pouvions pas faire quelque chose immédiatement, par exemple, ouvrir un stockage local ou une base de données. Nous pourrions démarrer l'opération, spécifier un rappel, et après un certain temps, lorsque le navigateur effectue l'opération, le rappel a été appelé. Il en a toujours été ainsi.
Quand ils sont venus avec Node.js, ce paradigme selon lequel tout est asynchrone est que les rappels sont passés de manière transparente à Node.js et fonctionnent très bien dans le paradigme asynchrone lorsqu'il y a un thread, et il y a beaucoup, beaucoup de choses de bas niveau sous le capot cette fois de temps en temps des rappels à ce rapport de thread.
Lorsque, après de nombreuses années, l'asynchronisation et l'attente sont arrivées en JavaScript, tout comme en Python, le puzzle s'est produit. Maintenant, l'application Node.js ressemble à une async-coroutine, et à l'intérieur, attendez, attendez, attendez tout ce que vous pouvez.
Python a mal tourné. Python n'était pas, à l'origine, un langage intégrable, mais un langage d'application dans lequel des systèmes finis et lancés par les utilisateurs étaient créés: concasseurs de nombres, serveurs, etc. Lorsque tous ces systèmes voulaient ouvrir un fichier, c'était une opération de blocage. Python historiquement dû au GIL était pratique pour se reproduire et se multiplier par des threads.
Si nous en Python voulions faire quelque chose en parallèle, nous avons pris un pool de threads et multiplié par des threads - il y avait du bonheur! Puis vint Event Loop.
Qu'est-ce que Python a abandonné sur le paradigme des threads en faveur de la boucle d'événement?
Pourquoi ont-ils commencé à abandonner le paradigme de flux vers EventLoop?
Il est beaucoup plus facile pour un développeur de masquer toutes les machines de blocage sous le capot et de gérer uniquement les résultats des opérations asynchrones dans un seul thread.
C'est vraiment pratique - beaucoup plus pratique que de lancer mille threads et de les attendre en même temps. De plus, les flux eux-mêmes ne sont pas gratuits, les lancer, basculer entre eux pour le système d'exploitation est un fardeau.
Lorsque Python est passé des threads à la boucle d'événements, il s'est avéré que toutes les bibliothèques existantes bloquaient. Dans Node.js, JavaScript, toutes les bibliothèques existantes étaient initialement non bloquantes, tandis qu'en Python elles étaient initialement bloquantes. Par conséquent, le merveilleux asyncio prêt à l'emploi donne essentiellement deux primitives que nous pouvons attendre: les opérations réseau et les temporisateurs.
Travaillez avec des fichiers, des bases de données, des tuyaux, des concasseurs de nombres, NumPy, le redimensionnement d'image - tout cela dans les anciennes bibliothèques synchrones. Et pour les utiliser, nous devons créer le pool de threads nous-mêmes, les lancer nous-mêmes, créer l'avenir, les replacer dans le flux avec Event Loop - en général, c'est une chose triste. De nouvelles bibliothèques fraîches comme asyncpg tentent en quelque sorte de conclure.
Python asynchrone est encore très jeune.
Il n'a pas eu un héritage aussi réussi que Node.js, et donc il n'a pas encore mûri. Cependant, la langue elle-même est très forte. Par conséquent, s'il y a une équipe de développeurs Python, même avec cette limitation de la jeunesse de la programmation asynchrone en Python, un développeur Python expérimenté sera déjà en mesure de faire une solution productive qui ne sera pas inférieure en vitesse à Node.js. Mais en même temps, étant donné que Python le sait beaucoup mieux que Node.js, la solution sera meilleure et développée plus rapidement, le code est plus propre, le support est moins cher.
Est-il difficile d'écrire à partir de zéro des solutions asynchrones en Python
Zlata Obukhovskaya: En fait, personne
n'interdit d' écrire votre propre pilote asynchrone pour un nouveau référentiel à la mode.
Grigory Petrov: Oui pour vous.
Zlata Obukhovskaya: Et qui ne le fait pas?
Grigory Petrov: Tous les développeurs sont inférieurs aux développeurs seniors. Les solutions asynchrones sont vraiment difficiles à écrire. Ils échouent dans des endroits inattendus. Arseny, dis qu'il est difficile de faire ces choses.
Arseny Gabdullin: Asynchronie? Insolite.
Zlata Obukhovskaya: Utilisez-vous l'asynchronie quelque part dans Tinkoff? Peut-être que certains gars au dîner ont raconté une histoire triste ou, au contraire, drôle sur l'utilisation de l'asynchronie?
Arseny Gabdullin: La plupart de nos services sont fournis par Node.js. Là, l'asynchronie est intégrée dans l'ADN. Nous avons également, par exemple, des services vocaux, dont beaucoup fonctionnent en Python. Pour être honnête, je ne sais pas exactement comment ils implémentent tout cela, mais je pense que l'asynchronie est obtenue grâce au multithreading. En général, dans les API hautement chargées, ce n'est plus Node.js, mais certains Scala, au moins. Et ils font des charges de travail très élevées en C ++, mais encore une fois, en plus du multi-threading.
À propos de l'outil de programmation parfait
Grigory Petrov: Il y a une chose dont j'aime parler. Le beau conte qu'il existe un outil idéal pour résoudre le problème, malheureusement, n'est qu'un conte de fées. Au fil des années, en utilisant le même langage, le framework, le développeur développe de nombreux modèles. Ces modèles augmentent considérablement sa puissance en tant que développeur, combien il peut garder les objets au point. Lorsqu'un joueur d'échecs apprend à jouer aux échecs au fil des ans, après de nombreuses années, il commence à regarder le tableau comme une combinaison de pièces familières et familières.
Si, par exemple, un développeur Python programme en Python depuis 5 à 10 ans, il peut être un développeur expérimenté, en forme de T, connu Go, Node.js, etc. Mais étant donné qu'il a une si grande expérience dans l'utilisation de Python, lui et son équipe Python écriront spécifiquement un service de plus en plus rapide qui sera plus facile à développer et à maintenir que sur Node.js et même sur Go. Tout simplement parce que l'outil familier pendant de nombreuses années offre un énorme bonus à tous les côtés de l'écriture de code.
Bien sûr, il y a des cas dégénérés - bien sûr. Mais dans le cas général, c'est le cas pour la plupart des tâches. Ou pas? Discutez avec moi.
Zlata Obukhovskaya: On peut argumenter, bien sûr, car si le développeur a une longue jambe de la lettre T, rien ne l'empêche d'écrire un code trop saturé de spécificités du langage, que personne ne comprendra plus tard. Mais il comprend - il est cool!
Grigory Petrov: Ils disent que les développeurs expérimentés, au contraire, écrivent du code simple.Zlata Obukhovskaya: La prochaine fois, nous amènerons plusieurs développeurs expérimentés de diverses technologies au studio, vous donnerons une arme et la laisserons pendant une heure.
Valentin Dombrovsky: Je suggère à chacun de lire le code de l'autre et de voir ce qui se passe. Ce sera une bataille!
Zlata Obukhovskaya: Terminons cet argument philosophique et revenons à Django. Je suis très intéressé par l'opinion d'Arseny, mais si ce n'est pas Django? À propos des choses asynchrones à forte charge, nous avons un peu compris. Et pour des tâches comme la création d'un magazine, la publication de systèmes multimédias, Django est vraiment la meilleure solution. Pourquoi pas Flask?
Valentin Dombrovsky: Était-ce le meilleur choix de votre point de vue, ou pourrait-il y avoir autre chose?
Arseny Gabdullin: Je pense que
Django est le meilleur choix pour les médias.Valentin Dombrovsky: Quelles étaient les options? Peut-être que quelque chose d'autre a été envisagé?
Arseny Gabdullin: Il y avait une option à faire sur la pile bancaire, c'est-à-dire utiliser les meilleures pratiques qui se trouvent dans la zone d'administration de Tinkoff. Il y avait une variante du framework PHP parce que nous avions PHP - pour rester dans le même paradigme. Il n'y avait pas d'options plus particulières. Mais nous voulions maintenir notre circuit, c'est-à-dire ne pas être lié au cycle de développement bancaire, car il y a toujours leurs propres caractéristiques.
Zlata Obukhovskaya: Autrement dit, si Python et les médias sont Django?
Arseny Gabdullin: Je pense que oui.
ORM résout .
Zlata Obukhovskaya: Mais il y a aussi ORM et non lié à Django.
Arseny Gabdullin: Il semblerait que oui. SQLAlchemy, par exemple.
Valentin Dombrowski: PonyORM.
Zlata Obukhovskaya: Mais le peewee est toujours utilisé dans la production.
Arseny Gabdullin: Mais
quand même, Django a été initialement développé, me semble-t-il, pour des projets aussi complexes et structurés, liés aux données, à la relation entre les données, et cela se lit directement dans l'ADN de notre modèle, dans la construction de la logique.
Spécificité du développement en banque
Grigory Petrov: Nous apprendrons le reste du rapport. Profitant de cette occasion, je veux également poser une question qui n'est pas liée à Python.
Notre société a tendance à romantiser des institutions très réglementées comme, par exemple, le gouvernement, la médecine et la banque: «Bank?! L'argent est là! Il y a probablement des mitrailleurs à l'entrée, un système d'accès à quatre niveaux, l'œil de Sauron est installé sur le toit », etc. Pour vous, en tant que développeur qui a précédemment travaillé dans une banque, puis a commencé à travailler dans une banque, y a-t-il une spécificité de travailler dans une banque?
Ici, en passant, il est heureux que vous ne travailliez pas sur le noyau financier réglementé, mais sur les services d'infrastructure connexes. Donc, en dehors du développement de base, le travail à la banque a-t-il des détails amusants, ou est-ce juste une entreprise informatique ordinaire, uniquement au lieu des likes sur les réseaux sociaux, fonctionnons-nous avec de l'argent?
: , - , IT- .
: vc.ru, , , , . , -, - .., . . .
IT- ?
: . , , . .
Moscow Python Conf ++
: , Moscow Python Conf ++ , , . ? ? ?
: — . , : « , , PostgreSQL 10 ».
— - -, , . , , .
: ? , - , - , ?
: , . , , .
: , Django — !
: Django.
: , , Django — . .
: , .
: , 24 , Python Core Developer, , - . , .
: Moscow Python Conf++.
: Python- 5 . . , , . Venez!