Вопрос глубокой связи букмекера с операторами оставлю за скобками. С этим сложно что-то сделать, потому что оператор официально будет всё отрицать, а менты всегда работают по принципу "звоните, когда будут убивать". Так что немного соображений из предположения об отсутствии такой связи, больше по возможной технике.
В GSM у каждой сим-карты есть уникальный номер IMSI. Для функционирования сети в ней предусмотрена возможность сделать запрос по номеру, чтобы получить IMSI. Причём формальный запрос можно сделать через SS7 из сети любого оператора в мире. Естественно, операторам такое не нравится. И сейчас у крупных операторов это не работает: в качестве IMSI из-за пределов своей собственной сети они возвращают случайное значение, каждый раз разное.
В своё время появилась гениальная идея бороться с угоном симок (и последующим воровством средств) через получение IMSI. Типа если IMSI поменялся, то пусть клиент со своей мордашкой и паспортом покажется банку, чтобы они подтвердили владение номером. Разумеется, IMSI интересовали не только банки, но банкам это, по понятным причинам, было очень важно. Из-за этого после зарубания доступа к реальным IMSI у операторов постепенно появился платный сервис мониторинга IMSI: можно поставить номера на мониторинг, и оператор будет через специальный API присылать события по этому номеру (сам IMSI неизвестен, но известно, что он поменялся). Этими сервисами (которые есть у "большой четвёрки" и у некоторых мелких операторов) сейчас в той или иной мере пользуются многие банки. Небанковским организациям такое практически не дают (недавно внезапно дали Яндексу, и он это шумно пропиарил). Я сомневаюсь, что букмекеры могут легально получить такой доступ.
Но вернёмся к изначальной истории с IMSI через запросы в SS7. Помимо получения IMSI, можно также сделать HLR-запрос, который можно использовать для проверки живости номера (а также его текущего оператора). Так что я могу предположить, что букмекеры потихоньку сканят неизвестные номера (возможно, они это делают не сами, а это делают какие-то их партнёры-поставщики), и если какой-то номер, что был год офлайн, вдруг стал онлайн, то это явный признак нового договора.
Естественно, доказать подобное будет крайне сложно.
cntfrgthr, я тоже ни фига не понимаю, что тут имелось в виду и какое поведение ожидалось.
В метод button_click_check передаётся button, но в его теле используется вместо него self.button.
Далее, в классе Interface используется self.button, который инициализируется только в его потомке Button. Что не соответствует элементарным принципам наследования. И вообще, интерфейс это интерфейс, а методы внутри него предполагают, что это уже кнопка, непорядок...
У Interface нет конкструктора - тоже плохо. По-хорошему все поля класса должны появиться после конструктора (self.coords, self.button - все поля класса, которые я тут вижу).
В button_click_check используется self.coords, хотя в реальности за пределами этого метода поле coords не нужно, поэтому имеет смысл использовать локальную переменную, а не поле класса, как в is_cursor_on_button.
Пережимаем с помощью ffmpeg в размер навроде 160x120 и можно также с маленьким битрейтом, а потом при желании можно и увеличить размер кадра - качество всё равно уже будет утеряно. Самый простой способ.
The_one_who_asks, именно поэтому шарить лучше просто некий общий каталог на всё, а создавать уже внутри него. И обычно именно так и делают.
Правда, возникнет вопрос с правами доступа, если нужны кастомные. Ну там есть два соображения: с одной стороны, каждому отделу/департаменту/рабочей группе делается своя шара (а отделы не появляются каждый день), с другой - можно правами внутри сервера разделять доступ по группам даже в пределах одной шары.
Я даже накручивал acl. Например, есть личные каталоги учеников в школе, доступные только им лично (как бы у любого юзера есть такой), и есть шара, через которую учитель их видит все разом и имеет доступ к ним, в том числе на запись. Учителя, соответственно, входят в одну группу, которая используется в дополнительном acl на все каталоги учеников.
Это легальный WhatsApp Business API или нелегальная имитиация Web API? Легальный у некоторых провайдеров фактически пробрасывает как есть запросы в WA (только авторизация подменяется), и в нём в POST явно не такое надо посылать, а в GET ничего подобного не передаётся.
Более того, если компы в домене, то можно ещё и соорудить автоматическое подключение как сетевого диска через вызовы net use в logon script. Я в своё время делал чтобы файлопомойка автоматически у всех подключалась например как S:\
Если бы у smb-ссылок в винде был нормальный спосол использования через URI, как в Linux через smb://, то было бы проще - можно было бы давать ссылки, например, во внутреннем вики или в письмах.
Neitr, у нас был Slack, пока в нём сидела разработка, эксплуатация и саппорт, было ещё более-менее по цене, когда решили внедрить во всю компанию поняли что ценник негуманный, и тогда выбрали Rocket.Chat за то что он достаточно близок к слаку по идеологии. Но он оказался довольно глючным и тормозным, поэтому в прошлом году изучали альтернативы, в шортлист вошли Mattermost и Matrix, в итоге победил Matrix и мы провели тест его использования, по итогу руководство того отдела, что вело этот проект, решило остаться на Rocket.Chat и просто его немного доработать (своя сборка мобильного приложения, свой модуль интеграции с LDAP).
По поводу Rocket.Chat есть такие проблемы:
1. В мобильном клиенте есть недостаточно поддерживаемые фичи, из-за чего сообщения с кусками кода временами рендерятся криво.
2. Мобильный клюент в бесплатной версии глючит с пушами, часто пуши опаздывают, иногда приходят прям пачками и даже дублируются. Можно заплатить разрабам за поддержку, и пуши будут идти через другой сервер и работать быстрее, но всё равно не очень надёжно. Мы в итоге сделали свою сборку клиента со своими пушами, но её приходится ставить не из сторов, на андроиде ещё ничего, на яблоках это какой-то странный квест...
3. Декстопная версия очень любит жрать память и вообще не очень отзывчива по скорости работы. Вообще, кто-то у нас заметил, что там в интерфейсе дофига избыточных div и span...
4. Это приложение на Electron, причём один из худших вариантов, которые я встречал. Да, я знаю, что приложения на Electron это фактически браузер, но всё же. Вон, клиент Matrix Element тоже Electron, но он реально клёво написан, память не жрёт, работает быстро и красиво.
В общем-то мы привыкли, да и глючить оно стало в современных версиях чуть меньше, чем раньше, хоть и жаль, что прогресс такой медленный.
Также смотрели Mattermost. Его декстопный клиент вроде выглядел поприличнее Rocket.Chat, но он кажется чуть меньше похож на Slack. Про мобильный клиент не помню впечатления.
Ещё смотрели Zulip, это довольно забавная штука, там можно текстовые топики создавать прям в канале и фильтровать по ним, этакая замена тредов, но это явно будет пользователям тяжело воспринимать.
Что касается аудиовидео, большинство открытых проектов такого рода просто используют Jitsi Meet, позволяя прям из клиента создать в нём встречу и показывая в webview её. Можно поставить свой сервер Jitsi Meet и использовать. У нас всё равно свой сервер есть, мы его и внутри используем, и для встреч с внешними пользователями (включая онлайн-собеседования). Правда, часть сотрудников всё равно используют обычный Zoom с личными аккаунтами :)
lolrofl01, никак, докер даёт приложению очень мало времени на завершение, потом убивает принудительно, с высокой вероятностью никакие потуги не позволят гарантированно записать базу в файл.
Вообще, советую пересмотреть свою задачу: зачем ей вообще нужны такие манипуляции? Может, нужно базу в докер не засовывать, а запустить на хосте?
Neitr, да, может. И даже его функции федерации можно зарезать, чтобы нельзя было связываться с другими Matrix-серверами.
Но есть некоторые неудобства в том, что пользователей придётся обучить его функциям криптографии (бэкап ключа, авторизация других устройств итд). Это стало основным препятствием, почему у нас в конторе решили его не внедрять.
Не надо копипастить простыню кода безо всяких пояснений. Может, автор вопроса скопипастит и у него заработает (но не факт), а вот понимания не прибавится и лучше программировать он не научится.
Вадим, интернет там был ни при чём. Браузер тормозит - скрипт считает, что видео отдаётся медленно - понижает качество.
Ну а общее соображение в том, что "интернет хороший" - это масло маслянное. Как будет роутиться трафик и какая будет загруженность конечного сервера угадать никогда нельзя. Тем более что, как я говорил, у них может быть такой же автодетект, как у ютуба и других хостингов, который снизит качество при любых лагах сети.
