Сергей Горностаев

зачем делать разархивирование внешним, если можно элегантно покодить ?

import zipfile
zip_ref = zipfile.ZipFile(path_to_zip_file, 'r')
zip_ref.extractall(directory_to_extract_to)
zip_ref.close()

vagrant

data = {"method": "startLiveview","params": [],"id": 1,"version": "1.0" }
with requests.post('http://192.168.122.1:8080/sony/camera', json=data, stream=True) as r:
    for chunk in r.iter_content(chunk_size=8192):
        # Делай что-то с куском в 8кб

маст хев:

Понимание принципа работы ssh ключей, чтобы уметь настроить себе доступ на линукс машину или в гит (bitbucket/github/etc)

Базовое понимание git и то, что висит поверх него (github, bitbucket, etc) чтобы не путаться в пулл реквестах, понимать зачем они и как организована у вас работа - неймконвенш для веток, как ревью делается

Если пишете под докер, то Dockerfile - это в основном ответственность разработчика. Где его запускать - уже второй вопрос.

Вы должны уметь ваше приложение развернуть на локальной машине, и понимать как его развернуть на другой машине.
Jenkins\Teamcity - это тулзы, где девопс старается автоматизировать то, что вы разворачиваете на локальной машине. Вы его консультируете где и откуда вы читаете конфиги, возможно у девопсов есть какие-то централизированные способы для этого. Но Jenkins\Teamcity вам нужны на уровне продвинутого юзера. Можно на месте попросить девопса вам показать базу.

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

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

Не надо с ней бороться, вы не победите.

Нужно понять и использовать. Чтобы понять - прочитать про EventLoop.
Чтобы использовать - прочитать про Promise, и async/await (в свежих версиях, либо с транспилером)

Какой смысл использования node.js и прочего для backend на фрилансе, если все заказчики, в основном, просят натяжку на CMS, где нужно понимание php.

???

Мои "все заказчики" - просят разработать заказное решение (не CMS) и совершенно не интересуются на каком инструменте я буду это делать (я вообще на Go делаю бэкенд, а на Dart фронтенд).

опять же, для фриланса, на каком уровне нужно знать backend?

В дешевом сегменте вам нужно знать все.
В дорогом сегменте - узкая специализация очень полезна.

если все заказчики, в основном, просят натяжку на CMS, где нужно понимание php

False

на CMS, где нужно понимание php

False

на каком уровне нужно знать backend

на уровне - я знаю как решить данную проблему за Х часов, я ее уже решал минимум два раза