v3shin

Обычно поднимают балансировщик и делают так что сначала все ходят на 1.1.1.1.
Потом делают перевод новых сессий в новое место в пропорции 20:80.
И так далее пока все сессии не переползут.

function getLeaves(tree) {
  const result = [];

  for (const stack = [...tree]; stack.length; ) {
    const n = stack.pop();
    if (Array.isArray(n.children) && n.children.length) {
      stack.push(...n.children);
    } else {
      result.push(n);
    }
  }

  return result.reverse();
}

или

function getLeaves(tree) {
  const result = [];
  const stack = [];

  for (let arr = tree, i = 0; i < arr.length || stack.length; i++) {
    if (i === arr.length) {
      [ i, arr ] = stack.pop();
    } else if (Array.isArray(arr[i].children) && arr[i].children.length) {
      stack.push([ i, arr ]);
      [ i, arr ] = [ -1, arr[i].children ];
    } else {
      result.push(arr[i]);
    }
  }

  return result;
}

Эти ваши "гуру" просто ничего кроме примитивного PHPMyAdmin'а не знают. База ставится на хостинге, MySQL Workbench на рабочем компьютере. Подключение через ssh туннель, это штатная опция Workbench'а.

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

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

Тестирование конкретного модуля. Обычно - это самый нижний уровень, отдельные простые классы, т.е. ниже по логике уже будут отдельные функции. Например, в 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...

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

Дело в том, что флекс был не всегда. И раньше элементы в ряд выстраивали инлайн-блоками, ещё раньше флоатами.

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

В современном мире для построения сеток используют флексы и гриды.

Минусы как бы очевидны:

нет, не очевидны, по крайней мере миллионам разрабов

1 Код становится трудно читаем. По месту использования не всегда понятно что имеется ввиду под Order::load() - \Framework\Sale\Order::load или \Vendor\Project\Sale\Order::load - приходится проматывать к верху файла.

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

2 Код становиться длиннее - там где было бы просто:
\Framework\Main\UI\Extension::load([ 'vendor.module.components.cabinet.personal' ]);
приходится писать:
use \Framework\Main\UI\Extension;
Extension::load([ 'vendor.module.components.cabinet.personal' ]);

Код становится длиннее в проектах где 2 контроллера и в них по 1 экшену. Там где Extension::load будет вызываться больше одного раза, очевидно экономия на эксплуатации клавиатуры заметно увеличивается. А в больших проектах создание объекта может (и будет) повторяться многократно.

4 Код становиться замусоренным, так как верхушки файлов запросто превращаются во что-то вроде:

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

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

Хрен не знает, а ИДЕ замечательно знает и даже подсвечивает серым цветом неиспользуемые.

Если в iframe загружена страница с того же origin (протокол + домен + порт) откуда загружена текущая - то Вы имеете полный доступ к его window через свойство contentWindow. Соответственно можете обращаться к его DOM, глобальным переменным, менять их и т.д.

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

Если сторонний сайт отдает нормальные CORS заголовки при запросе с Вашего сайта (что судя по вопросу не так, но все же), то можно скачать страницу как текст через fetch api и распарсить ее через DOMParser.

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

Есть скрипт слайдера

Здорово!

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

Определить необходимую ширину в условие > выполнить "срабатывание".

Window.innerWidth
Element.clientWidth

как это сделать на чистом javascript

В целом, можно и на грязном...