Как правило (но это не всегда так) лучше использовать для данных общий код: модели, функции, параметры базы итд итп. Это упростит сопровождение кода, внесение изменений в структуру базы итд итп. Разные части проекта используют общий код, что уменьшает неоднозначности в поведении.
Да, это не надо воспринимать как категорическое требование. Например, если части проекта написаны на разных языках, то логично, если для них работа с базой написана на своих языках. Или если к компонентам разные требования, или они используют почти непересекающиеся части базы. Но в целом стоит очень хорошо подумать, зачем дробить работу с базой, ибо это банально неудобно и увеличивает риск ошибок и неоднозначностей.
anton1221, если у мошенников это налаженный на*бизнес, то у них может быть всё готово даже для того, чтобы украсть одну копейку в один клик. Более того, наоборот, воровать большие суммы опасно, а мелкие - больше шансов, что пользователь забьёт. Ссылаться на то, что раньше сервис ничего не воровал, достаточно бессмысленно, ведь это обязательств никаких не создаёт.
Но в данном случае явно проблема в симке. Другой вариант - угнали с одного из устройств файл сессии (поэтому в списке нет других залогиненных сессий).
Justa Gain, а тебе якобы можно под всеми вопросами писать что ТС дураки.
И ты посмотри, он всего лишь высказался, что на русских форумах вместо ответа на вопрос все норовят обсудить личность автора (это, конечно не всегда так, но излишняя любой части наших соотечественников к такому достаточно известна), на что ты прямо назвал его "личностью" в кавычках и начал неприкрыто наезжать. Он же даже слово "быдлан" применил по отношению к неопределённому кругу лиц, а ты - к нему персонально.
Как ни крути, а наиболее непорядочно и агрессивно в этой ситуации поступил именно ты.
Justa Gain, настоятельно рекомендую сменить тон комментариев, потому что рано или поздно модераторам надоест всего лишь удалять наиболее одиозные из твоих сообщений, и они могут перейти к более кардинальным мерам.
Да, тут часто пользователи не могут нормально сформулировать свои задачи, показывают непонимание элементарных вещей и всё такое, но как бы именно для такой категории пользователей сайт и предназначен в первую очередь. Унижать людей за то, что они не очень умные - это недопустимо.
Маленьких детей учат не брать что попало в рот, что валялось на улице.
Взрослых приходится учить не открывать какие попало файлы.
Довольно очевидно, что это письмо не содержит ничего полезного, так зачем мучиться моральными страданиями? Эти "стихи" - просто попытка обойти антиспам за счёт уникального текста. Вся цель этого спама - в этом файле. И не надо даже думать, является ли вредоносным этот файл или он просто содержит непосредственную рекламную инфу - спам есть спам и место ему в помойке.
venom99, решение очень зависит от того, что с данными делается и как. Например, если это датчики, которые передают текущее значение, и сохранять историю не нужно, то можно вообще не использовать никаких баз или очередей. Достаточно просто записывать последнее значение, и пусть его другие потоки читают. Главное, чтобы операция записи нового значения была атомарна, что обеспечивается либо использованием атомарных структур данных (например, 32-битное число), либо блокировками (например, мутексы).
Что касается in memory, то можно и просто использовать рамдиск.
В общем-то, люди правильно говорят, что без знания подробностей задачи сложно давать осмысленные советы.
Хранить картинки в git-репе проекта - это обычно плохая идея, кроме случаев, когда их совсем немного. Хранить их в каталоге рядом с ботом - нормальная.
Но если картинки для разных пользователей будут повторяться, то лучше запоминать file_id ранее загруженных, чтобы в следующий раз не отправлять сами файлы. Это ускорит отправку, да и Телеграму лишние копии файлов на их серверах ни к чему.
Айнур Шангараев, тогда для начала отладить отправку файла, безо всей остальной логики. Делаем временного бота с отдельным токеном и скрипт, в котором файл посылается по любому сообщению или по какому-то конкретному. Добиваемся, что файл отправляется нормально.
У нас в конторе по новым сотрудникам делают стандартную карточку-картинку, где фото, откуда пришёл, компетенции и увлечения, QR-коды на соцсети. Вероятно, для этого у них соцсети специально спрашивают. У меня не спрашивали - когда я устраивался, в конторе ещё HR не было, меня оформляла бухгалтерия.
Человек имеет право в соцсетях быть вообще не зарегистрирован. Можно ничего не указывать.
ZakaT4160, как самый попсовый способ - google docs. Очень многие для этого его и используют. Вполне себе вариант готовить статью, а потом копипастить финальную версию.
postfix сам по себе не обслуживает почтовые ящики, ну кроме может LDA (local delivery agent, это ящики для системных локальных пользователей, лежащие в /var/spool/mail). Ему нужен агент, который доставляет в реальный почтовик с ящиками, например, в dovecot. А в самом dovecot можно создавать ящики, причём информацию по пользователям можно хранить не только в файлах, но также и в базе или в LDAP. В общем-то, я советую погуглить, как это всё интегрируется друг с другом, информации и примеров полно.
В dovecot есть утилиты, которыми можно смотреть содержимое ящиков. Но вообще в некоторых вариантах постановки задачи это выглядит как задача для IMAP-клиента: залогиниться по IMAP и посмотреть последнее письмо.
member - это объект класса discord.Member, и member.id - это id пользователя (даже если мы имеем объект discord.Member, а не discord.User, прям в документации так написано).
Konyuh, синхронный - который делает запрос, ждёт ответа и не делает других запросов в процессе. Естественно, все массовые парсеры пытаются делать одновременно много запросов. В том числе к разным сайтам, через разные прокси итд итп...
Konyuh, это потому что парсер не надо делать синхронным. Правильно написанный парсер может ОЧЕНЬ МНОГО. Плюс эти проекты наверняка имеют большую ферму парсеров с кучей проксей, которые финансируются из платы клиентов.
Максим, рекомендую сделать бэкап и его залить. Как вариант, можно попробовать указать правильный тэг postgis, чтобы соответствующий образ был от ровно такого же образа postgres, какой используется сейчас (там дефолтный latest, надеюсь latest у postgis такой же). Но перед этим рекомендую всё равно сделать бэкап на всякий пожарный.
Будет несомненно дешевле, так как на подобные деньги можно арендовать несколько физических серверов или пару десятков виртуалок. Но потребуется начальная инвестиция в разработку и скорее всего налиие аутсорсера или достаточно оперативного доступного фрилансера на подхвате, чтобы это вовремя чинить, если упадёт или не справится.
В общем-то, люди не просто так платят деньги за готовые работающие решения, снимающие с них головную боль...
Да, это не надо воспринимать как категорическое требование. Например, если части проекта написаны на разных языках, то логично, если для них работа с базой написана на своих языках. Или если к компонентам разные требования, или они используют почти непересекающиеся части базы. Но в целом стоит очень хорошо подумать, зачем дробить работу с базой, ибо это банально неудобно и увеличивает риск ошибок и неоднозначностей.