Transcription
Привет. Меня зовут Андрей Фамин. Я преподаватель курсов линейки управления в OTUS.
OTUS - это образовательная платформа, которая специализируется на обучении IT. Мы обучаем тех, кто создаёт будущее, помогаем профессионалам развиваться, а новичкам войти в индустрию. Компании доверяют нам обучения своих сотрудников, как индивидуальных специалистов, так и целых команд.
Мы предлагаем широкую линейку IT-курсов на популярные и на узко специализированные темы по направлениям программирование, анализ и аналитика, инфраструктура, архитектура, data science, Game Dep, управление IT-командами и другие. Здесь найдётся всё для juniнир, midle и senior специалистов.
Курсы US - это онлайн-обучение, которое проходит в формате живых вебинаров, где опытные специалисты делятся собственными решениями реальных задач. Мы поддерживаем студентов на всём пути обучения. Наставники ежедневно ревьют домашние задания и дают развёрнутую обратную связь. А непонятные вопросы всегда можно уточнить в учёном чате или задать преподавателю на занятия. Благодаря поддержки экспертов, у студентов получается осваивать даже сложные и очень сложные темы.
Важная часть обучения - это проектная работа, в которой студенты реализуют полученные на курсе знания. И обычно она максимально приближена к реальным рабочим задачам. Поэтому выполненный проект пополнит ваше профессиональное портфолио и поможет при поиске новой работы либо при обсуждении повышения.
По окончании обучения у студентов остаётся бессрочный доступ к материалам курса. Они всегда могут вернуться за вдохновением и новыми идеями. OTUS - это лицензированная образовательная платформа. По окончании обучения мы выдаём студентам официальный документ, который подтвердит профессиональный рост. это удостоверение о повышении квалификации или диплом о профессиональной переподготовке. Также сертификат о прохождения курса всегда доступен в личном кабинете студента на русском и английском языках.
Наша миссия - развивать технологии, обучая их создателей. Каждым занятием, каждым проверенным домашним заданиям или проектом мы создаём настоящее и будущее образование. Мы видим это будущее в разработке качественных материалов и организации дружелюбного коммьюнити. Приглашаем вас разделить с нами этот путь.
Так, всем привет. А, добро пожаловать на открытый урок OTUS по курсу Python разработчик. Да, напишите, пожалуйста, плюсик в чат, если меня слышно и видно. Нет никаких помех. Так, спасибо, вижу плюсики. Отлично.
Так, тогда я кратко представлюсь. Меня зовут Стаценко Кирилл. Я ведущий разработчик. Занимаюсь ээнд-разработкой с 2018 года. Э, успел пописать на разных языках. Начинал с Jav, потом писал на GO, а потом в итоге начал писать на Python. Э последние несколько лет я свой выбор сделал, остановился на Го и на Пайтоне, да, сейчас развиваюсь только в этом направлении.
А что касается моих профессиональных интересов, моей специализации, да, я фактически всё время на всех работах занимался разработкой инженерных платформ, то есть каких-то внутренних сервисов для разработчиков, то есть пас, САС, различные решения. А и Ага. О'кей. И а сейчас я занимаюсь разработкой MLOPS платформы в компании MTS Websvices. Да, на этом проекте много Пайthна. много го, потому что приходится изучать операторы в Кубернетисе и, собственно, много самого Кубернетиса. А так что с инфраструктурой, сетями, с этим, если что, возникнут какие-то вопросы по ходу вебинара, можно тоже спрашивать. Буду рад на них ответить.
А правила нашего вебинара следующее. Активно участвуем, задаём вопросы. Чем больше зададите вопросов, тем будет лучше всем. Да, вы узнаете больше нового, мне будет приятно на них отвечать. А вопросы нужно задавать в чатик. А я эти вопросы вижу. У меня справа отдельный ноутбук. На нём как раз у меня выведен чат. Я буду периодически читать вопросы, но сразу скажу, что отвечать на вопросы я буду в конце блоков. То есть прошли какую-то тему, начинаю отвечать на вопросы просто, чтобы не выйти за рамки временные, потому что э на вопросы можно очень много времени потерять. И что касается записей, она придёт вам на почту, на которую вы регистрировались вместе с презентацией, вместе с какими-то полезными ссылками.
И теперь я хочу, чтобы вы написали в чат немножко о себе, да, буквально ответить на два вопроса. Какая у вас актуальная должность? Возможно, вы учитесь или уже где-то работаете, да? Если работаете, то какой у вас опыт там с пайтном или программирование вообще? И второй вопрос: с какой целью сегодня пришли на вебинар? Что бы вы хотели узнать?
Вот вижу уже ответ от Григория. Добрый вечер. Я Python Backend Developer I integration and Automation с опытом коммерческой разработки, где занимался поддержкой и развитием сервиса, включая оптимизацию обработки данных, рефакторинг, работу с инфраструктурными проблемами и улучшение качества данных и документации. пришёл на вебинар, чтобы послушать про виртуальное окружение и задать вопросы. Отлично. Ваша цель соответствует теме вебинара.
А Вадим пишет: "Я студент, изучаю и интересен вебинар подчеркнуть новые знания". Отлично.
Михаил пишет: Python fast API плюс мас. Что такое мас? Не совсем уверен. Можете написать поподробнее, пожалуйста.
Так, Арсений пишет: "Я разработчик ETL, опыт 10 лет, запускал скрипт на Python через shell скрипты". Отлично, сегодня узнаете что-то новое.
Ага, System. Спасибо.
Так, Николай пишет: "Python в рамках аналитических задач. Виртуальное окружение для меня новое. Интересно. Отлично. Сегодня будем как раз смотреть на особенности виртуального окружения.
Так, ну спасибо за ответы. Да, тема нашего урока: Настройка удобного в окружения для Python проекта.
А маршрут следующий. Сначала мы посмотрим на архитектуру такого типичного Python проекта, какие в нём есть компоненты, посмотрим, а как это приложение нуждается в инфраструктурных сервисах, каких-то внешних зависимостях. Следом посмотрим на инструментарий локальной разработки, да, как мы можем локально воссоздать окружение, в котором будут представлены все эти зависимости. А следующее, а настройка депоя в кубернете, да, мы сначала запустим приложение в докере, в композе, посмотрим, что у нас всё работает, и начнём немножко развивать вот эту вот идею. А сделаем так, чтобы оно ещё и работало в кубернетесе. поднимем локальный кластер, а, и запустим там нужные ресурсы. После вот этой теоретическо практической части у нас будет, а, блок, посвящённый рассказу про курс, да, что это вообще за курс Атос такой, что вы там можете узнать, кому он подойдёт, какие-то интересные предложения, и в конце будет рефлексия, сама рефлексия, просто поотвечаем на вопросы, чтобы убедиться, что мы, э, узнали что-то новое, да?
И перед нами сегодня три основные цели. во-первых, э, понимать архитектуру типового Python проекта, да, чтобы, в принципе, знать, из чего он состоит, чтобы можно было это как-то переиспользовать и в своих проектах, и, э, быстрее погружаться в какие-то существующие там сторонние проекты, да, чтобы понимать вообще какие-то ключевые узлы, по которым можно понять суть проекта. Вторая цель - это собирать локальное окружение с инфраструктурными компонентами. Это основная часть нашего занятия, да? Зачем это нужно? Ну, очевидно, что современное приложение - это не просто какой-то скрипт или там один файлик, да, с питоном. Это какой-то комплексный проект, у которого есть внешние зависимости. И эти внешние зависимости нужно как-то resolv, да, то есть запускать как-то локально, чтобы ваше приложение полноценно протестировать. А, и третья цель - это наше приложение задепоить Kubernetis Cluster. То есть Kubernetis - это, в принципе, современный инструмент. Он много где используется, почти в любой эээнд ва-вакансии, да. И очень полезно понимать полный цикл жизненного, точнее, полный жизненный цикл приложений. То есть не просто мы его написали, оно у нас локально работает, а ещё и действительно смогли его задеплоить в какой-то реальный кластер. Вот так.
Сейчас прочитаю, пока есть время. Э, так, Николая, мы читали. Олег пишет: "Хотелось бы услышать про DUTН в подключение проекта немного ос". Ну, про MLOPs тут сегодня не будет, к сожалению.
Артур пишет: "Хочу начать обучаться в Хай. Что посоветуете для старта? Какие области более актуальные сейчас ближайшие будуще?" Давайте этот вопрос наконец оставим. Я на него отвечу.
Михаил скинул, наверное, в ответ Артуру, да, чтобы он посмотрел, как изучать Python.
И Леонид пишет: "Изучаю Python. Хотелось бы получить новые знания для дальнейшего развития". Отлично.
Итак, а я сейчас перешарю презентацию, потому что я буду демонстрировать весь экран, чтобы показывать не только презентацию. Скажите, пожалуйста, видно ли вам то, что я показываю свой редактор? Да. Отлично. Скажите ещё, пожалуйста, нужно ли сделать шрифт побольше или, в принципе, всё и так о'кей? Можно ли разобрать текст? Побольше. Ага, давайте попробуем. Так, побольше. Давайте поставлю 1 де. Вот, наверное, так будет лучше. Напишите, стало ли лучше. Угу. Видно, норм. Плюс. Отлично.
Тогда давайте двигаться по первому нашему блоку. Архитектура типового Python приложения. И для этой цели я вот накидал такую небольшую диаграммку, которая будет как раз-таки описывать наше приложение. А это DAO диаграмма. Здесь нарисованы такие обзорные как основные элементы нашего приложения, да, из чего оно состоит. И первое, что мы видим - это типичное HTTP приложение, да, веб-приложение, там как 99% веб-приложений, которые мы разрабатываем, они работают по HTTP протоколу. У нас здесь будет использоваться, а, UVCORN как реализация ISGI веб-сервера, то есть веб-сервер, который поддерживает asynchronous gateway. А само наше ISGI приложение, оно будет написано с помощью фреймворка Fast API, да? То есть вот в этом а кусочке, как бы в этом компоненте будут описаны роутеры HTTP, которые отвечают за HTTP запросы, а наши бизнесовые модели, а настройки приложения, там какие-то пайден схемы и всё такое. То есть вот по сути основная часть нашего кода будет сосредоточена в этом компоненте. А справа можете видеть реляционную базу данных, да, 99% веб-приложений работают с базой данных. не обязательно с реляционной, да, это может быть какая-то объектная база, там ещё какая-то, в нашем случае будет реляционная, и конкретно это будет Postg SQL. А, то есть вот эта вот верхушка - это, в принципе, классическое веб-приложение, да, оно вот любое веб-приложение чаще всего из этого и состоит. Там, например, вместо Fast API у вас может использоваться джанга или фласк там или ещё что-то. Starlлет, например, голый. Вместо Ювикорна может использоваться там прямо, например, или Gunicorn или что-то ещё, там Hyperкорн какой-нибудь, если вы знаете, что это такое.
А вот эта вот часть, которая снизу, она довольно такая, ну, более интересная. Она тоже часто используется. Это тоже типовая архитектура. А фактически здесь нарисован реализация использования фреймворка селери. Это фреймворк, который нужен для выполнения асинхронных задач. То есть, по сути, это eventт дривен подход, когда у вас есть веб-приложение и вы не хотите все запросы от пользователя обрабатывать. Ну, то есть до конца, например, пришёл пользователь, он зарегистрировался, и в конце регистрации вы пользователю хотите отправлять ла с какой-то полезной информацией, там какое-нибудь приветственное сообщение, да, и если бы у вас не было вот этой вот очереди задач или каких-то асинхронных задач, вам бы пришлось прямо вот в самом обработчике запроса сначала зарегистрировать пользователя, сохранить его в базу данных, потом с помощью какого-нибудь СМТПсервера сходить в него, отправить ему письмо. Да, и пока вы всем вот этим вот занимаетесь, ваш пользователь бы ждал ответа. То есть это довольно странно, это не очень отзывчивый интерфейс, да, не очень отзывчивая API, то, что приходится долго ждать. И по этому поводу используется асинхронная обработка. То есть идея в том, что когда пришёл пользователь, он зарегистрировался, вы его сохранили в базу данных и сразу отправили ему ответ. То есть там что-то типа 200 ОК или 2011 created. пользователь понял, что он зарегистрировался, и вместе с тем, как вы ему отправили ответ, вы в очередь задач положили сообщение, да, какую-то задачу. Это ещё называется Taskq или Message Q, в принципе, неважно. И, э, то есть вот наше Fast API приложение положило какую-то задачу. И у нас также есть серикеer, который следит за этой очередью, обнаруживает там новые задачи и достаёт их из очереди. Когда он достаёт их из очереди, он их, соответственно, выполняет. То есть, что мы сделали? Мы положили в очередь задачу отправить письмо вот такому-то пользователю. А серикер увидел, что в очереди появилась эта задача. Да, там не не обязательно прямо сейчас, может быть, он был занят, он увидел про это событие через минуту, про это сообщение. Через минуту он его достал из очереди, выполнил задачу и сохранил результат этой задачи вредис. А как кэширующий такой database кэширующий бэкэнд. А в принципе сохранять результаты задачи может быть полезно и нам самим, чтобы посмотреть в будущем на какую-то статистику по тому, как они выполнялись, да, есть ли какие-то проблемы с задачами. И это также механизм используется в самим селлере. Если вы работали сриy, знаете, что там есть такая концепция, как цепочки задач серий, а они как раз-таки переиспользуют бэкэнды и результаты, чтобы запускаться по цепочке. То есть следующая задача использует результат предыдущей задачи. И результат она берёт вот из этого бэкэнда. И ещё один компонент - это тоже часть селери называется селе. А смысл в том, что он нужен для того, чтобы добавлять в очередь задачи по расписанию. То есть у нас есть какие-то задачи, которые мы запускаем в ответ на какое-то событие, например, регистрация пользователя, да, есть какой-то триггер, а есть задачи, которые мы хотим запускать просто по расписанию, например, каждый день там или каждый час или раз в неделю. И вот как раз-таки sребит, он для этих целей и нужен. Мы в конфигурации просто говорим, какую задачу и как часто мы хотим запускать. Он у нас работает фоном как демон и периодически просто добавляет в нашу MessageQ вот эти вот задачки. И что тут из интересного? Вот Message Q он может быть не обязательно редисом. Это может быть и Rabit MQ, это может быть, э, кавка или что-то похожее, да, любой как бы сервис, который реализует очередь, но я использую дис для простоты, потому что это проще настроить. А в качестве кэша тоже можно использовать разные бэкэнды, можно использовать базу данных, можно использовать там тоже дис, ещё что-то, но дис он считается как бы де-факто самым хорошим э выбором для хранения кэша. И по этой причине он у нас тоже будет использоваться. Но, в принципе, вот эти вот компоненты, они все заменяемые. Вот. А, в принципе, и селлери можно заменить при желании, если слышали. Есть такой фреймворк современный на Пайthне fastстAM. Он в каком-то смысле может заменить селери, но он не такой верхнеуровневый, с ним не так удобно писать вот эти вот задачи. То есть он именно для задач, астAM он, в принципе, для общения сessage Q, то есть этоброкеer, ариy - это как типа messageброкер на стероидах. Вот это как бы обзорная архитектура, структура нашего приложения.
Теперь давайте посмотрим на него поподробнее, то есть на наши исходные файлы. Ну, во-первых, с чего начнём? Это с точки входа, да? Это ISGI модуль. Я его назвал ISGI, потому что здесь содержится наш ISGI application, да, то есть, а, вот этот вот app из фреймворка Fast API. А также у нас есть несколько роутеров, да, это, то есть обработчиков запросов AUS роутер, Userроoutу и Bookроутер. Они у нас лежат в отдельном каталоге. Вот, например, можно посмотреть на AUS роутер. Он отвечает за то, что пользователю выдаёт такен, да? То есть это fast API роутер. Здесь содержится логика обработки запроса, здесь содержатся входные данные в запрос, здесь содержится dependency, то есть инъекция зависимостей каких-то. Вот, например, нам, чтобы создать таке, нужно вызвать usеerсервис. И мы его не хотим создавать явно, мы используем зависимость. То есть фастапе как-то там сам за нас заинжектит вот этот вот сервис, и в этом методе мы сможем с ним работать. А схемы лежат в отдельном файлике, то есть в отдельном модуле. А схемы - это фактически модель данных, которая будет возвращаться в ответ на запрос. Вот, например, на запрослогин по пути сten будет возвращаться, то есть будет возвращатьсяка, в которой лежит два поля access to и token type. А дальше у нас есть endpint для книжек, да, ну просто, то есть это такое показательное больше приложение. Здесь нет какого-то реального смысла просто чем-то его наполнить, да, что у нас не голый один endpint для аутентификации, а ещё есть какие-то другие сущности. Здесь, в принципе, всё тоже похожее. Здесь используется bookсвиice, да, для создания книжек. Ну и есть partial update, то есть, точнее, не partial, а полностью апдейт перезаписанный. Есть delete. Вот схема здесь тоже отдельная для книжек, то есть отдельная схема на создание, отдельная схема на апдейт и отдельная схема на когда мы возвращаем книжку. И то же самое с юзерами. Да, тут останавливаться даже особо нет смысла. Тоже схема. И наши роутеры общаются с нашей доменными сущностями, с книжками и пользователями через сервисы. То есть это такая прослойка, типа слоя абстракции, который реализует вот логику взаимодействия с, в нашем случае это SQL Alchemy, то есть Book - это SQL Alchemy а модель. Вот так вот выглядит наш буксервис, так выглядит userсервиice. Тут просто запросы в базу данных с применением ORM. По сути, ничего такого интересного здесь нету. А вот как выглядят сами модели, да? Это SQL Alchemy. Вот тут видно, что мы импортируем ключи из SQL Алchми. В смысле классы. А создаём книжку, да, у нас табличка Books. Тут, в принципе, внешние ключи есть на авторов. то, что там связь один ко многим. И то же самое для автора, чтобы не случилось э циркулярных импортов, да, зависимостей, мы добавляем typeчеcking, чтобы импортировать бук только в момент проверки типов.
Вот что касается modelл. Дальше из интересного у нас используется settings для настройки конфигурации приложения. То есть вот там в чатике спрашивали про DNF. Это по сути то, что позволяет нам запускать приложение с вычитыванием значений переменных окружения из DTN файликов. То есть мы описываем а префикс и все переменные окружения, которые будут начинаться с AUS. И вот дальше продолжение, оно будет попадать вот в этот вот объект A settings. И мы уже в нашем приложении можем с ним что-то делать. Вот, например, ну, у меня сейчас нету интерпретатора, попозже тогда покажу. А то же самое для селери, чтобы настроить селери, мы тоже задаём переменное окружение с префиксом сери. И вот у него есть два свойства: брокеer URL и result backend. То есть вот, если возвращаться на схему, это брокеer URL - это вот эта часть, а result - это вот эта часть. Вот. А это что касается настроек salary. И вот что касается настроек базы данных, подключения к базе данных. тоже такой же settings экземпляр. Просто заполняем строку подключения так называемой DSN.
Вот э из тасков вот серисков, то есть это функции, которые будут запускаться селери workркером. Есть две задачи. Вот эта задача периодическая. Её запускает селери вот здесь вот, точнее серии bit. А вот здесь вот это можно видеть. Здесь есть schedule, то есть это указание расписания, что вот эту вот задачу нужно запускать с такой частотой, то есть раз в 30 секунд будет запускаться вот эта вот задачка. А эта задачка по сути как такая точка входа для того, чтобы запустить ещё несколько задач. И вот по сути она собирает всех пользователей с базы данных и для каждого пользователя запускает вот эту задачу. Send news to user. Вот. Э-э, что касается, ну, AS просто штуки для работы с двткенами, да, с хэшированием пасворда, пароля. А сери - это точка входа. А-а, это как бы конфигурация для а селери, как оно будет импортировать задачи. Да, у нас задач немного, поэтому всего один импорт. Есть include для подключения других зависимостей, которые нужны в воркере. в нашем случае просто подключаются модели, потому что workкеer должен уметь тоже ходить в базу данных, работать с моделями. Database тут просто создаётся ORM движок и конструктор сессий, да, фабрика, который используется уже в сервисах. Ну и в Dependнсе здесь просто удобная штука, чтобы доставать из хедеров, из аутентифиication headдера beer token доставать. То есть наш GVT таке.
Вот это всё, наверное, что интересного было про наше приложение. Ещё у нас есть DockerФай, да, мы им сейчас будем пользоваться. Здесь на самом деле файл простой. Я просто взял из документации UV такой минимальный шаблон, чтобы показать, что можно просто запустить приложение с помощью UV. И если вы хотите его как-то развивать, да, тут вот ссылочка на бест практисы, там уже будет показано, как и с кэшем работать, и как больше слоёв делать мультистч сборки и всё такое. Но для нашего урока это будет просто перегруз информации, поэтому я оставил простой вариант. И ещё важный момент, что в нашем приложении используется алембик для создания миграции базы данных. То есть мы не пишем скрипты SQLные для атеterтейблов и так далее руками. Мы используем аemмбик. Олембик он у нас настроен по дефолту. Единственное, что вот мы указываем а опцию, что подключаться к базе данных он будет из нашей конфигурации, из database settings. То есть, чтобы запустить Олембик миграцию, нам нужно будет передать переменные окружения ему. Вот. Э, соответственно, вот наши две модели. Они создаются с помощью Олембика.
И вот эта часть у меня всё. Я, в принципе, рассказал всё, что хотел про этот проект. А давайте я сейчас спрошу у вас про свой вопрос, да, и пока вы отвечаете, я буду отвечать на ваше. А напишите, пожалуйста, в чат прямо быстренько, о каких новых аспектах Python проектов вы узнали и какие из этих аспектов вы планируете применять на практике, если что-то такое есть. А я пока буду читать ваши вопросы.
А, Михаил пишет: "Очередь и в пост QL можно положить". Насчёт очереди, если честно, не уверен. По-моему, по дефолту она в селере не поддерживается, да? То есть брокер как база данных, но кэш, результаты выполнения задач точно можно с помощью ОРМки, тоже SQL алхимии, положить в базу данных.
А далее Михаил пишет поentic может и ENFS вычитывать, и DNF аккуратнее. А, да, спасибо за предупреждение, но как бы нас это интересует. Я сейчас не совсем понимаю, в чём проблема, что он и то, и то умеет читать. Э, в этом же и смысл. То есть когда вам нужно изва вычитать и вы не хотите соурсить все переменные, вы просто создаёте DTN. Мы сейчас на это тоже посмотрим. А если у вас нету, вы явно указываете NВС для вашего процесса.
Так, а Михаил опять пишет: "Структура проекта слойная, когда по доменам лучше раскладывать?" По доменам лучше раскладывать, но тут, на самом деле, нет какого-то универсального ответа. зависит от вашей сложности, от вашей как бы экспертизы, насколько вы можете декомпозировать домен, если вы понимаете, что вы на это как бы потратите больше времени, да, у вас там в команде нету какого-то аналитика или subбжект там доменного эксперта, тогда, наверное, лучше сильно с этим и не запариваться. Вот.
А в Pject используется def mode. А что вы имеете в виду под def mode? А, наверное, def dependency группу или editable, типа установку в editable режиме нашего пакета. Если про Editable, то нет. Здесь, по сути, пакетирования вообще нету, потому что мы будем запускать это в докере. А, соответственно, нет смысла собирать пакет.
Э, так, Григорий пишет: "Вкод у меня отображаются три Python интерпретатора: системный Python, локальный, виртуальная. Устанавливаю через Windows. Бла-бла-бла-бла. Можете объяснить, почему VC видит все три? Все ли в порядке или я что-то не так делаю?" А, да, на самом деле всё в порядке, да? Просто VS-код, когда вы пишете там selectтепр, он, а, сканирует какие-то заранее известные, а, заранее известные пути, да, и по этим путям ищет, если у вас интерпретатр. Вот, например, я на Линуксе, я использую PENF, я использую какой-то вот у меня системный интерпретатор. Сейчас у меня ещё в этом проекте появился интерпретатор. То есть тут никакой ошибки нет. Он просто знает, где искать, и поэтому показывает вам всё, что по сути нашёл.
А, Арсений пишет: "Я использовал Pcharm. А вы какую среду разработки сейчас используете?" Это VS-код. Вот тут вот написано Visual Studio Code. Просто он у меня немножко кастомизированный. Вот. Если интересно, я могу к лекции приложить профиль. Вот свой профиль, в котором есть какие-то экстеншены. И так вот он будет у вас тоже выглядеть, если вас интересует.
А Павел пишет: "Зачем селери? Фастапи же сам ASН. Наверное, письма можно и без очереди отправить". А просто письмо - это такой простой пример, который проще всего понять. На самом деле селери и для других вещей используются, да? Если у вас какая-то сложная там многосоставная, не знаю, подход к созданию каких-то сущностей, вы, например, пользователю отправляете в ответ, когда он там создал, например, книгу, да? А вам эту книгу ещё нужно там на складе зарегистрировать, в каком-то сервисе зарегистрировать. То есть у вас огромный такой пайплайн создания какой-то сущности. Очевидно, ваш пользователь не будет ждать, даже если у вас fast API. То есть здесь, когда я говорю синхронные задачи, я имею в виду не то, что они, а, работают с ASIN, да, с Eвентлупом, а то, что они, в принципе, могут быть выполнены когда-то потом, то есть отложенное выполнение. Не обязательно дожидаться результата выполнения этой задачи, чтобы ответить пользователю. То есть вы с помощью селери, а просто повышаете отзывчивость вашей системы.
Так, Михаил пишет: "Копируются классы вве или только ссылки?" Э, если честно, я ваш вопрос не очень понял. Что значит классы? Венf у вас по сути интерпретатор и библиотечки, да, исходники ваших библиотечек. Плюс
ещё всякие вилы с бинарными зависимостями. Что значит классы в этом контексте? Я не очень понял. Лучше, пожалуйста, ещё раз спросите вопрос.
И Григорий пишет: "То есть у меня всё нормально?" Да, я бы сказал, что у вас всё нормально, просто у вас несколько интерпретаторов, и это типа о'кей. А я про э отображается три питонным путатора. Да, я думаю, я вам ответил.
Олег пишет: "С каким уровнем знаний оправдано использование ИИ и агентов?" Давайте на этот вопрос, наверное, я в конце отвечу, а то мы сейчас очень много времени потеряем, нам уже нужно ко второму блоку переходить.
А, и вопрос от Арсения: где в проекте хранятся пароли? Но тут вопрос интересный, всё зависит от вашего проекта, да? Если вы ну как в нормальном проекте делается, по сути, у вас два варианта. Либо у вас это хранится в системе контроля версий, да, в Гитлабе, там, в Гитхабе, откуда вы деплоите приложение. А либо у вас это хранится в валте или в каком-то аналоге, то есть специализированном решении, которое создано для хранения паролей. Вот. Но если у вас простой проект, типа вы там, я не знаю, на какую-то ВПСку закинули архив и из этого архива запустили веб-приложение, то, в принципе, у вас может и на ВПэске в файле храниться пароль. если у вас туда никто не попадёт, кроме вас. То есть тут опять же нужно понимать, что какого-то идеально правильного ответа на ваш вопрос нет. Всё зависит от вашей ситуации. Когда-то риски незначительные, когда-то риски значительные, вам нужно придумывать более какие-то совершенные решения. Вот.
О'кей. Так, на мой вопрос никто не ответил. Ничего страшного. Давайте я пойду к следующей теме. Настройка локального окружения, собственно, то, зачем мы как бы здесь и собрались. И давайте с чего начнём? С того, что, ну, просто с помощью UV я настрою виртуальное окружение, да? То есть у меня есть P Project, в нём есть какие-то зависимости, и я хочу свой проект А, о'кей, Арсений пишет, ничего не было понятно. А так я запускаю UV S - это команда, которая делает две вещи. Она, во-первых, создаёт виртуальное окружение VNF и сразу же в это виртуальное окружение ставят все нужные пакеты. Вот смотрите, как быстро это отработало, да? Кто привык там работать с Пипом или с пойтри, вы, наверное, сразу заметите разницу, что UV работает гораздо быстрее. Он так много зависимости поставил почти что мгновенно. Вот. Ну, опять же, тут такая у него была подсказка ювелок, то, что я заранее запускал, но, в принципе, этот инструмент считается актуальным. Э и если безопасники VV отрубили, сейчас попробую ответить на этот вопрос попозже. А вот, собственно, теперь у меня есть UV, и я могу, в принципе, запустить своё приложение, да, я буду его запускать с помощью ювикорна, как было на моей схеме, и для запуска UVCORРN, а, так, я ещё не активировал виртуальное окружение. Вот теперь активировал. И теперь у меня есть UVCorn. И я хочу запустить свой App. Я напоминаю, что он у меня лежит в каталоге в модуле ASJI. И в этом модуле есть переменная АП. Я её, собственно, и запускаю. И первое, что я вижу, э, это то, что у меня приложение попыталось запуститься, но ему как раз не хватило переменных окружения, да, он попытался создать настройки для аутентификации, но так как я запускал без указания переменных окружения, у меня ничего не получилось. Соответственно, я могу с помощью flocal это сделать, да? То есть здесь указать экспорт, там указать все нужные переменные окружения, потом сделать что-то типа source nfcal, да, чтобы засоурсить вот эти переменные, чтобы они у меня были в моём шеле в баше в данном случае. Но на самом деле есть вариант попроще. Я могу с помощью UV run просто указать флаг Nфile и путь до файла, в котором у меня лежат переменные. И, э, UV, когда будет запускать команду, которую я ему передам дальше, он автоматически сам засоурсит этот файл, и переменные будут доступны в окружении этого процесса. Соответственно, если я сейчас так напишу, у меня совершенно нормально запустится моё fast приложение с помощьюкорна. И я даже смогу его открыть в браузере. Сейчас вот я зайду в браузер, открою свой аpi приложуху. И вот, пожалуйста, видно свагер, да? То есть наше приложение запустилось. Но если я сейчас попытаюсь в нём что-то сделать, например, создать пользователя, я получу internal server error, потому что у меня не активирована база данных, да? То есть я в своих переменах окружения указал, что приложуха должна подключаться к пасгрессу, который вот здесь вот находится с такими кредами, но я этот пасгресс не запустил. Соответственно, что мне нужно делать? Мне нужно запустить пагress. То есть это моя первая зависимость. Сейчас я интерпретатор выберу, чтобы он не ругался на то, что у меня нет пакетов. Вот теперь не ругается. И давайте зайдём в docker complз. То есть все зависимости мы будем ставить с помощью композы. И я не буду изобретать колесо. Я прямо так и напишу poгress docker compose. А чтобы увидеть пример вот этого яamo файлика, который позволяет нам запустить Passgrгress. И давайте я его прямо скопирую. Сейчас я вам побольше сделаю. Вот. А, скопирую его, вставлю свой docker compose. Что здесь мы видим? Вот писать не очень хорошо. Давайте укажем какую-то явную версию. Рестарт пусть будет, ничего страшного. И здесь указываются креды, которые будут создавать пользователь и базу данных при запуске вот этого вот контейнера. У нас креды немножко другие. Давайте я их возьму из NFCAL файла. User у нас называется Otus User Password Otus Pass и база данных, которую нужно создать USD. И заметьте, что я указываю порт 8432. Соответственно, я, когда буду запускать контейнер, я хочу, чтобы он на моём околхосте, да, на моей хостовой машине слушал 8432, а внутри сам процесс посгреса внутри контейнера слушал порт 5432, то есть стандартный по порт а постгреса. И volums я использую для того, чтобы создать виртуальный том и этот том подмонтировать к контейнеру, чтобы я мог его остановить и потом запустить заново. И данные у меня остались, потому что если я запущу вот так вот свой сервис композный, а каждый новый запуск будет создавать новые данные, то есть у него не будет какого-то постоянного хранилища. А вот с помощью Volume я создаю что-то типа виртуального постоянного хранилища. И давайте запустим, да, напишу Docker Compose up. И у меня уже Постг 15 был скачан, поэтому он сразу создался. создалась сеть для композы, создался волюм, как раз-таки вот этот вот, где будут храниться данные погри и создался контейнер DB о. И по логом контейнера мы видим, что всё у него хорошо. Теперь давайте снова запустим приложение. Я сразу тут покажу э свой lae jon. Я буду запускать приложение с помощью вот этого вот файлика, да, как отладка. В пачарме есть, в принципе, что-то похожее, просто там оно немножко по-другому выглядит. Там нужно через интерфейс настраивать. А здесь это вот такая джисонина. А что здесь происходит? Ну, по сути, здесь то же самое, что я писал руками, да? Вот это вот я писал UVCORN, а appgup. И здесь делается ровно то же самое. И ровно так же передаётся файл с переменными окружения. Так, э, вопрос вижу. Сейчас на него в конце отвечу. Да или даже не в конце. Я думаю, сейчас вы сами увидите ответ. А давайте теперь я запущу приложение, посмотрю, что нам напишет наш фаста. Вот снова захожу на local host. Давайте тут же останемся и попробуем опять создать юзера с дефолтными полями. Опять internal server error. Но давайте теперь посмотрим на ошибку. Здесь уже ошибка поинтереснее. До этого у нас было написано, что пост не смог подключиться к базе данных. Теперь он пишет, что таблички users не существуют. То есть у нас логика начала работать, да? Вот я сейчас отвечу как раз заодно на вопрос, почему я запускаю не через compс, а просто потому, что мне таким образом удобнее проводить отладку, да? То есть я могу запустить в дебаггере. Ээ сейчас ещё раз. Вот я поставил точку останова на апоинтеen. Точнее я не на таке поставлю, а на юзера, потому что я пытаюсь создать юзера, да? Вот этот вот create user я ставлю здесь endpint. Когда я нажимаю execute в браузере, я из-за того, что я в отладочной сессии, я проваливаюсь в этот метод. Я могу здесь, э, перемещаться, могу провалиться внутрь метода, да, могу вызвать там какой-то посмотреть, что реально происходит. Вот тут вот в момент комита у меня как раз-таки выбивается ошибка, потому что такой таблички не существует. Это как раз-таки вот ответ на вопрос, почему АП не запускается в композие. В принципе, можно и в композить, если вам а не хочется отладкой заниматься, да, можно и в композить. Никаких проблем с этим нет. А, итак, что в чём проблема? У нас не существует таблички users. Как я говорил в начале, у нас есть омбик. Мбик - это та штука, которая как раз-таки нужна для того, чтобы у нас табличка users появилась. То есть нам нужно а запустить вот такую вот команду alic upgrade head. Это по сути означает то, что нужно накатить самую последнюю версию на нашу базу данных. Да. Вот если я сейчас так сделаю, опять же N file скажу в точку local и upgrade head. А вот запустилась эта команда, и я вижу, что отработал скрипт миграции, да, накатился вот это вот первая ревизия. И теперь в моей базе данных должна быть схема. Давайте я ещё раз попробую создать пользователя, да, какого-нибудь, неважно. Аа вот сейчас я уберу бреak pointит, потому что он у нас тормозит. И смотрите, что мы получили. Мы получили 200 ОК. То есть наш пользователь создался. Вот всё хорошо. То есть наша база данных работает. Вот можно видеть, что произошёл insert в базу данных. А видно, что users 200 ОК. То есть, в принципе, приложение работает. Но мне такой вариант не очень нравится, потому что я не хочу постоянно писать, а OLMIC upgrade head. Я хочу сделать так, чтобы в Docker Composer, когда я запускаю базу данных, у меня здесь где-то ещё и сразу запускался Upgrade Head. Как я могу это сделать? Ну, на самом деле, довольно просто. У меня есть мой Docker файл, да, с моим приложением. Давайте посмотрим, что там лежит внутри. Я напишу do app. Вот укажу контекст. Соберу приложение, а, в смысле образ докера. И давайте я это запущу в интерактивном режиме. Я зайду в контейнер, запущу в нём баш сессию и давайте посмотрим, что здесь лежит. А на самом деле здесь лежит всё то, что нам нужно для запуска Олембика. То есть внутри контейнера у меня уже есть возможность написать migrate head, да? То есть такая команда Олек существует внутри в виртуальном окружении, внутри контейнера, потому что я указал вот эту вот штуку, то, что в пути поиска бинарей, да, в нашем ПАВ, а лежит виртуальное окружение. Соответственно, все бинари, которые мы поставили VNF, они будут также доступны и в нашем контейнере. Вот, пожалуйста, список. Там и селери будет доступен, и Олемпик будет доступен. И я теперь хочу этой особенностью воспользоваться в своём компост файле. А, соответственно, я создаю сервис, называю его DB Migграor. А что этот сервис будет делать? Он будет состоять из имиджа, который я сам соберу, да, назову его отсп. А чтобы собрать образ, а, а не просто скачать какой-то из интернета, да, как в случае погрей, я напишу build точка. Это примерно то же самое, что там указать типа dockerфайл, а dockerфаile и контекст точка, да, чтобы вот это вот не писать каждый раз, я просто напишу такой shortcut build точка. А что я сделаю дальше? Ну чтобы теперь мне запустить upgrade head, мне нужно указать entry point. Соответственно, я скажу, что мой entry point - это то есть, когда запустится контейнер, в нём нужно запустить команду Олембик. И этой команде нужно передать аргументы. Аргументы передаются с помощью команд. И какие аргументы? Это upgrade и head. Да, всё просто. То есть, по сути, вот эта вот штука запустит мой контейнер и вызовет в нём внутрик head. Ровно то же, что я делал руками. А ещё тут полезно будет добавить такую директиву, как depends on, которая говорит о том, что вот этот вот контейнер нужно будет запустить после какого-то другого контейнера и в нашем случае после контейнера ДБ, после сервиса ДБ, потому что нам нет смысла накатывать миграции до тех пор, пока, извиняюсь, пока сам сервис ДБ не запущен. И что ещё здесь не хватает? А здесь не хватает указания переменных окружения, да? То есть проще всего опять же воспользоваться нашим файлом ENF local указать путь к то local. И на самом деле тут не всё так просто, потому что мы запускаем эту штуку внутри Docker Compose сети. И заметьте, что в нашем локальном файле я обращаюсь к хосту по адресу 12700 и порту 8432. Но когда я запущу DB мигратор, он, если пойдёт на 127001, он придёт сам на себя, а ему нужно прийти вот сюда, вот на этот сервис. И, соответственно, я хочу немножко переопределить а переменный окружения. Так оно пишется. Вот так вот оно пишется. И я говорю, что вместо вот этого вот database host ты должен ходить на DB, то есть вот в этот вот сервис. И вместо вот этого database порт ты должен ходить на порт 5432, потому что именно этот порт слушает, а, контейнер внутри Docker сети, Docker Compost сети, которую мы создаём. Итак, теперь я вышил из своего контейнера. Давайте я сделаю вместе с volumes, удалю наш Passgrгress и все данные, которые лежали в этом волюме, благодаря вот этому флагу можно удалить. И если я теперь снова запущу Docker Compose up, я увижу, что у меня точно так же создаётся база данных. Но ещё и при этом у меня запускается второй контейнер, который выполняет миграции. Да, вот видите вот этот вот лог. Соответственно, теперь, если я запущу своё приложение fastе, у меня уже сразу будет готова база данных. И в этой базе данных уже сразу будет готова схема. То есть я просто запустил compсs и у меня по сути уже всё готово. То есть вот я могу создать пользователя, он успешно создался. Вот 200 ОК. А, соответственно, мы по сути вот на данном этапе, э, автоматизировали, э, создали копии сервисов для двух компонентов, для, ну, точнее, для одного компонента, для нашего постгресса, да, но мы при этом создали саму базу данных и накатили на неё миграции с помощью олембика. И сделали мы всё это одним шагом, что, в принципе, очень удобно. А следующий этап, если смотреть на нашу схему, у нас есть ещё селери, который требуется, которому требуется readyс. Значит, давайте точно так же дис запишем, запустим в докере. То есть вместо прогресса давайте запустим дис. Я опять не буду с нуля это всё писать по памяти. Давайте так и сделаем. Разве что вот этот драйвер нам не нужен. Он и так локал. Нейронка нам фигню подсказала. И вот он назвал кэш. Ну давайте назовём его, чтобы было понятнее. Вот он сразу указал рестарт овость. Пусть тоже будет 6379. Мне не нравится, потому что у меня локально он может быть занят. Я пишу 8379. Ну и волюм точно так же, как с пазгрёй, чтобы при рестарте а всё было о'кей. И тут, смотрите, он нам предлагает запускать дис с командой, да? Вот смотрите, здесь команд написано как список, но, в принципе, никто вам не мешает это писать как строку в одну строчку, но список как будто бы более понятный. А, и он советует запускать дис с паролем, но я с паролем не хочу, потому что мы локально разрабатываем. Нафига нам пароль? Давайте просто запускать redis с беспарольной аутентификацией. Вот. Соответственно, RedСis мы запустили, ну, не просто так, а для того, чтобы запустить worker, хотим ещё здесь создать, запускать и сериit. Вот. А, собственно, здесь идея такая же. Мы собираем docker файл, а, в котором у нас, а, уже есть бинари для вызова селери, да? Если я опять вот сейчас это стопну, зайду в наш Otus AP, здесь уже есть всё для запуска селери. Вот я вызвал селлери, получил подсказку, как его вызывать. И я этой особенностью точно так же воспользуюсь, как и в случае ДБ мигратора. Я прямо всё скопирую. Единственное, что, а, так, извиняюсь, это мне надо закрыть. А, скопирую и запущу Worker, который по сути тоже будет состоять из нашего приложения, но будет у него отличаться entry point. Я буду запускать селери. Чтобы запустить селери, ему нужно указать флаг ап. Флаг app - это, по сути, путь до нашего селепа, да? Вот у нас лежит app.sary up. Я так и напишу app salary up. Вот. Также я сделаю скажу, что мне нужно запустить воркера, да, а не что-то там другое. И давайте для наглядности, чтобы видеть, что воркер работает, добавим ему Level Dbag. И заметьте, что здесь depend, ну да, от DB и от Редиса, потому что нашему воркеру нужно и в Redis уметь ходить, и в базу данных. То же самое касается переменных, да, так как вот это приложение, ой, я его никак не назвал, да, назовём его worker, будет запускаться в акеer compose c общаться и с базой данных по имени сервиса, и с нашим с редисом тоже по имени его, а так как он называется в докер композие. Поэтому я здесь переписываю значение переменных окружений seller и broker URL. Я оставляю, потому что это, ну, типа протокол. И вместо 12700 я пишу название сервиса. Вот так вот. И порт, который этот сервис слушает внутри. И здесь то же самое. Заметьте, что только разница в том, что, а, брокер у нас нулевая база данных, у нас первая база данных, но это один и тот же инстанс редиса. И второе, что я делаю - это я хочу запустить сериit. Bit запускается практически идентично. Это то же самое сери приложение, только вместо воркера я указываю бит. Ну и тоже давайте у него level оставим debug. А так в остальном ничего абсолютно не отличается. И давайте я выйду из нашего контейнера и запущу Docker Compose up, точнее, и посмотрю, что у нас происходит. У нас запустился дис, у нас запустилась база данных, у нас миграции вернули ноль. Ну, точнее, ничего не сделали, потому что у нас уже сохранились данные из предыдущего запуска. Но смотрите, у нас запустился серикеer, и мы видим, что он реально работает. Он подключился к нашему селере, к нашему Редису, извиняюсь, который у нас в Docker Comp. И где-то здесь бит бит у нас тоже запустился. Вот бит говорит, что он каждые 30 секунд будет а отправлять запрос. Да, ссылка на проект обязательно будет. Я её и сейчас на следующем этапе пошарю и вместе с презой. Собственно, вот то, что я, в принципе, хотел показать, да, то, что мы с помощью композа, с помощью вот такого вот doкер файла смогли, а, создать все инфраструктурные компоненты, которые нам были нужны. То есть вот, если глядеть на эту схему, да, то она превратилась вот во что-то такое. То есть UVCORN и Fast API я запускаю локально у себя на хостовой машине, а в докере, в докер сети я запускаю все остальные компоненты. Опять же, а, как уже писали в чатике, почему я UVCorn фаast запускаю локально, просто потому, что так удобно. Но опять же, никто вам не мешает, например, серикер запустить на своём хосте, который будет также ходить в погрес и в Redes на в Докере. То же самое можно сделать с битом. Вам никто не мешает вот эти компоненты, как вам удобно перемещать. Если вам, например, нужно поставить точку остановы там в воркере, да, и вам не хочется заморачиваться, вы можете его просто запустить локально и указать ему ходить вот в этот постгрес и в этот редис. Вот. А, Михаил, у меня Python. Сейчас я отвечу на ваши вопросы. Так, я открываю презу. Это была вторая часть наша, да, нашего маршрута. И напишите, пожалуйста, в чатик, о каких новых способах подготовки локального окружения вы узнали и что из этого планируете у себя применять. Так, а я сейчас попью воды и буду отвечать на вопросы.
Итак, давайте пойду по порядку. Первый вопрос был: "А если безопасники UV отрубили?" Ну так меня слышно, да? Ну на самом деле тут я вам помочь не могу, но обычно во всех компаниях, если вам что-то отрубают, вам делают какие-то зеркала, да, зеркальные репозитории. И, скорее всего, какая-то версия UV, которая прошла аудит безопасности, у вас в компании должна быть. Возможно, не самая новая, но какая-то точно есть. И вы, в принципе, можете ей пользоваться. Вот. Надеюсь, я на ваш вопрос ответил.
Арсений Михаил пишет: "UV через Докеer запустить можно без установки". Да, вы совершенно правы, можно запустить без установки, но просто будет сложнее, потому что вам придётся там прокидывать волюм и так далее. В принципе, UV - это инструмент, который локально запускать гораздо проще, потому что у вас есть такая штука, как UVX, да, есть такая штука, как UV Tool. И если вы будете запускать это каждый раз в докере, как будто бы смысла не особо много, потому что вам придётся каждый раз прокидывать волюм до вашего локального там типа Local Cash, да, где там UV хранит версии питона, хранит инструменты. Как будто бы UV один раз установить и забыть про это гораздо удобнее, да, моё такое личное мнение.
А дальше Михаил пишет: "Почему АПП не поднимаем через DoК compos?" Я в принципе на это уже ответил, да, потому что мне так удобнее дыбажить. И далее вопрос от Михаила. Ап дыбажить можно и в compу, смотря как доке идж собран. Да, тут вы совершенно правы. Можно сделать так, но это как будто бы просто больше времени. А это в принципе о'кей, да? Вам придётся просто запускать удалённый а сервер для отладки и в вс-коде или в пайчарме подключаться к этому серверу. Так сделать можно. Это просто сложнее. Типа для этого урока это точно было бы очень такой сложной для восприятия информации. Поэтому я просто показал, как удобнее. В реальном проекте, конечно, вы можете сделать и так, и в каком-то смысле это даже будет лучше, потому что вы таким образом сможете там и в кубе, и где-то на удалённой ВПэске дебажить своё приложение. То есть то, что вы говорите, это очень правильно. Просто вот в нашей лекции я пошёл другим путём.
А опять Михаил пишет через команд Олембик запускать, да? Это всё правильно. Мы по сути так и делали. Запускали олембик и запускали селлери.
Григорий пишет: "Что лучше: потри или UV? Хочу уйти с ПИП". А на самом деле я вам предлагаю попробовать и то, и то, да, понять для себя, что вам лучше. UV он такой как комбайн. Там одной командой можно и ВН создать, и питон установить, и пакеты все установить. Пойтрий он более такой как бы как бы как сказать а императивный, да? Вы ему говорите: "Установи потри". В смысле, установи пакеты, установи виртуальное окружение. Python сам ставить он не умеет. Поэтому, если вы хотите прямо быстро что-то запускать, используйте UV. Он сейчас на хайпе. Там сейчас все современные проекты на него переходят. А, то есть можно сказать, что потри он как бы уже идейно устарел, но если на вашем проекте используются потри или если вы придёте работать, а там будет потри, а вы знаете только UV, будет не очень. Поэтому я вам и предлагаю попробовать опа. Они, в принципе, не сильно отличаются, но если вы попробуете оба, вы будете лучше понимать вообще, как они работают, да, на абстрактном таком уровне. А освоить какую-то конкретную фичу либо UV, либо пойтри - это там вопрос, не знаю, часа.
А Михаил пишет: "UV на раст шустрее". Да, это абсолютная правда. Особенно если у вас огромный проект с огромным количеством зависимостей, вам UV это must have, он очень быстро резолвит деревозависимости по сравнению с PE. Там, типа, если вы пришли в большой проект и пишете poet reinstall, у вас установка может занять, ну, я не знаю, там минут 10 спокойно, 20, если это реально большой проект. А если вы напишите UVS в этом же проекте, у вас там установка минут за несколько завершится.
Григорий пишет: "Кирилл, ссылка на проект будет?" Да, будет. Я скоро скину.
Григорий пишет: "Михаил, у меня Python". На самом деле то, что UV написано нараст, это не значит, что вам нужно, ну, типа вы не должны писать на Пайthне, да? Это просто утилита. Исходный код написан на раз, но ничего страшного, вы можете её использовать. Например, в Пайтоне довольно частая тема, что какие-то высокопроизводительные штуки пишут на расте. Вот, например, PIDНТИК, который мы сегодня смотрели, он используется для сериализации, для валидации.
моделей. И вот это вот ядро, которое выполняет сериализацию, оно написано на Rust. То есть у Пайна такой интерфейс, API-шка такая, ABI в каком-то смысле, которая позволяет в него инжектить другие языки без проблем. Ну, до тех пор, пока вы соблюдаете вот этот вот Application Binary Interface. Ну, не API, ну, типа, наверное, это лучше назвать ABI, нежели API.
Э, Михаил пишет source.Nflocal Flb мигра. Я так понимаю, это ответ на вопрос. Спасибо за ответ. А отвечаю, да, Григорий пишет: "Отвечаю вопрос на слайде. Планирую перейти с PIP, только пока не знаю, куда: на Poetry или UV". Ну, в принципе, я думаю, я вам ответил, да? Вы можете для себя решить на основе моего ответа. И Дмитрий пишет: "Сразу UV".
Ну, опять же, можно и сразу UV, если хотите быстрее и использовать хайповый инструмент, можно сразу UV. Но опять же, потратить там, не знаю, вечерок, посидеть, почитать доку Poetry. На самом деле дока Poetry очень, э, ну, хорошо написана, там всё расписано подробно. Она местами даже написана лучше, чем DOC UV, потому что DOC UV она такая, знаете, для тех, кто уже шарит. Типа вы знаете, что хотите найти, и вы в этой доке уже просто ищете, как это сделать. В случае Poetry, она такая более user-friendly, она вам объясняет сначала концепции, потом как эти концепции реализовать. UV вам концепции объяснять не будет. Он вам просто скажет: "Если хотите вот это, делайте вот так вот". Поэтому потратить вечерок на Poetry не будет лишним. Вам это точно, ну, как бы хуже не сделает, да? То есть лучше попробовать и то, и то. Опять же, если вас время не ограничивает, если вам нужно завтра там выходить на работу, где UV, учите UV, забудьте про Poetry.
А, о'кей. Следующий наш пункт — деплой в Kubernetes-кластер. Да, вы всё правильно поняли, Григорий. Лучше попробовать и то, и то. Но опять же, если времени мало, лучше попробуй что-то одно. И я советую UV просто потому что он быстрее, он более популярный. Вот, давайте я остановлюсь. А, да, время есть. Отлично. Тогда попробуйте оба. Вы точно, ну, от этого ничего не потеряете.
Итак, я говорил, что я поделюсь ссылкой. Давайте я сразу поделюсь ссылкой на проект. Я его сохранил в GitHub. Lesson Up. Он публичный. Вы можете его прямо сейчас даже чекаутнуть. И если есть у вас где-то кластер Куба локальный или удалённый, можете даже попробовать за мной что-то повторять, если вам интересно. А я перехожу в редактор кода, и я буду говорить, что мы вообще хотим сделать. Ну, мы, в принципе, разобрались с тем, как это запускать локально, да? Теперь давайте сделаем примерно то же самое, но уже в Kubernetes-кластере.
И вот наша диаграммка того, как будет выглядеть наше приложение, когда мы его задеплоим в Uber. Вот смотрите, у нас точно так же это остаётся веб-приложением, с которым пользователь общается по HTTP-протоколу. Но смотрите, как поменяется структура. Во-первых, PostgreSQL и Redis у нас уже не обязательно должны запускаться там же, где запускается приложение. В общем случае это может быть просто любой удалённый кластер. А забегая вперёд, скажу, что в нашем случае PostgreSQL и Redis будут запускаться в том же самом кластере, но просто для удобства, чтобы не переусложнять, потому что для понимания концепции, на самом деле, неважно, где именно они запускаются.
А у нас на входе в кластер будет специальный Load Balancer сервис, да, это такая кубовая сущность. Э, в нём, по сути, будет работать, да? Кто знает, что такое, он у нас будет выступать таким reverse proxy. И проксировать, точнее, реверс-проксировать запросы он будет на наш Uvicorn, на наш веб-сервер. Но из-за того, что это всё запускается в Кубе, нельзя проксировать трафик просто на под, а перед подом должен стоять сервис. То есть ещё одна специальная сущность Куба, которая называется сервис.
И наши вот компоненты, которые мы запускали в Compose: Uvicorn, Celery Worker и Celery Beat, они будут запускаться как отдельные деплойменты в рамках кубовых как бы ресурсов, да, это называется Deployment. В деплойменте есть под, и в подах будут у нас по одному контейнеру. Почему именно так, забегая вперёд, возможно, у кого-то такой вопрос возникает, просто потому что таким образом нам будет удобнее скейлить инстансы. То есть, если бы мы все поды запихали в один деплоймент, мы бы не могли их скейлить независимо, а нам нужно их скейлить независимо, потому что у нас может появиться повышенная нагрузка на API-шку, тогда мы захотим создать ещё один под. Но при этом повышенная нагрузка на API-шку не означает, что нам нужно создавать ещё один воркер.
Или наоборот, у нас может быть обратная ситуация, когда у нас повысится количество задач. О'кей, Григорий убегает, тогда посмотрите в записи. Спасибо за вопросы. А если повысится нагрузка, количество задач вырастет в очереди, да, воркеры не будут справляться, мы захотим заскейлить воркеры, создать ещё экземпляры воркеров, чтобы они побыстрее разгребали очередь задач. Вот по этой причине мы запускаем их изолированно, потому что нельзя сделать так, чтобы в рамках одного пода мы заскейлили один, в рамках одного деплоймента мы заскейлили один под, а второй под не заскейлили. Мы можем заскейлить только деплоймент. Соответственно, если в деплойменте два пода, у нас появится ещё одна копия, а нам этого не нужно. Это просто расточительство ресурсов.
Вот. И, как я уже сказал, у нас Redis и PostgreSQL будут запущены внутри кластера просто для удобства. Вот это обзорная схема того, что мы будем делать. Теперь давайте уже ближе к делу, к деталям. Вот здесь в репозитории я вам как раз скинул ссылочку, да, можете повторять за мной. Здесь расписана, как сказать, инструкция, как это всё запустить в Кубе.
В качестве Куба я буду использовать такой инструмент, такую утилиту, как Kind. Kind — это сокращение от Kubernetes in Docker. То есть мы будем запускать кластер Кубернетиса с помощью Docker. Как бы странно это ни звучало, но такая возможность есть. То есть Kind запускает несколько Docker-контейнеров, и каждый из этих контейнеров выполняет свою определённую роль в кубовом кластере. Да, это Control-компоненты, это Worker-компоненты. У нас будет простая инсталляция, у нас будет всего одна нода кубовая, да, в кавычках. На самом деле это будет Docker-контейнер, который будет одновременно и воркером, и Control-компонентом.
А запуск контейнера написан вот в файлике local cluster.sh. Да, чтобы это сделать, вам нужна утилитка Kind. Возможно, у кого-то есть. Можете запускать вместе со мной. И что я делаю? Я захожу в K8S, а, ну, указываю имя кластера, у нас он будет Otus Kuber называться, и запускаю его создание. Вот вы видите, что пошёл процесс создания кластера. Создаётся, как раз-таки запускается Control Pod, вот это наш Docker-контейнер. Он использует образ kindest v1. И вот нам предлагают переключить kubectl context на наш созданный, что такое? На наш, так, почему он не реагирует на наш созданный кластер. Вот.
А теперь, а тут такая сложная штука. В конце, кому интересно, можем остаться. Я объясню, что именно тут происходит. Но суть в том, для того чтобы можно было добраться до нашего кластера снаружи, да, из извне Куба, у нас должен быть Ingress-контроллер. И чтобы этот Ingress-контроллер получил какой-то IP-адрес, к которому можно обратиться, я запускаю вот такую вот специальную штуку. Она называется Cloud Provider Kind. Э, приложил ссылочку, можно почитать про него поподробнее, что именно он делает. Там есть документация. А пока что примите как факт, что он у нас запускается в кластере и нам это нужно.
Далее идём смотреть, что мы запускаем дальше. Мы будем запускать PostgreSQL, да, как я сказал. Давайте я буду вот здесь это делать. Сейчас я сделаю шрифт побольше. Напишите, пожалуйста, плюсик, если вам видно, что я здесь делаю в терминале. Ага. Плюс. Спасибо. Вот я буду создавать PostgreSQL. У меня просто почему-то VS Code начал неправильно реагировать на команды. Он думает, что я жму Ctrl V, Ctrl Shift V в редакторе, а не в терминале. Вот я создаю кубовый namespace postgres, называю его. В этом спейсе я создаю деплоймент, в котором будет один под, и в этом поде будет крутиться наш PostgreSQL. И чтобы другие поды могли с PostgreSQL общаться, я создаю сервис. То есть сервис — это такой специальный компонент в Кубе, специальный ресурс, который нужен для того, чтобы обеспечивать сетевую такую связанность между подами.
А помимо PostgreSQL мне ещё нужна Redis. Я создаю Redis. В этом спейсе я точно так же создаю деплоймент, в котором всего один контейнер. И в этом контейнере запускается Redis. И точно так же я создаю сервис, чтобы с помощью сервиса можно было обратиться к нашему контейнеру внутри пода. Вот я его запустил. Давайте с помощью утилиты K9S, это такая тулза удобная для того, чтобы смотреть, что происходит в кластере, я посмотрю, что я в итоге создал. Вот перед вами список неймспейсов. Я создал namespace postgres и namespace redis. В неймспейсе postgres у меня есть один под. Да, вот, пожалуйста, postgres. А я могу посмотреть его логи. У него всё хорошо, он запустился. А то же самое я могу зайти в namespace redis, посмотреть на под Redis. У него тоже есть в логах, что всё хорошо. Вот запустился Redis, он работает. Вот. То есть я создал такую подготовительную часть.
И, э, чего ещё не хватает в нашей подготовительной части — это, собственно, создание Ingress-контроллера, то есть чего-то такого, какого-то такого компонента, который за нас создаст вот этот вот Load Balancer, чтобы трафик мог попасть извне, снаружи из внешней сети в нашу кубовую сеть. И я это делаю с помощью Helm. Helm — это такой DevOps-инструмент для установки а различных штук в Куб. И вот он у меня почему-то не хочет ставить. А потому что нет, я вроде засорсил. Давайте ещё раз. А, не хочет. Не знаю. Короче, у меня с сетью бывает какая-то проблема, то что вот эта штука Helm не может почему-то достучаться до моего кубового кластера. Давайте чуть-чуть подождём, может быть, он подумает. Если не подумает, я сейчас просто кластер переустановлю. А,
Python remote debugging, а настроить вот такую вот штуку. То есть, у вас будет в вашем процессе с вашим веб-сервисом будет слушать ещё один сокет, к которому вы откуда-то сможете подключиться удалённо. Это супер небезопасная штука. В проде так делать вообще нельзя, потому что любой сможет подключиться к вашему приложению и что угодно с ним сделать. Да, у него будет фактически полный доступ к вашему приложению: ко всей его памяти, ко всем эктрейсам, ко всем сисколам и так далее.
А, да. Ну, то есть, я надеюсь, я на ваш вопрос ответил. Если вкратце, вам нужно гуглить, что такое Python remote debugging. Про это можно долго рассказывать. Лучше будет, если вы сами это погуглите, с этим разберётесь. Тут, в принципе, ничего сложного нету. Вот даже есть официальная дока. Да, также в новых версиях питона это всё постоянно развивается, так что просто советую вам почитать самостоятельно. Я вот, давайте, даже ссылочку в чат скину.
Михаил пишет: "В подт может быть несколько контейнеров". Да, совершенно верно, может быть несколько контейнеров.
Просто я вот в нашем примере объяснил, почему я сделал отдельные депломенты, чтобы их можно было скейлить независимо друг от друга.
Соответственно, если у вас такая, что у вас реально одно приложение, точнее, один деплоймент, и контейнеры не имеют смысла друг без дружки, да, тогда вы можете запускать несколько контейнеров в рамках одного пода. Это не проблема. Плюс ещё в кубернетесе есть такой паттерн, как сай con контейнеer, да, когда вы запускаете какой-то функционально полезный контейнер, который работает вместе с вашим приложением. Например, там отвечает за аутентификацию или авторизацию, да, там за airbag какие-то политики и так далее.
Так, есть ли ещё вопросы, или пойдём дальше поговорим про, собственно, сам курс OTUS US?
Давайте я опять перешарю и пошарю вам вкладку.
Да, вот, Михаил, вы всё верно пишете. Вы, видимо, опытный разработчик. А сайка как один из принципов, ну, использования способов — это, да, подгрузка переменных как раз из того же Валта, чтобы не хранить переменные в поде, не хранить их в своём контейнере, да, вы используете сайтка, который знает, как за определённой переменной сходить в или в какое-то другое удалённое хранилище. Вот.
Итак, давайте поговорим про вообще курс от Python, от OTUS.
Вот это вот наше занятие проходит в рамках открытого урока по курсу "Python разработчик", да, от компании OTUS.
А в компании OTUS есть три основные линейки курсов, связанных с Пайthном. Они делятся по сложности, по длительности.
А самый первый — это "Python разработчик базовый уровень". Это, по сути, курс для новичков, да, кто там что-то для себя уже учил, но вам показалось сложно то, что постоянно нужно искать какую-то информацию, а вы хотите всё в одном месте, чтобы за вас уже кто-то её собрал, отделил нужное от ненужного, да, и предоставил вам всё необходимое для того, чтобы найти первую работу. То есть, на этом курсе вы звучите ключевые Python фреймворки. Это джанга, это работа с ОРМка, с СQэлем, да, какие-то первые проекты, связанные с бэкэндом. То, что на этом курсе предполагается курсовая работа — это какой-то большой проект, который, в принципе, можно добавить в портфолио, да, и кому-то показать. Ну и, в принципе, этот курс даст вам базу для первой работы джуном, потому что вы изучите реально актуальные, востребованные фреймворки. Это позволит вам найти работу первую.
А второй уровень — это "Python разработчик продвинутый". Я как раз преподаю на этом курсе.
Он уже подходит для тех, кто уже знает Python, да, кто уже джун как минимум, либо кто, а, знает другой язык программирования и хочет побыстрее вкатиться в питон, да, понять какие-то фишки питона, какие-то парадигмы. Опять же, чтобы самому это нигде не искать, просто приходите на курс, а вас это уже всё собрано, актуальная информация, вы просто её как бы получаете, делаете домашки, общаетесь с преподавателями. Таким образом, вы гораздо быстрее вкатываетесь в особенности питона.
Если же вы уже как бы пишете на Пайthне и так джуниор, да, этот курс вам даст более глубокое понимание самого языка, его специфики. Он уже больше направлен на какие-то инженерные штучки, да? Будете разбирать архитектуру приложения, как писать там более производительные high приложения, как уже настраивать се, какие-то нюансы работы в команде, да, там тот же гит, упаковка пакетов, сборка контейнеров, прокуп там тоже немножко будет и так далее.
И третья опция — это "Python разработчик специализация". Я вот вам даже ссылочку скину в чатик, чтобы вы тоже могли параллельно посмотреть.
Это, по сути, а, полная такая двухступенчатый курс, который состоит и из патный разработчик базового уровня, и из продвинутого уровня. То есть, если вы понимаете, что вы новичок и плохо шарите в Питоне, да, но точно хотите найти работу и не просто какую-то джуновскую работу, а, возможно, сразу на медла попробовать, этот курс вам как раз-таки подойдёт, потому что он, во-первых, будет выгоднее: если вы хотите пройти оба курса, вам проще купить сразу специализацию. И, э, по сути, он просто включает в себя два курса. Он ничем не отличается, просто более выгодная аа с точки зрения покупки.
И также есть специальная акция. Это мини-курс от, а, компании, которая сотрудничает с OTUS, называется ALGкоcд. И вместе с приобретением вот одного из курсов по Python разработке на платформе OTUS, вы также получите мини-курс "Покавка" или "System Design".
А в чём здесь смысл? Ну, смысл такой, что как бы одно дело быть разработчиком, да, знать там особенности Пайтона, какие-то фреймворки, и совсем другое дело — это искать работу. А у нас такая индустрия, что поиск работы — это отдельный навык, который нужно прокачивать, да, и как бы не секрет, что кто-то занимается этим намеренно.
И чтобы вы, опять же, не тратили какое-то своё время, есть компания Агокод, в которой есть эксперты, которые вас подготавливают именно к прохождению собеседований в какие-то бигтехи, на какие-то интересные для вас позиции, да, то есть это разбор, а, типовых задач там по тому же систем-дизайну, по кавке, да, это даже, возможно, у джинов это не спрашивают, но если вы претендуете на Mid, systemдизаign вас 100% спросят. И вот, по сути, компания Агокод помогает вам подготовиться к этому собеседованию, да, к каким-то его специфичным моментам, потому что с вами будут заниматься эксперты, которые сами работают в Бигтехе, которые сами собесят чуваков, и они, в принципе, понимают, что спрашивать, что от вас ожидать.
Так, идём дальше.
И для тех, кто уже находится в поиске, да, какого-то онлайн-обучения и знает про существование карьерных центров, а тут просто пару слов скажу, что как бы обучение в Отусе с поддержкой алгода, вот этого мини-курса в подарок бесплатного, оно просто будет, э, профитнее, выгоднее, да, потому что в карьерных центрах чаще всего с вами работают HR-специалисты, которые больше заинтересованы в том, чтобы подготовить вас к каким-то софтовым скилам, да, с точки зрения софскилов, типа объяснить, что нужно говорить на собеседовании, что от вас хотят услышать рекрутёр, да, как там правильно резюмешку заполнить.
Плюс у них общий подход для разных специальностей: там типа и фронтендеры, и бэкэндеры, и девопсы идут под одну к ребёнку, да, у них просто какой-то общий пайплайн, который они пытаются на всех натянуть.
Если вы выбираете OTUS и Алгокод, у вас, по сути, взаимодействие уже идёт не счарами, а с реальными программистами, которые реально находятся в профессии, которые знают внутреннюю кухню и могут вам посоветовать какие-то тонкости, какие-то лайфхаки, да, и в принципе, как бы вы будете развивать именно навык прохождения технических собеседований, потому что одно дело — подготовить резюмеху какую-то понятную, да, тем более сейчас это, в принципе, не сложно, там можно попросить, я не знаю, нейронку какую-то специальную, написать вам качественное резюме, но навыки прохождения технических этапов собеседование вам красивое резюме не повысит, да, соответственно, тут вот преимущество у правого подхода. Вот. И то, что ещё они учитывают специфику профессии, да, в которую вы идёте, типа там фронтендеров, скорее всего, не будут спрашивать systemдизаign так, как это будут спрашивать у бэкэндеров. Поэтому от этого зависит то, чему именно вас будут учить.
Итак, и ещё чуть-чуть про обучение тус, да?
Э, все выступления построены в живом формате. Вот как мы сейчас с вами сидим: есть лектор, он заранее подготовленную какую-то лекцию ведёт. Вы можете также задавать вопросы, вам будут на эти вопросы отвечать.
Что касается доступа к материалам, у вас доступ к записям остаётся навсегда. Если вы какую-то тему там плохо поняли, можете попозже её ещё раз посмотреть.
А что касается домашних заданий, здесь тоже такая интересная система. Это не какой-то автогрейдер, да, который вы там типа скинули задание. Он написал: "Всё классно, типа пять баллов". Здесь развёрнутый фидбэк. Э, преподаватель пишет, что вы сделали хорошо и почему вы сделали это хорошо. Он пишет, что вы сделали плохо и почему так лучше не делать, да? То есть, вот вы реально получаете какой-то как бы а основу для будущей работы, потому что вы шишки набили заранее и точно знаете, как на работе вы уже делать не будете, потому что ваш преподаватель объяснил вам, почему это плохо.
А что касается нетворкинга, тут, в принципе, очевидно, да: вы будете общаться с преподавателями, вы будете общаться с вашими однокурсниками, сокурсниками, вы будете находиться в такой среде общительной, да, всегда учиться вместе с кем-то интереснее, даже эффективнее, чем одному. И как раз-таки курс вот будет вам давать нужную среду.
А про проекты я, в принципе, сказал. Эээ, на каждом курсе или на специальности у вас будет два проекта. На каждом курсе — по одному. Это такая большая, по сути, домашнее задание большое. Вы сначала защищаете идею проекта, потом защищаете его реализацию. То есть, у вас будет такая типа как дипломная выпускная работа.
И, а, касательно актуальности и обновления материалов, а тут тоже всё хорошо продумано. После каждого потока и во время занятий на каждом потоке собирается обратная связь от вас как от студентов. Команда курса с этой обратной связью работает. Она заинтересована в том, чтобы сделать курс ещё лучше. И все какие-то пожелания учитываются. Плюс это также касается, в принципе, актуальности, да? То есть, курсы пересматриваются, их материалы тоже адаптируются, потому что, ну, нет такого, что вас будут учить какому-то древнему фреймворку, который вообще сейчас нигде не используется, да? Здесь будет только актуальная информация, с которой вы реально пойдёте на работу и на работе будете это использовать. Вот.
А тут есть QR-код: если успеете отсканить, там будет просто информация на на лендинг, ссылка на лендинг, которую я продублировал в чатик. Ээ, просто напомню, что у вас есть там время подумать насчёт этого курса до конца мая. А там все вот все три линейки курсов, которые здесь представлены, они стартуют плюс-минус в одно время. То есть, есть время подумать. Вот.
И, по сути, это всё, да, что касается коммерческого вот такой вот блока. Теперь давайте подведём итоги занятий, или, возможно, у вас есть какие-то вопросы. Вот, поэтому, в принципе, могу ответить. Спасибо.
Да, Михаил, подождите, ещё не всё, не уходите.
А, итак, если вопросов нет, то, а, у вас есть интенсив курса 5 дней в неделю, например? А вот то, что если говорить про Python, такого точно нету. Курсы длятся, точнее, проходят два раза в неделю. Там, в зависимости от ступени, там понедельник и среда, по-моему, и вторник и четверг. То есть, э, всегда курс проходит два занятия в неделю, если вот говорить о Python-курсах.
Итак, э, теперь я хочу, чтобы вы в чат ещё разок написали: вот здесь пронумерованы цели, которые мы в начале ставили. Напишите, пожалуйста, цифру или несколько цифр в соответствии с той целью, которую вы, по вашему мнению, сегодня достигли, да? То есть, вот вы вначале писали, что хотите получить, и напишите, пожалуйста, цифру, если вам эти знания, эти навыки удалось получить.
Вот, соответственно, 1, 2, 3 — только один. Угу. Один. О'кей.
Так, Михаил пишет: "1". Отлично. Михаил больше всех получил пользы.
Так, и давайте ещё подождём, пока кто-то пишет. Я параллельно скину, а, в чатик ссылочку. Да, тут она, в принципе, у вас прикреплена в в верху чата. Я её просто продублирую. А я её вставлю со своего второго аккаунта. Вот она появилась. Вот.
Кирилл, Кирилл Арсений пишет: "Я не знаю, а ни про Kubernetis, ни про Докеer, ни продис, ни про Селери, ни про Олембик". Ну что тут сказать? Э, в принципе, если интересно, можете приходить на курс, да, это здесь всё изучается. Это скорее изучается на второй ступени, то есть, на продвинутом курсе, в принципе. Также, а если вам интересно эта тема, в этом побольше разобраться, я вот в ссылке на репозиторий, по которому мы сегодня проводили урок, приложил ссылки на документацию этих инструментов. Там, в принципе, тоже можно со всем этим ознакомиться.
Вот, пишет Михаил. Ну да, тут, к сожалению, если у вас нету какого-то опыта, ну, работы с питоном, да, с этими инструментами, тут сложно что-то предложить. Нужно просто брать их и изучать. То есть, сейчас можно, в принципе, там нейронки написать, типа: "Придумай мне задание, чтобы я использовал докер", да? Типа: "Придумай какой-нибудь практически полезный мне таск, в котором я смогу воспользоваться докером".
Пишет: "Доступ запрещён". А доступ запрещён, наверное, потому что вы не авторизованы на сайте Оттуса. Там вот в закреплённом сообщении как раз написано, что для а прохождения опроса нужно быть авторизованным на сайте OTUS.
Итак, да, мы вышли немножко за временные рамки. Вот. А, соответственно, на этом моя увлечённый вопрос. Почему вершились Java на Python? Да, давайте сейчас я закончу официальную часть и попробую ответить.
А, собственно, всё, я закончил. Да, надеюсь, вы узнали что-то новое, что-то вы реально будете применять у себя на проекте: там, на новом проекте, на старом проекте, неважно. Посмотрите в репозитории, может быть, там какое-то вдохновение для себя ещё дополнительное найдёте. Ээ, спасибо за внимание, да, спасибо за вопросы, и надеюсь, увидимся ещё на курсах в Отусе, если я вас заинтересовал. Вот, я буду останавливать шеринг и поотвечаю ещё на ваши вопросы.
Э, Арсений пишет: "Отвлечённый вопрос: а почему вы перешли с Java на Python?"
А какого-то, наверное, прямо конкретного, однозначного ответа у меня нету. Мне просто понравился, наверное, синтаксис, то, что на Питоне было писать поприятнее, да, он был в каком-то смысле попроще, меньше бойлерплейта.
В целом понравилось то, что типа такая экосистема развивается, да, в Джаве там, например, есть один фреймворк, как он забыл, м, ну, короче, который все используют. А, Spring, Spring Framework, да-дада. Вот. И там у вас как бы выбора нету. Если вы хотите там писать на Джаве, вы учите, а Спринг — это такой огромный комбайн, который учит вас пользоваться только спрингом. На Пайтоне такого нету. Есть несколько фреймворков. Есть, в принципе, какая-то конкуренция, да: какие-то лучше, какие-то хуже. Вы, в принципе, когда их изучаете, больше узнаёте, в принципе, про устройство фреймворков, да, про устройство веба. Аэ, да и всё, наверное, просто понравился Python.
Плюс я на Питоне как бы скрипты писал ещё, когда работал на Джаве. И вот этим, наверное, тоже понравилось то, что типа: хочешь что-то сделать — просто пишешь скрипт, а не создаёшь там типа public main, не не устанавливаешь какой-нибудь маvнграду, чтобы это всё потом собрать и запустить и так далее. Там, плюс, в принципе, вот эти вот джарники доставлять на сервис, там, точнее, на хосты типа Томка использовать. Мне это каким-то таким, ну, не очень, короче, интересным показалось. Я просто пошёл на Python. Вот.
Да, Java более entтерпраis. Всё верно. Ну, на Пайthне. Плюс ещё что на Pйthне прикольно, то, что его часто используют для прототипирования. То есть, если вы пишете на Пайthне, вы, скорее всего, вот за свою как бы жизнь разработчика повстречаете, повидаете гораздо большее количество разных проектов, да, которые вам могут больше понравиться, какие-то меньше. А на Джаве, ну, вы, скорее всего, будете работать где-то в банке, типа там в банке, в каком-то и-коммерсе, возможно, а на Пайтоне свобода, она такая более, ну, как бы широкая, что ли, так.
Так, с каким уровнем знаний, а, оправдано использование ии агентов? Спрашивает Олег. Если Олег ещё тут, то, ну, наверное, хотя бы, чтобы вы, ну, осознанно, да, своими руками доросли до джуна плюс, до медла, потому что, а, использование агентов оправдано тогда, когда вы понимаете, что он вам сгенерировал какой-то бред. И если вы как бы не прокачали вот этот вот навык критического мышления, да, там не ревьюили чужой код, не писали свой код, вы не поймёте, что агент сгенерировал вам бред. И это в какой-то момент вам может просто обернуться не очень хорошо. Соответственно, если вы понимаете, что вы реально можете сами своими руками без агента написать то, что он вам написал, значит, вы готовы использовать агента. Если вы попросили агента, вам там что-то сгенерировать и вы не понимаете этот код, а, но он при этом работает, значит, агента использовать пока рано. Вам лучше набраться какой-то базы. Вот.
Тут вроде всё отвечал. Вот, вижу три дизлайка под презентацией. Наверное, про Kuber лучше не рассказывать. Можно было что-то попроще взять.
Так, Арсений пишет: "Мне просто когда понадобилось быстро скрипт для кавки написать, я написал дня. Не знаю ни про кавку, ни питон". Так, не совсем понял. Вы его написали на питоне? Не знаю, питон или на джаве за 3 дня.
Да, Михаил пишет: "Сейчас на Java спрос меньше, на Python больше, особенно для ML. И ай, да, это совершенно верно. Кстати, на Джаве есть фреймвор PMML, по-моему, называется Rime. Один из inference runнтаймов для запуска моделей. Вот он, как ни странно, написан на Джаве, или не PMML. Ну, короче, какой-то есть, но большинство, да, пишется на Пайthне, большинство, больше даже скажу, пишется с использованием Fast API, да, если вы там следили за новостями питона, то Fast API основан на фреймворке Starlet. И вот этот вот framework Starlet, он очень долгое время всегда был, э, версией ниже ноль, ниже 1. Да, то есть, он всегда был без релизной версии. Он всегда там был 0,9 какой-нибудь, 0,50, 0100. А когда вот начался вот этот вот форсмок, они все начали использовать fast API для обеспечения Open AP совместимого, а, ну, спецификации, да, протокола httтиtного. И, э, это настолько повлияло на развитие Fast API и, следовательно, на Starl, что Starl впервые за долгое время получил вот эту первую релизную версию. И сейчас, если вы посмотрите на Starl, он там один-ноль какой-то версии, а до этого времени можете сами посмотреть, сколько там было минорных релизов. Вот это что касается питона в эмле. Он он повсюду.
Арсений пишет: "На питоне написал". Java я знал, понимаю, как написать скрипт на Джаве. Прородил панику. Вот. Ну да, Python, он как бы и меньше от вас навыков требует, да. Если вам нужно что-то написать и забыть, то Python — это идеальный вариант. Но если нужно поддерживать, да, тут уже нужно соблюдать какие-то правила. Тут он, в принципе, уже будет больше на Java похож. Вот.
А если вопросов нет, спасибо за внимание. Ещё раз спасибо за вопросы. Ссылочки я вам все скинул, да, приходите учиться, и я буду завершать презентацию. Всем хорошего вечера.