Vitaly Karasik

Это нормальная практика, когда тестировщик итеративно смотрит сырые варианты. В определенных ситуациях это лучше, чем сделать готовый вариант, отладив программистами все баги и понять, что надо то было совсем другое.

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

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

У вас вероятно очень специфические задачи если производительности ноутбука за "цена вопроса не имеет значения" вас не устраивает.
Ноут лучшее решение.
Альтернативы:
Переносной накопитель. Ниже производительность, нужны современные интерфейсы, ниже надёжность, выше риск утраты включая возможность компрометации информации.
Любая форма rdp или удаленного ПО. Зависимость от сети.
Скриптованное окружение. Высокая сложность, издержки поддержки скриптов.

Ноут лучшее решение, в стационарных условиях к нему подключается внешний монитор или два.

а как тестировать крупные приложения?

Да точно также.

Как понять, что именно мне нужно покрыть тестами?

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

Ведь по логике нужный каждый кусок покрывать, чтобы быть на 100% уверенным в этом коде?

Да, но полное покрытие - это очень дорого, и часто не оправдано.

По тому, если приоложение большое, а тестов нет:
1. Покрываем самое критичное и важное, без чего просто жить нельзя, если оно поломается.
2. Покрывает то, где много изменений происходит, и есть шанс случайно поломать.
3. Покрываем всё новое, как часть реализации фичи.
4. Юнит тестами ещё есть смысл покрыть всякие общие компоненты, которые используются тупо везде.

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

А vue тут ни при чём.

Скорость света в вакууме 300,000 км/с, расстояние до Японии от Москвы по поверхности земли примерно 7500 км или 15000 км туда и обратно, что дает 50мс задержки. С учетом коэффициента преломления оптоволокна (порядка 1,5) - 75мс. Можно немного сократить, если пробурить канал напрямую вглубь земли и передавать световым пучком в вакууме без оптоволокна.

Но вместе с пингом 40мс вы все равно получите Нобелевскую премию по физике.

На самом деле каналов по прямой до Японии нет, данные идут достаточно сложным маршрутом и не в вакууме и 300мс это более-менее ожидаемый результат. Типичный маршрут для российских провайдеров - Европа - Северная Африка/Средний восток - Юго-восточная Азия - Япония. Можно поискать провайдера у которого есть пиринг с азиатскими IX минуя Европу, чтобы маршрут был "прямее", вы можете получить задержки. скажем, вдвое меньше. Прокси может быть найти сложнее, т.к. надо чтобы был прямой трафик до прокси и от прокси. Имеет смысл посмотреть в точки где может быть пиринг с европейской Россией и Азией, например наш дальний восток или Казахстан. Прокси в Японии скорей всего никакого преимущества не даст, нужен прокси где-то, куда есть более-менее прямой канал от вашего провайдера и откуда есть прямой канал на пиринги в Азии.
Если хотите маленький пинг - вам надо клиентский софт располагать в Японии (возможно вместе с сотрудником), а не прокси-сервер. Для высокочастотного трейдинга его располагают не просто в той же стране, где биржа, но и как можно ближе у того же провайдера или на самой бирже.

Посмотри show full processlist \G
Включи slow_log и посмотри, какие запросы следует оптимизировать.

При простом гуглении все быстро находится.
Вот например.

Эту инфу нужно искать в отрыве от языка, это уровень операционной системы.
Один из ответов на SO:
What is Under the Hood in a Stream in Programming?
Upd. Еще есть пересекающаяся тема как http streaming,
я когда-то для себя шпаргалку писала (ссылка)

Перед запуском докера создайте пустой файл и дайте полные права (конечно slow.log а не slow.cfg)

touch ./resources/docker/logs/slow.log
chown 777 ./resources/docker/logs/slow.log

- "./resources/docker/logs/slow.log:/var/log/mysql/mysql-slow.log"

А лучше пробросьте в контейнер всю папку logs

volumes:
      - "./resources/docker/config/my.cfg:/etc/mysql/conf.d/config-file.cnf"
      - "./resources/docker/logs/mysql/:/var/log/mysql/"
      - "./resources/schema/schema.sql:/docker-entrypoint-initdb.d/1-schema.sql"

Самое главное не высунуть php-fpm порт наружу в интернет что бы никто не запустит на нем какой-нибудь зловред.

Если же порт торчит из докера и прикрыт с наружи файр-волом то занчит вы знаете что делаете и принимаете на себя управление рисками you know exactly what you are doing (and are willing to accept the extreme risk)

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

Создать директорию с именем 1 и в случае успеха выполнить ещё одну команду которая создаст поддиректорию 2 в директории 1:
mkdir 1 && mkdir 1/2

А это mkdir 1 | mkdir 1/2 не логический оператор, а pipe - труба для направления вывода в другое приложение.

Не слетит, он на машиночасы распространяется, а не на конкретные машины.