Nikita

Самый неправильный способ обучения - с конца. Это очень неэффективно если не бессмысленно, изучать программирование непоследовательно.

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

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

Советую изучать с низов, самостоятельно, чтобы было понимание каждого шага, всего что происходит.
* операционные системы, процессор и многопоточность, сети,...
глубоко изучать это не требуется но базовые понимания нужны чтобы не получать медленное приложение только потому что не знал что каждый твой запрос в tcp это 'туда-сюда', и это медленно (десятки миллисекунд), что одновременно два человека пытающиеся что то изменить на сайте нужно разруливать чтобы не было конфликтов и т.п.
* бакэнд и фронтэнд
буквально что значит запрос и генерация ответа, какие бывают способы организации этого бакэнда (http rest и к примеру websocket), не понимание разницы между бакэндом и фронтэндом у новичков рождает абсурдные вопросы как из javascript изменить переменную php (и наоборот)... в чем разница между генерацией страницы на сервере и в браузере.
* html, css,..
верстка и дизайн, отдельный мир браузерных стандартов, исторических наслоений,. когда стоит применять фреймы, почему шрифты по разному выглядят, разные устройства и размеры экранов, разные способы взаимодействия (сенсорный экран, мышь, клавиатура)...
* базы данных
еще более огромный мир атомарных транзакций, индексов, нормальных форм и прочего
* девопс
без умения выбрать инструмент, настроить тулчейны, среду разработки, среду исполнения (веб сервер), настроить бакапы и прочее пытаться что то разрабатывать это как в слепую гулять по лесу, будешь постоянно на ветки натыкаться
...
это я еще про системную аналитику не сказал, обычно прежде чем что то создавать, нужно продумать как это все делать, что такое технический долг и т.п., а еще есть тестирование, обслуживание, работа с отказами (сервер сдох, база упала, как все восстановить), обновление на живую и прочие веселья

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

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

Опишу простыми словами для упрощения понимания.

модульное тестирование

Тестирование конкретного модуля. Обычно - это самый нижний уровень, отдельные простые классы, т.е. ниже по логике уже будут отдельные функции. Например, в JS есть класс Math - тестирование всех его методов и есть модульный тест. Конечно, границы между логическими уровнями могут быть размыты и в данную категорию вполне можно вписать класс уровнем выше. Так же, модулем может быть и что-то более сложное - опять же, много зависит от масштабов и особенностей архитектуры.

интеграционное тестирование

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

функциональное тестирование

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

какими инструментами оно делается?

Инструментами автоматизации GUI - для сайтов это Selenium и браузеры. Для десктопных/мобильных приложений аналогичные решения.

приемочное тестирование

в че отличие от интеграционных.. еще видел фразу что тут и фронт и бек тестируются, но яснее не стало, какими инструментами оно делается?

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

E2E - тут тестируется чрез браузер, с помощью Mocha и тп, те тестируются "требования бизнеса к приложению", тестируются пользовательские сценарии.. а в чем отличие от функциональных тестов тогда?

Сквозное тестирование. Это полная проверка от начала и до конца. Отличие от функционального в том, что это более комплексный тест. Если функциональное тестирование - это проверка конкретной функции, тот сквозное - работа всего приложения, т.е. более комплексное. Например, E2E тест приложения для загрузки файла на сервер: тест включает в себя запуск приложения, авторизация пользователя, выбор файла, указание мета информации, загрузку файла на сервер, выход из приложения. Вот тут неплохая статья на хабре: https://habr.com/ru/company/otus/blog/681066/

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

Картинка отсюда: https://www.rainforestqa.com/blog/the-layers-of-te...

Сколько людей - столько мнений. Не стоит прям вообще всех слушать, кто высказывает какие-то "гениальные" откровения. Даже внутри крупных фреймворков многие вещи реализованы по разному, и каждый считает что именно так надо, и никак иначе. Думаю автор статьи просто искал дешевого хайпа, на практике никто так не делает. Контроллер по сути не модель, а управляющая конструкция, в ней нормально внутреннее ветвление на методы. С таким же успехом можно решить что для модели нужно 4 репозитория, на каждое действие CRUD...

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

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

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

В компьютере много устройств. Если бы они напрямую друг с другом общались, мы бы никогда не добились такого развития цифровой техники. В компьютере есть ШИНА, и управляющее устройство, которое поочередно работает то с первым устройством, то со вторым, и когда они одновременно что-то хотят - они ставятся один за другим с проверкой "кто раньше и кто сейчас может".

Таким образом дебажится лог запросов и ответов с "шины" (эта шина пишется хорошим сеньором, либо ставится и долго настраивается хорошим сеньором), чтобы понять кто когда кому чего спрашивал.

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

Если вы все же очень хотите сохранить это рабочее место (но дальше - только хуже) - вы можете либо дампать в браузере, делая прямые запросы, логику смотреть в бд, а если логика прям жесткая - подключите пакет Monolog\Logger в dev-dependencies ко всем проектам, и включите Handler который складывает все логи в канал с одним и тем же местом хранения, и потом смотрите в каком порядке логи идут (у вас как раз и получится логгер вместо шины, только он не дает никому комманд, а только пишет что за чем произошло, это тоже задача шины и её мощь)

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

Полгига памяти для браузера категорически недостаточно. Swap можно было бы попробовать сделать гига два-четыре, но у вас на это диска не хватит, если я правильно понял конфигурацию. Эта виртуалка не подходит для десктопа.

Начнём с того, что 500 шт. каждые 5 с - это 100 запросов в секунду. Прокси будут баниться очень быстро при подобном трафике.

Далее, получение данных мегабыстро имеет смысл в автоматизированных системах торгов на фондовой бирже, а если это в телеграм человеку сливать, то он в любом случае будет реагировать намного медленнее этих 5 секунд. И зачем тогда так часто опрашивать? Если опрашивать с интервалом в 3 секунды, то товары будут приходить с опозданием в среднем 13 минут, максимум 25 минут, что для многих задач вполне приемлемо.

Советую поговорить с заказчиком ещё раз на тему того, что именно ему нужно.

Установи либу через composer и не нужно мазохизма.
В папке с проектом выполняешь ту команду которую говорит документация и подключаешь автолоад
require "vendor/autoload.php"

На первом скриншоте - возможно выделенная для VM ОЗУ, на втором-потребляемая внутри VM.
Ну и так как guest tools не установлены - proxmox не получает нужную информацию изнутри VM.