Александр Леон-Булатов

Нужно найти файл php.ini той версии которой у вас на локальном сервере.
И выставить в этом файле такие настройки, или которые вам нужно..

upload_max_filesize = 200M
post_max_size = 200M

Посмотреть список работающих контейнеров:
docker ps
Подключение к контейнеру:
docker exec -t -i <container_name> /bin/bash
Смотрится структура директорий, находится где лежит проект и запоминается его путь. Выходим из контейнера

Копируем данные из контейнера:

docker cp <container_name>:<пусть к проекту> <путь куда копируем на текущем сервере>

select u.name, u.phone, sum(o.summa) total, avg(o.summa) average, max(o.created) last_date
from orders o, `users` u
where u.id=o.user_id
group by u.id
having total > 0

Я надеюсь, что "Поле created в формате Y-m-d H:i:s" это не строка, а DATETIME.

но даже после добавления ключей и запросов по этим ключам всё равно получается, что затрагивается огромное кол-во строк

этот explain надо еще научиться читать.
Вот неплохая статья для старта, особо присмотритесь к колонке type
https://mattweb.ru/moj-blog/bazy-dannykh/item/65-i...

Потом постарайтесь построить такие индексы, чтобы свести type к наилучшему варианту.

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

У меня возникала такая проблема. Оказалось, стояла галочка против автоматического прописывания адресов в hosts:

Решение - убрать галку

потому что могли))
если без шуток, https://stackoverflow.com/a/7095292

имхо, реального применения не имеет и стоит забыть.

Мне кажется, самый простой пример замыкания - это счетчик.

var counter = (function () {
	var current = 0;
	return function () {
		current++;
		return current;
	}
})();

console.log(counter()); // 1
console.log(counter()); // 2

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

var current = 0;
var counter = function () {
	current++;
	return current;
}

console.log(counter()); // 1
current = 5;
console.log(counter()); // 6

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

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

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Есть обалденная статья от 2015 года
https://blog.bullgare.com/2015/05/%D0%BF%D1%80%D0%...

Только примеры на js

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

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

Один момент - не все принципы одинаково полезны и применимы в веб-разработке, но знать и понимать их все в любом случае на пользу.