Вова, добро пожаловать в дивный мир парсинга! Где сайты обклеены js, капчами, поведенческим анализом, запросными лимитами итд итп. Готового, конечно же, чаще всего нигде нет, ну кроме как у кого-то где-то по секрету без публичного доступа.
Тут есть два базовых подхода:
1. Изучить, какие запросы делаются при навигации по сайту, и воспроизводить их. Лучший способ с точки зрения скорости, но слишком уж легко детектится и слишком часто ломается при мельчайших изменениях в сайте.
2. Использовать полноценный браузер с автоматизацией работы через Selenium. Более надёжно, но запущенный браузер сожрёт дополнительной памяти. И тоже в принципе может детектиться (но сложнее и есть всякие методы обмана).
Также на многих сайтах придётся бороться с капчами и банами, как собственными сайтовыми, так и Cloudflare/DDOS-Guard/итд. Прыгать с бубном с пачками прокси...
Гугл - советую отказаться от парсинга сразу. Этих парсить любят так сильно, что они защитами обвешаны по самые уши. Нет смысла даже возиться.
Вот livelib.ru может оказаться перспективнее, поскольку не так крут, как гугл. Правда, я не очень понимаю, какой толк парсить книжный магазин. Я парсил книжные сайты, где выложены тексты книг, это поинтереснее будет...
Если речь об общем ключе шифрования, то он генерируется по алгоритму DH обеими сторонами независимо от того, используется ли авторизация по клиентскому сертификату или нет.
Вообще-то это не так делается. Пуши работают даже когда приложение на телефоне не запущено. Реализация может быть как раз с помощью firebase.
Приложение на телефоне постоянно запущенное - это костыль. Тем более что фоновые телефонные приложения по определению могут быть закрыты в любой момент, если понадобятся ресурсы.
Разработка на python для телефона в теории возможна. В теории. Но это неудобно и неэффективно. Если это попытка сделать что-то посерьёзнее "себе на поиграться", то лучше отказаться сразу.
Николай Ростов, я-то знаю, и даже писал более сложные обходы дерева каталогов, чем в вопросе. Но я делал это именно в тех случаях, когда это было необходимо для конкретной нетривиальной задачи, а не когда мне было лень разобраться в нормальном решении простой.
Если Телеграм не позволяет штатнт так делать, то только пытаться имитировать. Можно написать бота, который будет ограничивать отправку каждому пользователю на конкретный срок после отправки сообщения. Можно сделать, чтобы бот удалял сообщения, если время не вышло. В любом случае и так и сяк будет коряво, пользователи не будут понимать, что вообще не так...
Николай Ростов, find создаст не больше нагрузки, чем php-скрипт, а даже меньше. Ведь и тому, и другому придётся прочитать список файлов с диска и затем отправить ему какое-то количество операций удаления. Две основных разницы в том, что, во-первых, find написан на C, а во-вторых, он написан очень эффективно и заточен как раз для подобных задач.
И у файла есть своя собственная дата изменения (mtime), которую можно использовать, не читая какие-то спецфайлы (что ещё и гораздо медленнее).
Совет отказаться от плохого механизма и внедрить хороший - он очень правильный и полезный.
Ivansh_v, да, только ssh:// не нужен (по-моему, там надо не ssh:// а git+ssh://, я никогда не запоминал, потому что он всё равно избыточен, достаточно user@server)
XG22, нет никакого смысла городить два разных подхода. Тем более что наверняка некоторые API-вызовы будут использоваться и в публичном API, и в SPA. Отсылки на распространённость практики не заградительны: вы можете делать так, как вам удобнее. Особенно если публичный API у вас будет глубоко вторичным способом работы.
Но это в любом случае решать вам внутри команды, а не посторонние пользователи Хабра будут за вас решать. Если с консенсусом в команде сложно - пусть окончательнео решение принимает тимлид.
Gioplens, не знаю, я селекты не использовал, только сообщения с кнопками (кнопка редактирует сообщение и поэтому получается многоэтажное меню). Но отредактировать код всё равно надо, может при нормальном виде кода и проблема бы стала более понятной.
Не надо лепить какие попало тэги, ни питон, ни vscode вопрос в текущей формулирове не касается: нет ни кода на python, да и вопрос никак не связан с интерфейсом/функционалом vscode.
Да и вопрос непонятный. Это два разных interaction? В discord с точки зрения общих идей заложено, что пользователь работает с однимм interaction единомоментно. И там можно редактировать, что именно показывается в текущий момент, в том числе можно одни менюшки заменять на другие - вполне себе решение для всяких многошаговых и разветвлённых взаимодействий.
