Хорошо хоть не под трёхфаным напряжением)). Можете уточнить как методология стала приложением?
Это просто явный перевод названия методологии, не стал оставлять англицизмом, на мой взгляд "методология 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) и выбор кликом (название проекта там видно).
для себя принял, что первый экран это обычный, второй браузер, третий это активный проект и дальше экраны с проектами, которые по мере необходимости можно перемещать на место третьего. это позволяет свайпаться между браузером и активным проектом влево/вправо тремя пальцами по тачпаду.
бить по производительности? в pet-проекте? серьезно?
имхо пусть новички везде юзают f-стринги, чем городят страшные конструкции с конкатенацией строк, а оптимизацией всегда можно заняться потом, если в этом вообще будет необходимость, когда упор будет в производительность python-кода, а не во внешние сервисы.
пользователю уже не достаточно просто сухих страниц с информацией, он хочет интерактивности, платой за которую является весь тот ворох технологий, который выше перечислили.
точнее пользователю нужна интерактивность -> разработчик не хочет страдать от лапшевидного кода и императивного управления dom (плюс на него давит бизнес «фича нужна была неделю назад») -> разработчик берет более удобное -> вес итоговой сборки больше, выполняется на клиенте дольше -> пользователь мирится с тормозами в обмен на интерактивность
Мой коммент был именно про «пуш на каждый чих». Когда разработчик не может увидеть результат своего труда до того как он закоммитит, запушит и дождется выкатки feature-ветки. Это слишком долго. А если еще вспомнить, что должны прогнаться тесты, то совсем грустно становится.
А зачем на каждый чих коммитить и пушить? Разрабатываешь локально, с подключенными тестовыми ресурсами, когда убедился, что ок, коммитишь и пушаешь. После этого на тестовом стенде собирается ветка и её можно дать пощупать другим.
Это просто явный перевод названия методологии, не стал оставлять англицизмом, на мой взгляд "методология 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) и выбор кликом (название проекта там видно).
для себя принял, что первый экран это обычный, второй браузер, третий это активный проект и дальше экраны с проектами, которые по мере необходимости можно перемещать на место третьего. это позволяет свайпаться между браузером и активным проектом влево/вправо тремя пальцами по тачпаду.
тогда получилась бы совсем другая статья, более техническая и архитектурная, чем про общий процесс :)
так это гораздо интереснее, чем простое "мы используем запуск ботов по расписанию и потом смотрим отчеты"
по мне это лишь дело вкуса, сам бы я написал бы без f-строк и даже не подумал бы что они тут нужны
бить по производительности? в pet-проекте? серьезно?
имхо пусть новички везде юзают f-стринги, чем городят страшные конструкции с конкатенацией строк, а оптимизацией всегда можно заняться потом, если в этом вообще будет необходимость, когда упор будет в производительность python-кода, а не во внешние сервисы.
точнее пользователю нужна интерактивность -> разработчик не хочет страдать от лапшевидного кода и императивного управления dom (плюс на него давит бизнес «фича нужна была неделю назад») -> разработчик берет более удобное -> вес итоговой сборки больше, выполняется на клиенте дольше -> пользователь мирится с тормозами в обмен на интерактивность
Лучше сделать симлинк на общие ассеты.