Некоторое дополнение: в докладе я говорю, что нельзя генерировать рандомные данные по пайдентик моделям. После доклада мне подсказали - можно! С помощью hypothesis. Очень крутая библиотека, кстати.
сейчас в поисках работы и обнаружил что практически везде либо уже требуется FastAPI, либо собираются на него переезжать))) вообще люто быстро штука появилась и уже в энтерпрайзе во всю работает)))
@@PythonDevelopment Правильный подход))) Не забудь посмотреть и изучить Django, так как в нём куча архитектурных паттернов применяется, которые помогают лучше разобраться в том же Flask и FastAPI))) И помогают лучше понимать как организовывать и писать код правильно)))
потому что он не совсем самостоятельный. это если грубо то как в js есть TS. тоже и тут, ибо под капотом скарлет.😁 поэтому и результат таков. ну и api само по себе стало более популярно из-за сильной моды SPA. можно писать на Flask, но он сложный! он очень крут, но слишком сложный для большинства. был еще скарлет. он и сейчас есть. разрабы FastAPI посмотрели на скарлет, поняли что это еще сложнее чем Flask и его вообще все бояться.. решили людей подружить с скарлет и сделали FastAPI.😁
Никак. Наследование это не про Fastapi. Бери и пиши в каждой вьюхе все руками. Надо чуток изменить наследника? А их нету. Бери и ебашь руками по всей кодобазе.
@@anton6643 Теперь немножко не соглашусь, прошло уже 10 месяцев как я работаю с FastApi. Понятное дело тут классы не используются, но есть крутая штука которая называется Dependency. И при помощи нее можно очень много логики скрыть и обобщить))
@@poperechniy депенденси инжекшн в пайтоне ))) бгага, жабаскриптеры научились писать на питоне, но так как они не умеют в ООП, то принесли все свое говно с собой...
@@anton6643 🤣🤣🤣, ну мой первый язык это питончик, я даже не знал про эти инъекции в js пока не прочел про них от тебя тут. В целом мне нравится методология, спасибо за поднятое настроение
Спасибо! Да мне кажется мы в какой-то мере в этой ситуации. На большинство вещей есть фреймворк или библиотека. Но я думаю, что здесь возникает проблема: это еще потом собрать надо как-то вместе и не просто собрать, а сделать, чтобы оно не ломалось в 99 процентах случаев и могло быть дописываемо и обновляемо. Вот тут и пригождается инженерный талант и умение. Всё для всего есть, но программировать, в общем, не перестаём :)
По-моему, это бы было очень негибко. А так мы считай отделываемся include_router и дальше можем как нам нравится организовывать структуру. Это супер удобно и приятно. Из минусов, понятно, что у каждого своя идея как это организовать, но, мне кажется, это и не плохо.
@@xfenixws Не согласен, портянка из двух сотен роутов превращает код в сущий ад, создать из которого структуру апи можно только взяв карандаш или запустив код. Моя библиотека автоматически транслирует структуру каталога в апи и даже описания модулей попадают в swagger.
@@stanislavsheev7748 так в фастапи из коробки можно по разным модулям разбивать через include_router, как раз к этому я вёл. Можно разбить твои роуты по тегам и файлам как нравится, мы так и делаем. Кроме того, 200 роутов в одном сервисе это довольно много, возможно имеет смысл разбивать на отдельные микросервисы. Мы в нашем приложении так и делаем, один микросервис не тянет больше нескольких десятков роутов. И если у тебя есть такой модуль, как ты описываешь, почему бы тебе не показать его? Я звездочку на гитхабе поставлю :)
@@kandreyk9159 спасибо, вот я собственно так же считаю, поэтому так и сказал. Но коллегам не нравится. Возможно, они выступают за терминологическую точность или считают, что это некорректно. Но, комментариев, раскрывающих это, я пока не видел
О, привет, Егор :) да там проектор в первый день отлетал и предыдущий оратор сильно выбился из-за этого из тайминга, мое выступление в итоге сократилось и мне пришлось подстраиваться. Хотя, конечно, если уж быть честным, я в принципе стараюсь быстро говорить
Жаль только, что по итогу, фаст апи избавляет нас от кучи работы в 1 ситуациях и это всеми расхваливается, но так же накладывает на нас кучу другой работы, сделать которую по итогу гораздо труднее, чем пример про джанго
Если речь о бд, то да, дальше сложнее. Но на то он и небольшой фреймворк, что не затаскивает всё сразу. Когда тебе важна скорость, ты берешь его, алхимию или sqlmodel от того же автора и, в целом, вполне себе живешь.
@@xfenix3 Так в том то и дело, что не могу представить себе настолько маленький проект, чтобы спокойно обойтись одним фаст апи, а раз уж надо расширяться, то джанго подходит как ничто другое, НО...Ассинхронность... пожалуй козырь этого, на мой взгляд прекрасного но через чур распиаренного фремворка, конечно ассинхронность нужна и творит чудеса, но в среднем проект на фаст апи, как минимум пока-что, разрабатывать и поддерживать раза в 4 тяжелее и дольше, чем тот же на джанго. Плюс в джано, когда нужен сваггер, 5 строк кода и готово, что либо еще понадобилось? 5 строк кода и готово. Не хватает только ассинхронности полноценной. Ждем что будет дальше, учить конечно же нужно, банально полезно самому опуститься на уровень пониже, по сравнению с джанго.
@@Biongar мы у себя все бекенды пишем в довольно приличном по объему проекте на фастапи. У нас сотни ручек, около 15 микросервисов и все на fastapi. Нам важна скорость, т.к. все таки чат. Я соглашусь, что джанго миграции куда круче, чем то что ты сам можешь соорудить. Но когда речь идет именно о выстраивании архитектуры, отличной от очередной MVC вариации, тут у тебя чистый лист. Мы, например, активно используем многослойную архитектуру, dependency injector, sql alchemy и все это очень здорово работает. Плюс надежно, плюс быстро. Ну и в целом по банку все кто что-то стартует, стартуют обычно микросервисное, поэтому фастапи залетает на ура. Потом посложнее, конечно. Т.е. не соглашусь что раза в 4, максимум раза в 1.5 )). Но посложнее да, но для нас всех это еще и челендж в плане развития как инженеров. Джанго очень в этом смысле толерантен к уровню того, кто что-то делает. Это и плюс и минус. Ну и я просто уже лет 10 с джангой, мне лично надоело немного, поэтому я и в фастапи с ногами улетел. В целом, я честно считаю, что джанга никуда не денется и так же будет популярна. Но ей явно требуется реновация.
@@xfenix3 Спасибо большое за то, что расписали, многое подчерпну для себя, мне тоже после джанги фаст апи зашла, как я говорил ощущение что ушел на уровень ниже, я лишь говорю что фаст апи распиарена, это не к тому что фаст апи плоха, она прекрасна, но аргументы которые в ее пользу приводят спорные, по факту аргумент весомый только 1, фаст апи асинх, а джанго нет, явных преимуществ больше нет, ну опять таки, если не брать что для микросервиса джанго спорно подходит, а просто если сравнивать вот "фремворк для работы"
@@xfenix3 а чём челлендж развития заключается? Взять что-то сложное и пытаться заставить это работать, вместо решения которое будет работать без пыток? 🤔
😂 исходники там как обычно у фреймворков: для потребителей красиво сделаем, а внутри требуха. Но, надо отдать должное Себастиану, там все таки кода немного, это тонкая обертка вокруг starlette и pydantic. > Ну и не все живут RESTом И это неоспоримо. А для тех, кто живет - нормальный фреймворк.
Для тех кто не живет рестом и угорает по ультра хардкору! К вашему вниманию фреймворки propan и litestar. Для MQ первый целиком, у второго есть абстракции. Поэтому могу рекомендовать!
На слайдах говнокод чудовищный. Надеюсь, докладчик просто торопился. Еще он не понимает, что такое dependency inversion, к сожалению. Неприятно, что теперь такие доклады стали нормой(
Я понимаю разницу, но действительно допустил ошибку. Так что тут извините, уже писал об этом в комментариях. Это примерные куски, конечно, не реальный продакшн код. Некоторые куски из официальной документации FastAPI. Но если, разумеется, есть более конкретные комментарии по слайдам - не стесняйтесь поделиться. А про то, что «такие» доклады стали нормой: я вообще один доклад тут сделал, у других докладчиков они лучше, посмотрите с этой конференции, было много хороших докладов. Призываю не раздавать несправедливые ярлыки коллегам из-за моих ошибок :)
@@xewuss3750 да вот теперь посложнее ситуация в мире началась. Про местную я не говорю... Теперь придется пробиваться в индустрию, скорее всего. Думаю, пару лет и ситуация изменится, но в моменте все тоскливо.
асинхронность как бы всегда была если че.. просто мало кто знает что асинк это сахар над генератором.🤣раньше просто на том же Flask писали асинхронность с помощью генираторов. оно больно, согласен, современный подход прост и понятен всем. ну и FastAPI, это не прорывной фреймворк а просто взяли чудище скарлет которого боялись все больше чем Flask, отмыли, постригли, косметикой помазали, духами пшик и все, народ уже не так сильно боится скарлета. главное не говорить им что это скарлет.🤣часто слышу тип - "в доках fastapi все слишком просто приведено, остальное надо самому додумывать искать и тд..". те кто в теме, если им не хватает доков fastapi, ищут доки скарлет и реализации, ну и тд.. на скарлет.😁для api он хорош. но не под все он подходит, гора нюансов все же за плечами висит... с Flask все ок, просто мало кто умеет его готовить и от этого инфы тоже не много.. поэтому большинство или на Django, или FastAPI (если адекваты то выбирают под задачи).😁
Ну так и есть, по сути. Отмыли, постригли и это то, что людям и нужно было, по сути. Получилось не так уж плохо. В этом году обратил внимание на его конкурента - litestar, мне он больше понравился и о нём я тоже сделал доклад!
Так ну у нас что не день, то новый фреймворк. Ребят, там еще esmerald подвезли! Лайтстар уже затащили в прод, я сделал доклад и мы на нем успешно пишем. По эсмеральду пока мнения нет, но вдруг кто заинтересуется.
Depends это элегантный способ внедрения зависимости, а не инверсия зависимостей. Вспомни SOLID. Доклад слабоват, в FA до ебени фени батареек, о которых ни слова. (Обработчики аутентификации, исключений, расширение сваггера, middleware). Короче очередной helloworld по фастапи.
Думаю, что я некорректно выразился. Доклад ограничен временем, которое еще и по факту порезалось. Да, многое не уместилось, но и, честно говоря, цели рассказать обо всем не было. К слову, изначально доклад был больше о нашем опыте применения, но ПК попросили перевести больше в хелловорлд. Что я и сделал. По факту, что доклад не особо сильный я и не спорю. В комментах я с этим соглашаюсь, об этом ранее писали.
@@xfenix3 привет! не подскажешь, можно ли в тинькофф как то устроиться на стажировку? знаю django/drf/asyncio/celery/redis/docker/git/фронт/хочу сейчас как раз таки начать писать на фастапи, но проблема в том что мне 14 лет( не мог бы подсказать как мне приблизиться к работе/стажировке?
@@evilcorp.3546 привет. Увы, про Тинькофф не подскажу, я сам из Райффайзена, а ребята из Тинькофф просто заплатили денег, чтобы конференция была очень массивно забрендирована под них :)
@@evilcorp.3546 спрошу про стажировки. Какие-то у нас точно есть, но, увы, не для питонистов на текущий момент, т.к. в банке питонистов не сильно много всё ещё и гигантского запроса нет. Скорее для джавистов, датасаентистов. На текущий момент, мне кажется, учитывая законодательство, официально на работу в банк могут взять с 18. Но до этого времени, если хочется прокачаться, хороший вариант заниматься опенсорсом и можно ещё фрилансить, если не сильно пугает количество конкуренции и обмана на рынке.
Не совсем тупо и не совсем пересказ, все таки отличия там существенные. Но чисто эмоционально я понимаю и даже согласен с мыслью. Изначально доклад был больше о нашем представлении, я больше рассказывал о наших пакетах и опыте применения, часть про сам фреймворк была маленькой, на 3 слайда. Однако, ПК меня попросили в процессе подготовки сделать его более хеловорлдным. В принципе, согласен, что продвинутой аудитории это скучно слушать (хотя и есть небольшой кусок про наш опыт, он может быть полезен), спору нет. В свою защиту могу сказать вот что - даже сам автор фрейморвка, Себастиан, вон в pycon Латвия с тоже хелловорлдом выступает, можно на ютубе найти. Иными словами, такой жанр докладов имеет место в этой вселенной. В любом случае пк благодарен за то, что дали шанс выступить, хотя и понимаю, что не сильно многих темой заинтересовал. А ещё в этом году у меня были более технологичные и разнообразные и доклады на других конференциях. Найти не сложно :)
Некоторое дополнение: в докладе я говорю, что нельзя генерировать рандомные данные по пайдентик моделям. После доклада мне подсказали - можно! С помощью hypothesis. Очень крутая библиотека, кстати.
Прикольный кстати сайт у тебя. Есть полезные вещи )
хороший и интересный доклад, хотелось бы почаще видеть работы этого человека
Спасибо большое! Мне и самому хотелось бы почаще видеть работы этого человека :(
Крутой доклад. Спасибо
Спасибо!
Спасибо за доклад, я для себя многое структурировал.
Мне понравился доклад, много полезной информации. Спасибо!
Спасибо!
Проклятие человека «на самом деле». Уже вторую конференцию мое фирменное «на самом деле» меня не покидает. Меня где-то покусали что-ли за гаражами...
Легенда
На самом деле это нормально.
сейчас в поисках работы и обнаружил что практически везде либо уже требуется FastAPI, либо собираются на него переезжать))) вообще люто быстро штука появилась и уже в энтерпрайзе во всю работает)))
Я очень плотно изучаю flask это мой первый фреймворк, который я изучил очень хорошо. Следующий будет FastAPI
@@PythonDevelopment Правильный подход))) Не забудь посмотреть и изучить Django, так как в нём куча архитектурных паттернов применяется, которые помогают лучше разобраться в том же Flask и FastAPI))) И помогают лучше понимать как организовывать и писать код правильно)))
И это радует, он бомбанул буквально за год-два. Буквально недавно о нем даже никто не говорил особо
потому что он не совсем самостоятельный. это если грубо то как в js есть TS. тоже и тут, ибо под капотом скарлет.😁 поэтому и результат таков. ну и api само по себе стало более популярно из-за сильной моды SPA. можно писать на Flask, но он сложный! он очень крут, но слишком сложный для большинства. был еще скарлет. он и сейчас есть. разрабы FastAPI посмотрели на скарлет, поняли что это еще сложнее чем Flask и его вообще все бояться.. решили людей подружить с скарлет и сделали FastAPI.😁
@@IT_psychopath Flask сложный? да-ну
Норм видос, покекал
Интересно как реализуются CBV внутри FastAPI
Никак. Наследование это не про Fastapi. Бери и пиши в каждой вьюхе все руками. Надо чуток изменить наследника? А их нету. Бери и ебашь руками по всей кодобазе.
@@anton6643 Теперь немножко не соглашусь, прошло уже 10 месяцев как я работаю с FastApi. Понятное дело тут классы не используются, но есть крутая штука которая называется Dependency. И при помощи нее можно очень много логики скрыть и обобщить))
@@poperechniy депенденси инжекшн в пайтоне ))) бгага, жабаскриптеры научились писать на питоне, но так как они не умеют в ООП, то принесли все свое говно с собой...
@@anton6643 🤣🤣🤣, ну мой первый язык это питончик, я даже не знал про эти инъекции в js пока не прочел про них от тебя тут. В целом мне нравится методология, спасибо за поднятое настроение
Первый раз в жизни вижу докладчика в защитных очках, вот это я понимаю, альфа-поведение! :)
Инетересно посмотреть, как быстро получить админку... 😀
Джекхаммер3д, спасибо за доклад)
Спасибо!
звук очень плохой(
Да, правда не очень :(
Спасибо, вкусно! Как скоро мы придем к ситуации, что на каждый чих будет свой фреймворк?
Спасибо! Да мне кажется мы в какой-то мере в этой ситуации. На большинство вещей есть фреймворк или библиотека. Но я думаю, что здесь возникает проблема: это еще потом собрать надо как-то вместе и не просто собрать, а сделать, чтобы оно не ломалось в 99 процентах случаев и могло быть дописываемо и обновляемо. Вот тут и пригождается инженерный талант и умение. Всё для всего есть, но программировать, в общем, не перестаём :)
Почему в FastApi нет создания роутов из структуры каталогов?
По-моему, это бы было очень негибко. А так мы считай отделываемся include_router и дальше можем как нам нравится организовывать структуру. Это супер удобно и приятно. Из минусов, понятно, что у каждого своя идея как это организовать, но, мне кажется, это и не плохо.
@@xfenixws Не согласен, портянка из двух сотен роутов превращает код в сущий ад, создать из которого структуру апи можно только взяв карандаш или запустив код. Моя библиотека автоматически транслирует структуру каталога в апи и даже описания модулей попадают в swagger.
@@stanislavsheev7748 так в фастапи из коробки можно по разным модулям разбивать через include_router, как раз к этому я вёл. Можно разбить твои роуты по тегам и файлам как нравится, мы так и делаем. Кроме того, 200 роутов в одном сервисе это довольно много, возможно имеет смысл разбивать на отдельные микросервисы. Мы в нашем приложении так и делаем, один микросервис не тянет больше нескольких десятков роутов.
И если у тебя есть такой модуль, как ты описываешь, почему бы тебе не показать его? Я звездочку на гитхабе поставлю :)
@@xfenixws ок. выложу на днях и кину комментарием ссылку
@@stanislavsheev7748 спасибо, буду ждать :)
Чувак, инверсия зависимостей и внедрение зависимостей (Depends()) это разные вещи, посмотри
Поторопился, был не прав. Хотел бы сказать исправлюсь, но это как повезет :)
внедрение зависимостей это частный случай инверсии управления
@@kandreyk9159 спасибо, вот я собственно так же считаю, поэтому так и сказал. Но коллегам не нравится. Возможно, они выступают за терминологическую точность или считают, что это некорректно. Но, комментариев, раскрывающих это, я пока не видел
Привет! Ты как будто рэп читаешь :)
О, привет, Егор :) да там проектор в первый день отлетал и предыдущий оратор сильно выбился из-за этого из тайминга, мое выступление в итоге сократилось и мне пришлось подстраиваться. Хотя, конечно, если уж быть честным, я в принципе стараюсь быстро говорить
Жаль только, что по итогу, фаст апи избавляет нас от кучи работы в 1 ситуациях и это всеми расхваливается, но так же накладывает на нас кучу другой работы, сделать которую по итогу гораздо труднее, чем пример про джанго
Если речь о бд, то да, дальше сложнее. Но на то он и небольшой фреймворк, что не затаскивает всё сразу. Когда тебе важна скорость, ты берешь его, алхимию или sqlmodel от того же автора и, в целом, вполне себе живешь.
@@xfenix3 Так в том то и дело, что не могу представить себе настолько маленький проект, чтобы спокойно обойтись одним фаст апи, а раз уж надо расширяться, то джанго подходит как ничто другое, НО...Ассинхронность... пожалуй козырь этого, на мой взгляд прекрасного но через чур распиаренного фремворка, конечно ассинхронность нужна и творит чудеса, но в среднем проект на фаст апи, как минимум пока-что, разрабатывать и поддерживать раза в 4 тяжелее и дольше, чем тот же на джанго. Плюс в джано, когда нужен сваггер, 5 строк кода и готово, что либо еще понадобилось? 5 строк кода и готово. Не хватает только ассинхронности полноценной. Ждем что будет дальше, учить конечно же нужно, банально полезно самому опуститься на уровень пониже, по сравнению с джанго.
@@Biongar мы у себя все бекенды пишем в довольно приличном по объему проекте на фастапи. У нас сотни ручек, около 15 микросервисов и все на fastapi. Нам важна скорость, т.к. все таки чат. Я соглашусь, что джанго миграции куда круче, чем то что ты сам можешь соорудить. Но когда речь идет именно о выстраивании архитектуры, отличной от очередной MVC вариации, тут у тебя чистый лист. Мы, например, активно используем многослойную архитектуру, dependency injector, sql alchemy и все это очень здорово работает. Плюс надежно, плюс быстро. Ну и в целом по банку все кто что-то стартует, стартуют обычно микросервисное, поэтому фастапи залетает на ура. Потом посложнее, конечно. Т.е. не соглашусь что раза в 4, максимум раза в 1.5 )). Но посложнее да, но для нас всех это еще и челендж в плане развития как инженеров. Джанго очень в этом смысле толерантен к уровню того, кто что-то делает. Это и плюс и минус. Ну и я просто уже лет 10 с джангой, мне лично надоело немного, поэтому я и в фастапи с ногами улетел. В целом, я честно считаю, что джанга никуда не денется и так же будет популярна. Но ей явно требуется реновация.
@@xfenix3 Спасибо большое за то, что расписали, многое подчерпну для себя, мне тоже после джанги фаст апи зашла, как я говорил ощущение что ушел на уровень ниже, я лишь говорю что фаст апи распиарена, это не к тому что фаст апи плоха, она прекрасна, но аргументы которые в ее пользу приводят спорные, по факту аргумент весомый только 1, фаст апи асинх, а джанго нет, явных преимуществ больше нет, ну опять таки, если не брать что для микросервиса джанго спорно подходит, а просто если сравнивать вот "фремворк для работы"
@@xfenix3 а чём челлендж развития заключается?
Взять что-то сложное и пытаться заставить это работать, вместо решения которое будет работать без пыток? 🤔
Главное не смотреть в исходники этого самого фастапи.
Ну и не все живут RESTом.
😂 исходники там как обычно у фреймворков: для потребителей красиво сделаем, а внутри требуха. Но, надо отдать должное Себастиану, там все таки кода немного, это тонкая обертка вокруг starlette и pydantic.
> Ну и не все живут RESTом
И это неоспоримо. А для тех, кто живет - нормальный фреймворк.
Для тех кто не живет рестом и угорает по ультра хардкору! К вашему вниманию фреймворки propan и litestar. Для MQ первый целиком, у второго есть абстракции. Поэтому могу рекомендовать!
На слайдах говнокод чудовищный. Надеюсь, докладчик просто торопился. Еще он не понимает, что такое dependency inversion, к сожалению. Неприятно, что теперь такие доклады стали нормой(
Я понимаю разницу, но действительно допустил ошибку. Так что тут извините, уже писал об этом в комментариях. Это примерные куски, конечно, не реальный продакшн код. Некоторые куски из официальной документации FastAPI. Но если, разумеется, есть более конкретные комментарии по слайдам - не стесняйтесь поделиться. А про то, что «такие» доклады стали нормой: я вообще один доклад тут сделал, у других докладчиков они лучше, посмотрите с этой конференции, было много хороших докладов. Призываю не раздавать несправедливые ярлыки коллегам из-за моих ошибок :)
мда.... тут джангу не можешь освоить, потому что не работает в IT и нет постоянной практики, а уже много вакансий требуют фастапи.
С джанги можно начинать, ничего страшного, что fastapi не знаешь. Все равно сможешь найти себе работу
@@xfenix3, эх... :-/
@@xewuss3750 да вот теперь посложнее ситуация в мире началась. Про местную я не говорю... Теперь придется пробиваться в индустрию, скорее всего. Думаю, пару лет и ситуация изменится, но в моменте все тоскливо.
@@xfenix3, как, однако, Вы точно поняли столь короткую реплику.
@@xewuss3750 да мне, кажется, просто сейчас все об одном плюс минус думают :(
ВНЕДРЕНИЕ зависимостей!!!
DI является способом достижения DIP. Поэтому не принимаю претензию :)
асинхронность как бы всегда была если че.. просто мало кто знает что асинк это сахар над генератором.🤣раньше просто на том же Flask писали асинхронность с помощью генираторов. оно больно, согласен, современный подход прост и понятен всем. ну и FastAPI, это не прорывной фреймворк а просто взяли чудище скарлет которого боялись все больше чем Flask, отмыли, постригли, косметикой помазали, духами пшик и все, народ уже не так сильно боится скарлета. главное не говорить им что это скарлет.🤣часто слышу тип - "в доках fastapi все слишком просто приведено, остальное надо самому додумывать искать и тд..". те кто в теме, если им не хватает доков fastapi, ищут доки скарлет и реализации, ну и тд.. на скарлет.😁для api он хорош. но не под все он подходит, гора нюансов все же за плечами висит... с Flask все ок, просто мало кто умеет его готовить и от этого инфы тоже не много.. поэтому большинство или на Django, или FastAPI (если адекваты то выбирают под задачи).😁
Ну так и есть, по сути. Отмыли, постригли и это то, что людям и нужно было, по сути. Получилось не так уж плохо. В этом году обратил внимание на его конкурента - litestar, мне он больше понравился и о нём я тоже сделал доклад!
Так ну у нас что не день, то новый фреймворк. Ребят, там еще esmerald подвезли! Лайтстар уже затащили в прод, я сделал доклад и мы на нем успешно пишем. По эсмеральду пока мнения нет, но вдруг кто заинтересуется.
Depends это элегантный способ внедрения зависимости, а не инверсия зависимостей. Вспомни SOLID.
Доклад слабоват, в FA до ебени фени батареек, о которых ни слова. (Обработчики аутентификации, исключений, расширение сваггера, middleware). Короче очередной helloworld по фастапи.
Думаю, что я некорректно выразился.
Доклад ограничен временем, которое еще и по факту порезалось. Да, многое не уместилось, но и, честно говоря, цели рассказать обо всем не было.
К слову, изначально доклад был больше о нашем опыте применения, но ПК попросили перевести больше в хелловорлд. Что я и сделал. По факту, что доклад не особо сильный я и не спорю. В комментах я с этим соглашаюсь, об этом ранее писали.
@@xfenix3 привет! не подскажешь, можно ли в тинькофф как то устроиться на стажировку? знаю django/drf/asyncio/celery/redis/docker/git/фронт/хочу сейчас как раз таки начать писать на фастапи, но проблема в том что мне 14 лет( не мог бы подсказать как мне приблизиться к работе/стажировке?
@@evilcorp.3546 привет. Увы, про Тинькофф не подскажу, я сам из Райффайзена, а ребята из Тинькофф просто заплатили денег, чтобы конференция была очень массивно забрендирована под них :)
@@xfenix3 ну, в таком случае, в Райффайзен 😂
@@evilcorp.3546 спрошу про стажировки. Какие-то у нас точно есть, но, увы, не для питонистов на текущий момент, т.к. в банке питонистов не сильно много всё ещё и гигантского запроса нет. Скорее для джавистов, датасаентистов. На текущий момент, мне кажется, учитывая законодательство, официально на работу в банк могут взять с 18. Но до этого времени, если хочется прокачаться, хороший вариант заниматься опенсорсом и можно ещё фрилансить, если не сильно пугает количество конкуренции и обмана на рынке.
тупо пересказ доки
Не совсем тупо и не совсем пересказ, все таки отличия там существенные. Но чисто эмоционально я понимаю и даже согласен с мыслью.
Изначально доклад был больше о нашем представлении, я больше рассказывал о наших пакетах и опыте применения, часть про сам фреймворк была маленькой, на 3 слайда.
Однако, ПК меня попросили в процессе подготовки сделать его более хеловорлдным.
В принципе, согласен, что продвинутой аудитории это скучно слушать (хотя и есть небольшой кусок про наш опыт, он может быть полезен), спору нет.
В свою защиту могу сказать вот что - даже сам автор фрейморвка, Себастиан, вон в pycon Латвия с тоже хелловорлдом выступает, можно на ютубе найти. Иными словами, такой жанр докладов имеет место в этой вселенной.
В любом случае пк благодарен за то, что дали шанс выступить, хотя и понимаю, что не сильно многих темой заинтересовал.
А ещё в этом году у меня были более технологичные и разнообразные и доклады на других конференциях. Найти не сложно :)
@@xfenixws Норм доклад. Мне было интересно посмотреть. Не нужно оправдываться перед непонятно кем, непонятно кому, непонятно что сделавшего полезного.
@@ИванИванов-н9т9ъ большое спасибо за слова поддержки! Я просто стараюсь рассматривать разные точки зрения :)
Блин, это стендап или что?
Вообще нет, но в данный момент да.
@@xfenix3 вообще хорошо вышло.
@@ПётрГригорьев-т1ь спасибо! 🎩