Виктор П.

при таком количестве аппаратуры нафирме должно быть н-ое количество запасных готовых к работе частей. ибо самое лучший ремонт "боевых" элементов - 100% замена.
спорси разрешение использвать эти запчасти для изучения системы магазов, т.е. взять две камеры, собрать из програмок, установленных в живой системе у себя на ноуте с нуля на чистой операционке систему сбора видеоинформации. далее настроить работу IP-телефонии на основе имеющегося по друкой оборудования и ПО и т.д. и т.п.
стобально будут непонятки, глюки и система сразу не запуститься. ну а дальше ищи ответы на свои вопросы. при этом не пое...общавшись с настройкой системы, почитав попутные man howto и т.д. ты будешь задавать уже разумные вопросы ентим 4 "крутым" админам. а правильно и технически грамотно заданный вопрос очень возвышает тебя в глазах вопрошаемого :)
системный админ должен знать как с нуля собрать систему (а считай енто подразумевает знание структуры системы и взаимообмена данными).

Не ваш случай, наверное, хотя указано про авторизацию в JSON'e.
В Docker for Windows пользовать может быть авторизован по e-mail, а docker-cli авторизуется по Docker ID.
Тогда нужно авторизоваться в Docker for Windows с помощью DockerID (а не e-mail). Для них это разные вещи и это обсуждалось на GitHub

Зарплаты весьма высокие, т.к. необходима высокая квалификация даже на старте. Но не у нас. И удалённой работы, совсем не так много, как в IT, к сожалению.
У нас мало рабочих мест, зарплаты, обычно, довольно печальные, в сравнении с тем же IT, большая часть разработки электроники, в целом у нас, это оборонка, и там свои заморочки...

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

В перспективных разработках чаще всего будут ARM и ПЛИС. 8/16 битные микроконтроллеры, хоть и используются местами, но чаще из-за инерции, или очень специфичной периферии.

P.S. Я сделал, кстати, ровно обратный переход, и совершенно о том не жалею. Сейчас, если жить в России, к сожалению, разработка электроники хороша, только как интересное хобби, а не как прибыльная работа.

Причин может быть несколько. Если у вас подозрения на медлительность CMS — сделайте статическую копию страницы с высоким TTFB. Измерьте данный показатель на статике. Так, вы сможете определить, насколько ухудшает TTFB скорость генерации контента Wordpress'ом. Если показатель метрики не слишком отличается, присмотритесь к оптимизации ресурсов сервера.

Может быть вам просто освоить Git?

1) Тестировщик - это сотрудник в штат или сотрудник в штат на удаленку. На Фрилансе ничего сложнее заказов "протыкать сайтик, посмотреть ошибки, уязвимости" тебе не дадут. Ибо, мелким заказчикам тестирование не нужно, а крупные уже набирают в штат (НДА, знакомство с системой и прочее).

2) На западе считается, что тестер - это обезьяна, поэтому платят копейки. Реальные деньги появляются, когда ты становишься либо безопасником, либо QA-Аutomation (а это уже знание Java/Python + базы данных и прочие тестовые фреймворки).

3) Тестирование - это прослойка между ПМ и Разработкой на более менее крупных проектах. Собственно, если нет этого, то прослойка в виде тестера не нужна.

_____

Если кратко, то в тестировании хорошие деньги получают только лиды, qa-automation, безопасники - это 3-4 года опыта надо. Разработчики в целом получают выше, да и всегда остается возможность сделать что-то свое. Т.е. разработчиком быть выгоднее. Вопрос только в том, что в тестирование зайти проще, да и всегда можно в разработчика перерасти.

на чистом js:

var button = document.getElementsByClassName('btn')[0];
    button.onclick = function() {
    location.href = 'http://google.ru';
}

Html и css с практическими задачами лучше изучать на htmlacademy.ru. После того как освоился, качаешь бесплатные psd макеты и верстаешь, с адаптивом, какие-то сложные вещи, которые не можешь сверстать оставляешь пока.
Далее ищешь видео где верстают макет, обычно на первых секундах-минутах показывают макет и сразу можешь понять сможешь ли сверстать сам или нет, если понимаешь, что не сможешь, то смотришь как автор это сделает, узнаешь новое для себя.

По php. Читать большие и толстые книги пока бессмысленно, всё прочитанное будет вылетать из головы. Ставишь OpenServer, и сразу в бой:
1. Переменные, условия, циклы, массивы.
2. Пользовательские функции
3. Базовые функции по работе со строками и с массивами. Комбинация функций. (важно понять и запомнить что они умеют).
4. Post и Get запросы, получение Post и Get запросов из формы (тут сразу и html по формам подтянешь)
5. Базы данных, простые запросы к базе, выборки, запись в базу данных из формы.
6. Куки, сессии.
7. Чтение и запись в файлы.
8. Регулярные выражения.
9. ООП, базовые понятия. Самое сложное и непонятное для новичка. Непонятно потому, что не ясно зачем это нужно и почему это в дальнейшем упрощает работу, поэтому как-то мимо ушей все пролетает.

Если с английским хорошо, то codecademy.com.
Если плохо, то базовую теорию (и сразу практику) делать здесь.

Далее лучше сразу переходить на фреймворк (лучше Laravel). MVC в теории тоже понимается плохо потому, что пользу донести до понимания новичкам сложно, а при работе с фреймворками сам понимаешь почему это удобно.
Во время изучения фреймворка и ООП подтянешь.

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

То есть чтения меньше, практики больше. Это про голый PHP.

Про фреймворк, если английский позволяет то Laracasts: Laravel 5.4 from scratch. Если не позволяет, то ищешь в ютубе что-то вроде "простой блог на Laravel", смотришь и кодишь параллельно у себя.
Тут тоже самое, под попкорн просмотреть всю серию роликов от начала до созданного блога с админкой бесполезно. Обнаружится потом, что не можешь даже базовые вещи сделать. Нужно делать параллельно с автором, он делает какой-то функционал, смотришь, делаешь также, изначально может быть непонятно многое и зачем автор это делает, но со временем поймешь как это работает.

Далее пробуешь сделать что-то свое, какие-то "фичи", например авторизацию с помощью соц. сетей, лайки к постам и комментариям (с помощью ajax, тут можно jQuery изучить чуть-чуть), вложенность комментариев и т.д. Можешь другой себе проект придумать(представь себя стартапером).

Далее можно изучить системное администрирование чуть-чуть, покупаешь VPS недорогой, ставишь Nginx, MySQL, PHP-FPM и т.д. Пробуешь залить туда свой проект, так чтобы всё работало. Далее можешь попробовать прикрутить какой-нибудь поисковый движок (Sphinx, например). Изучение командной строки тоже на codeacedemy.com есть.

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

Сам изучаю всё это недавно. До этого был Python+Django(первый фреймворк). В команде никогда не работал. Так что можно сказать передаю опыт от новичка новичку.

Во первых нужно закладывать время на разбор легаси кода, об этом сразу надо говорить с заказчиком. Зная задачу, всегда понимаешь, ЧТО надо написать, но в случае с легаси надо еще и понять КУДА это написать. Без этого никак и поэтому это время надо учитывать.

Второе. Когда-то меня учили, что код нужно менять только дописывая его, в крайнем случае удаляя, но ни в коем случае не переписывая. Поэтому, если надо изменить поведение - наследуешься, переопределяешь метод и используешь новый класс. Мне сложно судить о php, как этот проект реализован, но ООП для того и придумали, что его легче поддерживать и он легче модифицируется.

Следующий вариант изучить код, начинать писать тесты к нему. Я этим способом пользуюсь редко, в основном пишу на то, в чем я не уверен, что боюсь сломать.

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

А вообще чтение легаси, это дело опыта. Я помню первые свои чужие проекты, я думал, что попал в ад. Сейчас копаться в чужом коде, это мое любимое дело) Я могу часами сидеть разбирать чужой код, что начальству приходится меня попускать: "я понимаю, я тоже это люблю, но надо дело делать")) Люблю просто на гитхабе полазить по чужим проектам, посмотреть как люди думают.