ZOKIDINuz, ответ выше хоть и короткий, но правильный. Нельзя на одном устройстве одновременно держать два звонка. Да и зачем это делать тоже непонятно.
Какая РЕАЛЬНАЯ проблема стоит? Из неё и надо исходить. Если волнует платность обычных звонков, то просто переместиться на звонки в мессенджерах, которые бесплатны. Если волнует расходуемый при таких звонках трафик, то отказаться от звонков через мессенджеры и звонить обычными звонками. Или посмотреть в сторону наличия у своего оператора тарифных опций по безлимитному трафику в мессенджеры (у некоторых такое бывает - или включено в какие-то тарифы, или как отдельная услуга).
Володимир, самый что ни на есть простой способ - делать sleep (1/150) и запускать очередной асинхронный запрос. Тогда в секунду будет делаться 150 асинхронных запросов.
Виктор Таран, если json не сложноструктурированный, а просто набор фиксированного количества параметров, и хочется файликом, то я бы рекомендовал условный заранее правильно экранированный env-файл, который можно было бы включить через source. Или файл, где параметры построчно указаны, а читается он через read с правильным IFS (если точно известно какие символы не будут встречаться в данных, можно использовать и символ в качестве разделителя вместо переноса строки).
Но вообще именно для этой задачи (раскатывание каких-то скриптов, настройка каких-то параметров) лучше использовать ansible (если ещё не используется - начать использовать) и нацеливаться на то, чтобы под нужные системы все необходимые таски работали.
В конце концов, если виртуалки создаются через API, можно же указывать подходящие условия установки, включая дистриб и версию плюс необходимый софт.
lambardi, бот на самом деле может написать первым, но только при условии, что пользователь подписан на канал, а бот является в этом же канале админом. Но это достаточно специфический сценарий.
Надо просто привыкнуть к мысли, что слово "рассылка" к Телеграму неприменимо. Если нужно доносить до некоторой аудитории некоторую информацию, то надо просто сделать канал и мотивировать аудиторию на него подписаться.
Николай, у любой живой библиотеки есть примеры, которые знающий соответствующий язык программист без проблем запустит. Совсем без знания программирования тут можно добиться успеха только чудом.
При такой постановке вопроса нельзя дать однозначный ответ.
Есть много способов. Например, можно выполнять служебные запросы с одного сайта на другой для передачи данных (в том числе и не в реальном времени, а время от времени передавать обновлённую статистику).
Можно настроить доступ одному сайту к базе данных другого. В том числе по сети, если они на разных серверах (для защиты взаимодействия лучше поднять между ними VPN). Можно вообще базу реплицировать.
В общем, тыжпрограммист, сделай хоть как-нибудь...
Безотносительно языка, полезно понимать общие идеи, которые стоят за этими подходами. Многопоточность - это когда "много потоков" - почти что отдельных процессов, но использующих общую память с основным, а асинхронность - когда поток-процесс всего один, но он выполняет разные задачи по очереди с переключениями в моменты ожиданий задачами ввода-вывода или результатов выполнения другой задачи/функции.
Когда у нас много ввода-вывода и мало процессорной работы, то асинхронность может быть очень эффективна, причём за счёт синтаксических конструкций (async/await) можно писать код очень удобно, наглядно и эффективно. Но любая вычислительная задача, любой синхронный код могут привести к заметным задержкам на выполнение других задач, это недостаток.
При этом асинхронная функция запускается быстро и дёшево, а запуск потока - это более сложная операция. Поэтому много коротких асинхронных функций это нормально, а много потоков с коротким временем жизни - нет. При многопоточности обычно или делят задачу на большие части, выполняющиеся в разных потоках, или разделяют по функционалу (например, GUI в одном потоке, вычислительные задачи в другом).
Ну а дальше начинаются вариации, которые в разных языках и фреймворках могут быть реализованы по-разному. Например, можно запустить несколько потоков и в каждом свой асинхронный цикл событий. Или асинхронные задачи распределять по пулу потоков, чтобы лучше утилизировать возможности многоядерных процессоров и уменьшить влияние синхронных кусков кода на задержки переключения задач.
Ксения Тимошенко, например, может через crontab или по вызову другой страницы (в том числе GET-запросом) восстанавливать и затем делать GET-запрос. Я бы посоветовал также проанализировать запросы с того же IP, что и сделал POST, возможно, будет сразу заметно, что именно делается. Также посмотреть cron на сервере (если это возможно) и возможно механизмы регулярных запусков задач в самом движке (я в WP не очень, не знаю, есть ли там такое).
Вообще, я сталкивался, что мошенники свои страницы засовывают, например, в свалку картинок в uploads, где их сложнее заметить. Если целенаправленно поискать там php-файлы, может оказаться, что вредонос быстро найдётся (и обязательно проверить содержание заглушечных index.php, которые должны быть именно заглушками). Кстати, неплохой идеей является настроить так, чтобы в каталогах, где не должно быть php-кода, файлы не выполнялись как код (но придётся повозиться с настройкой).
Ярослав, у меня у самого есть задача как-то красиво работать с данными, которые получаются, например, в виде json-структур, чтобы они прозрачно могли записываться в базу без написания кучи кода. Данные образуются при парсинге и архивации разных сайтов, и их структура очень разнообразна. Пока не смог придумать лёгкого и удобного решения. Для сайтов которые не меняются, можно данные сохранять как есть и грузить из них по необходимости, но бывает так, что данные могут удалять, а их нужно запомнить для истории (у данных есть уникальные ключи, которые позволят избежать дублирования). Придумал с помощью inflection конструировать объекты с полями на лету, а сами объекты описывать в peewee, но пока не получилось добиться работоспособности...
sqlalchemy вполне можно использовать как абстрактный интерфейс к базам данных, просто передавая в него строковые запросы.
А так, конечно, есть всякие https://github.com/web2py/pydal. да и в ORM-движках обычно есть средства замаппить ORM-объект в уже имеющиеся таблицы вместо создания их.
ENigma371, я бы посмотрел в сторону умеет ли он UUID или LABEL, потому что имя устройства, как я уже говорил, это ненадёжный идентификатор. В том числе и для физических дисков.
