alexalexes

У true программистов всегда было много вопросов к switch (как в свое время к go to). Поэтому в любой непонятной ситуации используйте цепочку if else, так вы будите ближе к строгим стандартам.

if(a > b) {
  alert(a + b)
} else if(a < b) {
    alert('Lorem Ipsum terebismum')
} else {
    alert('Isn"nt number')
}

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

Потому что, это Lite. У локальных СУБД должно быть минимум функционала и максимум переносимость в любую среду разработки.

Гуглите border-radius.
1. border-radius делаете >= 50% и у вас получается круг.
2. Закругление можно делать по отдельным сторонам блока.

выдает только фон

$image = imagecreatefromjpeg('/banner/png');
Символ около расширения файла не смущает? И расширение png для метода *jpeg?
PS: если вы var_dump-ните $image, то обнаружите false - значит, что-то с путем к файлу или его отсутствие.

В цепочке Телефон -> ПК интерфейс usb будет беспокоить в последнюю очередь в плане надежности и скорости.
Чтобы начать беспокоиться насчет usb, вам нужно гонять трафик не менее 1 Гбит/с или иметь отклик не более 1 мс.
Либо если у вас между телефоном и ПК более 5 метра провода.

Очень принципиально по производительности имеет значение количество атрибутов в строке выборки, и есть ли там бинарные типы данных или длинные строки - это именно то, что будет просаживать производительность при попытке сделать большую выборку.
Если в реальной системе из этой таблицы выбираются сначала "легкие" атрибуты в тысячи записей, а потом по конкретным записям дозапрашиваются "тяжелые" атрибуты (бинарные данные, длинные строки).
То синтетический тест:
SELECT * FROM articles LIMIT 1000
к реальной жизни не будет иметь никакого отношения, потому, что вы выбираете все атрибуты (*), при наличии "тяжелых" атрибутов, в здравом уме никто не будет делать такие большие выборки. Разве что, если это не импорт/экспорт - но это сам по себе процесс затяжной.

Если нет особых требований, то пока удобно создать такие таблицы:

Таблица "План накопления статистики"
id - идент. плана
begin_date - дата/время начала сбора статистики
end_date - дата/время окончания сбора статистики
name - название плана
description - описание плана
interval - интервал накопления статистики в секундах
... - другие параметры плана

Таблица "Точка фиксации показателей"
id - идент. точки
plan_id - инд. плана накопления статистики
begin_date - дата/время начала сбора данных для точки фиксации
end_date - дата/время окончания сбора данных для точки фиксации

Таблица "Агрегированные показатели точки фиксации"
id - идент. показателя
Name - название показателя
measure_id - инд. единицы измерения показателя (тоже нужна таблица справочник: байты, биты, байт/с, Ватт, Кг и т.д.)

Таблица "Значения агрегированных показателей точки фиксации"
id - идент. значения показателя
point_id - идент. точки фиксации
param_id - идент. показателя
value_int - значение показателя в целых числах
value_flt - значение в вещественных числах
value_str - значение в строковом представлении
value_... - если нужен еще какой-то тип данных, которых можно индексировать.

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

Если не вдаваться в категории, то простым языком это выглядит так:

Если нужно только 100Мбит/с, то подойдет любой попавшийся кабель (можно сэкономить и взять тонкий кабель с 2 парами).
до 1Гбит/с - кабель должен содержать 4 пары, остальные характеристики не важны.
до 2,5Гбит/с или 10 Гбит/с - 4 пары, плюс металлизированная изоляция коннектора и кабеля, длина кабеля не может превышать 40 метров.

Но для это подойдет для поиска одного размера, а мне прилетает несколько. Не ужели скажем если 10 размеров прилетит, писать 10 запросов для проверки каждого размера?

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

select * from table
where 1 = 1 -- чтобы можно было однотипно подставить выражения с and или or, не заморачиваясь в каких случаях нужен and/or, а в каких нет.
or find_in_set('L', replace(value, ';', ','))
or find_in_set('XL', replace(value, ';', ','))
...
or find_in_set('XXXL', replace(value, ';', ','))

Вам нужно проработать архитектуру таблиц.
Чтобы удобно хранить свойства ads и serp в одной таблице, которые представленные в виде массива. Вам нужно не только выделить тип записи - ads или serp, но нужно как-то связать все записи, которые входят в одно событие свойства p1.
Допустим, для событий мы создаем таблицу Event со свойствами:
Event_Id - код события,
info - строка или JSON-тип,
success - число,
query - строка или JSON-тип,
total_count - число
...
Не все свойства p1 перечисляю, так как, например, paa - тоже массив, и нужно понять, будете ли под него выделять отдельную таблицу или приспособите какую-нибудь существующую, добавив новый тип - paa.
-----
А для хранения элементов массивов ads, serp (и, возможно еще каких-либо свойств-массивов, которые появятся непосредственно в p1 не во вложенных свойствах) вы создадите отдельную таблицу event_prop_array:
prop_arr_Id - код элемента свойства события
prop_id - тип свойства из таблицы-справочника типов свойств (внешний ключ)
event_id - событие, к которому относится запись, внешний ключ к таблице event
link - строка
snippet - строка
...
дальше идут другие скалярные свойства, которые можно найти в одном элементе ads или serp
------
Добавляем таблицу справочник, чтобы закодировать внешний ключ prop_id
Таблица event_prop
prop_id - код свойства
prop_name - имя свойства
----------------------------
Теперь, чтобы залогировать один элемент p1 нужно сделать так:
1. Вставить в таблицу event запись из простых свойств (info, success, query, total_count, ... )
2. Получить event_id вставленной записи (гуглите last_insert_id для PDO или дополнительную клаузу для insert - "returning event_id into :event_id", если вы используете, например, oracle, а не mySQL)
3. Получить prop_id из справочника (тут обычный select)
4. В цикле вставляете записи в таблицу event_prop_array, используя известные event_id, prop_id и текущие свойства элемента ads.
5. Тоже самое как 4, но используете свойства serp.
-------------------
Когда сформируете лог в базе, то типичный запрос для выборки чего-либо будет иметь вид:

select e.*, ep.*, epa.*
from event_prop_array epa
join event_prop ep on ep.prop_id = epa.prop_id
join event e on e.event_id = epa.event_id
-- какие-то условия для поиска
where e.event_id = 1
 and ep.prop_name = 'ads'

Контроллер памяти процессора в этом ноуте поддерживает до 32Гбайт.
https://ark.intel.com/content/www/ru/ru/ark/produc...
Так, что нет проблем поставить 2 по 8.

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

Что нужно знать и уметь для реализации такого алгоритма?

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

Какие технологии применяются?

Для обычного разработчика применяются навыки работы с API любых сервисов, к которым можно получить доступ через авторизацию, и в которые в режиме запрос-ответ дадут искомые данные.
1. Изучаете API условного Shazam-a, куда будете отправлять образцы звуковых данных.
2. Изучаете API музыкальных библиотек, куда будете отправлять результат ответа от Shazam, чтобы получить недостающие данные.

Как foreach-ем обходили контейнеры, чтобы инициализировать каждый слайдер:

$(какой-то селектор элемента или нода).slick(какие-то свойства инициализации);

Таким же путем нужно пробежаться по всем слайдерам и дать им команду обновить свое состояние (refresh) после того, как отработает функция renderProducts.

$('.slider__body').each(function () {
  $('.slider', $(this)).slick('refresh')
  $('.slick__thumbs', $(this)).slick('refresh')
})