Nós, no “Python Junior Podcast” - um podcast para quem quer entender melhor o Python - tentamos contribuir de todas as formas para o desejo de aprender. Convidamos especialistas, fazemos perguntas complicadas, obtemos dicas sobre o que e como aprender para um desenvolvedor iniciante em Python, ou para um iniciante ou não para Python - tudo pode acontecer.
Hoje, chamamos a atenção para você em uma versão em texto de nossa conversa com Arseny Gabdullin, desenvolvedor da revista Tinkoff, sobre o tópico de seu futuro relatório sobre o
Moscow Python Conf ++ , mas sem spoilers.
Embora eu sempre diga que as pessoas vão a conferências, não estudam, há muitos benefícios para elas. Como no nosso podcast.
A conversa envolveu:
- Grigory Petrov, evangelista do MoscowPython, chefe do comitê de programa do Moscow Python Conf ++;
- Arseny Gabdullin, desenvolvedor da revista Tinkoff, palestrante no MoscowPython Conf ++;
- Zlata Obukhovskaya, líder da equipe Nvidia, evangelista MoscowPython, membro do comitê de programa do Moscow Python Conf ++;
- Valentin Dombrovsky, co-organizador e co-fundador do MoscowPython,
Valentin Dombrovsky: Arseny, seu
relatório sem spoilers - o que você nos dirá na conferência?
Como Arseny se tornou desenvolvedor da TJ
Arseny Gabdullin: De fato, falaremos em conjunto com o parceiro Vadim Goncharov, o chefe do nosso desenvolvimento. É do lado comercial e eu do lado do desenvolvimento. Falaremos sobre como realizar projetos de mídia usando Python, quais benefícios ele oferece aos negócios e à mídia, como mudamos do WordPress para o Django, o que estamos fazendo agora, quais problemas e sucesso tivemos e quais são nossos planos para o futuro.
Valentin Dombrovsky: Vamos dar um passo para trás. Diga-me o que você faz e como você terminou em uma organização tão maravilhosa como a Tinkoff? O que te trouxe lá? O seu caminho profissional?
Arseny Gabdullin: Eu vivi e estudei como sociólogo em São Petersburgo. Eu tinha uma estranha especialidade “sociólogo da informática” - aparentemente um pesquisador, mas de alguma forma conectado com o desenvolvimento e com sistemas de informação para pesquisa social. Durante algum tempo, eu estava criando bancos de dados e sistemas de informação para apoiar estudos de caso. Na sociologia, o Python é frequentemente usado. Ao mesmo tempo, criei todos os tipos de sites no WordPress - aconteceu.
Coletivo relacionado ao WordPress saindo
Grigory Petrov: Não há nada para se envergonhar. Tudo acontece na vida.
Zlata Obukhovskaya: Sim, tudo aconteceu.
Valentin Dombrovsky: Bem, agora eles dirão novamente que estamos envenenando especialistas em PHP.
Zlata Obukhovskaya: Grisha, você criou sites WordPress?
Grigory Petrov: Claro!
Zlata Obukhovskaya: E eu
criei sites no WordPress.
Valentin Dombrowski: E eu fiz sites WordPress. Eu nem desenvolvi em Python, mas desenvolvi sites no WordPress.
Arseny Gabdullin: Sim, eu era jovem, precisava de dinheiro. Então, em algum momento, fui chamado para a equipe de terceirização que fazia TJ. Então não tínhamos desenvolvedores no estado, tudo era remoto. Comecei com algumas pequenas tarefas, depois elas se tornaram cada vez mais. Então, no final, eles me disseram - você quer se juntar à equipe, ao estado, a Moscou? Pensei e troquei Petersburg pela Revista Tinkoff.
Valentin Dombrowski: E então era o WordPress?
Arseny Gabdullin: Sim.
Valentin Dombrovsky: Ou seja, sua migração para o Python aconteceu diretamente no processo de trabalho?
Arseny Gabdullin: Eu escrevi anteriormente em Python, mas basicamente eles eram sistemas sociológicos para a ciência, e o desenvolvimento foi no WordPress.
Em 2016, o T-F era apenas um tema do WordPress. Tínhamos poucos artigos e era uma solução perfeitamente adequada. Até certo ponto, o WordPress é suficiente para os olhos. Então, até o final de 2016, sugeri tentar mudar para o Django, porque havia acumulado vários problemas que precisavam ser resolvidos.
Experimente os palestrantes no Moscow Python Conf ++ mais próximo
Grigory Petrov: A propósito, é claro, isso não é habitual, você deve primeiro realizar uma conferência e, dois meses depois, para coletar feedback dos oradores. Noah não pode evitar. Nesta conferência, estamos realizando um experimento pela primeira vez -
estamos preparando palestrantes do zero . Não convidamos apenas Arseny junto com Vadim. Primeiro, eles participam pela primeira vez neste experimento. E esta será a primeira vez durante a existência do meu sistema, quando o adaptarmos à história de dois oradores ao mesmo tempo.
Você sabe como são as histórias de dois oradores? É muito triste: uma pessoa conta, conta, conta, a segunda com uma expressão triste no rosto fica na primeira atrás das costas. Então eles dificilmente mudam de lugar.
Tudo vai dar errado conosco. Arseny e Vadim transmitirão a história perfeitamente de um para o outro. Agora está tudo pronto, nós três já executamos o desempenho. Foi divertido.
Arseny, compartilhe suas primeiras impressões da nossa oficina. Acho que eles são especialmente valiosos agora, porque você e Vadim ainda não se apresentaram. Você está no meio da jornada, mas o relatório está pronto. Como você gosta do workshop? Quão louco, complicado e incomum foi isso - como isso se encaixa na sua experiência anterior?
Arseny Gabdullin: Nós realmente gostamos de nos preparar com Vadim. Cada vez que fechamos o laptop, pensamos: "Que legal!" Uma abordagem muito legal que em pequenas porções, mas regular. Cada vez que você percebe que fez algum progresso, mas no geral já foi percorrido um longo caminho.
Um sistema interessante é um princípio aparentemente simples no centro do discurso, mas, ao mesmo tempo, você entende imediatamente como tudo está conectado e como funcionará no futuro. Claro, eu nunca me apresentou com alguém no palco. É interessante tentar - não sei o que vai acontecer. Espero que tudo corra bem.
Grigory Petrov: Vai dar certo, o sistema não falha. Muito bom ouvir isso. Além de Arseny e Vadim, temos mais onze relatórios em preparação. A maioria dos dois meses antes da conclusão da conferência. É isso que significa que
sou ressegurador paranóico - um mês antes da conferência, e os relatórios estão prontos.Valentin Dombrovsky: Só tivemos meio ano entre as conferências, o
último Moscow Python Conf ++ foi em outubro.
Grigory Petrov: Hoje temos um tipo de conversa pequena com um alto-falante para o nosso público.
O podcast Python Junior está posicionado para desenvolvedores iniciantes, embora eu lhe conte um segredo que não apenas os juniores estão nos ouvindo.
Arseny Gabdullin: Segundo os rumores, Guido Van Rossum às vezes olhava.
Valentin Dombrowski: Legendas em inglês incluem - muito bom!
O Django é adequado como uma estrutura de mídia on-line em 2019
Grigory Petrov: Conte-me, Arseny, por sua experiência - para desenvolvedores iniciantes - quão satisfeito você estava com o Django. De fato, em princípio, o Django foi originalmente posicionado como uma estrutura para o negócio editorial, ou seja, revistas. Mas isso foi há muito tempo. A web mudou muito desde então, e você começou recentemente a usar o Django para a Tinkoff Magazine. Diga-me, você está decepcionado? Como o Django gostou para os sistemas de publicação em 2016 e além? Qual a sua opinião pessoal?
Valentin Dombrovsky: Ao mesmo tempo, sem spoilers! Bem, se apenas um pouco.
Arseny Gabdullin: No ano passado, trabalhamos no DevOps, tivemos uma grande equipe de engenheiros que nos transformaram em super infraestrutura diretamente. Eles geralmente são bastante céticos em relação ao Python, e em particular ao Django. Tínhamos um pingue-pongue constante.
Zlata Obukhovskaya: Eles simplesmente não precisavam fazer a revista.
Arseny Gabdullin: Sim, a propósito. Eles estão acostumados a prestar serviços corporativos, agora estão fazendo tudo no Node.js. Eles estão acostumados a elevar tudo ao Node.js, mas eu convenci muitos de que você pode se sair bem no Python e no Django. Mas, enfatizo, há muitas idéias sobre o bloqueio de solicitações - afinal, essa é a
natureza síncrona do Django, que não pode mais ser refeita . Esse é o destaque.
Em termos de trabalho com o ORM, acredito que seja para projetos grandes, onde existem muitos relacionamentos, onde tudo muda e você precisa ter uma estrutura na qual o domínio de dados será definido, o Django é muito conveniente. Agora estamos usando o Django como uma API, que é o objetivo dele, ou seja, distribuir dados.
Quanto tempo um projeto de conteúdo vive bem no Framework REST do Django?
Zlata Obukhovskaya: Você usa DRF, precisa falar sobre isso.
Arseniy Gabdullin: Sim, o
DRF é um padrão de fato . Existe um modelo Django, no topo da DRF - felicidade (até certo ponto).
Zlata Obukhovskaya: Até que ponto?
Arseny Gabdullin: Até o momento em que começam os complexos relacionamentos aninhados. Em nossa revista, o sistema de publicação é complexo, mas linear. Fizemos outro serviço para o banco no Django - Tinkoff Help, que cresceu fora da revista. Tudo é muito mais complicado lá, porque designers e produtos criaram uma hierarquia muito complexa de produtos e seções. Em algum momento, chegamos ao fato de que é difícil implementar no REST, é difícil serializar e é difícil garantir o desempenho. Você pode, mas precisa gastar muito tempo e apresentar movimentos não óbvios para otimização.
Zlata Obukhovskaya: Ou seja, assim que a junção de três etapas começar - tudo bem, não uma junção de três etapas, mas algo ainda mais profundo, provavelmente já é difícil.
Arseny Gabdullin: Exatamente.
Zlata Obukhovskaya: Acontece que o projeto Tinkoff Help seria melhor reescrever para outra tecnologia. Alguma idéia do que poderia ser usado? Do seu ponto de vista pessoal?
Valentin Dombrovsky: Nos apresente um pouco, o que é a Ajuda Tinkoff?
Arseniy Gabdullin: este é um serviço puramente bancário - informações sobre os produtos do banco. Mas, durante muito tempo, ele morou dentro de uma revista. Foi um pouco absurdo, porque ele tem pouco a ver com a revista. Mas já tínhamos uma plataforma de publicação em funcionamento, processos de produção estabelecidos e a prestação de um serviço separado naquele momento estava fora de lugar e fora de prazo.
Valentin Dombrovsky: Ou seja, em Tinkoff, eles combinaram, grosso modo, um projeto de conteúdo: a revista e a ajuda foram feitas na mesma plataforma.
Arseny Gabdullin: Foi um experimento. Ajudamos como uma pequena seção de uma revista, e depois ela cresceu, e ficou claro que ele já estava morando em uma revista. Depois, levamos para um serviço separado.
Valentin Dombrovsky: E para uma nova plataforma técnica?
Se não o Django, então o que
Zlata Obukhovskaya: Eu tenho uma pergunta: se não Django - e daí? Quais são as alternativas?
Arseny Gabdullin: Todos nós amamos o Node.js, fomos persuadidos a fazer o Node.js. Recusamos, não há desejo de trabalhar com dados no Node.js. Sim, é claro que há desempenho, assincronia e muito mais. Mas vamos ainda apresentar os dados nos modelos.
Zlata Obukhovskaya: Então Python assíncrono acontece?
Arseny Gabdullin: Sim, se você quiser escrever em Python, acho que isso é diretamente uma salvação.
Valentin Dombrowski: Aqui, então, a questão é - Node.js versus Python - quem vencerá quem. Se falamos sobre os hábitos das pessoas, isso é uma coisa, mas ainda é útil, onde funciona melhor? Grisha, Node.js ou Python assíncrono?
Grigory Petrov: É você apenas ...
Zlata Obukhovskaya: Eles abriram a caixa de Pandora praticamente!
Sobre o histórico do desenvolvimento síncrono e assíncrono em Python
Grigory Petrov: Eu já disse isso várias vezes e vou dizer, porque esses são os princípios básicos que são muito bem transmitidos pelo podcast do PythonJunior - olá, jones e todos os outros!
A programação assíncrona em geral - Event Loop no Python 3.7 e no Node.js 11 - é muito semelhante.
Mas existem camadas históricas. O Node.js foi do JavaScript, que foi do navegador. Em princípio, o navegador não pode permitir operações de bloqueio em JS, porque, caso contrário, a página será bloqueada, ela não será rolada.
Não podemos permitir que o JavaScript bloqueie a rolagem da nossa página exibida pelo navegador. Portanto, o JavaScript estava originalmente em retornos de chamada. Não foi possível fazer algo imediatamente, por exemplo, abrir algum armazenamento local ou um banco de dados. Poderíamos iniciar a operação, especificar um retorno de chamada e, depois de um tempo, quando o navegador executa a operação, o retorno de chamada foi chamado. Sempre foi assim.
Quando eles criaram o Node.js, esse paradigma de que tudo é assíncrono é retornos de chamada perfeitamente transformados em Node.js e agiram muito bem no paradigma assíncrono quando há um encadeamento e há muitas coisas de baixo nível ocultas nessa época de tempos em tempos retornos de chamada para este relatório de encadeamentos.
Quando, após muitos anos, assíncrona e aguardada chegou em JavaScript, assim como em Python, o quebra-cabeça aconteceu. Agora, o aplicativo Node.js se parece com uma async-coroutine, e por dentro aguarda, aguarda, aguarda tudo o que puder.
Python deu errado. O Python originalmente não era um incorporável, mas uma linguagem de aplicativo na qual eram feitos sistemas iniciados pelo usuário: esmagadores de números, servidores etc. Quando todos esses sistemas queriam abrir um arquivo, era uma operação de bloqueio. Historicamente, o Python devido ao GIL era conveniente para reproduzir e multiplicar por threads.
Se nós, no Python, quiséssemos fazer algo em paralelo, pegamos um pool de threads e multiplicamos por threads - havia felicidade! Então veio o Event Loop.
O que o Python desistiu do paradigma do encadeamento em favor do Event Loop?
Por que eles começaram a abandonar o paradigma de fluxo em direção ao EventLoop?
É muito mais fácil para um desenvolvedor ocultar todas as máquinas de bloqueio sob o capô e gerenciar apenas os resultados de operações assíncronas em um thread.
Isso é realmente conveniente - muito mais conveniente do que lançar milhares de threads e esperar por eles ao mesmo tempo. Além disso, os fluxos em si não são livres, lançá-los, alternar entre eles para o sistema operacional é um fardo.
Quando o Python passou dos threads para o Event Loop, verificou-se que todas as bibliotecas existentes estavam bloqueando. No Node.js., JavaScript, todas as bibliotecas existentes estavam inicialmente sem bloqueio, enquanto no Python estavam bloqueando inicialmente. Portanto, o maravilhoso assíncrono pronto para uso fornece essencialmente duas primitivas pelas quais podemos esperar: operações de rede e temporizadores.
Trabalhe com arquivos, bancos de dados, pipes, esmagadores de números, NumPy, redimensionamento de imagens - tudo isso em antigas bibliotecas síncronas. E, para usá-los, precisamos fazer o pool de threads, iniciá-los, criar o futuro, jogá-los de volta no fluxo com o Event Loop - em geral, é uma coisa triste. Novas bibliotecas novas, como o asyncpg, estão de alguma forma tentando encerrar isso.
Python assíncrono ainda é muito jovem.
Ele não tinha uma herança tão bem-sucedida como o Node.js e, portanto, ainda não amadureceu. No entanto, a própria linguagem é muito forte. Portanto, se houver uma equipe de desenvolvedores de Python, mesmo tendo essa limitação da juventude da programação assíncrona em Python, um desenvolvedor experiente de Python já poderá criar uma solução produtiva que não terá velocidade inferior ao Node.js. Mas, ao mesmo tempo, devido ao fato de o Python o conhecer muito melhor que o Node.js, a solução será melhor e desenvolvida mais rapidamente, o código é mais limpo e o suporte é mais barato.
É difícil escrever soluções assíncronas em Python do zero
Zlata Obukhovskaya: De fato, ninguém proíbe escrever seu próprio driver assíncrono para qualquer novo repositório da moda.
Grigory Petrov: Sim para você.
Zlata Obukhovskaya: E quem não?
Grigory Petrov: Todos os desenvolvedores são inferiores aos desenvolvedores seniores. Soluções assíncronas são realmente difíceis de escrever. Eles falham em lugares inesperados. Arseny, diga que é difícil fazer essas coisas.
Arseny Gabdullin: Assincronia? Incomum.
Zlata Obukhovskaya: Você usa assincronia em algum lugar de Tinkoff? Talvez alguns caras no jantar tenham contado uma história triste ou, inversamente, engraçada sobre o uso de assincronia?
Arseny Gabdullin: A maioria dos nossos serviços é fornecida por Node.js. Lá, a assincronia está embutida no DNA. Também temos, por exemplo, serviços de voz, muitos dos quais funcionam em Python. Para ser sincero, não sei exatamente como eles implementam tudo isso, mas acho que a assincronia é alcançada por meio de multithreading. Em geral, em APIs altamente carregadas, não é mais o Node.js., mas alguns Scala, pelo menos. E eles estão realizando cargas de trabalho muito altas em C ++, mas, novamente, além de multithreading.
Sobre a ferramenta de programação perfeita
Grigory Petrov: Há uma coisa que eu gosto de falar. O belo conto de que existe uma ferramenta ideal para resolver o problema, infelizmente, é apenas um conto de fadas. Ao longo dos anos, usando a mesma linguagem, o framework, o desenvolvedor desenvolve muitos padrões. Esses padrões expandem muito seu poder como desenvolvedor, o quanto ele pode manter os objetos em foco. Quando um jogador de xadrez aprende a jogar xadrez ao longo dos anos, depois de muitos anos, ele começa a ver o tabuleiro como uma combinação de peças familiares e familiares.
Se, por exemplo, um desenvolvedor de Python estiver programando em Python por 5 a 10 anos, ele pode ser um desenvolvedor experiente, em forma de T, conhecer Go, Node.js etc. Mas devido ao fato de ele ter uma experiência tão grande no uso do Python, ele especificamente e sua equipe do Python escreverão um serviço cada vez mais rápido, que será mais fácil de desenvolver e manter do que no Node.js e até no Go. Só porque a ferramenta familiar por muitos anos oferece um bônus enorme para todos os lados da escrita de código.
Claro, existem casos degenerados - é claro. Mas, no caso geral, para a maioria das tarefas é assim. Ou não? Discuta comigo.
Zlata Obukhovskaya: Pode-se argumentar, é claro, porque se o desenvolvedor tem uma longa parte da letra T, nada o impede de escrever um código muito saturado com características específicas da linguagem, que ninguém entenderá mais tarde. Mas ele entende - ele é legal!
Grigory Petrov: Eles dizem que desenvolvedores experientes, pelo contrário, escrevem código simples.Zlata Obukhovskaya: Da próxima vez, levaremos vários desenvolvedores experientes de várias tecnologias para o estúdio, daremos uma arma e deixaremos por uma hora.
Valentin Dombrovsky: Sugiro que cada um leia o código do outro e veja o que acontece. Será uma batalha!
Zlata Obukhovskaya: Vamos terminar esse argumento filosófico e retornar ao Django. Estou muito interessado na opinião de Arseny, mas e se não for o Django? Sobre coisas assíncronas e muito carregadas, entendemos um pouco. E para tarefas como criar uma revista, publicar sistemas de mídia, o Django é realmente a melhor solução. Por que não o frasco?
Valentin Dombrovsky: Essa foi a melhor escolha do seu ponto de vista ou poderia haver algo mais?
Arseny Gabdullin: Eu acredito que o
Django é a melhor escolha para a mídia.Valentin Dombrovsky: Quais eram as opções? Talvez algo mais tenha sido considerado?
Arseny Gabdullin: Havia uma opção para fazer na pilha de bancos, ou seja, usar as melhores práticas existentes na área administrativa de Tinkoff. Havia uma variante da estrutura do PHP porque tínhamos o PHP - para permanecer no mesmo paradigma. Não havia mais opções particulares. Mas queríamos manter nosso circuito, ou seja, não estar atrelado ao ciclo de desenvolvimento bancário, pois ainda há características próprias.
Zlata Obukhovskaya: Ou seja, se Python e mídia são Django?
Arseny Gabdullin: Eu acho que sim.
ORM resolve .
Zlata Obukhovskaya: Mas também existe ORM e não relacionado ao Django.
Arseny Gabdullin: Parece que sim. SQLAlchemy, por exemplo.
Valentin Dombrowski: PonyORM.
Zlata Obukhovskaya: Mas peewee ainda é usado na produção.
Arseny Gabdullin: Ainda assim, o Django foi desenvolvido inicialmente, parece-me, para projetos tão estruturados e complexos, vinculados aos dados, à relação entre dados, e isso é lido diretamente no DNA do nosso modelo, na construção da lógica.
Especificidade de desenvolvimento no banco
Grigory Petrov: O restante aprenderemos com o relatório. Aproveitando esta oportunidade, também quero fazer uma pergunta que não esteja relacionada ao Python.
Em nossa sociedade, há uma tendência a romantizar instituições altamente regulamentadas como, por exemplo, o governo, a medicina, o banco: “Banco ?! O dinheiro está aí! Provavelmente, existem metralhadoras na entrada, um sistema de acesso em quatro níveis, o olho de Sauron está instalado no telhado ", etc. Para você, como desenvolvedor que trabalhou anteriormente em um banco e depois começou a trabalhar em um banco, há alguma especificidade em trabalhar em um banco?
A propósito, é uma sorte que você não esteja trabalhando no núcleo financeiro regulamentado, mas nos serviços de infraestrutura relacionados. Então, fora do desenvolvimento principal, o trabalho no banco tem alguma especificidade engraçada ou é apenas uma empresa de TI comum, apenas em vez de gostar de redes sociais operamos com dinheiro?
: , - , IT- .
: vc.ru, , , , . , -, - .., . . .
IT- ?
: . , , . .
Moscow Python Conf ++
: , Moscow Python Conf ++ , , . ? ? ?
: — . , : « , , PostgreSQL 10 ».
— - -, , . , , .
: ? , - , - , ?
: , . , , .
: , Django — !
: Django.
: , , Django — . .
: , .
: , 24 , Python Core Developer, , - . , .
: Moscow Python Conf++.
: Python- 5 . . , , . Venha junto!