https://t.me/uxfromhell/714
Не знаю уж насчёт того, схоже ли отношение к поисковой выдаче с отношением к списку писем, но среди меня шансы на открытие таких ссылок точно будут сильно понижены.
Bot API нельзя использовать для рассылки сообщений пользователям по имени. Только для ответа явно написавшим входящее сообщение. Там специально всё так продумано, чтобы использовать API как канал неконтролируемого спама было невозможно.
Ну вот можно оформить вызов bot.get_chat_member в отдельную функцию и вызывать её в начале методов бота.
Недостаток - будет слишком много вызовов этого метода. Можно их кэшировать для оптимизации, в том числе сохраняя в базу и обновляя время от времени, но поначалу и так сойдёт.
Можно даже исхитриться и сделать декоратор, тогда можно писать что-то типа:
@dp....
@check_subscription
def some_handler(...)
чтобы это делалось красиво без написания лишнего кода.
В целом, можно не особо сложно к любой CMS приладить аудиофайлы к контентным страницам. И прослушивание с помощью тэга audio. Можно вместо готовой CMS взять какой-нить фреймворк, хоть django, и дописать необходимый функционал самому.
Но можно и готовые решения типа jellyfin использовать. Правда, у них ниша немного другая.
Александр +, зачем вообще всё это нужно? Весь смысл наследования в ООП как раз в том состоит, что дочерний класс обладает всеми свойствами родительского. Не нужно специально генерировать экземпляр родительского, можно просто обращаться к именам и методам дочернего.
А если методы или семантика полей дочернего перепреоделены, то это верный признак того, что что-то делается неправильно и не по делу.
Если дело только в сериализации, то можно сделать отдельный метод типа dump_as_bookshelref(), который вернёт только нужную информацию и не вернёт ненужную.
Просто случайный ключ сгенерировать это полдела. Вопрос как сделать, чтобы сторона-получатель его тоже знала, а злоумышленнику он не достался. Это нужен какой-то отдельный достаточно безопасный канал передачи, и кажется тогда вообще не нужно передавать ключ - можно просто передать нужное сообщение.
Именно поэтому в большинстве случаев используют совершенно другие подходы. И борются не за то, чтобы ключ нельзя было подобрать, а чтобы это было практически бесполезным делом.
Например, если подбор ключа требует 1000 дней, то с помощью тысячи компьютеров можно его подобрать за 1 день. Но что толку, если время жизни этого ключа составляет 1 минуту, после чего ключ менется? Тогда для того, чтобы успеть подобрать ключ до его истечения, потребуется минимум полтора миллиона компьютеров.
Это очень грубая иллюстрация, но логика реальных современных алгоритмов примерно такая и есть.
AlexeyFuture, be1 либо сам сканировал сайты, либо дёргал данные из поисковиков.
Но даже поисковики отслеживают изменения не моментально. Лаг может порой исчисляться неделями.
И поисковики тоже прикрывают дыры и фичи, через которые можно получать такую инфу. Например, "сохранённая копия" гугла показывала дату создания этой копии - но теперь сохранённые копии больше в гугле недоступны.
Надёжного способа всё равно нет. Контент сейчас часто динамический. Причём многие сайтописатели уже даже 404 не отдают, по ссылке возвращают одинаковый на всех js, который уже грузит контент или рендерит ошибку текстом. Из-за этого любая страница существует всегда, даже с неправильным URL.
Можно софтовый роутер из него сделать для дома или дачи, но в целом да, в условиях когда всё 64-битное, особого смысла в нём нет. Я бы всё же посоветовал протестировать, может быть 64-битный Linux там на самом деле взлетает.
А так вообще это действительно "промышленный компьютер", подключать какие-нить станки или другие специализированные устройства, для чего там и есть эти COM-порты. Если он ни для чего не нужен, то просто спишите его уже.
