En el "Python Junior Podcast", un podcast para aquellos que quieren comprender mejor Python, intentamos contribuir de todas las formas al deseo de aprender. Invitamos a expertos, hacemos preguntas difíciles, obtenemos consejos sobre qué y cómo aprender para un desarrollador principiante de Python, o para un no principiante, o no Python: cualquier cosa puede suceder.
Hoy traemos a su atención una versión de texto de nuestra conversación con Arseny Gabdullin, el desarrollador de la revista Tinkoff, sobre el tema de su futuro informe sobre
Moscow Python Conf ++ , pero sin spoilers.
Aunque siempre digo que las personas van a conferencias, no a estudiar, tienen muchos beneficios. Como en nuestro podcast.
La conversación involucró:
- Grigory Petrov, evangelista de MoscowPython, jefe del comité de programa de Moscow Python Conf ++;
- Arseny Gabdullin, desarrollador de la revista Tinkoff, ponente en MoscowPython Conf ++;
- Zlata Obukhovskaya, líder del equipo Nvidia, evangelista MoscowPython, miembro del comité de programa de Moscow Python Conf ++;
- Valentin Dombrovsky, coorganizador y cofundador de MoscowPython,
Valentin Dombrovsky: Arseny, su
informe sin spoilers, ¿qué nos dirá en la conferencia?
Cómo Arseny se convirtió en desarrollador en TJ
Arseny Gabdullin: De hecho, hablaremos junto con su socio Vadim Goncharov, el jefe de nuestro desarrollo. Es del lado de los negocios, y yo del lado del desarrollo. Hablaremos sobre cómo hacer proyectos de medios usando Python, qué beneficios brinda a las empresas y los medios, cómo nos mudamos de WordPress a Django, qué estamos haciendo ahora, qué problemas y éxito tuvimos y cuáles son nuestros planes para el futuro.
Valentin Dombrovsky: Retrocedamos un paso. Dime qué haces y cómo terminaste en una organización tan maravillosa como Tinkoff. ¿Qué te trajo allí? ¿Tu camino profesional?
Arseny Gabdullin: Viví y estudié como sociólogo en San Petersburgo. Tenía una extraña especialidad: "Sociólogo informático", aparentemente un investigador, pero conectado de alguna manera con el desarrollo y con los sistemas de información para la investigación social. Durante un tiempo estuve haciendo bases de datos y sistemas de información para apoyar estudios de casos. En sociología, Python se usa a menudo. Al mismo tiempo, hice todo tipo de sitios en WordPress, sucedió.
Lanzamiento del colectivo relacionado con WordPress
Grigory Petrov: No hay nada de qué avergonzarse. Todo pasa en la vida.
Zlata Obukhovskaya: Sí, todo sucedió.
Valentin Dombrovsky: Bueno, ahora volverán a decir que estamos envenenando a especialistas en PHP.
Zlata Obukhovskaya: Grisha, ¿creaste sitios de WordPress?
Grigory Petrov: ¡ Por supuesto!
Zlata Obukhovskaya: Y
creé sitios web en WordPress.
Valentin Dombrowski: E hice sitios de WordPress. Ni siquiera desarrollé en Python, pero hice sitios web en WordPress.
Arseny Gabdullin: Sí, era joven, necesitaba dinero. Luego, en algún momento, me llamaron al equipo de outsourcing que hizo TJ. Entonces no teníamos desarrolladores en el estado, todo era remoto. Comencé con algunas tareas pequeñas, luego se hicieron más y más. Luego, al final, me dijeron: ¿quieres unirte al equipo, al estado, a Moscú? Pensé y cambié a Petersburg por la revista Tinkoff.
Valentin Dombrowski: ¿ Y luego fue WordPress?
Arseny Gabdullin: Sí.
Valentin Dombrovsky: ¿ Es decir, su migración a Python ocurrió directamente en el proceso de trabajo?
Arseny Gabdullin: Escribí antes en Python, pero básicamente eran sistemas sociológicos para la ciencia, y el desarrollo estaba en WordPress.
En 2016, T - F era solo un tema de WordPress. Teníamos pocos artículos y era una solución perfecta. Hasta cierto punto, WordPress es suficiente para los ojos. Luego, a fines de 2016, sugerí intentar mudarme a Django, porque se habían acumulado varios problemas que debían abordarse.
Experimente con altavoces en el más cercano Moscow Python Conf ++
Grigory Petrov: Por cierto, por supuesto, esto no es habitual, primero debe celebrar una conferencia, luego dos meses después para recopilar comentarios de los oradores. Noah no puede evitarlo. En esta conferencia, estamos llevando a cabo un experimento por primera vez,
estamos preparando oradores desde cero . No solo invitamos a Arseny junto con Vadim. Primero, participan por primera vez en este experimento. Y esta será la primera vez durante la existencia de mi sistema, cuando lo adaptemos para la historia de dos oradores al mismo tiempo.
¿Sabes cómo son las historias de dos oradores? Es muy triste: una persona cuenta, cuenta, cuenta, la segunda con una expresión triste en su rostro se encuentra en la primera detrás de su espalda. Entonces apenas cambian de lugar.
Todo estará mal con nosotros. Arseny y Vadim transmitirán sin problemas la historia de uno a otro. Ahora todo está listo, los tres ya hemos ejecutado el rendimiento. Fue divertido
Arseny, comparte tus primeras impresiones de nuestro taller. Ellos, creo, son especialmente valiosos ahora, porque usted y Vadim aún no han actuado. Estás en medio del viaje, pero el informe está listo. ¿Qué te parece el taller? ¿Qué tan loco, complicado e inusual fue esto? ¿Cómo encaja esto con su experiencia previa?
Arseny Gabdullin: Realmente disfrutamos preparándonos con Vadim. Cada vez que cerramos la computadora portátil, pensamos: "¡Qué bueno!" Un enfoque muy genial que en pequeñas porciones, pero regular. Cada vez que te das cuenta de que has progresado, pero en general ya se ha recorrido un largo camino.
Un sistema interesante es un principio aparentemente simple en el corazón del discurso, pero al mismo tiempo comprende de inmediato cómo está conectado todo y cómo funcionará en el futuro. Por supuesto, nunca actué junto a alguien en el escenario. Es interesante intentarlo, no sé qué resultará. Espero que todo salga bien.
Grigory Petrov: Saldrá bien, el sistema no falla. Muy agradable escuchar eso. Además de Arseny y Vadim, tenemos once informes más en preparación. La mayoría de los dos meses anteriores a la finalización de la conferencia. Eso es lo que significa que
soy una reaseguradora paranoica, un mes antes de la conferencia, y los informes están listos.Valentin Dombrovsky: Solo tuvimos medio año entre las conferencias, la
última Moscú Python Conf ++ fue en octubre.
Grigory Petrov: Hoy tenemos una especie de pequeña conversación con un orador para nuestra audiencia.
El podcast Python Junior está posicionado para desarrolladores principiantes, aunque les diré un secreto que no solo los junior nos están escuchando.
Arseny Gabdullin: Según los rumores, Guido Van Rossum a veces miraba.
Valentin Dombrowski: Los subtítulos en inglés incluyen: ¡muy bien!
¿Es Django adecuado como marco de medios en línea en 2019?
Grigory Petrov: Dime, Arseny, por tu experiencia, para desarrolladores principiantes, cuán satisfecho estabas con Django. De hecho, en principio, Django se posicionó originalmente como un marco para el negocio editorial, es decir, las revistas. Pero eso fue hace mucho tiempo. La web ha cambiado mucho desde entonces, y recientemente comenzó a usar Django para la revista Tinkoff. Dime, ¿estás decepcionado? ¿Qué le gustó a Django para los sistemas de publicación en 2016 y más allá? ¿Cuál es tu opinión personal?
Valentin Dombrovsky: ¡ Al mismo tiempo, sin spoilers! Bueno, aunque sea un poco.
Arseny Gabdullin: El año pasado trabajamos en DevOps, tuvimos un gran equipo de ingenieros que nos hicieron super-infraestructura directamente. En general, son bastante escépticos con Python, y en particular con Django. Teníamos un ping pong constante.
Zlata Obukhovskaya: Simplemente no tenían que hacer la revista ellos mismos.
Arseny Gabdullin: Sí, por cierto. Están acostumbrados a hacer servicios empresariales, ahora están haciendo todo en Node.js. Simplemente están acostumbrados a subir todo a Node.js, pero he convencido a muchos de que puedes hacerlo bien tanto en Python como en Django. Pero, enfatizo, hay muchas ideas sobre el bloqueo de solicitudes; después de todo, esta es la
naturaleza sincrónica de Django, que no se puede rehacer . Este es el punto culminante.
En términos de trabajar con ORM, creo que esto es para grandes proyectos, donde hay muchas relaciones, donde todo cambia y necesita tener un marco en el que se establecerá el dominio de datos, Django es muy conveniente. Ahora estamos pasando a usar Django como API, que es para lo que está destinado, es decir, para distribuir datos.
¿Cuánto tiempo dura un proyecto de contenido en Django REST Framework?
Zlata Obukhovskaya: Usas DRF, necesitas hablar de eso.
Arseniy Gabdullin: Sí,
DRF es un estándar de facto . Hay un modelo de Django, además de DRF: felicidad (hasta cierto punto).
Zlata Obukhovskaya: ¿Hasta qué punto?
Arseny Gabdullin: Hasta el momento en que comienzan las complejas relaciones anidadas. En nuestra revista, el sistema de publicación es complejo, pero bastante lineal. Hicimos otro servicio para el banco en Django: Tinkoff Help, que surgió de la revista. Todo es mucho más complicado allí, porque los diseñadores y productos han creado una jerarquía muy compleja de productos y secciones. En algún momento, se nos ocurrió el hecho de que es difícil de implementar en REST, es difícil de serializar y es difícil garantizar el rendimiento. Puede, pero necesita pasar mucho tiempo y encontrar movimientos no obvios para la optimización.
Zlata Obukhovskaya: Es decir, tan pronto como comience una unión de tres pasos, está bien, no una unión de tres pasos, pero algo aún más profundo, probablemente ya sea difícil.
Arseny Gabdullin: Exactamente.
Zlata Obukhovskaya: Resulta que la ayuda del proyecto Tinkoff sería mejor reescribir a otra tecnología. ¿Alguna idea de lo que podría usarse? Desde su punto de vista personal?
Valentin Dombrovsky: Preséntanos un poco, ¿qué es la ayuda de Tinkoff?
Arseniy Gabdullin: Este es un servicio puramente bancario: información sobre los productos del banco. Pero durante mucho tiempo vivió dentro de una revista. Fue un poco absurdo, porque tiene poco que ver con la revista. Pero ya teníamos una plataforma de publicación en funcionamiento, procesos de producción establecidos y hacer un servicio separado en ese momento estaba fuera de lugar y fuera de tiempo.
Valentin Dombrovsky: Es decir, de hecho, en Tinkoff combinaron, en términos generales, un proyecto de contenido: la revista y la ayuda se hicieron en la misma plataforma.
Arseny Gabdullin: Fue un experimento. Ayudamos como una pequeña sección en una revista, y luego creció, y quedó claro que ya estaba viviendo en una revista. Luego lo llevamos a un servicio separado.
Valentin Dombrovsky: ¿ Y a una nueva plataforma técnica?
Si no es Django, entonces qué
Zlata Obukhovskaya: Tengo una pregunta: si no es Django, ¿entonces qué? Cuales son las alternativas?
Arseny Gabdullin: Todos amamos a Node.js, fuimos persuadidos para hacer Node.js. Nos negamos, no hay deseo de trabajar con datos en Node.js. Sí, por supuesto que hay rendimiento, asincronía y más. Pero sigamos presentando los datos en los modelos.
Zlata Obukhovskaya: ¿ Entonces resulta Python asincrónico?
Arseny Gabdullin: Sí, si quieres escribir en Python, creo que esto es directamente una salvación.
Valentin Dombrowski: Aquí la pregunta es: Node.js versus Python, quién vencerá a quién. Si hablamos de los hábitos de las personas, esto es una cosa, pero aún en uso, ¿dónde funciona mejor? Grisha, Node.js o Python asíncrono?
Grigory Petrov: Eres solo ...
Zlata Obukhovskaya: ¡Abrieron la caja de Pandora prácticamente!
Sobre el trasfondo del desarrollo sincrónico y asincrónico en Python
Grigory Petrov: Lo he dicho varias veces y lo diré, porque estos son los principios básicos que son muy buenos para transmitir desde el podcast PythonJunior: ¡hola, jones y todos los demás!
La programación asincrónica en general (Event Loop en Python 3.7 y en Node.js 11) es muy similar.
Pero hay capas históricas. Node.js pasó de JavaScript, que pasó del navegador. En principio, el navegador no puede permitirse el bloqueo de operaciones en JS, porque de lo contrario la página se bloqueará, no se desplazará.
No podemos permitir que JavaScript bloquee el desplazamiento de nuestra página que muestra el navegador. Por lo tanto, JavaScript estaba originalmente en devoluciones de llamada. No podríamos hacer algo allí de inmediato, por ejemplo, abrir algún almacenamiento local o una base de datos. Podríamos comenzar la operación, especificar una devolución de llamada, y después de un tiempo, cuando el navegador realiza la operación, se llama la devolución de llamada. Siempre ha sido así.
Cuando se les ocurrió Node.js, entonces este paradigma de que todo es asíncrono son devoluciones de llamada sin interrupciones a Node.js y funcionaron muy bien en el paradigma asíncrono cuando hay un hilo y hay muchas, muchas cosas de bajo nivel en ese momento. de vez en cuando devoluciones de llamada a este informe de hilo.
Cuando, después de muchos años, llegó a JavaScript asíncrono y en espera, al igual que en Python, ocurrió el rompecabezas. Ahora la aplicación Node.js parece una rutina asíncrona, y dentro espera, espera, espera todo lo que puedas.
Python salió mal. Python originalmente no era un elemento embebible, sino un lenguaje de aplicación en el que se creaban sistemas completos ejecutados por el usuario: trituradoras de números, servidores, etc. Cuando todos estos sistemas querían abrir un archivo, era una operación de bloqueo. Python históricamente debido al GIL fue conveniente para reproducirse y multiplicarse por hilos.
Si en Python queríamos hacer algo en paralelo, tomamos un grupo de hilos y los multiplicamos por hilos: ¡había felicidad! Luego vino Event Loop.
¿Qué renunció Python en el paradigma del hilo a favor de Event Loop?
¿Por qué comenzaron a abandonar el paradigma de flujo hacia EventLoop?
Es mucho más fácil para un desarrollador ocultar toda la maquinaria de bloqueo debajo del capó y administrar solo los resultados de las operaciones asincrónicas en un hilo.
Esto es realmente conveniente, mucho más conveniente que lanzar miles de hilos y esperarlos al mismo tiempo. Además, las transmisiones en sí mismas no son gratuitas, lanzarlas y cambiarlas por el sistema operativo es una carga.
Cuando Python se movió de los hilos a Event Loop, resultó que todas las bibliotecas existentes estaban bloqueadas. En Node.js, JavaScript, todas las bibliotecas existentes inicialmente no se bloqueaban, mientras que en Python se bloquearon inicialmente. Por lo tanto, el maravilloso asincio fuera de la caja ofrece esencialmente dos primitivas que podemos esperar: operaciones de red y temporizadores.
Trabaje con archivos, bases de datos, tuberías, trituradoras de números, NumPy, cambio de tamaño de imagen, todo esto en antiguas bibliotecas síncronas. Y para usarlos, necesitamos crear el grupo de subprocesos nosotros mismos, iniciarlos nosotros mismos, hacer el futuro, arrojarlos nuevamente a la transmisión con Event Loop; en general, es algo triste. Las bibliotecas nuevas y nuevas como asyncpg de alguna manera están tratando de concluir esto.
Python asíncrono todavía es muy joven.
No tuvo una herencia tan exitosa como Node.js, y por lo tanto aún no ha madurado. Sin embargo, el lenguaje en sí es muy fuerte. Por lo tanto, si hay un equipo de desarrolladores de Python, incluso teniendo esta limitación de la juventud de la programación asíncrona en Python, un desarrollador experimentado de Python ya podrá hacer una solución productiva que no será inferior en velocidad a Node.js. Pero al mismo tiempo, debido a que Python lo sabe mucho mejor que Node.js, la solución será mejor y se desarrollará más rápido, el código es más limpio, el soporte es más barato.
¿Es difícil escribir soluciones asincrónicas en Python desde cero?
Zlata Obukhovskaya: De hecho, nadie prohíbe escribir su propio controlador asincrónico para un nuevo repositorio de moda.
Grigory Petrov: Sí a ti.
Zlata Obukhovskaya: ¿ Y quién no?
Grigory Petrov: Cualquier desarrollador es más bajo que los desarrolladores senior. Las soluciones asincrónicas son realmente difíciles de escribir. Fallan en lugares inesperados. Arsenio, di que es difícil hacer estas cosas.
Arseny Gabdullin: ¿Asincronía? Inusual
Zlata Obukhovskaya: ¿
Utilizas la asincronía en algún lugar de Tinkoff? ¿Quizás algunos chicos en la cena contaron una historia triste o, por el contrario, divertida sobre el uso de la asincronía?
Arseny Gabdullin: La mayoría de nuestros servicios funcionan con Node.js. Allí, la asincronía está incrustada en el ADN. También tenemos, por ejemplo, servicios de voz, muchos de los cuales funcionan en Python. Para ser honesto, no sé exactamente cómo implementan todo esto, pero creo que la asincronía se logra a través de subprocesos múltiples. En general, en API altamente cargadas, ya no es Node.js, sino algunos Scala, al menos. Y están haciendo cargas de trabajo muy altas en C ++, pero nuevamente, más subprocesos múltiples.
Sobre la herramienta de programación perfecta
Grigory Petrov: Hay una cosa de la que me gusta hablar. La bella historia de que existe una herramienta ideal para resolver el problema, desafortunadamente, es solo un cuento de hadas. Con los años, usando el mismo lenguaje, el framework, el desarrollador desarrolla muchos patrones. Estos patrones amplían enormemente su poder como desarrollador, cuánto puede mantener los objetos enfocados. Cuando un jugador de ajedrez aprende a jugar ajedrez a lo largo de los años, después de muchos años comienza a mirar el tablero como una combinación de piezas familiares y familiares.
Si, por ejemplo, un desarrollador de Python ha estado programando en Python durante 5-10 años, puede ser un desarrollador experimentado, en forma de T, know Go, Node.js, etc. Pero debido al hecho de que tiene una gran experiencia en el uso de Python, él específicamente y su equipo de Python escribirán un servicio cada vez más rápido, que será más fácil de desarrollar y mantener que en Node.js e incluso en Go. Solo porque la herramienta familiar durante muchos años brinda una gran ventaja a todos los lados de la escritura de códigos.
Por supuesto, hay casos degenerados, por supuesto. Pero en el caso general, para la mayoría de las tareas esto es así. O no? Discute conmigo.
Zlata Obukhovskaya: Esto se puede argumentar, por supuesto, porque si el desarrollador tiene una pierna larga de la letra T, nada le impide escribir un código que esté demasiado saturado con características específicas del lenguaje, que nadie entenderá más adelante. Pero él entiende: ¡es genial!
Grigory Petrov: Dicen que los desarrolladores experimentados, por el contrario, escriben código simple.Zlata Obukhovskaya: La próxima vez llevaremos al estudio a varios desarrolladores experimentados de diversas tecnologías, le daremos un arma y la dejaremos durante una hora.
Valentin Dombrovsky: Sugiero que cada uno lea el código del otro y vea qué sucede. ¡Será una batalla!
Zlata Obukhovskaya: Terminemos este argumento filosófico y regresemos a Django. Estoy muy interesado en la opinión de Arseny, pero ¿y si no es Django? Sobre cosas asincrónicas de alta carga entendimos un poco. Y para tareas como hacer una revista, publicar sistemas de medios, Django es realmente la mejor solución. ¿Por qué no matraz?
Valentin Dombrovsky: ¿Fue esta la mejor opción desde su punto de vista, o podría haber algo más?
Arseny Gabdullin: Creo que
Django es la mejor opción para los medios.Valentin Dombrovsky: ¿Cuáles fueron las opciones? Quizás algo más fue considerado?
Arseny Gabdullin: Había una opción para hacer en la pila del banco, es decir, usar las mejores prácticas que están en el área de administración de Tinkoff. Había una variante del marco PHP porque teníamos PHP: permanecer en el mismo paradigma. No había más opciones particulares. Pero queríamos mantener nuestro circuito, es decir, no estar atados al ciclo de desarrollo bancario, ya que todavía tienen sus propias características.
Zlata Obukhovskaya: Es decir, si Python y los medios son Django?
Arseny Gabdullin: Creo que sí.
ORM resuelve .
Zlata Obukhovskaya: Pero también hay ORM y no está relacionado con Django.
Arseny Gabdullin: Parece que sí. SQLAlchemy, por ejemplo.
Valentin Dombrowski: PonyORM.
Zlata Obukhovskaya: Pero el peewee todavía se usa en la producción.
Arseny Gabdullin: Pero aún así, Django se desarrolló inicialmente, me parece, para proyectos tan complejamente estructurados, vinculados a los datos, a la relación entre los datos, y esto se lee directamente en el ADN de nuestro modelo, en la construcción de la lógica.
Especificidad de desarrollo en el banco
Grigory Petrov: El resto lo aprenderemos del informe. Aprovechando esta oportunidad, también quiero hacer una pregunta que no esté relacionada con Python.
En nuestra sociedad, hay una tendencia a romantizar instituciones tan altamente reguladas como, por ejemplo, el gobierno, la medicina, el banco: “¡¿Banco ?! ¡El dinero está ahí! Probablemente haya ametralladoras en la entrada, un sistema de acceso de cuatro niveles, el ojo de Sauron está instalado en el techo ", etc. Para usted, como desarrollador que anteriormente trabajó en un banco y luego comenzó a trabajar en un banco, ¿hay alguna especificidad de trabajar en un banco?
Aquí, por cierto, es una suerte que no esté trabajando en el núcleo financiero que está regulado, sino en los servicios de infraestructura relacionados. Entonces, fuera del desarrollo central, ¿el trabajo en el banco tiene detalles divertidos, o es solo una compañía de TI común, pero en lugar de gustos en la red social, operamos con dinero?
: , - , IT- .
: vc.ru, , , , . , -, - .., . . .
IT- ?
: . , , . .
Moscow Python Conf ++
: , Moscow Python Conf ++ , , . ? ? ?
: — . , : « , , PostgreSQL 10 ».
— - -, , . , , .
: ? , - , - , ?
: , . , , .
: , Django — !
: Django.
: , , Django — . .
: , .
: , 24 , Python Core Developer, , - . , .
: Moscow Python Conf++.
: Python- 5 . . , , . Ven