Типы в Python

Я познакомился с типизацией в Python ещё в 2018 году. Вернее не совсем познакомился — просто мы начали писать какие-то аннотации, без правил: кто хотел, тот и писал. С виду довольно бесполезное занятие — автодополнения не было, по рукам, если накосячил, никто не бил. Дальше такой опциональной типизации мы тогда не пошли — нормального инструментария не было.

Даже в такой типизации была польза: когда пишешь код с типами, начинаешь гораздо больше думать об API и данных, чем об алгоритмах и синтаксисе языка. Сдвиг мышления похож на то, что происходит с TDD — с ходу не видишь пользы, но если вкуришь, то мышление траснформируется и больше не возвращается обратно.

В 2021 году я наконец-то смог сделать проект по фен-шую: с django-stubs и mypy. На мой взгляд, стало гораздо лучше: помимо автодополнения и стандартизации кодовой базы, радикально улучшилась читаемость. Последний пункт особенно важен сейчас, когда я захожу в проекты пару раз в месяц, и с ходу должен понять, над чем работает команда.

С типизацией согласны далеко не все: и в нашей команде и в питоньем мире в целом есть чуваки, которые думают, что типы в коде забирают больше времени, чем экономят. Я этих ребят понимаю — сам несколько лет не мог определиться. До сих пор отдаю решение об обязательности типов в команду проекта: если хотят писать с нестрогими типами или вообще без них — пожалуйста.

В общем для согласных, несогласных и тех, кто хочет радикально улучшить знания по типизации, мы с Марьяной позвали в Школу Никиту Соболева. Если вдруг не знаете Никиту — он один из авторов django-stubs, член Django Software Foundation, коммитит в mypy, typeshed и CPython. Никита прочитает цикл из трёх вебинаров — об устройстве типов, о тайпчекерах и о практическом применении всего этого.

Курс — бесплатный: времена располагают, да и сообществу надо помогать. Для желающих получить обратную связь есть тариф с домашкой и сертификатами, 30% выручки от которого пойдёт на развитие системы типов в Python.

Стартует 11 октября, читаем по одному вебинару в неделю, заканчиваем 31 октября.

Зарегистрироваться →

Из коробки

Важное понятие в мире хорошего DX — «из коробки». Это из сленга линуксоидов — когда ты устанавливаешь ubuntu на thinkpad, а у тебя всё работает без танцев с бубном — камера, сканер отпечатков пальцев, управление питанием по крышке и куча других вещей, о которых владельцы макбуков даже не подозревают.

Для рабочих проектов, к сожалению, не существует такого же радикального решения как макбук, поэтому и здравствуют горы репозиториев, которые нужно разворачивать по несколько дней: искать старые или несуществующие зависимости, ставить определённые версии языка, демонов и внешних либ, добавлять какие-то файлы, которых нет в репозитории, или вообще править код.

Представьте, как почувствует себя новый программист в первый день работы, когда сталкивается с таким бардаком? Чувак «бьёт копытом», хочет приносить пользу, а вы его заставляете заниматься тупой механической (и скорее всего плохо документированной) работой. Это как если бы менеджеров, прежде чем допустить до первой встречи с клиентом, заставляли мыть туалеты.

Любой проект должен разворачиваться одной командой, желательно в более, чем 90% случаев. Конечно, для этого придётся проделать огромную работу — одвенадцатифакторить приложение, вылечить менеджер зависимостей, докеризовать всё что можно, протестировать на разных операционках. Эта работа может показаться пустой, но когда вы увидите новичков, которые пушат в прод на первой неделе работы — поймёте, что оно того стоит.

#вопрос Скажи, как ты меряешь красоту архитектурных решений, когда оцениваешь, сколько стоит разработчик?

Красота и правильность архитектурных решений проверяется только временем. Для меня основной критерий для таких решений — это устойчивость к изменениям. Думаю каждый сталкивался с абстракциями, которые выглядят красиво до первой встречи с бизнесом, на которой выясняется что оказывается, чтобы добавить эту красную кнопку, надо всё переписывать.

С архитектурой систем то же самое — смотрим, насколько быстро новые разработчики способны понять устройство системы, насколько легко в неё добавляются новые проекты.

Некоторая насмотренность позволяет мне сходу оценивать решения джунов и некоторые решения мидлов. Ну а если я в себе не уверен — у команды всегда есть право облажаться, так что просто сижу и жду, что покажет время :-)

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Действия как лекарство от тревоги

Осознал, что история с мобилизацией в эмоциональном плане проходит для меня гораздо легче, чем 24 февраля — я всего пару вечеров читал медузу, и до сих пор остаюсь функциональным и бодрым, хотя после 24 февраля приходил в себя несколько недель.

Подумал и нашёл разницу — в то время вселенная не требовала от меня никаких действий: в первые пару недель мы просто охреневали, читая новости, никаких шагов предпринимать не было нужно. Даже карты начали блокировать в первую неделю марта, то есть через две недели. А сейчас требуется совершить сразу кучу действий: отыскать военные билеты; оформить команде документы для отсрочки; помочь проектам не остановиться от того, что их участники стоят на границе.

За всеми этими действиями, времени переживать у меня просто не остаётся — вот всё и идёт спокойно. Кажется, это универсальный совет — если конвертировать тревогу не в потребление контента, а в производство важных для себя вещей, она пройдёт гораздо быстрее. Если нет важных вещей для себя — есть близкие\родственники\друзья и волонтёрство. Все кто угодно, кроме издателей СМИ, которые зарабатывают на переживаниях.

Возможно совет банальный, но не могу не поделиться, простите.

На бесплатный курс Никиты Соболева про типизацию в Python записалось уже больше 800 человек. Это в 2 раза больше самой большой группы, которую мы когда-либо обучали! Волнуюсь за организацию курса и даже немного радуюсь, что не стали делать на английском — Никита довольно известный и продуктивный опенсорсер, пришло бы ещё больше участников.

На платном тарифе с домашкой и обратной связью места тоже пока есть. Это довольно странно, учитывая известность Никиты, но всё же — если хотите с гарантией разобраться в том, как улучшить питоний код при помощи типизации, то сейчас самое время записаться, стартуем в следующий вторник, больше потоков не будет. Ну и сертификат получите.

Перезапуск Вебиума

Выложили статью о проекте, который делали целый год (!) — полном перезапуске разработки Вебиума. Вебиум — онлайн-школа с огромным количеством учеников и сложной LMS.

Моя персональная гордость — во время этого проекта я научился не писать код — с марта добавил в репу всего несколько строк.

Горжусь командой и собой!

Цель сообщения

Тупое правило, которое иногда не соблюдают даже хорошие менеджеры — в удалённой работе у каждого сообщения должна быть конкретная и чётко понятная из него цель. Так, чтобы тот, кто получил ваше сообщение мог с одного взгляда понять, что вы от него хотите.

Цели бывает три:
— Задать вопрос: «Федя, у нас тут A и B. Не понимаем C. Подскажешь?»
— Согласовать: «Федя, у нас тут D и E. Хотим сделать F. Норм?»
— Попросить: «Федя, нам надо G. Без тебя не можем. Сделаешь?».

Если ваше сообщение не задаёт вопрос, не спрашивает разрешения и ни о чём не просит — скорее всего это пустое сообщение, которое лучше не писать.

#вопрос Ты топишь за 12 факторов. А как ты поддерживаешь второй фактор — зависимости, к примеру imagemagick? Оборачиваешь окружение в докер? А на локальной тачке?

Для прода мы используем либо Docker, либо билдпаки от Heroku, которые точно так же явно показывают зависимости.

С локальными зависимостями сложнее. Если мы разворачиваем бекенд на машине фронтендера, то там, используем тот же dockerfile, что и на проде. Если бекенд нужно развернуть на машине бекендера — я рекомендую работать на bare metal, а в докере держать только инфраструктуру, вроде PostgreSQL или RabbitMQ.

Считаю, что бекендер не должен отвлекаться на проблемы с inotify или искать сложные пути, как зайти в контейнер и посмотреть, что там происходит. Работать на локальной тачке не так страшно, как это может звучать, по крайней мере в питоньем мире. Даже если на машине нет каких-то бинарей вроде ImageMagick, скорее всего бóльшая часть эндпоинтов всё равно будет работать корректно и без них. А если прилетит фича на эндпоинт, которому нужно специфичное окружение — уж будь добр, разберись, ты ж бекендер.

Если кускам приложения нужно сложное окружение, лучше вынести эти куски в отдельный сервис, даже не имея нормальной архитектуры. К примеру у нас в школе есть сервис генерации дипломов, у которого образ может собираться 10 минут — туда приходится паковать кучу шрифтов и headless chrome. Конечно, я не хотел бы видеть все эти зависимости в основном монолите, который приходится пересобирать по несколько раз в день, вот и вынес их в отдельный образ, который неспешно меняется раз в пару месяцев.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Вы приняты: второй поток

Мы запускаем второй поток нашего самого актуального (🥲) на сегодня курса — «Вы приняты». Курс помогает программистам найти работу за рубежом. Делая домашку, вы пройдёте все этапы поиска работы — докрутите линкедин-профиль, составите шорт-лист компаний, подготовитесь к собеседованию и даже научитесь тороговаться за офер.

Вторая штука, кроме знаний, — поддержка: на тарифе «в тусовке» вы попадёте в чатик таких же переезжающих программистов, как вы сами. На первом потоке ребята отчитывались о собеседованиях и даже находили работу прямо в процессе обучения, такие вещи придают уверенности.

Главный эксперт курса — Дима Рожков: переехал в Германию в 2014 году, поработал в Амазоне, знает много о других фаангах и десятками нанимает разработчиков в Twilio, где работает сейчас.

Посмотрите первый урок, даже если не собираетесь покупать курс — это самые полезные 12 минут, посвященные переезду, которые я видел.

Ну а если собираетесь — стартуем 4 ноября. До 26 октября действует промокод 2Y1ET со скидкой 10%.

P.S. У нас есть 20 мест для тех, кто находится рядом с боевыми действиями, но имеет силы учиться. Напишите нам, если вас это касается.

Вообще в курсе много материалов не о том, как сделать, а о том, почему не стоит этого делать. В первом уроке рассказываем почему переезд может быть плохой идеей, или вот Дима записал видео почему не стоит работать в фангах — https://www.youtube.com/watch?v=RRFSLEFBV6Q

Лайкните, пожалуйста

Обещал рассказать про эксперимент с четырёхдневкой. TLDR — мы продолжаем работать 4 дня в неделю на всех проектах.

К сожалению, в нашей деятельности довольно сложно посчитать производительность и эффективность, поэтому мы ориентируемся на ощущения и опросы. По ощущениям, производительность команды не снизилась. По опросам, часть ребят продолжает работать 5 дней — хоть далеко и не в каждую пятницу. Доля работающих по пятницам колеблется от 30% до 50%, в зависимости от напряжённости на проектах. Судя по коммуникации в бейскемпе, чаще всего по пятницам работают менеджеры.

На первый взгляд цифры кажутся плохими, как будто четырёхдневка у нас только номинальная, а на практике все работают 5 дней. Но я интерпретирую эти данные немного по-другому — скорее график становится более свободным: меньше рабочих часов в день и меньше выходных дней. Я и сам давно живу по такому графику — у меня бывают недели совсем без выходных, при этом я умудряюсь делать все личные дела, нахожу время на путешествия, семью и хобби и в целом чувствую себя ровно и здорóво.

Эксперимент пока рано признавать удавшимся — я согласен с комментаторами предыдущего поста, что в долгом сроке всё может поменяться. Но мы продолжаем и надеемся.

#вопрос что почитать, чтобы лучше разобраться в Django?

Этот вопрос мне задали в пятницу на PiterPy и я слегка потерялся, поэтому попробую ответить здесь.

Потерялся я потому, что сам я по Django не читал ничего, кроме официальной документации и пары десятков статей на специфичные темы вроде edge-кейсов в поведении ORM. Честно говоря, я не думаю что по Django можно написать хорошую книгу. Достаточно материала наберётся только, если описывать её целиком, включая древние и бесполезные части вроде системы шаблонов, форм, подсистемы сайтов или стокового тестирования на базе TestCase.

Если описывать только актуальные части, нужные для создания API — ORM, DRF, работу с HTTP, админку, актуальные батарейки— материала наберется на 3–4 лонгрида максимум. Поэтому книг никто и не пишет.

Так что отвечу здесь так же, как ответил на конференции — смотрите на готовые проекты и решайте реальные задачи с помощью подходов, которые в них найдёте. Возьмите для начала стартер для Django от Никиты Соболева, или посмотрите на бекенд нашей школы, это уже не маленький проект.

Если всё же знаете, что почитать — напишите в комменты пожалуйста, только не забывайте что прямые ссылки постить нельзя, и надо ставить их слепыми, как в предыдущем абзаце.

Это был традиционный вопрос по понедельникам. Хоть вопрос и задали на конференции, чтобы не ждать следующей лучше напишите мне на fborshev@pm.me

Один из клиентов недавно спросил у нас с Саматом, не боимся ли мы публиковать имена программистов в анонсах проектов — вдруг увидят и схантят. Бояться такого довольно странно — если следовать этой логике, надо запрещать им пользоваться ещё и Линкедином, ездить на конференции и вести блоги.

Мне кажется, что рынок труда — это такой же рынок, как и любой другой: там тоже есть разные продукты (компании), между которыми покупатели (программисты) делают свой выбор. И чтобы обеспечить приток покупателей и высокий LTV (чтобы программистов не хантили), надо делать то же самое, что и на рынке — найти нишу, и выпятить вперёд фичи, которые закрывают потребности людей этой ниши. О наших фичах я постоянно говорю в этом канале — это асинхронная коммуникация, четырёхдневная рабочая неделя, чистый код и взрослые отношения внутри коллектива.

Правило с рынком работает и со стороны соискателя. Когда вы ищете работу, вы точно так же анализируете потребности целевых компаний и упаковываете скиллы таким образом, чтобы у компаний не возникло сомнения, что вы — тот, кто им нужен. Многие просто плывут по течению и берут количеством, а не качеством — тратят время на отклики и переписку вместо того, чтобы подобрать ключи к компании мечты. Об этом мы подробно говорим на курсе «Вы приняты», второй поток которого стартует в этот четверг.

Кроме очевидных вещей вроде написания резюме и выбора компании, мы говорим о том, как торговаться за офер, тренируем самопрезентацию, факультативно изучаем ведение профессионального блога и пет-проектов. Курс ориентирован на разработчиков, но подойдёт всем, кто связан с айтишечкой. Если вы разработчик — берите «VIP» или «в тусовке», если просто интересуетесь поиском работы за рубежом — «самостоятельный».

Стартуем в пятницу, а сегодня в 19:30 MSK на канале у Димы отвечаем на вопросы о курсе и поиске работы за рубежом. Записи не будет, напоминать тоже не буду — ставьте напоминалку на ютубе, если интересно.

Записаться →

Почему важно вести дневник

Я веду дневник уже почти 4 года. За это время я сделал около 1000 записей, загрузив в них почти 10 ГБ фото и видео. Считаю, что дневник — самая лучшая инвестиция в осознанность, даже полезнее чем покупка курса HeadSpace. Помимо общей осознанности или улучшения качества жизни, дневник даёт и измеримую пользу.

К примеру, дневник снимает писательский блок. Даже в канал с двумя подписчиками писать тяжелее, чем в дневник. Единственный судья в твоём дневнике — ты сам.

Отсутствие читателей помогает рефлексировать, делая автора предельно честным. К примеру, мне дневник помогает понять и принять довольно стыдные вещи — вроде того, что я уже полгода не был в спортзале и забил на уход за собой. Несколько лет назад дневник помог мне пережить развод — дневник был идеальным собеседником, с которым можно делиться чувствами и глубинными переживаниями, и который в ответ не будет давать тебе жизненных советов.

Рефлексия в дневнике бывает и для удовольствия: отдельный кайф после интересной поездки сесть и воспроизвести свои ощущения на каждой ключевой точке. Можно просто похвастаться успехами, или просто делиться интересными наблюдениями в течение дня.

Теги и геометки — тоже кайф: интересно посмотреть эволюцию моих размышлений на заданную тему, к примеру про текущие события или развитие пандемии; приятно смотреть как на карте увеличивается количество точек, в которых я испытал необычные ощущения.

В общем советую всем. Если юзаете мак — берите Day One: у них не сильно раздутое приложение (по крайней мере пока), честное e2e-шифрование и неглючная синхронизация.

#вопрос Подскажи пожалуйста, всегда ли вам хватало возможностей Django для ваших кейсов? Были ли моменты когда было желание переписать на чём то пошустрее? Есть ли какие-то кейсы когда ты бы не взял Django как основу для веб-проекта (помимо микросервисов и жестких ограничений по latency)?

Нам Django всегда хватало. Правда у нас много аутсорсной специфики: команды с высокими требованиями к времени ответа обычно реализуют проекты in-house с помощью собственных дорогих специалистов. В аутсорсе мы практически не работаем с нагрузкой, которую нельзя закешировать.

Даже там где работаем — предпочитаем делать простой, но медленный код, избегая преждевременной оптимизации. Порядок мыслей здесь простой — нагрузка может и не вырасти, а понятный и покрытый код всегда ценнее для команды, которая заберёт у нас проект, чем непонятный, но быстрый.

Хоть я с этим и не сталкивался на практике, рискну предположить, что современные облака с неограниченным горизонтальным масштабированием позволяют даже забить на GIL. Так что пока мы остаёмся на Django: на ней гораздо проще оказывать стандартную услугу разработки, чем на зоопарке из красивых фреймворков.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Управляющие воздействия

Когда я оцениваю проекты, команды или даже отдельных людей, я использую понятие «управляющее воздействие». Чем меньше таких воздействий нужно, чтобы нужные вещи случались — тем лучше.

Плохая команда не едет вперёд без дейликов. Несамостоятельный сотрудник не выполняет задачи без десятка комментариев от меня. Плохо настроенный проект буксует без ежедневных встреч всех участников.

Это как с машинами — от Москвы до Воронежа можно доехать на мерседесе или на жигулях примерно за одно и то же время. Только на мерседесе будешь разглядывать дорогу и слушать музыку, а на жигулях придётся подруливать, следить за температурой двигателя и может быть даже остановиться, если что-то сломается.

Правда, в отличие от машин, ответственные сотрудники хотят не на порядок больше денег, чем обычные.

Модель юзера — только для authn/authz

В Django есть две окаменелости — это система шаблонов и модель юзера. Про систему шаблонов я уже писал, когда рассказывал что Django — это API, а на второй остановлюсь подробнее: во-первых я не про AUTH_USER_MODEL, как вы подумали, а во-вторых, этот антипаттерн встречается не только у нас, но и в рельсе и, препдоложу в других M(VC)-фреймворках.

Проблема любой модели юзера в любом таком фреймворке — она своим существованием буквально просит неопытного программиста писать в себя код. Пишешь метод получения заказа? Как же клёво будет сделать request.user.get\_orders(). Делаешь почтовые уведомления? request.user.send\_email(). Хочешь отдать в API накопительную скидку? request.user\_get\_discount().

В итоге получается божественный объект, который буквально умеет всё, находится в центре любой схемы данных и не помещается в одной голове, чтобы его отрефакторить. Особенно грустно становится, когда в системе есть несколько видов юзеров — скажем потребители и контент-менеджеры. Первый действительно часто нужно делать .get\_orders(), то у других больше востребованы методы для работы с пермишенами и аудитлогом. И все они лежат в одном месте, путаясь друг с другом!

Конечно можете разбить код по рельсовым concerns или по питоньим миксинам, но этим вы притащите больше проблем, чем решите. Кроме того, что вы перестанете понимать, откуда приходит какой метод, вы (по крайней мере в django) отделите код консёрна от его полей: django не умеет собирать набор полей в модели из множественного наследования.

Так что настоятельно рекомендую, если работаете с MVC-фреймворкаии — не используйте модель юзера ни для чего кроме аунтификации и авторизации: запутаетесь.

#вопрос Не возникало ли желания разработать свой инструмент для отрисовки фронта? Я имею ввиду backend driven ui. Возможно что-то используешь из существующего, расскажи пожалуйста об этом. И как в целом рассматриваешь такой подход? И поделись пожалуйста мнением о собственной разработке подобных решений, стоит ли игра свеч?

Начну со второго вопроса. Желание делать собственные инструменты у меня пропало лет 10–12 назад, когда я понял, что попытки конкурировать с сообществом не приносят ни денег, ни счастья. Чтобы делать собственные фреймворки, нужно быть очень хорошим инженером, уметь разговаривать с людьми и разбираться в продуктоводстве. Разговаривая с опенсорсерами уровня Никиты Соболева я понимаю, что мне с моим ремесленническим подходом до этого очень далеко.

Про backend driven ui я уже где-то писал. Даже если отбросить крайности вроде приснопамятного GWT или попыток делать динамические формы на Django, делать фронт силами бекендеров довольно невыгодно с точки зрения бизнеса. Во-первых, на рынке труда гораздо больше неуниверсальных специалистов, то есть проще нанять отдельно бекендера и отдельно фронтендера, чем фуллстека. Во-вторых, все инструменты генерации фронта на бекенде, которые я видел, — довольно маргинальные. Как не конфигури тулзы вроде django-webpack, DX там будет ужасным — ни горячей перезагрузки, ни zero-configuration, даже разворачивать всё это на одной тачке крайне больно. Получается довольно обидно — настраиваешь неделю кучу всякой фигни, с трудом ищешь людей, которые с ней будут работать, а на соседнем проекте набирают npm init vue и получают всё то же самое, но сто раз проще.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me

Надёжность

Основа рабочих отношений в нашей компании — надёжность. Когда программист говорит, что сделает задачу в пятницу — менеджер проекта уверен, что в пятницу увидит код на проде, или в среду получит сигнал о том, что программист не успевает.

Когда два сотрудника назначают встречу на 16:00 — я уверен, что в 16:01 встреча уже будет идти. Когда любой сотрудник компании пишет письмо любому другому сотруднику (мне в том числе), он уверен, что письмо не потеряется.

Надёжность нужна, потому что мы — маленькие, а значит должны быть предельно эффективными: не тратить время, чтобы напоминать другу-другу о забытых обещаниях или извиняться перед клиентами за поехавшие сроки.

Внедрять надёжность а компании тяжело — приходится и увольнять людей, и самому «ходить в поля», чтобы понять состояние дел, — в общем целая история, о которой даже писать не хочется. Наверное, единственный понятный шаг, который с гарантией повысиит надёжности — это внедрить асинхронную коммуникацию: чем меньше люди на связи друг с другом, тем более понимают, раз пообещал — нужно сделать.

Мы в школе стараемся не играть в скидки, потому что считаем, что хорошие знания приобретаются осознанно, а не через импульсные покупки. Промокоды используем как награду — ребятам, которые читают рассылку или ранним пташкам, которые покупают курсы сразу после запуска.

Сейчас проводим эксперимент — объявляем чёрнопятничную распродажу: в течение 24 и 25 ноября даём скидку 25% на самостоятельный тариф любого нашего курса по промокоду BlackFriday. Хотим использовать пятницу, чтобы дать возможность познакомиться со школой тем, кто сомневается и видит недостаточно ценности в курсах. Или подарить друзьям.

Если заработает — будем раз в год придумывать что-нибудь новое.

Выбрать курс →

Если вы юрлицо, и хотите со скидкой купить 5 или больше билетов — напишите нам в чатик на сайте, для вас промокод тоже действует.

#вопрос Как нанимать сотрудника на незнакомый стек? К примеру, если мне нужно нанять react-разработчика, то я знаю какие вопросы задать, т.к. я сам пишу на реакте. Но как быть, если в команду нужен специалист по machine learning и ни у кого нет опыта в этом направлении?

Для начала — смириться с тем, что джуна вы не наймёте: не разбираясь в стеке, вы вряд ли отличите нормального джуна с горящими глазами от выпускника вайтишных курсов: вы не поймёте, насколько актуальны его знания, чем он интересуется и, тем более, не увидите его слабых мест.

Скорее всего, вы будете нанимать синьёров, а их собеседовать нужно уже как синьёров — не спрашивать, что нового в последней версии Keras, а пытаться понять, насколько он умеет разбираться в задачах бизнеса, быть самостоятельным, выполнять обещания, организовывать других и ещё кучу всего.

Ещё посоветую, если в компании нет экспертизы в ML, не пытаться её вырастить сразу, а обратиться к аутсорсерам. С теми всё ещё проще — вы просто говорите о деньгах и сроках, и выгоняете тех, кто не укладывается в обещания: не важно, подрядчик это по ML или какой-нибудь аутсорс-девопс.

Это был традиционный вопрос по понедельникам. Задавайте свои на fborshev@pm.me