Сергей П

Во всех случаях, где это позволит сделать код более читаемым и лаконичным.
ООП ужно людям, чтобы легче было писать более сложные программы. ООП при правильном использовании позволяет изолировать сложность в отдельных классах так, чтобы эта сложность не накапливалась единым запутанным клубком в одном месте.
Почитайте про принципы SOLID.

модуль subprocess позволяет выполнять консольные команды и получать их выхлоп (в том числе в реальном времени).

А зачем вы это пытаетесь делать? Судя по всему вы просто не понимаете чего хотите.
Докер у вас доступен в терминале хоста. Сам контейнер ничго про докер не знает и не должен знать.
Очень странно хотеть из терминала контейнера пытаться что-то сделать с докером.
Если отвечать на вопрос буквально, то можно сделать ssh-соединение с хостом, но после жтого вы уже в терминале хоста через ssh, а не в терминале контейнера непосредственно.

При такой постановке вопроса на любом языке у вас CMS медленно будет работать ввиду недостатка опыта правильной разработки.
Язык программирования нужен не для скорости, а для понятности людям. Скорость выполнения кода не так критична в вебе, как правильная архитектура. Иначе всё бы писали на ассемблере, но где вы видели сайты на ассемблере? Нет, наверняка такие есть и вполне можно сделать какой-нибудь фреймворк с CMS хоть на ассемблере, хоть на брейнфаке, но это глупо.
Обычно язык программирования не является бутылочным горлышком для скорости CMS.
Ошибки в архитектуре, непродуманная масштабируемость, отсутствие кэширования, излишняя связность, избыточность внешних зависимостей, пренебрежение CDN -- всё это гораздо сильнее влияет на тормоза и все эти проблемы можно реализовать на любом языке.
Язык нужно выбирать так, чтобы он давал возможность делать код более простым, читабельным и понятным не смотря на его количество. У языка должно быть большой комьюнити, чтобы можно было легко находить недорогих и эффективных специалистов для поддержки проекта.

У целого числа нет метода replace.
Чушь написана в коде.

Вы немного не в том русле пытетесь решить вашу проблему.
Бэкапить целиком разделы машины - это не очень хорошая идея, потому что ломаются не только диски, но и сама система при обновлениях (вы же не будете отказываться от обновлений езопасности, например), могут возникнуть уязвимости и всякие там шифровальщии пошифруют вам тома, да мало ли чего еще может произойти. что бинарный бэкап по какой-то причине не поднимется и придётся вам очень геморрно выковыривать работабщий сервис из бэкапа системы.
Правильный путь - это бэкапить БД и раздел со пользовательской статикой отдельно, а исходники и систему бэкапить не надо. Система должна быть максимально стандартной и чистой, а бэкенд должен развораичваься в докер-контейнерах по апуску компоуз-файла.
Преимуществ много:
- прозрачная понятная и декларативно описанная конфигурация,
- отсутствие зависимостей от хостовой системы,
- толератность к подъёму любого количества стейджинг сереров,
- удобно вести разработку и запускать на машинах разработчиков,
- удобно бесшовно мигрировать на новое железо, когда только начали сыпаться предупреждения от SMART а не когда жареный петух SSD одолбает,
- гораздо эфективнее расходуется место для бэкапов: бэкапятся толкьо данные (БД и файлы),
- вся конфигурация толерантна к системам контроля версий, а значит легче разматывать и решать проблемы,
- вы запросто поднимите запасной или временный сервис где угодно, прежде чем погасите рабочий для какой-то цели,
- можно быстро (одной командой) развернуть временный сервер на любой машине, пока не настроите штатный сервер взамен умершего.

Если хотите максимально упростить работу всем -- делайте скрипты оркастрации (с комментариями), которые будут поднимать, опускать, развёртывать, бэкапить и поднимать бэкапы. Через пару лет, когда забудете как там всё устроено, эти скрипты и комментарии сильно сэкономят время.
Не забывайте, что помимо основной конфигурации есть еще SSL-сертификаты, которые имеют свойство "неожиданно" просрачиваться, конфигурация Nginx, которую тоже хорошо бы положить в соответствующем контейнере, и прочее. А ещё есть IP-адреса внутренних DNS и всяких шлюзов, которые могут поменяться, а тупой подъём бэкапа только усугубит ситуацию. Да и на поднятом из бэкапа сервере скорее всего давно не одновлялся сертификат и так просто ваш сайт не заработает.

Короче, нельзя просто так взять и забэкапить винт сервера, чтобы не поиметь проблем при любых обстоятельствах.

Не помню уже за какой там класс, но годы прошли, а четкая ассоциация осталась: задачник, физика, чертов воробьёв (это фамилии соавторов, а не игра слов). Гуглите, я по нему лет двадцать назад тренировался.

Ну так а в чем у вас проблема-то? Вы в принципе не знаете как запрос писать и это задание такое?
Если так, то данный ресурс не для этого.
Если у вас конкретный вопрос, то заайте его конкретно. Что именно у вас не получется?
Не ясно как сформулировать рамочные условия с интервалами, пересекающими конкретную дату?
Не понятно как сгруппировать интервалы по товарам?
Не знаете про coalesce?
Запутались с граничными точками интервалов?
В чем проблема?

Наверно сам не заметил как поправил crontab через sudo и старое запускается оттуда. Или наоборот, из под пользователя, а новые изменения от суперъюзера.

получить информацию из огромного json массива

Я уж думал у вас проблема с чтением действительно огромного JSON-файла. Такое бывает, когда файл не помещается в памяти, но из него что-то нужно достать. Приходится читать JSON-файл SAX-парсером, чтобы не помещать все данные в оперативку.
Но тут поблема, очевидно, в другом.
Нужно по нечетко поставленной задаче для автора вопроса написать код, который тривиально преобразует json более простую стркутуру.
Просто автор вопроса не умеет, зато это не мешает ему писать бота.
Вам стоит проследовать на биржу фриланса с этим вопросом, или свормулировать конкретно что именно вам не понятно.

pojarcky, тут же не клуб экстрасенсов, как мы поймём, что дёргающиеся гифки - это у вас чатом зовётся? В указанном примере никакого чата не наблюдается.
ок.
Проблема может возникнуть при захвате чата и при слиянии (не понятно как вы это делаете).
Посмотрите отдельно на поток чата до слияния. Попробуйте запустить слияние с теми же настройками с другим нормальным роликом нужных пропорций.

Решение всех проблем всегда однотипно: разедить проблему на части и реашть их по отдельности. Если какая-то из частей слишком велика -- см пункт первый.

Как обычно, как любой другой сервер.
Проектируете API, реализуете необходимые модели данных, создаёте хендлеры для API, настраиваете CI/CD и разворачиваете на сервере в интернете, например VDS. Помимо прочего ставите Nginx, который будет заворачивать трафик в SSL и раздавать статику. Сертификат можно получить бесплатно через Let's Encrypt. Нужно лишь настроить специальный скрипт (certbot), который раз в месяц будет этот сертификат автоматически продлять.
Кто там к вам на API будет ходить: браузер или мобильное приложение - это не важно.

Если спрашиваете совета как решить проблему, приводите воспроизводимые примеры.
Мало того. что код не проверяете на опечатки, так еще и проблема у вас какая-то локальная. Может быть комп тормозит, может быть страница в браузере, может быть js на ней тупо рандомные нажатия клавиш пропускает.
С учетом невоспроизводимости вашей проблемы, разумно было бы хотя бы попробовать дугие драйверы, хром тот же... А-то складывается впечатление, что "ой что-то не работает памагити!!!111"

Питон проще осваивать, к нему больше примеров, библиотек, обучающих курсов, книг и открытого кода в инете. А ещё полно удобного инструментария. Для любых ваших проектов питон подойдёт не хуже го.
Когда вы готовы разрабатывать на Го, у вас уже не возникает вопроса питон или го. А если возникает, значит питон.
ИМХО.

Но го неслабо так развивается и у него большие перспективы, как мне кажется.

Я бы строил следующую систему:

1. Приёмная антенна базовой станции или ретранслятор в виде баофенга с аккумулятором устанавливается либо на господствующей высоте, откуда есть прямая видимость большей части полигона, либо поднимается на привязном водородном аэростате. Водород получать несложно из алюминия и воды с щёлочью (для снятия оксидно пленки), для этого можно приспособить старый огнетушитель в качестве реактора, он не боится нагрева от экзотермической реакции и давления. В качестве щелочи дешево и эффективно работает "Крот" (лучше сыпучий). Вот отличный видос про это.
   
2. Для пятикилометрового полигона с учетом поднятой на шаре антенны и более-менее прямой видимости можно использовать безлицензионный диапазон 433 МГц, или двухметровый, который будет луше обходить деревья и небольшой рельеф.
   
3. Спортсменам можно выдать дейвайсы с цифровыми приёмо-передатчиками (вроде таких), которые в непрерывном режиме на своём канале будут передавать последние точки трека, полученные GPS-приемником. Можно даже зуммер поставить, для сигнализации чек-поинтов.
   
4. На чек-поинтах можно поставить такой же приёмопередатчик со свето-звуко-сигнализацией.
   Энерговооружение и мощность чекпоинтов можно обеспечить выше, в том числе за счет дешевой китайской радиостанции (типа такой). Она управляется через стандартный разъём, к которому можно приделать ардуинку с локальным приёмо-передатчиком ближнего поля, RFID-сканнером, релюшкой для сигнализации.
   
   

За счет многократной передачи цепочек координат получается избыточность, и не критично наложение передач. Важно, чтобы интервалы передачи от чекпоинтов были взаимно-простыми или рандомизированными.
Стандартные баофенги в качестве приемо-передающих станций делают элементы системы дешевле за счет массовости. Сами вы добротные стании так дешево не сделаете, а эти можно и про запас иметь парочку.

Если сделаете компактный ошейник, способный несколько дней транслировать раз в 5 минут цепочку получасовую координат трека, записанного с тридцатисекунжным интервалом, то я кубил бы такой для собаки. Но нужен компактный. На чихуа тяжелый вешать не гуманно.

Если совсем упарываться по бюджету, то можно действительно китайские модули на 433 МГц и LoRa протокол, но с носимых устройств передавать надо по кругу очередь последних координат трека.
Станции можно сделать на основе RFID-дальнего поля, но это выйдет дороже.
MESH-сеть - тоже интересная мысль. В этом случае чекпоинты и базовая станция будут плюс-минс одинаковыми, но к базовой станции подключен комп и снимает логи всех передач в сети.

Нет, вы можете получить листинг каталога по маске glob.glob('*.user'), потом взять максимальное (в алфавитно-цифровом порядке) имя, отрезать у него расширение, превратить в целое число, увеличить на единицу, отформатировать нулями слева и создать новый файл.

last = max(glob.glob('*.user')+[''])
new = (last and int(last.split('.')[0]) or 0) + 1