Почему в «Тинькофф-журнале» выбирают Django
Мы в «Python Junior подкаст» — подкасте для тех, кто хочет лучше разбираться в Python — стараемся всячески способствовать стремлению учиться. Приглашаем экспертов, задаем каверзные вопросы, получаем советы, чему и как учиться начинающему Python-разработчику, или не начинающему, или не Python — всякое бывает.
Сегодня вашему вниманию предлагается текстовая версия нашей беседы с Арсением Габдуллиным, разработчиком Тинькофф-журнала, на тему его будущего доклада на Moscow Python Conf++, но без спойлеров.
Хоть я все время говорю, что на конференции ходят, не чтобы учиться, пользы на них много. Как и в нашем подкасте.
В беседе участвуют:
- Григорий Петров, евангелист MoscowPython, руководитель программного комитета Moscow Python Conf ++;
- Арсений Габдуллин, разработчик Тинькофф-журнала, докладчик MoscowPython Conf++;
- Злата Обуховская, тимлид Nvidia, евангелист MoscowPython, член программного комитета Moscow Python Conf++;
- Валентин Домбровский, соорганизатор и сооснователь MoscowPython,
Валентин Домбровский: Арсений, твой доклад без спойлеров — о чем ты нам расскажешь на конференции?
Как Арсений стал разработчиком в Т—Ж
Арсений Габдуллин: На самом деле будем выступать вдвоем с напарником Вадимом Гончаровым — руководителем нашей разработки. Он со стороны бизнеса, а я со стороны разработки. Мы будем рассказывать, как делать медиа-проектыс использованием Python, какие это дает преимущества бизнесу и медиа, как мы переезжали с WordPress на Django, что мы с этим делаем сейчас, какие у нас были проблемы и успехи, и какие планы на будущее.
Валентин Домбровский: Давайте на один шаг назад отойдем. Расскажи, чем ты занимаешься, и как ты оказался в такой замечательной организации, как Тинькофф? Что тебя туда привело? Твой профессиональный путь?
Арсений Габдуллин: Я жил и учился на социолога в Петербурге. У меня была странная специальность «Информатик-социолог» — вроде бы исследователь, но как-то связанный с разработкой и с информационными системами для социсследований. Какое-то время я делал базы данных и инфосистемы для поддержки социологических исследований. В социологии часто используется Python. При этом параллельно я делал всякие сайты на WordPress — так вышло.
Коллективный coming out, связанный с WordPress
Григорий Петров: Нечего стыдиться. В жизни всякое бывает.
Злата Обуховская: Да, у всех бывало.
Валентин Домбровский: Ну вот, сейчас опять скажут, что мы травим PHPшников.
Злата Обуховская: Гриша, ты делал сайты на WordPress?
Григорий Петров: Конечно!
Злата Обуховская: И я делала сайты на WordPress.
Валентин Домбровский: И я делал сайты на WordPress. Я даже не разрабатывал на Python, но я делал сайты на WordPress.
Арсений Габдуллин: Да, я был молод, мне нужны были деньги. Потом в какой-то момент меня позвали в аутсорс-команду, которая делала Т—Ж. Тогда у нас еще не было разработчиков в штате, все было на удаленке. Я начинал с каких-то маленьких задач, потом они становились все больше и больше. Потом мне в итоге сказали — не хочешь ли ты в команду, в штат, в Москву? Я подумал, и променял Петербург на Тинькофф-Журнал.
Валентин Домбровский: И тогда это был WordPress?
Арсений Габдуллин: Да.
Валентин Домбровский: То есть твоя миграция в Python случилась непосредственно в процессе работы?
Арсений Габдуллин: Я писал до этого на Python, но в основном это были социологические системы для науки, а разработка была на WordPress.
В 2016 году T—Ж был просто бложек на WordPress. У нас выходило мало статей, и это было вполне годное решение. До какого-то момента WordPress хватает за глаза. Потом, к концу 2016 года я предложил попробовать переехать на Django, потому что накопился ряд проблем, которые надо было решать.
Эксперимент со спикерами на ближайшей Moscow Python Conf++
Григорий Петров: Кстати, конечно, так делать не принято, надо сперва провести конференцию, потом через два месяца собрать фидбэк со спикеров. Ноя не могу удержаться. На этой конференции мы впервые проводим эксперимент — готовим спикеров с нуля. Мы не просто так пригласили Арсения вместе с Вадимом. Они, во-первых, участвуют первый раз в этом эксперименте. И это будет первый раз за время существования моей системы, когда мы адаптируем ее для рассказа двух спикеров одновременно.
Знаете, как обычно выглядят рассказы двух спикеров? Очень печально: один человек рассказывает, рассказывает, рассказывает, второй с грустным выражением лица стоит у первого за спиной. Потом они с трудом меняются местами.
У нас все будет не так. Арсений и Вадим будут бесшовно передавать рассказ от одного другому. Сейчас уже все готово, мы втроем уже провели прогон выступления. Было весело.
Арсений, поделись первыми впечатлениями о нашем воркшопе. Они, я думаю, сейчас особенно ценные, потому что вы с Вадимом еще не выступали. Вы находитесь на середине пути, но при этом доклад уже готов. Как тебе воркшоп? Насколько это было безумно, сложно, необычно — как это с твоим предыдущим опытом стыкуется?
Арсений Габдуллин: Нам очень понравилось готовиться с Вадимом. Мы каждый раз, закрывая ноутбук, думали: «Как круто!» Очень классный подход, что небольшими порциями, но регулярными. Каждый раз понимаешь, что немножко продвинулся, но в целом уже пройден большой путь.
Интересная система — вроде бы простой принцип в основе выступления, но при этом сразу понимаешь, как все связано, и как это будет работать в будущем. Конечно, я не выступал никогда в паре с кем-то на сцене. Интересно попробовать — я не знаю, что получится. Надеюсь, что все пройдет гладко.
Григорий Петров: Получится хорошо, система не дает сбоев. Очень приятно это слышать. Кроме Арсения с Вадимом у нас еще одиннадцать докладов в подготовке. Большая часть еще за два месяца до конференции завершена. Вот что значит, что я параноик-перестраховщик — месяц до конференции, а доклады готовы.
Валентин Домбровский: У нас получилось всего полгода между конференциями, прошлая Moscow Python Conf ++была в октябре.
Григорий Петров: Сегодня у нас своего рода smalltalk со спикером для нашей аудитории.
Python Junior подкаст позиционируется для начинающих разработчиков, хотя, скажу вам по секрету, слушают нас не только джуниоры.
Арсений Габдуллин: По слухам, Гвидо Ван Россум иногда посматривал.
Валентин Домбровский: Субтитры на английском включает — very good!
Годится ли Django как фреймворк для онлайн-медиа в 2019 году
Григорий Петров: Скажи мне, Арсений, по твоему опыту — для начинающих разработчиков — насколько вы остались довольны Django. Ведь в принципе Django изначально позиционировался как фреймворк для издательского бизнеса, то есть как раз журналов. Но это было очень давно. С тех пор веб сильно изменился, и вы недавно начали использовать Django для Тинькофф-журнала. Скажи, не разочаровались ли вы? Что понравилось в Django для издательских систем в 2016 году и дальше? Твое личное мнение?
Валентин Домбровский: При этом еще без спойлеров! Ну, если только немножко.
Арсений Габдуллин: Мы в прошлом году работали над DevOps, у нас собралась классная команда инженеров, которые нам делают прямо суперинфраструктуру. Они в целом довольно скептически относятся к Python, и в частности, к Django. У нас был постоянный пинг-понг.
Злата Обуховская: Им просто журнал не приходилось делать своими руками.
Арсений Габдуллин: Да, кстати говоря. Они привыкли делать enterprise сервисы, сейчас они всё делают на Node.js. Им просто привычно поднимать все на Node.js, но я многих переубедил, что можно делать хорошо и на Python, и на Django. Но, подчеркну, много идей по поводу блокирующих запросов — все-таки это синхронная природа Django, которую уже не переделать. Это основной момент.
По части работы с ORM, я считаю, что это для больших проектов, где много взаимосвязей, где все меняется и нужно иметь каркас, на котором будет раскладываться домен данных, Django — это очень удобно. Мы сейчас переходим к тому, что используем Django как API — то, для чего он и предназначен, т. е. раздавать данные.
До какого момента контент-проекту хорошо живётся на Django REST Framework
Злата Обуховская: Вы используете DRF, нужно об этом сказать.
Арсений Габдуллин: Да, DRF — это стандарт де-факто. Есть Django модель, поверх DRF — счастье (до какого-то момента).
Злата Обуховская: До какого момента?
Арсений Габдуллин: До момента, когда начинаются сложные вложенные взаимосвязи. У нас в журнале система публикаций сложная, но довольно линейная. Мы делали еще на Django сервис для банка — Тинькофф Помощь, который вырос из журнала. Там все намного сложнее, потому что дизайнеры и продакты придумали очень сложную иерархию продуктов и разделов. Мы в какой-то момент уперлись в то, что это сложно реализовывать в REST, сложно сериализовать и сложно обеспечить производительность. Можно, но нужно потратить много времени и придумать неочевидные ходы для оптимизации.
Злата Обуховская: То есть, как только начинаются трехступенчатые join — ладно, не трехступенчатые join, а что-то еще глубже, то, наверное, уже тяжело.
Арсений Габдуллин: Именно так.
Злата Обуховская: Получается, проект Тинькофф Помощь лучше бы переписать на другую технологию. А есть идеи, что можно было бы использовать? С твоей личной точки зрения?
Валентин Домбровский: Чуть-чуть познакомьте нас, что такое Тинькофф Помощь?
Арсений Габдуллин: Это чисто банковский сервис — справка по продуктам банка. Но он долгое время жил внутри журнала. Это было немножко абсурдно, потому что он имеет мало отношения к журналу. Но у нас уже была работающая издательская платформа, наработанные процессы по выпуску, и делать отдельный сервис на тот момент было не к месту и не ко времени.
Валентин Домбровский: То есть де-факто в Тинькофф объединили, грубо говоря, контентный проект: журнал и help сделали на одной платформе.
Арсений Габдуллин: Это был эксперимент. Мы делали Помощь просто как небольшой раздел в журнале, а потом он разросся, и стало понятно, что в журнале ему жить уже тесно. Тогда мы его вынесли в отдельный сервис.
Валентин Домбровский: И на новую техническую платформу?
Если не Django, то что
Злата Обуховская: У меня вопрос: если не Django — то что? Какие альтернативы?
Арсений Габдуллин: У нас все любят Node.js, нас уговаривали сделать на Node.js. Мы отказались, нет желания работать с данными в Node.js. Да, там конечно производительность, асинхронность и прочее. Но давайте все-таки мы будем раскладывать данные в моделях.
Злата Обуховская: Тогда получается асинхронный Python?
Арсений Габдуллин: Да, если хочется писать на Python, я думаю, это прямо спасение.
Валентин Домбровский: Здесь тогда вопрос — Node.js против Python — кто кого поборет. Если мы говорим о привычках людей, это одно, а все-таки в usecase, где что лучше работает? Гриша, Node.js или асинхронный Python?
Григорий Петров: Это вы просто…
Злата Обуховская: Открыли ящик Пандоры практически!
О предыстории синхронной и асинхронной разработки на Python
Григорий Петров: Я уже несколько раз это говорил и буду говорить, потому что это базовые принципы, которые очень хорошо транслировать с PythonJunior подкаста — привет, джуны и все остальные!
Асинхронное программирование в целом — Event Loop в Python 3.7 и в Node.js 11 — очень похожи.
Но есть исторические наслоения. Node.js пошла из JavaScript, который пошел из браузера. Браузер в принципе себе не может позволить в JS блокирующие операции, потому что иначе страница будет заблокирована, она скроллиться не будет.
Мы не можем позволить себе, чтобы JavaScript заблокировал scroll нашей страницы, которую показывает браузер. Поэтому JavaScript изначально был на коллбэках. Мы не могли там что-то сделать сразу, например, открыть какой-нибудь local storage или базу данных. Мы могли начать операцию, указать коллбэк и через некоторое время, когда браузер операцию выполнит, коллбэк вызывался. Так было всегда.
Когда придумали Node.js, то эта парадигма, что все асинхронное и есть коллбэки, совершенно бесшовно перешла в Node.js и очень хорошо действовала в асинхронной парадигме, когда есть один поток, и есть под капотом много-много всяких низкоуровневых штук, которые время от времени коллбэками в этот поток отчитываются.
Когда через много лет в JavaScript, так же, как в Python, пришел async и await, пазл сложился. Теперь Node.js приложение выглядит какasync-корутина, и внутри await, await, await на все, что можно.
Python шел не так. Python изначально был не встраиваемым, а прикладным языком, на котором делали законченные, запускаемые пользователем системы: числодробилки, серверы и пр. Когда все эти системы хотели открыть файл — это была блокирующая операция. Python исторически за счет GIL было удобно плодиться и размножаться потоками.
Если мы на Python хотели делать что-то параллельно, мы брали thread pool и размножались потоками — было счастье! Потом пришел Event Loop.
К чему привёл в Python отказ от парадигмы потоков в пользу Event Loop
Почему вообще начали отказываться от парадигмы потоков в сторону EventLoop?
Для разработчика гораздо проще спрятать всю блокирующую машинерию под капот и в одном потоке управлять только результатами асинхронных операций.
Это реально удобно — гораздо удобнее, чем запускать тысячу потоков и в них одновременно ждать. Плюс потоки сами по себе не бесплатные, их запускать, переключаться между ними для операционной системы это нагрузка.
Когда Python из потоков перешел в Event Loop, оказалось, что все существующие библиотеки блокирующие. У Node.js, JavaScript все существующие библиотеки изначально были не блокирующие, а у Python они изначально блокирующие. Поэтому замечательный asyncio из коробки дает по сути два примитива, на которые мы можем ждать: это сетевые операции и таймеры.
Работа с файлами, базами данных, пайпами, числодробилками, NumPy, ресайзом картинок — всё это в старых синхронных библиотеках. И чтобы их использовать, нам надо самим делать thread pool, самим их запускать, делать future, пробрасывать их себе обратно в поток с Event Loop — в общем, беда-печалька. Новые, свежие библиотеки вроде asyncpg как-то стараются это обернуть.
Пока асинхронный Python еще очень молод.
У него не было такого удачного наследства, как у Node.js, и поэтому он еще не зрел. Тем не менее, сам по себе язык очень сильный. Поэтому если есть команда Python-разработчиков, то даже имея это ограничение молодостиasync-программирования на Python, опытный Python-разработчик уже сможет сделать производительное решение, которое не уступит по скорости Node.js. Но при этом, за счет того, что Python он знает гораздо лучше Node.js, решение будет качественнее и разработано быстрее, код чище, поддержка дешевле.
Трудно ли писать на Python асинхронные решения с нуля
Злата Обуховская: На самом деле написать свой собственный асинхронный драйвер какого-нибудь нового модного хранилища никто не запрещает.
Григорий Петров: Тебе — да.
Злата Обуховская: А кому нет?
Григорий Петров: Любым разработчикам уровня ниже, чем senior. Асинхронные решения реально тяжело писать. Они глючат в неожиданных местах. Арсений, скажи, что тяжело эти штуки делать.
Арсений Габдуллин: Асинхронность? Непривычно.
Злата Обуховская: У вас в Тинькоффе используется где-нибудь асинхронность? Может быть, какие-нибудь ребята за обедом рассказывали грустную или, наоборот, веселую историю про использование асинхронности?
Арсений Габдуллин: Большинство наших сервисов работают на Node.js. Там асинхронность заложена в ДНК. Еще у нас есть, например, голосовые сервисы, многие из которых работают на Python. Если честно, я не в курсе, как точно реализуют это все, но думаю, что асинхронность достигается за счет многопоточности. В целом в высоконагруженных API уже не Node.js, а какая-нибудь Scala, как минимум. А совсем высоконагруженные делают на C++, но опять плюс многопоточность.
Про идеальный инструмент в программировании
Григорий Петров: Есть одна вещь, о которой я люблю рассказывать. Красивая сказка о том, что есть идеальный инструмент для решения задачи, к сожалению, всего лишь сказка. С годами, используя один и тот же язык, фреймворк, разработчик нарабатывает много паттернов. Эти паттерны сильно расширяют его мощь, как разработчика, сколько он может держать объектов в фокусе внимания. Когда шахматист годами учится играть в шахматы, через много лет начинает смотреть на доску уже как на комбинацию знакомых и привычных штук.
Если, например, Python-разработчик программирует на Python 5–10 лет, он может быть опытным разработчиком, T-shaped, знать еще Go, Node.js и т.д. Но за счет того, что у него такой большой опыт использования именно Python, он конкретно и его команда на Python напишут быстрее и более быстрый сервис, который будет легче развивать и поддерживать, чем на Node.js и даже на Go. Просто из-за того, что привычный за много лет инструмент дает огромный бонус ко всем сторонам написания кода.
Есть, конечно, вырожденные случаи — понятное дело. Но в общем случае для большинства задач это так. Или нет? Поспорьте со мной.
Злата Обуховская: Тут можно поспорить, конечно, потому что, если у разработчика длинная ножка от буквы Т, ничего не мешает ему написать слишком насыщенный специфическими фичами языка код, который потом никто не поймет. Но он-то понимает — он же крутой!
Григорий Петров: Говорят, опытные разработчики, наоборот, пишут простой код.
Злата Обуховская: В следующий раз мы приведем в студию несколько опытных разработчиков из разных технологий, дадим вам в руки оружие, и оставим на час.
Валентин Домбровский: Я предлагаю дать каждому из них почитать код другого и посмотреть, что будет. Это будет баттл!
Злата Обуховская: Давайте, закончим это философский спор, и вернемся к Django. Мне очень интересно мнение Арсения, а что если не Django? Про асинхронные высоконагруженные вещи мы немножко поняли. А для задач типа сделать журнал, издательские медиасистемы, действительно ли Django — лучшее решение. Почему не Flask?
Валентин Домбровский: Это оказался оптимальный выбор с твоей точки зрения, или что-то другое могло быть?
Арсений Габдуллин: Я считаю, что Django — оптимальный выбор для медиа.
Валентин Домбровский: Какие были варианты? Может быть, что-то еще рассматривалось?
Арсений Габдуллин: Был вариант делать на банковском стеке, то есть использовать наработки, которые есть в админке Тинькофф. Был вариант PHP фреймворка, потому что у нас был PHP, — чтобы остаться в той же парадигме. Больше особо вариантов не было. Но мы хотели поддерживать свой контур, то есть не завязываться на банковский цикл разработки, так как там все-таки есть свои особенности.
Злата Обуховская: То есть, если Python и медиа — то Django?
Арсений Габдуллин: Думаю, что да. ORM решает.
Злата Обуховская: Но есть же ORM и не связанные с Django.
Арсений Габдуллин: Казалось бы, да. SQLAlchemy, например.
Валентин Домбровский: PonyORM.
Злата Обуховская: Но и peewee используют в продакшене до сих пор.
Арсений Габдуллин: Но все-таки Django изначально, как мне кажется, разрабатывалась для таких сложно структурированных проектов, завязанных на данные, на отношения между данными, и это читается прямо в ДНК нашей модели, в построении логики.
Специфика разработки в банке
Григорий Петров: Остальное мы узнаем на докладе. Пользуясь случаем, тоже хочу задать вопрос, не связанный с Python.
У нас в обществе есть склонность романтизировать такие сильно регулируемые институты, как, например, правительство, медицина, банк: «Банк?! Там же деньги лежат! Наверное, там пулеметчики у входа, четырехуровневая пропускная система, око Саурона установлено на крыше» и т.д. Для тебя, как для разработчика, который раньше работал не в банке, а потом начал работать в банке, есть какая-нибудь специфика именно работы в банке?
Тут, кстати, удачно, что ты работаешь не над финансовым ядром, которое регулируется, а над сопутствующими инфраструктурными сервисами. Так вот, вне разработки ядра есть у работы в банке какая-нибудь забавная специфика, или это просто обычная IT-компания, только вместо лайков в соцсети мы оперируем деньгами?
Арсений Габдуллин: Кстати, Тинькофф-Банк сейчас себя позиционирует уже не как финансовую организацию, а как большую IT-компанию с лицензией на банковские операции.
Валентин Домбровский: Я недавно читал интервью Олега Юрьевича на vc.ru, где он как раз рассказывал, что Тинькофф фактически хочет конкурировать с Яндексом, строить экосистему, как банковская организация. Яндекс имеет свои данные о запросах, о локациях пользователей через Яндекс-карты, Яндекс-такси и т.д., а у Тинькоффа свои данные. Они некоторым образом более чувствительные. Поэтому есть желание конкурировать и строить свою экосистему.
Ты чувствуешь себя сотрудником IT-организации в большей степени?
Арсений Габдуллин: Да. В атмосфере и в духе компании у нас очень мало заметно, что это банк, где все очень строго. Этого вообще нет.
Moscow Python Conf ++
Злата Обуховская: Наверное, в заключении интересно было бы поговорить про нашу любимую конференцию Moscow Python Conf ++ и послушать, Арсений, твое мнение и ожидание от этой конференции. Чего ты ждешь? Зачем ты на нее идешь? Что тебе хочется от нее получить?
Арсений Габдуллин: У нас идея — сделать немножко необычное выступление. По опыту участия на конференциях как слушателя, обычно выходят люди: «Мы сделали это и это, столкнулись с такими проблемами, и использовали PostgreSQL 10 версии».
Мы хотим рассказать техническую историю с точки зрения продукта и бизнеса — какую функцию мы выполняем как разработчики для такого крутого медиа-проекта как Тинькофф-журнал, почему мы принимаем именно такие решения для лучшей дистрибуции, лучшего охвата аудитории и пр. Хочется, чтобы получился не сухой технический доклад, а история.
Валентин Домбровский: А твои собственные ожидания? Может быть, ты надеешься на какой-то отклик аудитории или, сам рассчитываешь что-то узнать, почерпнуть для себя полезное?
Арсений Габдуллин: Интересно, как у других. Наверное, такие же задачи решают другим способом, это всегда супер интересно узнать.
Валентин Домбровский: Готовьте свои кейсы, если вы разрабатываете издательские системы на Django — добро пожаловать!
Арсений Габдуллин: И не на Django.
Валентин Домбровский: Поспорьте с нами, скажите нам, что Django — это на самом деле полный отстой. И приходите на конференцию.
Злата Обуховская: Я могу про это сказать, но только в кулуарах.
Григорий Петров: Я постараюсь организовать спикерскую, чтобы все 24 спикера, включая Python Core Developer, могли пересекаться в одной комнате и общаться друг с другом, приглашать туда кого-то из гостей конференции и в свободной обстановке обсуждать разные вещи. Я нашел в Инфопространстве место, которое можно трансформировать в спикерскую.
Валентин Домбровский: И это не единственное нововведение на конференции Moscow Python Conf++.
Для справки: Конференция Python-разработчиков состоится 5 апреля в Москве в Инфопространстве. Все принятые доклады уже на сайте в разделе тезисов. Будет три параллельных потока, много тем для общения, афтерпати и вообще круто. Приходите!
