pip разумеется хорош, но отсутствие локов и вменяемого разделения зависимостей приложения от саб зависимостей доставляет прям неудобства и снижает воспроизводимость.
если скорость и удобный тулинг со встроенным venv пережить более чем можно, потому что и без uv это делается без проблем (удобство действительно спорное), то нам хватило единичного случая когда минорная версия в одной из зависимостей ломает у новых разработчиков часть проекта, после этого задумались над альтернативами.
из приятного это вообще не забивает голову, оно просто работает. самособой по началу оно всё было сырым (привет раннее poetry), но сейчас используем uv и прям критичных багов не наблюдаем.
обфуцировав прежде чем вы из этого сделаете образ и начнете гонять дальше образ по workflow, было б очень странно когда оттестировали один вариант, а в проде запускается совершенно другое, это аналогично тому что вы запускали бы сервис в прод без какой либо валидации
Я вижу что это про локальную разработку, но ведь когда-то это попадет на прод, и крайне желательно иметь единообразие между разными окружениями, меняется лишь инфраструктура вокруг
# ---STAGE-3---
# Стадия сборки зависимостей приложения для dev среды
FROM base-pdm-builder AS development-pdm-builder
RUN pdm install --check --dev
# ---STAGE-4---
# Стадия сборки зависимостей приложения для test среды
FROM base-pdm-builder AS test-pdm-builder
RUN pdm install --check -G test --no-self
# ---STAGE-5---
# Стадия сборки зависимостей приложения для prod среды
FROM base-pdm-builder AS production-pdm-builder
RUN pdm install --check --production --no-self
# ---STAGE-6---
# Базовая стадия сборки зависимостей для python образа
FROM python-base AS base-project-builder
Это противоречит всем современным практикам: один образ - много окружений, но никак не собирать разные образы под разные окружения
Режим swarm пока не используется, так как в настоящее время мы располагаем только одним сервером и если вдруг сервер перестанет отвечать, то всё равно все реплики перестанут работать, поэтому и смысла от них нет.
Хостер с одним сервером? Это как? И ваши клиенты получается перекатываются всегда с downtime? А как же минимум 2 ноды в апстриме?
Хорошо хоть не под трёхфаным напряжением)). Можете уточнить как методология стала приложением?
Это просто явный перевод названия методологии, не стал оставлять англицизмом, на мой взгляд "методология 12-факторного приложения" эквивалентна официальному переводу как "приложение двенадцати факторов - методология ..."
Разве базы данных бэкенда (SQL и noSQL), менеджеры очередей (у вас их нет, но всё же) не являются неотъемлимой частью бэкенда?
Тут смотря что рассматривать, если бэкенд в целом, то вы правы, если структуру самого бэкенда, то отдельно есть серверный код, который работает условно на сервере приложений и дополнительные ресурсы по отношению к этому инстансу в лице бд, кеша, хранилища, иногда внешних api и т.д.
В 12 factors нет ни слова об этом. И чтобы нормально заработало горизонтальное масштабирование, часто надо выполнить ряд иных условий.
Самособой, это относится уже к непосредственной реализации. Методология задает лишь необходимые факторы, чтобы это было возможно.
У вас статику бэкенд отдаёт? Обычно для кэширования статики используется CDN.
Сама статика отдается с CDN, но запрос из браузера всё равно должен долететь до бекенда, чтобы получить ссылки на актуальные ресурсы.
Тут какая-то неразбериха. Есть веб сервер, он принимает запросы, если надо обрабатывает и отдаёт их бэкенду (у тебя он проксирует на бэкенд) -- здесь всё стандартно. Зачем на него заварачивать ещё кэшированный трафик (с CDN???)?
Кешированный трафик на него не заворачивается, запрос приходит стандартно на веб-сервер (фронтенд прокси в лице nginx), ответ отдается либо из локального кеша, либо проксируется дальше. Если ответом от бека является html-ка, то она кладется в локальный кеш фронтенд прокси и отдается клиентам напрямую, не долетая в последствии до бекенда. Внутри этой html-ки ссылки на ресурсы ведут на CDN и браузерные клиенты запрашивают ресурсы оттуда.
Даже если такое количество пользователей в час будет не так уже много. Около 120 rps.
Дневная нагрузка действительно не очень большая. Проблема только в пиках. До бекенда иногда прилетало чистых 1400 rps, что тоже не очень много, но к этому надо быть готовым.
В 2023 еще важен стек на бекенде?) С таким же успехом там могло быть что угодно, в данном случае php + laravel просто потому что коллегам из компании этот стек хорошо знаком.
какие js-библиотеки нужны для того, чтобы выбрать ответ из списка?
На фронтенд можно было притащить десяток библиотек, но мы обошлись лишь react'ом и парой утилитарных вещей типо inputmask или jspdf. Остальное кастом, чтобы следовать дизайну.
Так и есть, поэтому если с одним учителем не получилось, то всегда можно поискать другого или дойти своим умом.
Озвучу еще раз мой поинт: это не проблема конкретных курсов, что каким-то студентам их подход к подаче материала и сложность материала не подходят. Восприятие, скорость обучения и бекграунд индивидуальны.
Курсы лишь хорошее подспорье, но основные усилия необходимо приложить собственным интеллектом.
Потому что учитель способен повлиять только на свою подачу, но не на то, как другие воспримут его знания. И было б некорректно с него спрашивать, что его поняли не так.
Возьмите произвольную группу учеников, в ней один учитель говорит одни и те же слова по одной и той же программе ... но все обучатся совершенно по разному.
Курс «не очень», а каков тогда будет «правильный курс»? У меня нет на это ответа, я не педагог и не методист.
Сейчас нет недостатка в информации, проблема в её фильтрации и курсы решают эту проблему, они дают верифицированные ссылки на источники и путь, который может привести, а может и не привести студента к цели, но идти по пути в любом случае будет сам студент.
Я не защищаю яндекс, но не думаю что подход «сервисно-информацинной модели всего я-бизнеса» как-то порочен. В конце концов со студента нужно спрашивать «почему ты не научился?», чем с учителя «почему ты не научил?».
начав читать статью, хотел было скинуть знакомому, который пишет курс/задания для практикума, с комментарием "ррраунд", но добравшись до 5 пункта, понял, что автора озарила суровая правда IT:
Сама образовательная модель зиждется на принципе: СТУДЕНТ УЧИТ СЕБЯ САМ.
по моему мнению все эти курсы не способны научить, они лишь дают минимальную дисциплину, если человеку самому не интересно или он сам не прикладывает усилий, то шансов освоиться в IT (да и в любой нетривиальной области) практически нет
у меня открыт постоянно с десяток проектов в разных продуктах от jetbrains и все на фулскрин, переключение между ними либо свайпом тремя пальцами влево/вправо по тачпаду, либо тремя пальцами вверх (когда открывается mission control) и выбор кликом (название проекта там видно).
для себя принял, что первый экран это обычный, второй браузер, третий это активный проект и дальше экраны с проектами, которые по мере необходимости можно перемещать на место третьего. это позволяет свайпаться между браузером и активным проектом влево/вправо тремя пальцами по тачпаду.
pip разумеется хорош, но отсутствие локов и вменяемого разделения зависимостей приложения от саб зависимостей доставляет прям неудобства и снижает воспроизводимость.
если скорость и удобный тулинг со встроенным venv пережить более чем можно, потому что и без uv это делается без проблем (удобство действительно спорное), то нам хватило единичного случая когда минорная версия в одной из зависимостей ломает у новых разработчиков часть проекта, после этого задумались над альтернативами.
из приятного это вообще не забивает голову, оно просто работает.
самособой по началу оно всё было сырым (привет раннее poetry), но сейчас используем uv и прям критичных багов не наблюдаем.
ни uv/poetry, ни 12 factor app ... это точно современный roadmap?)
PS: тулинг разумеется мелочь, но всё-таки)
в настройках конкретного проекта CI/CD -> General pipelines можно переопределить путь, удобно когда репозиторий кочует между гитлабами
dev зависимостей и правда не должно быть на проде, но всё остальное вполне себе часть проекта
обфуцировав прежде чем вы из этого сделаете образ и начнете гонять дальше образ по workflow, было б очень странно когда оттестировали один вариант, а в проде запускается совершенно другое, это аналогично тому что вы запускали бы сервис в прод без какой либо валидации
Я вижу что это про локальную разработку, но ведь когда-то это попадет на прод, и крайне желательно иметь единообразие между разными окружениями, меняется лишь инфраструктура вокруг
Это противоречит всем современным практикам: один образ - много окружений, но никак не собирать разные образы под разные окружения
Хостер с одним сервером? Это как?
И ваши клиенты получается перекатываются всегда с downtime? А как же минимум 2 ноды в апстриме?
В IDE от JetBrains есть update без переключения веток
Это просто явный перевод названия методологии, не стал оставлять англицизмом, на мой взгляд "методология 12-факторного приложения" эквивалентна официальному переводу как "приложение двенадцати факторов - методология ..."
Тут смотря что рассматривать, если бэкенд в целом, то вы правы, если структуру самого бэкенда, то отдельно есть серверный код, который работает условно на сервере приложений и дополнительные ресурсы по отношению к этому инстансу в лице бд, кеша, хранилища, иногда внешних api и т.д.
Самособой, это относится уже к непосредственной реализации. Методология задает лишь необходимые факторы, чтобы это было возможно.
Сама статика отдается с CDN, но запрос из браузера всё равно должен долететь до бекенда, чтобы получить ссылки на актуальные ресурсы.
Кешированный трафик на него не заворачивается, запрос приходит стандартно на веб-сервер (фронтенд прокси в лице nginx), ответ отдается либо из локального кеша, либо проксируется дальше. Если ответом от бека является html-ка, то она кладется в локальный кеш фронтенд прокси и отдается клиентам напрямую, не долетая в последствии до бекенда. Внутри этой html-ки ссылки на ресурсы ведут на CDN и браузерные клиенты запрашивают ресурсы оттуда.
Дневная нагрузка действительно не очень большая. Проблема только в пиках. До бекенда иногда прилетало чистых 1400 rps, что тоже не очень много, но к этому надо быть готовым.
В 2023 еще важен стек на бекенде?) С таким же успехом там могло быть что угодно, в данном случае php + laravel просто потому что коллегам из компании этот стек хорошо знаком.
На фронтенд можно было притащить десяток библиотек, но мы обошлись лишь react'ом и парой утилитарных вещей типо inputmask или jspdf. Остальное кастом, чтобы следовать дизайну.
Спасибо, поправил. 1,5 месяца
Так и есть, поэтому если с одним учителем не получилось, то всегда можно поискать другого или дойти своим умом.
Озвучу еще раз мой поинт: это не проблема конкретных курсов, что каким-то студентам их подход к подаче материала и сложность материала не подходят. Восприятие, скорость обучения и бекграунд индивидуальны.
Курсы лишь хорошее подспорье, но основные усилия необходимо приложить собственным интеллектом.
я не спорю, что это хороший курс) но он не для новичков, для него требуется какой никакой бекграунд чтобы не спотыкаться на мелочах
Потому что учитель способен повлиять только на свою подачу, но не на то, как другие воспримут его знания. И было б некорректно с него спрашивать, что его поняли не так.
Возьмите произвольную группу учеников, в ней один учитель говорит одни и те же слова по одной и той же программе ... но все обучатся совершенно по разному.
Курс «не очень», а каков тогда будет «правильный курс»? У меня нет на это ответа, я не педагог и не методист.
Сейчас нет недостатка в информации, проблема в её фильтрации и курсы решают эту проблему, они дают верифицированные ссылки на источники и путь, который может привести, а может и не привести студента к цели, но идти по пути в любом случае будет сам студент.
Я не защищаю яндекс, но не думаю что подход «сервисно-информацинной модели всего я-бизнеса» как-то порочен. В конце концов со студента нужно спрашивать «почему ты не научился?», чем с учителя «почему ты не научил?».
начав читать статью, хотел было скинуть знакомому, который пишет курс/задания для практикума, с комментарием "ррраунд", но добравшись до 5 пункта, понял, что автора озарила суровая правда IT:
по моему мнению все эти курсы не способны научить, они лишь дают минимальную дисциплину, если человеку самому не интересно или он сам не прикладывает усилий, то шансов освоиться в IT (да и в любой нетривиальной области) практически нет
urllib2 для Python 2.х, urllib для Python 3.х, requests, lxml и BeautifulSoup ... невероятный набор хакера, просто слов нет
у меня открыт постоянно с десяток проектов в разных продуктах от jetbrains и все на фулскрин, переключение между ними либо свайпом тремя пальцами влево/вправо по тачпаду, либо тремя пальцами вверх (когда открывается mission control) и выбор кликом (название проекта там видно).
для себя принял, что первый экран это обычный, второй браузер, третий это активный проект и дальше экраны с проектами, которые по мере необходимости можно перемещать на место третьего. это позволяет свайпаться между браузером и активным проектом влево/вправо тремя пальцами по тачпаду.
тогда получилась бы совсем другая статья, более техническая и архитектурная, чем про общий процесс :)