Если подсеть, в которой хостер выдаёт адреса в Голландии, приписана к российскому юрлицу, то её и будут идентифицировать как российскую сеть. Как она стыкуется в BGP при этом и где физически располагается никого не интересует. Советую посмотреть данные whois по IP, если там country: RU, то бессмысленно использовать этого хостера для VPN.
Adamos, в принципе, ничто не мешает организовать написание кода так, чтобы он на одной платформе превращался в dll, а на другой - в lib.so. Да, придётся заморочиться, но если автор хочет действительно переносимое решение для полноценно компилируемых языков, то ему это может быть интересно.
Это обычная практика для сервисов такого размера - делегировать муторную рутину на партнёров. Viber тоже на партнёров кивает при попытке подключить их платный сервис (Viber Business Messages). А партнёры уже знают, как всё делать, ну и у них на сами сервисы есть свои выходы.
Если хочется именно надёжный сервис для бизнеса и не хочется регулярно менять номер из-за внезапно случающихся блокировок - то заморочиться имеет смысл. В конце концов, все эти нецелевые использования WhatsApp Web - всего лишь полумеры.
Много клиентов на одном телефоне не запустишь. Читал, что есть у кого-то из китайцев "двойной режим", где можно приложения ставить в двух экземплярах, они будут иметь отдельные настройки и не знать о существовании друг друга, как раз для запуска двух аккаунтов одного мессенджера сойдёт. Но сомневаюсь, что можно запустить сразу десяток, да и не потянет телефон наверняка такое. И в теории WA может заметить, что на устройстве с одним hardware запущено много клиентов сразу.
Я всё же говорил о программных эмуляторах. Серверная винда не нужна. На самом деле некоторые из эмуляторов даже кроссплатформены (как эмулятор из Android Studio), в то время как под Windows есть эмуляторы типа Bluestack Player, которые хороши сами по себе, но больше нацелены на то, чтобы пользователям запускать игрушки, а не автоматизировать работу каких-то приложений...
Но я во всех этих эмуляторах не очень разбираюсь и ничего советовать не могу. Народ как-то это дело даже автоматизирует...
Amigun, можно посмотреть как это сделано в verlihub https://github.com/verlihub/verlihub, там плагины - это подгружаемые библиотеки на C++, а скрипты на других языках реализуются отдельными плагинами (LuaScript, PerlScript, PythonScript), которые уже умеют загружать скрипты и вызывать в них методы. При этом основной софт вообще не зависит от наличия библиотек этих скриптовых язык - они не нужны, пока не понадобятся.
Блин, написал ответ по-дискордовски, а потом посмотрел, кто пишет :)
Если это опять vk-бот, то советую посмотреть на то, имплементирует ли он ctx.author как Discord, тогда вместо user.first_name лучше брать ctx.author.first_name. Также, возможно, там работает type hint, как в discord.py, когда можно у параметра указать тип аргумента как member:discord.Member и он его автоматом превратит в инстанс этого класса, так что можно обращаться к нему со всеми его полями. В частности, в discord.py есть member.mention, который и надо использовать вместо @id.
Также надо использовать f-строки, вызов format на одну переменную вообще лишён смысла (а если там у юзера встретится {} в имени - то ещё и вызовет ошибку). Называть переменную list очень плохо, так как это название встроенного класса - можно где-нибудь прилично выстрелить себе в ногу.
В общем случае никак, так как эти боты работают от аккаунтов обычных пользователей. В том числе в теории это могут оказаться и взломанные аккаунты пользователей, которые уже раньше были в чате, вели себя нормально и прошли любые верификации.
Для каналов проблем нет, так как список подписчиков канала видит только админ.
alextimson, чтобы это была именно команда, нужен класс discord.ext.commands.Bot, который порождён от discord.Client и расширяет его функционал. В discord.Client нет команд, но их можно имитировать путём парсинга сообщений в event on_message. События с именем info в Discord не бывает, поэтому подобая функция будет делать совсем ничего.
Зачем в reviews есть ФИО, если они есть в persons? И не стоит где-то называть person, а где-то user. Если их функции различаются, то это должны быть разные сущности. Возможно расширение функций, когда, например, user может быть клиентом магазина, а может быть владельцем/менеджером, тогда это могут быть таблицы с допсвойствами и ссылкой на первичную таблицу по id (user-shop_client и user-shop_manager).
У сообщения стопудово должно быть время отправки, по которому надо будет сортировать чат. Или можно по id сообщений сортировать, если id будут возрастать со временем. id и получателя, и отправителя не имеют смысла, если чат тет-а-тет, тут имеет смысл id только отправителя, который может совпадать с user_id в чате, а может быть user_id менеджера магазина (заодно можно, чтобы в магазине работали разные люди и могли независимо общаться с пользователями). Клиенту магазина можно не показывать имя менеджера, а показывать название магазина.
Хорошо бы навести порядок в английском. Massage - это массаж, правильно message; magazine - это журнал, правильно shop. ФИО лучше сортировать нормально (а не ставить отчество первым, хотя, конечно, в базе порядок столбцов неважен, но если уж проектировать, то аккуратно) и быть готовым к тому, что многие категорически не хотят его заполнять и будут ставить минусы или "нет" везде, кроме имени - короче, лучше разрешать их пустые значения. Вместо patronymic чаще всего поле называют middle name - это покрывает и понятие отчества, и дополнительные имена, существующие во многих культурах и странах.
products_id - почему во множественном числе? Лучше вообще единообразие: либо таблицы называются единственным числом (тогда красиво выглядят отсылки user.id, user.name), либо множественным (users), а ссылки как раз через единственное число.
При именовании таблиц и колонок не стоит использовать разный регистр и лучше воздерживаться camelCase. Всё равно большинство баз имеют регистронезависимые имена сущностей (и из-за этого приходится дополнительно напрягаться иногда). И не надо пробелов в именах. Названия типа name magazine тоже плохие, так как (на этом примере): 1. пробел вместо подчёркивания; 2. и так понятно, что магазин, по имени таблицы; 3. порядок в названии лучше более естественный; 4. это вообще-то магазин, а не журнал (см. выше) - короче, правильно просто name, даже не shop_name и уж тем более не name_shop. Вообще, это тот случай, когда уместен некоторый перфекционизм.
У покупателей часто бывает больше одного адреса: они могут заказывать домой, на работу, на дачу, в квартиру родителей итд. Имеет смысл также вынести в отдельную таблицу. Также часто выносят названия городов и областей в отдельные таблицы (словарь), а в адресе указываются id (через выпадающий список). Но если это учебная задача или проект небольшой, то можно не заморачиваться. Всё равно часто изменения таких вещей происходят с пониманием масштабов и специфики работы. Например, московские магазины могут при выборе Москвы предлагать улицу из списка, а при выборе подмосковных населённых пунктах - позволять вводить улицу вручную, так как база улиц каждого областного СНТ - это нереально.
Короче, улучшать можно почти до бесконечности. Особенно если дорасти до уровня всяких авито.
