Сергей П

Вы, видимо, не так понимаете суть современных систем контроля версий.
1. Вы настраиваете работающее окружение на работе и дома.
2. Делаете клоны проекта на работе и дома.
3. Работаете над проектом, каждое осмысленное изменение коммитите и время от времени отправляете в центральный репозиторий на гитхабе. Каждый раз приступая к работе обновляете локальный клон и продолжаете работать. Если фича требует много изменений, то вы можете сделать несколько коммитов в отдельную ветку и залить ветку на сервер. На другом компе вы тоже можете работать с этой веткой. Ветка лично ваша. У вас может быть много веток. Когда закочите работу над фичей - подольёте изменения в мастер.

SELECT DISTINCT t1.eid
FROM
    t t1
    JOIN t t2 ON t2.eid = t1.eid AND t2.key = 'patronymic' AND t2.value='Павлович'
WHERE t1.key = 'place_award' AND t1.value = 'г.Коломна'

И научитесь уже предоставлять исходные примеры таблиц в виде SQL, чтоб отвечающие могли быстро и без труда потестировать свои решения, а не писать из головы.

1. Прийти в серверную, взять сервер и приподнять его. Проблемы: обычно сервера прикручены к стойкам. Легко поднять неприкрученный сервер, прикрученный следует открутить, отсоединить и тогда уже поднимать. Не забудьте потом всё опустить и подключить как было.
   
2. Взять и купить на месяцок самую дешевую виртуалку (VDS) на каком-нибудь лоу-кост хостинге. Выберите ubuntu, поставьте docker, запустите в отдельных контейнерах (и пропишите в контаб) VPN, прокси для Телеграма, сервер майнкрафта. Каждое из этих действий делается одной командой. Проблемы: осторожно, на такой сервер легко подсесть. Стабильно работающий телеграм, отсутствие блокировок сайтов, свой ламповый сервачок майнкрафта - к этому быстро привыкаешь. Потом захочется поднять своё облако, запустить свою интернет-радиостанцию для друзей... Будьте осторожны, если борода прорастёт сквозь свитер, от них будет трудно избавиться.
   
3. Внимательно изучите предметную область в рамках которой вы проходите стажировку и, наверно, станет понятно о каком сервере тут может идти речь. Может быть вы в грузчики метите и тогда см. п.1.
   
4. Наверно ваш вопрос разумно задать тем, кто поставил такую задачу, а не неопределенной группе лиц, которые помогают новичкам решать технические задачи.
   

Интересная задачка у вас: NP-полная, но при ограничениях реального мира вполне разрешимая.
Коммивояжер ваш имеет ограниченный ресурс по числу пунктов доставки. Доставку, наверно, нужно делать в заданных временнЫх рамках (пока горячая).
Итого ваша задача разбивается на две:

1. Распределить заказы между курьерами. Причем какие-то курьеры еще в пути, какие-то в резерве. Скажем, курьеров у вас 7: один в пути далеко, еще один на подходе и трое стоят под загрузкой (плюс двое в резерве на подхвате на случай аврала). Есть поток задач на доставку и нужно распределить их между курьерами максимально эффективно.
   
2. Расставить задачи одного курьера в очередь так, чтобы при обходе точек назначения минимизировать какой-то параметр. Обычно это время, поскольку бензин, расстояние и стоимость проезда вторичны и коррелируют со временем.
   

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

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

Для начала я бы провёл кластеризацию адресного пространства. Построил бы матрицу "цены" перемещения между узлами. Вынес бы роутинг на отдельный изолированный слой, чтобы не быть сильно зависимым от конкретного построителя маршрутов.
Можно глянуть, например, в сторону OSRM.

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

Вообще технически можно ещё круче сделать, чтобы один курьер второго мог перехватить по пути и перераспределить с ним часть заказов так, чтобы совокупный расход на перемещение был меньше.
Здесь курьер, получается, может доставлять товар еще и в произвольную точку рандеву другому курьеру.
Если у вас мультимодальная система доставки с пешими и "конными" курьерами, то часть товаров, возможно, будет проще выпускать и развозить по магистрали автомобилем, а пешие гонцы перехватывают грузовик по пути и разносят локально.
Можно попробовать глубже копнуть роевые алгоритмы.
Каждый акт перемещения курьера, приёма/передачи товара (от ресторана курьеру, от курьера курьеру), подготовки заказа в конкретном пункте выдачи - это ветвоение в дереве решений.
Такие ветвления могут быть реальными и потенциальными:

• Реальные необратимы и по своему факту отсекают потенциальные ветки связанные зависимостями.
  
• Потенциальные ветки имеют свою цену и динамически характеризуются числом зависимостей. Зависимости бывают мягкие и критические: чем большим приростом потенциально цены обернётся отсечение ветки, тем более она критична.
  

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

Короче, добро поджаловать в логистический адок.

У вас там однотипные кавычки, во-первых. Это уже не хорошо.
Во-вторых, вы перенаправление вывода делаете не там. Портится синтаксис вызова.
Объявите функцию, в ней делайте что вам надо с перенаправлениями и вызывайте уже её.
Вот здесь про объявление и вызов функций: https://habr.com/ru/company/ruvds/blog/327248/

function myfunc {
ffmpeg ... >> out.log
}

Откройте дебаг-консоль браузера и посмотрите какой именно запрос делает браузер для скачивания файла. Нажмите правой кнопкой и скопируйте CURL-команду для выполнения этого запроса из командной строки.
В условиях той скудной информации что вы предоставили (без примеров) вам подробнее ничто не подскажет.

https://developers.google.com/webmaster-tools/sear...

Функция в питоне - это объект первого рода.
В питоне всё - объекты. И функция и число и строка и список и словарь и класс и экземпляр класса.
У каждого объекта может быть много имён. Рассматривайте имя объекта, как ярлычок, привязанный к чайному пакетику.
print_friends_count(count)
Здесь print_friends_count это имя переменной, а скобочки после него заставляют вызывать объект, доступный пр этому имени как функцию. Вызов происходит с передачей единственного аргумента, который доступен по имени count.

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

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

Мне кажется вам стоит скачать книжку Лутца про изучение питона с нуля и вдумчиво прочитать. По порядку.

Мне приходилось работать с JSON файлами по несколько гигов размером (6 - 7, если не изменяет память). Такой большой файл долго и монолитно грузится, плохо помещается в память в виде объектной модели, в общем так себе идея делать такие файлы, но поставщик данных предоставляет их именно в этом виде и работать надо.
Поэтому я соорудил простенькую утилитку, которая представляет собой своеобразный SAX парсер, но для JSON.
Утилита принимает огромный JSON в виде текстового потока данных, реагирует на открытие и закрытие тегов и выдаёт куски поэлементно в виде последовательности отдельных JSON строк, разделенных абзацами (в соответствии с RFC7464).
С таким потоком небольших однотипных кусков справляться гораздо проще.
Потом, кстати, мне подсказали, что известная и замечательная утилита JQ тоже умеет работать в таком режиме (SAX). Но свою задачу я уже к тому времени решил и в тонкости параметров командной строки для такого режима JQ не углублялся.

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

Вопрос форм-фактора открытый, но идея гиротрекера - очень годная идея.
Сейчас практически все камеры на борту имеют Wifi. Можно попробовать сделать гиротрекер на базе белкой ESP8266 с wifi. Синхронизацию времени с камеры можно брать по wifi. Даже подкидывать на флешку камеры файлы с гиро-треками можно, если API позволит.

JPEG не нужен.
Отмасштабируйте png с помощью PIL (Pillow)