я что-то торможу и все равно не понимаю: вот есть фронт - по сути собранная статика JS, вот есть бэк - Django приложение. фронт посылает запросы на бэк, бэк что-то отвечает, когда нужна авторизация - фронт делает редирект юзера на тг-бота (по сути, тоже приложение бэкенда в соседнем контейнере), дальше фронт как узнает авторизационные данные? Фронту по факту нужны токены access/refresh. Опишите, пожалуйста, подробно механизм их получения фронтом в вашем флоу без ввода телефона
если на фронте не будет ввода телефона, то мы потеряем связь фронт-бэк, так как все будет происходить на стороне бэка, а фронт понятия иметь не будет что и как и что это за пользователь и где для него токены брать. Или я неправильно понял вашу мысль...
а как мы будем получать номер телефона юзера, если в дальнейшем решим изменить механику авторизации? если в дальнейшем все же перейти на подтверждение по смс
отличные вопросы, отвечаю: 1 - да, все верное, нужно поделиться номером, который привязан к аккаунту и который юзер указал в форме 2 - не бывает идеальных решений, есть компромиссы или личные предпочтения (не люблю я веб-сокеты:))
да если делать вызов системных утилит - какой смысл использовать что-то другое) как я уже писал в другом комментарии выше - все можно сделать как угодно, все это будет компромисс, как хочется так и делай
можно придумать такие кейсы. Например: считать информацию о загрузке процессора (CPU load) для каждого пользователя из /proc/loadavg и отсортировать их по убыванию средней нагрузки за последние 15 минут.
для меня в python видится использование библиотеки psutil (не входит в стандартную бибиотеку), а в bash это `awk '{for(i=1;i<=NF-2;i++) print $i}' /proc/loadavg | sort -nr`
ну тут go больше python уже подойдет, чтобы меньше телодвижений было. Дело, конечно, каждого, как извращаться. Как говорится "можно и зайца научить курить, но нафига?". Так и тут: bash - понятный POSIX инструмент, здесть P (Portable) является ключевым. Для каждой задачи должен подходить свой инструмент. Если задача требует программирования, то надо смотреть на накладные расходы. Никогда нет супер правильного решения - есть только компромиссы, с которыми мы готовы мириться
Не зря это считается бэд практис. Самый простейший пример: нужен какой-то пакет не ниже какой-то версии, а этот пакет уже установлен для системных нужд, а ты взял и обновил этот пакет и все, в системе что-то сломал
нет, дорогой друг, ставить какой-то пакет питона в "стандартное" окружение ОС - это путь в никуда, если вы собираетесь прожить с этой системой хоть пару лет (со всеми обновлениями безопасности и т.д,) Никогда! Повторю, НИКОГДА, не нужно ставить какие-то пакеты в окружение python вашего дистрибутива. Нет, я не выпендриваюсь, честно, просто это - опыт. P.S. python - мой рабочий инструмент более 10 лет, я его искренне люблю и лелею, но нет - для задач переносимой автоматизации он подходит едва ли...
У Python есть один явный минус в сравнении с bash - это виртуальное окружение. Далеко не все скрипты можно "вот так взять и просто написать" без использования сторонних библиотек, а для этого нужно создавать виртуальное окружение, прописывать полный путь к интерпретатору в этом окружении... То есть речи о переносимости "из коробки" тут быть не может.
docker-compose.yml с описанным самими сервисом и нужными ему службами по дефолту находится в репозитории с сервисом для быстрого "поднятия" его (сервиса) локально, все тесты гоняются в контенере. Откуда он взялся я писал в разделе "мы имеем"
это вопрос риторический, ну не хочет делиться номером - не надо, и не надо пользоваться сервисами тогда, где телефон надо привязывать к аккаунту
я что-то торможу и все равно не понимаю: вот есть фронт - по сути собранная статика JS, вот есть бэк - Django приложение. фронт посылает запросы на бэк, бэк что-то отвечает, когда нужна авторизация - фронт делает редирект юзера на тг-бота (по сути, тоже приложение бэкенда в соседнем контейнере), дальше фронт как узнает авторизационные данные? Фронту по факту нужны токены access/refresh. Опишите, пожалуйста, подробно механизм их получения фронтом в вашем флоу без ввода телефона
а как у вас фронт получает номер телефона? у меня фронт - это react приложение, которое входит в коммуникацию с бэком по REST API
если на фронте не будет ввода телефона, то мы потеряем связь фронт-бэк, так как все будет происходить на стороне бэка, а фронт понятия иметь не будет что и как и что это за пользователь и где для него токены брать. Или я неправильно понял вашу мысль...
Спасибо, я не знал про это, изучу на досуге
Ну такое с точки зрения юзер флоу...
Да тут нет проблемы ненастоящего номера, ну не настоящий введёт - сам себе злой Буратино, дальше не будет истории заказов и персонализации
опишите плз процесс как вы видите
а как мы будем получать номер телефона юзера, если в дальнейшем решим изменить механику авторизации? если в дальнейшем все же перейти на подтверждение по смс
отличные вопросы, отвечаю:
1 - да, все верное, нужно поделиться номером, который привязан к аккаунту и который юзер указал в форме
2 - не бывает идеальных решений, есть компромиссы или личные предпочтения (не люблю я веб-сокеты:))
Этот материал больше для поста, а не для статьи, как по мне. Думал под катом будет какая-то невероятная или, по крайней мере, поучительная история
да если делать вызов системных утилит - какой смысл использовать что-то другое) как я уже писал в другом комментарии выше - все можно сделать как угодно, все это будет компромисс, как хочется так и делай
можно придумать такие кейсы. Например: считать информацию о загрузке процессора (CPU load) для каждого пользователя из
/proc/loadavgи отсортировать их по убыванию средней нагрузки за последние 15 минут.для меня в python видится использование библиотеки
psutil(не входит в стандартную бибиотеку), а в bash это `awk '{for(i=1;i<=NF-2;i++) print $i}' /proc/loadavg | sort -nr`А тут подробности нужны, я, как искренний любитель Ansible, не сталкивался с какими-то трудностями
ну тут go больше python уже подойдет, чтобы меньше телодвижений было. Дело, конечно, каждого, как извращаться. Как говорится "можно и зайца научить курить, но нафига?". Так и тут: bash - понятный POSIX инструмент, здесть P (Portable) является ключевым. Для каждой задачи должен подходить свой инструмент. Если задача требует программирования, то надо смотреть на накладные расходы. Никогда нет супер правильного решения - есть только компромиссы, с которыми мы готовы мириться
Не зря это считается бэд практис. Самый простейший пример: нужен какой-то пакет не ниже какой-то версии, а этот пакет уже установлен для системных нужд, а ты взял и обновил этот пакет и все, в системе что-то сломал
нет, дорогой друг, ставить какой-то пакет питона в "стандартное" окружение ОС - это путь в никуда, если вы собираетесь прожить с этой системой хоть пару лет (со всеми обновлениями безопасности и т.д,) Никогда! Повторю, НИКОГДА, не нужно ставить какие-то пакеты в окружение python вашего дистрибутива. Нет, я не выпендриваюсь, честно, просто это - опыт.
P.S. python - мой рабочий инструмент более 10 лет, я его искренне люблю и лелею, но нет - для задач переносимой автоматизации он подходит едва ли...
У Python есть один явный минус в сравнении с bash - это виртуальное окружение. Далеко не все скрипты можно "вот так взять и просто написать" без использования сторонних библиотек, а для этого нужно создавать виртуальное окружение, прописывать полный путь к интерпретатору в этом окружении... То есть речи о переносимости "из коробки" тут быть не может.
docker-compose.yml с описанным самими сервисом и нужными ему службами по дефолту находится в репозитории с сервисом для быстрого "поднятия" его (сервиса) локально, все тесты гоняются в контенере. Откуда он взялся я писал в разделе "мы имеем"
ну, как говорится, на вкус и цвет фломастеры у всех разные :)